Работа с Честным знаком из Супермаг Плюс построена по принципу «работа из одного окна», т.е. сотрудникам, которые работают в Торговой системе и должны взаимодействовать с государственными системами (ЕГАИС, Меркурий, Честный знак) не нужно заходить в несколько программ. Все необходимые документы загружаются в Супермаг Плюс и появляется возможность создавать учетные документы на основании документов ФГИС. Дополнительная возможность сопоставлять номенклатуру ФГИС и учетную номенклатуру позволяет минимизировать ошибки, связанные с человеческим фактором.
Общие принципы работы с маркированными товарами:
1. Факт перехода прав собственности на товар фиксируется через электронный документ, полученный по ЭДО.
2. Факты выбытия маркированной продукцией из оборота фиксируется на кассовом ПО при продаже конечному покупателю
В решении Супермаг Плюс есть возможность подключить электронный документооборот через сервис ПО СБИС (от компании Тензор).
Внимание!Идентификатор участника обмена который устанавливается в документе "УПД на приход", и "Накладная поставщика".
Не передается в явном виде от провайдера электронного документооборота. В настоящее время для его модификации следует изменить схему объекта UI.XSD
Оптимально (но не обязательно!), если его значение будет равно значению переменной в файле UI.XML. В принципе значение может принимать любой вид, главное, чтобы оно было уникальным, если одна БД обслуживает несколько ЮР лиц. <SMWAYBILLSEXT> После того, как изменена схема, установлено значение по умолчанию (или оставили все как есть, т.е. "1"). Проверьте настройку в почтовом модуле, параметр "Собственный идентификатор участника документооборота" - должен быть равен этому значению.
Зачем это сделано?Сценарий таков:
|
|---|
Здесь и далее, предлагается общая инструкция по настройке обмена электронными документами через провайдера Тензор (решение СБИС).
Схемы объектов используемые в процессе обмена (будут актуализироваться, изменяться, предлагаться варианты).
| № п.п. | Название объекта. | Тип объекта в СМ+ | Название файла. схемы | Файл схемы. (!эти файлы берем себе!) | Дата модификации. | Пример файла XML. Комментарий. |
|---|---|---|---|---|---|---|
| 1. | Заказ поставщику. | OR | OR.XSD | 25.06.2021 21.01.2022 | ||
| 2. | Подтверждение заказа поставщику. | OE | OE.XSD | 25.06.2021 | ||
| 3. | Накладная поставщика. | WE | WE.XSD | 25.06.2021 | В обмене с Тензор не участвует. (устарела). Возможно участие при использовании структуры с распределенными БД Супермаг. | |
| 4. | УПД на приход. | UI | UI.XSD | 25.06.2021 21.01.2022 до 1.048 01.06.2022 от 1.048 | UPD_Natur_Prod.xml Изменено значение в схеме для OURUTDID UPD_Natur_Prod_SMALL.xml ; UPD_Natur_Prod_SMALL2.xml | |
| 5. | Требование на отбор | SW | SW.XSD | 21.01.2022 | SW_Требование на отбор.xml - В обмене с Тензор не участвует. Возможно использование для решения локальных задач. Один из способов применения - формирование документа на обмен товара (хлеб). | |
| 6. | Ответ системы СМ+ на факт приемки. (до версии 1.045) | PACKAGE | UICONFIRM.XSD | 25.06.2021 | ||
| 7. | Ответ системы СМ+ на факт приемки. (от версии 1.046) | PACKAGE | UICONFIRM.XSD | 29.09.21 | нет примера | |
| 8. | Ответ системы СМ+ на факт приемки. (от версии 1.046) | PACKAGE | UICONFIRM.XSD | 29.09.21 | ||
| 9. | Ответ системы СМ+ на факт приемки. (от версии 1.046) | PACKAGE | UICONFIRM.XSD | 29.09.21 | нет примера | |
| 10. | Ответ системы СМ+ на факт приемки. (от версии 1.046) | PACKAGE | UICONFIRM.XSD | 31.03.2022 | Из схемы исключён элемент <xs:element name="SUPPLIERARTICLE" type="xs:string" /> Поскольку, отсутствие у карточки артикула поставщика, приводило к ошибке: ----- Причина исключения, уровень вложения 1 ----- Для обхода ошибки, есть 2 варианта:
Необязательные патчи для версии 1.047 сп2-3. Ошибка формирования файла ответа REPLY description_Результат приемки: Sm.Post.Filters.Utd.1.047x64.7z Неверный статус УПД при приеме немаркированного товара с расхождением: | |
| 11. | Квитанция провайдера ЭДО. Протокол обмена дополнен получением технической квитанции в ответ на отсылку файла с результатом приемки. Квитанция имеет смысл подтверждения успешности обработки и пересылки провайдером ЭДО файла подтверждения. | - | - | - | 14.03.2022 | |
| 12. | ||||||
| 13. |
Перечень готовых QR кодов для самопроверки, на основании UPD_Natur_Prod.xml → QR коды.docx
2. Требования для клиентов для подключения Интеграции СМ+
- 1. Наличие версии Супермаг Плюс 1.44 или выше.
- Наличие специальной расширенной лицензии для ПО Супермаг плюс в которой открыты модули:
- №121 УПД на отгрузку.
- №51 УПД на приход. - Расширенная лицензия выдается по договоренности между клиентом и его курирующим менеджером (со стороны компании Сервис Плюс) на коммерческой основе.
- Лицензированию подлежит каждый экземпляр БД, в случае если клиентом используется вариант «распределительных баз».
- В случае, если у клиента имеется одна единая БД которая используется для работы всех пользователей предприятия (склады, магазины, офис) – расширенная лицензия понадобится только одна.
- Лицензия открывает доступ к необходимым разделам ПО, и выдает разрешение на их использование всем пользователям СМ+ без ограничений.
- Для осуществления обмена данными на стороне СМ+ необходимо:
- Запустить и настроить Почтовый модуль Супермаг Плюс.
- В параметры настроек добавить две «Доверительные базы», например TENSOR1, TENSOR2 (или как на рисунках - SBIS_IN_УПД, SBIS_OUT).
- Каждая из БД должна производить обмен по протоколу FTP.
- Каждая из БД должна иметь свои уникальные каталоги обмена (IN, OUT).
- БД TENSOR1 – должна использовать фильтр «Стандартный фильтр XML»
- БД TENSOR2 – должна использовать фильтр «УПД XML» - Настройка отмеченная в п.7 обеспечивает обмен разными типами документов по разным каналам связи. (например, База TENSOR1 предназначена для обмена EDI объектами. База TENSOR2 предназначена для обмена УПД и УКД документами (в дальнейшем);
- Каждая из БД использует свои почтовые схемы объектов (XSD).
- Схемы объектов будут предоставляться службой Технической поддержки СМ+, но вариант разработки новых (других) схем самостоятельно клиентом– не исключён (если такая необходимость возникнет).
3. Общие принципы и условия обмена.
- Обмен подразумевает ситуацию при которой справочники (товары и их атрибуты, поставщики, клиенты и т.п.) не имеют полной синхронизации между отправителем и получателем.
- Поэтому идентификация объектов на принимающей стороне происходит по заранее определенным и назначенным признакам.
- Например: идентификация карточки, происходит на основании закрепленного за товаром Штрихового кода.
- Например: идентификация поставщика, происходит на основании GLN (GLN (Global Location Number) – глобальный номер места нахождения – уникальный номер в системе GS1 для идентификации участников цепи поставки и их материальных, функциональных или юридических объектов (подразделений) (филиалы/офисы/склады/рампы и т.д.). Используется главным образом в EDI для эффективной идентификации всех объектов, касающихся поставок).
- Торговая система Супермаг Плюс при формировании пакета на отправку или при осуществлении приема имеет возможность указания в схеме объекта XSD определенных функций, в задачу которых будет входить предобразование одной сущности в другую. Например: При приеме объекта со ШК, функция ArticleByBarcode* произведет преобразование ШК в артикул карточки товара в Супермаг Плюс. * - описание функций смотрите в бюллетенях изменений - Бюллетень изменений СуперМаг
- В качестве транспорта для передачи объектов со стороны Супермаг Плюс используется Почтовый модуль СуперМага работающий по протоколу FTP.
4. Необходимая информация для справочников Супермаг Плюс, которая требует обязательного указания и согласования с Тензор.
- Контрагент (Поставщик, Покупатель, Собственный контрагент). Указывается: ИНН, КПП, GLN.
- Контрагент (Поставщик). Указывается (опционально): на закладке "Артикулы контрагента" - спецификация поставляемой продукции, Арт. контрагента (внутренний код поставщика), Штриховой код товара (Штриховой код товара который зафиксирован в справочниках поставщика, для идентификации товара).
- Места хранения. Указывается: КПП, GLN
- Карточка товара. Указывается: На закладке "Штрихкоды", для одного ШК - атрибут "Обмен с EDI", именно этот ШК будет участвовать в отсылке поставщику. Алгоритм выбора ШК для отправки поставщику работает по следующему правилу: По умолчанию передается ШК поставщика, заранее заявленный в системе СМ+ (раздел контрагенты, закладка артикулы поставщика), если список артикулов и ШК у поставщика пуст. То передается ШК из раздела - карточка товара, который имеет признак - "Использовать при с EDI обмене". Если ни один штриховой код не отмечен, штриховой код будет подобран по правилу "первый попавшийся".
5. Настройки обмена.
- Для обеспечения полноценного обмена как EDI объектами, так и УПД и УКД объектами. Используются разные точки отправки и приемка.
- Пример настроек Почтового модуля для обмена EDI объектами:
- Пример настроек Почтового модуля для обмена УПД и УКД объектами:
5. Правила рассылки почтовых объектов.
- правила рассылок почтовых объектов указываются пользователями исходя из текущих потребностей, структуры сети и способа работы. Ниже представлены общие моменты.
- Интерфейс настройки:
- возможные настройки №1 (централизованная схема БД Супермаг (одна база данных)).
| № п.п. | Название объекта. | Тип объекта в СМ+ | Правило рассылки в доверительную базу. |
|---|---|---|---|
| 1. | Заказ поставщику. | OR | 1-2 |
| 2. | Подтверждение заказа поставщику. | OE | нет, или 2-3 опционально по договоренности с провайдером EDI. |
| 3. | Накладная поставщика. | WE | нет |
| 4. | УПД на приход. | UI | нет |
| 5. | Ответ системы СМ+ на факт приемки. | PACKAGE | ответ происходит в автоматическом режиме. |
Настройка №2 находится на этапе проектирования.Предполагаемое время готовности февраль 2022г. |
|---|
- возможные настройки №2 (распределенная схема БД Супермаг (одна старшая и множество подчиненных БД)).
Обмен с ЭДО и EDI (со всеми провайдерами) настроен в базе ЦО.
ЦО получает Накладную поставщика из магазина и отсылает ответ.
Справка:
Отличия между EDI и ЭДО
Теперь мы располагаем всей полнотой информации, чтобы уверенно ответить: EDI и ЭДО — разные системы. Доступен и ответ на вопрос о том, в чём заключаются отличия между ними. Главное из них — в следующем:
сообщения и документы в системе EDI имеют форму, не утверждённую законодательством — она определяется самими участниками обмена данными;
документация, передаваемая с помощью системы ЭДО, имеет форму, предусмотренную нормативными актами, и заверяется электронной цифровой подписью. Это придаёт ей юридическую силу и позволяет подавать в налоговые инспекции, суды, другие государственные и муниципальные органы.
Примечание:
№1 - В рамках версии 1.045 сп2. Была сделана доработка
Почтовый модуль. Функция импорта артикула XML файла.
В почтовый модуль добавлена функция ArticleByBarcodeUI для определения артикула при импорте XML файла по содержанию поля, предназначенного для хранения EAN штрихового кода артикула и/или таблицы с КИЗ.
Функция исследует значение поля для хранения штрихового кода. если поле содержит данные, то определяет артикул по штриховому коду, также как функция ArticleByBarcode. В противном случае функция исследует содержание таблицы с КИЗ и определяет артикул по содержанию первого попавшегося кода КИЗ (КИЗ содержит 14 символов GTIN товара после кода применения 01, из которого, в свою очередь, можно получить EAN товара отбрасыванием лидирующего нуля).
XSD схема должна содержать, как поле «BARCODE» (название может быть произвольным), так и таблицу с полем «MARCCODE», тогда как XML файл может содержать как оба поля, так и какое либо одно из них.
Функция ArticleByBarcodeUI предназначена, в первую очередь для обработки УПД на приход при приеме УПД от разных поставщиков, которые по разному формируют содержание документа.
--- Задача функции сводится к определению артикула из двух возможных источников.
Но, как показала практика, есть случаи, когда на товаре нет ШК, и еще нет КИЗ (не маркированный), чаще всего такой товар - является весовым.
В этом случае, "добыть" артикул нам не из чего. Конечно, можно исправить схему (убрать функцию: "ArticleByBarcode(BARCODE)" или "ArticleByBarcodeUI"). И передавать Артикул в явном виде в файле УПД (UI).
Но тогда сломается определение артикула для случаев, когда нужно опираться на ШК или КиЗ (т.е. для штучных товаров и маркированных товаров, а их порядка 90% в общем справочнике).
Предложение следующее (или \ или):
- Назначить на товар ШК = текущему артикулу.
- Назначить на товар любой короткий ШК, можно вообще любой.
- Назначить на товар ШК = артикулу поставщика.
Определить этот код, как "Используется при EDI обмене". Передавать его для поставщика и получать его обратно. На основании функций "ArticleByBarcode(BARCODE)" или "ArticleByBarcodeUI" - определять артикул товарной карточки. (т.е. не менять установленную логику работы).
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
№2 - Провайдер присылает документ с заполненной "меткой", необходимо было видеть значение этой же метки, но в другом документе.
Во вложении скрипт, который нужно пропустить по базе oracle от имени supermag.
Если по почте приходит документ «Подтверждение заказа поставщику» с изменившимся значением метки «EDIReceivedStatus»,
то это значение будет проставлено в ту же метку для заказа поставщику, находящегося в общих основаниях подтверждения заказа.
Ограничение: если после получения метки ее удалить из заказа поставщику и получить повторно документ
«Подтверждение заказа поставщику» с прежним значением метки, она в заказ поставщику не проставится,
т.к. в подтверждении заказа ее значение не изменится.
CentrTorg_DocPropsOE_Trigger.sql