Распознавание счетов в Make: что проверить до передачи данных в 1С
PDF прочитан, но сумма не сходится, поставщик не найден или файл уже приходил. Разбираем путь от вложения до проверенного черновика документа и очереди исключений.
Поставщик прислал счёт в PDF. Распознавание вернуло номер, дату и итог, сценарий создал запись в учётной системе. Позже выяснилось: документ был исправленной версией прежнего счёта, а банковские реквизиты отличались от согласованных. Технически все модули сработали; содержательно процесс принял неподтверждённые данные.
Автоматическая обработка документов должна доводить файл до понятного результата: проверенный черновик, запрос уточнения или отказ с причиной. Ниже проектная схема для входящих счетов на оплату. Она не заменяет бухгалтерскую проверку и не предполагает автоматическую оплату по результату OCR.
Сначала определите, какие файлы входят в процесс #
Укажите каналы поступления, допустимые форматы и виды документов. Счёт, акт, договор и счёт-фактура требуют разных полей и правил. Расширение .pdf не доказывает, что внутри один счёт: там могут быть несколько документов, сопроводительное письмо или страницы с плохим сканом.
Каждому вложению присвойте внутренний идентификатор, сохраните источник, время получения и исходный файл в разрешённом хранилище. Повторное письмо связывают с прежним поступлением. Изменённый файл с тем же номером рассматривают как возможную новую редакцию, а не безусловно отбрасывают по совпадению названия.
Получите данные файла и отдельно извлеките реквизиты #
В Make ссылка на документ и его содержимое — разные значения. Документация по файлам показывает передачу File Name и Data между модулями; для файла по URL сначала требуется его загрузка. Там же описан пример извлечения текста через Make AI Content Extractor. Названия модулей и допустимые размеры проверяют для используемого подключения и плана.
Дальше результат приводят к собственной структуре: поставщик, номер, дата, валюта, позиции и суммы. Не подменяйте отсутствующее значение наиболее вероятным. Пустой номер договора должен остаться неизвестным, даже если модель видела похожий документ этого поставщика.
Проверку сумм выполняют по согласованной модели документа. Если НДС уже включён в цену, его нельзя прибавлять повторно. При несовпадении округления система показывает строки и расчёт, а не «исправляет» итог под ожидаемое число. Для денежных значений при реализации используют точную десятичную арифметику.
Уверенность распознавания — дополнительный сигнал, если выбранный сервис её возвращает. Она не заменяет сопоставление: отчётливо прочитанный номер счёта может относиться к отменённой редакции. Поле без оценки уверенности нельзя автоматически считать достоверным на сто процентов.
Ниже пример внутреннего результата валидации. Это не формат API 1С или Make. Сумма показана строкой для сохранения точности при передаче; её преобразование согласуют с принимающей системой.
Рядом с полями нужны ссылка на оригинал, подсветка спорного фрагмента, причина проверки и история правок. Сотрудник подтверждает конкретную редакцию. Если файл заменили после согласования, разрешение не должно автоматически переходить на новые данные.
Очередь исключений разделяют по причинам: качество скана, неизвестный поставщик, изменение реквизитов, дубли и арифметика. Для каждой причины назначают владельца. Иначе все документы застрянут у человека, который умеет исправлять OCR, но не вправе подтверждать реквизиты.
Передача начинается после обязательных проверок. Тип создаваемого объекта, обязательные поля и статус черновика зависят от конфигурации 1С и согласованного способа интеграции. Нельзя обещать одинаковый HTTP-запрос для любой базы. Внешний идентификатор документа связывают с идентификатором созданного объекта, а подтверждение записи сохраняют отдельно от подтверждения отправки.
Не отправляйте весь исходный документ в облачный AI-сервис без проверки принятой политики обработки данных. Регион организации в Make не гарантирует одинаковый регион исполнения каждого AI-модуля: это отдельно разъясняется в документации по провайдерам и зонам обработки . Для закрытого контура выбирают допустимый обработчик и доступное хранилище.
Возьмите обезличенные примеры: повтор письма, исправленный счёт, нечитаемая страница, две валюты, отсутствующий поставщик и изменение реквизитов. Проверяйте не только долю заполненных полей. Важно, сколько документов прошло без существенных исправлений, какие ошибки проскочили и можно ли восстановить историю одного поступления до объекта 1С.
Можно ли сразу проводить распознанные документы? #
Для этого потребуется отдельно согласованный контур контроля и полномочий. Разумная граница первого этапа — проверенный черновик. Успешное извлечение текста не означает подтверждение хозяйственной операции или разрешение на оплату.
Зачем нужен оригинал, если все поля уже сохранены? #
Он позволяет проверить спорное значение и понять, где возникло изменение: в файле, распознавании или ручной правке. Набор полей без связи с редакцией исходника плохо подходит для разбора ошибок и исправлений.
Поможем связать распознавание с вашим документооборотом #
NetLabCS поможет настроить обработку документов с ИИ : определить поля, проверки и правила исключений, затем согласовать передачу в вашу конфигурацию учёта. Опишите поток документов : форматы, каналы поступления, необходимые объекты 1С и ситуации, которые обязан подтверждать сотрудник.
