Интеграция сайта с 1С: обмен товарами, заказами и остатками

Как устроить интеграцию сайта с 1С?

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

Где хранить исходные товары, цены и заказы?

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

Что выбрать: CommerceML, API, OData или файлы?

CommerceML создан для обмена коммерческой информацией и подходит типовым потокам каталога, предложений и документов между 1С и веб-витриной. REST API, OData или собственный HTTP-сервис полезны для узкого контракта и событийной логики. Решение выбирают после проверки конкретной конфигурации 1С, CMS и требуемой задержки.

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

Как синхронизировать каталог и характеристики?

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

1. Зафиксировать структуру. Определить группы, товары, варианты, комплекты и единицы измерения.
2. Сохранить идентификаторы. Хранить связь объекта сайта с объектом учётной системы.
3. Разделить поля. Не перезаписывать тексты и SEO-атрибуты, которыми владеет CMS.
4. Обрабатывать архив. Снять товар с публикации по явному правилу, а не удалять историю заказов.
5. Проверить варианты. Размер, цвет и другие свойства должны стабильно образовывать нужную торговую позицию.
6. Контролировать медиа. Передавать изображения отдельно, проверять размер, формат и обновление.

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

Как передавать цены и остатки без расхождений?

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

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

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

Как передавать заказы и возвращать статусы?

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

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

Как исключить дубли и конфликты обмена?

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

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

Как защитить обмен сайта с 1С?

Интеграция использует отдельные учётные записи с минимальными правами и получает доступ только к нужным объектам. Контур 1С не публикуют шире необходимого: применяют защищённое соединение, сетевые ограничения или шлюз, а секреты хранят вне кода и журналов. Любое внешнее значение проверяют как недоверенное.

OWASP отдельно выделяет риски нарушения авторизации, неправильной конфигурации и небезопасного использования сторонних API. Эти проверки относятся и к готовому модулю: его происхождение, обновления, права и сетевые маршруты входят в приёмку.

Как провести пилот и принять интеграцию?

Пилот ограничивают небольшим набором товаров, одним типом цены, складом и способом заказа, но проводят весь маршрут до обратного статуса. До переключения готовят тестовые случаи, контрольную сверку и план возврата. Успех подтверждается данными двух систем, а не только зелёным ответом API.

1. 01

   Инвентаризация

   Версии, доработки, модули, объёмы и владельцы систем.

2. 02

   Контракт

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

3. 03

   Тестовый обмен

   Новые и изменённые товары, цены, остатки и заказ.

4. 04

   Исключения

   Повтор, недоступность, неизвестный товар, отмена и возврат.

5. 05

   Сверка

   Количество, суммы, статусы, пропуски и лишние записи.

6. 06

   Ограниченный запуск

   Наблюдение, разбор очереди и решение о расширении.

Критерии и ответственность удобно закрепить в документе по принципам технического задания на разработку. Для B2B-витрины дополнительно проверьте роли, договорные цены и лимиты из руководства по B2B-личному кабинету.

Что влияет на стоимость интеграции сайта с 1С?

Стоимость определяют не названия систем, а количество потоков, варианты данных, доработки конфигурации, требования к задержке и приёмке. Точная оценка появляется после диагностики тестового контура и критичных неизвестных. Поэтому смету связывают с перечнем проверяемых работ и границ. До этого корректен только диапазон с перечисленными допущениями и исключениями.

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

Частые вопросы