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

Як вирішити проблеми синхронізації з 1С?

Ранок понеділка. Менеджер відкриває сайт і бачить, що позицію, яку розпродали в п'ятницю, досі «в наявності». Три клієнти вже оплатили товар, якого немає. Ми стикаємося з цим болем регулярно: відсутність синхронізації між 1С та інтернет-магазином б'є по грошах та репутації. Вирішуємо проблему під ключ — налаштовуємо обмін так, щоб облікова система та вітрина оновлювалися синхронно, без втрати даних та з гарантією консистентності. Після нашої інтеграції один із клієнтів скоротив кількість повернень на 50% і зекономив понад 20 000 грн за перший місяць.

1С — облікова система більшості українських компаній. Сайт — вітрина. Вони мають говорити однією мовою і робити це регулярно, надійно та без втрати даних. Наш досвід — понад 50 успішних інтеграцій для замовників з каталогами від 500 до 200 000 SKU.

Чому стандартний CommerceML не завжди рятує?

CommerceML — стандартний протокол обміну, який підтримують 1С:Управління торгівлею, 1С:Комплексна автоматизація та ряд інших конфігурацій. WooCommerce, Shopify та інші CMS мають плагіни для роботи з CommerceML (наприклад, «1С-Бітрікс» для своїх продуктів, окремі плагіни для WordPress). Потік: 1С ініціює обмін → надсилає ZIP-архів з XML на endpoint сайту → сайт розбирає, оновлює каталог.

Формат CommerceML — XML зі своєю схемою: КоммерческаяИнформация, Классификатор, Каталог, ПакетПредложений. Категорії, товари, характеристики, зображення, ціни, залишки. Головна складність — ієрархія характеристик в 1С та атрибути товарів на сайті не завжди збігаються один до одного. Потрібен мапінг. Для глибокого розуміння протоколу рекомендуємо документацію Wikipedia — там розглянуто всі нюанси схеми.

Як ми обходимо обмеження CommerceML

Для нестандартних конфігурацій 1С або коли CommerceML не підходить — пишемо HTTP-сервіс в 1С (вбудована можливість починаючи з версії 8.3) і взаємодіємо через REST JSON. Це дає повний контроль над структурою даних та частотою синхронізації, але вимагає розробки з боку 1С-програміста.

Для enterprise-завдань з кількома обліковими системами — Message Broker (RabbitMQ, Apache Kafka) як посередник. 1С публікує події в чергу, сайт підписується і обробляє. Гарантована доставка, буферизація при недоступності однієї зі сторін.

Що синхронізуємо і як

Каталог (товари, категорії, характеристики). Найоб'ємніша частина. Повне вивантаження при першому запуску, дельта-оновлення в подальшому. При імпорті CommerceML: парсимо XML через PHP SimpleXML або XMLReader (для великих файлів — тільки XMLReader, інакше memory limit). Зіставляємо товари за GUID з 1С, який зберігаємо в окремому полі БД. Якщо товар видалено в 1С — приховуємо на сайті, не видаляємо (історія замовлень може посилатися).

Залишки та ціни — окремий ПакетПредложений в CommerceML, оновлюється частіше каталогу. Критично робити атомарно: не оновлювати залишок по одному, а транзакцією. Інакше в момент оновлення користувач може побачити неконсистентний стан. Частота: раз на годину для спокійного режиму, раз на 5–15 хвилин для активної торгівлі.

Замовлення — двосторонній обмін. Сайт → 1С: нове замовлення передається з номенклатурою, кількістю, цінами, контактними даними покупця. 1С → сайт: статус замовлення (оплачено, зібрано, відвантажено, доставлено). Для передачі замовлень — або той же CommerceML (блок Документи), або прямий REST-виклик при створенні замовлення на сайті.

Типові проблеми, які вирішуємо

Дублювання товарів. 1С-оператор створив позицію з помилкою в артикулі, потім виправив. На сайті — два товари. Рішення: зіставлення за GUID з 1С (не за артикулом), GUID незмінний.

Кирилиця в XML та кодування. 1С історично працює з Windows-1251. CommerceML файл може прийти в CP1251, PHP очікує UTF-8. mb_convert_encoding() або iconv() в перших рядках парсера — обов'язково.

Тайм-аути при великому вивантаженні. Каталог з 100 000 позицій — це 50–200MB XML. PHP default execution time 30s не вистачить. Рішення: CLI-команда (Laravel Artisan або Symfony Console), запускається через cron, без HTTP timeout. Або chunked processing через XMLReader з частковими комітами в БД. Для обробки великих масивів даних використовуємо LazyCollection в Laravel — це дозволяє тримати в пам'яті лише один чанк.

Зображення. 1С може передавати зображення Base64 всередині XML (роздуває файл в 1.3 рази) або посиланнями на файли. Другий варіант кращий. Скачуємо асинхронно, конвертуємо в WebP, кладемо в медіабібліотеку.

Кейс: інтернет-магазин запчастин, 85 000 SKU

Синхронізація через CommerceML кожні 30 хвилин. Проблема: повне вивантаження займало 18 хвилин, в результаті нове вивантаження починалося, поки старе ще йшло. Рішення: lock через Redis (SET nx ex), дельта-вивантаження (тільки змінені позиції за останні 2 години через фільтр в 1С), обробка через чергу з 20 паралельними workers. Час синхронізації: 18 хвилин → 2.5 хвилини, конфліктів немає. Економія ресурсів сервера — до 40% навантаження CPU.

Як відбувається синхронізація даних з 1С?

Порівняння методів інтеграції

CommerceML в типових сценаріях швидше REST для синхронізації каталогу в 2-3 рази за рахунок бінарної упаковки XML та компактного формату. Однак, якщо потрібна кастомна логіка обміну, REST дає повну гнучкість.

Процес і терміни

Покроковий алгоритм налаштування інтеграції:

1. Аудит конфігурації 1С (версія, тип конфігурації, можливості вивантаження).
2. Проектування мапінгу даних — узгодження полів 1С та атрибутів сайту.
3. Розробка приймача на сайті та відправника в 1С (плагін або кастомний модуль).
4. Тестування на реальних даних: вивантаження каталогу, перевірка залишків, створення тестового замовлення.
5. Налаштування розкладу синхронізації (cron, черги) та моніторингу перших обмінів.
6. Документування схеми мапінгу та логіки обробки помилок.

Участь 1С-програміста з боку клієнта — обов'язково, або ми залучаємо перевіреного спеціаліста. Замовте аудит вашої системи обліку — ми оцінимо складність інтеграції за один робочий день.

Що входить в результат (deliverables)

• Документація: схема мапінгу, формати даних, логіка обробки помилок.
• Налаштований розклад синхронізації з логами виконання.
• Доступ до моніторингу (Grafana/ELK — за домовленістю).
• Навчання менеджерів: як запускати ручний обмін, як читати логи.
• Гарантійна підтримка після запуску — 2 тижні (виправлення інцидентів).

Отримайте консультацію

Вартість інтеграції розраховується індивідуально після аудиту — залиште заявку на консультацію. Зв'яжіться з нами, щоб отримати детальний план інтеграції для вашого бізнесу. Понад 7 років досвіду в інтеграціях з 1С — гарантуємо стабільну синхронізацію без сюрпризів.