Сначала определяют владельца каждого типа данных
Интеграция ломается не из-за формата файла, а из-за неясных правил. Нужно решить, где создаются карточки, кто меняет описание, откуда приходят цены и остатки, куда сайт передаёт заказ и может ли менеджер редактировать его после обмена.
Для каждого поля назначают источник истины. Например, 1С отвечает за артикул, цену и остаток, а сайт — за SEO-текст и фотографии. Тогда очередная выгрузка не перезапишет работу контент-менеджера.
Что обычно синхронизируют
Состав обмена зависит от конфигурации 1С и логики магазина. Минимальный набор лучше расширять поэтапно.
- Категории, товары, характеристики и варианты
- Типы цен, скидки и остатки по складам
- Изображения и файлы, если их источником является 1С
- Заказы, покупатели, доставки и способы оплаты
- Статусы обработки и номера отгрузок
- Справочники брендов, единиц измерения и контрагентов
CommerceML, файлы или API
Стандартный обмен с сайтом часто строится на CommerceML. Для нестандартных сценариев используют HTTP-сервисы, JSON, очередь сообщений или промежуточный сервис. Выбор зависит от конфигурации 1С, объёма каталога, нужной частоты и возможности доработки обеих сторон.
Большой каталог не стоит каждый раз выгружать полностью. Инкрементальный обмен передаёт только изменения, а пакетная обработка не перегружает сервер. Для критичных остатков иногда нужен отдельный быстрый канал.
Что проверить перед запуском
Тестовый контур должен быть максимально похож на рабочий. Сначала запускают небольшой набор товаров и заказов, затем полный каталог и только после сверки включают расписание.
Обязательны устойчивые внешние идентификаторы, журнал обмена, повтор обработки без дублей, уведомление об ошибках и инструкция для ответственного сотрудника. Резервная копия нужна до первой полной синхронизации.
- Дубликаты артикулов и характеристик
- Товары без категории или цены
- Нулевые и отрицательные остатки
- Изменение заказа после передачи в 1С
- Обрыв соединения в середине пакета
- Повторная отправка одного и того же заказа