Реализация двусторонней синхронизации каталога товаров с 1С
Представьте: менеджер обновил цену в 1С, но на сайте она висит прежняя три дня. Или товар сняли с продажи в учётной системе, а он всё ещё доступен для заказа. Двусторонняя синхронизация каталога с 1С — не просто импорт и экспорт. Это проектирование системы правил, которая разрешает конфликты данных, когда информация меняется в обеих системах одновременно. Без чёткого определения источника правды синхронизация превращается в хаос: данные затираются, возникают дубли, теряются заказы.
Типичная ситуация: в 1С изменили цену и остаток, а на сайте отредактировали описание. Если обмен настроен как односторонний импорт, описание может быть затёрто. Наш подход — двусторонний обмен с разделением полей на мастер-системы. Мы проектируем логику так, чтобы сайт и 1С оставались согласованными без ручного вмешательства.
Определение источников правды
Первый шаг — зафиксировать для каждого поля, какая система является мастером:
| Поле | Мастер | Логика |
|---|---|---|
| Название товара | 1С | 1С — система номенклатуры |
| Артикул / SKU | 1С | Артикул задаётся в учётной системе |
| Описание | Сайт | Маркетинговые тексты пишутся редактором |
| Цена | 1С | Ценообразование в учётной системе |
| Остатки | 1С | Реальный учёт на складах |
| Изображения | Сайт | Фото обрабатываются отдельно |
| SEO-поля | Сайт | meta title/description — на стороне сайта |
| Статус активности | Обе | 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 | REST API |
|---|---|---|
| Скорость развёртывания | Быстро (из коробки) | Требует разработки |
| Гибкость | Ограниченная схема | Полный контроль над полями |
| Поддержка версионирования | Нет | Да (через заголовки) |
| Детализация ошибок | Общие коды | HTTP-статусы + тело ответа |
| Производительность | Парсинг XML | JSON, быстрее |
Мы выбираем подход под конкретную задачу. Для малого бизнеса часто достаточно 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 рабочих дней. Свяжитесь с нами для аудита вашей текущей схемы синхронизации. Получите консультацию по настройке обмена данными — оценим объём работ и предложим оптимальное решение.