Сразу скажу, что я программист 1С и постараюсь изложить принцип решения. Со стороны Сайта реализовывать будут разработчики.
[B]Задача[/B]:
Обновление цен на сайте (порядка 3000 товаров со скидками).
[B]Требования[/B]:
1. Обеспечение корректности цен.
2. Минимизация времени обновления
3. Необходимость проверки цен на сайте до того, как они начнут действовать
С нашей точки зрения, штатная загрузка цен из XML (CommerceML2.0) не удовлетворяет этим требованиям. Хоть время загрузки цен и будет относительно небольшим, но после загрузки кто-то должен их проверять и в случае ошибки этому сотруднику придется снова загружать цены и т.д.
Предполагаемое решение:
1. Добавить в MySQL дополнительную таблицу – аналог 1С-ного регистра сведений «Цены номенклатуры»:
[B]inforegister_catalog_price_1c[/B] - аналог регистра сведений «Цены номенклатуры»
[B]Columns[/B]:
- ID int(16) PK – Ид записи
- DATE datetime – Дата записи
- PRODUCT_ID int(11) – Ид товара
- CATALOG_GROUP_ID int(11) – Ид типа цены
- PRICE decimal(18,2) – Значение цены
- CURRENCY char(3) – Валюта
Если на товар должна быть установлена новая цена, например, с 01.01.2018 то в таблице добавится новая строка для товара с датой 01.01.2018 новой и ценой.
2. Существующую таблицу [B]b_catalog_price[/B] переименовывать в [B]b_catalog_price_old[/B].
3. Создать [B]View [/B]с именем [B]b_catalog_price[/B] с колонками (аналогичными исходной [B]b_catalog_price[/B]):
- ID int(11) AI PK
- PRODUCT_ID int(11)
- EXTRA_ID int(11)
- CATALOG_GROUP_ID int(11)
- PRICE decimal(18,2)
- CURRENCY char(3)
- TIMESTAMP_X timestamp
- QUANTITY_FROM int(11)
- QUANTITY_TO int(11)
- TMP_ID varchar(40)
- PRICE_SCALE decimal(26,12)
Выбираем в этот [B]View [/B]записи по следующему принципу:
- Для каждого товара запись с максимальной датой, меньшей, чем Текущая дата (колонка DATE) – т. е., актуальная цена для товара (аналог Среза последних цен Регистра сведений на текущую дату в 1С).
Т.о., при загрузке данных на сайт из 1С заполняется таблица [B]inforegister_catalog_price_1c [/B]необходимыми данными, которые средствами SQL попадают в созданный [B]View[/B] (загрузка будет доработана разработчиками).
При обновлении цен можно заранее загрузить данные в таблицу inforegister_catalog_price_1c на будущую дату. Эти данные можно будет проверить.
При наступлении даты начала действия новых цен, они автоматом будут получены из [B]View.[/B] Насколько я понял, необходимо будет очистить кэш страниц сайта.
Предполагаем также, что такое решение будет не сильно чувствительно к обновлениям, достаточно будет повторить подмену таблиц (однако не совсем понятно, что произойдет с [B]inforegister_catalog_price_1c [/B]при обновлении).
Прошу оценить это решение, насколько реально его реализовать, достаточно ли замены одной таблицы, чему стоит уделить внимание?
Высказывайте критику и предложения.
[B]Задача[/B]:
Обновление цен на сайте (порядка 3000 товаров со скидками).
[B]Требования[/B]:
1. Обеспечение корректности цен.
2. Минимизация времени обновления
3. Необходимость проверки цен на сайте до того, как они начнут действовать
С нашей точки зрения, штатная загрузка цен из XML (CommerceML2.0) не удовлетворяет этим требованиям. Хоть время загрузки цен и будет относительно небольшим, но после загрузки кто-то должен их проверять и в случае ошибки этому сотруднику придется снова загружать цены и т.д.
Предполагаемое решение:
1. Добавить в MySQL дополнительную таблицу – аналог 1С-ного регистра сведений «Цены номенклатуры»:
[B]inforegister_catalog_price_1c[/B] - аналог регистра сведений «Цены номенклатуры»
[B]Columns[/B]:
- ID int(16) PK – Ид записи
- DATE datetime – Дата записи
- PRODUCT_ID int(11) – Ид товара
- CATALOG_GROUP_ID int(11) – Ид типа цены
- PRICE decimal(18,2) – Значение цены
- CURRENCY char(3) – Валюта
Если на товар должна быть установлена новая цена, например, с 01.01.2018 то в таблице добавится новая строка для товара с датой 01.01.2018 новой и ценой.
2. Существующую таблицу [B]b_catalog_price[/B] переименовывать в [B]b_catalog_price_old[/B].
3. Создать [B]View [/B]с именем [B]b_catalog_price[/B] с колонками (аналогичными исходной [B]b_catalog_price[/B]):
- ID int(11) AI PK
- PRODUCT_ID int(11)
- EXTRA_ID int(11)
- CATALOG_GROUP_ID int(11)
- PRICE decimal(18,2)
- CURRENCY char(3)
- TIMESTAMP_X timestamp
- QUANTITY_FROM int(11)
- QUANTITY_TO int(11)
- TMP_ID varchar(40)
- PRICE_SCALE decimal(26,12)
Выбираем в этот [B]View [/B]записи по следующему принципу:
- Для каждого товара запись с максимальной датой, меньшей, чем Текущая дата (колонка DATE) – т. е., актуальная цена для товара (аналог Среза последних цен Регистра сведений на текущую дату в 1С).
Т.о., при загрузке данных на сайт из 1С заполняется таблица [B]inforegister_catalog_price_1c [/B]необходимыми данными, которые средствами SQL попадают в созданный [B]View[/B] (загрузка будет доработана разработчиками).
При обновлении цен можно заранее загрузить данные в таблицу inforegister_catalog_price_1c на будущую дату. Эти данные можно будет проверить.
При наступлении даты начала действия новых цен, они автоматом будут получены из [B]View.[/B] Насколько я понял, необходимо будет очистить кэш страниц сайта.
Предполагаем также, что такое решение будет не сильно чувствительно к обновлениям, достаточно будет повторить подмену таблиц (однако не совсем понятно, что произойдет с [B]inforegister_catalog_price_1c [/B]при обновлении).
Прошу оценить это решение, насколько реально его реализовать, достаточно ли замены одной таблицы, чему стоит уделить внимание?
Высказывайте критику и предложения.
