Как разработать систему управления ТСД для WMS на платформе 1С?

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

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

Выбор архитектуры: RDP, мобильная платформа или мобильный клиент?

Перед началом разработки необходимо определиться с технологическим стеком. Проанализируем основные варианты, доступные на платформе 1С:

  1. RDP (Удаленный рабочий стол): Самый простой путь. Вы рисуете обычные формы или управляемые формы под размер экрана ТСД, и пользователь работает напрямую в базе. Плюсы: мгновенная разработка, отсутствие обменов. Минусы: полная зависимость от Wi-Fi. При малейшем разрыве сессия «отваливается», данные могут не сохраниться.
  2. Мобильное приложение (МП): Полноценное приложение на ТСД со своей локальной базой данных. Плюсы: работа в офлайне, высокая скорость интерфейса. Минусы: необходимость настройки обмена данными (Web-сервисы, HTTP), сложности с драйверами сканеров на специфическом железе.
  3. Мобильный клиент (МК): Тонкий клиент для мобильных устройств. Плюсы: не нужно писать обмен, формы рисуются почти как в основной базе. Минусы: требует стабильного онлайна, хотя современные версии платформы поддерживают «автономный режим».

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

Организация обмена данными через JSON и Web-сервисы

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

Проанализируем пример структуры обмена. При получении задачи мы передаем не только номенклатуру, но и все необходимые разрезы (серии, сроки годности, ячейки). Использование сжатия при передаче JSON позволяет значительно ускорить работу на слабых каналах связи.

Пример кода для обработки задания на ТСД (упрощенно):


// Пример получения данных через HTTP-сервис
Соединение = Новый HTTPСоединение(АдресСервера, Порт, Пользователь, Пароль);
Запрос = Новый HTTPЗапрос("/v1/tasks/get_queue?worker_id=" + Идентификатор);
Ответ = Соединение.Получить(Запрос);

Если Ответ.КодСостояния = 200 Тогда
    ЧтениеJSON = Новый ЧтениеJSON;
    ЧтениеJSON.УстановитьСтроку(Ответ.ПолучитьТелоКакСтроку());
    ДанныеЗадач = ПрочитатьJSON(ЧтениеJSON);
    // Запись в локальную базу мобильного приложения
    Для Каждого Задача Из ДанныеЗадач.Tasks Цикл
        НоваяЗадача = Справочники.ЗадачиТСД.СоздатьЭлемент();
        НоваяЗадача.Наименование = Задача.ID;
        НоваяЗадача.ЯчейкаИсточник = Задача.SrcCell;
        НоваяЗадача.Записать();
    КонецЦикла;
КонецЕсли;

Решение проблем со сканированием и драйверами

Одной из главных проблем при использовании Мобильной платформы 1С является работа со встроенным сканером ТСД. Часто стандартная библиотека МБПО (1С:Библиотека подключаемого оборудования для мобильных устройств) не видит профессиональный сканер или работает с ним некорректно (например, через эмуляцию клавиатуры, что медленно и неудобно).

Выясним причины и способы решения:

  1. Режим Broadcast Intent (Android): Большинство профессиональных ТСД (Zebra, Honeywell, Atol) позволяют настроить системную утилиту сканирования на отправку широковещательного сообщения (Intent) после успешного считывания. Это лучший способ работы.
  2. Проблема версий Android: Старые устройства (например, Zebra MC36 с Android 4.4.2) могут не поддерживаться современными версиями МБПО. В этом случае приходится писать собственную внешнюю компоненту (ВК) на Java.
  3. Нативная внешняя компонента: Позволяет напрямую обращаться к API производителя сканера. Это гарантирует мгновенный отклик и возможность управления настройками луча (включение/выключение подсветки, выбор типов ШК).

Если вы столкнулись с ситуацией, когда стандартное событие ВнешнееСобытие не ловит штрихкод, проверьте настройки DataWedge (для Zebra). Необходимо создать профиль для вашего приложения и указать Intent Output в режиме Broadcast Intent.

Офлайн-логика: почему это важно для WMS

Многие специалисты считают, что WMS обязана быть в онлайне. Однако на практике офлайн-режим — это не «бумажная работа», а способ обеспечить непрерывность процесса. Разберем преимущества:

Практические советы по оптимизации

Рассмотрим несколько нюансов, которые помогут сделать работу ТСД комфортной:

  1. Производительность файловой системы: При больших объемах данных (например, справочник товаров на 200 000 SKU) запись во внутреннюю базу 1С на ТСД может замедляться. Используйте индексацию по штрихкоду и минимизируйте количество полей в локальных справочниках.
  2. Управление через ШК: Чтобы кладовщик меньше тыкал пальцами в экран (особенно в перчатках), внедрите управляющие штрихкоды. Например, ШК с текстом "DONE" для завершения документа или "NEXT" для перехода к следующей строке.
  3. Работа с весами: Если на складе есть весовой товар, рассмотрите возможность подключения весов через Ethernet/IP. Мобильное приложение может напрямую посылать запрос на весы по их IP-адресу, зашитому в штрихкоде на самих весах.

Подводя итог, разработка собственной системы для ТСД на базе 1С оправдана, когда стандартные решения становятся слишком дорогими или неповоротливыми. Использование Мобильной платформы в связке с HTTP-сервисами и внешними компонентами для сканирования позволяет создать гибкий и надежный инструмент для склада любого размера.

← На главную