Written by DROPS.ST.
Separate permission to change shop records from responsibility for preparing and releasing a report. Before comparing two outputs, agree the source, included records, definitions and time covered. A different total may reflect a different scope rather than an incorrect order.
DROPS links Customer Accounts, orders and items, giving a cannabis-shop team common records to inspect. Use that connection to explain the report’s basis, then assign preparation, review and any authorized correction separately. Do not change a live record simply to make a spreadsheet agree.
Define the question the report must answer
Identify the intended decision and the population of records. Confirm which states, dates, items or accounts belong in the scope, using the actual supported information.
“Orders received,” “completed orders” and “items counted” are different measures. Record the definition rather than relying on the file name. State the time of preparation where continuing activity could affect a later output.
If the available download cannot supply the agreed scope, identify an approved preparation method or mark the gap. Do not assume native filters, historical snapshots or a bulk report exist.
Keep an entry-and-release record
This original working record belongs in the business-approved process, not an assumed DROPS approval screen.
| Responsibility or check | What to record | Release decision |
|---|---|---|
| Record-entry authority | Who may make the relevant supported changes | Corrections stay with an authorized person |
| Source and scope | Records, definitions and time basis | Reviewer knows what was included |
| Preparer | Person creating the output and method used | Work can be explained and repeated where supported |
| Reviewer and backup | Named people and required checks | Absence does not create silent approval |
| Reconciliation | Record counts, quantities and unexplained differences | Exceptions are resolved or clearly held |
| Release | Identified version, recipient and approved purpose | The accepted output is unambiguous |
NIST’s separation-of-duties control connects defined responsibilities with supporting access. Apply that principle to the actual tools; a written split does not prove software enforcement. NIST AC-5.
Investigate the difference before authorizing a correction
Compare scope and definitions first. Check whether a later record changed the population, whether an item uses another unit, or whether the two outputs represent different order states.
Use a relevant reference to explain each exception. If the underlying shop record needs correcting, obtain the applicable authorization and reconcile the result. If the report needs correcting, distinguish that from a transaction change.
Keep the accepted version identifiable. This is an owner-managed release decision, not a promise that all earlier values can be recovered through native immutable history.
Hypothetical example: twelve records versus eleven
Two workers prepare a fictional report. One includes twelve received orders; the other excludes one order under a different state definition and includes eleven.
The reviewer confirms the intended population and explains the difference before choosing the report to release. There is no reason to edit the excluded order merely to force the totals to match.
These hypothetical figures show a scope check, not a native report calculation or regulatory reporting rule.
Match access to the actual task
Preparing a report does not justify cancellation, refund or payment authority. DROPS has separate order-action controls, and shop settings require an administrator. Catalogue editing also includes customer-account edits and wallet adjustments; it is not a report-only grant.
Account-data exports require appropriate account access and export authority, while individual order downloads follow order-view authorization. Use the export permissions guide to review the file-handling boundary separately from the report-release decision.
Do not pass logins between preparer and reviewer. If someone lacks needed access, arrange an authorized review or revise the responsibility.
Release the evidence your team can explain
Confirm the version, purpose, recipient and unresolved limitations before sharing the output. Keep the necessary review record without claiming that it is a native audit log. Required financial or regulatory submissions need their own approved scope.
DROPS gives your team connected order and item context. Pair it with clear preparation and review responsibility so the report reflects an agreed question rather than whichever worker downloaded it last.
Explore DROPS.ST and the shop demos. Rehearse two fictional outputs with different definitions and show how the reviewer identifies the accepted version without changing business records unnecessarily.