При автоматизации складского учета с использованием терминалов сбора данных (ТСД) перед разработчиком неизбежно встает вопрос: какую технологию мобильной разработки «1С» выбрать? На рынке существуют два основных подхода: Мобильное приложение (МП) и Мобильный клиент (МК). Каждый из них имеет свои архитектурные особенности, требования к сетевой инфраструктуре, лицензированию и скорости разработки.
В этой статье мы подробно разберем различия этих технологий, проанализируем практический опыт интеграции ТСД (на примере популярного устройства Атол Смарт.Лайт), рассмотрим вопросы подключения сканеров штрихкодов, обработки кодов маркировки DataMatrix и выберем оптимальную архитектуру под ваши задачи.
Для начала давайте разграничим понятия, так как в терминологии мобильной платформы «1С» легко запутаться. Рассмотрим ключевые различия:
Давайте проанализируем плюсы и минусы каждого подхода с технической точки зрения.
Если на вашем складе невозможно обеспечить качественное бесшовное покрытие Wi-Fi, то классический онлайн-клиент будет постоянно выдавать ошибки связи при переходе между точками доступа. Однако, как показывает практика, мобильный клиент «1С» достаточно устойчив к кратковременным разрывам соединения.
Рассмотрим механизм работы веб-соединения. В отличие от сторонних веб-интерфейсов, которые требуют постоянной активной сессии и критичны к малейшим потерям пакетов, мобильный клиент оптимизирован для работы по протоколам HTTP/HTTPS. Он передает данные пакетами, и кратковременное пропадание сигнала Wi-Fi в момент перемещения сотрудника по складу не приводит к аварийному завершению сеанса. Но если связь отсутствует минутами, работать без автономного режима будет невозможно.
Выясним, где «писанины» меньше, а разработка проще. Здесь мнения разработчиков разделяются, но мы можем выделить четкую закономерность:
Рассмотрим промежуточный и наиболее изящный вариант решения проблемы интерфейса. Вместо адаптации тяжелых типовых форм основной конфигурации (например, формы документа «Приобретение товаров и услуг» в ERP), мы создаем в основной базе отдельное рабочее место (АРМ) складского сотрудника. Это специализированная обработка с крупными кнопками и полями ввода, оптимизированная под разрешение экрана ТСД. Мобильный клиент запускает именно это АРМ. В результате мы получаем простоту разработки (код пишется в одной конфигурации) и удобный складской интерфейс.
Одной из главных проблем при разработке под ТСД является интеграция встроенного лазерного или светодиодного сканера штрихкодов. На ТСД Атол Смарт.Лайт сканер работает на уровне операционной системы Android. Он может передавать данные двумя способами: путем эмуляции нажатия клавиш (ввод штрихкода в активное текстовое поле) или через широковещательные сообщения (Android Intent Broadcast).
Для корректной работы в «1С» первый вариант (эмуляция клавиатуры) крайне неудобен: сотруднику придется каждый раз вручную устанавливать фокус в поле ввода штрихкода перед сканированием. Поэтому рассмотрим настройку через механизм внешнего события.
Разберем по шагам, как настроить сканер на ТСД Атол под управлением Android:
android.intent.action.BARCODEEXPORT.barcode_string.В самой платформе «1С» для перехвата этого события используется внешняя компонента. Вы можете задействовать мобильную Библиотеку подключаемого оборудования (БПО) от «1С» или использовать сторонние внешние компоненты, написанные под Android.
Посмотрим на пример обработки входящего штрихкода в коде управляемой формы «1С» при использовании внешней компоненты:
&НаКлиенте
Процедура ПриВнешнемСобытии(Источник, Событие, Данные)
// Проанализируем источник события
Если Источник = "СканерШтрихкодов" Или Событие = "Barcode" Тогда
// Полученные данные могут содержать XML со сложной структурой
// Очистим строку от лишних символов
ОчищенныйШтрихкод = СокрЛП(Данные);
// Запустим процесс обработки на сервере
ОбработатьСканированиеНаСервере(ОчищенныйШтрихкод);
КонецЕсли;
КонецПроцедуры
При работе с маркированной продукцией (система «Честный Знак», штрихкоды DataMatrix) драйвер сканера ТСД может возвращать спецсимволы, такие как символы разделителей групп GS (Group Separator, ASCII 29). При написании кода разбора штрихкода обязательно учитывайте наличие этих символов, так как без них невозможно корректно разобрать структуру кода маркировки и вычленить криптохвост.
Если вы решили делать выбор в пользу Мобильного приложения (МП), но хотите избежать громоздких планов обмена, отличной альтернативой является использование связки МП + HTTP-сервисы на сервере.
В этом сценарии локальное мобильное приложение не хранит тяжелые справочники номенклатуры. При сканировании штрихкода мобильное приложение отправляет быстрый асинхронный HTTP-запрос к серверной базе «1С». Сервер мгновенно обрабатывает запрос, ищет номенклатуру и возвращает мобильному приложению JSON-пакет с детальной информацией о товаре (наименование, остаток, цена, характеристики).
Рассмотрим пример кода на стороне мобильного приложения для отправки запроса к серверу «1С»:
&НаКлиенте
Функция ПолучитьДанныеТовараССервера(Штрихкод) Экспорт
// Создаем HTTP-соединение с сервером публикации основной базы
Соединение = Новый HTTPСоединение("192.168.1.100", , "Администратор", "Пароль");
// Формируем запрос к нашему HTTP-сервису
АдресРесурса = "/Base/hs/WarehouseAPI/v1/product?barcode=" + Штрихкод;
Запрос = Новый HTTPЗапрос(АдресРесурса);
Попытка
Ответ = Соединение.Получить(Запрос);
Если Ответ.КодСостояния = 200 Тогда
// Читаем JSON ответ сервера
ЧтениеJSON = Новый ЧтениеJSON;
ЧтениеJSON.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
ДанныеТовара = ПрочитатьJSON(ЧтениеJSON);
ЧтениеJSON.Закрыть();
Возврат ДанныеТовара;
Иначе
ВызватьИсключение "Ошибка сервера: " + Ответ.КодСостояния;
КонецЕсли;
Исключение
Сообщить("Не удалось связаться с сервером: " + ОписаниеОшибки());
Возврат Неопределено;
КонецПопытки;
КонецФункции
Этот подход совмещает в себе надежность мобильного приложения (оно продолжит работать, формы не зависнут при потере связи) и актуальность данных мобильного клиента (информация о товарах запрашивается в реальном времени).
Лицензионная политика фирмы «1С» для мобильных решений часто вызывает вопросы у разработчиков. Давайте проанализируем правила распределения лицензий:
Для принятия окончательного решения сопоставим ключевые параметры в виде таблицы-матрицы выбора:
| Критерий оценки | Мобильное приложение (МП) | Мобильный клиент (МК) |
|---|---|---|
| Зависимость от Wi-Fi | Минимальная (работает полностью автономно) | Критическая (требуется постоянный онлайн) |
| Сложность разработки | Высокая (нужно писать механизмы синхронизации) | Низкая (код пишется в основной базе без обменов) |
| Адаптация интерфейса | Требуется разработка мобильных форм с нуля | Платформа автоматически адаптирует формы, но требуется доработка под экраны ТСД |
| Стоимость лицензий | Требуются лицензии на мобильные рабочие места | Использует стандартный серверный пул лицензий |
| Актуальность данных | Данные актуальны на момент последнего обмена | Абсолютная актуальность (работа напрямую в СУБД) |
Подводя итог нашему анализу, дадим практические рекомендации:
Выбирайте Мобильный клиент (МК), если у вас на складе развернута стабильная бесшовная сеть Wi-Fi, а складской учет ведется в режиме реального времени. Вы сэкономите колоссальное количество времени на разработке схем обмена данными, а ваши сотрудники будут сразу видеть актуальные остатки товаров на экранах ТСД. Для минимизации трудозатрат на верстку экранов просто создайте в основной конфигурации отдельный интерфейс (АРМ) с крупными элементами управления, адаптированными под вертикальное разрешение ТСД.
Выбирайте Мобильное приложение (МП) или гибридный вариант с автономным режимом, если склад находится в подвальном помещении, имеет зоны экранирования металлическими конструкциями, либо если работы ведутся на выезде (мобильные курьеры, экспедиторы). В этом случае стабильность работы приложения перевешивает затраты на проектирование механизмов интеграции и синхронизации данных через HTTP-сервисы.