Диагностика · 60 секунд

Соберём маршрут до разговора

Три вопроса без отправки данных. Ответы останутся в этой вкладке, пока вы сами не перенесёте маршрут в форму.

Вопрос 01 / 03
Контекст

Что сейчас болит сильнее всего?

Выберите главный разрыв — остальные детали архитектор уточнит на разборе.

API · очереди · шины · оборудование

Свяжем 1С с внешней системой без дублей и слепых ошибок

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

Не выпускаем обмен только по успешному тесту API.До выпуска проверяем тот же идентификатор сообщения, недоступность стороны, неверный контракт, восстановление и итоговое состояние.

1С · первый рабочий обмен маршрут восстановим
Источник1С:ERPбизнес‑событие
ДоставкаAPI · очередьправила обмена и идентификатор сообщения
ПолучательWMS · CRMподтверждённое состояние
01

Событиеorder.updated · ID 10587

Принято
02

Контрактschema v1.2 · ключи проверены

Valid
03

Повтортот же идентификатор сообщения · попытка 2

Без дубля
04

Сверкаисточник = получатель

Совпало
Приёмкаосновной путь · повтор · сбой · восстановление · сверка
1 событиев границах первого этапа2 системыисточник и получатель10 материаловдля релиза и поддержки20 днейограниченный проектный старт

Ролевая линза

Один проект. Четыре критерия правильного решения.

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

Непрерывность обязательства

Ограничим инвестицию одним обменом, сбой которого уже влияет на деньги или срок.

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

Фокус решения
Цена остановки, граница пилота, ответственность и решение о масштабе
Главная метрика
Доля контрольных событий с принятым результатом без ручного восстановления
Результат первого шага
Рабочий пилот и решение выпускать, усилить, изменить или остановиться
Перейти к продуктовому пилоту
Карта решения01 / 04
  1. 01Какое обязательство зависит от обмена
  2. 02Что считается результатом у получателя
  3. 03По какому факту открывается масштаб
Управленческий выходИнвестировать после принятого отказного теста
Выбор сохраняется только на этом устройствеСобственник / CEO

Когда нужна инженерная схема

Соединение работает недостаточно, если бизнес не может безопасно пережить сбой

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

01Нужно подключить новую систему

API уже выбран, но никто не зафиксировал бизнес‑результат обмена

CRM, WMS, MES, сайт или маркетплейс описаны своими методами и полями. При этом не определено, какое событие рождается в 1С, какой объект должен появиться у получателя и кто принимает итог.

Разработка формально выполняет спецификацию, но не закрывает сквозной рабочий сценарий
02Существующий обмен нестабилен

Ошибку исправляют повторным запуском обработки и ручной правкой данных

После тайм‑аута команда не знает, дошёл ли запрос. Повтор может создать второй заказ, а отказ от повтора оставляет системы в разных состояниях.

Восстановление зависит от конкретного разработчика и может увеличить исходный ущерб
03Формат внешней системы меняется

Каждая новая версия API превращается в срочное изменение 1С

Контракт смешан с внутренними таблицами, преобразования разбросаны по коду, а контрольные примеры не сохранены. Совместимость проверяется уже после обновления внешней стороны.

Обязательное обновление запускает цепочку непредсказуемых исправлений в рабочей системе
04Журналы есть — контроля нет

Техническая ошибка не связана с заказом, сроком и владельцем решения

Поддержка видит стек вызова, но не может ответить, какой бизнес‑объект остановлен, можно ли повторить операцию и совпали ли состояния после восстановления.

Критичный разрыв обнаруживается звонком пользователя или клиента, а не системой контроля

Короткий ответ

Что входит в разработку интеграции 1С под ключ?

01Граница02Контракт03Реализация04Приёмка

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

  • Контракт отделён от структуры конкретной базы
  • Повтор не создаёт вторую бизнес‑операцию
  • Ошибка связана с объектом и владельцем
  • Восстановление завершается сверкой

Шесть слоёв поставки

Каждый слой обмена получает отдельный механизм и проверяемый результат

Если слой не выделен, проблема контракта маскируется повтором, а эксплуатационная ошибка — доработкой транспорта. Разделение сохраняет локальность решения.

01

Граница и событие

Один бизнес‑объект, инициатор, получатель, ожидаемое состояние, допустимая задержка и критерий приёмки.

Принимаемый результатПаспорт обмена
02

Контракт и ключи

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

Принимаемый результатВерсионируемый контракт
03

Адаптер источника

Формирование события в 1С, исходящий буфер, статус публикации и связь с бизнес‑объектом.

Принимаемый результатНаблюдаемый producer
04

Транспорт и надёжность

API, очередь, шина или файл; подтверждение, тайм‑аут, порядок, лимиты, повтор и карантин.

Принимаемый результатПолитика доставки
05

Обработка получателя

Входной контроль, идемпотентность, транзакционность, компенсация и протокол результата.

Принимаемый результатБезопасный получатель
06

Эксплуатация и приёмка

История прохождения, показатели, оповещения, список исключений, инструкция, проверки сбоев и сверка систем.

Принимаемый результатПротокол готовности

Интерактивная схема поставки

Проследите обмен от принятого контракта до восстанавливаемой эксплуатации

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

Слой 01 · единый смысл события

До кода фиксируем объект, состояние, ключи и ожидаемый результат у получателя.

Контракт отделяет бизнес-смысл от внутренней структуры 1С и внешней системы. Версия, обязательные поля, справочники и примеры ошибок становятся общей точкой приёмки для аналитика, разработчика и владельца процесса.

  • Один объект имеет устойчивый идентификатор
  • Поля и статусы одинаково понимаются обеими сторонами
  • Несовместимое изменение требует новой версии
Сквозная трасса поставки01 / 05
01ВходБизнес‑событие02МеханизмСхема и версия03КонтрольКонтрольный пример04РезультатПринятый контракт
Контролируемый сбойПолучатель получает неизвестную версию или сообщение без обязательного поляСообщение отклоняется объяснимо и не создаёт частично заполненный бизнес‑объект.
Принимаемый результатВерсионируемый контракт и набор контрольных сообщений

Продуктовый первый шаг

01 / Первый рабочий обмен

Одно событие между двумя системами за 20 рабочих дней

Берём один самостоятельный бизнес‑поток, реализуем его на тестовом контуре и проводим через основной путь, повтор, недоступность, неверный контракт, восстановление и сверку результата.

Срок20 рабочих днейОбъём1 событие · 2 системыНа выходе10 рабочих материалов
Решение после проверкивыпускать / усилить / сменить паттерн / масштабировать / остановиться
Зафиксировать контрольное событие
01

Паспорт события

Инициатор, объект, результат, допустимая задержка, цена ошибки и владелец процесса.

02

Карта систем и доступов

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

03

Правила данных

Версия, поля, типы, обязательность, смысл и контрольные примеры сообщений.

04

Соответствие данных и ключей

Связь объектов, статусов, единиц, справочников и идентификаторов.

05

Отправка из 1С

Формирование события, очередь на отправку, журнал и управляемая передача.

06

Маршрут доставки

Транспорт, подтверждения, лимиты, тайм‑ауты, повторы и правила карантина.

07

Обработка у получателя

Проверка сообщения, защита от дублей, запись результата, ответ и восстановление после ошибки.

08

Контроль обмена

Связь идентификатора сообщения с заказом или документом, статусы, показатели, оповещения и журнал событий.

09

Проверка сбоев

Основной путь, дубль, недоступность, неверная схема, восстановление и сверка.

10

Инструкция и план запуска

Действия поддержки, роли, время запуска, решение о продолжении и безопасный возврат.

Контролируемый сбой

Первый этап должен подтвердить не только доставку, но и способность восстановиться

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

  • Один и тот же объект проходит все сценарии
  • Каждый тест имеет ожидаемый бизнес‑результат
  • Ручное действие описано до аварии
  • Финал каждого сценария — сверка систем
Инженерный результатКоманда знает, что произойдёт при повторе и недоступности, а владелец процесса видит не технический лог, а состояние конкретного обязательства.
Лаборатория приёмки 5 сценариев одного события
Контрольный объектЗаказ 10587 · идентификатор 8F2AОдинаковый контракт и ожидаемое состояние во всех прогонах
  1. 01
    Основной путьСобытие обработано один раз

    Ожидаемое состояние принято владельцем

  2. 02
    ПовторТо же сообщение доставлено снова

    Второй бизнес‑объект не создан

  3. 03
    НедоступностьПолучатель временно выключен

    Событие сохранено и доставлено позже

  4. 04
    Неверный контрактПоле или версия не проходят проверку

    Сообщение объяснимо попадает в карантин

  5. 05
    ВосстановлениеПричина устранена по рабочей инструкции

    Состояния систем повторно сверены

КритерийНи один сценарий не заканчивается неизвестным состоянием бизнес‑объекта

Публичный продукт / Интеграции

Реестровая запись · 02.05.2023

Собственный модуль интеграции 1С с AVITO

Публичная карточка продукта указывает правообладателя БИТУБИ и номер 17507 в Едином реестре российского ПО. Это проверяемое подтверждение собственной интеграционной разработки компании.

ПравообладательБИТУБИПродуктМодуль интеграции 1С с AVITOЗапись№ 17507
Подтверждено публичной карточкой№ 17507
Учётная системаТовары · параметры · изменения
Собственный
модуль
Внешняя площадкаAVITOПубликация и синхронизация
Класс
Дополнительный программный модуль
Основание
Публичная запись и карточка правообладателя
Проверяемый выводКомпания умеет создавать собственный интеграционный продукт, а не только настраивать готовые обмены

Не приписываем модулю неподтверждённые объёмы, скорость или эффект: используем только название, правообладателя и опубликованный номер записи.

Открыть публичную карточку

«Команда настоящих профессионалов: разбирается в бизнес‑процессах и учитывает специфику бизнеса».

Власов Иванруководитель IT‑департамента, ГК «ЖЕЛЕЗНО»

«Доверяем команде за внимание к деталям и индивидуальный подход к нашему делу».

Сметанина Светланаглавный бухгалтер, НЛК

«Команда проработала план перехода, предусмотрела наши пожелания и успешно его реализовала».

Солмашенко Светланакоммерческий директор, Miko

Маршрут первого этапа

Двадцать дней от границы события до отказной приёмки

Срок относится к ограниченному первому этапу при доступных тестовых средах и ответственных с обеих сторон. Полный промышленный ландшафт оценивается отдельно.

  1. 01
    Дни 1–2

    Ограничить первый этап одним событием

    Фиксируем бизнес‑объект, источник, получателя, результат, доступные среды и то, что остаётся за границей.

    Граница принята обеими сторонами
  2. 02
    Дни 3–5

    Согласовать данные и контрольные примеры

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

    Правила обмена готовы к разработке
  3. 03
    Дни 6–10

    Реализовать источник и получателя

    Настраиваем отправку и приём, проверку данных, преобразование и запись результата в тестовой среде.

    Сквозной путь выполняется
  4. 04
    Дни 11–14

    Добавить надёжность и восстановление

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

    Сбой не создаёт второй ущерб
  5. 05
    Дни 15–17

    Сделать обмен наблюдаемым

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

    У сбоя есть ответственный и порядок действий
  6. 06
    Дни 18–20

    Провести отказную приёмку

    Проверяем основной путь, повтор, недоступность, неверную схему, восстановление и итоговую сверку систем.

    Первый этап принят или обоснованно остановлен

Как доказываем готовность

Обмен принят, когда повтор и сбой не меняют смысл результата

Проверяем один заказ или документ по всей цепочке. Успешный HTTP‑ответ недостаточен: состояния сторон должны совпасть, а восстановление — проходить по понятной инструкции.

  1. 01

    Проводим основной путьСобытие обработано один раз, а владелец принимает ожидаемое состояние.

  2. 02

    Повторяем то же сообщениеПолучатель возвращает прежний результат без второго бизнес‑объекта.

  3. 03

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

  4. 04

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

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

Короткие ответы

Что спрашивают до разработки интеграции 1С

Состав работ, сроки, выбор технологии, защита от дублей, тестовый контур, типовая поддержка и эксплуатация после запуска.

Задать свой вопрос
01Что входит в разработку интеграции 1С под ключ?

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

02Сколько занимает интеграция 1С с внешней системой?

Срок зависит от числа событий и систем, качества API, доступов и требований к надёжности. За первые 20 рабочих дней проверяем одно событие между двумя системами и готовим десять рабочих материалов. После этого можно оценить полный запуск.

03Можно ли сначала стабилизировать уже работающий обмен?

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

04Что выбрать: REST API, OData, SOAP, очередь или интеграционную шину?

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

05Как интеграция защищается от дублей?

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

06Можно ли интегрировать 1С с оборудованием, WMS или MES?

Да, если доступен поддерживаемый драйвер, протокол или API. Кроме соединения нужны очередь на случай недоступности, идентификатор физической операции, подтверждение результата и понятный порядок ручного восстановления. Эти условия проверяются на первом этапе.

07Обязательно ли снимать 1С с типовой поддержки?

Нет. Сначала проверяем стандартные интерфейсы, HTTP- и web-сервисы, OData, EnterpriseData, планы обмена, расширения и внешние компоненты. Изменение основной конфигурации допускается только при доказанной необходимости и с отдельным решением по обновляемости.

08Как тестировать интеграцию без риска для рабочей базы?

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

09Кто поддерживает обмен после запуска?

До релиза фиксируются владелец процесса, техническая поддержка, SLA, каталог исключений и рабочая инструкция. Поддержка может остаться у IT-Сервис, перейти внутренней команде или быть совместной. В любом варианте документация и наблюдаемость не должны зависеть от памяти одного разработчика.

Материал проверенПлатформа 1С · HTTP · JSON · корпоративная шина · публичный продукт

Состав работ сверён с официальными материалами фирмы «1С» по механизмам интеграции платформы, HTTP‑сервисам, работе с JSONи возможностям 1С:Интеграция КОРП. Практический контекст IT‑Сервис подтверждён публичным портфолио компаниии карточкой собственного модуля. Конкретный транспорт, срок промышленного запуска и состав инфраструктуры определяются после проверки систем и доступов заказчика.

Актуализировано

Первый проверяемый шаг

Выберем одно событие и способ доказать его доставку

За 45 минут зафиксируем источник, получателя, объект, текущую проблему, доступные интерфейсы и критерий результата. После разговора останется понятный объём первого этапа — без продажи сложной шины до проверки необходимости.

  • Один заказ или документ вместо всех систем сразу
  • Критерий приёмки и сценарии сбоев до оценки
  • Без обязательства сразу запускать большой проект
Первый этап интеграции01 / 01
Какой обмен сейчас создаёт главный разрыв?

Ответим в рабочее время. До встречи пришлём короткий список данных, чтобы разговор был предметным.

Заявка принята

Спасибо. Мы получили вашу задачу.

Обращение передано ответственному менеджеру вместе с выбранной темой и контекстом страницы. Свяжемся с вами в рабочее время.