Pull to refresh

Comments 12

РОман, а обмены у вас на 1С реализованы?
Да, это все на 1Се написано, но суть не в платформе
UFO just landed and posted this here
С одной стороны это не бесплатно, с другой поставщиков «прогибать» под единый формат все равно нужно. Большие EDI имеют смысл, когда поставщиков и производителей много с обеих сторон.
спасибо, хороший пример для «семь раз отмерь — один отрежь»
Интересно какая у Вас номенклатура приобретаемых товаров?
Тут бывают изредка обсуждения сложности такого обмена с разными системами данными по номенклатуре (прайсы, заказы и т.п.). И собственно основная проблема это идентификация товаров. Как сопоставить что две единицы которые имеют своершенно разое наименование это одно и то же. А очень похожие с точки зрения всяких там индексов сравнения намиенования, которые из 65 символов отличаются ровно одним символом — это совершенно разные номенклатурные позиции. С этим как Вы разбираетесь?
У нас жесткие критерии, никаких индексов сравнения. Гораздо интереснее, что иногда даже человек не может сказать две запчасти, лежащие перед ним — это одна позиция или нет. Напр. какой-то электронный датчик на корпусе которого написано Bocsh 12345 может быть двумя позициями, в зависимости от того, упакован он в пленочку Volkswagen или Skoda (а пленочка, понятное дело может быть потеряна).
По поводу аптек, часто с ними работаем, у них тоже зоопарк, например, есть фармхаб и фарм см, плюс ряд сетей аптек написало свои обмены на основе упомянутых систем, которые представляют из себя dbf файлы с самой разнообразной структурой.
Я как увидел XSLT затаил дыхание, это и правда очень мощная и древняя магия:)
Предстоит мне скоро решать похожие проблемы, боюсь там будет ужас-ужас и эксель файлы.
UFO just landed and posted this here
про структуру: в строгом понимании вы конечно правы, но в рамках повествования это был самый удачный термин, который я смог найти.

про эволюцию в 52-й формат: я бы не сказал что есть риск перехода от 51-го к 52-му формату. есть перспектива развития 51-го формата — это естественный процесс, нужно только следить, чтобы эволюция проходила с учетом обратной совместимости.

про эволюцию поставщиков: если поставщик захочет изменить формат — это, в общем случае, ничем не будет отличаться от подключения нового поставщика.

про форматный конвертер: наберите в гугле «xml — json преобразователь» — первая ссылка будет на то, как это делается.

про конфликты: не совсем понятно что имеется ввиду, если отказ поставщика принять заказ — то ответ поставщика также принимается, конвертируется и отдается в ERP.

Общая концепция возражений не вызывает, но утверждение "Для этого лучше всего подходит XML" ничем не обосновано. Правильнее было бы сказать "В рамках нашего стека технологий лучше всего подошёл XML" иначе это выглядит как "Слово "молоко" лучше всего говорить на испанском языке :)"


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

Sign up to leave a comment.

Articles