At close of business, the clerk’s cash-drawer process must total tender types and write one daily reconciliation row. Which object should implement that workflow?
Select an answer to reveal the explanation.
Short Explanation
End-of-day close is a mini batch job—sum the tenders, drop one reconciliation row—and a stored procedure is the tidy place to run that script. Constraints and graph MATCH are not your cash-out routine.
Full Explanation
At close of business, totaling tender types and writing one daily reconciliation row is a short batch workflow: read today’s tender transactions, aggregate by type, insert a single reconciliation summary, and perhaps mark the drawer closed. A stored procedure is the appropriate object—callable by the clerk’s end-of-day button or a scheduled job—with clear transactional boundaries so the aggregate and the reconciliation insert commit together.
A UNIQUE constraint on tender_type prevents duplicate type codes; it does not auto-build reconciliation summaries. A graph MATCH query over facility–incident edges is for relationship traversal, not cash-drawer totals. An INSTEAD OF trigger on a read-only open-data view of park hours neither runs at close of business nor aggregates tender types into a reconciliation row.
Exam caveat: procedures own multi-statement operational close processes; constraints and graph features solve integrity and relationship questions, not nightly cash-out scripts. Operational check: seed known tender rows for a business date, execute the procedure once, verify exactly one reconciliation row with expected totals, execute again under the procedure’s idempotency rules, and confirm you do not get duplicate close rows.