Двостороння синхронізація каталогу товарів з 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 робочих днів. Зв'яжіться з нами для аудиту вашої поточної схеми синхронізації. Отримайте консультацію з налаштування обміну даними — оцінимо обсяг робіт і запропонуємо оптимальне рішення.