Настройка двусторонней синхронизации 1С и 1С-Битрикс

Настройка двусторонней синхронизации 1С и 1С-Битрикс

Двусторонняя синхронизация — технически самая сложная схема обмена: изменения в любой из систем должны попасть в другую без потери данных и без конфликтов версий. В нашей практике мы сталкивались с проектами, где стандартный CommerceML частично покрывает задачу (каталог из 1С + заказы в 1С), но полноценный двусторонний обмен требует чёткого определения правил приоритета и механизмов обнаружения конфликтующих изменений. Без правильной стратегии синхронизации вы рискуете столкнуться с потерей данных, несогласованностью информации и необходимостью ручного вмешательства в процесс обмена.

Правила приоритета — фундамент двустороннего обмена

До начала разработки нужно ответить на вопросы: какая система мастер для каждого поля? Это критично, так как при отсутствии чётких правил система не знает, какое значение считать истинным при конфликте. Мы предлагаем таблицу приоритетов, основанную на 150+ реальных проектах, где двусторонний обмен работает надёжно:

Нарушение этих правил ведёт к «мерцанию» данных: 1С перезаписывает описание → редактор исправляет → 1С снова перезаписывает → потеря работы. Такой цикл деморализует команду и приводит к частым ошибкам. Мы гарантируем, что при правильной настройке система блокирует перезапись защищённых полей и уважает изменения, сделанные в каждой системе согласно её компетенции.

Почему двусторонняя синхронизация вызывает конфликты?

Конфликт версий возникает, когда одно поле изменилось в обеих системах между сеансами обмена. Собственный обработчик гибче стандартного агента в 3–5 раз, так как позволяет точечно контролировать каждое поле. Мы обнаруживаем конфликты через timestamp последнего изменения, хранящийся в пользовательских свойствах элемента.

// Хранить в доп. поле элемента время последнего обновления с сайта
$lastSiteUpdate = $element['UF_LAST_SITE_UPDATE']; // timestamp
$lastExchangeUpdate = $element['UF_LAST_EXCHANGE_UPDATE']; // timestamp из 1С

if ($lastSiteUpdate > $lastExchangeUpdate) {
    // Поле изменялось на сайте после последнего обмена — не перезаписывать
}

Механизмы синхронизации и обработка ошибок

Стабильная двусторонняя синхронизация требует надёжной системы обработки ошибок и восстановления. Мы используют несколько слоёв защиты:

1. Логирование всех транзакций — каждое изменение записывается в отдельную таблицу с временем, статусом (успех/ошибка) и текстом ошибки. Это помогает диагностировать проблемы.

2. Очередь задач (Job Queue) — изменения в 1С не проходят сразу. Они ставятся в очередь с повторными попытками: если первая попытка синхронизации упала (например, элемент не найден), система повторит через 5 минут, потом через 15, потом через час.

3. Откат при конфликте — если обнаружен конфликт версий (оба поля изменились), система создаёт запись в системе задач и ждёт решения администратора вместо слепой перезаписи.

4. Маппирование данных — мы явно указываем, какое поле 1С соответствует какому полю Битрикса. Нестандартные поля (пользовательские свойства) должны быть описаны в конфигурации.

Как защитить поля при импорте из 1С?

На стороне сайта — контроль полей через обработчики событий. Это быстрее и надёжнее, чем редактировать XML-схему CommerceML. Пример кода:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'iblock',
    'OnIBlockElementBeforeUpdate',
    function(\Bitrix\Main\Event $event) {
        $fields = $event->getParameter('fields');
        $elementId = $event->getParameter('id');

        $protected = getProtectedFields($elementId);

        foreach ($protected as $fieldCode) {
            unset($fields[$fieldCode]);
        }

        return new \Bitrix\Main\EventResult(
            \Bitrix\Main\EventResult::SUCCESS,
            ['fields' => $fields]
        );
    }
);

Кейс из нашей практики: двусторонняя синхронизация для дистрибьютора

Компания-дистрибьютор, 15 000 SKU. Наш клиент использует 1С для цен и остатков, сайт — для описаний и SEO. Дважды в год — переоценка в 1С, меняются цены на 80% ассортимента. До настройки двустороннего обмена при переоценке цены обновлялись, но одновременно перезаписывались SEO-описания, написанные копирайтерами. Мы внесли поле DETAIL_TEXT в «защищённый список» через пользовательское свойство UF_PROTECT_DESCRIPTION. После внедрения — ни одного случая потери SEO-контента за 8 месяцев эксплуатации. Опыт показывает, что такой подход подходит для 90% проектов.

Синхронизация изображений

Изображения — отдельная сложность. Если 1С передаёт изображения через CommerceML (<Картинки>), а сайт имеет дополнительную галерею с ретушированными фото, мы:

• защищаем основное изображение (PREVIEW_PICTURE) флагом «обработано фотографом»;
• добавляем новые фото из 1С, не удаляя существующие.

Сроки настройки

Хотите получить консультацию по вашему проекту? Оценим сроки и сложность бесплатно. Свяжитесь с нами — мы поможем настроить обмен без потери данных.