Эдо

Переход на юридически значимый документооборот (ЮЗДО) при всем влиянии на эффективность бизнеса остается сложной процедурой: нужно учесть многие нюансы, в том числе законодательные, перенастроить процессы, согласовать действия с контрагентами. Важна тщательная подготовка самостоятельная или с помощью опытных консультантов.

Меня зовут Владислав Степанов, я специализируюсь на внедрении и консалтинге в сфере автоматизации документооборота в ИТ-компании КОРУС Консалтинг. Хочу поделиться опытом и рекомендациями по переходу компаний на электронный документооборот и рассказать о нюансах: проблемах роуминга, типизации, маршрутизации, комплектности и обработки документов.

Для начала определимся с терминологией. Электронный документооборот (или ЭДО) это любой обмен цифровыми копиями документов как внутри компании, так и вовне. Как только штат организации преодолевает условную отметку в 100+ человек, потребность в ЭДО начинает ощущаться все более остро. Разница между обычным документооборотом и юридически значимым (ЮЗДО) в характере файлов, которыми обмениваются стороны. В последнем случае документ можно привлекать для доказательства прав. Таким образом, ЮЗДО это разновидность ЭДО.

Использование автоматизированных систем для ЮЗДО в бизнесе постепенно увеличивается несмотря на ряд объективных сдерживающих факторов. Полностью перейти на электронный документооборот мешает отсутствие законодательных норм для некоторых типов документов, не прописано разделение зон ответственности при использовании электронной подписи (ЭП).

Есть и хорошая новость: определенные государственные инициативы (в частности, вступившие в силу с 1 января 2020 года поправки в 63 ФЗ об использовании ЭП), распространение удаленной работы, рост количества мобильных сотрудников и растущая цифровая зрелость бизнеса стимулируют переход на ЮЗДО.

Насколько глубоко компания распространит ЮЗДО на свои бизнес-процессы, зависит от многих факторов. В крупных организациях, по нашим оценкам, до 75% документов на данный момент могут быть полностью и успешно оцифрованы, но на практике этот показатель гораздо ниже. Часть контрагентов по-прежнему не хочет переходить в цифру, хотя среди крупных игроков доля выбравших ЭДО достигает 30-50%, а в некоторых случаях даже больше. Тем не менее даже эти контрагенты зачастую предпочитают использовать ЭДО для обмена только какой-то частью документов, например, финансовой первичкой. А некоторые, наоборот, готовы обмениваться по ЭДО только полными комплектами.

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

Выбор системы для ЮЗДО

Платформой для автоматизации документооборота могут выступать разные внутренние системы: единая ECM (Enterprise Content Management) или несколько решений (СЭД/ECM, ERP и др). Еще на стадии выбора учитывайте возможности масштабирования ЭДО в будущем. Инструментария уже установленной в компании системы электронного документооборота, которая всех полностью устраивает, в будущем может не хватить для какого-то определенного процесса. Сейчас он не используется, но как только потребность возникнет, придется выбирать дополнительное решение, а это сопряжено с новыми затратами как на лицензии, так и на поддержку. Поэтому систему сразу необходимо примерить на вырост.

При выборе одной или нескольких ИТ-систем стоит учесть, что при ЮЗДО у каждой должны быть установлены свои коннекторы к операторам ЭДО, внешним и внутренним центрам хранения сертификатов подписей. Необходимо оценить, какие именно инструменты потребуются и, исходя из этого, очертить круг подходящих решений. Вполне возможно, что для полноценной реализации ЮЗДО вам может потребоваться не одна СЭД/ECM-система, но и ERP, CRM и другие, в зависимости от процессов.

Выбор оператора ЭДО

Сегодня на рынке представлено не менее двух десятков операторов ЭДО, которые предлагают услуги маршрутизации внешних документов: Диадок, СБИС, СФЕРА Курьер, Такском, Калуга Астрал, Синердокс и другие. С точки зрения взаимодействия и выбора подходящего SLA, проще работать через единого оператора ЭДО. Но так только кажется.

На самом деле контрагенты компании обычно работают с разными операторами ЭДО. Чем больше у бизнеса партнёров, с которыми у него налажен документооборот, тем больше провайдеров ему придется вовлечь. Для обмена между операторами существует роуминг, но на данный момент в его реализации есть ряд сложностей.

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

• Роуминг между операторами может занимать много времени, так как тех, кто подписал в рамках инициативы ассоциации разработчиков и операторов систем электронных услуг (РОСЭУ) интеграцию в один клик, пока немного. У прочих провайдеров настройка может растянуться на 10-15 дней и даже несколько месяцев.

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

• Существуют проблемы с наименованием документов (при роуминге используется транслитерация).

• У каждого оператора свое понимание того, как определять документы в полуформализованном виде (если для них нет установленных ФНС форматов). У кого-то существует единая сущность договора, у других несколько. Соответственно, может теряться типизация документов при передаче между провайдерами.

Не все операторы ЭДО работают с пакетами документов, которая необходима многим крупным компаниям.

Работа с контрагентами

На практике компаниям приходится взаимодействовать с несколькими операторами ЭДО, но их круг должен быть ограничен разумными рамками. Пока на рынке не существует универсального коннектора, который позволил бы подключиться к любому из них. Однако проблему работы с несколькими операторами ЭДО все же можно решить: например, с помощью отдельного микросервиса интеграции, шины данных, доработки СЭД как хаба и т.п.

Чтобы сделать выбор, нужно рассмотреть тех провайдеров, с которыми работает большинство контрагентов компании. Как правило, это СБИС, Диадок и Такском. Такую информацию даст опросник, рассылаемый клиентам/поставщикам: его можно составить как своими силами, так и с помощью консалтинговой компании. Он поможет выяснить, готов ли партнер перейти на ЭДО, что ему мешает и как можно помочь.

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

Крупные организации, как, например, Сбер или Магнит, могут себе позволить переход на ЭДО в уведомительном порядке, просто сделав его обязательным условием с оговоренной даты. Но если ваше влияние на рынке не столь велико, нужно будет договариваться с контрагентами и выделить на это время.

Нюансы работы с документами: типизация, маршрутизация, комплектность

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

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

Еще один важный вопрос связан с комплектностью первичных документов, присланных контрагентами. Речь идет о возможности разбирать комплекты, чтобы потом передавать их в определенные ИТ-системы, и собирать их из нескольких систем в единый пакет, подписывать и отправлять вовне.

Третья группа вопросов связана с большим объемом документооборота с контрагентами. Для них может быть реализована техническая подпись. Кроме того, важно прогнозировать рост объема документов в перспективе для того, чтобы заранее определить потребность в ресурсах для их обработки и хранения. Этот параметр также влияет на выбор класса систем ECM и расчет потенциальных затрат.

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

Кроме того, в процессе перехода на ЭДО может возникнуть вопрос с остаточными бумажными документами. Он решается с помощью систем для работы с архивом Они позволяют автоматизировать процессы сканирования и штрих-кодирования,

оцифровки и хранения внутри ИТ-системы всего архива. Это может быть сделано как в самой компании, так и передано на аутсорсинг.

---

Несмотря на большое количество нюансов внедрение ЮЗДО в компаниях продолжается. Работа с внешними консультантами позволяет сделать такой переход максимально безболезненным, учесть все тонкости и факторы. Если в организации уже есть ЭДО и/или ЮЗДО, специалисты помогут сделать их использование более эффективным и масштабировать решения.

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

Ведь в конечном счете задача перехода на ЮЗДО состоит не в том, чтобы усложнить процессы в бизнесе, а упростить их, ускорить прохождение процедур, способствовать росту операционной эффективности и прибыли. И все эти возможности заложены в саму идею ЭДО, но работают только в умелых руках.

В последнее время все чаще слышно про RPA или Robotic Process Automation. С одной стороны, говорят о его эффективности для банковского сектора и крупных корпораций, с другой про применимость и в среднем, и даже в малом бизнесе. На днях на Хабре вышла обзорная статья про интеллектуальную обработку документов с помощью RPA и мы подумали, что хабравчанам также будет интересен рассказ про наш опыт реализации такого проекта в деталях.

Он был выполнен для одного из крупнейших ритейлеров в РФ и Европе. Его магазины можно найти везде: в одной только Москве и области их десятки, а по всей России больше сотни. Это фантастическое количество товаров, поставщиков, поставок и связанного с ними документооборота, которого с каждым месяцем становится больше и больше.

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

Идеальный сценарий для RPA! А для нас отличная возможность показать, как он грамотно и продуктивно реализуется.

С чем предстояло работать

Итак, нам предстояло создать робота, который будет трудиться в одном из звеньев стандартной рабочей схемы любого ритейла. Схема очень простая и расхожая: ритейлер формирует заказ на поставку товаров в свои магазины, после его доставки поставщиком производится приемка и после обработки документов оплата.

Описанные выше проблемы возникали на этапе обработки документов. На стороне заказчика каждый день на эту задачу тратилось 72 часа. Это 9 полноценных бухгалтерских рабочих дней! Роботизации этого проекта от нас и ждали.

Подробное описание процесса сверки, с которым мы должны были работать:

Как видите, большая часть этого процесса механическая рутина. Идеальная цель для автоматизации! Однако классический путь доработки ERP-системы с интеграцией ее с СХД был заказчику закрыт: бэклог команд, занимающихся сопровождением и развитием этих систем, был расписан на месяцы вперед, а доработка системы сложна и дорога. В общем, классический кейс а давайте лучше робота: с ним не нужно будет дорабатывать информационные системы.

В качестве платформы роботизации был выбран UiPath: абсолютный лидер на рынке РФ и один из лидеров глобального рынка RPA, кроме того, уже обкатанный в головном офисе нашего партнера в Европе.

Чего мы хотели от робота?

У этой роботизации было несколько основных и вспомогательных целей. Основные цели были достаточно стандартные: процесс нужно было автоматизировать не менее чем на 90% (звучит впечатляюще, но для мира RPA это норма), сократив затраты на него по сравнению с ручным трудом. Второстепенные цели были любопытнее:

выявить аномальные расхождения, которые человек может пропустить;

снизить риск ошибки специалистов по товарному предложению;

предотвратить расширение штата бухгалтеров при увеличении объемов поставок;

ускорить проведение оплат поставщикам.

На основе всего этого мы поставили перед собой такие задачи:

разработать роботов, которые будут выполнять работу бухгалтеров;

разработать сервис их взаимодействия с бухгалтерами и СТП; не допускающий использования вил и факелов

реализовать процесс извлечения данных из сканов бумажных документов;

интегрировать роботов с системой распознавания бумажных документов.

Ну и как же без дополнительных требований от заказчика:

runtime-лицензии роботов должны использоваться максимально эффективно. Лишние действия, задержки все это должно быть сведено к минимуму;

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

отсутствие у роботов дублирования функций;

приоритизация срочных задач (например, отчетов);

минимизация поддержки решения после ввода в эксплуатацию;

автоматический онлайн-расчет окупаемости (дэшборд в Confluence);

и еще, чтоб участников процесса письмами/уведомлениями не спамило.

Подход к проблеме и проект

С самого начала заказчику было ясно, что автоматизировать процесс на 100% невозможно, да и не нужно: не все бумажные документы нормально распознаются, не во всех бумагах будут артикулы для сопоставления с заказами ритейлера, поставщики наверняка будут допускать ошибки Поэтому человека мы из процесса не исключали: он в любом случае должен был остаться в роли супервайзера, а также для решения нестандартных задач.

Итак, сформулировав процесс AS-IS, мы декомпозировали его на подпроцессы для роботизации. Получилось вот так:

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

Однотипные задачи мы сразу стали собирать в совместную обработку, помня о требовании об эффективном расходовании runtime-лицензии. На практике это значило, что если нужно выгрузить из ЭХД 10 доков, то открывать его мы будем 1 раз, выгружать нужное и 1 раз закрывать, а не открывать и закрывать для каждого документа.

Архитектуру системы полностью определило решение формировать списки задач для каждого роботизируемого процесса в СУБД (MS SQL). Тем более что, как мы выяснили, отчёт из учетной системы (на базе СУБД ORACLE) можно выгружать запросом. Поэтому мы решили сделать Link к БД учетной системы и настроить Job в БД для регулярной выгрузки новых приемок, готовых к сопоставлению. Этот Job будет также анализировать полученные данные и переводить приемки на нужный этап обработки: Требует согласования с СТП, Требует выгрузки в систему распознавания, Передать в оплату и т.д.

Роботу оставалась только грязная работа по выполнению механических операций в соответствии с установленным статусом.

Что еще нужно было определить перед тем, как приступить к работе?

Архитектура распознания документов

Наш робоподопечный должен был уметь распознавать документы такое зрение ему мы сделали на известной платформе ABBYY FlexiCapture. У нее есть, во-первых, готовые шаблоны распознавания для первичных документов (мы лишь немного докрутили их под примеры заказчика). Во-вторых, она предоставляет удобный интерфейс для верификации результатов распознавания, а это экономит время тому, кто верифицирует.

В этом процессе было несколько критически важных точек: качественное извлечение табличной части документа; проверка артикулов в БД (да, номенклатура также выгружалась из БД ERP-системы); сверка суммы документов; проверка совпадения штрихкода на документе и в ERP.

В общем виде процесс распознавания получился следующий:

Формирование интерфейса

Для взаимодействия с пользователями изначально планировали использовать Jira, но затем мы приняли решение упростить интерфейс. Мы разработали собственный сервис по взаимодействию с пользователями. Если требуется согласовать расхождение, робот присылает сотруднику по товарному предложению ссылку в письме. При переходе по ней формируется web-страница, при этом проверяется, не был ли этот заказ уже согласован, а также имеет ли данный человек все необходимые права. На этой странице сотрудник выполняет согласование и вводит комментарий. После этого приемка в БД получает соответствующий статус для дальнейшей обработки роботом.

Что важно отслеживать в такой ситуации? Согласованные приемки, сотрудника, который их согласовал, а также его возможный комментарий. Но главное обязательно нужно выполнить дополнительную проверку согласования бухгалтером (в компании уже был случай, когда СТП по ошибке согласовал очень крупное расхождение в цене).

Формирование отчетности

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

Всего отчетов было реализовано четыре:

отчет по задачам бухгалтеров (требуются ли действия от бухгалтера?);

отчет главного бухгалтера (по задачам всех бухгалтеров);

общий отчет по выявленным расхождениям;

детальный отчет по расхождениям (с суммами по приёмкам и по поставщикам).

Каждый из них формируется на основе вьюхи из БД, в которой есть все необходимые данные. Роботу остается только сделать запрос, красиво и удобно его оформить и предоставить пользователю на блюдечке с голубой каемочкой.

Пользователи должны были иметь возможность в любой момент получить необходимый им отчет, для чего было решено задействовать сервис взаимодействия с пользователями. Схема получилась такая: бухгалтеры на странице сервиса открывают форму заказа отчета с его параметрами (вроде периода, за который нужно сформировать отчет), заказ получает и исполняет робот.

Формирование графиков в Confluence

Помимо отчетов, робот также должен был строить real-time графики окупаемости самого себя. Для этого был разработан набор представлений в БД, в которых рассчитываются ключевые метрики робота. Методология расчета метрик включает в себя все затраты на роботизацию процесса, в том числе стоимость лицензий, серверов, стоимость наших услуг, а также зарплату бухгалтеров, ведь полностью мы их не исключили из процесса. Для отображения графика на странице в Confluence используется плагин Database Query.

С какими трудностями мы столкнулись

Если и бывают проекты, которые проходят без сучка и задоринки, то редко и наша роботизация не стала исключением. В процессе мы столкнулись с несколькими затруднениями в реализации задуманного и решили их.

Проблемы при заказе отчетов как сделать так, чтобы робот выполнял приоритетные задачи раньше других?

После реализации персонализированных отчетов мы столкнулись с проблемой приоритизации задач.

Каждое утро бухгалтеры начинали с того, что заказывали у робота отчеты о проделанной работе. Именно утро пиковый период работы: приемок очень много, все роботы заняты, отчеты встают в длинные очереди, пользователи ждут их очень долго, т.к. задание на формирование отчета добавлялось в общую очередь задач робота.

Для решения проблемы мы выделили срочные задачи в отдельную очередь и настроили робота на проверку наличия заданий в ней. Если такие возникают, обычные процессы останавливаются, и стартует срочный. Также было решено сделать робота-диспетчера (мы назвали его Доминатор), который запускался после каждого процесса и выбирал, какой процесс запустить следующим.

Таким образом, при наличии в очереди задач на формирование отчета, робот практически сразу брался за их выполнение.

Как заставить робота самого себя поднимать

С самого начала заказчик предупредил нас, что системы, с которыми предстояло работать роботу, нестабильны. Соответственно, ему предстояло качественно обрабатывать их ошибки.

Например, если учетная система падает во время исполнения роботом задачи, он должен через фиксированное время делать еще одну попытку. Если система остается недоступна несколько часов, робот должен писать заявку в поддержку этой системы в Jira.

В качестве основы всех процессов мы использовали Enhanced REFramework. Нас устраивали его расширенное логирование и централизованная обработка исключений.

Робот копил информацию о произошедших ошибках и выполнял соответствующие действия в зависимости от типа ошибки. В алгоритмы обработки ошибок были заложены попытки решить проблему локально, например, перезапустить текущую страницу в браузере. Если это не удавалось, то ошибка передавалась на централизованную обработку. Если ошибка повторялась 3 раза, то робот переходил к следующей приемке, а для этой устанавливался статус Завершено с ошибкой с отправкой уведомления администратору.

Переиспользование частоиспользуемых процессов (инвоуков)

Ввиду большого количества разрабатываемых процессов встает вопрос о переиспользовании повторяющихся разработок. Например, во все наши процессы входит взаимодействие с базой данных, во многие получение и отправка писем, открытие и закрытие учетных систем. Все разработанные последовательности действий, которые могут быть переиспользованы, мы собрали в отдельные библиотеки и объединили в nuget-пакеты по области их применения. Пакеты хранятся в оркестраторе и GIT, соответственно, все разработчики имеют доступ к актуальной версии.

Кастомные активности

Не обошлось без разработки собственных активностей. Например, мы не нашли в публичном доступе активностей для группировки, условного форматирования, задания размера колонок и строк в Excel. Также не было функционала, чтобы отметить письмо как непрочитанное, и других возможностей при работе с почтой Exchange. Мы разработали как свои собственные активности с нуля, так и расширили возможности уже существующих в UiPath активностей. Далее мы упаковали их в библиотеки UiPath с некоторыми общими пространствами имен, например:

работа с БД (получение данных по приемкам, по отчетам, сохранение статусов и т.д.);

работа с почтой (получение запросов от бухгалтеров, отправка уведомлений);

работа с Excel (форматирование, группировка, сортировка и т.д.);

работа с учетными системами (авторизация, проверка ошибок).

Все это используется в разных роботизируемых процессах разными роботами и хранится в Оркестраторе, оставаясь доступным для всех разработчиков.

Курьезный случай исчезновение штрихкодов

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

Этот случай очень показателен: многие думают, будто роботы могут сами принимать решения, совершать что-то незапрограммированное или даже сливать кому-нибудь на сторону конфиденциальную или коммерческую информацию. Конечно же, роботам это не интересно, и наши не исключение. Они работают по четким алгоритмам (скриптам), и любое отклонение просто невозможно, если только это не разработчик ошибся.

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

Пришлось-таки подключить команду сопровождения этой учетной системы. Мы совместно настроили расширенную трассировку процесса и уже на первом же тестовом прогоне обнаружили место сбоя. Виновником был java-скрипт на стороне учетной системы. Коллеги выпустили патч и проблема исчезла.

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

Результаты

Как мы говорили в самом начале, от нас требовалась оптимизация рабочего процесса на 90%. Как вычислить этот показатель? Для этого нужно сравнить время, которое будет потрачено на нужный процесс с роботом и без него. Мы определили, сколько занимали все составляющие роботизированной работы выгрузка актов, работа в ABBYY, составление отчетов и даже написание писем; задали резерв на обслуживание робота.

И выяснили, что с задачами, на которые штат бухгалтеров ежедневно тратил время девяти полностью занятых профессионалов, робот справляется примерно за половину одного рабочего дня (0,47 рабочего дня, если быть точным). Точный показатель 94% оптимизации. Это была победа!

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

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

В частности, прямо сейчас мы роботизируем для него два других процесса, в том числе обработку актов сверки поставщиков.

Спасибо всем дочитавшим до этого момента. Если у вас возникли вопросы, мы будем рады на них ответить!

Я индивидуальный предприниматель на УСН в сфере услуг, работаю в одно лицо. Некоторые контрагенты просят присылать им оригиналы закрывающих документов (актов).

Пользуюсь электронной почтой. За год отправляю, дай бог, 20 писем формата А5. Каждое обходится в среднем около 30 рублей. Письма отправляю обычные, не заказные. Если не дойдет, отправлю повторно, но такого еще не случалось. Мои расходы на почтовый документооборот, таким образом, составляют 20 * 30 = 600 рублей в год.

Но сейчас модно использовать ЭДО и некоторые контрагенты предлагают обмениваться документами, подписанными электронной подписью. Ну что же, я не против беречь природу и бумагу, занялся изучением вопроса.

Т.к. я программист, то кое-что понимаю в криптографии. Суть электронной цифровой подписи (ЭЦП) в том, что у вас есть закрытый и открытый ключ. Любой документ можно подписать закрытым ключом и отправить клиенту подпись, где будет содержаться сама сигнатура подписи и открытый ключ, с помощью которого можно определить, что документ действительно подписан этим ключом. Ну а действительность ключа проверить в центрах сертификации, которые по цепочке сертификатов ведут к Министерству связи РФ.

По сути, то же самое, что печать. Купил печать и можешь ставить ее на документы.

Сейчас принято, что подпись файла отправляется вместе с ним с таким же именем и расширением, как файл и еще расширением sig. Соответственно, такой набор файл + подпись получатель может проверить и если что, предъявить в суд или государственные органы, как подтверждение оригинала документа.

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

Вооруженный этими познаниями я отправился прицениваться к ЭДО. Каково же было мое удивление, когда я узнал, что ЭДО стоит от 2000 рублей, причем минимальный пакет включает 200 пакетов на отправку, что явно избыточно для меня. У меня на порядок меньше 20. Причем у всех провайдеров. Обычное ЭДО, не интегрированное с 1С.

Тогда я уточнил про ЭЦП. Она тоже стоит от 2000 рублей на год. Причем операторы не знают даже и не могут проконсультировать, как этой ЭЦП пользоваться:

Не очень понимаю, как государство собралось экономить бумагу, если мелким предпринимателям не выгодном использовать ЭДО? Какой электронный документооборот, если на пустом месте предлагают увеличить расходы предпринимателя в 3 раза?

Радует то, что в этом году налоговая планирует выдавать ЭЦП бесплатно. Тогда мелкие предприниматели смогут обмениваться подписанными документами по обычной почте, а ЭДО будет пользоваться действительно только средний и крупный бизнес, для которого такие расходы оправданы.

А после массового применения, я думаю и обычные почтовые сервисы научатся автоматически проверять sig-файлы. Вот тогда и наступит долгожданная экономия леса и разгрузка Почты России.

А вообще, давно пора внедрять sig-подпись в теги метаданных PDF-файла. При этом для хэша подписи будет использоваться только тело PDF-файла, без метаданных. Ну или все метаданные, кроме метаданных подписи. Тогда можно обмениваться уже подписанными документами прямо в PDF.

Вот это и будет ЭЦП здорового человека, а не курильщика, как это происходит сейчас.