Проверка экспортных документов: что можно автоматизировать

Какие документы входят в экспортный пакет

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

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

Часть сведений уже существует в CRM, 1С или других рабочих системах. Чем меньше данных сотрудник переносит вручную между документами, тем меньше риск расхождений. Общую схему экспортного процесса можно сначала зафиксировать по подходу из статьи об автоматизации экспортных операций.

Какие проверки можно формализовать

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

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

Что ИИ может подсветить, но не должен утверждать сам

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

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

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

Пример: проверка реквизитов и условий поставки

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

1. Из документов извлекаются реквизиты покупателя, валюта, суммы, даты и условия поставки.
2. Реквизиты сравниваются с эталонной карточкой контрагента.
3. Суммы и валюта сопоставляются между счётом, спецификацией и сделкой.
4. Условие поставки сравнивается с согласованным значением и шаблоном формулировки.
5. Система формирует результат: что совпало, где обнаружено точное расхождение и какие места требуют ручной оценки.

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

Как хранить правила проверки

Правила не стоит прятать только в коде или системной инструкции ИИ. Бизнесу нужен понятный реестр: что проверяется, откуда берётся эталон, какое отклонение допустимо, насколько правило критично и кто отвечает за исключения.

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

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

Как встроить согласование

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

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

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