Для производителей и оптовиков. EDI при отгрузке товаров покупателям - серьёзным торговым сетям : КИС Lack & УС Land

Великие и могучие торговые сети со школьниками на разработке и сопровождении их программ... и когда постоянно с их творениями сталкиваешься, то возникает недоумение на каких свалках они себе работников набирают? Сегодня их "прорвало" на творчество - конечно это мне задачи: обрабатывать дибилизм их разработчиков, добавляя сотни строк кода на обработку всевозможной их тупости, да добавляя негативные мысли в копилку своей невостребованности. Только за сегодня - правда предыдущие "разборки" были 2 недели назад и не буду употреблять конкретные названия этих мегасетей - мне с ними ещё работать:

1. ХХХ. Параллельно... 1.5 месяца не могли у себя настроить приём УПД к тому же постоянно без информирования меняя требования к оформлениям уникальных для сети тегов при этом обмениваясь другими документами, до кучи вдруг через пару дней успешного обмена УПД прекратили их принимать с информированием об "ошибке" - сами их разработчики не могли объяснить их источник... совместно с провайдером, методом тыка выяснили, что справочные единицы измерения, нигде ими не передаваемые должны иметь строгое написание с точностью до шрифта, как у них в базе, например "шт", "Кг."

Сегодня выслушивал очередные наезды на себя с требованием "что-то придумать"... Согласно договору мы отгружаем и обмениваемся по EDI примерно со 150 магазинами, а они постоянно посылают заказы на 500-600 магазинов, которые бракуются по настройке, но дамам нужно постоянно разбираться с этими ошибочными заказами, т.к. может в теории проскочить и наши ошибки за которые полагаются огромные штрафу... Конечно мы постоянно посылаем инфу по их косякам, что конечно ими не исправляется

2. YYY. Всё два месяца работало стабильно и без проблем... до сего дня, когда они вдруг решили изменить GTIN заказываемого товара по части магазинов на какой-то левый... Так любит развлекаться сеть TTT и программы имеют средства обработки такой ситуации, когда все магазины сети перешли на новый левый GTIN, но сходу не получилось включить такую обработку и теперь придётся выявлять нюанс по YYY, а пока дамы перешли на ручную обработку заказов... и меня будут доставать каждодневно по "автоматизации" бардака по сети YYY

3. ZZZ. Правила оформления XML файлов очень жесткие и не допускают вольностей оформления с тэгами... Всё всегда было хорошо, но сегодня пришло чудное уведомление о приёме с формально правилами ХМЛ правильным оформлением, но нарушающее требование обмена "при не заполнении тегов они не указываются"... в результате программа обмена стала вылетать, т.к. не учитывает такого "творчества". По делу конечно нужно снова на 80% её переписывать, добавляю защиту и от таких "дураков"??? Пока удалил, найденный единственный такой кривой файл и всё заработало... но уж больно нет желания заниматься "глупой" работой - подожду м.б. это был разовый косяк в их программном обеспечении?

Трясу мощами с утра пытаясь разобраться с алгоритмами древней, от 2015 года разработки по данной теме, когда сделал первую программу закачки заказов из электронных таблиц произвольной структуры от торговых сетей... и только недавно впервые с 2015 года всплыл нюанс, который в программах с 2019 был разрешен.

Осталось понять, как впихнуть понимаемые мной сейчас алгоритмы в древний код... Единственная отрада, что тот код очень подробно документирован.

Суть проблемы: как всегда "заторможенность" великих и могучих ТС - произошла смена матрицы поставляемых ассортиментов, т.е. одни новые товары добавились, а другие выведены из поставок... а магазины (частично) сети продолжают присылать заказы по уже не поставляемой продукции, которые "путают" программу.

Алгоритм решения (в новых программах) - имеется файл со списком отсеиваемых из заказов товаров

GLN КА,GTIN
…
GLN КА,GTIN

… и на этапе чтения заказов ТС и предварительного анализа просто игнорируются данные позиции... В новых программах данный нюанс прорабатывался на этапе разработке, а в этом древнем творении даже не подразумевались такие ситуации … и повторюсь - тщательно документируйте исходный код своих программ, а иначе это была бы "жесть"

Как не странно, но все, в том числе взаимоисключающие требования по EDI от разных сетей были разрешены. Даже в рамках раннее созданных технологий удаётся "разруливать" путаницы и неверное ведение GTIN у разных сетях... и как сейчас увидел - потребовалось в связи с возможным срочным ближайшим гемором, последняя правка исходного кода программы интеграции была 28.01.2021г.

Не люблю число 13, да и сделал огромную кучу дел с 6:00 - вот и хочется поболтать

Ещё одна приятная новость - повод для удовлетворения своим умишком! Как уже писал https://olegon.ru/showpost.php?p=369511&postcount=6, что с 07.06.2021 нежданно добавилось в интеграцию 1800 новых магазинов... Сильно опасался, что переход количества в качество приведёт к проблемам в работе программы - тьфу-тьфу, полет уже 2 недели нормальный… были проблемки в "УС Land", да и они поправились. Как подготовку купили существенно мощный ПК под предполагаемую нагрузку, но из-за раздолбайства компьютерщиков его ещё не настроили, а я ожидаю наездов со стороны руководства о лишних тратах... более того ПК интеграции продолжают пользовать параллельно обычной работе диспетчера - одним человеком... правда ставшим более раздражаемым

На тему: https://olegon.ru/showpost.php?p=369913&postcount=19, где так же полная неопределенность! 17.06.2021 пришло письмо от провайдера:

В принципе новая схема:





Проектируя программу интеграции предполагал такие неожиданные и срочные изменения, а посему при взаимодействии с провайдером по максимуму старался переложить логику изменения требований и законодательства на "сторону" провайдера, где предполагаемые "неопределенные" моменты обрабатываются его скриптами. Да и по данному неприятному письму не увидел требований изменения логики работы программы интеграции? Однако, на всякий случай 17.06 послал уточняющий запрос провайдеру:

На что 21.06 (за 10 дней до армагедца) получил ответ, который "развеселил до слёз":

Как следствие, предполагаю, что с 28.06.2021 по всем неоговоренным нюансам пресловутого высера Правительства РФ предстоит круглосуточная работа с непрерывной нервотрёпкой, а пока пора отдыхать?

Пришлось "побороться" с тормознутостью ОС и некоторых функций инструмента. Было замечено, что через некоторое время робот обрабатывающий обмен начинает подтормаживать. Лечилось переносом файлов из служебных каталогов в архив, а после этого скорость обработки документов возрастала примерно на 30%. Удивительно, т.к. происходило обращение к базовым механизмам OS - копировать файл, удалить, считать содержимое каталога. Ручное выделение устаревших файлов было утомительно и долго... и вот добавил режим:





В нём просто и очень быстро переносятся старые и ненужные в оперативной работе файлы в создаваемые каталог с именем даты архивации, что уже может делать персонал самостоятельно.

Как и я программа ничего не удаляет с ПК... и необходимость в "старье" пару раз возникала при разборках. Пользуясь случаем опишу каталоги программы интеграции:

Arc - Новый. Туда отправляем устаревшие файлы в каталоги с основными именами;
Err - Прога отправляет туда файлы XML, в которых обнаружены ошибки или несоответствие ожидаемой логики данные;
Inbox - сваливается в него в асинхронном режиме входящие файлы из FTP сервера. Затем, когда настанет "очередь" программа забирает для обработки;
Log - обработка каждого типа входящего или исходящего файла логируется и логи отражаются в процессе работы и сохраняются в данный каталог;
Mus - убирает всё не нужное. Пока (?):
Ok - корректные входящие и исходящие файлы, которые программа "признала" и обработала;
Outbox - сохранение исходящих файлов перед асинхронной отправки на FTP сервер;
Rep - сюда можно сохранять отчеты по режимам.

… и в завершении дня сегодняшнего... наконец полностью отладил новую технологию

Как писал раннее издавна была заморочка - у нас по продукции установлен правильный зарегистрированный GTIN, но в сетях (КА) под этим кодом числился некий левый товар. При приеме заказов их кривой GTIN через список PreoGTIN.cfg в программе zLeraOrd преобразовывался в наш правильный, а при отправке исходящих документов: подтверждение заказов, уведомлении об отгрузке, УПД уже в программе интеграции zLe производилось обратное преобразование наших правильных GTIN в их кривые. Схема по каждому GLN КА : GLN_КА, GTIN_КА, GTIN_правильный

Однако руководство решило, что надо по максимуму переходить на работу с распределительными центрами сетей, что облегчит логистику и планирование. Однако для РЦ товары фасуются в транспортную упаковку и у них появляется понятие фасовка, да и по сути - это другие товары, т.к. появляется ещё один этап производства. Так как, это изделия с другими характеристиками мы не можем им присваивать GTIN (глобальный уникальный идентификатор), как у входящего в упаковку штучного товара... Вот и РЦ полностью проводились через Web интерфейс, а в УС "ручками"… Но РЦ для поставок стало уже много, а увеличивать персонал ни кто не собирается, то пришлось ломать голову над разрешением этой проблемы.

Выход, как всегда был найден, как и решение проблемы! Для проги zLeraOrd введена ещё одна схема преобразований Preob_rc для преобразования для торговых точек (РЦ), а не КА, неких входящих GTIN в фиктивные GTIN продукции для РЦ... а дальше дело техники:

1. В УС для товаров (шаблонов изделий) РЦ вписали фиктивный GTIN:
2. При приеме заказов. zLe запоминая GTIN заказа и фасовку, переправляет заказ в zLeraOrd, где вначале GTIN преобразуется по схеме РЦ (если нужно), затем через преобразование "кривых GTIN"
3. При создании исходящих файлов производится обратное преобразование... т.е. и по поставкам РЦ работает "робот, а не человек"!

В очередной раз убедился, что изобрести, запрограммировать - это 10%-20% от решения реальной проблемы...

Сделал задачу по придуманным алгоритмам в соответствии с имеющимся у меня мануалом по правилам оформления документов, установил - не работает! По началу браковало на уровне чтения документов из FTP - последовательно разобрался, что анализ по ряду полей строгий, хотя выявленные нюансы не описаны в мануале и были "вычислены"... а затем "веселее":

Подтверждение заказа, уведомление об отгрузке поступает на платформы как-бы без ошибок, а через 2-5 минут у "уведомления" изменяется статус на отказано с непонятными ошибками. Подумал - ничего не понял, звоню провайдеру, объясняю проблему, по мнению спеца из ТП "как-то" неправильно заполнены поля... Затем долгий обмен письмами с провайдером с приложением отправляемых ХМЛ и "эксперименты"... Наконец мне это надоело - рекомендовал спецу зайти к клиенту по удаленке и самому увидеть проблему

Наконец спец провайдера позвонил клиенту - девушки ему сказали что очень заняты... "заходите после", на что "обиженный" спец прислал мне письмо с новым свежим мануалом - типа разбирайся сам... Конечно жалобы боссу, попытки стыковаться с менеджером провайдером и объяснения от него, что в Мск время спецов слишком дорогое, что-бы тратить его на "капризы" дамок из глубинке, но моё не так дорогое - типа "разлекайся"...

Сличение описаний нового мануала - нашел 2 расхождения со "старым"... переделал программу - в воскресенье проведение доков в реальной контуре, натыкание на ошибки, удаление моих липовых доков... и так 3 выходных. Конечно в "итого" всё заработало и уже неделю работает без проблем.

Обмен электронными документами весьма ответственная операция, а проблемы с ними, недовозы товаров с позиций торговых сетей - штрафуемые нарушения, а посему изначально в программу интеграции внеслись режимы протоколирования, сохранения принятых и отосланных документов, что ещё программа дублирует в каталоге архивов FTP сервера...

Но пользователи имеют бесконечные таланты обманывать защиту программы... программы интеграции не получается, тогда пытаемся обмануть со стороны учетной системы "УС Land" - нашли таки "дырку": Одна сетка прислала претензию, что пару недель назад в несколько распределительных сетей не привезли заказанные изделия... "обделались" без штрафов - менеджеры молодцы! Однако ко мне обратились с "наездом" на косячную работу программ.

Пришлось потратить много часов, отслеживая действия операторов в процессе обработки ошибочных документов, отправленных по EDI... К счастью для меня - это хитрые косяки операторов, а после объяснения их косяков вспомнили почему они так сотворили:

1. Загрузили заказы;
2. Далее им сказали, что изделие не смогут произвести по сложностям производства;
3. Опера пачкой удалили это изделие из заказа;
4. Отправили подтверждение заказа и уведомление об отгрузке;
5. Нашли ресурсы произвести изделие;
6. Опера добавили (вернули) изделие в заказы;
7. Снова, забыв отменить предыдущую отправку, подтверждение заказа и уведомление об отгрузке. Т.е. у провайдера остались в БД старые документы.

Признать свой косяк очень сложно, поэтому меня назначили основным виноватым, так как в программе нет средств оперативного обнаружения таких ошибок... Хорошо - сделал:

Теперь каждая операция выгрузки документов УС в программу интеграции:





Ведёт лог по полному выгруженному набору информации, по каждой операции отдельный лог файл с именем, содержащим дату и время выгрузки до секунды, где содержится подробная информация о выгрузке товарных позиция и проблемами при выгрузке по причине неполного оформления реквизитов справочников или сбоя БД УС:




Пример информации из файла логов - обычный текстовый файл в 1251 кодировке:

Недавно пришлось потратить время на источник проблемы и доказательство, что это не косяк программы интеграции или проблемы у провайдера, которого тоже "достали" этой разовой проблемой... Технические специалисты затратили несколько часов, а в ответ "но у нас же запарка и сами виноваты, что не можете быстро определить такие ошибки"... Это стало очень популярной аргументацией юзеров, что потихоньку стало раздражать и по возможности уже не пытаюсь глубоко разбираться в их претензиях, если это не становится "повторяющимися замечаниями". Суть проблемы сообщения и доработок программ:

Во всевозможных обменах ЭДО участвуют 3 программы:

1. zLeraOrd - программа (технология) развиваемая с 2015 года. Её суть - программа мониторит файлы заказов в своём каталоге, на их основе и своей настройки создаёт заказы в учетной системы. Сейчас файлы для неё поступают из EDI, платформ заказчиков, в письмах покупателей и основное в программе - логика создания заказов.





2. Lera_edi - полная автоматическая бездиалоговая интеграция учетной системы с провайдером в системе EDI. В части "заказов" - забирает с FTP сервера, сохраняет атрибуты заказа в своей БД... и кидает в программу zLeraOrd:





Очевидно, что исходящие документы программа :Lera_edi "стыкует" с принятыми заказами, выбирая кучу уникальных атрибутов торговых сетей из раннее сохраненных заказов, а по-этому может работать только с принятыми этой программой заказами по уникальной связке "КА+ТТ+номер+дата_заказа"... и если "скормить" программе документы по не известному заказу, то она отправляет документ в ошибки... Так вот - у провайдера в течении нескольких часов были проблемы с FTP сервером и операторы не долго думая взяли сотни заказов на платформе и скормили их программе zLeraOrd, типа не могут задерживать производственные процессы... а на следующие сутки попытались отправить всё провайдеру через Lera_edi, которая их (не пропущенные через себя) отвергла.

Что сделано? При передаче из Lera_edi в zLeraOrd в имя файла вставляется семафор, а zLeraOrd при приемке заказа анализирует наличие семафора в имени файла и прописывает источник получения заказа в "системную метку" заказа. Сист.метка - не печатаемое но анализируемое (отражаемое) примечание е документу. Таким образом сейчас заказы "различаются":

1. Из EDI - пришедшие из Lera_edi;
2. Руками - просто от куда-то скормили XML файлы программе zLeraOrd;
3. Ничего - ручное заведение заказов.