The most common mistake in accounting systems is assuming the price list can change and history will "catch up". It will — and it will wreck your reporting.
Picture this: a customer bought a tee for 2,490 ₽. A month later you raise the price to 2,990 ₽. If the order line points at the product's "current price", their past order suddenly costs more — in reports, reconciliations, refunds. Money that already cleared the till changes retroactively.
What a snapshot means
The right approach: an order line stores the price at the time of sale (a snapshot), not a reference to the product's current price. Editing the price list no longer rewrites the past — the order forever remembers what it actually cost.
Technically it's simple: the order line carries not just product_id but also price, name and vat_rate at creation time. A little more data — in exchange for immutable history.
Where else it matters
The same goes for tax rates, exchange rates, plan terms and delivery address. Any fact that affects money or obligations is frozen at the moment of the event and no longer depends on reference data.
Any fact that affects money is frozen at the moment of the event — and no longer depends on reference data.
In the PAINKILLER case, snapshot prices on order lines are exactly what let them change the price list and run promotions without breaking the 54-FZ fiscal history.
It's a little more data, but in return you get reproducible history, correct reconciliations and calm audits. It's far cheaper to design this up front than to untangle discrepancies a year later.