Двусторонняя синхронизация каталога с 1С — настройка обмена данными

Реализация двусторонней синхронизации каталога товаров с 1С

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

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

Определение источников правды

Первый шаг — зафиксировать для каждого поля, какая система является мастером:

Как разрешаются конфликты при синхронизации?

Конфликт: поле active_site было выставлено оператором сайта в false (снят с публикации), но следующая выгрузка из 1С содержит active = true. По правилам таблицы выше — 1С является мастером для active_1c, но active_site не трогается. Итог: active_1c = true, active_site = false → товар не отображается. Оператор сайта сохраняет контроль. Для каждого поля мы определяем систему-мастер и правило мержа. Это гарантирует целостность данных и исключает потерю информации.

Схема базы данных

CREATE TABLE products ( id BIGSERIAL PRIMARY KEY, onec_guid UUID UNIQUE, -- идентификатор 1С sku TEXT, -- Поля из 1С (перезаписываются при каждой синхронизации) name_1c TEXT, price_1c NUMERIC(12,2), stock_1c INTEGER, category_guid UUID, active_1c BOOLEAN DEFAULT true, -- Поля сайта (не перезаписываются синхронизацией) description TEXT, meta_title TEXT, meta_description TEXT, images JSONB, active_site BOOLEAN DEFAULT true, -- Мета синхронизации last_sync_1c TIMESTAMPTZ, sync_hash_1c CHAR(64) -- хеш данных из 1С для детекции изменений ); -- Итоговый статус: товар активен только если активен и в 1С, и на сайте CREATE VIEW products_active AS SELECT * FROM products WHERE active_1c = true AND active_site = true; 

Алгоритм синхронизации из 1С → сайт

class OnecToSiteSyncService { public function sync(CommerceMLData $data): SyncResult { $result = new SyncResult(); foreach ($data->products as $onecProduct) { $syncHash = $this->computeHash($onecProduct); $product = Product::firstOrNew(['onec_guid' => $onecProduct->guid]); // Пропускаем, если данные не изменились if ($product->exists && $product->sync_hash_1c === $syncHash) { $result->skipped++; continue; } // Обновляем ТОЛЬКО поля из 1С (не трогаем description, images и т.д.) $product->fill([ 'sku' => $onecProduct->sku, 'name_1c' => $onecProduct->name, 'price_1c' => $onecProduct->price, 'stock_1c' => $onecProduct->stock, 'category_guid'=> $onecProduct->categoryGuid, 'active_1c' => $onecProduct->active, 'last_sync_1c' => now(), 'sync_hash_1c' => $syncHash, ]); $product->save(); $result->updated++; } // Товары, которые 1С больше не выгружает — деактивируем $syncedGuids = $data->products->pluck('guid'); Product::whereNotIn('onec_guid', $syncedGuids) ->update(['active_1c' => false]); return $result; } } 

Синхронизация сайт → 1С

Сайт передаёт в 1С только то, что изменилось на сайте и имеет значение для 1С: новые заказы, возвраты, отзывы об оплате.

class SiteToOnecSyncService { public function getUnsyncedOrders(): Collection { return Order::where('sent_to_1c', false) ->where('status', '!=', 'draft') ->with(['items.product', 'customer']) ->get(); } } 

Почему важно выбрать правильный формат обмена?

CommerceML — отраслевой стандарт для интеграции с 1С, но REST API даёт больше контроля. Сравнение:

Мы выбираем подход под конкретную задачу. Для малого бизнеса часто достаточно CommerceML, для крупного каталога с highload — REST API.

Мониторинг синхронизации

-- Последние статусы синхронизации SELECT source, COUNT(*) FILTER (WHERE status = 'success') AS success, COUNT(*) FILTER (WHERE status = 'error') AS errors, MAX(finished_at) AS last_run, AVG(EXTRACT(EPOCH FROM (finished_at - started_at))) AS avg_duration_sec FROM sync_logs WHERE started_at > NOW() - INTERVAL '7 days' GROUP BY source; 

Как часто должна происходить синхронизация?

Интервал зависит от интенсивности изменений и нагрузки. Для интернет-магазина с 10 000 товаров оптимально обновлять цены и остатки каждые 15-30 минут. Для крупного маркетплейса (100 000+ позиций) — раз в 5 минут в пиковые часы и реже ночью. Всегда настраиваем регулируемое расписание с возможностью ручного запуска.

Типичные ошибки при настройке синхронизации

• Отсутствие хеширования данных: каждая выгрузка перезаписывает все поля, даже если данные не изменились. Решение — хранить хеш последней синхронизации и сравнивать.
• Игнорирование статуса активности: если товар недоступен ни в одной из систем, он всё равно отображается на сайте. Использовать логику AND между active_1c и active_site.
• Неправильный порядок обработки: сначала импорт из 1С, потом экспорт заказов — иначе возможны коллизии. Соблюдать последовательность.

Что входит в работу

• Аудит текущей схемы данных — выявляем несоответствия и точки роста.
• Проектирование правил синхронизации — определяем источники правды и логику разрешения конфликтов.
• Реализация обмена — пишем код синхронизации с использованием CommerceML или REST API.
• Тестирование на реальных данных — проверяем на боевой конфигурации, устраняем ошибки.
• Документация и обучение — передаём инструкции по эксплуатации.
• Поддержка после запуска — гарантируем стабильную работу, исправляем инциденты.

Сроки

Двусторонняя синхронизация каталога с 1С, включая тестирование на реальной конфигурации: 14–20 рабочих дней. Свяжитесь с нами для аудита вашей текущей схемы синхронизации. Получите консультацию по настройке обмена данными — оценим объём работ и предложим оптимальное решение.