Самая частая ошибка в учётных системах — считать, что справочник цен можно менять, а история «подтянется». Она подтянется — и развалит отчётность.
Представьте: клиент купил футболку за 2 490 ₽. Через месяц вы подняли цену до 2 990 ₽. Если позиция заказа ссылается на «текущую цену товара», то его прошлый заказ внезапно станет дороже — в отчётах, в сверках, в возвратах. Деньги, которые уже прошли через кассу, задним числом меняются.
Что значит snapshot
Правильный подход: позиция заказа хранит цену на момент продажи (snapshot), а не ссылку на текущую цену товара. Тогда правка прайса не переписывает прошлое — заказ навсегда помнит, за сколько его реально купили.
Технически это просто: в строке заказа лежит не только product_id, но и price, name, vat_rate на момент создания. Чуть больше данных — зато история неизменяема.
Где это важно ещё
То же касается ставок налога, курсов валют, условий тарифа и адреса доставки. Любой факт, влияющий на деньги или обязательства, фиксируется в момент события и больше не зависит от справочника.
Любой факт, влияющий на деньги, фиксируется в момент события — и больше не зависит от справочника.
В кейсе PAINKILLER именно snapshot-цены в позициях заказа позволили спокойно менять прайс и проводить акции, не ломая фискальную историю по 54-ФЗ.
Это чуть больше данных, но взамен вы получаете воспроизводимую историю, корректные сверки и спокойные аудиты. Дешевле заложить это сразу, чем разбирать расхождения через год.