Идея освободить клиентов от необходимости прибегать к услугам операторов электронного обмена звучит достаточно крамольно. Тем не менее, вовсе не исключено, что развитие систем сканирования и распознавания текстов, со временем, приведет к чему-то подобному. А формат PDF для EDI станет чем-то вроде ключа к конвергенции разных способов электронного обмена.

Сегодня многими уже осознается потребность в сведении различных форм и способов электронного документооборота и обмена данными в нечто, выглядящее единым и целостным в глазах клиента. Традиционный, давно проторенный путь — это вывод на рынок новых видов и классов ИТ-решений с интригующими заказчиков наименованиями: EDI, ECM… А теперь еще и EIM. И даже, пока еще где-то на горизонте, но зато уже вполне отчетливо мелькает отдельный класс решений, предназначенных исключительно для e-invoicing.

Крупных вендоров, поддерживающих такое вот постоянное “положение” новых сущностей, можно понять. Очередная, придуманная для них маркетологами аббревиатура выходит все более красивой, убедительной и всеобъемлющей. И помогает вендорам выгодно позиционировать свои новые ИТ-решения относительно предыдущих разработок конкурентов. Которые тоже, может быть, не так уж и плохи, но начинают выглядеть на фоне появления все новых и новых подходов, звучных концепций и инновационных приложений несколько устаревшими. И даже старомодными.

Поэтому оставим в стороне вопрос о том, как “это” правильно именуется. Ведь все равно через год появится новое название. Вернемся к сути дела.

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

Стандартный «заход» EDI-провайдера к обозначенной выше теме изложить достаточно просто. PDF-документ удобен человеку, но не особенно удобен машине. Поскольку, вообще говоря, не предполагает автоматической обработки. Что и отличает PDF от стандартных EDI-сообщений в XML или аналогичном ему формате. Значит выбор очевиден. PDF — это временная мера на пути к полноценному EDI-обмену.

С другой стороны, бездна, отделяющая PDF от XML, не так уж и глубока, как кажется. Во-первых, такие форматы как PDF/A-3 дают возможность, — незаметно для непосвященного в технические тонкости пользователя, — вложить, в PDF-документ дополнительную информацию. Например, XML-файл, дублирующий содержимое этого документа в структурированном виде. Стандартизируйте эту информацию и вы получите некий гибрид, равно пригодный для ручной и для автоматической обработки. Во-вторых, если задуматься, то и сам по себе PDF, — даже безо всяких, хитрым способом приложенных к нему файлов, — это тоже структурированная информация, легко поддающаяся стандартизации. Вопрос лишь в том, насколько трудоемок и быстр процесс ее извлечения.

Некая невидимая грань, отделяющая целесообразное от нецелесообразного, проходит через трудоемкость превращения исходных данных в структурированную информацию, пригодную для автоматической обработки. Сразу выделим тот факт, что различие тут вовсе не принципиальное, а чисто технологическое. Появятся новые мультиформатные, безошибочно работающие ИТ-решения — и пробема выбора между XML и PDF станет неактуальной. Поскольку все рядовые пользователи попросту выберут PDF.

Понятно, что распознавание документа требует вычислительного времени. Однако важным это становится лишь на больших и регулярных потоках однотипных документов, которые мы наблюдаем, например, в ритейле. Гораздо более критичным, чем лаг по времени, является то, что бумажный документ может быть распознан с ошибками. Это означает, что для окончательной верификации извлеченного из него файла потребуется участие человека. Ведь случайно добавить лишний нолик в платежку, по вине программы, никому, наверное, не хочется.

В случае с бумажными документами, технологическая цепочка снятия информации с носителя получится наиболее длинной — сканирование, распознавание, ручная выверка и коррекция и т.д. С документами, изначально созданными в PDF, устраняется самая обременительная часть проблемы — отпадает необходимость привлечения людей для рутинной корректорской работы, проверки правильности распознавания сканированного документа. Даже если мы имеем дело с «обычным» PDF типа картинки, не содержащем “внутри себя” файла с информацией в XML (или, хотя бы, текстового слоя), то распознать его все равно не составит сегодня особого труда. Ведь самый проблематичный этап со сканированием написанного на (помявшейся, порвавшейся, исчерканной) бумаге, в случае с уже готовым PDF, отпадает.

Да, скорость обработки PDF будет ниже. Но построив EDI на базе PDF мы получим весьма важные преимущества. EDI обмен станет абсолютно понятным для человека на уровне отдельных транзакций. Формат EDI-сообщений перестанет разительно отличаться от формата повседневно-привычных электронных документов, с которыми почти каждый сталкивается на работе.

EDI в формате PDF станет универсальным инструментом для компаний любого размера. Офисные документы можно будет обработать “продвинутым” EDI-способом дополнительно к обычному. Но это будет уже не жесткая обязанность, а некая дополнительная возможность. Отметим, что в похожем духе развивается сегодня, например, европейский проект ZUGFeRD В данном ключе можно попытаться как-то переосмыслить и опыт налаживания электронного обмена в такой стране как Португалия. Дело в том, что путем ведущейся там сертификации ERP и бухгалтерских систем можно, теоретически, добиться многого. Например, можно жестко регламентировать электронные счета-фактуры, генерируемые всеми такими системами. Причем проделать все это возможно вплоть до малейших деталей — скажем, вплоть до выбора строго определенного шрифта, оптимального для целей OCR.

«Ставит» ERP в тексте лишний пробел перед названием контрагента? Значит на этом все — сертификат у данной ИС отзывается. Инвойсы, оформленные такой «неправильной» ERP, становятся непригодными для бизнеса. Всего этого, в масштабах целой страны, согласитесь, довольно сложно добиться, применяя другие, не столь жестко-административные способы.

Понятно, что после такой “глубокой” стандартизации внешнего вида PDF-документа, его конвертация в EDI формат будет делом довольно быстрым и абсолютно безошибочным. Даже если отбросить при этом всевозможные «нечеловекочитаемые» ухищрения с двумерными штрих-кодами. Участия человека в дополнительных выверках не потребуется, даже если такой, тщательно оформленный «машиной» электронный документ напечатать на бумаге. Созданные сертифицированной ИС PDF и EDI-сообщения станут фактически полностью эквивалентными — с задержкой в несколько секунд, необходимых для того, чтобы EDI-конвертор отработал очередной документ и выдал сообщение в формате EDIFACT.

Тема электронных счетов-фактур, по идее, не должна привлекать к себе отдельного, особого внимания — если исходить лишь из одной только строго-научной и безупречно логичной классификации. Однако мы наблюдаем сейчас, скорее, обратное. E-invoicing растет во всем мире опережающими темпами. И давно превратился в самостоятельное направление, в обособленный сегмент рынка со своими ведущими игроками, новостными порталами, саморегулированием и отраслевыми конкурсами.

Буквально все, включая процесс стандартизации, идет сейчас в сфере e-invoicing чрезвычайно быстро. Надо всем этим осталось лишь немного поработать маркетологам. После чего e-invoicing , пожалуй, окончательно станет новой ИТ-отраслью. Ведь главным критерием для выделения нового направления в составе прежних служит сегодня емкость рынка и потребительский спрос, а вовсе не мнение маститых экспертов из академий наук.

Чтобы EDI стал по-настоящему удобен и экономически оправдывал себя, сегодня нужна ERP, дорогостоящая интеграция, ощутимые потоки сообщений. Что востребовано лишь относительно небольшим количеством действительно крупных компаний-заказчиков.

Электронный обмен на базе PDF будет гораздо более гибким инструментом. И каждый предприниматель сможет выбрать, как лучше обработать поступивший к нему инвойс — автоматически или же вручную. Охват отраслей EDI-технологией значительно ускорится по мере того, как у компаний СМБ будет возникать естественная, а не навязываемая им потребность в автоматизации документооборота. Это критично, поскольку низкий процент охвата СМБ технологией EDI сдерживает сейчас весь рынок электронного обмена в целом.

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

В такой стране, как Бразилия, водитель не сможет отправиться в рейс, пока не зарегистрирует через EDI-сеть предстоящую перевозку в облаке регулятора. Убеждать ГИБДД в том, что EDI нужен не только в Бразилии, но и в нашей стране, можно очень долго.

Если же EDI-обмен будет организован в формате PDF, то в дорогу шоферу будет достаточно взять флешку с накладной, заверенной ЭП. Прочитать и проверить такой документ в полевых условиях на любом мобильном устройстве (заодно сохранив себе копию для отчетности) станет достаточно просто. Способ, может быть, дешевый и сердитый, но довольно эффективный, вполне отвечающий духу времени.

По мере взросления отечественной EDI-технологии и развития каналов связи в регионах, инспектору можно будет навести справки о перевозке в облаке ГИБДД или ФНС, отправив туда PDF с ТТН на дополнительную проверку. И мы, наконец, догоним Бразилию и даже в чем-то, может быть, перегоним. Оставив этой развивающейся стране, пожалуй, лишь пальму первенства по числу диких обезьян, живущих в дремучих джунглях.

В завершение остается заметить, что PDF по факту стал, пожалуй, наиболее распространенным сетевым форматом для обмена документами. Однако понятно, что на роль нового “человекочитаемого”, “офисного” формата для EDI могут претендовать многие другие. Например, форматы файлов программы Excel.

Ключом для верного выбора формата в целях EDI должна стать конвергенция способов электронного обмена, устранение “полифонии” форматов: отдельных — для человека, отдельных — для компьютера. Таким образом, самым главным аспектом такого рода конвергенции будет предоставление возможности бизнесу, — безо всяких искусственных усилий и ухищрений, — использовать файлы одного и того же типа и в автоматизированных, и в неавтоматизированных бизнес-процессах. Отдав ему право сделать окончательный выбор. И, заодно, устранив оставшиеся сомнения и иррациональные страхи по поводу отработанности и надежности технологии EDI с 40-летней историей.

Идею вернуться в “офисные” форматы после того, как было столько всего проделано на ниве XML, можно назвать крамольной. Впрочем, подобного рода аргументы звучали и по поводу облаков, которые так и не удалось качественно реализовать и «довести до ума» в эпоху мейнфреймов.

Новое — это хорошо забытое старое. И в новом римейке 2014-го года фильма RoboCop, робот-полицейский уже действует, будучи подключенным к облаку. А «автоматизировавшие» его медики наблюдают за каждым его шагом на стезе правопорядка из ситуационного центра.

Если делать аналогичный римейк для фильмов про Терминатора, то он, возможно, должен быть следующим. Машины начинают обмениваться вредоносными сообщениями с целью низвергнуть породившее их человечество с его пьедестала. Однако, поскольку весь этот обмен идет в формате PDF, то простая, скажем, пенсионерка из штата Аризона легко перехватывает и читает все, чего там компьютеры самостоятельно понаписали друг другу. И срывает зловещие планы роботов, позвонив по номеру 911. PDF, согласно только что придуманному нами сценарию, спасает человечество, и мы получаем очередной хэппи-энд.