Легенда:
1. Оператор Торговой системы СМ+ формирует "Заказ поставщику".
2. Торговая система СМ+ автоматически отправляет (здесь и далее используется специальный модуль системы "Почтовый модуль" или "Сервер обмена" входящий в стандартную поставку ПО) его по EDI.
3. Поставщик, реагирует на заказ и высылает «Подтверждение заказа». "Подтверждение заказа" может как полностью повторять "Заказ поставщику" (поставщик везет, то, что просили), так и отличаться от заказа т.е. содержать другую отличающуюся от заказа спецификацию (поставщик везет, то, что есть...)
4. Оператор ознакамливается с требованием, и тут три сценария:
4.1. Соглашается со спецификацией, поскольку не видит расхождений. (на этом этапе СуперМаг Плюс может "промолчать", а может "вернуть" "Подтверждение заказа" не исказив его содержимое, но, в другом статусе. (Например, "Подтверждение заказа" было получено было в статусе - "Принят (1)", а факт ознакомления и подтверждения со стороны заказчика будет - "Закрыт(2)".)
4.2. Отказывает поставщику в поставке. "Подтверждение заказа", остается в том виде, в котором оно пришло от поставщика. Документ не модифицируется. При это оператор в интерфейсе документа нажимает специальную кнопку "Отменить заказ". Система переводит "Заказ поставщику" в заблокированное состояние (статус документа меняется на 0 ). После чего "Заказ поставщику" пересылается поставщику. Статус документа = 0, будет говорить поставщику, что его «тут не ждут», товар его не нужен, привозить ничего не надо.
4.3. Соглашаемся с поставщиком (с его изменениями). "Подтверждение заказа", остается в том виде, в котором оно пришло от поставщика. Документ не модифицируется. При это оператор в интерфейсе документа нажимает специальную кнопку "Согласовать заказ". Система переводит "Заказ поставщику" в заблокированное состояние (статус документа меняется на 0 ). И сразу создает новый документ "Заказ поставщику". Оба документа высылаются поставщику. Один отменяет ранее сделанный заказ, другой показывает поставщику, что фактически с его правками мы согласны. Но, т.к. с момента получения "Подтверждения заказа", и формирования нового "Заказа поставщику" может пройти достаточно много времени - оптимально: если поставщик закрепит достигнутые договоренности и вышлет еще раз "Подтверждение заказа".....И у нас опять 3 варианта сценария.....
5. Только после прохождения п.5.1, 5.3. Поставщик должен сформировать "Накладную поставщика", и в основании проставить корректный номер "Заказа поставщику".
6. Товар физически поступит на Торговую точку
7. Оператор сформирует "Приходную накладную", на основании "Заказа поставщику" и "Накладной поставщика". И почтовый модуль автоматически вышлет уведомление о факте поставки, в виде "Приходной накладной." Спецификация "Приходной накладной" будет содержать реально принятое количество, в независимости от спецификации "Заказа поставщику", "Подтверждения заказа" и "Накладной поставщика". Т.е. в "Приходной накладной" будет зафиксировано реальное, а не бумажное количество.
Описание объектов.
| Тип объекта | Описание объекта | Название объекта в Торговой системе СуперМаг Плюс | Направление обмена | Схема объекта для Супермаг Плюс | Пример объекта в виде файла | Комментарий |
|---|---|---|---|---|---|---|
| Order | ORDERS («Заказ») — тип EDI-сообщений, который содержит запросы на поставку определённого количества товара. Компания-покупатель создаёт заказ в своей учётной системе или в личном кабинете на платформе электронного документооборота, после чего мгновенно отправляет его деловому партнёру. | Тип OR - Документ Заказ поставщику предназначен для формирования заказа поставщику, а именно: перечня заказываемых артикулов, их количества и условий поставки заказа. Заказ используется для заказа необходимых товаров у поставщика в терминах артикулов486px поставщика и для контроля соответствия поставок товаров заказанному количеству. Документ имеет статусы: "Заблокирован", "Черновик", "Размещен", "Закрыт". Статус "Размещен" означает факт завершения формирования заказа для передачи его поставщику. Статус "Закрыт" означает завершение работ с поставками по данному заказу, независимо от полноты его исполнения. При получении статуса "Размещен" количество товара, указанное в заказе, отражается на остатках товара в колонке "Поставка". Количество товара, ожидаемого к поставке, учитывается в алгоритмах генерации заказа, чтобы не допустить повторный заказ уже заказанного товара. При получении статуса "Закрыт" недопоставленное количество товара по заказу изымается из количества, ожидаемого к поставке, и может быть помещено в следующий заказ. При оформлении приходной накладной на основании заказа и получении накладной статуса "Принят в количестве", одновременно с увеличением товарного остатка товара происходит уменьшение количества товара, ожидаемого к поставке по данному заказу. |
| Схема, и соответственно пример файла, может быть изменены интегратором под свои персональные задачи. Возможность добавления новых полей, колонок, объектов и т.п. следует уточнять в службе технической поддержки компании разработчика. | ||
| Ordersp | Как только деловые партнёры начинают обмениваться EDI-сообщениями ORDERS («Заказ»), сразу же возникает потребность в использовании ORDRSP («Ответ на заказ»). | Тип OE - Документ Подтверждение заказа поставщику предназначен для получения ответа от поставщика о подтверждении или отклонении позиций заказа или всего заказа. Документ может быть использован для принятия решения об отказе от заказа или об изменении заказа и его дальнейшего согласования, например, если265px поставщик подтвердил возможность частичного выполнения заказа. Документ может создаваться вручную по данным, полученным от поставщика, или может быть принят по почте, например, с использованием системы электронного документооборота. |
| Схема, и соответственно пример файла, может быть изменены интегратором под свои персональные задачи. Возможность добавления новых полей, колонок, объектов и т.п. следует уточнять в службе технической поддержки компании разработчика. | ||
| Desadv | DESADV – один из типов EDI-сообщений, который входит в стандартную цепочку: ORDERS, ORDRSP, DESADV, RECADV. С помощью этого стандартизированного электронного сообщения поставщики уведомляют торговые сети о том, что поставляемый товар отгружен со склада и отправляется в магазин. | Тип WE - Документ Накладная поставщика является документом, определяющим окончательные намерения поставщика поставить товар в обозначенном количестве и с указанной ценой. Документ должен приходить по почте или системе электронного документооборота от поставщика и не может создаваться вручную. Документ не приводит к изменению остатка товара и не порождает финансовое обязательство перед поставщиком. Документ может быть использован в качестве основания для формирования приходной накладной, а также источником информации о поставке в случае доверительного приема поставки, когда прием товара производится без его пересчета в процессе приемки. Документ, будучи принятым из внешней системы, может пересылаться в другие базы данных по правилам рассылки почтового модуля. |
| Схема, и соответственно пример файла, может быть изменены интегратором под свои персональные задачи. Возможность добавления новых полей, колонок, объектов и т.п. следует уточнять в службе технической поддержки компании разработчика. | ||
| Recadv | RECADV — это EDI-сообщение, которое заказчик отправляет поставщику после фактической приемки товара. По сути, это уведомление о приемке, которое подтверждает, что заказ получен. RECADV — замыкающее сообщение в базовой EDI-цепочке. | Тип WI - Документ Приходная накладная предназначен для регистрации факта поступления товаров в места хранения предприятия от внешних контрагентов. В документе "Приходная накладная" регистрируются данные из товарной накладной контрагента, а также часть сведений о сопроводительных документах - сертификатах соответствия, справок ГТД/ТТН и сведений о товаре - срок истечения годности, страна происхождения и т.д. В документе может быть отражена разница между количеством, указанным в документе контрагента, и фактически принятым количеством. Разница может быть использована для формирования актов несоответствия. Документ имеет статусы: "Заблокирован", "Черновик", "Принят на складе", "Принят полностью". При получении документом статуса "Принят на складе", количество из документа отражается на остатках места хранения в колонке "Остаток" и в колонке "В приемке/в пути". При получении документом статуса "Принят полностью" документ считается полностью оформленным и количество документа изымается из колонки "В приемке/в пути". Приходная накладная может быть создана на основании заказа и, в этом случае, получение накладной статуса "Принят на складе" влияет на количество товара, ожидаемого к поставке по данному заказу. Документ имеет товарные операции, выбор которых зависит от категории контрагента (поставщик или клиент) или от учетного действия - инвентаризации излишков. |
| Схема, и соответственно пример файла, может быть изменены интегратором под свои персональные задачи. Возможность добавления новых полей, колонок, объектов и т.п. следует уточнять в службе технической поддержки компании разработчика. | ||
| УПД | Универсальный передаточный документ (УПД) – документ, совмещающий в себе свойства счёта-фактуры, товарной накладной и акта выполненных работ. | Тип IU - Документ УПД на приход предназначен для хранения данных о содержании УПД, полученного из системы электронного документооборота. Документ участвует в бизнес процессе приема маркированного товара и содержит согласованные обоими сторонами данные о составе поставки и перечне КИЗ поставленного товара. Документ служит основанием для выполнения регламентированных процедур электронного документооборота. |
| Схема, и соответственно пример файла, может быть изменены интегратором под свои персональные задачи. Возможность добавления новых полей, колонок, объектов и т.п. следует уточнять в службе технической поддержки компании разработчика. | ||
Цепочка обмена по ЭДО.
| Тип объекта | Описание объекта | Название объекта в Торговой системе СуперМаг Плюс | Направление обмена | Схема объекта для Супермаг Плюс | Пример объекта в виде файла | Комментарий |
|---|---|---|---|---|---|---|
| OR |
| 1. Пользователь Торговой системы Супермаг Плюс формирует документ «Заказ поставщику». Тип документа в СМ+ => OR. (Пример: OR_230412095637_19347_2_1.XML). Для целей дополнительных уведомлений как поставщика, так и заказчика используется специальный атрибут документа - <DOCSTATE>X</DOCSTATE>, где: 2 – заказ подготовлен, ожидает рассмотрения у поставщика. 0 – заказ аннулирован заказчиком, поставщик не должен исполнять данный заказ. 1 – (обычно не используется при обмене) – черновик документа, находится в редакции заказчика. 3 - (обычно не используется при обмене) –документ проведен, исполнен, товар поставлен. | ||||
| OE |
| 2. Поставщик получает заказ, и запускает процедуру его обработки, подготовки товара к отгрузке. Опционально (не обязательно), поставщик может сформировать и выслать документ «Подтверждение заказа». Этот документ получит заказчик, ознакомится с ним, и примет окончательное решение о готовности получить товар. Документ «Подтверждение заказа», Может: - Полностью повторять заказ (спецификация, количество, цены). - Отличаться от «Заказа поставщику» (количество, цены). - Отличаться от «Заказа поставщику» (спецификация (замена)). Этот пункт нужно расценивать как опцию. Т.к. маловероятно, что заказчик захочет получить «кота в мешке». Тип документа в СМ+ => OE. (Пример: OE_ORDRSP_1.XML). В настоящее время логика реализована следующая: - Если заказчик согласен с предложением, Торговая система никак не проинформирует об этом поставщика. - Если заказчик не согласен с предложением, Торговая система проинформирует об этом поставщика, осуществив рассылку в сторону поставщика документа «Заказ поставщику» в <DOCSTATE>0</DOCSTATE>. | ||||
| UI |
| 3. Поставщик формирует документ УПД. И направляет в сторону заказчика, документ «УПД на приход». (Пример: UI_UPD_OSU.XML, UI_UPD_KIZ.xml). | ||||
| REPLY |
| 4. Заказчик получает документ в систему, и в любо момент времени, по факту прибытия товара может начать его приемку. - Товар принят частично. Есть расхождения (обнаружены расхождения в спецификации, количестве, цене или сумме). (Пример: REPLY_RESULT_3_УПД.XML). <RESULT>3</RESULT> + причина расхождения + спецификация отражающая факт поставки. Ожидаем новую УПД. - Товар принят частично. Есть расхождения (обнаружены расхождения в спецификации, количестве, цене или сумме). (Пример: REPLY_RESULT_2_УКД.XML). <RESULT>2</RESULT> + причина расхождения + спецификация отражающая факт поставки. Ожидаем УКД. Опциональная возможность. - Товар не принят полностью. Заказчик отказался от поставки. (Пример: REPLY_RESULT_3_ОТКАЗ.XML). <RESULT>3</RESULT> + НЕТ причина расхождения + НЕТ спецификации. Ничего более не ожидаем. | ||||
| APPERAK |
| 6. По факту завершения процесса обмена, провайдер электронного документооборота, высылает в Супермаг Плюс специальную квитанцию. Эта же квитанция может использоваться в случае возникновения ошибки, например – не удалось подписать. Реакций со стороны СМ+ на эту квитанцию последовать не будет. Пользователь увидит это сообщение в теле УПД, и предпримет определенные действия. (Пример: APPERAK_Успех.xml, APPERAK_Не_удача.xml). Если RESULT = 1 (при отсылке файла подтверждения с флагом приема) или 2 (при отсылке файла подтверждения при приеме с расхождением), то считается, что ответ о результате приемки провайдером принят успешно. Описание: <APPERAK> Если после отсылки файла подтверждения будет получена квитанция со значением RESULT = 3, что означает ошибку при прохождении в системе ЭДО, то файл подтверждения можно будет отослать повторно из открытого на просмотр документа: Если RESULT = 1 (при отсылке файла подтверждения с флагом приема) или 2 (при отсылке файла подтверждения при приеме с расхождением), то считается, что ответ о результате приемки провайдером принят успешно. |