Проблема и что мы сделали
Договоры, счета, акты и накладные приходили пачкой — почтой, сканами, из мессенджеров. Дальше начиналась ручная работа: открыть файл, понять тип, перебить реквизиты, завести карточку в 1С или СЭД, отправить по маршруту.
Мы разработали систему, которая делает этот контур сама: определяет тип документа, извлекает данные, проверяет обязательные поля, создаёт карточку и направляет документ на согласование.
Если данные спорные или поля не бьются — подключается человек.
Как было: файл есть, карточки ещё нет
В компании поток входящих документов не останавливается. Юридически и финансово значимые файлы приходят вперемешку: договор с одной стороны, счёт с другой, акт и накладная — следом. Каналы тоже разные. Кто-то шлёт на почту, кто-то скидывает скан, кто-то кидает файл в мессенджер.
Пока документ «просто лежит» в письме или чате, в 1С и СЭД его ещё нет. Сотрудник открывает вложение, читает, вручную переносит контрагента, суммы, даты, номера. Потом создаёт карточку и только после этого запускает согласование. На объёме это съедает часы и даёт ошибки: цифра не та, поле пустое, тип документа определён на глаз, маршрут стартовал с дырявой карточкой.
Нужна была система обработки входящих документов, а не очередная папка «разобрать».
Как стало: от файла до карточки и маршрута
Документ попадает в контур из почты, скана или мессенджера. Система определяет, что это — договор, счёт, акт или накладная. Достаёт реквизиты, проверяет обязательные поля. Если всё сходится — создаёт карточку в 1С или СЭД и отправляет документ по маршруту согласования. Если есть ошибка или спорные данные — карточка не «пролетает» молча: кейс уходит на ручную проверку.
Для команды это другой день. Вместо перебивки полей — контроль исключений и согласование уже заведённых документов.
Что разработали
- Единый контур приёма. Собрали обработку входящих из трёх каналов: почта, сканы, мессенджеры. Файлы не живут в трёх разных очередях с тремя разными привычками — попадают в одну систему распознавания.
- Распознавание типа документа. ИИ отделяет договор от счёта, акта и накладной. От типа зависят и набор полей, и то, какая карточка нужна дальше, и какой маршрут запускать. Без этого шага автоматизация быстро превращается в свалку «всё подряд в одну форму».
- Извлечение реквизитов. Система вытаскивает из документа данные, которые раньше переносили руками: контрагент, номера, даты, суммы и другие обязательные реквизиты под тип. Цель — готовая основа карточки, а не сырой текст распознавания без структуры.
- Проверка обязательных полей. Перед созданием карточки модуль сверяет, всё ли на месте для этого типа документа. Пустое критичное поле или явный конфликт данных — стоп-сигнал, а не слепая запись в 1С.
- Создание карточки в 1С или СЭД. Если проверка пройдена, система сама заводит карточку в нужном контуре учёта/документооборота. Документ перестаёт быть вложением в почте и становится объектом, с которым уже можно работать по процессу компании.
- Направление по маршруту согласования. После создания карточки документ уходит по маршруту: не ждёт, пока сотрудник вспомнит «надо согласовать». Маршрут стартует из того же контура, что и распознавание.
- Ручная проверка для ошибок и спорных данных. Отдельный контур исключений: нераспознанный фрагмент, сомнительный реквизит, неполная обязательная часть. Человек проверяет и правит, автоматика не делает вид, что всё идеально. Так сохраняется скорость на типовых документах и контроль на рискованных.
Где система не должна «договаривать»
Документы бывают кривыми: плохой скан, обрезанные поля, нестандартная форма, расхождение в реквизитах. Здесь хуже всего ложная уверенность. Поэтому спорное не маскируется под успех: кейс уходит на ручную проверку, а в 1С/СЭД не создаётся «почти правильная» карточка, которую потом сложно откатить по согласованию.
Вторая граница — тип документа. Ошибка на этом шаге тянет за собой неверные поля и неверный маршрут. Логика завязана на уверенном определении типа и на правилах обязательных полей именно для него.
Документы приходили из почты, сканов и мессенджеров — дальше шла ручная перебивка в 1С. Мы собрали контур: определение типа, извлечение реквизитов, проверка обязательных полей, создание карточки и маршрут согласования. Спорные данные сознательно уводим на ручную проверку — ложная уверенность здесь хуже, чем медленный разбор одного файла.
„
Максим, Руководитель проектов NeuroB2B
| Было | Стало |
| Документы из почты, сканов и мессенджеров разбирали вручную | Единая система забирает все три канала |
| Тип и реквизиты определяли глазами | ИИ распознаёт тип и извлекает данные |
| Карточку в 1С/СЭД создавали руками | Карточка создаётся автоматически после проверки полей |
| Согласование запускали отдельно | Документ сразу уходит по маршруту |
| Ошибки находили поздно, уже в карточке | Спорные данные уходят на ручную проверку до «тихого» успеха |
Что вышло в результате
Компания получила систему, которая превращает входящий файл в готовую карточку в 1С или СЭД и запускает согласование. ИИ определяет тип документа — договор, счёт, акт, накладная — извлекает реквизиты, проверяет обязательные поля и только потом пишет в учётный контур.
Типовой поток больше не держится на ручной перебивке. Люди подключаются там, где нужна проверка: ошибки, спорные данные, нестандартные формы. Документооборот ускоряется не ценой слепой загрузки в 1С, а за счёт автоматики на чистых кейсах и контроля на сомнительных.
