Автоматизация документооборота для B2B: от заказа до подписи

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

Передача самих сообщений о заказах и отгрузках разобрана в статье «EDI: что это и как подключить». Здесь о документах: откуда они берутся, куда уходят и как не потерять связь с учётом.

Цепочка документов: от договора до акта сверки

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

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

Три места, где документы теряются

Потери почти всегда на стыках, а не внутри систем.

• Между учётом и оператором ЭДО. Документ сформирован в 1С, но файл выгружают вручную и отправляют отдельно. Статус подписи остаётся в личном кабинете оператора, и в 1С его никто не видит.
• Между бумагой и учётом. Водитель привозит подписанную накладную, её сканируют, складывают в папку и забывают привязать к отгрузке. При споре ищут по дате и фамилии.
• Между почтой и заказом. Клиент прислал подписанный акт письмом, письмо ушло в личный ящик менеджера, и бухгалтерия не знает, что документ получен.

Автоматизация на каждом стыке сводится к одному: документ должен знать, к какому заказу он относится, а учёт — знать, в каком состоянии документ.

Единый ключ: как связать заказ, отгрузку и документ

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

Что делает ключ полезным

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

Условный пример: заказ покупателя разбит на две отгрузки, вторая задержалась. У заказа один ключ, у каждой отгрузки свой номер, и на каждую выпущен отдельный УПД со ссылкой на заказ. Когда клиент подписал первый документ, а второй ещё в пути, учёт показывает «подписан наполовину», и менеджер не гадает, закрыт ли заказ. При общей папке со сканами то же самое пришлось бы выяснять звонками.

Порядок событий важен

Закрывающий документ формируется после проведения отгрузки или закрытия работ, а не по заказу. Иначе клиент получает документ с количеством, которое ещё не принял. Правило «документ только после проведения» записывается как условие в процессе, а не держится в памяти бухгалтера.

Статусы подписи: что приходит обратно и что с этим делать

Документ отправлен — это только полдела. Дальше он проходит несколько состояний, и каждое должно оказаться в учёте.

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

Бумага и сканы: что делать с документами, которые не электронные

Часть партнёров всегда будет работать на бумаге или присылать сканы. Цель — не заставить всех перейти, а чтобы бумага не выпадала из цепочки.

1. Привязка при сканировании. На документе есть номер заказа или штрихкод, система читает его при загрузке и сразу кладёт файл в нужную отгрузку.
2. Распознавание реквизитов. Номер, дата, сумма и контрагент извлекаются автоматически. Для сканов и фотографий используется распознавание документов на ваших серверах, как на странице «Распознавание документов».
3. Проверка человеком. Если уверенность распознавания ниже порога или данные не сошлись с заказом, документ уходит оператору на проверку, а не в учёт.
4. Загрузка в учёт. Подтверждённые данные записываются в 1С. Как это устроено, описано на странице «Загрузка документов в 1С».

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

Сверка: как находить расхождения до спора

Расхождения появляются не в акте сверки, а раньше: когда отгрузка проведена одним числом, а принята другим. Автоматическая сверка делает три вещи.

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

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

Архив, права и срок хранения: что решить заранее

Автоматизация создаёт цифровой архив, и вопросы к нему надо решить до загрузки, а не после.

• Срок хранения. Его определяют закон и ваш регламент, вопрос для бухгалтерии и юриста. Система должна уметь хранить и удалять по сроку.
• Права доступа. Менеджер видит документы своих клиентов, бухгалтер — все, внешний аудитор — выбранные. Права проверяет сервер, а не интерфейс.
• Целостность. Подписанный файл и подпись хранятся вместе и не меняются. Исправление создаёт новую версию.
• Поиск. По номеру заказа, договору, клиенту, периоду и статусу. Если документов много, добавляется поиск по тексту, как в ассистенте по документам.
• Резервные копии. Копия, которую ни разу не восстанавливали, не считается копией.

Персональные данные граждан России обычно должны храниться на серверах в России. Юридические вопросы хранения решает юрист заказчика, технические меры закладываем мы.

С чего начать: порядок внедрения

1. Один тип документа и один-два партнёра. Обычно закрывающие документы, потому что их много и они повторяются.
2. Таблица цепочки. Как в начале статьи, только по вашим документам: создаётся, лежит, уходит, подписывается.
3. Общий ключ. Проверьте, что номер заказа дойдёт до документа и обратно.
4. Возврат статусов. Подключите получение статуса подписи в учёт и покажите его менеджеру.
5. Напоминания и очередь ошибок. Просроченные и отклонённые документы должны сами приходить к ответственному.
6. Бумага и сканы. Только когда электронная часть работает, иначе вы автоматизируете то, что можно убрать.
7. Сверка. Последний шаг: она опирается на все предыдущие.

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

Что делаем мы и с чего начать

Начинаем с обследования: 200 000 ₽ и 2–3 недели за один обмен, 350 000 ₽ и 3–4 недели, если систем и партнёров несколько. На выходе таблица цепочки документов, схема ключей и статусов, список того, что автоматизируется в первую очередь, и вилка бюджета. Стоимость вычитается из первого этапа, если продолжаете с нами.

Дальше пилот на одном типе документов, вывод в эксплуатацию и сопровождение; остановиться можно после любой ступени. Мы связываем ваш учёт с оператором ЭДО и строим очередь ошибок, но не выступаем оператором, не выдаём сертификаты подписи и не даём юридических заключений. Цены и сроки на странице «Тарифы», описание услуги — на странице «Разработка EDI-интеграций для B2B».