Настройка обмена 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): # Получить товары из 1С 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'] # Проверить существование в 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: # Обновить requests.put(f"{self.m2_url}/rest/V1/products/{sku}", headers=self.m2_headers, json=payload) else: # Создать 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): # Получить необработанные заказы 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) # Отправить в 1С result = requests.post( f"{self.onec_url}/orders", json=order_1c, auth=self.onec_auth, timeout=10 ) if result.status_code == 200: # Отметить заказ как переданный в 1С requests.post( f"{self.m2_url}/rest/V1/orders/{order['entity_id']}/comments", headers=self.m2_headers, json={"statusHistory": {"comment": "Передан в 1С", "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С обеспечивают соответствие лучшим практикам. Сокращение затрат на поддержку до 40% и ускорение обработки заказов на 50% — типичные результаты после внедрения. Получите консультацию — первый анализ данных бесплатно. Свяжитесь с нами для оценки вашего проекта.