Что такое интеграция сайта с 1С и сколько стоит настройка обмена
Интеграция сайта с 1С — это автоматический обмен данными между учётной системой и сайтом или Odoo: каталог, цены и остатки едут из 1С наружу, заказы и покупатели — обратно в учёт. Смысл один: перестать переносить данные руками и показывать клиенту то, что действительно есть на складе.
Работа состоит из четырёх частей: сверка справочников, настройка самого обмена, тестовый контур на копии базы и мониторинг, чтобы о сбое сообщал обмен, а не покупатель звонком.
Цена зависит от того, обмен настраивается внутри нового проекта или на существующем сайте. В публичной лестнице обмен входит в два тарифа: магазин на 1С-Битрикс с обменом номенклатурой и заказами — от 250 000 ₽, связка Odoo и сайта в едином контуре — от 400 000 ₽. Настройка обмена на уже работающем сайте считается отдельно и зависит от числа объектов из матрицы ниже: от 40 000 ₽ заявки с визитки · от 120 000 ₽ Bitrix + 1С базовый · от 220 000 ₽ расширенный · от 150 000 ₽ Odoo + 1С.
ИНТЕРВОЛГА публикует по обмену 1С с сайтом от 35 тысяч рублей за товары, от 50 тысяч за заказы, от 70 тысяч за наборы и от 90 тысяч за персональные предложения. Ориентир рынка, не наш прайс.
Матрица обмена: что именно синхронизируется и в какую сторону
Главный вопрос на первом созвоне звучит не «сделаете ли вы обмен», а «что именно вы будете обменивать». От ответа зависят и трудоёмкость, и цена. Ниже — полный список объектов, из которого собирается проект; та же матрица работает и для связки 1С с Odoo, только на другом конце вместо витрины стоит ERP.
| Объект обмена | Направление | Как часто | Что входит в настройку |
|---|---|---|---|
| Номенклатура и свойства | 1С → сайт или Odoo | По расписанию, ночью | Сопоставление справочников, категории, характеристики, изображения |
| Цены и типы цен | 1С → сайт или Odoo | По расписанию или по изменению | Типы цен, скидки по группам контрагентов, округление |
| Остатки по складам | 1С → сайт или Odoo | До нескольких раз в час | Какие склады участвуют, резервы, что показывать при нуле |
| Заказы покупателей | Сайт или Odoo → 1С | Сразу после оформления | Документ, контрагент, доставка, оплата, защита от дублей |
| Статусы заказов | 1С → сайт или Odoo | По событию в учёте | Карта статусов, уведомления покупателю, отмены и возвраты |
| Контрагенты и договоры | Двусторонний | По событию | Поиск дубля по ИНН, реквизиты, лимиты и отсрочки |
| Наборы и комплекты | 1С → сайт или Odoo | По расписанию | Состав, цена комплекта, списание составляющих при отгрузке |
| Персональные предложения | 1С → сайт или Odoo | По расписанию | Цены в кабинете, привязка к договору и менеджеру |
| Документы: счета, УПД, акты | 1С → сайт или Odoo | По событию | Печатные формы в кабинете, передача в ЭДО, хранение |
Все девять строк сразу не берёт почти никто: обычный первый этап — номенклатура, цены, остатки и заказы. Трудоёмкость растёт не по числу строк, а по двум признакам: есть ли обратное направление и нужна ли реакция на событие вместо расписания.
Интеграция 1С и Odoo по API: два контура вместо одного
Связка 1С и Odoo устроена иначе, чем обмен 1С с сайтом, и путать их не стоит. С сайтом обмениваются витринными данными: что показать и что заказали. С ERP обмениваются учётными: документы, взаиморасчёты, движения по складу.
Разделение обязанностей обычно такое: Odoo ведёт оперативный контур — продажи, склад, закупки, производство, портал клиента; 1С остаётся регламентированным учётом. Номенклатура и контрагенты синхронизируются, реализации и поступления уходят в 1С, оплаты и взаиморасчёты возвращаются в Odoo. Бухгалтерию при этом никто не переписывает.
Технически обмен идёт через HTTP-сервисы на стороне 1С и внешний API Odoo. Синхронизация двусторонняя, с ключами соответствия объектов на обеих сторонах: без них повторная выгрузка создаёт дубли, и это самая частая поломка самодельных обменов. Работаем с 1С:Бухгалтерия 8.3, 1С:Управление торговлей и облачным вариантом 1С; релиз конфигурации фиксируется на старте — от него зависит состав доступных методов.
Как устроен обмен: CommerceML, HTTP-сервисы и очередь
Три способа связать 1С с внешним миром; выбирают по задаче, а не по привычке.
- CommerceML. Стандартный формат выгрузки каталога и заказов, поддержанный типовыми конфигурациями и 1С-Битрикс. Самый дешёвый путь, если обе стороны типовые.
- HTTP-сервисы 1С. Собственные методы в конфигурации: передаём ровно те поля, которые нужны, и в тот момент, когда нужно. Требует доработки на стороне 1С, зато снимает ограничения формата.
- Промежуточная очередь. Слой, который принимает событие и гарантирует доставку. Нужен там, где 1С недоступна часть суток: заказ ждёт, а не теряется.
Четыре свойства обязательны в любом варианте и почти никогда не попадают в прайсы: повторная передача заказа не создаёт второй документ, по каждой выгрузке есть журнал, о сбое обмен пишет в мониторинг сам, а изменения проверяются на копии базы.
Что ломается в обмене и как мы это чиним
Список реальных отказов вместо обещания «настроим под ключ» — то, с чем приходят, когда обмен настроен кем-то другим.
- Дубли номенклатуры. Нет ключа соответствия, и каждая выгрузка создаёт товар заново. Лечится сопоставлением по коду или артикулу и чисткой накопленных дублей до запуска.
- Остатки отстают. Каталог едет ночью целиком, а остатки меняются весь день. Разделяем расписания: справочники редко, остатки и цены часто.
- Заказы не доходят. Истёк токен, сменился пароль служебной учётной записи, 1С была недоступна в момент оформления. Ставим очередь и повторную попытку, а не надеемся на удачу.
- Оптовый прайс виден рознице. Типы цен не привязаны к группам контрагентов. Лечится настройкой привязки, а не ручной правкой карточек.
- Обмен встал после обновления. Обновили 1С или CMS, формат полей изменился. Поэтому обновления планируются и проходят через тестовый контур.
Миграция данных при переходе с 1С:УПП и старых конфигураций
Миграцию часто путают с обменом, а это разные работы: обмен — постоянная синхронная жизнь двух систем, миграция — разовый перенос с закрытием старой. Первый вопрос миграции: что переезжает. Справочники и открытые документы — почти всегда; полная история за десять лет стоит заметно дороже и обычно не нужна, её оставляют в архивной копии на чтение. Второй вопрос — качество данных: перед переносом сверяются остатки и взаиморасчёты, расхождения показываются заказчику списком. Молча перенесённая ошибка становится ошибкой новой системы.