The context
A local operational ledger connected source documents, product mappings, physical counts, receipts, transfers and payment allocations. The practical requirement was to preserve evidence and uncertainty while preventing repeated processing from silently creating another purchase, movement or payment record.
What was done
Use exact decimals for quantities and integer minor units for money. Store an event identifier together with its type and canonical payload. An identical retry returns the existing result; changed details under that identifier are rejected.
Commit receipts and paired transfer movements atomically. Check for an existing receipt before posting, block unresolved stock units and preserve referenced human events during imports. Test rollback after an injected failure and verify that backup creation refuses to overwrite an existing file.
What was observed
Inspected code and test contracts cover duplicate receipts, conflicting event identifiers, precise arithmetic, transactional rollback and preservation across imports. A saved local verification includes an isolated count-entry exercise; it does not turn that test entry into production stock.
Historical purchases remain distinct from present inventory. Without a physical-count baseline, stock remains unknown. Payment allocation is recorded with its evidence but is not represented as payment execution or independent bank reconciliation.
What this establishes
The mechanism covers a bounded local ledger. Physical arrival, partial deliveries, in-transit stock and subsequent corrections require explicit operational confirmation or additional workflows.
What comes next
Develop auditable corrections and reversals, then test one reconciled period using permitted source records. Keep reporting coverage, physical confirmation and responsibility for unresolved entries visible.