Как привязать GPS-координаты торговых точек к договорам контрагентов в мобильной торговле 1С

← На главную

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

Причины архитектурного конфликта структур данных

Проанализируем предпосылки проблемы. Большинство коробочных мобильных систем проектируют свои мобильные базы на автономных СУБД (например, SQLite), стремясь минимизировать объем передаваемых данных и упростить интерфейс торгового представителя. В их стандартной модели сущность «Точка маршрута» строго эквивалентна юридическому лицу из справочника Контрагенты.

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

Способ 1. Создание промежуточной буферной базы 1С

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

Разберем по шагам логику работы такой схемы:

Трансформация справочников при выгрузке: Настраиваем регулярный обмен между рабочей и буферной базой. В процессе переноса справочника Контрагенты каждая пара «Контрагент + Договор» из рабочей базы конвертируется в отдельный элемент справочника Контрагенты буферной базы. Наименование формируется составным, например: "ООО Вектор (Магазин №5)".
Привязка координат: В буферной базе система мобильной торговли работает по своей штатной схеме: каждый сгенерированный контрагент имеет собственные координаты GPS, персональную историю продаж и индивидуальный долг.
Обратный сбор документов: Торговые агенты выгружают созданные заказы в буферную базу. Так как в буферной базе контрагент однозначно соответствует конкретному договору рабочей базы, операторы или регламентное задание переносят готовые документы в рабочую базу, разделяя сущность обратно на исходного контрагента и его договор.

Главное преимущество такого подхода — полное снятие блокировок с рабочей информационной базы. Когда десятки мобильных сотрудников одновременно запрашивают остатки или выгружают заказы, они нагружают буферную базу. Рабочая база полностью освобождается для операторов и складских служб.

Способ 2. Виртуализация торговых точек в модуле выгрузки обмена

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

Модули сопряжения коробочных систем на стороне 1С, как правило, открыты для редактирования. Вместо физического создания новых элементов мы можем синтезировать виртуальных клиентов «на лету» в момент формирования пакета данных для КПК.

Разберем алгоритм переопределения выгрузки:

В обработке выгрузки находим процедуру выборки клиентов. Вместо прямой выборки из справочника Контрагенты строим запрос по связке контрагентов и их действующих договоров.
Формируем составной уникальный идентификатор для мобильного устройства, объединяющий идентификатор контрагента и идентификатор договора (например, через разделитель СтрШаблон("%1_%2", ИДКонтрагента, ИДДоговора)).
GPS-координаты передаются в мобильное приложение из реквизитов договора или подчиненного регистра сведений.
В процедуре загрузки документов от КПК разбираем полученный составной идентификатор и заполняем в документе ЗаказПокупателя стандартные реквизиты: Контрагент и ДоговорКонтрагента.

Посмотрим на пример запроса, объединяющего контрагента и его договоры для передачи в мобильное приложение:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	Договоры.Ссылка КАК Договор,
    |	Договоры.Владелец КАК Контрагент,
    |	Договоры.Владелец.Код КАК КодКонтрагента,
    |	Договоры.Код КАК КодДоговора,
    |	Договоры.Наименование КАК ИмяТочки,
    |	ЕСТЬNULL(КоординатыТТ.Широта, 0) КАК Широта,
    |	ЕСТЬNULL(КоординатыТТ.Долгота, 0) КАК Долгота
    |ИЗ
    |	Справочник.ДоговорыКонтрагентов КАК Договоры
    |	ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.КоординатыТорговыхТочек КАК КоординатыТТ
    |		ПО Договоры.Ссылка = КоординатыТТ.ТорговаяТочка
    |ГДЕ
    |	НЕ Договоры.ПометкаУдаления
    |	И НЕ Договоры.Владелец.ПометкаУдаления";

Результат = Запрос.Выполнить().Выгрузить();

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

Особенности контроля геолокации и технические ограничения

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

Фоновое энергосбережение Android: Начиная с Android 8 и выше, операционная система агрессивно выгружает фоновые службы геолокации. Чтобы координаты торговых точек определялись точно, мобильное приложение должно быть внесено в список исключений оптимизации батареи на устройстве сотрудника.
«Холодный старт» GPS: Если координаты запрашиваются только в момент нажатия кнопки создания документа внутри торговой точки (в помещении или торговом центре), сигнал со спутников может отсутствовать. Надежные системы комбинируют данные спутников с координатами вышек сотовой связи и BSSID точек Wi-Fi.
Борьба с фиктивными координатами: Установка приложений эмуляции местоположения (Mock Locations) часто используется сотрудниками для фиктивного закрытия маршрута. Контроль достоверности требует запрета режима разработчика на служебных смартфонах либо проверки флага фиктивных координат на уровне мобильного клиента.

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