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