Есть таблица товаров (Goods). У каждого товара есть цена. При создании заказа (Order) к нему прикрепляются товары с помощью дополнительной таблицы Goods__Order. При этом после заказа цены товаров в заказе не должны меняться, даже если они изменились в таблице Goods.
Один из вариантов - сохранять цену в таблицу Goods__Order. Но количество полей, которые не должны меняться, возможно, станет больше, и поэтому не хочется их все переносить в эту таблицу + вариант не очень универсальный.
Второй вариант, как мне кажется, можно логировать изменения в таблице Goods в таблицу Goods_audit, которая будет содержать изменения полей + номер версии (revision number). Это доступно через Hibernate Envers. Но тогда в таблицу Goods_Order нужно будет вносить id товара + номер версии + я не нашел примеров, что так делают.
Какой вариант будет лучше? Учитывая, огромное количество интернет-магазинов, наверное уже есть более-менее известное решение для этого. Да и во вариантах на php никакого Hibernate Envers нет.
Ответ
Заказ не является объектом бухгалтерского учета, это объект процессов логистики
и взаимоотношения с клиентами. Однозначных рекомендаций по
логистике и CRM не существует, правильная постановка таких процессов
является ноухау организации.
Пока заказ не оплачен, он является по сути предложением клиенту и
объектом любой переоценки.
В магазине могут действовать правила расчета цены
отдельного товара для клиента с учетом скидок (иногда и надбавок) -
скидка по промокоду, скидка за объем заказа (суммарный по всем
товарным позициям заказа), персональная скидка клиента (например - за
историю заказов, либо скидка отдельным категориям клиентов), и т.д.
За время, когда заказ ожидает оплаты, может стартовать кампания по
стимулированию спроса - на отдельные товары/группы начинает
действовать значительная скидка, которая отменяет другие скидки
(промокод, песональные и т.д.).
После того, как заказ оплачен (тем более - если исполнен), все
текущие условия - базовая цена, скидки, условия доставки и пр. -
должны быть зафиксированы и не подлежать дальнейшим изменениям.
В развитых eComm платформах типа Magento текущие цены ведутся в
отдельных объектах - прайс-листах, могут настраиваться правила
перерасчета цен (скажем, в зависимости от валютных котировок для импортных
товаров), ведется история изменения прайс-листов.
Правила перерасчета неоплаченных заказов также могут настраиваться.
Так должно быть, а реализуется ли это в конкретной eComm и как - зависит от платформы. Если сами пишете платформу - посоветуйтесь с отделом продаж :-)
Комментариев нет:
Отправить комментарий