Как устроен обмен 1С с сайтом, CRM, банком и маркетплейсами
Содержание
Интеграция 1С — это передача данных между вашей базой и внешней системой: сайтом, CRM, банком, маркетплейсом. Технически это всегда один из нескольких механизмов обмена — планы обмена, веб-сервисы, HTTP-сервисы, OData или обмен через файлы. Остальное — надстройки над ними.
Разберём, как данные физически перемещаются между системами, какой способ выбрать под конкретную задачу, где чаще всего ломается обмен и во сколько обходится настройка. Пути меню — для платформы 8.3 (интерфейс «Такси»), конфигураций «1С:Бухгалтерия 3.0», «1С:Управление торговлей 11» и «1С:ЗУП 3.1».
Как данные ходят между 1С и внешними системами
Любая интеграция сводится к трём вопросам: кто инициирует обмен, в какую сторону идут данные и как часто. От ответов зависит выбор механизма.
По направлению обмен бывает:
- 🔁 Двусторонний — данные меняются в обе стороны. Пример: заказы с сайта попадают в 1С, а остатки и цены из 1С уходят обратно на сайт.
- ➡️ Односторонний — источник только отдаёт или только принимает. Пример: выгрузка номенклатуры в маркетплейс.
По инициатору:
- 1С сама подключается к внешней системе (например, забирает заказы через её API);
- внешняя система обращается к 1С, опубликованной на веб-сервере;
- посредник (сервис-коннектор, интеграционная шина) связывает обе стороны.
По моменту запуска обмен делится на обмен по расписанию (регламентное задание раз в N минут) и обмен по событию (провели документ — сразу ушёл во внешнюю систему). Расписание проще и надёжнее, обмен по событию нужен там, где важна скорость — например, бронь остатка на складе.
Прежде чем выбирать «как», ответьте «что и зачем». Половина проблем с интеграцией — из-за того, что синхронизируют больше справочников, чем реально нужно. Чем меньше объектов в обмене, тем он стабильнее.
Способы и форматы обмена данными в 1С
Платформа 8.3 даёт несколько встроенных механизмов. Выбор зависит от того, кто с кем общается и есть ли готовый формат.
Планы обмена — штатный механизм 1С для синхронизации двух баз. Регистрирует изменения объектов и отдаёт только то, что поменялось с прошлого сеанса. На планах обмена работает типовая синхронизация между конфигурациями: Бухгалтерия ↔ ЗУП, Бухгалтерия ↔ Управление торговлей.
Веб-сервисы (SOAP) — 1С публикует свой сервис, внешняя система вызывает его методы. Формат строгий, с описанием (WSDL). Подходит для надёжного обмена между корпоративными системами.
HTTP-сервисы (REST) — более лёгкий способ: 1С отвечает на обычные HTTP-запросы, данные чаще в JSON. Удобно для связки с сайтами и мобильными приложениями.
OData — автоматический REST-интерфейс ко всем данным базы. Включается без программирования: в конфигураторе задаёте состав, затем при публикации на веб-сервере ставите флажок публикации стандартного интерфейса OData. Внешняя система после этого читает и пишет справочники и документы напрямую.
Обмен через файлы — самый простой вариант: 1С выгружает XML, JSON или CSV в папку, вторая система его забирает. Так до сих пор работает классический клиент-банк.
Чтобы заработали веб-сервисы, HTTP-сервисы и OData, базу нужно опубликовать на веб-сервере (Apache или IIS). Делается это в конфигураторе: Администрирование → Публикация на веб-сервере.
Для типовых конфигураций есть универсальный формат EnterpriseData — это XML с описанием документов и справочников. Именно в нём типовые базы синхронизируются между собой. Если версии формата у двух баз расходятся, обмен начинает ругаться — об этом ниже.
Сопоставление данных — отдельная тема. При обмене редко совпадают названия полей, поэтому настраивается соответствие:
Как выбрать способ обмена под задачу
Не каждый механизм подходит под любую интеграцию. Ориентир:
Обмен с сайтом и интернет-магазином
Самая частая связка — 1С и сайт. Товары, цены и остатки едут из 1С на сайт, заказы — обратно в 1С.
С сайтами на 1С-Битрикс и большинством CMS работает стандартный протокол CommerceML — это обмен XML-файлами: один с каталогом (import.xml, offers.xml), второй с заказами. 1С выгружает каталог, сайт его принимает; заказы сайт отдаёт встречным запросом.
В «1С:Управление торговлей 11» обмен с сайтом настраивается в разделе НСИ и администрирование (включается использование обмена с сайтом, затем задаётся узел обмена и расписание). В «1С:Бухгалтерии» обмена с сайтом из коробки нет — там для интернет-торговли используют УТ, УНФ или «1С:Розницу».
Что обычно синхронизируют:
- Номенклатуру и её свойства (характеристики, картинки, описания).
- Цены и остатки по складам.
- Заказы покупателей и их статусы.
- Данные о контрагентах из заказов.
Остатки на сайт лучше отдавать с запасом или с ограничением «не ниже нуля». Если обмен идёт раз в час, за это время товар на сайте закажут больше, чем есть на складе. Настройте резервирование или виртуальный остаток, иначе получите заказы на то, чего нет.
Обмен с маркетплейсами
Маркетплейсы (Ozon, Wildberries, Яндекс Маркет) работают не по CommerceML, а по собственному API. Поэтому связка устроена иначе, чем с обычным сайтом.
Есть три пути:
- 🧩 Встроенный обмен — в свежих релизах «1С:Управление торговлей», «1С:УНФ» и отраслевых решений есть готовый обмен с крупными маркетплейсами. Настраивается в разделе продаж: подключаете кабинет по токену API, выбираете склад и правила цен.
- 🔌 Сервис-коннектор — отдельный модуль или облачный сервис, который забирает заказы из кабинетов и кладёт их в 1С. Удобно, если площадок несколько.
- 🛠 Индивидуальная разработка — HTTP-сервис под конкретный API площадки. Нужна, когда стандартного обмена не хватает (своя логика цен, нестандартные схемы FBO/FBS).
Типовой сценарий: цены и остатки уходят в кабинет, заказы приходят в 1С как документы реализации или заказы клиента, статусы отгрузки обновляются в обе стороны.
У маркетплейсов API меняется чаще, чем у обычных сайтов. Закладывайте, что обмен придётся обновлять вслед за площадкой, — это нормальная статья расходов, а не разовая настройка.
Синхронизация с CRM
С CRM связывают 1С, чтобы не вести клиентов и сделки в двух местах. Направление обычно такое: сделка закрыта в CRM → в 1С создаётся заказ или реализация; оплата прошла в 1С → статус сделки в CRM меняется.
Варианты интеграции зависят от того, какая CRM:
- «1С:CRM» — отдельная конфигурация из линейки 1С, встраивается прямо в УТ или УНФ. Обмен внутренний, без веб-сервисов.
- Внешняя CRM (Битрикс24, amoCRM и другие) — обмен через их API и HTTP-сервис на стороне 1С. Либо через готовый коннектор из маркетплейса приложений CRM.
Что обычно синхронизируют: контрагентов (клиентов), контактные лица, сделки и счета, задачи менеджеров, иногда остатки и прайс для выставления счёта прямо из CRM.
Ключевой момент — сопоставление клиентов. В 1С контрагент опознаётся по ИНН, в CRM — по своему внутреннему ID. Если не хранить соответствие, при каждом обмене будут плодиться дубли карточек. Решение — отдельное поле (дополнительный реквизит) под внешний ID, по которому идёт поиск.
Обмен с банком и эквайрингом
Банковские данные в 1С заводят двумя способами.
ДиректБанк — прямой защищённый канал между 1С и банком без выгрузки файлов. Платёжки уходят в банк на подпись и исполнение прямо из программы, выписки приходят обратно. Настраивается в разделе банка (подключение по заявлению в банк), работает для банков, которые этот канал поддерживают.
Файловый клиент-банк — классика. 1С выгружает платёжные поручения в файл формата «1С:Предприятие — Клиент банка» (1c_to_kl.txt), вы загружаете его в интернет-банк. Обратно банк отдаёт выписку (kl_to_1c.txt), которую 1С загружает и разносит по счетам. Формат стандартный, поэтому работает практически с любым банком.
Эквайринг и платёжные сервисы — интеграция с терминалами и онлайн-кассами: оплата по карте проводится из документа продажи, а чек уходит на фискальный регистратор. Настраивается через подключаемое оборудование.
Для бухгалтерии чаще хватает файлового обмена или ДиректБанка — обе схемы типовые и не требуют программиста.
Безопасность и типичные ошибки обмена
Обмен — это дыра в периметре учётной системы, поэтому доступ к нему настраивают отдельно.
Что защищает данные при интеграции:
- 👤 Отдельный пользователь для обмена с минимальными правами — только на те объекты, что участвуют в синхронизации. Не давайте внешней системе полный доступ к базе.
- 🔐 HTTPS для всех веб- и HTTP-сервисов. Токены и пароли храните в защищённом хранилище, а не в коде обработки.
- 📋 Журнал регистрации — по нему видно, кто и что менял через обмен. Включите логирование сеансов интеграции.
- 🌐 Ограничение по IP на веб-сервере — пускать к опубликованной базе только адреса внешней системы.
Теперь про то, что ломается чаще всего. Большинство сбоев обмена — не загадка, а одна из нескольких типовых причин:
При двустороннем обмене возможны конфликты: один объект изменили в обеих базах между сеансами. Заранее решите, чья версия главная (обычно — источник данных), и зафиксируйте это в правилах, иначе изменения будут затирать друг друга.
Сколько стоит интеграция 1С
Стоимость зависит от того, типовой это обмен или индивидуальная разработка. Ориентиры примерные — точная цена считается под задачу.
| Тип интеграции | Что входит | Ориентировочно |
|---|---|---|
| Типовая синхронизация 1С ↔ 1С | Настройка обмена Бухгалтерия ↔ ЗУП/УТ | В составе конфигурации, настройка от 5 000 ₽ |
| Обмен с сайтом по CommerceML | Настройка стандартного обмена | Примерно 10 000–30 000 ₽ |
| Подключение ДиректБанка | Заявление в банк + настройка | Обычно бесплатно или в составе сопровождения |
| Обмен с маркетплейсом через коннектор | Подписка на сервис | Ориентировочно от 1 000 ₽/мес за площадку |
| Индивидуальная интеграция через API | Разработка HTTP-сервиса под задачу | Примерно от 40 000 ₽ и выше |
На цену влияет число объектов в обмене, двусторонний он или односторонний, нужна ли передача в реальном времени и насколько нестандартен API второй системы.
Где можно сэкономить:
- Начать с типового обмена — его часто хватает, а стоит он дешевле заказной разработки.
- Синхронизировать только то, что действительно нужно обеим системам.
- Выбрать обмен по расписанию вместо обмена в реальном времени, если задержка в 10–15 минут не критична.