Интеграция приложения доставки с 1С: заказы, статусы и документы

Что должна решать интеграция

Интеграция приложения доставки с 1С нужна, чтобы заказ попадал к исполнителю без повторного ввода, а результат доставки возвращался в учётную систему. Но отправить данные по API недостаточно. Нужно договориться, кто ими управляет, что означает каждый статус и как восстановить обмен после сбоя.

Представьте ситуацию: курьер отметил доставку, связь оборвалась, приложение повторило запрос. Если сервер воспринимает каждую отправку как новое событие, в учёте возникают дубли. Другой пример: диспетчер отменил заказ, пока водитель работал без интернета. После подключения система должна разобрать конфликт, а не молча принять последнее пришедшее сообщение.

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

Что выяснить до оценки работ

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

Фраза «у нас 1С» не определяет состав интеграции. Объекты, права, расширения и правила проведения документов могут различаться. Для первичного обсуждения достаточно схемы и обезличенных примеров; рабочие пароли и клиентские базы передавать в открытой переписке не нужно.

Какие данные передавать и кто за них отвечает

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

Пример договора обмена — адаптируется под проект
Данные	Направление	Что согласовать
Заказ и состав груза	1С → сервер приложения	Идентификатор, версия, состав, ограничения и отмена
Адрес и контакт	Учётная система → назначенный исполнитель	Обязательные поля, исправления, доступ по роли
Назначение и маршрут	TMS или диспетчер → приложение	Единственный источник задания и смена водителя
Результат доставки	Приложение → сервер → 1С	Статус, причина, время события и время получения
Фото и подтверждения	Приложение → хранилище; ссылка → 1С	Связь с заказом, доступ, повторная загрузка, срок хранения

Не копируйте в телефон всю учётную базу. Для выполнения задания обычно нужен ограниченный набор полей. Состав данных и длительность их доступности нужно согласовать с владельцами процесса и ответственными за защиту информации.

HTTP-сервисы, OData или готовый обмен

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

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

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

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

Как избежать дублей и потери статусов

Идентификатор события и повторная отправка

У каждого события должен быть устойчивый идентификатор. Если подтверждение доставки отправлено повторно, сервер должен распознать уже обработанное событие и вернуть результат, не выполняя операцию ещё раз. Такую обработку называют идемпотентной.

Версия заказа и допустимые переходы

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

Очередь и подтверждение приёма

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

Разбор ошибок и сверка

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

Что делать с документами и вложениями

Разделите операционное событие и учётный документ. Нажатие «Доставлено» не обязано автоматически проводить реализацию или закрывать все связанные документы. Команда должна согласовать, какие действия запускаются сразу, какие после проверки, а какие остаются у сотрудника.

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

Если проект включает юридически значимый электронный документооборот, вынесите его в отдельный набор требований и согласуйте с профильными специалистами. В этой статье рассматривается технический обмен; фото или рисунок подписи на экране не следует автоматически приравнивать к завершённому процессу ЭДО.

Чек-лист проверки перед запуском

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

Для приёмки задайте измеримые критерии: допустимую задержку, порядок обработки накопившейся очереди, способ сверки и срок реакции на сбой. Численные значения выбирают под процесс и нагрузку, а не берут из универсального шаблона.

Частые вопросы

Можно интегрировать приложение без изменения 1С?

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

Обмен обязательно должен быть мгновенным?

Нет. Срочность зависит от данных: отмена активного задания и обновление справочника могут иметь разные требования. Для каждого потока согласуйте допустимую задержку и поведение при её превышении.

Что подготовить для оценки интеграции?

Версии систем, список объектов обмена, обезличенные примеры заказов, правила статусов и ожидаемую нагрузку. Для обсуждения доступны интеграции и API AppLogistics.

Продолжить планирование помогут материалы о выборе готового или заказного решения и о составе MVP приложения водителя.