...
| Тип объекта | Описание объекта | Название объекта в Торговой системе СуперМаг Плюс | Направление обмена | Схема объекта для Супермаг Плюс | Пример объекта в виде файла | Комментарий |
|---|---|---|---|---|---|---|
| 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 (при отсылке файла подтверждения при приеме с расхождением), то считается, что ответ о результате приемки провайдером принят успешно. |