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

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

12.08.2022 9:40


Контакты Поиск
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% её переписывать, добавляю защиту и от таких "дураков"??? Пока удалил, найденный единственный такой кривой файл и всё заработало... но уж больно нет желания заниматься "глупой" работой - подожду м.б. это был разовый косяк в их программном обеспечении?
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. При создании исходящих файлов производится обратное преобразование... т.е. и по поставкам РЦ работает "робот, а не человек"!
22.11.2021 10:14
AndreyZh
 
В очередной раз убедился, что изобрести, запрограммировать - это 10%-20% от решения реальной проблемы...

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

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

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

Сличение описаний нового мануала - нашел 2 расхождения со "старым"... переделал программу - в воскресенье проведение доков в реальной контуре, натыкание на ошибки, удаление моих липовых доков... и так 3 выходных. Конечно в "итого" всё заработало и уже неделю работает без проблем.
08.02.2022 17:33
AndreyZh
 
Обмен электронными документами весьма ответственная операция, а проблемы с ними, недовозы товаров с позиций торговых сетей - штрафуемые нарушения, а посему изначально в программу интеграции внеслись режимы протоколирования, сохранения принятых и отосланных документов, что ещё программа дублирует в каталоге архивов FTP сервера...

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

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

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

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

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





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




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

Код:
Заказ от 14.02.22 №_6467
Err не найдено/пустой GTIN: 019O Палет (Европоддон 1200*800)    шт
Заказ от 15.02.22 №_6038
      CR  Торт "Сникерс" 650                                514.000     108.12 Х607124660811
Заказ от 15.02.22 №_6044
      CR  пирожное "Профитроли со вкусом пломбира"          867.000      48.81 Х607124660873
Заказ от 15.02.22 №_6051
      CR  Торт "Сникерс" 650                                348.000     108.12 Х607124660811
Заказ от 15.02.22 №_6070
      CR  Торт "Рулет Сказка" 500                           428.000      69.39 Х607124660781
Заказ от 15.02.22 №_6071
      CR  Торт "Вдохновение 600"                            166.000     100.47 Х607124660743
Заказ от 15.02.22 №_6468
Err не найдено/пустой GTIN: 019O Палет (Европоддон 1200*800)    шт
Заказ от 15.02.22 №_6468
Err не найдено/пустой GTIN: 019O Палет (Европоддон 1200*800)    шт
Заказ от 15.02.22 №_6469
Err не найдено/пустой GTIN: 019O Палет (Европоддон 1200*800)    шт
Заказ от 15.02.22 №_6470
Err не найдено/пустой GTIN: 019O Палет (Европоддон 1200*800)    шт
Заказ от 15.02.22 №_6471
Err не найдено/пустой GTIN: 019O Палет (Европоддон 1200*800)    шт
Заказ от 16.02.22 №_6036
      CR  торт "Бисквитный с масл.кремом" Классика 600        6.000      95.20 Х607124660736
Заказ от 16.02.22 №_6057
      CR  Торт "Вдохновение 600"                            170.000     100.47 Х607124660743
Заказ от 16.02.22 №_6066
      CR  пирожное "Профитроли со вкусом пломбира"          759.000      48.81 Х607124660873
27.03.2022 10:01
AndreyZh
 
Недавно пришлось потратить время на источник проблемы и доказательство, что это не косяк программы интеграции или проблемы у провайдера, которого тоже "достали" этой разовой проблемой... Технические специалисты затратили несколько часов, а в ответ "но у нас же запарка и сами виноваты, что не можете быстро определить такие ошибки"... Это стало очень популярной аргументацией юзеров, что потихоньку стало раздражать и по возможности уже не пытаюсь глубоко разбираться в их претензиях, если это не становится "повторяющимися замечаниями". Суть проблемы сообщения и доработок программ:

Во всевозможных обменах ЭДО участвуют 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. Ничего - ручное заведение заказов.


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