DocAcquire извлекает из PDF и сканов нужные поля и таблицы, распознаёт текст, разделяет смешанные пакеты документов, предлагает проверить результат рядом с исходной страницей и передаёт подтверждённые данные в Excel, SQL, API или подключённую бизнес-систему.

Работа строится вокруг очереди документов. Файл попадает на этап Import, после распознавания переходит в Awaiting Review, затем оператор сверяет поля и строки таблиц, отмечает документ как Reviewed и только после этого отправляет данные на экспорт. Такой порядок полезен там, где автоматическое распознавание должно экономить время, но окончательная запись в учётной системе не может зависеть от непроверенного результата.

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

Очередь документов и логика рабочего процесса

После входа пользователь видит боковое меню и рабочую область со списком файлов. В обновлённом интерфейсе раздел Documents раскрывает четыре состояния: Import, Awaiting Review, Reviewed и Exported. Это не декоративные вкладки, а готовые фильтры по этапам обработки. В Import удобно контролировать новые загрузки и результат автоматической классификации; Awaiting Review собирает документы, где требуется человеческая проверка; Reviewed отделяет подтверждённые записи от ещё не просмотренных; Exported помогает найти то, что уже было передано дальше.

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

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

Импорт отдельных файлов и пакетов

Загрузка запускается кнопкой с плюсом в разделе Import. Документы можно добавлять по одному или группой; поступление из почтовых ящиков, сетевых папок, мобильных сканеров и облачных хранилищ организуется через интеграции. Для первичной проверки лучше начать с небольшого набора, где представлены все типичные варианты: обычный цифровой PDF, скан, многостраничный файл, документ с таблицей и образец плохого качества. Такой тест сразу показывает, какие поля распознаются без настройки, где требуется собственный тип документа и какие страницы дают низкую уверенность.

Поддерживаются PDF, PNG, JPEG и TIFF. PDF может содержать настоящий текст или только изображения страниц: в первом случае система получает доступ к текстовому слою, во втором применяет OCR. Для смешанного пакета не нужно заранее превращать каждую страницу в отдельный файл, если настроено автоматическое разделение и классификация. Однако перед массовым запуском следует проверить порядок страниц и убедиться, что в пакет не попали пустые обороты, случайные фотографии и дубликаты.

Классификация и статус Unclassified

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

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

Создание типа документа

Раздел Document Types хранит схемы, по которым DocAcquire понимает, какие данные нужно получить. На начальном экране каждый тип представлен отдельной карточкой, а новая схема создаётся кнопкой с плюсом. Практично давать типу название, совпадающее с реальным бизнес-документом: Invoice, Purchase Order, Bill of Lading, Insurance Claim или внутреннее наименование формы. Слишком общий тип вроде Other Documents затрудняет классификацию и делает набор полей неочевидным для проверяющего.

Внутри типа доступны области Main, Fields, Tables, Document Split, Export Connector и Export Webhook. Main используют для основных параметров схемы. Fields описывает одиночные значения, например номер, дату, поставщика или итог. Tables предназначен для повторяющихся строк. Document Split задаёт обработку многостраничных пакетов. Export Connector выбирает готовый канал выдачи, а Export Webhook связывает завершение обработки с HTTP-адресом принимающей системы. Эти настройки лучше проектировать как единый маршрут, а не заполнять независимо: поле должно иметь понятное назначение в экспорте, таблица — стабильные колонки, а разделение — выдавать документы того типа, который ожидает схема.

Обычные поля

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

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

Таблицы и линейные позиции

Табличные данные настраиваются отдельно от обычных полей. В боковой области Tables создаётся таблица, после чего добавляются колонки. В схеме Line Items можно использовать колонки Quantity, Description и Line Total; колонки можно переставлять, отмечать обязательными, сохранять или удалять. Такой подход подходит для позиций счета, товаров заказа, строк банковской выписки и перечня услуг, где число записей меняется от документа к документу.

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

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

Предобученное извлечение и собственная разметка

Zero-shot extraction предназначено для начала работы без подготовки шаблонов: модель использует контекст документа и предобученные знания, чтобы найти ключевые сущности в незнакомом макете. Это особенно удобно при большом количестве поставщиков, когда каждый печатает счёт по-своему. При этом собственные типы и нестандартные таблицы всё равно требуют точного описания результата. Предобученное распознавание отвечает на вопрос, что написано на странице; схема документа отвечает на вопрос, какие значения нужны конкретному процессу.

Для повторяющегося нестандартного бланка используется экран Annotate Document. В центре показывается страница, слева — миниатюры многостраничного файла, справа — список полей и таблиц. Пользователь выделяет области, связывает их с элементами схемы и сохраняет пример. Верхняя панель содержит масштаб, команды Process, Save, Classify и Exit. Разметку следует выполнять на нескольких реальных макетах, если положение полей меняется, иначе схема будет хорошо работать только на исходном образце.

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

После изменений используйте Process для повторной обработки, затем сравните автоматический результат с исходной страницей. Save сохраняет настройку, Classify помогает проверить привязку к типу, а Exit возвращает к списку. Не закрывайте экран сразу после первой удачной страницы. Минимальная проверка должна включать документ другого поставщика, более длинную таблицу и скан с заметно худшим качеством.

Проверка извлечённых данных

В Awaiting Review открывается рабочее место оператора. Исходная страница занимает центральную область, а извлечённые значения и таблицы расположены рядом. Такой вид позволяет исправлять данные без переключения между PDF-просмотрщиком и отдельной формой. На верхней панели доступны масштаб, поиск по странице, загрузка файла, сохранение и команда Mark Reviewed. Отмечать документ просмотренным следует только после проверки обязательных полей, строк таблиц и итогов.

Вкладка Fields показывает одиночные значения, а Document Chat предназначена для вопросов по содержимому. При ручной корректировке можно выбрать значение на странице и перенести его в поле методом point-and-click. Это быстрее перепечатывания и снижает риск опечатки, но оператор всё равно должен убедиться, что выбрал правильную строку. На счёте часто встречаются несколько дат, адресов и сумм, поэтому близость к подписи поля важнее простого совпадения текста.

Ручная работа с таблицей

В нижней части окна проверки отображаются строки таблицы. Кнопка Extract Table запускает извлечение выбранной табличной области, а Clear Table очищает текущий результат, когда разметка оказалась неверной. Отдельную строку можно удалить, если OCR принял заголовок, подытог или пустой разделитель за позицию. После исправлений нужно сохранить документ и ещё раз проверить сумму строк, налоги и общий итог, потому что табличная корректность не гарантирует арифметического соответствия.

Если таблица распознана частично, сначала сравните ширину выделенной области с исходником. Затем проверьте, не находится ли часть колонок на следующей странице и не меняется ли структура после переноса. При повторяющейся проблеме лучше исправить таблицу в Document Type, чем вручную восстанавливать каждую загрузку. Ручной Extract Table полезен для исключения, а настройка схемы — для устойчивого потока.

Что означает уверенность

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

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

Document Chat для вопросов по содержимому

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

Чат удобен как инструмент навигации и предварительного анализа, но не заменяет извлечение структурированных полей. Ответ в свободном тексте трудно безопасно передать в ERP или SQL без дополнительной проверки. Для регулярного процесса важные значения нужно хранить в Fields и Tables, а чат использовать для пояснения, поиска контекста и разовых вопросов. Если ответ влияет на юридическое решение, его необходимо сопоставить с точным фрагментом документа.

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

Автоматическое разделение и классификация пакетов

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

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

В Document Split можно задать правила для конкретного типа, а новая AI-классификация обрабатывает смешанные пакеты без ручной сортировки. Правила подходят, когда граница всегда выражена предсказуемо; интеллектуальное разделение полезно при меняющейся структуре. Если оба подхода используются в одном процессе, документируйте приоритет, чтобы оператор понимал, почему пакет разделился именно так.

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

Форматы файлов и OCR

Для извлечения используются PDF, PNG, JPEG и TIFF. Поисковый PDF обычно содержит текстовый слой, тогда как сканированный PDF хранит изображения страниц. DocAcquire обрабатывает оба варианта; для сканов применяется OCR. Стандартным OCR-движком служит Amazon Textract, а для отдельных задач можно выбирать Amazon Textract или Google Vision, чтобы сравнить качество на плохих сканах, сложных таблицах и нестандартной печати.

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

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

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

Поисковый и сканированный PDF

В поисковом PDF можно выделить текст обычным PDF-просмотрщиком. Такой файл не всегда идеален: текстовый слой может иметь неверный порядок чтения, а таблица — быть набором разрозненных символов. Сканированный PDF выглядит одинаково, но требует OCR для каждого элемента. Если результат неожиданно плох, проверьте тип исходника и сравните извлечение с визуальной страницей, а не полагайтесь на наличие текстового слоя.

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

Извлечение таблиц и многостраничные данные

Таблицы извлекаются как отдельный структурированный набор, а не как сплошной текст. DocAcquire поддерживает разные компоновки и может объединять продолжение таблицы на следующих страницах с помощью table append. Это важно для счетов и отчётов, где шапка повторяется, а позиции занимают несколько листов. После объединения проверьте, что повторная шапка не стала строкой данных, а промежуточный итог не смешался с товарами.

При экспорте создаётся книга Excel с листом Documents и отдельным листом line items. На первом хранится идентификатор документа и имя файла, на втором — DocumentID и значения табличных колонок. Такая связь позволяет восстановить, какие строки относятся к какому документу. При импорте в базу данных используйте DocumentID как технический ключ, а бизнес-номер счета храните отдельным полем: разные поставщики могут повторять номера.

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

Лист line items хранит по одной записи на позицию. Перед загрузкой в ERP проверьте типы столбцов: количество и сумма должны быть числовыми, а описание — текстовым. Если числа выглядят как текст, причиной может быть десятичный разделитель, символ валюты или пробелы. Исправлять это лучше в правилах преобразования или принимающей системе, а не вручную в каждой книге.

Для таблиц без явных границ особенно важна разметка. Модель должна понять, где заканчивается одна строка и начинается другая. Если описание переносится, колонка Quantity пустует или итог расположен внутри сетки, используйте несколько примеров и проверьте ручной Extract Table. В спорных случаях безопаснее отправить документ на Awaiting Review, чем автоматически экспортировать смещённые значения.

Экспорт в Excel, SQL и бизнес-системы

После проверки данные можно выгрузить в Excel, отправить в Microsoft SQL Server, получить через REST API в JSON или передать через настроенный коннектор. Список интеграций включает Xero, Zoho Books, Developer API, RPA и webhooks. Через сценарии Zapier документы могут поступать из Dropbox, Google Drive, Box и Gmail, а результат — создавать записи в Xero, SQL Server или Google Sheets.

Выбор канала зависит от назначения. Excel удобен для проверки пилота, ручного анализа и передачи ограниченной партии. SQL подходит, когда данные должны накапливаться в корпоративной базе. REST API нужен приложению, которое само управляет запросами и ответами. Webhook полезен для событийной передачи: DocAcquire уведомляет принимающий адрес, когда наступает нужное состояние. Готовый бухгалтерский коннектор сокращает код, но всё равно требует сопоставления полей.

REST API и JSON

При интеграции через API заранее зафиксируйте схему ответа: имена полей, типы, массивы таблиц, идентификатор документа и статус проверки. Принимающая сторона должна отличать пустое значение от отсутствующего поля и уметь обрабатывать повторный запрос. Нельзя считать HTTP-ответ единственным доказательством успешной записи: создайте журнал с DocumentID, временем отправки и идентификатором объекта в целевой системе.

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

Webhooks

Export Webhook отправляет данные на RESTful endpoint в реальном времени. В настройке важно проверить адрес, авторизацию, допустимый метод, формат тела и ожидаемый код ответа. На принимающей стороне следует сохранять исходный payload до преобразования: это облегчает разбор ошибки, когда структура документа изменилась или одна колонка таблицы получила неожиданный тип.

Если webhook не сработал, сначала проверьте, действительно ли документ дошёл до состояния, которое запускает экспорт. Затем посмотрите доступность адреса, сертификат, журнал ответов и ограничения сети. Не повторяйте отправку вслепую много раз. Сначала выясните, не приняла ли целевая система данные, но не вернула подтверждение; иначе появятся дубликаты.

Microsoft SQL Server

Прямая выдача в SQL Server удобна для последующей аналитики и передачи в внутренние приложения. До подключения создайте таблицы с ясными типами и ограничениями. Денежные поля не стоит хранить как произвольный текст, даты — как локализованные строки, а многострочные позиции — в той же таблице, что и заголовок документа. Нормальная схема использует отдельную таблицу документов и отдельную таблицу позиций, связанную идентификатором.

При ошибке вставки проверьте длину строк, обязательные столбцы, кодировку и преобразование дат. Если описание товара длиннее выделенного поля, SQL отклонит запись, хотя извлечение было правильным. Такие ошибки решаются изменением схемы или контролируемым преобразованием, а не повторным OCR. Разделяйте проблему распознавания и проблему сохранения: у них разные причины и разные журналы.

Сценарий обработки счетов поставщиков

Для счета обычно извлекают номер, дату, поставщика, адрес, налоговые реквизиты, валюту, срок оплаты, итог и строки товаров или услуг. Сначала создайте или выберите Invoice, затем загрузите документы нескольких поставщиков. На этапе Awaiting Review сравните номер и дату с заголовком, проверьте компанию-получателя, найдите правильный Total и убедитесь, что налог не включён дважды. После этого сверьте line items и только затем отмечайте документ просмотренным.

Особенно внимательно относитесь к нескольким суммам: subtotal, tax, shipping, amount paid, balance due и total due могут находиться рядом. Автоматическое извлечение способно прочитать каждую строку, но схема должна точно указывать, какая нужна системе. Если бизнес-процесс оплачивает остаток, поле Total не должно автоматически брать общую стоимость до учёта платежа. Для таких документов добавьте отдельные поля и проверку соотношения.

При сопоставлении поставщика используйте не только отображаемое название. Юридическое имя, торговая марка и банковский получатель могут отличаться. Если ERP требует код контрагента, настройте обогащение или сопоставление после извлечения. DocAcquire получает данные со страницы, но внутренний код обычно отсутствует в документе. Автоматический маршрут должен уметь отправить неизвестного поставщика на исключение, а не создавать новую карточку без контроля.

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

Сценарий для заказов и логистических документов

В логистическом процессе DocAcquire применяется к invoices, purchase orders, waybills, proof of delivery, bills of lading, packing lists, certificates of origin и rate confirmations. Смешанный входящий пакет можно разделить, классифицировать и направить в разные схемы. Заказ поставщика требует номера, дат, сторон и позиций; накладная — груза, отправителя, получателя и маршрута; подтверждение доставки — идентификатора отправления, даты и признаков получения.

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

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

После экспорта полезно сверять связки документов: номер purchase order в счёте, номер отправления в proof of delivery и номер накладной в системе. DocAcquire извлекает ключи, а бизнес-правило определяет, должны ли они совпадать. Несоответствие следует направлять на проверку до закрытия операции.

Сценарий для страховых и KYC-документов

Для страховых процессов используются contracts, insurance claims и KYC forms. Здесь автоматизация особенно зависит от человеческой проверки, потому что документы содержат много свободного текста, приложений и рукописных отметок. Сначала отделите основной бланк от подтверждающих материалов, затем классифицируйте тип и извлеките идентификаторы, даты, стороны, суммы и требуемые реквизиты.

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

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

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

Документы HR, юридических и медицинских процессов

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

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

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

Организация ручной проверки

Human-in-the-loop — центральная часть процесса. Автоматизация уменьшает объём ручного ввода, а оператор обрабатывает исключения и подтверждает критические значения. Чтобы очередь не превратилась в новое ручное хранилище, определите правила: какие документы можно экспортировать после автоматических проверок, какие всегда требуют просмотра и какой уровень уверенности считается поводом для исключения.

В списке документов виден Imported By, поэтому можно отслеживать канал загрузки. Для командной работы полезно распределять очереди по времени, типу или подразделению и не открывать один документ одновременно без договорённости. После исправления сохраняйте изменения до Mark Reviewed. Если проверка требует внешнего согласования, документ лучше оставить в Awaiting Review с понятным внутренним процессом, а не отмечать готовым ради очистки очереди.

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

Кредиты и планирование объёма

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

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

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

Практические ограничения DocAcquire

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

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

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

Готовые коннекторы уменьшают объём разработки, но сопоставление полей, права доступа, обработка ошибок и защита от дублей остаются задачей внедрения. Даже простой экспорт в Excel требует согласовать названия листов и колонок, если файл затем автоматически загружается дальше. Чем больше систем участвует в цепочке, тем важнее общий идентификатор и журнал состояния.

Устранение ошибок импорта и распознавания

Файл не появляется в очереди

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

Документ долго остаётся в Import

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

Получен Unclassified

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

Поле пустое

Найдите значение на исходной странице. Если его нет, определите, допустима ли пустота. Если значение есть, проверьте качество текста, правильность типа документа и область разметки. Используйте point-and-click для разового исправления, а при повторении измените схему. Для обязательного поля проверьте, не печатают ли разные поставщики тот же смысл под другим заголовком.

Выбрано неправильное значение

Сравните подписи вокруг извлечённого фрагмента. На документе могут быть invoice date, due date, delivery date и дата печати. Уточните название поля и добавьте образцы с разным расположением. Если ошибка зависит от поставщика, не закрепляйте одну абсолютную область на странице; используйте контекст и отдельную настройку, подходящую для нескольких макетов.

Низкая уверенность на хорошем скане

Проверьте, нет ли нескольких одинаковых значений или неоднозначной подписи. Уверенность снижается не только из-за качества изображения, но и из-за неопределённости выбора. Сравните другой OCR-движок на том же наборе, затем оцените именно критические поля. Если значение стабильно распознаётся правильно, порог проверки можно обсуждать после накопления статистики, а не по одному документу.

Таблица смещена

Откройте Document Type и проверьте порядок колонок. На странице убедитесь, что выделение не захватывает заголовок и итог. Для перенесённого описания проверьте, объединяются ли строки. Очистите неверный результат, выполните Extract Table заново и сохраните исправление. Если проблема возникает на каждой второй странице, настройте многостраничное продолжение и повторяющуюся шапку.

Пропали строки на следующей странице

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

Заголовок попал в line items

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

Document Chat отвечает неточно

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

Устранение ошибок экспорта

Документ не переходит в Exported

Убедитесь, что он отмечен Reviewed и все обязательные значения сохранены. Проверьте выбранный Export Connector или webhook, затем посмотрите, получил ли целевой адрес запрос. Если документ остаётся в Reviewed, проблема находится после проверки; повторное OCR не поможет. Сохраните текст ошибки и идентификатор документа, чтобы найти соответствующую запись в журнале принимающей системы.

Excel пуст или содержит не все листы

Проверьте, были ли обычные поля и таблицы включены в схему экспорта. Если документ не содержит line items, отдельный лист может не получить строк. Сопоставьте DocumentID на листе Documents с листом позиций. При повторяющейся пустой таблице вернитесь к экрану Review и убедитесь, что строки были сохранены до Mark Reviewed.

SQL отклоняет запись

Сравните тип и длину каждого поля со схемой базы. Особое внимание уделите датам, десятичным числам, null и длинным описаниям. Проверьте кодировку и обязательные ограничения. Не изменяйте распознанное значение, если оно верно; настройте преобразование на границе. После исправления повторите одну запись и убедитесь, что не создался дубликат.

Webhook возвращает ошибку

Проверьте URL в настройке, метод, авторизацию и сертификат. На целевой стороне сохраните тело запроса и ответ. Код 4xx обычно указывает на параметры или доступ, 5xx — на обработку принимающей системы. Перед повтором выясните, могла ли запись сохраниться частично. Для безопасного повтора используйте уникальный DocumentID и идемпотентную обработку.

Создаются дубликаты

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

Поля попадают не в те колонки

Сверьте имена в Document Type, экспортной схеме и целевой системе. После переименования поля старое сопоставление может остаться. Проверьте регистр, пробелы и вложенность таблиц в JSON. Для Excel посмотрите фактические заголовки листа. Исправляйте mapping в одном месте и документируйте изменение, чтобы следующий администратор не создал второе преобразование.

Контрольный пилот перед массовым запуском

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

Сначала настройте Document Types и экспорт на тестовую среду. Затем загрузите выборку, сохраните автоматический результат и создайте ручной эталон. Сравнивайте поля по смыслу, а таблицы — по строкам и колонкам. Отдельно измеряйте классификацию, разделение, OCR, извлечение, ручные исправления и экспорт. Один общий показатель скрывает причину ошибки и не подсказывает, что улучшать.

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

Перед запуском определите владельцев очередей и реакции на сбой. Кто проверяет Awaiting Review, кто исправляет тип документа, кто отвечает за webhook, кто подтверждает новые поля и кто разбирает нехватку кредитов. Без этих ролей даже точное извлечение не гарантирует устойчивый процесс: исключения будут накапливаться, а интеграция — повторять ошибки.

Сравнение DocAcquire с аналогами

Программа	Лучше подходит для	Главное ограничение
DocAcquire	Готовых маршрутов от импорта до ручной проверки и экспорта	Нужно настроить схемы и интеграции
Rossum	Корпоративной обработки транзакционных документов с очередью проверки	Внедрение ориентировано на бизнес-процесс
Nanonets	OCR и автоматизированных workflow для разных операционных документов	Качество зависит от модели и входных данных
Azure AI Document Intelligence	Разработки решений на готовых и собственных моделях Microsoft	Нужны ресурс Azure и программная интеграция
Google Document AI	Процессоров OCR, извлечения, классификации и разделения в Google Cloud	Требуются проект и экземпляры процессоров
Amazon Textract	API-извлечения текста, форм, таблиц, запросов и подписей	Нет встроенной очереди бизнес-проверки

DocAcquire стоит выбирать, когда нужен единый пользовательский маршрут с типами документов, очередью Awaiting Review, ручной корректировкой, таблицами, экспортом и готовыми интеграционными вариантами. Rossum решает близкую корпоративную задачу и особенно уместен для транзакционных потоков. Nanonets подходит командам, которым нужен конструктор OCR-workflow для разных документов. Azure AI Document Intelligence и Google Document AI удобнее разработчикам, уже использующим соответствующее облако. Amazon Textract полезен как программный строительный блок, но очередь проверки и бизнес-маршрут придётся собрать вокруг API.

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

Как выбрать подходящий режим работы

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

Начните с одного типа документа и одного канала экспорта. Счета поставщиков удобны для пилота, потому что имеют понятные поля и таблицы, но отличаются макетами. После устойчивого результата добавляйте purchase orders, logistics или KYC. Одновременная настройка десятка типов усложняет диагностику: невозможно понять, какая схема или интеграция вызвала ошибку.

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

Настройка полей по типам данных

Надёжность схемы зависит не только от названия поля, но и от того, как будет использоваться извлечённое значение. Номера счетов, заказов, договоров и клиентов следует трактовать как идентификаторы, а не как числа. У идентификатора могут быть ведущие нули, дефисы, косые черты и буквенные префиксы; арифметика к нему неприменима. Если принимающая таблица автоматически превращает 000184 в 184, исходное значение уже невозможно восстановить по экспорту. Поэтому перед подключением Excel, SQL или API проверьте, что целевая колонка хранит строку и не меняет регистр или формат.

Даты лучше разделять по смыслу: дата документа, срок оплаты, дата поставки, период услуги и дата рождения не взаимозаменяемы. В одном счёте могут одновременно встречаться Issue Date, Due Date и Delivery Date, поэтому общее поле Date повышает риск неверного выбора. На этапе проверки оператор должен видеть, какой реквизит ожидается, а при экспорте строку следует привести к формату, который однозначно читает целевая система. Если документы используют разные региональные записи вроде 04/08/2026 и 08/04/2026, одного распознанного набора цифр недостаточно — значение сверяют с языком, страной, подписью поля и соседними датами.

Для денежных полей заранее определяют валюту, десятичный разделитель, допустимость отрицательных значений и способ обработки символов тысяч. Subtotal, Tax, Discount, Freight и Total следует хранить отдельно, даже когда на части бланков некоторые строки отсутствуют. Проверка только итоговой суммы может скрыть ошибку в налоге или скидке, а перенос всех сумм в одно поле усложняет сопоставление с бухгалтерской записью. В таблицах line items полезно извлекать количество, единицу измерения, цену, налог и сумму строки отдельно, затем сравнивать арифметику с итогами документа с учётом округления.

Названия организаций, адреса и описания часто занимают несколько строк. Для них важнее сохранить смысловую целостность, чем повторить разрывы строк исходного PDF. У поставщика могут одновременно присутствовать юридическое имя, торговое название, адрес отгрузки и адрес выставления счёта. Если схема содержит одно поле Company, оператору придётся угадывать, какое из этих значений требуется. Разделите стороны документа и адресные роли, а для сопоставления с мастер-данными используйте устойчивые признаки: налоговый номер, регистрационный код, банковский реквизит или внутренний идентификатор контрагента.

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

После изменения схемы проведите регрессионную проверку. Переименование поля, смена типа данных или добавление обязательности влияет не только на экран Review, но и на заголовки Excel, ключи JSON, mapping коннектора и запросы к SQL. Возьмите один ранее успешный документ, один пограничный и один новый; обработайте их заново в тестовом маршруте и сравните структуру результата. Изменение считается завершённым только тогда, когда оператор видит понятное поле, экспорт принимает значение, а старые интеграции не теряют данные из-за нового имени.

Проверка автоматического разделения по страницам

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

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

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

Проверка интеграций Xero, Zoho Books и Google Sheets

Перед передачей в Xero или Zoho Books сопоставьте каждое извлечённое поле с конкретным реквизитом создаваемой записи. Поставщик должен находиться по устойчивому ключу, а не только по похожему названию; валюта, налоговый режим, номер счёта и дата должны соответствовать правилам учётной организации. Если контрагент не найден, не создавайте его автоматически без контроля: опечатка OCR способна породить дубль. Практичный маршрут отправляет неизвестного поставщика в исключение, а после ручного сопоставления сохраняет его идентификатор для следующих документов.

При работе через Zapier с Dropbox, Google Drive, Box или Gmail разделите три события: получение файла, завершение проверки и создание записи. Триггер на появление файла не должен немедленно создавать бухгалтерскую операцию, пока документ находится в Awaiting Review. В Google Sheets добавляйте DocumentID, время импорта, время проверки, статус экспорта и идентификатор внешней записи. Эти служебные колонки позволяют отличить повторный запуск сценария от нового документа и найти строку, которая была создана до тайм-аута ответа.

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

Метрики качества и критерии приёмки

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

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

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

Краткий рабочий чек-лист

• Определите типы документов и точный набор нужных полей.
• Подготовьте репрезентативные PDF, PNG, JPEG и TIFF без дубликатов.
• Создайте Document Types, обычные поля и таблицы с понятными именами.
• Проверьте Import, классификацию и разделение смешанного пакета.
• Настройте Awaiting Review и правила обязательной ручной проверки.
• Сверьте таблицы, многостраничное продолжение и арифметику итогов.
• Подключите тестовый Excel, SQL, API, webhook или готовый коннектор.
• Добавьте журнал DocumentID, статусов, повторов и ошибок экспорта.
• Проверьте кредиты и оцените запас на повторную обработку.
• Запускайте массовый поток только после второго пилота на новых файлах.

Ответы на практические вопросы

Можно ли извлекать данные из отсканированного PDF?

Да. Для страниц-изображений применяется OCR, после чего модель извлекает поля и таблицы. Результат нужно проверять на плохих сканах, рукописных элементах, печатях и сложной сетке. При систематической ошибке можно сравнить доступные OCR-движки на одинаковой выборке.

Подходит ли DocAcquire для цифрового PDF с текстовым слоем?

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

Можно ли загрузить много документов сразу?

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

Нужно ли обучать модель для каждого поставщика?

Zero-shot extraction позволяет начинать без шаблона для каждого макета. Собственная разметка нужна, когда требуется нестандартная схема, редкое поле, особая таблица или устойчивое поведение на внутреннем бланке. Проверять результат на новых поставщиках всё равно необходимо.

Как исправить одно неверное поле?

Откройте документ в Awaiting Review, выберите правильный фрагмент на странице методом point-and-click или отредактируйте значение, сохраните и продолжите проверку. Если ошибка повторяется, измените Document Type или добавьте образцы, а не исправляйте каждую запись вручную.

Можно ли извлекать строки таблицы?

Да. Таблица описывается в Tables, где создаются колонки и обязательные значения. В окне проверки доступен Extract Table, удаление ошибочных строк и Clear Table. Для многостраничных данных используется объединение продолжения таблицы.

Куда отправляются результаты?

Данные можно получить в Excel, записать в Microsoft SQL Server, запросить через REST API в JSON, передать webhook или направить через интеграции с бизнес-системами и сценариями автоматизации. Каждый маршрут требует проверки сопоставления полей и обработки повторов.

Как контролировать уже обработанные документы?

Используйте вкладки Reviewed и Exported, фильтры списка и DocumentID в выгрузке. Для интеграции храните внешний идентификатор созданной записи вместе с DocumentID и временем отправки. Это позволяет отличить успешный экспорт от документа, который только прошёл ручную проверку.

Что делать с низкой уверенностью?

Откройте исходную страницу, проверьте неоднозначные значения и качество OCR, затем исправьте поле или схему. Не повышайте порог автоматического прохода на основании нескольких удачных файлов. Сначала соберите статистику по конкретному полю и типу документа.

Можно ли использовать вопросы к документу вместо настройки полей?

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

Как понять, что документ готов к экспорту?

Все обязательные значения заполнены, таблицы проверены, изменения сохранены и документ отмечен Mark Reviewed. Затем он должен пройти настроенный канал и появиться в Exported. Дополнительно проверьте подтверждение целевой системы, потому что статус отправки и фактическая запись — разные события.

Можно ли обработать документы на арабском языке?

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

Что важнее: OCR или настройка процесса?

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

Как избежать повторной оплаты одного счета?

Не полагайтесь только на имя файла. Сопоставляйте DocumentID, поставщика, номер счета, дату и сумму, а в целевой системе используйте защиту от повторной записи. Перед повторным webhook или экспортом выясните, не была ли операция выполнена без корректного подтверждения.

Когда нужен PDF-редактор вместе с DocAcquire?

Когда страницы требуется вручную повернуть, переставить, объединить, удалить, отредактировать или подготовить для публикации. Эти действия относятся к работе с самим PDF. DocAcquire нужен для извлечения, классификации, проверки и передачи структурированных данных.

Итоговый рабочий подход

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

В ежедневной работе оператор следит за Import и Awaiting Review, проверяет низкую уверенность, исправляет поля рядом с исходной страницей, контролирует line items и отмечает документ Reviewed. Администратор анализирует повторяющиеся исправления, обновляет Document Types, следит за кредитами и журналами интеграции. Владелец процесса определяет, какие данные можно пропускать автоматически, а какие требуют обязательного подтверждения.

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