Налаштування обміну 1С та Magento 2: каталог, залишки, замовлення

Проблема синхронізації 1С та Magento 2

Ви запустили інтернет-магазин на Magento 2, а 1С — основа обліку. Товари, ціни, залишки — все має бути синхронізовано в реальному часі. На практиці інтеграція часто перетворюється на головний біль: невідповідність даних, втрата замовлень, помилки в залишках. Одного разу ми виправляли інтеграцію, де через тайм-аут REST-з'єднання пропало 20% замовлень. Після переходу на чергу RabbitMQ — нуль втрат. Правильна архітектура з чергою та обробкою помилок — запорука стабільної роботи. Замовте консультацію — ми проаналізуємо ваші дані та запропонуємо рішення.

Чому пряма REST-інтеграція ненадійна?

Пряме REST-з'єднання працює, але ненадійне при пікових навантаженнях. Черга повідомлень (RabbitMQ або Redis) дає гарантію доставки та дозволяє уникнути втрати даних. Порівняння підходів:

Інтеграція через чергу втричі надійніша — це перевірено на десятках проєктів. Magento Developer Documentation також рекомендує асинхронну архітектуру. CommerceML — стандарт обміну даними, спрощує узгодження форматів. Для каталогів із десятками тисяч товарів прямий REST-запит на оновлення всіх залишків може тривати хвилинами, блокуючи інші операції. Черга розбиває операцію на дрібні завдання, що обробляються асинхронно. Це виключає тайм-аути та знижує навантаження на сервер.

Архітектура з чергою: як це працює

Типова архітектура включає проміжний шар, який ізолює Magento від 1С. У цьому шарі працюють три компоненти: черга повідомлень (RabbitMQ або Redis), трансформер даних та обробник помилок з retry-логікою. Черга приймає події від 1С та Magento, трансформер переводить дані у потрібний формат, а обробник повторює запити при збоях. Надійність забезпечується persistent-повідомленнями в RabbitMQ та дублюванням у базу даних.

1С ←→ Integration Layer ←→ Magento 2 Integration Layer: - Queue (RabbitMQ / Redis) - Transformer (1С-формат ↔ Magento-формат) - Error Handler - Retry Logic 

Як реалізувати синхронізацію залишків з MSI?

Magento 2.3+ використовує Multi-Source Inventory. Оновлення залишків через MSI API — обов'язковий крок. Ось як це виглядає в коді:

def update_stock_msi(self, sku: str, source_code: str, qty: float): payload = { "sourceItems": [{ "sku": sku, "source_code": source_code, "quantity": qty, "status": 1 if qty > 0 else 0 }] } requests.post(f"{self.m2_url}/rest/V1/inventory/source-items", headers=self.m2_headers, json=payload) 

Цей метод оновлює залишки для конкретного складу (source_code). MSI API дозволяє гнучко керувати множиною точок зберігання, що критично для компаній з кількома складами або постачальниками. У випадку legacy-інвентарю (Magento 2.2 і нижче) використовувався інший ендпоінт, але з версії 2.3 рекомендується саме MSI.

Імпорт товарів та вивантаження замовлень

Нижче — Python-воркер, який забирає товари з 1С та створює або оновлює їх в Magento.

import requests import json from magento.models.product import Product class OneCMagentoSync: def __init__(self, m2_url, m2_token, onec_url, onec_auth): self.m2_url = m2_url self.m2_headers = {"Authorization": f"Bearer {m2_token}", "Content-Type": "application/json"} self.onec_url = onec_url self.onec_auth = onec_auth def sync_products(self): # Get products from 1C response = requests.get(f"{self.onec_url}/products", auth=self.onec_auth) products_1c = response.json() for product_data in products_1c: self.upsert_product(product_data) def upsert_product(self, data: dict): sku = data['sku'] # Check existence in Magento check = requests.get(f"{self.m2_url}/rest/V1/products/{sku}", headers=self.m2_headers) payload = { "product": { "sku": sku, "name": data['name'], "price": float(data['price']), "status": 1, "type_id": "simple", "attribute_set_id": 4, "extension_attributes": { "stock_item": { "qty": int(data['quantity']), "is_in_stock": int(data['quantity']) > 0 } } } } if check.status_code == 200: # Update requests.put(f"{self.m2_url}/rest/V1/products/{sku}", headers=self.m2_headers, json=payload) else: # Create requests.post(f"{self.m2_url}/rest/V1/products", headers=self.m2_headers, json=payload) 

Цей воркер передбачає, що в 1С є REST API для отримання товарів. Якщо ні — можна використовувати вивантаження в CSV або CommerceML. Важно налаштувати мапінг атрибутів: наприклад, поле 'sku' в 1С може називатися 'article'. Ми створюємо словник відповідностей для кожного клієнта.

Для повноцінного обліку важливо передавати замовлення з Magento в 1С. Код нижче отримує необроблені замовлення та надсилає їх.

def export_orders_to_1c(self): # Get unprocessed orders response = requests.get( f"{self.m2_url}/rest/V1/orders", params={ "searchCriteria[filter_groups][0][filters][0][field]": "status", "searchCriteria[filter_groups][0][filters][0][value]": "pending", "searchCriteria[pageSize]": 50 }, headers=self.m2_headers ) orders = response.json()['items'] for order in orders: order_1c = self.transform_order(order) # Send to 1C result = requests.post( f"{self.onec_url}/orders", json=order_1c, auth=self.onec_auth, timeout=10 ) if result.status_code == 200: # Mark order as transferred to 1C requests.post( f"{self.m2_url}/rest/V1/orders/{order['entity_id']}/comments", headers=self.m2_headers, json={"statusHistory": {"comment": "Transferred to 1C", "status": "processing"}} ) 

При вивантаженні замовлень важливо відстежувати статус: замовлення не повинне двічі потрапити в 1С. Ми використовуємо унікальний ID замовлення та перевіряємо його існування в 1С перед надсиланням. Також застосовуємо транзакційну логіку — якщо 1С не відповіла, замовлення залишається в черзі.

Щоб уникнути втрати даних, всі операції ставляться в чергу RabbitMQ. Persistent-повідомлення не зникають навіть при перезапуску.

import pika # RabbitMQ def publish_to_queue(self, event_type: str, data: dict): connection = pika.BlockingConnection(pika.URLParameters(RABBITMQ_URL)) channel = connection.channel() channel.queue_declare(queue='magento_1c_sync', durable=True) channel.basic_publish( exchange='', routing_key='magento_1c_sync', body=json.dumps({"type": event_type, "data": data}), properties=pika.BasicProperties(delivery_mode=2) # persistent ) connection.close() 

Ми налаштовуємо dead-letter exchange для повідомлень, які не вдалося обробити після кількох спроб. Це дозволяє не втрачати проблемні дані, а аналізувати їх окремо.

Типові помилки та як їх уникнути

Найчастіше проблеми виникають через некоректний мапінг атрибутів (наприклад, різний формат ціни), невідповідність одиниць вимірювання та конфлікти залишків при паралельному записі. Рішення — використовувати чергу та транзакційний API. Ми також документуємо всі трансформації даних, щоб уникнути сюрпризів. Додатково, для виключення дублювання замовлень, налаштовуємо idempotent-ключі.

Процес впровадження та терміни

1. Аудит даних — виявити невідповідності в номенклатурі, цінах, одиницях вимірювання.
2. Проектування схеми обміну — визначити мапінг полів, формати, протокол.
3. Розробка інтеграційного шару — реалізувати чергу, трансформери, обробники помилок.
4. Налаштування MSI — синхронізація залишків по складах.
5. Тестування на копії даних — перевірка повноти та коректності.
6. Запуск в експлуатацію — включення синхронізації в пілотному режимі.
7. Моніторинг та підтримка — відстеження метрик, обробка збоїв.

Базова синхронізація (каталог + залишки в один бік) — 10–14 днів. Двостороння інтеграція із замовленнями, чергою та моніторингом — 3–4 тижні. Конкретні терміни розраховуємо індивідуально після аудиту даних.

Гарантії та результати

Ми надаємо письмову гарантію на коректність синхронізації протягом 3 місяців після впровадження. Будь-які збої виправляються безкоштовно. Сертифіковані спеціалісти з Magento та 1С з понад 10-річним досвідом забезпечують відповідність найкращим практикам. Скорочення витрат на підтримку до 40% та прискорення обробки замовлень на 50% — типові результати після впровадження. Отримайте консультацію — перший аналіз даних безкоштовно. Зв'яжіться з нами для оцінки вашого проєкту.