Легенда:
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 - Документ УПД на приход предназначен для хранения данных о содержании УПД, полученного из системы электронного документооборота. Документ участвует в бизнес процессе приема маркированного товара и содержит согласованные обоими сторонами данные о составе поставки и перечне КИЗ поставленного товара. Документ служит основанием для выполнения регламентированных процедур электронного документооборота. | Схема, и соответственно пример файла, может быть изменены интегратором под свои персональные задачи. Возможность добавления новых полей, колонок, объектов и т.п. следует уточнять в службе технической поддержки компании разработчика. | |||