ТЕХНИЧЕСКОЕ ЗАДАНИЕ.

Доработка обмена 1С (выставка) и личного кабинета (подтверждение

клиентами заказов).
Обмен состоит из двух частей: 1СЛК и ЛК1С. На данный момент обмен ЛК1С всех
устраивает, а доработка требуется только для 1СЛК.
Обмен 1СЛК организовать следующим образом:
1. Разделить выгрузку на три части:
a. каталог с товарами Catalog.xml
b. каталог клиентов Clients.xml
c. заказы клиентов Orders.xml

2. Выгрузку строить по аналогии с выгрузкой каталогов на обычный сайт Робека: начальный

снимок (однократно) + дельта (часто в течении дня). Дельта – это изменение цифровых
величин относительно начального снимка. Отличие будет только в том, что речь идет не
об остатках, а о заказах. Заказ характеризуется двумя цифровыми величинами: «кол-во» и
«цена». Такой подход уменьшит размеры часто передаваемых данных и ожидается, что
период между дельтами получится уменьшить.

3. В выгрузку и начального снимка, и дельты также добавить файл info.xml, в нем

разместить тег <GUID>, который будет сцеплять начальный снимок с дельтой. По
значению этого тега необходимо делать проверку при загрузке очередной дельты: а с тем
ли GUID-ом была предыдущая загрузка начального снимка, и если с другим, то дельту не
загружать, а пытаться загрузить вначале начальный снимок, так как вероятно появился
новый. Предполагается, что в течение дня менеджеры захотят полностью обновить
начальный каталог, сделают новый начальный снимок, и дельта уже будет слаться
относительно его, при этом не прибегая к помощи программистов.
Также в файл info.xml добавить тег <GUID_file> - определяет уникальность конкретной
выгрузки пакета файлов. Пригодится для логирования загрузок.

4. Состав файлов для начального снимка и для дельты одинаков, только для дельты может
каких-то файлов не быть. Полный состав файлов:
a. Catalog.xml
b. Clients.xml
c. Orders.xml
d. info.xml

5. Обычно в дельте будут присутствовать только два файла Orders.xml и info.xml, но если со
стороны 1С захочется расширить каталог или обновить какие-то карточки в каталоге, то
появится файл Catalog.xml, в котором будет только то, что нужно обработать. Аналогично
с файлом Clients.xml: он появится, если добавятся новые клиенты в общем заказе
относительно начального снимка или захочется изменить реквизиты в карточке клиента.

6. Весь пакет файлов для начального снимка архивировать и размещать для обмена в папке
…\Zakaz1.
Аналогично делать для пакета фалов дельты.
Для начального снимка файл будет называться NachSn.zip
Для дельты – Delta.zip
Архивирование позволит избежать проблем недозагруженности файла в момент импорта:
если разархивировать получится, то файл был передан полностью и можно приступать к
 его обработке. Если же разархивировать не получилось, то нужно попытаться сделать это
повторно через некоторое время.

7. Вести лог загрузок в таблице загрузок в ЛК и дать возможность просматривать эту

таблицу из админки в ЛК.
Структура таблицы:
1) Дата/Время
2) Тип («Начальный снимок» либо «Дельта»)
3) GUID
4) GUID file
5) Кол-во записей, которые получилось загрузить из Catalog.xml
6) Кол-во записей, которые получилось загрузить из Clients.xml
7) Кол-во записей, которые получилось загрузить из Orders.xml
8) Коммент (здесь инфо о возникшей ошибке при загрузке либо «ОК»).

Алгоритм загрузки видится следующий:

1. В среде сайта храним значение GUID (значение тега GUID от последнего начального
снимка).
2. В папке …\Zakaz1 ищем файл дельты Delta.zip
a. Если нашли , то сверяем GUID из файла info.xml со значением GUID из П.1
i. Если GUIDы совпали, то загружаем дельту
ii. Если GUIDы НЕ совпали, то пытаемся найти файл NachSn.zip, загрузить
его, установить из него GUID в П.1 и вернуться к загрузке дельты П.2
b. Если не нашли, то ничего не делаем. Как вариант, можно в лог-таблице
загрузок сделать запись о попытке загрузки.
Файл дельты на стороне выгрузки всегда будет создаваться, даже если не было
изменений к начальному снимку.

Особенности при загрузке:

1. Файлы (и для начального снимка, и для дельты) загружаем в следующем порядке:
a. Catalog.xml
b. Clients.xml
c. Orders.xml
2. Если где-то встретится в таблице Orders.xml ссылка на несуществующую карточку
товара или ссылка на несуществующего клиента, то это повод оставить коммент об
ошибке в лог-таблице загрузок.
3. При загрузке каталога товаров из начального снимка необходимо первым проходом
во всей таблице на сайте сбросить признак хита, а при загрузке проставить там, где
надо.
Структура таблицы Catalog.xml:
Tov_Kod - код товара
Tov_Naim - наименование товара
Tov_Art - артикул товара
Tov_TM - торговая марка товара
Tov_Vid - вид товара
Tov_Pol - пол товара
Tov_Sezon - сезон товара
Tov_KolKor - кол-во в коробе
Tov_Razm - название ростовки
Tov_MatPodkl - материал подклада
Tov_MatVerha - материал верха - новый реквизит
Tov_MatPodosh - материал подошвы - новый реквизит
Tov_HIT - признак ХИТа товара - новый реквизит
TipPrice - наименование типа цены (заполняется только для ХИТов)
Price - цена в общем каталоге (заполняется только для ХИТов)
Foto_Dir - папка, где искать фото к товару.

Структура таблицы Clients.xml:

Kontr_Kod - код клиента
Kontr_Naim - наименование клиента
Kontr_INN - ИНН клиента
Kontr_Filial - филиал клиента - новый реквизит
Kontr_Reg - регион клиента.

Структура таблицы Orders.xml:

Kontr_Kod - код клиента
Tov_Kod - код товара
TipPrice - тип цены
Price - цена в заявке конкретного клиента (теоретически может
отличаться от цены в общем каталоге)
Kol - в файле NachSn.zip несет смысл кол-ва заказанного клиентом
товара, в файле Delta.zip несет смысл изменения количества
товара.

Пример для тега Kol:

в начальном снимке Kol = 10
в дельте Kol = -2
это означает, что первоначально у клиента был заказ на 10, а потом его заказ
скорректировали до 8.

Колонки TipPrice и Price в дельте – это не изменение к цене в начальном снимке, а

всегда текущая цена в заявке клиента. Попытка её изменить в ЛК по данным из
дельты должна быть всегда.

Может быть ситуация, когда в дельте Kol=0, но при этом TipPrice и Price заполнены.
Это означает, что кол-во заказа не поменялось, а изменилась цена в заказе клиента.

Если в результате сложения тегов Kol из начального снимка и из дельты получилось 0

или отриц. значение, то такие строчки визуально в ЛК клиенту не показывать, даже
если по товару уже клиент успел сделать подтверждение, и в итоги таблицы такие
строчки не считать (обсуждалось с Верой).