Сразу скажу, что мы сторонники электронного документооборота с клиентами и поставщиками, в котором отсутствует проблема/задача возврата/сканирования бумажных оригиналов (оригиналы документы подписанные по ЭДО всегда доступны в электронном виде). Но по разным причинам остается определенный массив документов с контрагентами, которые не участвуют в электронном документообороте и требуется возврат и сканирование бумажных оригиналов.
Примеры таких документов: УПД, счет-фактура, транспортная накладная, договор, спецификация, дополнительное соглашение, акт выполненных работ и т.д.
В нашей компании есть две основные задачи, связанные со сканами оригиналов первичных документов:
Хранить сканы оригиналов, в том числе на случай утраты бумажного оригинала.
Предоставлять сканы оригиналов в гос. органы, например, при запросе от ФНС.
Сложности: сканировать оригиналы первичных документов, упорядочивать хранение, оперативно находить среди сканов нужные документы по запросу.
До последнего времени обработкой бумажных оригиналов занимались менеджеры по документообороту, т.е. ручное: упорядочивание, сканирование, хранение, выборка. Объем документов - несколько тысяч экземпляров в месяц.
Далее, на примере транспортных накладных, описан способ автоматической идентификации сканов оригиналов и их хранения с привязкой к документам в 1С. А когда скан хранится в 1С, то программисту довольно просто выбрать такие документы и выгрузить сканы по запросу.
Кодирование первичных документов для последующего распознавания сканов, идентификации и хранения в 1С
Штрихкоды в печатных формах документов, на ценниках или этикетках в 1С, как правило, используются для идентификации с помощью сканера штрихкодов или ТСД.
Как правило, штрихкод в 1С кодирует УИД документа в формате Code 128 высокой плотности, который позволяет кодировать цепочку символов произвольной длины.
Идея автоматизации: идентифицировать сканы первичных документов по штрихкоду.
Быстрое тестирование показало, что штрихкод отсканированного документа не поддается распознаванию, так как после сканирования штрихкод становится нечитаемый из-за высокой плотности формата Code 128.
![Штрихкод в формате Code 128 после сканирования становится нечитаемый Штрихкод в формате Code 128 после сканирования становится нечитаемый](https://habrastorage.org/getpro/habr/upload_files/af5/1f5/21a/af51f521aaef9f86d23f6fc63a2ae4d1.png)
Затем были проверены другие популярные форматы штрихкодирования (QR-код, DataMarix, EAN-13):
QR-код и DataMatrix на выходе давали низкий процент распознавания после сканирования (~50)
EAN-13 оказался наиболее подходящим из-за низкой плотности (EAN-8 тоже подходит, но слишком маленькая разрядность для кодирования)
Другая особенность компоненты BarcodeRecognitionAddIn в 1С, которую мы используем для распознавания штрихкодов со сканов - должны быть заданы координаты QR-кода, что усложняет процесс распознавания.
![Для распознавания скана с QR-кодом нужно задать область расположения штрихкода Для распознавания скана с QR-кодом нужно задать область расположения штрихкода](https://habrastorage.org/getpro/habr/upload_files/c6c/187/b85/c6c187b85319016442786ba3cb3dd5f2.png)
Общая особенность распознавания штрихкодов со сканов - потеря качества после сканирования оригинала документа. Как в пример ниже, документы со сканированием в качестве 200 dpi не читаемые. Поэтому мы перешли на качество 300 dpi (отрицательный момент - увеличивает размеры файлов для хранения).
![Сканы документов в качестве 200 dpi становятся не читаемые Сканы документов в качестве 200 dpi становятся не читаемые](https://habrastorage.org/getpro/habr/upload_files/787/587/96f/78758796f762b411a0a62a2512448f5f.png)
Задача №1: идентифицировать документы 1С с помощью штрихкода
Возникла первая задача идентификации документа 1С, из которого выполняется печать первичного документа. УИД документа в 1С 8275005056b84a2d11eddeaee1857d5a
содержит 32 символа, что не позволяет его использовать в формате EAN-13. Другой ньюанс в том, что некоторые печатные формы (например, счет-фактура) могут быть рапечатаны из разных документов в 1С.
С другой стороны, большинство документов в 1С имеют нумерацию в пределах года. Т.е. внутри года номер документа для вида документа 1С является уникальным. Поэтому мы реализовали кодирование штрихкода в формате EAN-13 для идентификации документов 1С:
первые 2 цифры кодидуют вида документа 1С
следующие 2 цифры кодидуют год для идентификации по номеру документа 1С (или сразу номер, если нумерация сквозная и не в пределе одногогода)
остальные цифры кодируют номер документа 1С с учетом префикса, из которого напечатан первичный документ
![Пример кодировки документа 1С в формате EAN-13 для последующей идентификации Пример кодировки документа 1С в формате EAN-13 для последующей идентификации](https://habrastorage.org/getpro/habr/upload_files/39a/262/0ee/39a2620eef69cc61af444088d32f95ea.png)
Пример штрихкода транспортной накладной в формате EAN-13, который успешно распознается после сканирования документа благодаря низкой плотности.
![Штрихкод в формате EAN-13 после сканирования успешно распознается Штрихкод в формате EAN-13 после сканирования успешно распознается](https://habrastorage.org/getpro/habr/upload_files/329/833/579/3298335791ef9e106b060a9020a0d918.png)
Как выглядят настройки штрихкодирования EAN-13 для документов в 1С
![Пример настройки штрихкодирования документов 1С в формате EAN-13 Пример настройки штрихкодирования документов 1С в формате EAN-13](https://habrastorage.org/getpro/habr/upload_files/9ef/bc7/762/9efbc7762302fb4c4b6ce4e39c7e967f.png)
Задача №2: распознавать пачки отсканированных документов и хранить сканы в 1С
Сканирование и распознавание одного документа - это половина решения. Если менеджер по документообороту будет отдельно сканировать каждую транспортную накладную, то процесс особо не улучшается, а усложняется.
Идея автоматизации: сканировать пачки документов и разбивать на отдельные файлы для хранения в 1С - без участия менеджера по документообороту.
Для распознавания штрихкодов в формате EAN-13 используется стандартная компонента 1С BarcodeRecognitionAddIn. Особенность компоненты в том, что она распознает штрихкоды EAN-13 только с изображений (сканы мы храним в формате PDF). Поэтому было решено использовать утилиту ImageMagick, которая умеет разбирать PDF на изображения и собирать обратно.
Для сканирования пачек документов на МФУ настроена сетевая папка, куда сохраняются все отсканированные документы.
![Общая сетевая папка на МФУ для сохранения отсканированных пачек документов Общая сетевая папка на МФУ для сохранения отсканированных пачек документов](https://habrastorage.org/getpro/habr/upload_files/ce5/c28/21b/ce5c2821bac1b9b0d7136151dfddb052.png)
Принцип автоматического распознавания сканов документов по штрихкоду следующий:
Сотрудники сканируют пачки документов в сетевую папку
Обработка в 1С каждые 15 минут считывает файлы из сетевой папки
Каждая пачка PDF с помощью ImageMagick разбивается на отдельные файлы JPG
Для лучшей читаемости штрихкода с помощью ImageMagick повышается контрастность
Затем каждый файл распознается отдельно с помощью BarcodeRecognitionAddIn
Распознанные и нераспознанные файлы в исходном виде объединяются в документы с помощью ImageMagick (транспортная накладная - это 1 файл из 2-х страниц)
Распознанные файлы идентифицируются с документами 1С и сканы сохраняются в них
Нераспознанные файлы загружаются в 1С и ожидают ручной привязки ответственным к документам 1С
Как выглядит процесс распознавания сканов с точки зрения пользователя
Пачки документов могут содержать любое количество страниц. Главное, чтобы в одной пачке содержались документы одного вида, например, только транспортные накладные. Порядок и последовательность документов в пачке может быть любая.
После сканирования на МФУ каждой пачки документоа ответственный менеджер получает задачу на рабочий стол в 1С: пачка распознана с ошибками или без ошибок.
Пример пачки отсканинрованных документов до распознавания
![Файл скана транспортных накладных содержит 92 страницы Файл скана транспортных накладных содержит 92 страницы](https://habrastorage.org/getpro/habr/upload_files/9bd/60d/0f8/9bd60d0f8abe75609a40f1896b9dcde9.png)
![Пример задачи пользователю, когда пачка сканов распознана без ошибок Пример задачи пользователю, когда пачка сканов распознана без ошибок](https://habrastorage.org/getpro/habr/upload_files/9b4/621/838/9b462183805dde54d3a6a7e8b2728d45.png)
![Пример задачи пользователю, когда пачка сканов распознана с ошибками - 5 из 46 документов не распознано Пример задачи пользователю, когда пачка сканов распознана с ошибками - 5 из 46 документов не распознано](https://habrastorage.org/getpro/habr/upload_files/570/37a/58a/57037a58ab249d92dea06b92bc0b552c.png)
Примеры документов, когда штрихкод скана нераспознан автоматически
![Пример 1 Пример 1](https://habrastorage.org/getpro/habr/upload_files/760/29f/2a7/76029f2a757dd3bf06b469c50507de35.png)
![Пример 2 Пример 2](https://habrastorage.org/getpro/habr/upload_files/14e/8c7/c27/14e8c7c2712ee429c8c0e108ded3b2fc.png)
![Пример 3 Пример 3](https://habrastorage.org/getpro/habr/upload_files/31e/deb/dbe/31edebdbe75698efc9a0db24852d4a8f.png)
При наличии ошибок автоматического распознавания сканов ответственный менеджер формирует отчет по истории импорта сканов.
![История импорта сканов в 1С История импорта сканов в 1С](https://habrastorage.org/getpro/habr/upload_files/c48/0f0/0a2/c480f00a2235882022bdaa9da2d55cf0.png)
Когда документ не распознан, ответственный прямо из отчета делает привязку файла скана к документу 1С этого вида.
![Ручная привязка не распознанного скана к документу в 1С Ручная привязка не распознанного скана к документу в 1С](https://habrastorage.org/getpro/habr/upload_files/f6b/c1e/960/f6bc1e960394aae44d2ecb7beb2ae257.png)
По такому же принципу штрихкодируются печатные формы, сканируются пачки и распознаются сканы других видов первичных документов, которые автоматически связываются с документами в 1С.
Результативность системы распознавания сканов по штрихкодам в формате EAN-13 составляет от 90% до 100%.
Возможно, у вас есть другие способы решения подобной задачи. Поделитесь в комментариях.
Комментарии (13)
Necessitudo
19.04.2023 15:44А как быть с входящими документами?
E_BEREZIN Автор
19.04.2023 15:44С входящими пока нет решения. Это в основном мелкие поставщики, которые не перешли/не пользуются ЭДО.
zaki
19.04.2023 15:44А в чем проблема с QR кодами?
можно много заложить информации и распознается хорошо при сканировании если использовать PNG в место JPG(много артефактов создает из за этого плохое распознание)
E_BEREZIN Автор
19.04.2023 15:44QR-код и DataMatrix после печати читаемый. После сканирования и распознавания становится плохо читаемый. Печать и сканирование 300 dpi. PNG или JPG особой роли не играет, больше влияет плотность. В данном случае, степень распознавания сканов низкая ~50%. До тех же сканов с ean-13 распознавание до 100%, если сам штрихкод не испорчен (скрепками или др.)
zaki
19.04.2023 15:44Разница между PNG и JPG очень большая
JPG замыливает грани перехода между черным и белым QR кода из за этого пропадает четкая граница что снижает значительно качество распознания
E_BEREZIN Автор
19.04.2023 15:44Мы сканируем в формате PDF с качеством 300 dpi, т.е. качество скана уже здесь.
До распознавания сканировали с качеством 200 dpi.
Размеры файлов тоже имеют значение, все это ещё нужно хранить.
E_BEREZIN Автор
19.04.2023 15:44Другой ньюанс (дополню в статье) в том, что для распознавания QR-кола нужно задавать координаты области, что не очень хорошо. Скан может быть с наклоном или вообще перевернутая страница. Со штрихкодом таких траблов нет
zaki
19.04.2023 15:44Ничего не нужно задавать, используя Python и библиотеки OpenCV и pyzbar достаточно подать картинку на вход и на выходе получить содержимое QR кода
sevenlis
когда-то делал для получения уникального номера документа в 7.7 (SQL) - это прозаично ROW_ID таблицы _1SJOURN, догонял до 12 символов, считал контрольный и EAN-13 готов. всё. и не важно, какая нумерация в пределах чего.
если EAN-8, то тоже хватило бы. 9 млн. / ну, пусть, 30 тыс. экз. в мес. = 300 мес. / 12 = 25 лет.
E_BEREZIN Автор
В 7.7 возможно хватит и ean-8. В 8-ке есть ещё префикс от 2 до 4 символов в номере, ввидов документов > 10 (ещё 2 разряда) и год (миниму 2 разряда), потому ean-13 в притык
sevenlis
да, но в 8 никто не запретит замутить отдельную табличку с UID, Видом (_Document<n>, _Reference<n>, ...) (как в документации, я так понимаю, вид как раз) и автоинкрементным полем. автоинкрементное поле - в штрихкод, по которому очень легко получить UID и, собственно, "экземпляр объекта метаданных" (любой ;))
уникальный ключ по UID, индекс по автоинкрементному полю. ИМХО, как-то так ))
ЗЫ. можно даже без "Вида", UID так и так предположительно уникальный )))
E_BEREZIN Автор
Можно наверное, только зачем усложнять хранение в отдельных регистрах уид ради ean-8, когда подходит ean-13.
Регистр распухнет очень быстро, если взять все виды документов и количество документов для каждого вида в год (десятки тысяч). И туда же добавить справочники, из которых тоже печатаются документы, например, договора с клиентами/поставщиками и связанные допники и спе-ции
sevenlis
рискну предположить, что таблица с одним текстовым и одним числовым полем, с учетом индексов, "распухнет" базу на 1-2% не более ))
и, я не говорил про регистр, хотя, можно и регистром. понятно, что под регистр 1с создаст несколько таблиц с туевой хучей полей )). я про табличку в базе данных и паре глобальных функций. и про прямой запрос к БД, можно даже к внешней, можно даже по ADODB.