Введение
На Хабре не раз писали об инвентаризации, но для меня не нашлось ничего полезного. Почему? Ответ прост: передо мной была поставлена задача: автоматизировать процесс инвентаризации товаров магазина. Лежащие на полках склада товары не отвечают на пинги, не могут по команде сами о себе собрать статистику и отправить их на сервер. При этом магазин не виртуальный, и даже не маленький розничный магазинчик, где за час можно пересчитать все руками, блокнотом и ручкой. Речь идет о довольно крупной торговой сети, продающей товары весьма различных направлений.
До Амазона, с его роботами, мы конечно пока не доросли, но, тем не менее, инвентаризацию товаров как то надо проводить. Вот если бы каждый товар можно было бы однозначно идентифицировать! И тут не пришлось изобретать ни одного велосипеда. Каждая единица товара однозначно идентифицирует себя с помощью штрих-кода. Этого более чем достаточно для автоматизации сбора информации. В этой статье я попробую изложить мой опыт внедрения технологии инвентаризации с помощью терминала сбора данных.
Исходные данные
Большая часть продаваемых товаров имеет свой штрих-код. Но даже товары не имеющие такой отметки могут получить ее на складе во время оприходования. Кроме того, производимая продукция (например у нас, это выпечка, салаты и другие готовые к употреблению блюда) так же получают свою наклейку со штрих-кодом. Штрих-кодирование всех товаров вводилось на предприятии не для целей инвентаризации, а с целью упрощения продаж — наверное все видели как в супермаркетах товар выкладывается с тележек и сканируется на кассах специальными сканерами. Но этот факт (тотальное штрих-кодирование всего и вся) очень помог мне решить главную проблему — распознавание товара на полке склада (или в торговом зале, не имеет значения) и его учет. Для этих целей обычно используется специальное устройство с гордым именем — терминал сбора данных.
Выбор среди этих устройств весьма огромен, характеристики самые различные. В основном терминалы различаются по возможностям сбора данных:
- Сканирование линейных штрих-кодов (обычно всех возможных форматов, а так же инвертированных по цвету и зеркальных)
- Распознавание двухмерных штрих-кодов
- Чтение радио-меток
Но, так же, есть ряд других характеристик, на которые стоит обратить внимание:
- Характеристики экрана (влияет на количество и качество выводимой пользователю информации)
- Время автономной работы (будет неприятно прервать инвентаризацию из-за севшего аккумулятора)
- Объем памяти (количество записей БД, которые терминал может собрать перед передачей)
- Возможности связи (через док-станцию, по bluetooth или wi-fi)
- Защищенность от внешнего воздействия (ударопрочность, термостойкость — актуально для пыльных складов или холодильных установок)
- Цена
Так как изначально требовалось только попробовать инвентаризацию такими устройствами, и если окажется удобным — будут выделены деньги на массовое внедрение во всех подразделениях, то важнейшим критерием я выбрал низкую цену. В результате поисков и сравнений я выбрал CipherLab 8001L.
Интеграция
Для ведения учета в компании используется «1С: Предприятие 8. Управление Производственным Предприятием» (УПП). Поэтому для меня был важен вопрос интеграции с нашей системой этого устройства. К счастью терминал оказался в списке официально поддерживаемых устройств. По задумке это должно означать что мы скачиваем и ставим драйвер, обработку 1С и начинаем работать, но меня такая работа не устроила.
Естественно оборудование можно интегрировать в любую систему учета. Самый простой способ — использовать файлы заданного формата для обмена между терминалом и системой. Но компонента, написанная для 1С, поддерживает работу с терминалом напрямую. В качестве базы я использовал ПО от ScanCode — официального представителя CipherLab в России, т.к. куплен терминал был у партнера компании и имел соответствующую лицензию на прошивку. В целом продавец не сильно имеет значение, ведь все прошивки похожи друг на друга и имеют сходные генераторы приложений. На примере данной статьи можно разобраться и с другими прошивками. Подробнее о прошивках и приложениях для ТСД написано чуть ниже. Для внедрения в работу терминала потребуется скачать со страницы разработчика:
- Драйвер док-станции терминала
- Прошивку и генератор приложений
- Компоненту и обработку для 1С
Если планируется использовать учетную систему не от 1С, то на сайте производителя оборудования можно скачать Библиотеку для работы с устройствами. Этот архив содержит примеры использования библиотеки на разных языках программирования. На этом же сайте можно скачать и инструкции, в которых я разбирался, добиваясь удобной работы с терминалом.
Драйвер док-станции ставится как обычное устройство, после этого подключенный по USB кредл должен нормально определится и появится в оборудовании в виде COM-порта. Нам надо будет запомнить номер этого порта:
Если вы желаете просто начать работать, то все что осталось — это установить компоненту для 1С и подключить обработку. Компонента устанавливается как обыкновенное ПО, а обработка подключается в через справочник торгового оборудования. На примере УПП это будет выглядеть так:
Обработку обслуживания можно подключить из файла, установленного ранее, или скачать с сервера 1С, указав регистрационные данные.
Иногда библиотека cipherlab.dll не регистрируется должным образом, поэтому можно вручную зарегистрировать ее в системе командой:
regsvr32 [путь_до_файла]cipherlab.dll
Создается строка в справочнике «Торговое оборудование»:
На что следует еще обратить внимание, так это настройка терминала:
Тут необходимо указать COM-порт который мы запомнили выше при установке ИК-подставки, некоторые специфичные параметры, которые можно оставить и по умолчанию и два формата — БД и Файла для обмена с ТСД. Формат БД — зависит от ваших потребностей, актуального для статьи скриншота не осталось, а вот пример формата файла привожу:
После этих нехитрых манипуляций уже можно использовать терминал в работе, но это оказалось несколько неудобно. Поэтому я решил внести некоторые изменения, о которых далее и пойдет речь.
Анализ и доработка
После долгого общения с сотрудниками разного уровня и разных должностей выстроилась следующая цепь действий для удобного проведения инвентаризации:
Рассмотрим по пунктам, что надо в этом процессе автоматизировать:
Создание документа
Вроде бы все понятно: создается документ инвентаризации, в который необходимо забить суммы фактического наличия номенклатуры на складе и сверить их с учетным остатком. Звучит просто, но надо смотреть вперед и там (впереди) видно два варианта заполнения:
- Мы подождем пока с терминалом пройдутся по складу, а потом просто загрузим из него фактические остатки и в документе проставим учетное количество, рассчитаем расхождение и распечатаем сличительную ведомость
- Мы выгрузим номенклатуру в терминал, перед началом сбора данных, чтобы при инвентаризации было удобно работать с номенклатурой, а далее загрузка, сверка и печать.
Первый вариант — проще, практически ничего не надо доделывать, просто идем с терминалом и штрихуем всю номенклатуру, вводя количество, а потом стандартной обработкой загружаем номенклатуру в документ.
Второй вариант — намного удобнее и практичнее. Во-первых, оператор будет видеть штрих-код какой номенклатуры он сейчас считал в ТСД, т.к. терминал будет знать к какой номенклатуре приписан этот штрих-код. Можно также выводить и учетное количество, но я отказался от этого, чтобы оператор совсем не расслаблялся и не тыкал бездумно кнопку ввода, а проверял количество и вводил его цифрами. Кто то может отметить что ввод количества — это дырка в системе, т.к. из-за человеческого фактора может быть введено неправильное количество. На это я отвечу, что на должность инспектора (ревизора) берут людей ответственных, они не должны ошибаться, это их работа. Кроме того если «тыкать» каждую единицу номенклатуры и автосуммировать количество (тут надо отметить, что режим автосуммирования я предусмотрел в итоге), то процесс затягивается, а мне было важно именно сократить время инвентаризации (читайте — простоя магазина, приносящего доход). Во-вторых в первом варианте возможна ситуация что номенклатура по учетному остатку есть на складе, а фактически — отсутствует, тогда терминал об этом ничего не скажет, и расхождение не будет учтено. Однако эта проблема исчезнет и при первом варианте, если сначала заполнить документ остатками по складу, а уже потом загружать в него данные из терминала, надо только предварительно обнулить колонку фактического количества.
Итак, тут я выбрал второй вариант, появился этап выгрузки данных в терминал и мне было необходимо написать обработку, которая бы это делала. Заполнение же документа учетными остатками делается стандартной функцией: «Заполнить» → «Заполнить по остаткам на складе (Упр. учет)».
Выгрузка данных в терминал
Проще всего выгрузить определенный список номенклатуры из самого документа, потому что, во-первых, список уже присутствует в документе, а во-вторых оператору не придется переключаться в другую обработку для наполнения терминала. Так же это позволяет исключить ошибку, которая может возникнуть если документ заполнен одним набором номенклатуры, а обработка выгрузит другой набор. Для реализации выгрузки из документа я воспользовался механизмом внешних обработок заполнения табличных частей.
Весь код приводить не буду, приведу лишь сам файл обработки и опишу один занятный момент: в терминал можно передать только фиксированный набор полей, это ограничение разработчиков обработки-обертки драйвера. Если писать на другом языке или написать свою обертку, то конечно эти ограничения можно обойти, но меня список передаваемых полей вполне устроил:
- Штрихкод
- Наименование
- ЕдиницаИзмерения
- ХарактеристикаНоменклатуры
- СерияНоменклатуры
- Качество
- Цена
- Количество
Тем более что мне из этого набора достаточно вообще только два поля: штрих-код и наименование. Правда, тут мы сталкиваемся с еще одной проблемой: номенклатуре можно присвоить несколько штрих-кодов. Как быть? Да просто выгружать все штрих коды с наименованиями. Зачем экономить память терминала, которая навряд ли вообще когда-либо будет заполнена полностью за одну инвентаризацию? Тогда терминал по одному из штрих-кодов все равно найдет запись в БД для правильно номенклатуры и поставит количество, а при загрузке все количества с разных записей с суммируются для одной номенклатуры. Кроме того в терминал я передаю еще коэффициент умножения количества, привязанный к штрих-коду. Это необходимо для весовых товаров, но так же может использоваться и для упаковок. Правда реализовал работу с упаковками я гораздо позже и не для инвентаризации.
Подключать внешнюю форму надо в справочнике внешних обработок заполнения табличных частей, который можно открыть через меню «Сервис» → «Дополнительные внешние отчеты и обработки» → «Обработки заполнения табличных частей». Созданный элемент должен выглядеть примерно так:
Теперь в самом документе можно через «Заполнить» → «Выгрузка данных в терминал сбора данных» отправить список номенклатуры в обработку. Сам обработка была написана для универсального применения, и можно прямо в ее окне сделать подбор номенклатуры для выгрузки, но если она получает список, то достаточно просто нажать «Выгрузить» и подождать.
Сбор данных при помощи терминала
Терминал сбора данных — устройство довольно сложное, и для корректной работы ему необходима программа! Иначе он просто не будет знать что ему делать с этим списком. Для терминалов CipherLab есть два вида программы: прошивка и приложение. Прошивка — это что то вроде операционной системы терминала, прокладка между приложением и системой I/O. Можно разработать свою прошивку. Для этого на сайте производителя терминала есть все необходимое — ПО, примеры и документация. Меня стандартная прошивка от ScanCode вполне устроила. Кто хочет поэкспериментировать с разработкой прошивки, тот наверняка догадался, что ее надо будет еще и прошить. Делается это утилитами идущими в комплекте поставки. Осталось только создать приложение. Почему я говорю создать, а не разработать? Да просто потому, что процесс этот чисто визуальный и делается с помощью генератора приложений. Главное окно генератора — это эмулятор ТСД:
Весь функционал программы скрыт в контекстном меню (его открывает щелчок правой кнопкой мыши при наведенном на главную форму указателе курсора мыши). Процесс разработки выглядит примерно вот так:
По-умолчанию, базовое приложение просто собирает штрих-код и количество. Как мы определились выше — нас это не устраивает, и терминал должен показывать название номенклатуры, штрих-код которой только что считал, и учетное количество этой номенклатуры. Поэтому было натыкано мышкой такое приложение. Все что понадобилось для его написания — прочитать приложенную инструкцию по использованию генератора. Отмечу отдельно то, что я изменил в базовом файле:
- Убрал работу с несколькими базами (эта модель поддерживает одновременно три БД). Для этого просто исключил пункты из меню, которые открывают формы работы со всеми кроме первой базами. Сделано это для того что бы уменьшить вероятность ошибок, т.е. конечный пользователь не запутался в этих БД.
- Указал какую информацию надо выводить терминалу, для этого в полях «поиск в» указал поля БД в которые я передавал обработкой 1С нужные данные. Если требуется вывод учетного количества, чтобы оператор бездумно его подтверждал, надо, всего лишь, выставить в поле «поиск в» строки #8 значение «Поле 4». Правда надо убедится что в это поле 4 обработка выгрузки в терминал заполняет именно количество.
- Вместо цены я передавал привязанный к штрих-коду коэффициент умножения количества. Об этом я написал выше. У не весовых товаров этот коэффициент всегда равен 1 в этой версии (учет упаковок еще не был реализован).
Теперь, на этом этапе, мы имеем созданный в учетной системе документ и терминал с загруженным в него списком номенклатуры этого документа. Осталось пройти по складу и, сканируя все что есть на полках, вводить количество в ТСД.
Загрузка фактического количества номенклатуры в документ
Тут я ничего мудрить не стал и использовал стандартную загрузку из терминала от 1С. При подключении ТСД в торговом оборудовании, в меню «заполнить» многих документов (в том числе и документе «Инвентаризация товаров на складе») появляется пункт «Заполнить из терминала сбора данных». Этот механизм получает из терминала только штрих-код и количество. А больше ничего и не нужно, обработка заполнения табличной части документа выполняет поиск в БД по штрих-коду номенклатуру, находит (или добавляет) эту номенклатуру в документе и заполняет поле «фактическое количество». После этого необходимо записать документ и провести остальные регламентные процедуры (печать сличительной ведомости, раздача нагоняев за утерянные товары и т.д.). На этом автоматизированные процессы закончились. ТСД отправляется на полку, ревизоры — домой, а некоторые сотрудники начинают судорожно искать «недосдачу».
Послесловие
На текущий момент могу сказать, что в тех масштабах, которые планировались руководством, технология не используется. Хотя терминал ускорил инвентаризацию складов с 16 до 4 часов, но некоторые сотрудники встретили новшество в штыки, на отрез отказавшись использовать терминал, и по итогу его использует только один ревизор. Но самим устройством заинтересовались ответственные за отгрузку товара со складов в магазины и прием товара на склад от поставщика. В результате чего мне была поставлена задача автоматизировать их процесс. Для этого были закуплены более навороченные Сipherlab 8500, мне пришлось лезть в обработку работы с терминалом и вообще это совсем другая история. Кроме этого оборудования, мне, по долгу службы, уже довелось поработать с фискальными регистраторами и банковскими терминалами оплаты. Если тема эта будет интересна читателям, я могу изложить в новых статьях свои наработки и по этим направлениям. Все это я внедрял примерно год назад и что-то мог позабыть. Если кто-то использует этот материал как инструкцию, но столкнется с трудностями, я попробую помочь решить проблему. Может быть, кто то хочет видеть больше подробностей? Тогда укажите какие именно.
Автор: SoLRoN
