Отслеживание местоположения бумажных документов по штрих-коду

Cтатья описывает опыт практического применения, тонкости и нюансы работы с накопительным сканером штрих-кодов. Статья является продолжением темы «Контроль перемещения бумажных документов. Задачи и варианты решения», освещенной на сайте сообщества DIRECTUM27.07.2010.

Так что же на практике? На практике, для задачи контроля перемещения бумажных документов рекомендуем использовать два сканера:

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

В предыдущей статье рассматривался накопительный сканер, как устройство, которое может запоминать время и штрих-код документа. На деле же накопительный сканер оказался сильно беспомощным, так как без «серьезной» ОС, он мог запоминать только отсканированные им штрих-коды. Для  запоминания времени требовалась доработка на языке низкого уровня. Решили использовать сканер с операционной системой WindowsMobileCE, которая поддерживает технологию более высокого уровня .Net.

Задача синхронизации данных оказалась, не такой простой, как первоначально предполагалось. Основная сложность связана с ошибочными штрих-кодами, которые не занесены в систему или введены неверно, (онлайн связи с системой нет).

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

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

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

Задача выбора штрих-кода была не совсем тривиальной, так как нему предъявлялись особые требования:

• Уникальность для компании, что данный штрих-код соответствует только этой организации. Решение: разработан свой формат в рамках стандартного формата 128В, выделен из значимых символов префикс.
• Встроенная проверка штрих-кодов на целостность (не в штрихах, а именно в цифрах, при ручном вводе). Цифровую целостность поддерживают форматы только EAN13 (и подобные ему, например UPC), но у них есть серьезные недостатки для рассматриваемой задачи:
  • в штрих-коде содержаться только цифры;
  • количество цифр в штрих-коде фиксировано – всего 12 значащих цифр).

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

• Достаточное количество возможных комбинаций (порядок документов - сотни миллионов);

(Решение: выделение в рамках формата 128В девяти значащих цифр)

• Поддержка выбранного формата штрих-кода сканерами, а именно накопительным сканером и стационарным сканером. Решение: выбор форматов только из используемых сканеров.

После тщательного выбора штрих-кода предполагалось, что все проблемы решены, но на практике оказалось не так все просто. Потребовался достаточно уникальный префикс. Выбрали символьный префикс на латинице, по сокращенному названию компании. В середине тестирования системы сложилась следующая ситуация: ставим курсор в поле, подносим штрих-код к сканеру, и вот Вам кириллица вместо «буржуйской» латиницы. Ошибка распознавания подумали тестировщики, повторим, но, к сожалению, все равно символы от Кирилла и Мефодия. Оказалось, что была включена раскладка на русском языке в момент сканирования штрих-кода, при переключении на английский всё чудеснейшим способом возвращалось на свои места. Первоначальным решением было настроить правильно сканер. Связались с производителем. Ответ был совсем не утешительным: «Попробуйте настроить работу сканера, не через USB, а через COM-порт, правда потребуется ещё отдельное терминальное приложение, которое обрабатывает только латиницу». Решили обрабатывать программно, а именно приложением в котором регистрируем перемещение бумажных документов (в момент загрузки данных в приложение).

На «десерт» самое интересное - отдельно разрабатываемое ПО для накопительного сканера штрих-кодов. Было множество различных вариантов реализации интерфейса и логики работы при  сканировании штрих-кодов. Задача стояла выбрать простое и надежное решение, что накладывало сильный отпечаток на решение и на возможные варианты. Не буду перечислять возможные варианты решения, а поведаю о том, которое выбрали и которое в той или иной степени прижилось. Логика работы решения следующая: отметчаем сначала «Куда» передаем документы (сотрудники или подразделения), а потом собственного «Чего» (конечно же, документы) передаем. Что касается интерфейса работы, было решено отображать минимальное количество данных. А именно, два поля для отображения штрих-кодов «Куда» и «Чего».

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