Рассмотрим опыт
практического применения, тонкости и нюансы работы с накопительным сканером
штрих-кодов. Материал является продолжением темы «Контроль
перемещения бумажных документов с использованием сканеров штрих-кодов»
Так что же на практике? На практике,
для задачи контроля перемещения бумажных документов решено было использовать
два сканера:
- Накопительный
сканер – для сотрудников, которые осуществляют и контролируют перемещение
документов;
- Стационарный
сканер - для тех, кто регистрирует документы в СЭД на стационарных рабочих
местах. Он упрощает работу и снижает ошибки при вводе штрих-кода в
систему.
В
предыдущей статье рассматривался накопительный сканер, как устройство, которое
может запоминать время и штрих-код документа. На деле же накопительный сканер
без «серьезной» ОС оказался очень слабеньким, он мог запоминать только
отсканированные им штрих-коды. Для запоминания времени требовалась
доработка на языке низкого уровня. Поэтому решено было использовать сканер с
операционной системой Windows MobileCE, которая поддерживает технологию более
высокого уровня .Net.
Данные с
накопительного сканера необходимо было синхронизировать с данными СЭД. Задача
оказалась, не такой простой, как первоначально предполагалось. Основная
сложность связана с ошибочными штрих-кодами, которые не занесены в систему или
введены неверно (онлайн связи с системой нет, что подразумевается под названием
самого сканера «накопительный»).
Первый
вариант решения - это перенос части данных на сканер и постоянная синхронизация
их. Другим вариантом является перенос проверки ввода ошибочного штрих-кода в
программу синхронизации данных между сканером и системой. Этот вариант является
менее требовательным к аппаратному обеспечению накопительного сканера и менее
трудоемким в реализации, а так же сокращает время на передачу документов,
поэтому при данных требованиях представился наиболее оптимальным.
Задача
выбора формата штрих-кода была не совсем тривиальной, так как нему
предъявлялись особые требования:
- Поддержка
выбранного формата штрих-кода сканерами, а именно накопительным сканером и стационарным
сканером.
Решение:
выбор форматов только из используемых сканерами.
- Уникальность
для компании, то
есть чтобы получаемые штрих-коды соответствовали только этой организации.
Решение:
разработан свой формат в рамках стандартного формата 128В (Code 128), выделен из значимых символов
префикс.
- Достаточное
количество возможных комбинаций
(порядок документов - сотни миллионов);
Решение:
выделение в рамках формата 128В девяти значащих цифр.
- Встроенная
проверка штрих-кодов на целостность (не в штрихах, а именно в цифрах, при ручном
вводе). Цифровую целостность поддерживают форматы только EAN13 (и подобные ему,
например UPC), но у них
есть серьезные недостатки для рассматриваемой задачи:
- в
штрих-коде содержаться только цифры;
- количество
цифр в штрих-коде фиксировано – всего 12 значащих цифр.
Решение:
отказались от этого требования, вместо этого организационно запретили ручной
ввод штрих-кодов, ввод штрих-кода осуществляется только стационарным сканером
при регистрации документа.
После
тщательного выбора формата штрих-кода предполагалось, что все проблемы решены,
но на практике оказалось не так все просто. Потребовался достаточно уникальный
префикс, как минимум для видимого различия, чтобы не перепутать со сторонними
штрих-кодами. Выбрали символьный префикс на латинице, по сокращенному названию
компании.
В ходе
тестирования системы сложилась следующая ситуация: ставим курсор в поле,
подносим штрих-код к сканеру, и вот Вам кириллица вместо «буржуйской» латиницы.
«Ошибка распознавания» - подумали тестировщики. Повторим. Но, к сожалению, все
равно символы от Кирилла и Мефодия. Оказалось, что была включена раскладка на
русском языке в момент сканирования штрих-кода. При переключении на английский
всё чудеснейшим способом возвращалось на свои места. Первоначальным решением
было настроить правильно сканер. Связались с производителем. Ответ был совсем
не утешительным: «Попробуйте настроить работу сканера, не через USB, а через
COM-порт, правда потребуется ещё отдельное терминальное приложение, которое
обрабатывает только латиницу». Решили обрабатывать программно, а именно
приложением, в котором регистрируем перемещение бумажных документов (в момент
загрузки данных в приложение).
На «десерт»
самое интересное – особенности разрабатываемого ПО для накопительного сканера
штрих-кодов. Было множество различных вариантов реализации интерфейса и логики
работы при сканировании штрих-кодов. Задача стояла выбрать простое и надежное
решение, что накладывало сильный отпечаток на решение и на возможные варианты.
Не буду перечислять возможные варианты решения, а поведаю о том, которое
выбрали и которое в той или иной степени прижилось. Логика работы решения
следующая: отмечаем сначала «Куда» передаем документы (сотрудники или
подразделения), а потом собственного «Чего» (конечно же, документы) передаем.
Что касается интерфейса работы, было решено отображать минимальное количество
данных. А именно, два поля для отображения штрих-кодов «Куда» и «Чего».
В
заключение хотелось бы отметить, что предложенное решение является одним из
способов реализации при существующих ограничениях. Надеюсь, озвученные вопросы,
задачи и их решения, в той или иной мере помогут в дальнейшем развитии
направления работы с накопительными сканерами и сканерами штрих-кодов в целом.