Сохранение цен в логах

#java #hibernate #jpa #интернет_магазин #ecommerce

Есть таблица товаров (Goods). У каждого товара есть цена. При создании заказа (Order)
к нему прикрепляются товары с помощью дополнительной таблицы Goods__Order. При этом
после заказа цены товаров в заказе не должны меняться, даже если они изменились в таблице
Goods.

Один из вариантов - сохранять цену в таблицу Goods__Order. Но количество полей, которые
не должны меняться, возможно, станет больше, и поэтому не хочется их все переносить
в эту таблицу + вариант не очень универсальный.

Второй вариант, как мне кажется, можно логировать изменения в таблице Goods в таблицу
Goods_audit, которая будет содержать изменения полей + номер версии (revision number).
Это доступно через Hibernate Envers. Но тогда в таблицу Goods_Order нужно будет вносить
id товара + номер версии + я не нашел примеров, что так делают.

Какой вариант будет лучше? Учитывая, огромное количество интернет-магазинов, наверное
уже есть более-менее известное решение для этого. Да и во вариантах на php никакого
Hibernate Envers нет.
    

Ответы

Ответ 1

Заказ не является объектом бухгалтерского учета, это объект процессов логистики
и взаимоотношения с клиентами. Однозначных рекомендаций по
логистике и CRM не существует, правильная постановка таких процессов
является ноухау организации.
Пока заказ не оплачен, он является по сути предложением клиенту и
объектом любой переоценки.
В магазине могут действовать правила расчета цены
отдельного товара для клиента с учетом скидок (иногда и надбавок) -
скидка по промокоду, скидка за объем заказа (суммарный по всем
товарным позициям заказа), персональная скидка клиента (например - за
историю заказов, либо скидка отдельным категориям клиентов), и т.д.
За время, когда заказ ожидает оплаты, может стартовать кампания по
стимулированию спроса - на отдельные товары/группы начинает
действовать значительная скидка, которая отменяет другие скидки
(промокод, песональные и т.д.).
После того, как заказ оплачен (тем более - если исполнен), все
текущие условия - базовая цена, скидки, условия доставки и пр. -
должны быть зафиксированы и не подлежать дальнейшим изменениям.
В развитых eComm платформах типа Magento текущие цены ведутся в
отдельных объектах - прайс-листах, могут настраиваться правила
перерасчета цен (скажем, в зависимости от валютных котировок для импортных
товаров), ведется история изменения прайс-листов.
Правила перерасчета неоплаченных заказов также могут настраиваться.


Так должно быть, а реализуется ли это в конкретной eComm и как - зависит от платформы.
Если сами пишете платформу - посоветуйтесь с отделом продаж :-)


Ответ 2

Топорный вариант В таблицу Order(заказ)пишите цену на момент заказа добавить поле
price(цена).
Создать таблицу price_history[ид товара,номер ревизии,цена, дата и прочее если надо]
и вносить каждое изменения цены туда. В таблице Goods хранится всего лишь ид ревизии цены.

Система оплаты для Интернет-магазина

Здравствуйте! Задался такими вопросами: Как организуется система оплаты заказов (товаров) для Интернет-магазина? Какие предварительные действия надо совершить? Как работает сам механизм, его структура и организация? Как правильно реализовать, и что для этого необходимо? В Инете конкретныx ответы не нашел, поэтому будьте добры подскажите. Спасибо.

Ответ

Многое зависит от платежной системы, которую вы собираетесь использовать. С отечественными я не работал, но вот работа с такими системами как: PayPal, E-Bay, UsaEpay, Authorize.NET и некоторыми другими сводится обычно к бональному использованию их АПИ. Обычно у данных систем есть некие веб-сервисы (с документацией на сайте естественно) и вам нужно всего лишь научиться с ними работать. Более того, некоторые системы даже предоставляют "обёртку" в виде написанных ними библиотек под разные ЯП для работы со своим АПИ, что делает процесс еще более простым. Данное АПИ позволяет логиниться к ним в систему, проводить платежи на определенные кошельки, анализировать ошибки и другие транзакции с платежами. Качество данных АПИ бывает самым разным и иногда лучше использовать свой код, чем пользоваться ихним, ну да такое я встревал всего лишь раз. Важным моментом является при выборе подобной системы (если у вас конечно есть такая возможность) - это наличие тестового сервера на их стороне для проверки вашего кода на тестовых данных без реальных транзакций с деньгами! Это может быть большой проблемой, если вы сможете обнаружить ошибки только на этапе выхода в жизнь! Вкратце как-то так. Ну и для примера даже скажу некоторые цифры: для изучения любой платежной системы необходимо 2-3 дня максимум (если вам нужно банальный эл-магазин реализовать) и пару дней на внедрение в проект. Бывают конечно исключения, но обычно так выходит +-

Сохранение цен в логах

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

Ответ

Заказ не является объектом бухгалтерского учета, это объект процессов логистики и взаимоотношения с клиентами. Однозначных рекомендаций по логистике и CRM не существует, правильная постановка таких процессов является ноухау организации. Пока заказ не оплачен, он является по сути предложением клиенту и объектом любой переоценки. В магазине могут действовать правила расчета цены отдельного товара для клиента с учетом скидок (иногда и надбавок) - скидка по промокоду, скидка за объем заказа (суммарный по всем товарным позициям заказа), персональная скидка клиента (например - за историю заказов, либо скидка отдельным категориям клиентов), и т.д. За время, когда заказ ожидает оплаты, может стартовать кампания по стимулированию спроса - на отдельные товары/группы начинает действовать значительная скидка, которая отменяет другие скидки (промокод, песональные и т.д.). После того, как заказ оплачен (тем более - если исполнен), все текущие условия - базовая цена, скидки, условия доставки и пр. - должны быть зафиксированы и не подлежать дальнейшим изменениям. В развитых eComm платформах типа Magento текущие цены ведутся в отдельных объектах - прайс-листах, могут настраиваться правила перерасчета цен (скажем, в зависимости от валютных котировок для импортных товаров), ведется история изменения прайс-листов. Правила перерасчета неоплаченных заказов также могут настраиваться.
Так должно быть, а реализуется ли это в конкретной eComm и как - зависит от платформы. Если сами пишете платформу - посоветуйтесь с отделом продаж :-)