Для производителей и оптовиков. EDI при отгрузке товаров покупателям - серьёзным торговым сетям : КИС Lack & УС Land
25.11.2024 10:53
█ 16.02.2020 11:55
Хотите работать с большой тройкой: АО Тандер, юридические лица Х5, ООО Лента?
Минимальное требование для этого - полный документооборот с данными торговыми сетями по EDI! Минимальный комплект электронных документов в обороте:
order - заказ торговой точки покупателя, который вы принимаете и на его основе оформляется расходные операции в вашей УС;
ordrsp - подтверждение приёма заказа, отправляемое покупателя в случае, если вы готовы отгрузить конкретный заказ;
desadv - уведомление об отгрузке, отправляемое в "момент отправки" груза в торговую точку покупателя с указанием расхождений относительно заказа;
recadv - уведомление покупателя о приёмке груза с указанием фактически принятого товара;
УПД - юридически значимый электронный документ, формируемый на основе данных предыдущего обмена цепочкой "заказ - уведомление о приёме", отправляемый получателю.
Покупатель (получатель), ваше предприятие работают через своих поставщиков услуг по передаче электронных документов - провайдеров, но весь документооборот базируется на уникальных мировых идентификаторов, которые должны вестись в вашей учетной системе:
GLN - глобальный идентификатор юридического лица и/или торговой точки;
GTIN - глобальный код товара;
Идентификатор вашего провайдера и юридичсекого лица покупателя - 3х значный код провайдера.
В случае небольшого числа отгрузок (до 20 в сутки) вполне можно работать через Web интерфейс, предоставляемый каждым провайдером... и понятно, что у каждого провайдера он уникальный, а иначе вам придётся задуматься об автоматизированной системе электронного документооборота.
Автоматизированная система EDI - это очень дорогое "удовольствие" (из тех которые пришлось изучать у конкретных ЮЛ: от 1.5 до 8 млн. рублей), которая долго внедряется, если можно данный процесс когда-либо закончить (от 8 месяцев до 3 лет). У меня старт работ начался в июне 2019, а сейчас, с декабря 2019, продолжается лишь опытно-промышленная эксплуатация по всей цепочки документов EDI, с периодическими доработками под всплывающие нюансы и новые торговые сети со своими особенностями.
Однако стоимость АСУ ничтожна в сравнении с затратами на сам процесс обмена! Конечно всё зависит от умения договариваться, условий провайдера, количества торговых точек для отгрузки, но ориетировочно можно считать 3 руб. за документ, т.е. при небольшом объеме 10.000 отгрузок в год = от 100.000 в год... и наличие быстрого интернета и мощных рабочих компьютеров, грамотных пользователей, способных адекватно реагировать на постоянные проблемки.
... ну а дальше, если тема будет интересна, то она будет продолжена описанием конкретных деталей, нюансов торговых сетей и провайдеров ...
Минимальное требование для этого - полный документооборот с данными торговыми сетями по EDI! Минимальный комплект электронных документов в обороте:
order - заказ торговой точки покупателя, который вы принимаете и на его основе оформляется расходные операции в вашей УС;
ordrsp - подтверждение приёма заказа, отправляемое покупателя в случае, если вы готовы отгрузить конкретный заказ;
desadv - уведомление об отгрузке, отправляемое в "момент отправки" груза в торговую точку покупателя с указанием расхождений относительно заказа;
recadv - уведомление покупателя о приёмке груза с указанием фактически принятого товара;
УПД - юридически значимый электронный документ, формируемый на основе данных предыдущего обмена цепочкой "заказ - уведомление о приёме", отправляемый получателю.
Покупатель (получатель), ваше предприятие работают через своих поставщиков услуг по передаче электронных документов - провайдеров, но весь документооборот базируется на уникальных мировых идентификаторов, которые должны вестись в вашей учетной системе:
GLN - глобальный идентификатор юридического лица и/или торговой точки;
GTIN - глобальный код товара;
Идентификатор вашего провайдера и юридичсекого лица покупателя - 3х значный код провайдера.
В случае небольшого числа отгрузок (до 20 в сутки) вполне можно работать через Web интерфейс, предоставляемый каждым провайдером... и понятно, что у каждого провайдера он уникальный, а иначе вам придётся задуматься об автоматизированной системе электронного документооборота.
Автоматизированная система EDI - это очень дорогое "удовольствие" (из тех которые пришлось изучать у конкретных ЮЛ: от 1.5 до 8 млн. рублей), которая долго внедряется, если можно данный процесс когда-либо закончить (от 8 месяцев до 3 лет). У меня старт работ начался в июне 2019, а сейчас, с декабря 2019, продолжается лишь опытно-промышленная эксплуатация по всей цепочки документов EDI, с периодическими доработками под всплывающие нюансы и новые торговые сети со своими особенностями.
Однако стоимость АСУ ничтожна в сравнении с затратами на сам процесс обмена! Конечно всё зависит от умения договариваться, условий провайдера, количества торговых точек для отгрузки, но ориетировочно можно считать 3 руб. за документ, т.е. при небольшом объеме 10.000 отгрузок в год = от 100.000 в год... и наличие быстрого интернета и мощных рабочих компьютеров, грамотных пользователей, способных адекватно реагировать на постоянные проблемки.
... ну а дальше, если тема будет интересна, то она будет продолжена описанием конкретных деталей, нюансов торговых сетей и провайдеров ...
█ 24.02.2020 09:33
Пока очередная команда «одинэсников» пыталась решить задачу комплексной интеграции в EID в 2016 году объем заказов в виде XML файлов стал очень большим и мне была поставлена задача – хотя бы сделать закачку заказов в учетную системы, что бы операторам не было необходимости читать данный формат и переносить данные из него руками. К данному времени уже на «УСЕга» нацчился читать и разбирать данные файлы, т.ч. взялся за данную задачу и к марту 2016 она была в начальном виде сделана.
По любому Ваша программа интеграции должна будет заносить данные заказов (order) в учетную систему и данная программа должна уметь писать в базу данных учетной системы, т.е. данная часть системы интеграции жестко зависит от основной УС. Посему в данном сообщении ограничусь описанием алгоритмов и встречаемых нюансов.
Для создания заказов в УС нужно много меньше, чем для полной системы, по этому можно данное сообщение пропустить и вернуться к нему позже… Конечно форматы заказов от разных провайдеров различаются, однако у всех изучаемых необходимый набор тегов был идентичный, а используемый мной принцип потокового парсинга файла позволил «избежать» нюансов различия форматов. Для УС был необходим набор тегов – параметров заказа:
Далее сопоставляя с атрибутами учетной системы можно создавать «полные» расходные документы прописывая атрибуты непосредственно в БД УС.
Встречаемые нюансы:
- На начальном этапе у некоторых покупателях в заказах были перепутаны тэги поставщика и получателя. У меня в программе смотрю в каком теге есть наш GLN и тогда определяю атрибуты из соответсвующих тегах не обращая внимание на «стандарты»;
- Дата для отгрузки. Было всё и постоянно меняются «правила», а по этому параметр регулируется настройкой. Варианты:
А – неотрицательное число: текущая дата плюс указанное число дней.
Б – (-1) беру равное дате заказа.
В – (-2) беру равное дате доставки.
- У ряда покупателей PRODUCT не соответствует стандартизированному коду, используемому нами. В случае, когда его нет в нашей БД можно задать таблицу преобразования «кривых» кодов, по которой неверный код для юридического лица преобразуется к «правильному»
- Сети работаю по утвержденной «матрице», но зачастую мы больше не предлагаем товары, они выведены из «матрицы», а некоторые торговые точки продолжают присылать, выведенные из оборота GTIN. Есть настройка «отбраковки» кодов, когда программа приёма заказов их просто игнорирует, а не анализирует на «существование».
Нельзя от операторов требовать телепатических навыков, т.е. все этапы приемки заказов должны журналироваться с подробных описанием причин отказа во внесении заказа и способам исправления ошибки, а так же иметь легкий способ, после исправления его подробно принять. Документы «кидаются» в текущий каталог. У « меня» во всех подсистемах EDI принят подход: «отбракованные» заказы/операции сохраняются в подпапке err, а обработанные в ok, т.е. после исправления в УС заказ можно вернуть в рабочий каталог.
P.S. Есть и используются программы от 2011, 2012 года закачки заказов из электронных таблиц: (а), где по пачке магазинов заказы в одном файле (АО Тандер) и (б) каждый магазин делает заказ в отдельном файле. Программа имеют внешние средства настройки схемы «чтения» таких XLS(X) файлов. Так же есть программа автоматизированного внесения в УС возвратов от покупателей – desadv, сделанная в 2017 году, но сейчас, после запретов возвратов от сетей она не используются.
P.P.S. Позднее опишу уже «новую» универсальную комплексную систему документооборота по EDI, создаваемую мной в 2019-2020, которая уже не зависит от используемой учетной системы… и нюансы провайдеров, сетей, документооборота.
По любому Ваша программа интеграции должна будет заносить данные заказов (order) в учетную систему и данная программа должна уметь писать в базу данных учетной системы, т.е. данная часть системы интеграции жестко зависит от основной УС. Посему в данном сообщении ограничусь описанием алгоритмов и встречаемых нюансов.
Для создания заказов в УС нужно много меньше, чем для полной системы, по этому можно данное сообщение пропустить и вернуться к нему позже… Конечно форматы заказов от разных провайдеров различаются, однако у всех изучаемых необходимый набор тегов был идентичный, а используемый мной принцип потокового парсинга файла позволил «избежать» нюансов различия форматов. Для УС был необходим набор тегов – параметров заказа:
Код:
DOCUMENTNAME Вид документа NUMBER Номер заказа – важный везде атрибут и его, как и даты желательно сохранять в отдельных полях УС DATE Дата заказа DELIVERYDATE Дата доставки DELIVERYTIME Время доставки. Может отсутствовать. Для ООО Лента используется в уведомлениях об отгрузке. SUPPLIER Продавец – наше предприятие BUYER Покупатель - GLN клиента, юридического лица DELIVERYPLACE GLN адреса доставки POSITIONNUMBER Номер позиции – обязателен в отправляемых документах PRODUCT GTIN продукта ORDEREDQUANTITY Заказываемое количество ORDERPRICE Цена без НДС
Встречаемые нюансы:
- На начальном этапе у некоторых покупателях в заказах были перепутаны тэги поставщика и получателя. У меня в программе смотрю в каком теге есть наш GLN и тогда определяю атрибуты из соответсвующих тегах не обращая внимание на «стандарты»;
- Дата для отгрузки. Было всё и постоянно меняются «правила», а по этому параметр регулируется настройкой. Варианты:
А – неотрицательное число: текущая дата плюс указанное число дней.
Б – (-1) беру равное дате заказа.
В – (-2) беру равное дате доставки.
- У ряда покупателей PRODUCT не соответствует стандартизированному коду, используемому нами. В случае, когда его нет в нашей БД можно задать таблицу преобразования «кривых» кодов, по которой неверный код для юридического лица преобразуется к «правильному»
- Сети работаю по утвержденной «матрице», но зачастую мы больше не предлагаем товары, они выведены из «матрицы», а некоторые торговые точки продолжают присылать, выведенные из оборота GTIN. Есть настройка «отбраковки» кодов, когда программа приёма заказов их просто игнорирует, а не анализирует на «существование».
Нельзя от операторов требовать телепатических навыков, т.е. все этапы приемки заказов должны журналироваться с подробных описанием причин отказа во внесении заказа и способам исправления ошибки, а так же иметь легкий способ, после исправления его подробно принять. Документы «кидаются» в текущий каталог. У « меня» во всех подсистемах EDI принят подход: «отбракованные» заказы/операции сохраняются в подпапке err, а обработанные в ok, т.е. после исправления в УС заказ можно вернуть в рабочий каталог.
P.S. Есть и используются программы от 2011, 2012 года закачки заказов из электронных таблиц: (а), где по пачке магазинов заказы в одном файле (АО Тандер) и (б) каждый магазин делает заказ в отдельном файле. Программа имеют внешние средства настройки схемы «чтения» таких XLS(X) файлов. Так же есть программа автоматизированного внесения в УС возвратов от покупателей – desadv, сделанная в 2017 году, но сейчас, после запретов возвратов от сетей она не используются.
P.P.S. Позднее опишу уже «новую» универсальную комплексную систему документооборота по EDI, создаваемую мной в 2019-2020, которая уже не зависит от используемой учетной системы… и нюансы провайдеров, сетей, документооборота.
█ 01.04.2020 10:10
У всех провайдеров разные требования и рекомендации к процедуре обмена! Так получилось, что пришлось «подстраиваться» под все и программа интеграции работает так – если есть доступ к нужному каталогу ftp сервера, то программа «просто» переносит из него / в него файлы локального каталога, а на следующих этапах читает или пишет только в локальные папки, т.е. эти процессы независимы:
1. Обмен осуществляется программами провайдера;
2. Обмен возможен любой программой, удовлетворяющей набору требований;
3. Желательно, что бы процесс обмена делался из программы интеграции.
Кроме того у разных провайдеров разные процедуры «манипуляции» с ХМЛ файлами их сервера, например у кого-то считываемые файлы папки inbox, а имена папок у всех разные, что «регулируются» настройками, необходимо перенести в архивный каталог archive, а затем удалить из inbox. Программа эти требования обрабатывает, анализируя наличие или отсутствие к папкам сервера разного назначения.
В результате опыта и многочисленных переделок программы интеграции определился список обязательных атрибутов сохраняемых программой интеграции в своей БД, которые необходимы для своих учетных систем или для формирования файлов обмена. Многие из атрибутов «необязательные», но требуемые некоторыми сетями. В описаниях правил обмена у разных провайдеров имена тегов и требования по ним могут различаться, что в программе интеграции регулируется настройкой «под провайдера». В «стандартах» провайдеров их сотни, но реально используются мной и достаточно для отгрузки не маркируемых товаров. Опишу их:
Обязательно сохраняю из заказов orders, но не все нужны для УС, а требуются при создании исходящих документов. Ниже дано описание атрибутов, разбитых по блокам с минимальными требованиями по их форматам:
Атрибуты подтверждения заказа ordrsp, выгружаемые из учетной системы обязательно сохраняю в БД, т.к. они нужны будут для всех последующих исходящих документов. Трактовка данных атрибутов незначительно различается у разных провайдеров:
У «меня» номер, дата, количество, цена в подтверждении заказа, уведомления об отгрузке desadv, которое посылается сразу после подтверждения заказа и в УПД совпадают, а по этому атрибуты «подтверждения» беру и для «уведомления». Далее обрабатываю входящие recadv - уведомление покупателя о приёмке груза с указанием фактически принятого товара, которые нужны для контроля фактически принятого товара в УС и формирования УПД. Сохраняю информацию в БД программы интеграции:
Наконец, по данным из УС, выгруженным в программу интеграции, данным предыдущим документам проведения заказов формируется УПД по жестким требованиям ФНС, описанным в отдельной инструкции, идентичным для всех провайдеров. Однако число, порядок и набор «дополнительных» атрибутов УПД существенно различается для разных сетей, но все необходимое есть в УС и БД программы интеграции. Заполняется единственный атрибут:
На настоящий момент, отчасти в силу дороговизны программа интеграции не формирует электронную подпись для УПД, а по технологиям всех провайдеров такие УПД попадают в «черновики» на платформе, где их «пачкой» можно сразу подписать и отправить, тем более, что по срокам и порядке отправки УПД требования у всех торговых сетей разные.
1. Обмен осуществляется программами провайдера;
2. Обмен возможен любой программой, удовлетворяющей набору требований;
3. Желательно, что бы процесс обмена делался из программы интеграции.
Кроме того у разных провайдеров разные процедуры «манипуляции» с ХМЛ файлами их сервера, например у кого-то считываемые файлы папки inbox, а имена папок у всех разные, что «регулируются» настройками, необходимо перенести в архивный каталог archive, а затем удалить из inbox. Программа эти требования обрабатывает, анализируя наличие или отсутствие к папкам сервера разного назначения.
В результате опыта и многочисленных переделок программы интеграции определился список обязательных атрибутов сохраняемых программой интеграции в своей БД, которые необходимы для своих учетных систем или для формирования файлов обмена. Многие из атрибутов «необязательные», но требуемые некоторыми сетями. В описаниях правил обмена у разных провайдеров имена тегов и требования по ним могут различаться, что в программе интеграции регулируется настройкой «под провайдера». В «стандартах» провайдеров их сотни, но реально используются мной и достаточно для отгрузки не маркируемых товаров. Опишу их:
Обязательно сохраняю из заказов orders, но не все нужны для УС, а требуются при создании исходящих документов. Ниже дано описание атрибутов, разбитых по блокам с минимальными требованиями по их форматам:
Код:
o_numb C 35 Номер заказа по EDI - уникальный идентификатор o_dat D Дата заказа по EDI. Ключ o_devid D Дата поставки по заказу. Нужна всегда o_devti C 8 Время поставки по заказу. Обязательно Лента. o_buyer C 13 GLN КА. Покупателя o_place C 13 GLN АДРЕСА ДОСТАВКИ. Ключ o_gtin C 14 GTIN. Может быть 8,10,13,14 знаков qtyOld N 7 Номер позиции в заказе. Ключ второго индекса o_qty N12,3 Количество по заказу. Возможна резка и удаление позиции o_sales N10,2 Цена в заказе с НДС o_id C 16 Внутренний номер позиции у покупателя. Нужно для подтверждения o_unit C 3 Код единицы измерения o_lessnds N10,2 Цена в заказе без НДС. Для ТС обязательный атрибут o_desc C 70 Наименование товара у покупателя o_nds N2 Ставка НДС
Код:
p_numb C 19 Номер подтверждения в УС p_dat D Дата подтверждения p_sales N10,2 Цена с НДС в моих документах p_tip C 1 Кол-во 1-по заказу, 2-изменено кол-во, 3-отказ в поставке qtyPak N12,3 Фасовка товара. Нужно для уведомления отгрузки Лента codMin C4 Мой системный код номенклатуры p_qty N12,3 Поставляемое количество p_send L Признак выгрузки подтверждения в EDI
Код:
i_inp L Признак, что подтверждение отгрузки обработано по всем записям i_qty N12,3 Подтвержденное покупателем количество i_numb C 16 Номер подтверждения от покупателя i_dat D Дата подтверждения i_enddat D Дата фактической приемки товара. Для разборок в будущем
Код:
u_send L Признак отсылки УПД на FTP провайдера
█ 05.05.2020 08:45
Уф 
наконец нашел "где собака зарыта"... и это дало повод для сообщения 
Одними из серьёзных проблем промышленной эксплуатации системы EDI является - покупатели косячат, "они большие - им всё можно", а страдают поставщики... ну и разработчик, на которого все валят
Приведу ряд примеров:
1. Самый свежий. На новый товар матрицы покупателям дают новый GTIN, который внесен в "мировой реестр" и базы провайдеров, но по какой-то причине покупатель в своей БД вводит некий другой, а то и липовый GTIN и по нему начинает присылать заказы. Проблема старая - имеется таблица преобразования кривых GTIN, через которую проходят заказы и в обратную сторону преобразуются GTIN в исходящих документах...
Оказывается, без предупреждения, через 7 месяцев покупатель у себя в БД может проставить правильный GTIN, что сейчас наложилось с новым товаром и новым косяком по GTIN… При этом таблица преобразования для него "отключалась" при приеме заказа, но проходило неверное обратное преобразование. Структура таблицы со свежими комментариями для операторов:
2. Версия 14.02.2020г. При переходе на новый формат УПД, требования к форматам УПД у **** резко стали отличаться от остальных ТС. Сделана отдельная ветка построения файлов УПД для ****ы на основе образца УПД, создаваемого на платформе *****.
3. Версия 05.03.2020г. Подстройка нюансов, выявленных при реальной эксплуатации - от отдельных магазинов приходили "глупые" количества, по ним разбирались с менеджерами, исправляли, но часть исходящих документов уже отправлялось в EDI:
«Неверная» выгрузка фактического количество заказа в УПД. Раньше программа брала количество из «подтверждения заказа», а если оно не отсылалось, то фактическое количество из предзаказа. Что порождало «непонятки»: приняли заказ, отправили подтверждение, изменили количество, отправили УПД, а в УПД выгрузилось не измененное количество.
Сейчас. Программа в УПД всегда передаёт количество из предзаказа, но если подтвержденное количество не равно этому, то выдаётся сообщение об ошибке в логах по УПД в каталоге log.
Довольно большой процент УПД бракуется покупателем, если для него назначены «некорректные» цены, а он ведёт учет от «цены без НДС», например ему отгружают по 46.95, а он, округляя до 2 знаков учет ведёт от 39.13 (цена без НДС).
Сейчас. В настройке программы можно задавать точность расчетов и отражения цен в УПД. Кроме того все «суммы», на всех этапах отражения подгоняются под точное соответствие: Цена/сумма без НДС + НДС = Цене/сумме с НДС с точностью указанной в настойке программы.
Например, для «нашей» цены с НДС = 46.95 и точностью в настройке 4 знака и количеству 3 единицы будет: Цена без НДС = 39.1250, НДС = 7.8250, цена с НДС = 46.9500 Сумма без НДС = 117.3750, НДС = 23.4750, сумма с НДС = 140.8500
Перевыгрузка документов в EDI. При ошибочной выгрузке документов любого типа – подтверждение, уведомление об отгрузке, УПД программа не даёт повторно выгрузить документы в EDI. Сейчас это можно исправить – в новом режиме «Предзаказы / группы / Выгрузка заказов в EDI - чистить признак отсылки». Программа создаёт файлы DLT*.DLT, которые обрабатываются программой и по заказам из него удаляются все атрибуты «отсылки» всех видов документов. После обработки можно заново выгрузить, НО ВСЕ ВИДЫ документов, т.к., например, для выгрузки УПД нужно выгруженное подтверждение заказа.
4. Версия 26.03.2020г. По вопросам *****, только для **** должна быть точность в УПД обязательно равная 2 знакам, а для любых других ТС она определяется в настройке программы. Это актуально для Х5, где цены ведутся без НДС. Для **** настройка всегда назначается 2 знака.
5. Версия 21.04.2020г. Цены в УПД берутся из заказов учетной системы, а не заказов покупателей. В случае их расхождения даётся сообщение в фале логов. Косяки покупателей при проведении акций...
наконец нашел "где собака зарыта"... и это дало повод для сообщения Одними из серьёзных проблем промышленной эксплуатации системы EDI является - покупатели косячат, "они большие - им всё можно", а страдают поставщики... ну и разработчик, на которого все валят
Приведу ряд примеров:1. Самый свежий. На новый товар матрицы покупателям дают новый GTIN, который внесен в "мировой реестр" и базы провайдеров, но по какой-то причине покупатель в своей БД вводит некий другой, а то и липовый GTIN и по нему начинает присылать заказы. Проблема старая - имеется таблица преобразования кривых GTIN, через которую проходят заказы и в обратную сторону преобразуются GTIN в исходящих документах...
Оказывается, без предупреждения, через 7 месяцев покупатель у себя в БД может проставить правильный GTIN, что сейчас наложилось с новым товаром и новым косяком по GTIN… При этом таблица преобразования для него "отключалась" при приеме заказа, но проходило неверное обратное преобразование. Структура таблицы со свежими комментариями для операторов:
Цитата:
Другие примеры, где приходилось править программу интеграции - выдержки из интструкции: Схема для преобразования кривых GTIN у клиентов. Через запятую в отдельных строках отражаются GLN клиента/GTIN у него/GTIN по БД LeraData. Нет 3 запятых - строка игнор
05.05.2020... Если хотя бы для одной строке по gln будет gtin2 из УС (БД LeraData), то бракуется вся таблица при загрузке из Lera и будет обратное неверное преобразование при выгрузке в программе Lera_edi
Первая строка - по ней стали использовать правильный
460******9995-4607124662150-4607124662228
Новая "кривая" у покупателя позиция
460*******995,4607124662181,4607124662020
****ер, а этот так и не исправил в течении 2 лет - у них другой товар под этим кодом
46*********95,4607124662181,4607124662020
В отдельных строках может рсполагаться любой мусор. астройка только для заказов zLeraOrd, а не возвратов.
05.05.2020... Если хотя бы для одной строке по gln будет gtin2 из УС (БД LeraData), то бракуется вся таблица при загрузке из Lera и будет обратное неверное преобразование при выгрузке в программе Lera_edi
Первая строка - по ней стали использовать правильный
460******9995-4607124662150-4607124662228
Новая "кривая" у покупателя позиция
460*******995,4607124662181,4607124662020
****ер, а этот так и не исправил в течении 2 лет - у них другой товар под этим кодом
46*********95,4607124662181,4607124662020
В отдельных строках может рсполагаться любой мусор. астройка только для заказов zLeraOrd, а не возвратов.
2. Версия 14.02.2020г. При переходе на новый формат УПД, требования к форматам УПД у **** резко стали отличаться от остальных ТС. Сделана отдельная ветка построения файлов УПД для ****ы на основе образца УПД, создаваемого на платформе *****.
3. Версия 05.03.2020г. Подстройка нюансов, выявленных при реальной эксплуатации - от отдельных магазинов приходили "глупые" количества, по ним разбирались с менеджерами, исправляли, но часть исходящих документов уже отправлялось в EDI:
«Неверная» выгрузка фактического количество заказа в УПД. Раньше программа брала количество из «подтверждения заказа», а если оно не отсылалось, то фактическое количество из предзаказа. Что порождало «непонятки»: приняли заказ, отправили подтверждение, изменили количество, отправили УПД, а в УПД выгрузилось не измененное количество.
Сейчас. Программа в УПД всегда передаёт количество из предзаказа, но если подтвержденное количество не равно этому, то выдаётся сообщение об ошибке в логах по УПД в каталоге log.
Довольно большой процент УПД бракуется покупателем, если для него назначены «некорректные» цены, а он ведёт учет от «цены без НДС», например ему отгружают по 46.95, а он, округляя до 2 знаков учет ведёт от 39.13 (цена без НДС).
Сейчас. В настройке программы можно задавать точность расчетов и отражения цен в УПД. Кроме того все «суммы», на всех этапах отражения подгоняются под точное соответствие: Цена/сумма без НДС + НДС = Цене/сумме с НДС с точностью указанной в настойке программы.
Например, для «нашей» цены с НДС = 46.95 и точностью в настройке 4 знака и количеству 3 единицы будет: Цена без НДС = 39.1250, НДС = 7.8250, цена с НДС = 46.9500 Сумма без НДС = 117.3750, НДС = 23.4750, сумма с НДС = 140.8500
Перевыгрузка документов в EDI. При ошибочной выгрузке документов любого типа – подтверждение, уведомление об отгрузке, УПД программа не даёт повторно выгрузить документы в EDI. Сейчас это можно исправить – в новом режиме «Предзаказы / группы / Выгрузка заказов в EDI - чистить признак отсылки». Программа создаёт файлы DLT*.DLT, которые обрабатываются программой и по заказам из него удаляются все атрибуты «отсылки» всех видов документов. После обработки можно заново выгрузить, НО ВСЕ ВИДЫ документов, т.к., например, для выгрузки УПД нужно выгруженное подтверждение заказа.
4. Версия 26.03.2020г. По вопросам *****, только для **** должна быть точность в УПД обязательно равная 2 знакам, а для любых других ТС она определяется в настройке программы. Это актуально для Х5, где цены ведутся без НДС. Для **** настройка всегда назначается 2 знака.
5. Версия 21.04.2020г. Цены в УПД берутся из заказов учетной системы, а не заказов покупателей. В случае их расхождения даётся сообщение в фале логов. Косяки покупателей при проведении акций...
█ 28.07.2020 10:09
Создание программ интеграции с EDI, как впрочем любого приложения для бизнеса – это процесс не имеющий даты завершения. Начиная автоматизацию нужно это помнить и смириться с потерями времени и денег, в том числе на оплату ненужной работы. Как пример приведу «процесс» решения одной из множества «дополнительных» небольших задач в рамках интеграции с EDI в течении времени и комментариями. «Главным» является провайдер, т.к. только он владеет своими алгоритмами взаимодействия с клиентами. Приведу почтовую переписку.
Цитата:
4 февраля, 10:56 … Однако накопилось несколько непонятных проблем, которые необходимо разрешить:
2. Очень много УПД, в большинстве Х5, в том числе делаемые в Web бракуются получателем по несостыковки по суммам без НДС и НДС… Исходная причина понятна - округление при расчете сумм, например цена с НДС - 10.0руб, НДС - 1.66666666, без НДС - 8.333333 при округление до 1.67/8.33 могут давать расхождение с другими алгоритмами расчетов. От сюда вопросы/просьбы:
а. Может быть можно в УПД цены и суммы задавать не с 2, а большей точностью, например 43.98754, если да, то с какой
б. Почти все УПД с Web принимаются получателем без ошибок. Можете дать алгоритм подгона цен/сумм для начала по Х5?
2. Очень много УПД, в большинстве Х5, в том числе делаемые в Web бракуются получателем по несостыковки по суммам без НДС и НДС… Исходная причина понятна - округление при расчете сумм, например цена с НДС - 10.0руб, НДС - 1.66666666, без НДС - 8.333333 при округление до 1.67/8.33 могут давать расхождение с другими алгоритмами расчетов. От сюда вопросы/просьбы:
а. Может быть можно в УПД цены и суммы задавать не с 2, а большей точностью, например 43.98754, если да, то с какой
б. Почти все УПД с Web принимаются получателем без ошибок. Можете дать алгоритм подгона цен/сумм для начала по Х5?
Цитата:
5 февраля, 12:55 По второму вопросу, Вы можете добавить необходимое количество знаков после запятой, но сделать это нужно будет как в цене так и в суммах. Связано это действительно с округлением. Торговая сеть Х5 работает по прямому методу расчета. Можно так же проверить в 1с какой метод расчета стоит и дальше отталкиваясь от метода добавлять необходимое количество цифр.
Цитата:
5 февраля, 13:31 б. С округлениями и дробной частью понятно и это снимет 90% проблем — спасибо! Однако по методам расчетов — у нас нет «1С», а даже если бы и была — это «внутренние алгоритмы»… В то же время «платформа», как-то подгоняет «цифры» под требования Х5 и вам эти алгоритмы известны. Прошу дать вашу методику для подгон цен и сумм для торговой сети Х5?
Цитата:
Необходимо было решать более срочные задачи EDI, а посему по округлениям притормозил: 5 февраля, 14:45 По поводу методики. Методики как таковой нет. Все зависит только от метода расчета и округления.
Цитата:
Уже потребовалось несколько звонков в техподдержку и менеджеру, что бы дали ответ… 6 марта, 9:53 Переделал программу интеграции под ваше допущение «Вы можете добавить необходимое количество знаков после запятой, но сделать это нужно будет как в цене так и в суммах»… При попытке отправить УПД с 4 знаками в ценах и суммах оно перешло в папку error — приложен файл, откатил программу и отправил, как раньше с 2 знаками — УПД попало на платформу… Почему?
1. Ваша рекомендация ошибочна? Тогда — как выкручиваться с проблемами округления? Всё таки дайте алгоритмы подгона цен и сумм для сетей
2. У «меня» в УПД есть какие-то другие ошибки… и по этому файл был забракован?
1. Ваша рекомендация ошибочна? Тогда — как выкручиваться с проблемами округления? Всё таки дайте алгоритмы подгона цен и сумм для сетей
2. У «меня» в УПД есть какие-то другие ошибки… и по этому файл был забракован?
Цитата:
13 марта, 16:31 Согласно требованиям торговой сети Лента от 01.08.2019г, цена в УПД нового формата принимается на их стороне, только с двумя знаками после запятой. Цена товара [ЦенаТов] Если один товар присутствует в нескольких позициях УПД, проверяется, что все эти позиции имеют одинаковую цену. Цены должны округляться до целой копейки (не допускается дробное количество копеек). Цены проверяются на соответствие заказу на поставку. По товарам из соответствующих категорий (алкоголь, табак) выполняется проверка на соответствие цены и МЗЦ, МРЦ.
Цитата:
Опять пинание ТП и менеджера.. 13 марта, 18:21 Добрый вечер! Только сегодня увидел ваш ответ, т.к. вы его отослали не адресату вопроса. Позвольте уточнить? Требование округления только до копейки относится ко ВСЕМ торговым сетям, с которыми работает … или только к ООО Лента
Цитата:
Очередная пауза – уже из-за меня… Море других задач, а описываемая была неактуальной. Кроме того серьёзно изменил алгоритмы настройки цен 17 марта, 17:08 Данное требование относится только к ТС ООО "Лента"
Цитата:
После очередного цикла пинания – задача снова стала весьма актуальной 14 июня, 10:29 Добрый день уважаемые специалисты!
Вынужден возвратиться к «старому» вопросу суть, которого в переписке ниже — возможность задания точности цен и сумм в УПД. В начале вас спросил — вы ответили, что допустима любая точность, но она должна быть единой для цен и сумм… Сделал в настройке задание точности от 0 до 9 знаков. Приведу пример «отказанного» УПД:
Затем отправили УПД с точностью 4 знака и для ООО Лента УПД было забраковано, т.к. «неправильный значения». Отправил вам вопрос и вы ответили (см. ниже), что ТОЛЬКО для Ленты нужна точность 2 знака, а для других «произвольная»…. Опять переделал программу.
При попытке отправить УПД для Ленты 2 знака, для остальных 4 знака. ООО Лента прошла, а по Тандеру снова пришел отказ по точности… на чём временно были прекращены попытки решить с вами эту проблему
Проблема осталась! Ответьте пожалуйста чётко и определенно, как могу работать с точностью в УПД для различных контрагентов?
Вынужден возвратиться к «старому» вопросу суть, которого в переписке ниже — возможность задания точности цен и сумм в УПД. В начале вас спросил — вы ответили, что допустима любая точность, но она должна быть единой для цен и сумм… Сделал в настройке задание точности от 0 до 9 знаков. Приведу пример «отказанного» УПД:
Затем отправили УПД с точностью 4 знака и для ООО Лента УПД было забраковано, т.к. «неправильный значения». Отправил вам вопрос и вы ответили (см. ниже), что ТОЛЬКО для Ленты нужна точность 2 знака, а для других «произвольная»…. Опять переделал программу.
При попытке отправить УПД для Ленты 2 знака, для остальных 4 знака. ООО Лента прошла, а по Тандеру снова пришел отказ по точности… на чём временно были прекращены попытки решить с вами эту проблему
Проблема осталась! Ответьте пожалуйста чётко и определенно, как могу работать с точностью в УПД для различных контрагентов?
Цитата:
Очередная переделка программы. На этот раз сделал настройку точности для каждой сети. За проект мне оплатили… и такие косяки уже стали вызывать раздражение заказчика, чем и связано моё раздражение… В принципе уже давно просил дать официальный ответ, что возможна лишь точность 2 знака, что бы «отвязаться» от этой проблемы и «народ» ставил «правильные» цены через программу: https://olegon.ru/showpost.php?p=346316&postcount=33 Послал письмо только менеджеру, что бы «не обидеть» «тонкую душу» специалистов: 22 июня, 10:30 ТС X5 Retail Group и ГУЛЛИВЕР работают по прямому методу расчета и допустимо 4 знака после запятой. ТС МАГНИТ, Лента и Тамерлан работают по обратному методу расчета и допустимо 2 знака после запятой.
прямой метод:
Цена без НДС х Кол-во х ставку НДС = сумма с НДС Пример: 500 x 2 x 0,2 = 1200 - сумма с НДС
обратный метод: 1. Cумма с НДС\(1+ставка НДС) = сумма без НДС
2. Сумма без НДС х ставка НДС = Сумма НДС
Пример: 1. 1000 \ 1,2 = 833,33 - сумма без НДС
2. 833,33 х 0,2 - 166,67 - Сумма НДС. Данная информация есть в общедоступных источниках.
прямой метод:
Цена без НДС х Кол-во х ставку НДС = сумма с НДС Пример: 500 x 2 x 0,2 = 1200 - сумма с НДС
обратный метод: 1. Cумма с НДС\(1+ставка НДС) = сумма без НДС
2. Сумма без НДС х ставка НДС = Сумма НДС
Пример: 1. 1000 \ 1,2 = 833,33 - сумма без НДС
2. 833,33 х 0,2 - 166,67 - Сумма НДС. Данная информация есть в общедоступных источниках.
Цитата:
3 июля, 12:17 Что специалисты плохо разбираются или я чего-то не понимаю? Цитата из ответа «ТС X5 Retail Group и ГУЛЛИВЕР работают по прямому методу расчета и допустимо 4 знака после запятой». В очередной раз переделал программу и опять отказ по точности. Сделав 2 знака приложенные документы ушли. Прикладываю файлы из каталога error
Цитата:
Типа «пошел на…» - пришлось снова долбить менеджера, что бы дали однозначный ответ 6 июля, 13:44 Данные предоставленные Вам в соответствии с спецификацией торговых сетей.
Цитата:
После прямого обращения к руководителю отдела разработки провайдера от лично его пришел ответ «закрывающий» тему, но времени потеряно почти в пустую очень много 6 июля, 14:42 Изумительный и конкретный ответ на вопрос =) Вам приложил файлы (УПД для Х5) из папки error сервера LeraData, т.е. забракованные платформой по некой причине, надеясь на совет — что у меня неверно, а Вы ссылаетесь на некую «закрытую» для меня спецификацию ТС. Будьте добры дать ответ о причине отправки файлов в error?
Цитата:
8 июля, 20:29 Прошу прошения за изначально не верно отправленную Вам информацию. Выяснили, что обновилась спецификация, нас к сожалению разработчики не предупредили, но мы рады что у вам удалось самостоятельно доработать документы. Верное количество знаков после запятой для основных ТС (х5, Лента, Гулливер, Магнит) до 2х. Цены должны округляться до целой копейки (не допускается дробное количество копеек). Доработку Вы выполнили верную, сейчас Ваши документы обрабатываются корректно.
█ 11.10.2020 17:48
Новая задача. C 01.10 разбирался в ценах за "документооборот" в плане подключения ещё 800 магазинов, обсуждения с бухгалтерией и владельцем бизнеса. 5/6.10 "бесконечные" рекламные звонки провайдеров. 07.10 обсуждение вариантов и аргументированной принятие решения - более стабильный траффик и как минимум 300тыр годовой экономии... и "подписался" на перевод системы интеграции на другого провайдера по жестокому календарному плану... 8/9.10 завалили технической документацией. Часть субботы (на даче тоже надо закончить) и сегодня изучал документацию и заложенные в программу средства адаптации схем XML и настроек на провайдера - всё хорошо! Задача решаемая в заданные сроки и этапы до 01.12 => исчезаю для выполнения контракта.
█ 12.10.2020 09:28
Андрей, а не рассматривали вариант использования эдо только для обмена юридически значимыми документами (упд, например)?
У нас, в частности, есть своя встроенная система электронных заказов "из коробки", которая развивается около 7 лет и работает очень стабильно, с минимальными затратами на техническую поддержку. При этом не создает для пользователей учетной системы какой-либо дополнительной нагрузки.
Поскольку в ЭДО надо платить за каждый документ, насколько я знаю, и бизнес-процессы часто не предполагают примитивную схему заказ-отгрузка.
У нас, в частности, есть своя встроенная система электронных заказов "из коробки", которая развивается около 7 лет и работает очень стабильно, с минимальными затратами на техническую поддержку. При этом не создает для пользователей учетной системы какой-либо дополнительной нагрузки.
Поскольку в ЭДО надо платить за каждый документ, насколько я знаю, и бизнес-процессы часто не предполагают примитивную схему заказ-отгрузка.
█ 12.10.2020 09:50
Вообще описываемое - заказной проект создаваемый, как отдельное приложение, которое при желании можно пристегнуть к любой учетной системе. Делается максимально гибко относительно провайдеров и внешних учеток...
- Знания, опыт, наработки "УС Лэнд:ЕГАИС" позволили мне создать данный проект, что и является наибольшей ценностью, в том числе финансововой, для меня в проекте "УСЕга"
- Знания, опыт, наработки данного проекта, в частности, где есть обмен УПД надеюсь будет являться ценностью для следующего ожидаемого платного проекта "маркировка молочной продукции" для оптовок...
Цитата:
Скажу по секрету: FinSoft ➤ Андрей, а не рассматривали вариант использования эдо только для обмена юридически значимыми документами (упд, например)?
- Знания, опыт, наработки "УС Лэнд:ЕГАИС" позволили мне создать данный проект, что и является наибольшей ценностью, в том числе финансововой, для меня в проекте "УСЕга"
- Знания, опыт, наработки данного проекта, в частности, где есть обмен УПД надеюсь будет являться ценностью для следующего ожидаемого платного проекта "маркировка молочной продукции" для оптовок...
█ 03.11.2020 15:27
Цитата:
В режиме активного взаимодействия со специалистами нового провайдера была доработана, сделана более универсальная относительно провайдера программа интеграции, со стороны провайдера так же сделаны доработки в плане преобразования входящих документов, проведены все тестовые цепочки по всем обслуживаемых торговым сетям. AndreyZh ➤ Задача решаемая в заданные сроки и этапы до 01.12 => исчезаю для выполнения контракта.
Однако учитывая мою осторожность решили на некотором этапе перевести лишь пару сетей на них, т.е. одновременно будут работать две программы интеграции. Новую установлю, настрою на днях и обучу "жонглированию" с ними бухгалтеров и операторов. Инструкцию не знал, как дописать, т.к. всё внешне осталось без изменения, но решил сделать "детский рисунок", что бы дамы понимали происходящее, а понимая, думаю с технической работой они справятся.
Суть: каждая программа (копия всего в отдельной папке с особыми настройками) ловит со своих серверов документы "своих" сетей. Единственная "заморочка" - исходящие документы отправляются раздельно и при этом должна быть запущена своя программа интеграции. Надеюсь временный период на долго не затянется?
█ 09.12.2020 16:17
Бедная моя головушка предновогодний "жор" встретился с этапом опытно-промышленной эксплуатации на новом провайдере и этот "микс" выявил несколько новых "нюансов", которые в спешном порядке приходится "допиливать". Сказанное ниже думаю будет полезно разработчикам при проектировании своих систем дабы избежать моих "граблей":
1.У старого провайдера был тормозной FTP и его платформа забирала документы из сервера раз в 10 минут пачками по 50 документов и техника программы (выгрузить весь блок доков одного типа, а затем проверить их размещение на FTP) успешно работала. Выявилось, что у нового документы на FTP размещаются без задержек и забираются платформой все раз в 1 минуту, т.е. пока я неспешно помещаю «последние» на FTP «первые» доки уже платформа забрала и методика «проверки» показывает, что документы на FTP не разместились… и начинается повторный цикл отсылки… и так до «бесконечности».
Пришлось придумывать новую технологию. Сейчас: все документы под отсылку разбиваю на пачки по 3 документа, отсылаю пачку без «технологических задержек», а затем проверяю её на прохождение, т.е. всё вписывается в «минуту». При успехе отправляю-проверяю следующую пачку… и так до исчерпания списка документов. Три дня уже работает без проблем
2.На всех «еды не хватает» и части магазинов делается полный отказ. В подтверждении заказов «логично» сделал перечисление всех товаров с отказом всего количества, но что делать с «уведомлениями» и УПД? В мануалах четко сказано – создавать данные документы и передаваемое количество должно быть положительным… путаница – однако. Запросил провайдера – пока их ТП «зависла» с ответом
3. У старого провайдера во всех документах был необязательный тэг «ставка НДС», обязательный для торговых сетей, т.е. он всегда сохранялся и обрабатывался при расчетах цен. У нового этот тэг необязателен и ряд сетей присылают заказы без него, указывая только или цены без НДС, или цены с НДС… и вся «опора» на данные ТС «полетела». Программа интеграции не работает с БД УС, а посему ей в принципе не известны ставки НДС… У единственного пользователя данной программы весь товар по 20% - сделал «тупую» затычку, что если нет тега НДС, то прога подставляет 20%
P.S. Великие и могучие торговые сети . Процесс смены провайдера выглядит – посылаем письмо по каждой сети о смене провайдера, а далее он «сам» занимается… В принципе, что-то похожее и происходит, но сети на прямую нам шлют письма о готовности и дополнительных требованиях. Выделился «лидер» - первый прислал объявление о готовности и о том, что новый провайдер их основной и проблем не будет… и пропал… После кучи звонков и писем выяснилось, что «план» перехода в течении 10 дней изучался и визировался его департаментами, но все же «спустился» к техническому отделу, который «обещает» «настроить» обмен в течении 2 недель
P.P.S Другая мегасеть озадачила, что в это время (с 26.11) они переходят на другой формат УПД (СчФДОП), прислав многостраничные инструкции и кучу «пужалок», а с 1.12 «задолбали» ежедневными правками по оформлению уникальных тегов… При этом по факту не принимая вообще УПД в данном формате
предновогодний "жор" встретился с этапом опытно-промышленной эксплуатации на новом провайдере и этот "микс" выявил несколько новых "нюансов", которые в спешном порядке приходится "допиливать". Сказанное ниже думаю будет полезно разработчикам при проектировании своих систем дабы избежать моих "граблей":1.У старого провайдера был тормозной FTP и его платформа забирала документы из сервера раз в 10 минут пачками по 50 документов и техника программы (выгрузить весь блок доков одного типа, а затем проверить их размещение на FTP) успешно работала. Выявилось, что у нового документы на FTP размещаются без задержек и забираются платформой все раз в 1 минуту, т.е. пока я неспешно помещаю «последние» на FTP «первые» доки уже платформа забрала и методика «проверки» показывает, что документы на FTP не разместились… и начинается повторный цикл отсылки… и так до «бесконечности».
Пришлось придумывать новую технологию. Сейчас: все документы под отсылку разбиваю на пачки по 3 документа, отсылаю пачку без «технологических задержек», а затем проверяю её на прохождение, т.е. всё вписывается в «минуту». При успехе отправляю-проверяю следующую пачку… и так до исчерпания списка документов. Три дня уже работает без проблем
2.На всех «еды не хватает» и части магазинов делается полный отказ. В подтверждении заказов «логично» сделал перечисление всех товаров с отказом всего количества, но что делать с «уведомлениями» и УПД? В мануалах четко сказано – создавать данные документы и передаваемое количество должно быть положительным… путаница – однако. Запросил провайдера – пока их ТП «зависла» с ответом
3. У старого провайдера во всех документах был необязательный тэг «ставка НДС», обязательный для торговых сетей, т.е. он всегда сохранялся и обрабатывался при расчетах цен. У нового этот тэг необязателен и ряд сетей присылают заказы без него, указывая только или цены без НДС, или цены с НДС… и вся «опора» на данные ТС «полетела». Программа интеграции не работает с БД УС, а посему ей в принципе не известны ставки НДС… У единственного пользователя данной программы весь товар по 20% - сделал «тупую» затычку, что если нет тега НДС, то прога подставляет 20%
P.S. Великие и могучие торговые сети . Процесс смены провайдера выглядит – посылаем письмо по каждой сети о смене провайдера, а далее он «сам» занимается… В принципе, что-то похожее и происходит, но сети на прямую нам шлют письма о готовности и дополнительных требованиях. Выделился «лидер» - первый прислал объявление о готовности и о том, что новый провайдер их основной и проблем не будет… и пропал… После кучи звонков и писем выяснилось, что «план» перехода в течении 10 дней изучался и визировался его департаментами, но все же «спустился» к техническому отделу, который «обещает» «настроить» обмен в течении 2 недель
P.P.S Другая мегасеть озадачила, что в это время (с 26.11) они переходят на другой формат УПД (СчФДОП), прислав многостраничные инструкции и кучу «пужалок», а с 1.12 «задолбали» ежедневными правками по оформлению уникальных тегов… При этом по факту не принимая вообще УПД в данном формате
Часовой пояс GMT +3, время: 10:53.
Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.