Как выбрать ТСД и организовать онлайн-инвентаризацию в 1С без остановки продаж?

Программист 1С v8.3 (Управляемые формы) Управленческий учет Торговля и дистрибуция
← На главную

Автоматизация складского учета и инвентаризации с использованием терминалов сбора данных (ТСД) — частая задача при развитии розничных и оптовых магазинов. Нередко бизнес ставит цель проводить ревизию прямо во время торгового процесса, отображая текущие учетные остатки на экране терминала и временно ограничивая продажу пересчитываемой номенклатуры. Рассмотрим, какие аппаратные и программные архитектуры подходят для решения этой задачи, с какими сложностями интерфейса и методологии учета придется столкнуться и как их правильно преодолеть.

1. Выбор архитектуры подключения ТСД к базе 1С

Существует несколько основных подходов к организации обмена данными между мобильным терминалом и учетной системой 1С. Разберем преимущества и ограничения каждого из них:

  1. Прямой доступ через RDP (удаленный рабочий стол):

    Терминал подключается по Wi-Fi к серверу терминалов и запускает сеанс 1С. Основной плюс — не требуется разработка промежуточных баз, все данные передаются мгновенно в режиме реального времени. Однако у RDP есть существенные недостатки: при потере Wi-Fi пакетов сканер, эмулирующий клавиатурный ввод (HID), может терять или искажать символы штрихкода. Кроме того, интерфейс платформы 1С требует тонкой оптимизации под маленькие экраны.

  2. Специализированное промежуточное ПО (например, платформы Mobile SMARTS):

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

  3. Мобильный клиент 1С или веб-интерфейс через HTTP-сервисы:

    Современная альтернатива RDP. В 1С создаются HTTP-сервисы или используется тонкий мобильный клиент платформы. Приложение на Android взаимодействует с базой по REST API, оперативно передавая факт сканирования и статус блокировки номенклатуры без необходимости держать постоянную тяжелую RDP-сессию.

2. Требования к оборудованию терминала сбора данных

Проанализируем ключевые аппаратные параметры при подборе ТСД для складских и торговых ревизий:

  1. Операционная система: Рекомендуется выбирать современные терминалы на базе ОС Android. Устаревшие терминалы на Windows CE и Windows Mobile сняты с производства и не поддерживают современные протоколы безопасности и мобильные клиенты.
  2. Объем оперативной памяти: Не менее 2 ГБ RAM для плавной работы мобильных клиентов и браузерных оболочек.
  3. Тип сканирующего модуля: Лучше сразу ориентироваться на 2D-сканер (Image-сканер), так как он быстрее считывает потертые штрихкоды и поддерживает маркировку (DataMatrix, QR-коды).
  4. Разрешение и ориентация экрана: На типовых терминалах часто встречаются экраны с разрешением 240х320 или 320х320 пикселей. Это накладывает жесткие требования на размер элементов управления.

3. Адаптация пользовательского интерфейса под малый экран

При использовании сеанса 1С на компактном экране терминала стандартные управляемые формы могут выглядеть перегруженными из-за системных заголовков, командных панелей и отступов. Разберем правила оптимизации форм для ТСД:

  1. Отключение лишних панелей: Скрываем командные панели, заголовки окон и строку состояния. Рекомендуется использовать режим рабочего стола РабочееМесто или Киоск, разворачивающий форму на весь экран.
  2. Минимизация элементов ввода: На экране оператора должны быть только критически важные поля: наименование номенклатуры, артикул/штрихкод, ячейка и поле ввода фактического количества.
  3. Событийная модель: При сканировании штрихкода обработка должна происходить в обработчике внешнего события от сканера, без необходимости ручного нажатия кнопок на экране.

Посмотрим на пример структуры компактного обработчика внешнего события при сканировании на ТСД:


// Обработка внешнего события сканера штрихкодов
&НаКлиенте
Процедура ОбработкаВнешнегоСобытия(Источник, Событие, Данные)
    
    Если Событие = "BarCodeValue" Тогда
        Штрихкод = СокрЛП(Данные);
        ОбработатьШтрихкодНаСервере(Штрихкод);
    КонецЕсли;

КонецПроцедуры

&НаСервере
Процедура ОбработатьШтрихкодНаСервере(Знач Штрихкод)
    
    // Поиск номенклатуры по штрихкоду
    НайденнаяНоменклатура = РегистрыСведений.ШтрихкодыНоменклатуры.НайтиПоШтрихкоду(Штрихкод);
    
    Если ЗначениеЗаполнено(НайденнаяНоменклатура) Тогда
        ТекущаяНоменклатура = НайденнаяНоменклатура;
        // Получение текущего остатка для проверки
        ТекущийОстаток = ПолучитьОстатокПоСкладу(ТекущаяНоменклатура, СкладИнвентаризации);
    Иначе
        Сообщить("Штрихкод не найден в базе!");
    КонецЕсли;

КонецПроцедуры

4. Организация инвентаризации без остановки продаж

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

  1. Методологический риск отображения остатка: Если ревизор видит на экране терминала расчетный остаток программы, возникает человеческий фактор — проверяющий может подогнать фактическое количество под экранную цифру вместо реального пересчета. В классическом аудите рекомендуется «слепой» пересчет, когда факт сопоставляется с остатком уже после закрытия пересчета по конкретной ячейке.
  2. Механизм блокировки продаж: Жесткая транзакционная блокировка таблиц СУБД недопустима, так как она заблокирует работу кассиров. Вместо этого применяется концепция «мягкого» резервирования через неблокирующий регистр сведений. При сканировании товара на ТСД в регистр записывается признак пересчета. Модуль подбора на кассе проверяет этот регистр: если товар пересчитывается прямо сейчас, кассир получает предупреждение. Обязательно настраивается автоматическое снятие блокировки по таймауту на случай, если ревизор отвлекся.
  3. Учет движения товара по времени: В момент сканирования товара на полке необходимо фиксировать точную временную метку. Если покупатель взял товар с полки за минуту до пересчета, а чек пробит через 5 минут после, система при сведении итогов сможет учесть обороты документа реализации и восстановить точную картину расхождений.
← На главную