E-commerce
Сайт и интернет-магазин
Каталог, цены, остатки, заказы, оплаты, отгрузки и статусы исполнения.
- владелец номенклатуры и цен;
- резервы и доступные остатки;
- возвраты и отмены заказа.
Связываем системы, а не только API
Интеграции и управляемый обмен данными
Интегрируем учётные системы, сайты, CRM, маркетплейсы, кассы, склады и внешние API. Проектируем обмен, контролируем ошибки и сопровождаем запуск.
Сначала бизнес-правила и контракт данных.
Затем выбираем готовый коннектор, API, очередь или
заказной модуль — с понятным журналом и восстановлением.
- У каждого вида данных есть владелец
- Повтор не создаёт дубль
- Ошибка видна и восстанавливается
Интеграционный контур
От бизнес-правил до наблюдаемой эксплуатации
Контракт данных
единые правила
владельцы, поля и идентификаторы
-
Описатьобъекты, направления и правила
-
ПередатьAPI, коннектор, файл или очередь
-
Проверитьстатусы, журнал и метрики
-
Восстановитьповтор без дублей и ручной разбор
Вход по бизнес-задаче
Какие системы связываем
Для каждого сценария определяем источник истины, состав данных, допустимую задержку и порядок обработки ошибок. Это важнее названия конкретного API.
CRM
CRM и клиентский контур
Лиды, компании, контакты, сделки, счета и история взаимодействий.
- сопоставление клиентов;
- этапы и ответственные;
- двусторонние изменения.
Площадки
Маркетплейсы
Карточки, цены, остатки, заказы, сборочные задания, отгрузки и отчёты.
- лимиты и версии API;
- очередь изменений;
- статусы по каждой площадке.
ККТ / POS
Кассы и POS-системы
Товары, цены, смены, продажи, возвраты и кассовые события в учётном контуре.
- модель ККТ и кассовое ПО;
- версия драйвера и формат обмена;
- проверка совместимости до запуска.
Решения Мультисофт рассматриваем только после проверки конкретной модели и версии драйвера: сертификация MSPOS, реестр ККТ ФНС.
Связать кассовый контур
Склад
Склад и маркировка
Остатки, задания, серии, коды маркировки и движение товаров между зонами.
- ТСД и складские операции;
- агрегация и выбытие кодов;
- сверка с внешними системами.
Документы
ЭДО и внешние документы
Заказы, УПД, акты, накладные, статусы подписания и транспортные документы.
- идентификаторы пакетов;
- статусы и версии документа;
- подпись и маршруты согласования.
API
Заказной корпоративный API
Ограниченный контракт для внутренних сервисов, мобильных приложений и партнёров.
- версионирование методов;
- авторизация и права;
- документация и тестовый контур.
Контроль
Мониторинг существующих обменов
Единая картина заданий, очередей, ошибок и отставания по критичным интеграциям.
- журнал и метрики;
- уведомления по приоритету;
- история восстановления.
Архитектурное решение
Готовый коннектор, заказной обмен или ArMCore
Не начинаем с разработки «по привычке». Сравниваем функциональную полноту, стоимость владения, поддержку версий, требования к контролю и возможность восстановить обмен без ручного редактирования данных.
Готовый коннектор
- сценарий покрыт без критичных обходов;
- есть совместимость и поддержка версий;
- понятны журнал и порядок обновления.
Заказной обмен
- нестандартная модель или бизнес-правила;
- точный ограниченный контракт;
- приёмочные сценарии и документация.
ArMCore
- несколько систем и управляемые маршруты;
- централизованный журнал и мониторинг;
- расширение без замены работающих систем.
Финальный вариант фиксируем после обследования API, версий систем, объёма операций и требований к времени восстановления.
Эксплуатационная надёжность
Что делает обмен управляемым
Сам факт передачи данных не означает, что интеграция готова к работе. Нужны правила повторов, наблюдаемость и воспроизводимая процедура восстановления.
Владельцы данных
Для каждого объекта определена система-источник и допустимые изменения.
Идентификаторы
Внешние ключи и идемпотентность предотвращают повторное создание данных.
Очередь и повторы
Повторы ограничены, причины ошибок классифицированы, спорные операции не теряются.
Журнал операций
Видны сообщение, объект, время, результат, причина и история обработки.
Метрики и уведомления
Контролируем отставание, длину очереди, ошибки и критичные состояния.
Восстановление
Операцию можно безопасно повторить или продолжить с подтверждённой позиции.
Доступ и секреты
Минимальные права, серверное хранение ключей и отсутствие секретов в браузере.
Версии контракта
Изменения формата согласуются и проверяются на тестовом контуре до публикации.
Порядок работ
От обследования до сопровождения
Каждый этап имеет проверяемый результат и критерии перехода к следующему.
-
01
Обследование
Системы, процессы, ограничения, владельцы и текущие ошибки.
-
02
Контракт
Объекты, поля, идентификаторы, направление и частота обмена.
-
03
Прототип
Критичный маршрут на тестовых данных и проверка ограничений API.
-
04
Запуск
Миграция, приёмочные сценарии, обучение и контролируемое включение.
-
05
Поддержка
Мониторинг, разбор инцидентов, обновления и развитие контракта.
До старта проекта
Фиксируем границы ответственности
Интеграция зависит как минимум от двух систем. Поэтому заранее определяем, кто отвечает за доступность, изменения API, качество исходных данных и решение инцидентов.
ГК «АрМ»
Наш контур работ
Архитектура обмена, разработанный код, журнал, тесты и согласованный порядок поддержки.
- документированный контракт;
- приёмочные сценарии;
- разбор ошибок нашего контура.
Заказчик
Владельцы процесса и данных
Решения по бизнес-правилам, доступы, ответственные пользователи и качество исходных справочников.
- подтверждение модели данных;
- тестовые примеры;
- приёмка результата.
Внешняя система
Поставщик API или сервиса
Доступность внешней платформы, её лимиты, правила авторизации и изменения документации.
- учёт технических ограничений;
- окно изменений;
- эскалация поставщику сервиса.
Официальные первоисточники
Документация платформ и регуляторов
Точные методы, лимиты и правила меняются. Перед проектированием сверяем актуальную официальную документацию используемой системы.
1С
Интеграционные возможности платформы 1СМеханизмы обмена и взаимодействия
HTTP-сервисы 1СОфициальная документация платформы
1С-Битрикс и интеграция с учётомОбмен каталогом, заказами и статусами
Bitrix24 REST APIМетоды, права и сценарии приложений
Авторизация Bitrix24 RESTWebhooks, OAuth 2.0 и границы прав
Wildberries APIОфициальный портал разработчика
Яндекс Маркет Partner APIОфициальная документация для продавцов
Документация «Честного знака»ГИС МТ и работа с маркированными товарами
True APIОписание интерфейсов ГИС МТ
Реестр ККТ ФНСПроверка модели кассовой техники
Ссылки ведут на сайты правообладателей и государственных информационных систем. Условия конкретного проекта проверяем по действующим версиям систем на дату обследования.
Частые вопросы
До начала интеграционного проекта
С чего начинается проект интеграции?
С карты систем и контракта данных: фиксируем объекты обмена, владельца каждого вида данных, направление и частоту передачи, идентификаторы, правила повторной обработки, контроль ошибок и ответственных за смежные системы. Только после этого выбираем готовый коннектор, API или заказной обмен.
Чем эта страница отличается от раздела интеграций с 1С?
Здесь рассматривается весь интеграционный контур: сайты, CRM, маркетплейсы, кассы, склады, электронные документы и внешние API — независимо от конкретной учётной платформы. Раздел «Интеграции с 1С» подробно описывает механизмы и ограничения именно платформы 1С.
Всегда ли нужна заказная разработка?
Нет. Если готовый коннектор закрывает нужный состав данных, имеет понятную поддержку и совместим с используемыми версиями систем, его внедрение обычно быстрее. Заказной обмен оправдан при нестандартной модели данных, особых правилах процесса или отсутствии поддерживаемого коннектора.
Можно ли сделать обмен в реальном времени?
Да, если этого требует процесс и обе системы поддерживают нужную нагрузку. Но для части операций надёжнее очередь событий или регламентный обмен. Частоту определяем по допустимой задержке, объёму данных, ограничениям API и процедуре восстановления после сбоя.
Как интеграция защищается от дублей?
Для объектов и сообщений задаём устойчивые внешние идентификаторы, правила сопоставления и идемпотентность операций. Повторная доставка не должна повторно создавать заказ, оплату или документ; спорные случаи отправляются на ручной разбор.
Что происходит, если внешняя система временно недоступна?
Сообщение сохраняется с идентификатором и статусом, после чего выполняются ограниченные повторные попытки. Ошибка попадает в журнал и уведомление. После устранения причины обмен продолжается с контролируемой позиции, а не запускается вслепую заново.
Можно ли интегрировать кассы и POS с учётной системой?
Да. Состав обмена зависит от кассового ПО, модели ККТ, версии драйвера и учётной системы. До проекта проверяем совместимость оборудования и программ, а для фискальной части сверяем модель ККТ с официальным реестром ФНС.
Как безопасно подключать Bitrix24 и другие облачные API?
Способ авторизации выбирается по сценарию и правам. Простой webhook ограничивается правами пользователя-владельца; для приложения и расширенных сценариев применяется OAuth 2.0. Секреты хранятся на сервере и не выводятся в браузерный код или публичный репозиторий.
Кто сопровождает интеграцию после запуска?
В договоре фиксируем границы ответственности, перечень контролируемых обменов, порядок реакции и владельцев смежных систем. Мы можем сопровождать разработанный контур, журнал ошибок и восстановление, но доступность стороннего API и изменения его правил остаются в зоне поставщика внешней системы.
Следующий шаг
Нужна карта систем и обменов?
Разберём бизнес-процесс, источники данных и критичные ошибки. Предложим архитектуру, этапы запуска и границы сопровождения без преждевременного выбора технологии.