| Оглавление |
|---|
Легенда:
1. Оператор Торговой системы СМ+ формирует "Заказ поставщику".
2. Торговая система СМ+ автоматически отправляет (здесь и далее используется специальный модуль системы "Почтовый модули модуль" или "Сервер обмена" входящий в стандартную поставку ПО) его по EDI.
3. Поставщик, реагирует на заказ и высылает «Подтверждение заказа»«Подтверждение заказа». "Подтверждение заказа" может как полностью повторять заказ "Заказ поставщику" (поставщик везет, то, что просили), так и отличаться от заказа т.е. содержать другую отличающуюся от заказа спецификацию (поставщик везет, то, что есть...)
...
4.1. Соглашается со спецификацией, поскольку не видит расхождений. (на этом этапе СуперМаг Плюс может "промолчать", а может "вернуть" "Подтверждение заказа" не исказив его содержимое, но, в другом статусе. (Например, "Подтверждение заказа" было получено было в статусе - "Принят (1)", а факт ознакомления и подтверждения со стороны заказчика будет - "Закрыт(2)".)
4.2. Отказывает поставщику в поставке. "Подтверждение заказа", остается в том виде, в котором оно пришло от поставщика. Документ не модифицируется. При это оператор в интерфейсе документа нажимает специальную кнопку "Отменить заказ". Система переводит "Заказ поставщику" в заблокированное состояние (статус документа меняется на 0 ). После чего "Заказ поставщику" пересылается поставщику. Статус документа = 0, будет говорить поставщику, что его «тут не ждут», товар его не нужен, привозить ничего не надо.
4.3. Соглашаемся с поставщиком (с его изменениями). "Подтверждение заказа", остается в том виде, в котором оно пришло от поставщика. Документ не модифицируется. При это оператор в интерфейсе документа нажимает специальную кнопку "Согласовать заказ". Система переводит "Заказ поставщику" в заблокированное состояние (статус документа меняется на 0 ). И сразу создает новый документ "Заказ поставщику". Оба документа высылаются поставщику. Один отменяет ранее сделанный заказ, другой показывает поставщику, что фактически с его правками мы согласны. Но, т.к. с момента получения "Подтверждения заказа", и формирования нового "Заказа поставщику" может пройти достаточно много времени - оптимально: если поставщик закрепит достигнутые договоренности и вышлет еще раз "Подтверждение заказа".....И у нас опять 3 варианта сценария.....
5. Только после прохождения п.5.1, 5.3. Поставщик должен сформировать "Накладную поставщика", и в основании проставить корректный номер "Заказа поставщику".
6. Товар физически поступит на Торговую точку
7. Оператор сформирует "Приходную накладную", на основании "Заказа поставщику" и "Накладной поставщика.8. И ". И почтовый модуль автоматически вышлет уведомление о факте поставки, в виде "Приходной накладной." Спецификация "Приходной накладной" будет содержать реально принятое количество, в независимости от спецификации "Заказа поставщику", "Подтверждения заказа" и "Накладной поставщика". Т.е. в "Приходной накладной" будет зафиксировано реальное, а не бумажное количество.
Описание объектов.
| Тип объекта | Описание объекта | Название объекта в Торговой системе СуперМаг Плюс | Направление обмена | Схема объекта для Супермаг Плюс | Пример объекта в виде файла | Комментарий |
|---|---|---|---|---|---|---|
| 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 (при отсылке файла подтверждения при приеме с расхождением), то считается, что ответ о результате приемки провайдером принят успешно. |