Офлайн-режим и синхронизация с 1С в приложении торгового агента

Агент принял заказ в магазине на цокольном этаже, где нет связи, пошёл в следующую точку, там оформил возврат, а между ними 1С успела поменять цену на акционную позицию и списать остаток под заказ другого агента. Когда телефон наконец поймает сеть, системе нужно правильно принять оба документа, не задвоить их, пересчитать то, что изменилось, и сообщить агенту о проблемах понятным языком. Это и есть задача офлайн-синхронизации.

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

Принцип: приложение работает с локальной базой всегда

Частая ошибка — делать «онлайн-приложение с кэшем»: экраны грузят данные с сервера, а при отсутствии сети показывают последнюю копию. Такой подход ломается на первом же подвале. Надёжнее обратная схема — offline-first: приложение всегда читает и пишет в локальную базу на устройстве, а синхронизация — отдельный фоновый процесс, который обменивается изменениями с сервером, когда есть связь.

• Локальная база (обычно SQLite или надстройка над ней) хранит справочники агента и его документы.
• Сервер синхронизации — посредник между устройствами и 1С. Напрямую подключать сотни телефонов к 1С неудобно и рискованно: нагрузка, безопасность, версии.
• Обмен с 1С идёт между сервером и учётной системой по расписанию или по событиям — через HTTP-сервисы, OData или обмен пакетами, в зависимости от конфигурации.

Что синхронизируется и в какую сторону

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

Агенту не нужна вся база 1С. Ему нужны точки его территории, ассортимент, доступный этим точкам, и их условия. Фильтрация на сервере сокращает объём данных на устройстве и время первой синхронизации, а заодно ограничивает, что окажется на потерянном телефоне.

Очередь изменений на устройстве

Всё, что агент создаёт или меняет, сначала записывается в локальную базу, а затем — в очередь исходящих изменений. Очередь отправляется на сервер, когда есть связь. Ключевые правила:

1. Глобальный идентификатор документа создаётся на устройстве (например, UUID) в момент создания заказа. Номер документа 1С присвоит позже, а до этого документ узнаётся по UUID.
2. Идемпотентность: сервер, получив документ с уже известным UUID, не создаёт второй, а возвращает тот же результат. Это защищает от дублей, когда ответ сервера потерялся и телефон отправил пакет повторно.
3. Порядок: изменения одного документа отправляются в порядке создания; новая точка уходит раньше заказа на неё.
4. Статусы документа видны агенту: сохранён на устройстве → отправлен → принят сервером → загружен в 1С → проведён или отклонён с причиной.
5. Фото отправляются отдельно от документов и не блокируют очередь: заказ важнее картинки, и его нужно доставить первым.

Справочники и версии записей

Отправлять агенту весь справочник при каждом обмене — дорого и медленно. Стандартный приём — инкрементальная синхронизация по версии: у каждой записи на сервере есть номер изменения (монотонно растущий счётчик или отметка времени). Устройство помнит последний полученный номер и запрашивает только то, что изменилось после него. Удалённые записи передаются как пометка удаления, а не пропадают молча — иначе на устройстве останутся «призраки».

В 1С для отслеживания изменений можно использовать механизм планов обмена или регистрацию изменений через доработку, в зависимости от конфигурации и того, допустимо ли её менять. Это решается на этапе проектирования вместе с теми, кто сопровождает 1С. Подробнее о том, как не получить дубли контрагентов и номенклатуры при интеграции, — в статье интеграция CRM дистрибьютора с 1С и на странице интеграции CRM с 1С.

Остатки и цены: данные, которые устаревают

Остатки

Остаток на устройстве — всегда снимок на момент последней синхронизации. Агент должен видеть, насколько он свежий. Практика: показывать время снимка, а при заказе, когда сеть есть, — проверять остаток на сервере. Окончательно остаток резервируется только в учётной системе: если два агента в офлайне продали последние десять коробок, один из заказов при загрузке получит частичное подтверждение. Это нормальный бизнес-исход, а не ошибка, — важно, чтобы приложение показало его агенту, а оператор получил задачу. Как держать остатки актуальными между складом и каналами продаж — на странице синхронизации остатков.

Цены

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

Конфликты: когда две стороны изменили одно и то же

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

Ещё одно правило: конфликт, который система не может разрешить сама, превращается в задачу человеку — оператору или супервайзеру — с понятным описанием. Молча отклонённый заказ хуже, чем отсутствие приложения.

Версии приложения, схема данных и безопасность

Агенты обновляют приложение не одновременно. Кто-то в отпуске, кто-то отключил автообновление. Значит, сервер какое-то время работает с несколькими версиями клиента, и это нужно предусмотреть:

• Версионирование API синхронизации: клиент сообщает свою версию, сервер отвечает в совместимом формате.
• Миграции локальной базы при обновлении приложения — без потери неотправленных документов. Перед миграцией очередь желательно отправить.
• Минимальная поддерживаемая версия: если изменение несовместимо (например, новая логика скидок), сервер просит обновиться, но всё равно принимает уже созданные документы.
• Журнал синхронизации на сервере по каждому устройству: что пришло, что ушло, какие ошибки. Без него разбор жалобы «у меня пропал заказ» превращается в гадание.

Безопасность и потерянный телефон

На устройстве агента лежат цены, клиенты, долги — коммерческая информация и персональные данные контактных лиц. Минимум: вход по личной учётной записи, хранение токенов в защищённом хранилище ОС, шифрование чувствительных данных, удалённый отзыв доступа с очисткой данных при следующем подключении, ограничение данных территорией агента. Если обмен с 1С идёт через собственный сервер, это также точка контроля: журнал, ограничения частоты запросов, проверка прав на каждый запрос.

С чего начать проектирование

1. Составить карту данных: сущности, направление, владелец, частота изменения.
2. Решить, как отслеживать изменения в 1С: типовые механизмы или доработка конфигурации.
3. Записать бизнес-правила конфликтов: цены, остатки, правки справочников, поздние изменения заказов.
4. Определить объём данных на одного агента и время первой синхронизации.
5. Заложить статусы документов, журнал и версионирование API с первой версии — потом их добавить сложнее.

Если обмен нужно связать не только с 1С, но и с B2B-порталом, логистикой или маркетплейсами, сервер синхронизации становится частью общей интеграционной схемы — такие задачи решаются через API-интеграцию на заказ. О выборе между готовой SFA и своей разработкой — в статье приложение для торговых агентов: своя разработка вместо готовой SFA.