Источники данных
Определяем, из каких документов и справочников 1С должны уходить сведения в логистический контур.
Связываем Контур.Логистика с текущим контуром 1С: проектируем источники данных, обмен электронными перевозочными документами и статусами, учитываем доработки, роли пользователей и внешние системы, затем тестируем сквозной процесс до рабочего результата.
Интеграция нужна тогда, когда стандартного подключения недостаточно: данные хранятся нестандартно, есть собственные документы, несколько информационных систем или требуется автоматический обмен без ручного повторного ввода.
Определяем, из каких документов и справочников 1С должны уходить сведения в логистический контур.
Проектируем способ передачи данных, документов и статусов с учётом возможностей текущей системы.
Связываем перевозочные документы с исходными учётными операциями и фактической перевозкой.
Определяем, какие действия выполняются автоматически, а какие остаются за сотрудниками.
Учитываем КЭП и МЧД там, где автоматический обмен переходит в юридически значимое действие пользователя.
Возвращаем в 1С информацию о прохождении документа, чтобы сотрудники не контролировали процесс вручную.
Схема проектируется под вашу систему. Важно заранее определить, где создаются данные, где выполняется юридически значимое действие и куда должен возвращаться результат.
Реализация, заказ, рейс или другой объект становится источником исходных сведений.
Проверяем и приводим реквизиты к формату, который нужен внешнему контуру.
Данные и документы уходят в Контур.Логистика по согласованному механизму.
Пользователи и контрагенты выполняют необходимые действия и подписи.
Итог и промежуточные состояния возвращаются в рабочий контур 1С.
Чем сильнее база отличается от типовой, тем важнее сначала описать архитектуру данных и зависимости. Это снижает риск конфликтов с действующими процессами.
Интеграцию нельзя начинать с написания обмена без описания данных и бизнес-сценария. Сначала фиксируем архитектуру, затем реализуем и тестируем.
Разбираем 1С, внешние системы и рабочий процесс.
Определяем поля, документы, справочники и направления обмена.
Реализуем обмен и необходимые доработки в согласованном контуре.
Проверяем штатные и ошибочные сценарии на тестовых данных.
Переводим интеграцию в рабочий режим и контролируем первые операции.
Чем точнее определены данные и направление обмена, тем стабильнее решение и проще его дальнейшее сопровождение.
Передаём сведения, которые уже существуют в учётной системе.
Возвращаем информацию, которая нужна сотрудникам для контроля процесса.
В производстве, торговле и логистике разные объекты запускают перевозочный процесс. Поэтому интеграция строится от реального учётного сценария.

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

Автоматизируем регулярные отгрузки и передачу данных при большом числе документов и контрагентов.

Связываем рейсы, водителей, диспетчеров, документы и статусы выполнения перевозки.

Для нерегулярных схем проектируем отдельные правила формирования и передачи данных.
Основные риски появляются не при первой успешной отправке, а при нестандартных данных, изменениях конфигурации и ошибках внешнего обмена.
В 1С и внешнем сервисе один и тот же реквизит может храниться и проверяться по-разному.
Повторная отправка без контроля идентификаторов может создавать лишние операции.
Документ обработан снаружи, но в 1С остаётся старое состояние.
После изменения конфигурации интеграция получает данные не из того объекта или поля.
Пользователь видит только факт сбоя, но не понимает причину и следующий шаг.
Одиночный тест работает, а массовая обработка регулярных отгрузок выявляет узкие места.
Цель — сократить ручную работу и сделать состояние перевозочного документа видимым внутри привычного учётного контура.
Сведения берутся из 1С и не вводятся повторно в нескольких системах.
Документы и статусы передаются по согласованному сценарию.
Пользователь получает понятный статус и может отреагировать на сбой.
Архитектура позволяет подключать новые сценарии без полной переделки процесса.
Интеграционный проект нельзя корректно оценить только по названию конфигурации. Сначала нужно понять число объектов, направлений обмена и нестандартных сценариев.
Основные факторы определяются после обследования.
Разделяем интеграционные работы и эксплуатационные расходы.
Если стандартный сценарий подходит, достаточно настройки. Если нужно менять обмен данными или связывать несколько систем, требуется интеграционный проект.
Для типового или близкого к типовому сценария.
Подробнее →Общий интеграционный контур для электронных перевозочных документов.
Подробнее →Отдельный сценарий для электронной транспортной накладной.
Подробнее →Если сервис ещё не активирован и нужно подготовить инфраструктуру.
Подробнее →Проект от аудита до промышленного запуска и обучения.
Подробнее →Сервисная и проектная часть бюджета.
Подробнее →Интеграция Контур.Логистика с 1С нужна в ситуациях, когда типового подключения недостаточно для текущего учётного процесса. Это характерно для доработанных конфигураций, собственных документов, нескольких информационных систем и сценариев, где данные должны передаваться автоматически без повторного ручного ввода.
Первый этап интеграции — карта данных. Определяется, какие объекты 1С являются источниками сведений, какие поля необходимо передать, как идентифицировать документ и какие статусы должны вернуться обратно. Только после этого выбирается технический механизм обмена и начинается разработка.
Для компании в Москве важно проектировать не только успешную отправку, но и обработку ошибок, повторный обмен, изменение статусов и дальнейшее сопровождение решения. Особенно это важно при больших объёмах перевозочных документов или при связи 1С с WMS, TMS, CRM и другими корпоративными системами.
Если ваша база близка к типовой и требуется только подготовить пользователей и обмен, достаточно страницы «Контур.Логистика — настройка в 1С». Для общего контура электронных перевозочных документов смотрите «Интеграция ЭПД с 1С», а для электронной транспортной накладной — «Интеграция ЭТрН с 1С».
Стоимость сервиса и проектных работ вынесена на страницу «Тарифы 1С ЭПД».
Ответы на вопросы, которые возникают перед проектированием обмена.
Настройка использует готовые возможности системы, а интеграция изменяет или расширяет механизм обмена данными под конкретную архитектуру компании.
Да. Перед разработкой проводится обследование, чтобы определить источники данных, действующие доработки и потенциальные конфликты.
Если выбранная архитектура и возможности обмена это позволяют, статусы можно использовать для автоматического обновления состояния документов и уведомления пользователей.
Не всегда. Иногда достаточно использовать существующие объекты, а иногда требуется добавить реквизиты или отдельную логику подготовки данных.
Да, если процесс включает WMS, TMS, CRM или другие корпоративные системы. В этом случае архитектура проектируется с учётом всех источников и получателей данных.
Проверяются штатные сценарии, ошибочные данные, повторная отправка, возврат статусов и полный маршрут документа до завершения.
Стоимость зависит от конфигурации, числа объектов и направлений обмена, объёма доработок и требований к тестированию. Предварительная оценка возможна после короткого обследования.
Опишите конфигурацию, доработки и какие данные должны передаваться. Определим точки интеграции, состав работ и порядок тестирования до начала разработки.