Для производителей и оптовиков. EDI при отгрузке товаров покупателям - серьёзным торговым сетям : КИС Lack & УС Land
21.11.2024 11:39
█ 28.04.2022 15:58
Начинаю распутывать клубок проблем, когда количество переходит в качество... Тысячи адресов с которых приходят заказы несколько тысяч и ручной (визуальный) контроль ряда нюансов не проходит, да и экзотические косяки начали появляться, как например продумываемый и исправляемый сегодня.
Программа интеграции приняла заказ и отправила его в УС для доработки, как следствие сохранила его в своей внутренней БД для блокировки повторного приёма. Уже возникли 2 ситуации:
1. Заказчик послал заказ. Затем оставив атрибуты неизменным изменил на платформе. Прога интеграции его уже скушала и новый вариант не пропускает;
2. Заказ принят и отправлен в УС. Дамы в УС его удалили, но следы в проге интеграции сохранились. Затем хотят его снова закачать - взять с платформы и кинуть файл заказа в папку INBOX программы интеграции, а нет - он уже проводился....
Подумав, сделал первый в программе интеграции интерфейсный режим. Для облегчения программа сохраняет вводимые атрибуты:
Атрибуты копипастом можно взять из платформы провайдера. Программа ищет заказ в своей БД, а затем возможны варианты:
1. Заказ не найден - сообщение:
2. Заказ найден - запрос на удаление следов. Все ошибки операторов исправляемые - если удалят "лишнее", то всегда можно взять файл с платформы:
Программа интеграции приняла заказ и отправила его в УС для доработки, как следствие сохранила его в своей внутренней БД для блокировки повторного приёма. Уже возникли 2 ситуации:
1. Заказчик послал заказ. Затем оставив атрибуты неизменным изменил на платформе. Прога интеграции его уже скушала и новый вариант не пропускает;
2. Заказ принят и отправлен в УС. Дамы в УС его удалили, но следы в проге интеграции сохранились. Затем хотят его снова закачать - взять с платформы и кинуть файл заказа в папку INBOX программы интеграции, а нет - он уже проводился....
Подумав, сделал первый в программе интеграции интерфейсный режим. Для облегчения программа сохраняет вводимые атрибуты:
Атрибуты копипастом можно взять из платформы провайдера. Программа ищет заказ в своей БД, а затем возможны варианты:
1. Заказ не найден - сообщение:
2. Заказ найден - запрос на удаление следов. Все ошибки операторов исправляемые - если удалят "лишнее", то всегда можно взять файл с платформы:
█ 27.06.2022 14:13
«Сбои разные «нужны», сбои разные важны»…
Очередная ситуация, когда количество переходит в качество и пример «разрешения» данных ситуаций. В процессе перемещения электронных документов от платформы к учетной системы возможны и происходят сбои, потери документов в движении. Когда документов было мало, то сбоев было мало и они отслеживались в ручную, но их стало очень много… Мне была поставлена задача придумать и сделать автоматизированный контроль утери информации?
Вспомним цепочку прохождения документов в системе EDI:
Входящие документы – заказы, подтверждение отгрузки. Документ с Web платформы --> перемещается на FTP сервер --> программа интеграции забирает документ с FTP, сохраняя его копию в архиве FTP и информацию о документе во внутренних таблицах, перемещает его в каталог программы обработки заказов zLeraOrd --> создаётся автозаказ в учетной системе --> заказ в УС дорабатывается или вообще может быть удален.
Исходящие документы – подтверждение заказа, уведомление об отгрузке, УПД. Задание на создание и отправку документов задаётся в учетной системе --> программа интеграции создаёт электронный документ и сохраняет его на FTP сервере, оставляя пометку об отправке в своей БД --> Web платформа забирает документ с FTP и проводит с ним дальнейшие работы.
В программах, созданных мной уже была вложена техника «запоминания» совершенных «деяний» в её БД и файловой системе, т.е. сам себя, в теории, мог проверить. Созвоны с ТП, изучение платформы привели к обнаружению в ней отчета по факту наличия и статусу любых видов документов на платформе. В этом отчете, присылаемом на e-mail в виде какого-то корявого XLS файла – внешние программы не понимали его тип было очень много мусорной информации, но были и некоторые атрибуты: исходные дата и номер заказа, UUID хвост файла, дата и номер документа из УС, где их уникальность жестко контролируется.
Далее «дело техники»… Создан режим верификации по анализу прохождения документов разных типов через цепочку документооборота и построение отчета по «выпадению» документов на разных этапах, где решаются задачи:
Для входящих документов. Правильно, если документ с платформе будет соответствовать документу в учетной системе, а если нет, то отражены этапы, где от «потерялся», т.е. с кем из специалистов нужно решать проблемы. Уже находилось: С Web не попал на FTP; операторы удалили заказ из УС, через программу интеграции заказ прошел, а zLeraOrd его забраковала, но операторы не обратили внимание на это демонстрирующееся событии.
Для исходящих. Правильно, если полностью, отправленные из УС документы будут доставлены получателю. Находилось только – из УС не выгружалось, а на платформу внесено в ручном режиме.
Очередная ситуация, когда количество переходит в качество и пример «разрешения» данных ситуаций. В процессе перемещения электронных документов от платформы к учетной системы возможны и происходят сбои, потери документов в движении. Когда документов было мало, то сбоев было мало и они отслеживались в ручную, но их стало очень много… Мне была поставлена задача придумать и сделать автоматизированный контроль утери информации?
Вспомним цепочку прохождения документов в системе EDI:
Входящие документы – заказы, подтверждение отгрузки. Документ с Web платформы --> перемещается на FTP сервер --> программа интеграции забирает документ с FTP, сохраняя его копию в архиве FTP и информацию о документе во внутренних таблицах, перемещает его в каталог программы обработки заказов zLeraOrd --> создаётся автозаказ в учетной системе --> заказ в УС дорабатывается или вообще может быть удален.
Исходящие документы – подтверждение заказа, уведомление об отгрузке, УПД. Задание на создание и отправку документов задаётся в учетной системе --> программа интеграции создаёт электронный документ и сохраняет его на FTP сервере, оставляя пометку об отправке в своей БД --> Web платформа забирает документ с FTP и проводит с ним дальнейшие работы.
В программах, созданных мной уже была вложена техника «запоминания» совершенных «деяний» в её БД и файловой системе, т.е. сам себя, в теории, мог проверить. Созвоны с ТП, изучение платформы привели к обнаружению в ней отчета по факту наличия и статусу любых видов документов на платформе. В этом отчете, присылаемом на e-mail в виде какого-то корявого XLS файла – внешние программы не понимали его тип было очень много мусорной информации, но были и некоторые атрибуты: исходные дата и номер заказа, UUID хвост файла, дата и номер документа из УС, где их уникальность жестко контролируется.
Далее «дело техники»… Создан режим верификации по анализу прохождения документов разных типов через цепочку документооборота и построение отчета по «выпадению» документов на разных этапах, где решаются задачи:
Для входящих документов. Правильно, если документ с платформе будет соответствовать документу в учетной системе, а если нет, то отражены этапы, где от «потерялся», т.е. с кем из специалистов нужно решать проблемы. Уже находилось: С Web не попал на FTP; операторы удалили заказ из УС, через программу интеграции заказ прошел, а zLeraOrd его забраковала, но операторы не обратили внимание на это демонстрирующееся событии.
Для исходящих. Правильно, если полностью, отправленные из УС документы будут доставлены получателю. Находилось только – из УС не выгружалось, а на платформу внесено в ручном режиме.
█ 15.08.2022 11:37
Программа - всего лишь модель бизнеса, а подсказать программное решение вполне может и "уборщица", так вот и недавно был сильно озадачен... Сеть Х5 потребовало указание сроков годности в уведомлениях об отгрузке. В принципе за долгие годы развития системы данные техники достаточно хорошо были отработаны и имеются гибкие механизмы их ведения и контроля. Чуть подробнее: https://olegon.ru/showthread.php?t=33438
В частности есть опционная возможность автоматического назначения сроков годности на продукцию исходя из даты производства и срока хранения, что в реале отключено, т.к. по программе изделие может быть изготовлено сегодня, а по требованию покупателя, фактически будет изготовлено послезавтра и на этикетке проставляется дата фактического производства, как следствие срока годности. Во вторых заказы от покупателей, отгрузочные документы создаются днем на следующий день, продукция производится ночью, водители вывозят рано утром, а факт производства в программе создаётся на следующий день.
Так вот, на задачу отправлять сроки хранения в уведомлении я озвучил "сложности"... и "народ" завис... Пошел изучать вопрос по цехам и складу готовой продукции и выяснил - жесткое требование сетей == дата изготовления = дате отгрузке = дате отгрузочного документа... т.е. операторы закачивают заказ на послезавтра, делают сопроводительные документы на послезавтра, этой эе датой производят и отгружают.
Остальное - дело техники: правда внесено множество изменений в таблицы обмена. Суть - передаю также срок хранения, а при отправке уведомления об отгрузке к дате ТТН добавляю срок хранения, что даёт срок годности, требуемый Х5
В частности есть опционная возможность автоматического назначения сроков годности на продукцию исходя из даты производства и срока хранения, что в реале отключено, т.к. по программе изделие может быть изготовлено сегодня, а по требованию покупателя, фактически будет изготовлено послезавтра и на этикетке проставляется дата фактического производства, как следствие срока годности. Во вторых заказы от покупателей, отгрузочные документы создаются днем на следующий день, продукция производится ночью, водители вывозят рано утром, а факт производства в программе создаётся на следующий день.
Так вот, на задачу отправлять сроки хранения в уведомлении я озвучил "сложности"... и "народ" завис... Пошел изучать вопрос по цехам и складу готовой продукции и выяснил - жесткое требование сетей == дата изготовления = дате отгрузке = дате отгрузочного документа... т.е. операторы закачивают заказ на послезавтра, делают сопроводительные документы на послезавтра, этой эе датой производят и отгружают.
Остальное - дело техники: правда внесено множество изменений в таблицы обмена. Суть - передаю также срок хранения, а при отправке уведомления об отгрузке к дате ТТН добавляю срок хранения, что даёт срок годности, требуемый Х5
█ 10.11.2022 15:57
С головой закопался в проблемах порождаемых типично Российским подходом к цифровизации. Как минимум уже достало:
1. Отсутствие жестких стандартов оформления документов ЭДО/EDI, а то, что они считают стандартами плохо продумано;
2. Желание крупных игроков (провайдеров) зарабатывать на всём, в том числе на исправлениях своих же ошибок или непродуманных технологиях;
3. Капризы и полное нежелание ряда пользователей следовать предписанными, даже этими псевдостандартами правилам. Хочу, что-бы было так и точка!
Все эти проблемаы проявились в недавно решенной задачи по EDI. Суть задачи была понятна изначально... Сеть на РЦ заказывает много единиц товара, которые поставщик должен размещать на возвратной таре (паллетах) и очевидно точное число требуемых паллет при заказе неизвестно, хотя одна ТС заказывает их с избытком, что даёт возможность избегать проблемы задачи, описанной ниже. Другая сеть не требует движения паллет по EDI, что тоже снимает проблемы, но вот третья мегасети встала "позу", начиная с марта 2022г. - движение паллет должно быть в EDI, а иначе платить не будем!
Мне поставили задачу разрешить эту проблему, но ключевое базисное требование по EDI было - НЕЛЬЗЯ добавлять новые позиции в исходный заказ, а только удалять их или уменьшать количество. Весь непродуманный "стандарт" EDI опирается на это требование... Видимо очень многие "фигуры" были озадачены данной проблемой.
Наверное провайдеры сделали какой-то костыль для этой сетки. Его суть: мы подтверждение заказа, уведомление об отгрузке отправляем без паллет, на РЦ при отправке уведомления о приеме могут добавить в заказ фактическое число поступивших паллет, т.е. отправляя УПД по "уведомлению" сеть получала желаемый документ для оплаты... Однако на одном РЦ категорически отказались добавлять эти паллеты, утверждая, что "у всех" эта проблема решена без их дополнительных сложностей...
Конечно постоянно с июня долбим провайдера - что и как делать? С августа наконец стали получать ответы - платите и мы вам всё доработаем. Параллельно нашли и начали обзванивать "всех поставщиков" этой сети и этого РЦ... в основном бизнес прекратил поставки на это РЦ... и это из-за одной упёртой дамы... но "достучались" до пары поставщиков, которые нехило заплатили провайдеру за такую доработку, но при этом у них остался полуручной режим.
Продолжаем долбить провайдера - что нам нужно доработать, что бы ваши механизмы для тех поставщиков заработали... После серии угроз ухода от них получили ТЗ, но так написанной, что ХЗ, как его реализовать, но суть понял - паллеты можно через хардкодные вставки добавить только к уведомлению и УПД... Теперь "взбрыкнули" наши девушки - не хотим вводить их вручную...
В общем используя метод тыка и подбора реквизитов получилось "пропихнуть" документы на платформу и следовательно получить правильные алгоритмы для своих доработок. Так же придумал, как минимизировать свою набивку кода:
1. Заказы приходят без паллет. Дамы довносят их УС;
2. При выгрузке уведомлений об отгрузке смотрю наличие липового фиксированного кода паллеты, а если его нет в заказе, то добавляю в заказ, как бы он там был;
3. Эту позицию в подтверждении заказа игнорирую;
4. В уведомлении, УПД она пользуется, как в обычном стандартном подходе... Все довольны! Даже полгода не прошло
1. Отсутствие жестких стандартов оформления документов ЭДО/EDI, а то, что они считают стандартами плохо продумано;
2. Желание крупных игроков (провайдеров) зарабатывать на всём, в том числе на исправлениях своих же ошибок или непродуманных технологиях;
3. Капризы и полное нежелание ряда пользователей следовать предписанными, даже этими псевдостандартами правилам. Хочу, что-бы было так и точка!
Все эти проблемаы проявились в недавно решенной задачи по EDI. Суть задачи была понятна изначально... Сеть на РЦ заказывает много единиц товара, которые поставщик должен размещать на возвратной таре (паллетах) и очевидно точное число требуемых паллет при заказе неизвестно, хотя одна ТС заказывает их с избытком, что даёт возможность избегать проблемы задачи, описанной ниже. Другая сеть не требует движения паллет по EDI, что тоже снимает проблемы, но вот третья мегасети встала "позу", начиная с марта 2022г. - движение паллет должно быть в EDI, а иначе платить не будем!
Мне поставили задачу разрешить эту проблему, но ключевое базисное требование по EDI было - НЕЛЬЗЯ добавлять новые позиции в исходный заказ, а только удалять их или уменьшать количество. Весь непродуманный "стандарт" EDI опирается на это требование... Видимо очень многие "фигуры" были озадачены данной проблемой.
Наверное провайдеры сделали какой-то костыль для этой сетки. Его суть: мы подтверждение заказа, уведомление об отгрузке отправляем без паллет, на РЦ при отправке уведомления о приеме могут добавить в заказ фактическое число поступивших паллет, т.е. отправляя УПД по "уведомлению" сеть получала желаемый документ для оплаты... Однако на одном РЦ категорически отказались добавлять эти паллеты, утверждая, что "у всех" эта проблема решена без их дополнительных сложностей...
Конечно постоянно с июня долбим провайдера - что и как делать? С августа наконец стали получать ответы - платите и мы вам всё доработаем. Параллельно нашли и начали обзванивать "всех поставщиков" этой сети и этого РЦ... в основном бизнес прекратил поставки на это РЦ... и это из-за одной упёртой дамы... но "достучались" до пары поставщиков, которые нехило заплатили провайдеру за такую доработку, но при этом у них остался полуручной режим.
Продолжаем долбить провайдера - что нам нужно доработать, что бы ваши механизмы для тех поставщиков заработали... После серии угроз ухода от них получили ТЗ, но так написанной, что ХЗ, как его реализовать, но суть понял - паллеты можно через хардкодные вставки добавить только к уведомлению и УПД... Теперь "взбрыкнули" наши девушки - не хотим вводить их вручную...
В общем используя метод тыка и подбора реквизитов получилось "пропихнуть" документы на платформу и следовательно получить правильные алгоритмы для своих доработок. Так же придумал, как минимизировать свою набивку кода:
1. Заказы приходят без паллет. Дамы довносят их УС;
2. При выгрузке уведомлений об отгрузке смотрю наличие липового фиксированного кода паллеты, а если его нет в заказе, то добавляю в заказ, как бы он там был;
3. Эту позицию в подтверждении заказа игнорирую;
4. В уведомлении, УПД она пользуется, как в обычном стандартном подходе... Все довольны! Даже полгода не прошло
█ 29.12.2022 10:06
Число задач бизнеса - реальных пользователей систем "УС Лэнд" всё растет и растет 
Что, в частности подтверждает закон, что проект автоматизации никогда не заканчивается...
Вот и появилась задача упрощения "жизни" операторов: при отгрузке на распределительные центры сетей товар укладывается на возвратную тару - паллеты. Число необходимых паллет при заказе сети заранее неизвестно и становится известным после производства и укладки продукции для поставки, по этому данный товар в электронных заказах не приходит, да и правила работы с паллетами в разных ТС различаются, например в АО Тандер они оформляются отдельными сопроводительными документами и не проходят через EDI, а у Ленты, РЦ Х5 должны включаться в документооборот по EDI... См. выше
Лениво было решать задачку через хардкод... и придумал технологию: к программе zLeraOrd добавилась настройка, задающая правила добавления ассортиментов в список заказов по разным правилам для разных КА и ассортиментов. При попадании КА в данную схему программа или создаёт отдельные ТТН, беря базовые атрибуты из исходного заказа, как например на скрине или добавляет ассортименты к существующим заказам
По "моде" программ интеграции с EDI, которые имеют множество конфигурационных файлов, в тело файла включается инструкция с описанием назначения файла и задания настроечных атрибутов...
Что, в частности подтверждает закон, что проект автоматизации никогда не заканчивается...Вот и появилась задача упрощения "жизни" операторов: при отгрузке на распределительные центры сетей товар укладывается на возвратную тару - паллеты. Число необходимых паллет при заказе сети заранее неизвестно и становится известным после производства и укладки продукции для поставки, по этому данный товар в электронных заказах не приходит, да и правила работы с паллетами в разных ТС различаются, например в АО Тандер они оформляются отдельными сопроводительными документами и не проходят через EDI, а у Ленты, РЦ Х5 должны включаться в документооборот по EDI... См. выше
Лениво было решать задачку через хардкод... и придумал технологию: к программе zLeraOrd добавилась настройка, задающая правила добавления ассортиментов в список заказов по разным правилам для разных КА и ассортиментов. При попадании КА в данную схему программа или создаёт отдельные ТТН, беря базовые атрибуты из исходного заказа, как например на скрине или добавляет ассортименты к существующим заказам
По "моде" программ интеграции с EDI, которые имеют множество конфигурационных файлов, в тело файла включается инструкция с описанием назначения файла и задания настроечных атрибутов...
Образец схемы создания заказов Pal_plus.cfg:
█ 20.02.2023 08:43
Сам удивился, как спроектирована самая старая программа комплекса интеграции 
В принципе она развивалась по двум веткам:
1. Практически всё для создания заказов бралось из атрибутов, связанных с покупателями из БД УС;
2. В основном бралось из заказов и настройки вызовов программы интеграции, что и стало в "итого" основным....
Да так, что и не заметили когда образовалась глупая ошибка в коде, а именно: при определении атрибутов контрагентов программа не вставала на него, т.е. ветка №1 перестала работать. Однако "всплыла" задача акций: https://olegon.ru/showthread.php?t=37806 и вместе с ней выявилась ошибка, что автоматом программа акции перестала проставлять... Конечно исправил, но обидно, что такие косяки не проявляются сразу
В принципе она развивалась по двум веткам:1. Практически всё для создания заказов бралось из атрибутов, связанных с покупателями из БД УС;
2. В основном бралось из заказов и настройки вызовов программы интеграции, что и стало в "итого" основным....
Да так, что и не заметили когда образовалась глупая ошибка в коде, а именно: при определении атрибутов контрагентов программа не вставала на него, т.е. ветка №1 перестала работать. Однако "всплыла" задача акций: https://olegon.ru/showthread.php?t=37806 и вместе с ней выявилась ошибка, что автоматом программа акции перестала проставлять... Конечно исправил, но обидно, что такие косяки не проявляются сразу
█ 26.04.2023 16:46
Если всё работает без участия разработчика, то за что ему платить?
В принципе задача ЭДО изначально ставилась для АО "Тандер", но с дури постарался делать универсальной, для возможности подключения и других крупных сетей, в рамках одного заказа. Конечно для разных сетей чуть разные схемы создания XML исходящих документов и они были отлажены для Тандер, Х5, Лента и некая схема с избыточной информацией...
Сегодня, навещая клиента и спрашивая о вопросах и пожеланиях, люди вспомнили... Проверь всё ли нормально? Оказывается уже месяц отгружают и обмениваются всеми документами с "Дикси" - насколько мощная сеть не знаю... Взглянули, говорят на форму исходящих XML - похожее на Тандер, ну и сделали настройки, как для Тандера и типа всё заработало... При посещении руководителя, оплачивающего работы нарвался на вопрос "что новенького" - нет? А чем ты занимался?
В принципе задача ЭДО изначально ставилась для АО "Тандер", но с дури постарался делать универсальной, для возможности подключения и других крупных сетей, в рамках одного заказа. Конечно для разных сетей чуть разные схемы создания XML исходящих документов и они были отлажены для Тандер, Х5, Лента и некая схема с избыточной информацией...
Сегодня, навещая клиента и спрашивая о вопросах и пожеланиях, люди вспомнили... Проверь всё ли нормально? Оказывается уже месяц отгружают и обмениваются всеми документами с "Дикси" - насколько мощная сеть не знаю... Взглянули, говорят на форму исходящих XML - похожее на Тандер, ну и сделали настройки, как для Тандера и типа всё заработало... При посещении руководителя, оплачивающего работы нарвался на вопрос "что новенького" - нет? А чем ты занимался?
█ 08.08.2023 17:20
Продолжаем подстраиваться под требования влиятельных торговых сетей 
При получении письма персонал был озадачен, т.к. этого никогда не было... и как теперь быть? что это означает? Возможно теперь такая ситуация будет возможной
Надо - сделано. Как программа это отрабатывает? При обнаружении признаков отмены заказа:
1. В файл лога (отчета) пишет, что необходимо отменить/удалить конкретный заказ;
2. Заказ в предзаказе создаётся, но не проводимый, без номера, а в основание вместо обычной информации прописывает информацию из EDI документа по аннулированию заказа. Вам нужно будет удалить/отменить отправку исходного заказа, а так же удалить этот липовый документ.
До кучи улучшена "защита от дурака"... Наткнулись, однако. Наши номера документов программа определяет автоматически по неким прописанным в настройках правилам, но возможен ввод заказов "в ручную" и делаю задание на производство исходя из всех типов заказов. Что-бы отличать эти заказы от пришедших с EDI операторы не пишут номер и ставят признак "непроводимый". Но как-то забыли поставить этот признак и программа начала нумерацию с 1... Сейчас программа игнорирует все признаки и продолжает нумерацию с последнего номера большего № 2, т.е. по возможности игнорируя липу
При получении письма персонал был озадачен, т.к. этого никогда не было... и как теперь быть? что это означает? Возможно теперь такая ситуация будет возможной
Цитата:
В тегах заказа это отражается: Уведомляем вас, что ХХХ может скорректировать или аннулировать заказы, созданные в системе. Платформа Docrobot будет информировать поставщиков об изменении статуса заказа: сообщение о корректировке или аннулировании появится в окне со списком всех заказов и будет подсвечено красным. При открытии заказа можно увидеть причину аннулирования. Для тех, кто для обмена электронными документами использует интеграционное решение, оператор будет передавать информацию о корректировке или аннулировании в специальном теге. Просим быть внимательнее при получении таких уведомлений к заказам и оперативно принимать меры. Есть торговая сеть не примет товар, поставки замедлятся, а вы понесёте финансовые потери. Пожалуйста, при возникновении вопросов обращайтесь к вашему персональному менеджеру или в техническую поддержку
Надо - сделано. Как программа это отрабатывает? При обнаружении признаков отмены заказа:
1. В файл лога (отчета) пишет, что необходимо отменить/удалить конкретный заказ;
2. Заказ в предзаказе создаётся, но не проводимый, без номера, а в основание вместо обычной информации прописывает информацию из EDI документа по аннулированию заказа. Вам нужно будет удалить/отменить отправку исходного заказа, а так же удалить этот липовый документ.
До кучи улучшена "защита от дурака"... Наткнулись, однако. Наши номера документов программа определяет автоматически по неким прописанным в настройках правилам, но возможен ввод заказов "в ручную" и делаю задание на производство исходя из всех типов заказов. Что-бы отличать эти заказы от пришедших с EDI операторы не пишут номер и ставят признак "непроводимый". Но как-то забыли поставить этот признак и программа начала нумерацию с 1... Сейчас программа игнорирует все признаки и продолжает нумерацию с последнего номера большего № 2, т.е. по возможности игнорируя липу
█ 14.10.2024 11:18
Сегодня вспомнилась ситуация из лета. Один бизнесмен захотел торговать с Х5 через EDI. До меня задача дошла из третьих рук, а когда "взад" послал резюме, что это дорого, долго и процесс внедрения непрерывен меня, как обычно "обвинили" в плохой компетенции. Ну и хрын с ними, когда тот чел обратился к франчам они ему "зарядили" 1.5 ляма и 4 месяца... + конечно сопутствующие траты на "1С". Снова обратился по моей "аналитической" записке, где рекомендовал работать пока через веб интерфейс с небольшими уточнениями... Вылечили, удалив кривой файл из списка входящих документов...
А вспомнилось из-за "новой" и чудной ошибке... Вылет программы по ошибке и не принимает доки подтверждения заказов. Пытаюсь открыть файл посылки через EDGE, доступный у клиента:
Послали файлы мне, посмотрел место сбоя - ничего не понял, прога нормально "отработала", но вылетела по ошибке:
Открыл приходящий файл через Notepad++ и понял суть - пришел нормально читаемый редакторами и программой файл, т.е. "законченный", но информация обрезана аккуратно по серёдке - любопытно, т.к. такие же могут приходить по любой системе ЭДО?
А вспомнилось из-за "новой" и чудной ошибке... Вылет программы по ошибке и не принимает доки подтверждения заказов. Пытаюсь открыть файл посылки через EDGE, доступный у клиента:
Послали файлы мне, посмотрел место сбоя - ничего не понял, прога нормально "отработала", но вылетела по ошибке:
Код:
-------------------- Internal Error Handling Information --------------------- Subsystem Call ....: BASE System Code .......: 2022 Default Status ....: .F. Description .......: Argument error Operation .........: ALLTRIM Arguments .........: [ 1] = Type: U Involved File .....: Dos Error Code ....: 0 Trace Through: ---------------- ALLTRIM : 0 in Module: PWRKDECADV : 2,186 in Module: ZLE.PRG PDECADV : 1,943 in Module: ZLE.PRG POBMEN : 325 in Module: ZLE.PRG MAIN : 312 in Module: ZLE.PRG
Код:
<?xml version="1.0" encoding="UTF-8"?> <RECADV> <NUMBER>161914</NUMBER> <DATE>2024-10-13</DATE> <RECEPTIONDATE>2024-10-13</RECEPTIONDATE> <ORDERNUMBER>7527219770</ORDERNUMBER> <ORDERDATE>2024-10-11</ORDERDATE> <DESADVNUMBER>9372</DESADVNUMBER> <BUYERACTNUMBER>5999421715</BUYERACTNUMBER> <HEAD> <SUPPLIER>4607124669999</SUPPLIER> <RECIPIENT>4607124669999</RECIPIENT> <BUYER>4606038001260</BUYER> <SENDER>4606038001260</SENDER> <DELIVERYPLACE>4606038210419</DELIVERYPLACE> <EDIINTERCHANGEID>32494029</EDIINTERCHANGEID> <PACKINGSEQUENCE> <HIERARCHICALID>1</HIERARCHICALID> <POSITION> <POSITIONNUMBER>1</POSITIONNUMBER> <PRODUCT>4607124662167</PRODUCT> <PRODUCTIDBUYER>3949009</PRODUCTIDBUYER> <ORDERQUANTITY>248.000</ORDERQUANTITY> <ACCEPTEDQUANTITY>248.000</ACCEPTEDQUANTITY> <ACCEPTEDUNIT>PCE</ACCEPTEDUNIT> <PRICE>90.0000</PRICE> <PRICEWITHVAT>108.0000</PRICEWITHVAT> </POSITION> <POSITION><POSITIONNUMBER>2</POSITIONNUMBER> <PRODUCT>
Часовой пояс GMT +3, время: 11:39.
Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.