Как организовать помарочный учет алкоголя в 1С 7.7 с использованием ТСД на Android?

Программист 1С v7.7 Управленческий учет Торговля и дистрибуция
← На главную

Переход на помарочный учет алкогольной продукции (ЕГАИС 3.0 и выше) в рамках платформы 1С 7.7 представляет собой серьезный технический вызов. Проблема заключается не только в возрасте самой платформы, но и в физических ограничениях передачи данных. Современные акцизные марки и коды DataMatrix могут содержать до 150 символов, что создает трудности при использовании классических методов ввода. В данной статье мы подробно разберем, как выбрать оборудование и настроить взаимодействие между Android-устройствами и «семеркой».

Выбор оборудования: на что обратить внимание

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

  1. 2D-имиджер (Area Imager): Это обязательное условие. Старые лазерные сканеры не способны считывать двумерные коды PDF417 (на старых марках) и DataMatrix (на новых марках и Честном ЗНАКе). Мы рекомендуем выбирать устройства с модулями от Zebra или Honeywell, так как они обеспечивают быструю фокусировку даже на поврежденных или бликующих поверхностях.
  2. Операционная система: Android версии 9.0 и выше. Хотя 1С 7.7 — система почтенного возраста, современное программное обеспечение для ТСД требует актуальных библиотек Android.
  3. Защищенность: Складской учет предполагает падения и пыль, поэтому стандарт защиты IP65/IP67 будет крайне полезен.

Проанализируем конкретные модели. В бюджетном сегменте хорошо себя зарекомендовали Atol Smart.Droid и Urovo i6310. В более высоком классе стоит обратить внимание на Zebra TC21 или Honeywell ScanPal EDA52.

Проблема передачи 150 символов через RDP

Многие разработчики по привычке пытаются использовать ТСД как «клавиатуру» в терминальной сессии (RDP). Выясним, почему это плохая идея для помарочного учета. Длинная марка (150 символов) при эмуляции клавиатуры превращается в 300 событий (нажатие и отпускание клавиши). Буфер клавиатуры в Windows и протокол RDP часто не справляются с таким потоком данных в один пакет.

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

Для решения этой проблемы при работе через RDP необходимо использовать специализированные утилиты-драйверы на ТСД (например, ipDataWedge), которые позволяют отправлять данные не как нажатия клавиш, а как единый блок данных через сетевой стек.

Вариант 1: Использование специализированного ПО (Middleware)

Это самый надежный способ интеграции. Мы не заставляем 1С 7.7 «общаться» напрямую с Android, а используем промежуточное звено. Рассмотрим такие решения, как Cleverence (Склад 15) или DataMobile.

Схема работы выглядит следующим образом:

  1. На ТСД устанавливается клиентское приложение, которое имеет встроенную логику проверки марок.
  2. На стороне сервера 1С устанавливается промежуточная база или специальная компонента.
  3. Обмен данными происходит через файлы (XML/JSON) или напрямую через таблицы SQL (если 1С 7.7 работает на SQL-версии).

Это позволяет ТСД работать автономно. Даже если Wi-Fi пропадет в дальней части склада, сотрудник сможет продолжить сканирование, а при возвращении в зону покрытия данные будут синхронизированы. 1С 7.7 в этом случае просто получает готовый список проверенных марок в документ ПриходнаяНакладная или Реализация.

Вариант 2: Организация обмена через HTTP-сервисы или Web-сокеты

Поскольку 1С 7.7 штатно не умеет создавать HTTP-сервисы, мы можем реализовать «мост». Рассмотрим архитектуру с использованием легкого веб-сервера (например, на Python, PHP или Node.js).

Проанализируем алгоритм взаимодействия:

  1. Приложение на ТСД считывает марку.
  2. ТСД отправляет POST-запрос на веб-сервер с данными марки.
  3. Веб-сервер записывает данные в промежуточную таблицу SQL или создает текстовый файл в папке обмена 1С.
  4. В 1С 7.7 запущена обработка ожидания (Форма.ОбработкаОжидания), которая раз в секунду проверяет наличие новых данных и подтягивает их в форму документа.

Пример логики обработки файла в 1С 7.7 может выглядеть так:


Процедура ПроверитьНовыеСканирования()
    Текст = СоздатьОбъект("Текст");
    ИмяФайла = "C:\Exchange\scan.txt";
    Если ФС.СуществуетФайл(ИмяФайла) = 1 Тогда
        Текст.Открыть(ИмяФайла);
        Для НомерСтроки = 1 По Текст.КоличествоСтрок() Цикл
            ШтрихкодМарки = Текст.ПолучитьСтроку(НомерСтроки);
            // Обработка марки: поиск в базе, проверка ЕГАИС
            ОбработатьМарку(ШтрихкодМарки);
        КонецЦикла;
        Текст.Очистить();
        Текст.Записать(ИмяФайла);
        ФС.УдалитьФайл(ИмяФайла);
    КонецЕсли;
КонецПроцедуры

Вариант 3: Использование Intent (Android) и внешних компонент

Если вы все же решили использовать RDP, настройте сканер ТСД на передачу данных через Intent. Это системное сообщение Android, которое передает весь штрихкод целиком. На стороне терминального сервера должна работать внешняя компонента, способная перехватывать эти данные.

Разберем преимущества этого подхода:

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

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

Рассмотрим важный аспект: Разрешительный режим. С 2024 года требования к проверке марок ужесточились. Если ваша 1С 7.7 не может напрямую обратиться к API «Честного ЗНАКа» или ЕГАИС из-за устаревших протоколов шифрования TLS, использование ТСД с современным ПО становится единственным выходом, так как ТСД сам выполнит онлайн-проверку и выдаст результат: «Разрешено» или «Запрещено».

Подводя итог, скажем: работа с ТСД на Android в связке с 1С 7.7 возможна и эффективна, если отказаться от примитивной эмуляции клавиатуры в пользу обмена данными через файлы, SQL или специализированные Middleware-решения. Это обеспечит стабильность учета и соответствие всем требованиям законодательства.

← На главную