Как организовать мобильную кассу для курьеров с интеграцией в 1С:УТ 10.3 или КА 1.1?

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

Вопрос автоматизации мобильной торговли и курьерской доставки остается актуальным, особенно для компаний, использующих проверенные временем конфигурации на обычных формах, такие как 1С:Управление торговлей 10.3 или 1С:Комплексная автоматизация 1.1. Основная сложность заключается в том, что современные мобильные приложения ориентированы на протоколы обмена новых версий платформы (8.3 с управляемыми формами), в то время как старым системам требуется доработка механизмов обмена данными.

В данной статье мы подробно разберем, как построить надежную систему для курьеров, которая включает прием заказов, печать чеков согласно 54-ФЗ и автоматическое создание платежных документов в учетной системе.

Анализ требований и выбор архитектуры решения

Прежде чем приступать к реализации, проанализируем базовый бизнес-процесс, который необходимо автоматизировать:

  1. Выгрузка данных: Из основной базы 1С в мобильное устройство курьера должны попадать документы РеализацияТоваровУслуг (РТУ) или ЗаказПокупателя.
  2. Работа на выезде: Курьер находит нужный заказ, при необходимости корректирует количество товара (если клиент отказывается от части позиций).
  3. Фискализация: Печать чека на мобильном принтере или отправка данных на облачную кассу.
  4. Прием оплаты: Поддержка наличных и безналичных платежей (эквайринг).
  5. Обратный обмен: После закрытия смены или в реальном времени в 1С должны создаваться документы ПриходныйКассовыйОрдер (ПКО) или ОплатаОтПокупателяПлатежнойКартой с привязкой к исходной РТУ.

Вариант 1: Использование «1С:Мобильная касса» с доработкой обмена

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

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

Для организации обмена нам потребуется написать собственную обработку на стороне 1С (УТ 10.3), которая будет формировать файлы обмена (обычно в формате XML или JSON) и отправлять их в мобильное приложение. Проанализируем структуру кода для выгрузки заказов:


// Пример упрощенной логики подготовки данных для мобильного устройства
Процедура ВыгрузитьЗаказыДляКурьера(ВыбранныйКурьер)
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   РеализацияТоваровУслуг.Ссылка,
        |   РеализацияТоваровУслуг.Номер,
        |   РеализацияТоваровУслуг.СуммаДокумента,
        |   РеализацияТоваровУслуг.Контрагент.Наименование КАК Клиент
        |ИЗ
        |   Документ.РеализацияТоваровУслуг КАК РеализацияТоваровУслуг
        |ГДЕ
        |   РеализацияТоваровУслуг.Курьер = &Курьер
        |   И РеализацияТоваровУслуг.Проведен = ИСТИНА";
    
    Запрос.УстановитьПараметр("Курьер", ВыбранныйКурьер);
    Результат = Запрос.Выполнить().Выбрать();
    
    Пока Результат.Следующий() Цикл
        // Формируем структуру для передачи в мобильное приложение
        ДанныеЗаказа = Новый Структура("ID, Номер, Сумма, Клиент");
        ЗаполнитьЗначенияСвойств(ДанныеЗаказа, Результат);
        // Далее следует код сериализации в JSON и отправки через Web-сервис или файл
    КонецЦикла;
КонецПроцедуры

При использовании этого варианта важно помнить, что 1С:Мобильная касса требует настройки синхронизации через «1С:Предприятие», поэтому на стороне УТ 10.3 придется реализовать механизм, имитирующий поведение современных конфигураций в части обмена данными.

Вариант 2: Использование «Агент Плюс: Мобильная торговля»

Многие специалисты смотрят в сторону системы Агент Плюс. Проанализируем ситуацию, с которой часто сталкиваются пользователи: в демо-версии кажется, что функционала работы с заказами из РТУ нет. Однако это заблуждение.

Выясним причину: стандартные правила обмена в «Агент Плюс» могут быть настроены на документ ЗаказПокупателя, а не на РеализацияТоваровУслуг. Чтобы система начала «видеть» заказы, необходимо:

Преимущество: «Агент Плюс» имеет очень гибкий SDK, что позволяет программисту 1С полностью переписать логику работы мобильного рабочего места под конкретные нужды бизнеса.

Вариант 3: Современные облачные решения и Grotem

Разберем ситуацию с решением Grotem.Express. Несмотря на то что менеджеры могут заявлять об отсутствии поддержки старых конфигураций, технически это ограничение обходится через открытый API. Если компания не хочет тратить ресурсы на поддержку собственного сервера мобильных приложений, использование облачной «прослойки» становится оптимальным.

Схема работы выглядит так: 1С:УТ 10.3 -> HTTP-запрос (JSON) -> Облако Grotem -> Приложение курьера.

Рассмотрим преимущества такого подхода для работы с эквайрингом. Современные приложения позволяют использовать технологию Tap on Phone. Проанализируем, как это упрощает жизнь курьеру: ему больше не нужно носить с собой терминал Сбербанка. Смартфон с NFC-чипом сам принимает оплату, а данные о транзакции автоматически возвращаются в 1С в виде подтвержденной Оплаты от покупателя платежной картой.

Технология «Облачного чека» — экономия на оборудовании

Важным этапом развития мобильной торговли стала возможность удаленной фискализации. Рассмотрим, как это работает программно. Вместо того чтобы покупать каждому курьеру АТОЛ 11Ф, мы можем использовать одну мощную кассу, установленную в офисе.

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

  1. Курьер в приложении нажимает «Оплатить».
  2. Приложение отправляет пакет данных в центральную базу 1С.
  3. 1С отправляет команду на фискализацию чека на офисную кассу.
  4. Касса пробивает чек, и ОФД отправляет электронную копию клиенту на e-mail или телефон.
  5. Курьер на экране показывает QR-код чека.

Это решение полностью соответствует 54-ФЗ для курьерской доставки и существенно снижает затраты на обслуживание парка кассовой техники.

Обработка частичных отказов и возвратов

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

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


// Логика обработки частичного возврата
Если СуммаОплаты < СуммаРеализации Тогда
    // Создаем документ "Корректировка реализации" или правим текущий
    // В УТ 10.3 часто создают "Возврат товаров от покупателя"
    ВозвратДок = Документы.ВозвратТоваровОтПокупателя.СоздатьДокумент();
    ВозвратДок.Дата = ТекущаяДата();
    ВозвратДок.Основание = СсылкаНаРТУ;
    // ... Заполнение табличной части расхождениями ...
    ВозвратДок.Записать(РежимЗаписиДокумента.Проведение);
КонецЕсли;

Рекомендации по выбору

Проанализируем ситуацию и подведем итог:

Помните, что для стабильной работы со старыми конфигурациями ключевым моментом является надежность канала связи и наличие механизма «очереди сообщений», чтобы данные о продажах не терялись при плохом интернете у курьера.

← На главную