Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли > КИС Lack & УС Land

Для производителей и оптовиков. EDI при отгрузке товаров покупателям - серьёзным торговым сетям

25.10.2021 1:36


06.02.2021 12:57
AndreyZh
 



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

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

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

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

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

Правка: AndreyZh, 06.02.2021 13:01
06.05.2021 08:58
AndreyZh
 
Трясу мощами с утра пытаясь разобраться с алгоритмами древней, от 2015 года разработки по данной теме, когда сделал первую программу закачки заказов из электронных таблиц произвольной структуры от торговых сетей... и только недавно впервые с 2015 года всплыл нюанс, который в программах с 2019 был разрешен.

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

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

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

GLN КА,GTIN

GLN КА,GTIN

… и на этапе чтения заказов ТС и предварительного анализа просто игнорируются данные позиции... В новых программах данный нюанс прорабатывался на этапе разработке, а в этом древнем творении даже не подразумевались такие ситуации … и повторюсь - тщательно документируйте исходный код своих программ, а иначе это была бы "жесть"
22.06.2021 11:25
AndreyZh
 
Цитата:
AndreyZh Великие и могучие торговые сети со школьниками на разработке и сопровождении их программ... и когда постоянно с их творениями сталкиваешься, то возникает недоумение на каких свалках они себе работников набирают? Сегодня их "прорвало" на творчество - конечно это мне задачи: обрабатывать дибилизм их разработчиков, добавляя сотни строк кода на обработку всевозможной их тупости
Как не странно, но все, в том числе взаимоисключающие требования по EDI от разных сетей были разрешены. Даже в рамках раннее созданных технологий удаётся "разруливать" путаницы и неверное ведение GTIN у разных сетях... и как сейчас увидел - потребовалось в связи с возможным срочным ближайшим гемором, последняя правка исходного кода программы интеграции была 28.01.2021г.
22.06.2021 11:45
AndreyZh
 
Не люблю число 13, да и сделал огромную кучу дел с 6:00 - вот и хочется поболтать

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

Цитата:
Новый порядок работы с квитанциями по УПД/УКД

Уважаемые коллеги!

С 1 июля 2021 года изменится процесс работы с электронными счетами-фактурами. Новый порядок утвержден приказом Минфина России от 05.02.2021 № 14н. Предыдущий регламентирующий документ прекратит свое действие.
Приказ меняет логику обмена квитанциями по документам УПД/УКД. Он обязывает отправлять Титул продавца, и получать новые дополнительные служебные квитанции.

Что нужно сделать?

В веб-версии EDI-платформы все настройки будут выполнены автоматически. Если вы пользуетесь модулем 1С для ЭДО компании, в ближайшем релизе будут учтены все требования законодательства.

Если вы используете собственное решение для отправки УПД/УКД – доработайте учетную систему под новые требования. Учитывайте новые правила в своей работе или перешлите это письмо ответственному коллеге.
В принципе новая схема:





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

Цитата:
Получил сегодня приложенное письмо и извините, но не понял, что от меня, как разработчика «собственного решения» требуется к 1 июля? Очень ожидаю ответ технического специалиста?

У нас используется согласованная с вами схема работы:

- Прога интеграции забирает заказы с ftp сервера и после помешает в базу учетной системы;
- После доработки заказов операторов через прогу интеграции на ftp сервер помещаются подтверждения заказов и уведомления об отгрузке;
- Не обязательно для УС из ftp забираются уведомления о приёме;
- После отправляются электронные УПД на ftp сервер, которые после обработки сценарием помещаются в «черновики» платформы. - После группового подписания из платформы по согласованному с контрагентами принципу уже вами автоматом УПД отправляются покупателям.
На что 21.06 (за 10 дней до армагедца) получил ответ, который "развеселил до слёз":

Цитата:
Андрей, доброе утро!
Задача на технических специалистах уже есть. В ближайшее время коллеги вернутся к Вам с обратной связью.
Как следствие, предполагаю, что с 28.06.2021 по всем неоговоренным нюансам пресловутого высера Правительства РФ предстоит круглосуточная работа с непрерывной нервотрёпкой, а пока пора отдыхать?
31.08.2021 09:11
AndreyZh
 
Пришлось "побороться" с тормознутостью ОС и некоторых функций инструмента. Было замечено, что через некоторое время робот обрабатывающий обмен начинает подтормаживать. Лечилось переносом файлов из служебных каталогов в архив, а после этого скорость обработки документов возрастала примерно на 30%. Удивительно, т.к. происходило обращение к базовым механизмам OS - копировать файл, удалить, считать содержимое каталога. Ручное выделение устаревших файлов было утомительно и долго... и вот добавил режим:





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

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

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

Как писал раннее издавна была заморочка - у нас по продукции установлен правильный зарегистрированный 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. При создании исходящих файлов производится обратное преобразование... т.е. и по поставкам РЦ работает "робот, а не человек"!

Правка: AndreyZh, 16.10.2021 09:24

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.