Как ни странно, но сейчас возникают всё новые и новые вопросы при внедрении электронного документооборота (ЭДО) с покупателями, хотя часть проектов, касающихся этой тематики уже были завершены около 3-х лет назад. Наверное, сейчас эта тема всё более и более актуальна, оттого и вопросов больше 🙂
Решения, которые пришлось применять в разных компаниях, совсем разные. Где-то пришлось, как в старом анекдоте про нового русского «мучиться без полароида», где-то используя канал MSRS, но вопросы не про технологии, которые используем именно мы, вопросы про отображение документов на стороне покупателя. Надо сказать, что часть из них можно разрешить «на нашей стороне», а часть — из разряда концептуальных, хотя и их тоже стоит попытаться разрешить на «нашей стороне».
Начнём с того, что даже формализованные документы, утверждённые соответствующими распоряжениями правительства, могут по-разному отображаться в системе ЭДО. «Как так?» — спросите Вы. А я, как раз недавно получил такой вопрос от одного из моих клиентов, они пожаловались, что их адрес в УПД отображается некорректно и их покупатели жалуются. А дело всё в том, что адрес может быть задан по-разному: в одном случае так:
<АдрРФ Кварт="123" Корпус="4" Дом="5" Улица="Уличная" Город="Москва" КодРегион="77" Индекс="115000"/>
а в другом вот так:
<АдрИнф АдрТекст="115000, Москва г, ул. Уличная, дом № 5, корпус 4, офис 123" КодСтр="643"/>
В первом — с разделением на сегменты адреса, во-втором — без разделения. Правильнее — с разделением, но именно в этом случае в Диадоке адрес, заданный таким образом выглядел примерно так:
115000, г. Москва, Уличная, 5, 4, 123
то есть без указания того, что из этих цифр является домом, что корпусом, а что номером офиса. Разумеется, стоило бы обратиться с этим вопросом в Контур, но проще «на нашей стороне» изменить первый вариант отображения адреса на второй, что я и сделал. Теперь и клиент, и его покупатели довольны 🙂
И это мы говорим про строго формализованные документы, что уж говорить про документы, для которых формат XML структуры не формализован. Вот, например, недавно при переводе одного из покупателей на электронный документооборот другой мой клиент получил вопрос, что обязательный для фармацевтических компаний документ под названием «Протокол согласования цен поставки лекарственных препаратов, включенных в перечень жизненно необходимых и важнейших лекарственных препаратов» не читается. То есть он читается, но в виде XML файла, а не в виде печатной формы. Здесь сразу возникает вопрос: кому что требуется? Я стал об этом думать и написал коллегам письмо примерно следующего содержания:
Это действительно интересная тема. Практически, почти всё это время (с момента получения письма от покупателя) я искал ответ на этот вопрос. «А в чём же, собственно, вопрос, что-то не в порядке с XML файлом, который мы отправляем покупателю?», спросите Вы, а я отвечу: «Нет, с файлом всё в порядке». Просто диадок визуализирует только те документы, которые формализованы с точки зрения приказов правительства. А протокол согласования цены не является утверждённым формализованным документом, поэтому участники ЭДО могут изменять его в соответствие со своими представлениями и Контур не может создать визуальное представление подобных XML файлов. Точно так же, как и с документом под названием «Счёт». Я сам был крайне разочарован, когда отправил счёт в виде XML файла своему клиенту, а потом вынужден был досылать вдогонку PDF файл, т.к. бухгалтерия не может прочесть XML файл, это не человекочитаемый, а машиночитаемый файл. XML файлы нужны только тем получателям, у которых настроен приём информации из ЭДО в их ERP систему. Всем остальным вполне подойдут PDF файлы. Означает ли это, что мы должны одним клиентам слать XML файлы, а другим PDF файлы? Мне кажется, нет. Набор документов должен формироваться автоматически. Автоматически формировать PDF файлы в момент создания комплекта XML файлов в заданных папках не представляется возможным, по крайней мере я это не умею, но можно использовать другие визуальные форматы, например, HTML (как у обычных веб страниц). Диадок может отправлять такие файлы. Прилагаю к письму пример такого файла. Можно также создать аналогичную версию такого файла для документа «Счёт».
Остаётся спросить у коллег из Контура, как настроить коннектор, чтобы он отправлял пакет не из 4-х, а из 6 файлов: у двух документов будет по 2 файла, один – XML без визуализации, а второй – HTML – то есть визуальная версия.
Вопрос только, какую версию (XML или HTML) должен будет подписать получатель.
Дальше мысль пошла и я стал искать альтернативные пути. Одной из них может стать XSLT преобразование, чтобы при щелчке на таком XML файле, который система ЭДО не хочет визуализировать (по крайней мере бесплатно 🙂 ), этот файл открывался бы в читабельном виде, например, вот так:
А не так, как этот файл выглядит на самом деле:
Всё дело в небольшой добавке:
<?xml-stylesheet type="text/xsl" href="../ON_SCHET.xslt"?>
Это как раз то самое преобразование, которое позволяет видеть счёт на оплату, а не непонятный простому человеку код. В конце мая буду отправлять счета своим клиентам и обязательно это сделаю 🙂 Только ссылка должна быть не на файл в вышележащей папке (как в примере выше), а на файл, расположенный на сайте 🙂
Сама эта «добавка» не мешает принимающей ERP системе обработать поступивший XML файл именно как XML. Кстати, в ближайшие дни обязательно проверю это утверждение на практике, помните, я писал про обратный процесс, т.е. не про отправку файлов покупателю, а про получение файлов от поставщика.
18.05.2020: Я проверил, всё в порядке 🙂
Кстати, у меня файл с таким преобразованием открывается только в IE, в Хроме и других браузерах не открывается. А вы хотите попробовать?
В общем, если возникнут вопросы, не стесняйтесь их задать: