Интеграция приложения доставки с 1С: заказы, статусы и документы
3 сентября 2026
Как связать приложение доставки с 1С: состав обмена, выбор API, защита от дублей, обработка ошибок и чек-лист проверки перед запуском.
Автор: Елена Василькова
Начните с процесса, а не со списка продуктов
Когда диспетчер распределяет заказы в таблице, водители отчитываются в мессенджере, а оператор переносит результаты в 1С, хочется заменить всё одной системой. Но сначала нужно понять, где именно теряются время и информация. Иначе новое приложение лишь перенесёт старый беспорядок на другой экран.
Короткий ориентир: готовое решение стоит проверять первым, если ваши основные операции укладываются в его возможности. Заказную разработку имеет смысл рассматривать, когда подтверждены критичные ограничения готовых продуктов. Между ними есть третий вариант — оставить учётную систему и разработать недостающий модуль или мобильный интерфейс.
Выпишите путь одного заказа: от поступления до отгрузки, доставки, возврата и закрытия документов. Для каждого шага укажите ответственного, систему, входные данные и результат. Отдельно отметьте исключения: клиент перенёс время, часть груза не принята, водитель заменён, связь пропала. Именно на исключениях обычно обнаруживаются ограничения решения.
Три подхода к автоматизации
| Критерий | Готовое решение | Заказная разработка | Гибридный подход |
|---|---|---|---|
| Процессы | Настраиваются в пределах продукта | Проектируются под согласованные сценарии | Стандартные операции остаются в готовой системе |
| Запуск | Нужны настройка, перенос данных и обучение | Нужны проектирование, разработка и испытания | Нужны интеграция и проверка границ ответственности |
| Изменения | Зависят от настроек, API и планов поставщика | Зависят от архитектуры и доступности команды | Требуют совместимости двух частей |
| Расходы | Лицензии или подписка, внедрение, сопровождение | Разработка, инфраструктура, развитие и поддержка | Лицензии плюс разработка и поддержка интеграции |
Это рамка сравнения, а не рейтинг технологий. Готовый продукт может поддерживать сложные настройки, а заказная система — оказаться неудобной и дорогой в изменении. Ответ дают демонстрация ваших сценариев и пилот, а не название подхода.
Когда подходит готовая система
Готовое решение удобно проверять, когда задача понятна: получать заказы, распределять их по исполнителям, контролировать статусы и видеть отклонения. При этом команда готова принять предусмотренный продуктом порядок работы, а необходимые интеграции доступны и проверены.
Например, в официальном описании 1С:TMS представлены планирование перевозок, взаимодействие с мобильными исполнителями и обмен со складской системой. Наличие этих функций — основание включить продукт в проверку, но не доказательство совместимости с вашей конфигурацией, оборудованием и правилами доставки.
Попросите поставщика показать не абстрактный маршрут, а обезличенный пример вашей смены: несколько типов заказов, перенос доставки, частичный отказ и возврат. Уточните, какие действия выполняются стандартно, какие требуют доработки, а какие пока невозможны. Ответ «можно через API» должен сопровождаться описанием интерфейса, ограничений и ответственного за реализацию.
Когда оправдана заказная разработка
Собственная система становится аргументированным выбором, если важный для бизнеса сценарий невозможно надёжно реализовать настройками или отдельной интеграцией. Примеры требований для проверки: нестандартное распределение заказов между подрядчиками, особые правила загрузки, единый интерфейс для нескольких учётных систем, работа на специфическом оборудовании.
Важно отличать реальное ограничение от привычки. Требование «экран должен повторять нашу таблицу» само по себе не обосновывает разработку. Требование «после частичной приёмки нужно сохранить причины расхождений и передать их в два разных учётных контура» уже описывает проверяемую задачу.
До старта определите владельца продукта со стороны компании, порядок принятия решений и ресурсы на сопровождение. Вместе с работающим кодом нужны документация, доступы к инфраструктуре, резервное копирование и понятная процедура выпуска обновлений. Заказная разработка не устраняет зависимость от исполнителей автоматически: условия передачи и дальнейшей поддержки нужно согласовать отдельно.
Когда лучше доработать только недостающую часть
Если 1С уже ведёт заказы, а TMS устраивает диспетчеров, не обязательно заменять обе системы ради удобного приложения водителя. Можно оставить существующий учёт и добавить мобильный клиент, который получает задания и возвращает результаты.
Условный пример: перевозчик ведёт расчёты в 1С, но собирает фотографии повреждений через мессенджер. Отдельный модуль может связывать фото с заказом и причиной отказа. При этом он не должен создавать второй независимый справочник клиентов или менять финансовые документы без согласованных правил.
Основной риск такого подхода — размытая ответственность. Заранее определите, какая система владеет заказом, кто меняет статусы и где сотрудник разбирает ошибку обмена. Подробнее об этом — в статье об интеграции приложения доставки с 1С.
Как сравнить полную стоимость
Сравнивайте варианты на одинаковом горизонте и при одинаковой нагрузке. Например, для внутреннего расчёта можно взять три года, отдельно проверить обычный и пиковый объём заказов. Это пример методики, а не нормативный срок окупаемости.
- Разовые расходы: обследование процессов, настройка или разработка, интеграции, очистка и перенос данных, обучение.
- Регулярные расходы: лицензии, серверы, карты, сообщения, хранение файлов, техническая поддержка.
- Изменения: новые склады и подрядчики, обновления 1С, развитие приложения, регрессионное тестирование.
- Выход из решения: выгрузка данных, перенос истории, замена интеграций и обучение новой системе.
Отдельно посчитайте внутренние трудозатраты. Если сотрудники продолжают вручную исправлять обмен или вести параллельную таблицу, это часть стоимости эксплуатации. Не записывайте потенциальную экономию в гарантированный эффект: сначала измерьте исходное время обработки заказа и сравните его с результатом пилота.
Что проверить на пилоте
- Выберите ограниченный участок работы, но включите в него обычные заказы и характерные исключения.
- Зафиксируйте исходные показатели: время подготовки рейса, долю ручных исправлений, задержку получения статусов.
- Проверьте полный цикл: создание заказа, назначение водителя, доставку, отказ, возврат и сверку результата.
- Испытайте недоступность сети и учётной системы, повторную отправку и замену исполнителя.
- Запишите критерии приёмки, план отката и перечень данных, которые необходимо сохранить.
Победитель — не решение с наибольшим числом функций, а вариант, который проходит обязательные сценарии при приемлемых затратах и рисках. Если ни один вариант не проходит, уточните требования или разделите внедрение на этапы.
Частые вопросы
Готовая система всегда дешевле?
Нет. Сравнение зависит от лицензирования, числа пользователей, интеграций и объёма доработок. Но и заказная система не становится выгоднее автоматически при росте компании: её поддержку и развитие тоже нужно учитывать.
Можно начать с готового решения, а затем перейти на своё?
Да, если заранее проверить экспорт данных, доступность истории и условия интеграции. Полезно иметь стабильные идентификаторы заказов и описание обмена, чтобы переход не требовал ручного сопоставления записей.
С чего начать обсуждение с разработчиком?
Подготовьте схему процесса, перечень систем, примеры заказов и список обязательных исключений. Для мобильной части используйте чек-лист MVP приложения водителя.
Следующий шаг
Если рассматриваете разработку системы управления доставкой, начните с разбора текущего процесса. AppLogistics можно передать список интеграций, ролей и проблемных сценариев для обсуждения состава решения. Обсудить задачу.
