Как организовать автоматический ввод документов поступления со сканов накладных в 1С?

← На главную

Автоматизация ввода входящей первичной документации (товарных накладных ТОРГ-12, УПД, актов выполненных работ) — одна из наиболее частых задач при оптимизации учетных процессов. Разберем основные технические подходы к решению этой задачи, выявим подводные камни оптического распознавания текста (OCR) и сопоставим доступные альтернативы.

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

Проанализируем, почему задача автоматического создания документа поступления из отсканированного изображения не сводится только к вызову библиотеки OCR:

Разрушение табличной структуры: разные поставщики используют вариативные печатные формы. Даже в рамках стандартных форм ТОРГ-12 и УПД ширина колонок, переносы строк и количество объединенных ячеек могут отличаться. При сканировании с искажениями (наклоны, замятия бумаги) строки смещаются, что приводит к некорректному объединению данных соседних колонок.
Проблема сопоставления номенклатуры: распознанный текст наименования позиции поставщика почти никогда не совпадает символ в символ с наименованием в справочнике Номенклатура нашей базы. Требуется отдельный механизм сопоставления и хранения соответствий.
Ошибки распознавания чисел: цифры 0, 8, 6, а также разделители дробей и тысяч могут распознаваться некорректно. Ошибка даже в одном знаке в количестве или цене приводит к искажению суммовых показателей и расхождениям во взаиморасчетах.

Архитектура решения на базе оптического распознавания (OCR)

Если специфика бизнес-процесса требует обработки именно бумажных оригиналов или сканов, рассмотрим архитектуру построения подсистемы ввода:

1. Предварительная обработка изображений (препроцессинг). Перед передачей скана в движок распознавания необходимо программно подготовить графический файл: выровнять угол наклона (deskewing), убрать цифровой шум и выполнить бинаризацию (перевод в монохромный контрастный вид). Разрешение сканирования должно составлять не менее 300 DPI.

2. Взаимодействие с сервисами распознавания. Платформа 1С не содержит встроенного низкоуровневого OCR-движка, поэтому обработка выполняется через внешние сервисы по протоколу HTTP (REST API) или специализированные внешние компоненты. Сервер отправляет бинарные данные скана и получает структурированный ответ в формате JSON или XML с координатами найденных блоков текста и таблиц.

Посмотрим на пример отправки скана на обработку через HTTP-запрос средствами встроенного языка 1С:


Соединение = Новый HTTPСоединение("ocr-service.example.com", 443,,,,, Новый ЗащищенноеСоединениеOpenSSL());
Заголовки = Новый Соответствие();
Заголовки.Вставить("Authorization", "Bearer " + ТокенАвторизации);
Заголовки.Вставить("Content-Type", "application/octet-stream");

Запрос = Новый HTTPЗапрос("/api/v1/recognize", Заголовки);
Запрос.УстановитьТелоИзДвоичныхДанных(ДвоичныеДанныеФайла);

Ответ = Соединение.ОтправитьДляОбработки(Запрос);
Если Ответ.КодСостояния = 200 Тогда
    ЧтениеJSON = Новый ЧтениеJSON();
    ЧтениеJSON.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
    ДанныеДокумента = ПрочитатьJSON(ЧтениеJSON);
КонецЕсли;

3. Механизм сопоставления номенклатуры. Для хранения связей между наименованиями поставщиков и элементами справочника базы используется регистр сведений НоменклатураКонтрагентов (или аналогичный по структуре регистр). При разборе распознанной строки сначала выполняется поиск по точному соответствию артикула или наименования, затем — алгоритмами нечеткого поиска (например, расстояние Левенштейна). Если соответствие не найдено, позиция подсвечивается для ручного выбора оператором с последующим сохранением связи на будущее.

4. Контроль целостности и верификация. В интерфейсе создается форма верификации, где оператор видит одновременно исходный скан и распознанные реквизиты. Алгоритм обязательно проверяет контрольные соотношения:

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

Альтернативные и более надежные способы автоматизации

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

1. Юридически значимый электронный документооборот (ЭДО). Самый надежный подход. Документы передаются в строго формализованных XML-форматах, утвержденных ФНС. Данные загружаются в документ ПриобретениеТоваровУслуг или ПоступлениеТоваровУслуг со 100% точностью без ошибок распознавания.

2. Сервис «1С:Бизнес-сеть». Бесплатная альтернатива коммерческому ЭДО для пользователей систем 1С. Позволяет отправлять и принимать электронные накладные и заказы напрямую между базами контрагентов в структурированном виде без использования электронной цифровой подписи.

3. Загрузка из файлов табличных документов (Excel, XML, DBF). Если поставщик не готов подключить ЭДО, достаточно договориться об отправке электронных файлов накладных по электронной почте. Написание типовой обработки разбора таблицы Excel средствами объекта ТабличныйДокумент занимает минимальное время и полностью исключает ошибки распознавания символов.

4. Считывание QR-кодов кассовых чеков. Если автоматизируется авансовый ввод первичных документов, вместо распознавания текста чека эффективнее считывать двумерный QR-код фискального чека. По полученным реквизитам (ФН, ФД, ФПД) данные состава чека загружаются в точном виде через официальные сервисы проверки чеков.

Итоги и рекомендации

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