Бэк-офис получает три файла и видит знакомую картину: формально вложений достаточно, но закрывают ли они все требования? Чтобы ответить, нужно считать не файлы, а уникальные типы документов, сопоставленные с правилами конкретного процесса. Результат проверки — список представленных и недостающих типов, дублей и ответственных за уточнение.
Такая проверка комплектности документов отвечает на вопрос о составе пакета. Она не подтверждает юридическую силу, правильность содержания, подлинность подписи или соответствие отраслевым требованиям. Эти решения остаются за специалистом заказчика.
Какую задачу решает этот процесс
Представим сотрудника бэк-офиса: он получает заявку с несколькими вложениями и должен либо передать её дальше, либо запросить недостающее. Названия файлов ненадёжны, одно вложение может дублировать другое, а состав пакета зависит от типа сделки.
Процесс должен дать сотруднику конкретный результат:
- какие обязательные типы документов представлены;
- какие условные требования сработали;
- каких документов не хватает;
- какие файлы признаны дублями или спорными;
- кому направить единый запрос на уточнение.
Единицей контроля служит пакет одной заявки. Повторная досылка дополняет этот пакет, а не создаёт новую заявку. Граница процесса тоже фиксирована: система проверяет состав комплекта по правилам выбранного типа сделки, но не оценивает юридическую правильность содержания.
Если нужен более широкий взгляд на получение, извлечение и передачу данных, его даёт руководство по автоматизации работы с документами. Здесь разбирается более узкая операция — контроль комплектности.
Какие данные и правила подготовить
До автоматизации владелец процесса описывает входные данные и назначает ответственного за каждое правило. Если источник правила неизвестен, система не должна восстанавливать его догадкой.
| Поле | Условный заполненный образец | Источник | Кто отвечает | Статус |
|---|---|---|---|---|
| Тип процесса | Пакет к условной заявке на согласование | Карточка заявки | Владелец процесса | Обязательное |
| Ожидаемые документы | Заявление, счёт, спецификация | Утверждённая матрица | Профильный специалист заказчика | Обязательное |
| Условный документ | Приложение требуется при особом условии сделки | Утверждённая матрица | Профильный специалист заказчика | Условное |
| Полученные файлы и версии | Заявление v1, счёт v1, копия счёта v1 | Входящий пакет | Бэк-офис | Обязательное |
| Обязательные поля | Номер заявки и признак типа документа | Регламент заказчика | Профильный специалист заказчика | Обязательное |
| Срок ответа | Условная дата из карточки заявки | Правило обслуживания заказчика | Владелец процесса | Обязательное |
| Адресат уточнения | Условный менеджер заявки | Маршрут заявки | Руководитель бэк-офиса | Обязательное |
| Неясное условие | Неизвестно, нужно ли дополнительное приложение | Правило не найдено | Владелец процесса | Неизвестное |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Это синтетический образец без клиентских данных. Названия ролей и документов условны.
Разделение статусов влияет на решение:
- Обязательное должно присутствовать для каждого пакета данного типа.
- Условное требуется только при явно выполненном условии из матрицы.
- Неизвестное нельзя автоматически считать ни выполненным, ни неприменимым. Его направляют владельцу правила.
Кроме состава пакета, нужно определить признаки версии, правило поиска дублей, связь файла с заявкой и срок уточнения. У каждого правила должен быть источник, иначе сотрудник не сможет объяснить результат проверки.
Как описать ожидаемый пакет документов
Матрицу составляют для одного конкретного процесса. Нельзя смешивать в ней требования разных сделок или подразделений.
| Позиция условного пакета | Статус | Условие применения | Что означает результат |
|---|---|---|---|
| Заявление | Обязательное | Для каждой заявки этого типа | Должен быть найден один связанный с заявкой тип |
| Счёт | Обязательное | Для каждой заявки этого типа | Копии не увеличивают число представленных типов |
| Спецификация | Обязательное | Для каждой заявки этого типа | При отсутствии попадает в список уточнения |
| Дополнительное приложение | Условное | Только если в карточке указан согласованный признак | Без признака правило передают человеку |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Матрица задаёт требование к составу, но не выносит заключение о документе. Полезно разделить три проверки:
- Наличие файла. В пакете действительно есть вложение.
- Соответствие типу. Признаки позволяют отнести вложение к заявлению, счёту или спецификации.
- Проверка содержания. Профильный специалист оценивает реквизиты, условия, подписи и юридическую действительность по правилам заказчика.
Первые две проверки помогают установить комплектность. Третья относится к профессиональной проверке содержания и не должна незаметно подменяться автоматическим статусом «комплект полный».
Как сопоставить полученное с требованиями
Для каждого входящего файла нужна одна и та же последовательность:
- Установить связь с заявкой по согласованному идентификатору или передать файл человеку, если связь неясна.
- Извлечь признаки предполагаемого типа документа.
- Сопоставить тип с матрицей ожидаемого пакета.
- Проверить, не является ли файл дублем уже учтённого документа.
- Определить версию по согласованному правилу и сохранить спорный статус для проверки человеком.
Средства обработки документов могут извлекать текстовые признаки, флажки и рукописные сведения из входящего документа. Такой сценарий описан для document processing в Microsoft 365: извлечённые данные сохраняются как метаданные, используются при последующей проверке и могут передаваться в другие приложения. Но документация платформы не задаёт состав пакета конкретной компании и не подтверждает юридическую действительность документа.
OCR также не должен угадывать отсутствующий лист, подпись или целый документ. Если распознавание не позволяет уверенно определить тип либо разные признаки противоречат друг другу, файл получает статус «нужна проверка», а решение принимает сотрудник.
Дубликат тоже не равен новой позиции пакета. Его можно выявлять по согласованному набору признаков: контрольной сумме файла, совпадению содержимого, реквизитам или их комбинации. Конкретное правило выбирают на данных заказчика и проверяют на обычных и спорных примерах.
Как вернуть пакет на уточнение
Сотруднику и отправителю нужен один понятный список, а не несколько уведомлений по каждому файлу. В нём указывают:
- идентификатор исходной заявки;
- недостающий тип документа;
- причину запроса;
- спорный файл, если требуется ручное решение;
- адресата и срок ответа по правилу заказчика.
Например: «Для условной заявки представлен счёт и заявление. Спецификация из обязательной матрицы не найдена. Направить запрос условному менеджеру заявки». Отдельно можно сообщить, что вторая копия счёта отмечена как дубль и не увеличивает комплектность.
Когда адресат присылает спецификацию, система связывает её с той же заявкой, повторяет сопоставление и обновляет пакет. Новая заявка не создаётся. Если связь досланного файла с исходным пакетом не установлена, автоматическое обновление останавливается, а сотрудник выбирает заявку вручную.
При спорном OCR система не должна отправлять категоричное сообщение «документ отсутствует». Сначала человек подтверждает тип, после чего пакет либо обновляется, либо попадает в единый запрос на уточнение.
Учебный пример: путь от входных данных до результата
Ниже — синтетический пример, а не клиентский кейс и не результат выполненного теста. Все имена файлов, версии, роли и числа условны.
Для условного процесса требуются три типа: заявление, счёт и спецификация. Поступили три файла: заявление и две идентичные копии счёта. Сначала каждый файл связывают с заявкой, затем определяют тип, версию и дубликаты.
| Требование | Полученный файл | Версия | Проверка | Чего не хватает | Ответственный |
|---|---|---|---|---|---|
| Заявление | Заявление_условное_v1.pdf | v1 | Тип найден, связь с заявкой установлена | — | Условный сотрудник бэк-офиса |
| Счёт | Счёт_условный_v1.pdf и его идентичная копия | v1 | Один тип найден, второй файл отмечен как дубль | — | Условный сотрудник бэк-офиса |
| Спецификация | — | — | Тип не найден | Спецификация | Условный менеджер заявки |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Промежуточное решение выглядит так:
- Три входящих файла связаны с одной условной заявкой.
- Заявление представляет первый уникальный тип.
- Два одинаковых счёта представляют один уникальный тип; второй файл отмечен как дубль.
- Спецификация не найдена и включена в запрос ответственному.
Итоговая комплектность — 2 из 3 типов документов, а не 3 из 3 файлов. Если нужно выразить учебный результат долей, расчёт такой: 2 ÷ 3 × 100% = 66,7% после округления до одного знака. Это арифметика синтетического примера, а не измерение работы реальной системы.
После досылки спецификации обновляется тот же пакет. Дубль счёта сохраняет свою отметку, а исходная заявка не создаётся повторно.
Как проверить результат перед запуском
Проверку строят по заранее записанным входам и ожидаемому результату. Отдельно проходят нормальный путь и исключение.
| Сценарий | Вход | Ожидаемый результат | Сигнал ошибки | Действие человека |
|---|---|---|---|---|
| Нормальный путь | Заявление, счёт и спецификация | 3 из 3 уникальных типов; список недостающего пуст | Копия файла считается отдельным типом или связана с другой заявкой | Проверить правило дедупликации и связь файлов с заявкой |
| Исключение | Заявление и две одинаковые копии счёта | 2 из 3 типов; копия счёта отмечена как дубль; запрошена спецификация | Результат 3 из 3 либо спорный вывод OCR утверждён автоматически | Подтвердить типы, отметить дубль и направить единый запрос ответственному |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Перед запуском стоит отдельно подтвердить три инварианта:
- один файл не всегда равен одному типу документа;
- статус комплектности не означает юридическую экспертизу;
- повторная досылка обновляет существующий пакет, а не создаёт новую заявку.
К набору проверок добавляют повреждённый файл, неизвестный тип, несколько версий одного документа, отсутствие связи с заявкой и спорное распознавание. Для каждого исключения заранее назначают человека, который принимает решение.
Что согласовать для внедрения
Готовый инструмент распознавания или классификации может извлекать признаки документа. Но он сам по себе не знает матрицу конкретной сделки, правила версий и дублей, маршрут уточнения или полномочия сотрудников. Эти части требуют настройки либо собственной интеграции.
Перед проектированием нужно согласовать:
- один тип процесса и его матрицу документов;
- источники правил и их владельцев;
- способы получить файлы и связать их с заявкой;
- доступные API, форматы и права;
- правило определения версии и дубля;
- порог передачи спорного распознавания человеку;
- адресатов, сроки и формат запроса на уточнение;
- примеры нормального пути и исключений для приёмки.
В простом процессе может хватить фиксированной автоматизации: получить файл, применить однозначные правила и подготовить уведомление. ИИ-помощник уместен, если нужно извлекать признаки из неоднородных документов или выбирать разрешённую ветку обработки. Бот может служить каналом для уточнений, но сам формат диалога не заменяет правила комплектности. Различия между этими вариантами подробнее описаны на странице разработки ИИ-агентов.
Switch On AI может разработать ИИ-помощника, бота или интеграцию для этой операции после проверки данных и доступных API. Правила бухгалтерского, юридического, кадрового и отраслевого учёта задаёт и проверяет специалист заказчика. Совместимость с конкретной платформой, права доступа, тариф и ограничения подключения проверяются отдельно; упоминание Microsoft 365 выше не означает партнёрство или уже выполненное внедрение.
Первый шаг — передать обезличенный список обязательного пакета для пилота. Можно описать одну операцию: что приходит на входе, какие типы обязательны, кто получает уточнение и какой результат должен принять сотрудник. Затем разберём процесс и согласуем прототип ключевого сценария. Прототип не равен полному внедрению и не служит обещанием эффекта или срока.
Вопросы по этой задаче
Наличие файла означает корректный документ?
Нет. Наличие файла подтверждает только получение вложения. Отдельно проверяют его тип и связь с заявкой, а содержание, подписи и юридическую действительность оценивает профильный специалист по правилам заказчика.
Как проверять условные документы?
Для условной позиции в матрице указывают проверяемое условие и источник правила. Если условие выполнено, документ включают в обязательный состав. Если значение неизвестно или признаки противоречат друг другу, решение передают владельцу процесса.
Что делать с повторно присланным файлом?
Его связывают с исходной заявкой, проверяют тип, версию и признаки дубля. Досылка обновляет тот же пакет и запускает повторную проверку комплектности; новую заявку создавать не нужно.