Інтеграція 1С і Magento 2: де ламається обмін
Інтеграція 1С Magento 2 ламається не на старті, а на обсязі: перші тижні обмін каталогом іде чисто, а потім у вивантаженні з'являються дублі позицій, ціни на вітрині розходяться з обліковими, а частина замовлень зависає в проміжному статусі.
Причина майже завжди одна — обмін побудований на повному вивантаженні за розкладом, без розмітки змін і без журналу операцій. Чим більше номенклатури та замовлень, тим довше вікно, в якому дані на сайті та в обліковій системі живуть окремо.
Ціна розсинхрону рахується швидко. Клієнт оформлює замовлення за ціною, якої на складі вже немає, — менеджер або скасовує продаж, або продає в мінус. Синхронізація залишків із затримкою в години дає перепродажі за позиціями, яких фізично не залишилося, і повернення.
Завислий статус замовлення означає, що збирання не запустилося: товар лежить, клієнт чекає, а служба підтримки вручну звіряє списки. Дублі позицій роздувають каталог, ламають фільтри та розмивають пошукову видачу.
Окрема категорія збоїв — невідповідність довідників. Одиниці виміру, ставки податків, склади та контрагенти в 1С і Magento 2 описані по-різному, і обмін мовчки пропускає те, що не зміг зіставити.
Помилка не спливає одразу: вона накопичується в логах, поки розходження не стане помітним за виручкою.
Розбираємо, як це закривається: розмітка змін замість повного вивантаження, ідемпотентні операції, журнал обміну з повтором пакетів, що впали, і звірка розходжень за розкладом.
Що дає налаштування обміну: ефект за вузлами
Каталог: інкрементальний обмін замість повного вивантаження
Повне вивантаження каталогу на 40–60 тисяч позицій — це години роботи та пікове навантаження на обидві системи. Інкрементальний обмін передає лише ті позиції, що змінилися з моменту попереднього проходу: правки цін, описів, прив'язок до категорій. Час проходу падає з годин до хвилин, а сервер не простоює на перезбиранні незміненого.
Залишки: черга подій і частота обміну
Залишки — найчутливіший вузол: розбіжність у 10 хвилин дає продаж того, чого немає на складі. Черга подій фіксує кожен рух за регістром і віддає його пачками за розкладом — від разу за кілька хвилин до разу на годину.
Чим вища частота, тим менше вікно пересорту, але тим більше запитів тримає база. Розумний компроміс — обмін залишками кожні 5–15 хвилин плюс примусова синхронізація перед гарячими акціями.
Замовлення: зворотний потік без втрат
Замовлення з Magento 2 вирушає в 1С з ідемпотентним ключем — повторне надсилання при збої зв'язку не створює дубль документа. Статуси та оплата повертаються зворотним потоком, клієнт бачить актуальний стан в особистому кабінеті. Частка втрачених замовлень прямує до нуля, а ручне перенесення з пошти та таблиць зникає з процесу.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Повне вивантаження | Первинне заливання, відновлення після збою | Години роботи, високе навантаження |
| Інкрементальний обмін | Каталог, ціни, описи в робочому режимі | Потребує надійних міток змін |
| Черга подій | Залишки, замовлення, статуси | Потрібен контроль глибини черги |
| Обмін за запитом | Ручний запуск перед акцією | Не закриває потік у реальному часі |
Наші інженери будують обмін на штатних механізмах платформи та RabbitMQ як транспорті черги — це дає повтор доставки та розв'язку за навантаженням.
Етапи налаштування обміну 1С і Magento 2
Інтеграція 1С Magento 2 починається не з коду, а з аудиту облікової системи: які довідники реально ведуться, де дублі номенклатури, як влаштовані характеристики та торгові пропозиції, хто і як часто змінює ціни.
На цьому ж етапі фіксуємо склад сутностей обміну — каталог, залишки за складами, замовлення, статуси, контрагенти — і визначаємо, що є джерелом істини за кожним полем.
Помилка тут коштує найдорожче: якщо в обліковій системі немає єдиного ключа товару, будь-який обмін плодитиме дублі та розбіжності.
- Аудит облікової системи та каталогу. Розбираємо структуру номенклатури, характеристики, одиниці виміру, склади та правила ціноутворення. Фіксуємо розбіжності між тим, як товар заведений в обліку, і тим, як він має виглядати в каталозі на сайті.
- Проєктування схеми обміну. Визначаємо напрямок потоків, частоту синхронізації, правила зіставлення сутностей і поведінку при конфліктах. Окремо описуємо, що робити з товарами, знятими з продажу, і із замовленнями, оформленими в момент обміну.
- Налаштування вивантаження каталогу та залишків. Налаштовуємо формування пакетів, посторінкову передачу та обробку змін — щоб обмін ішов порціями і не блокував роботу сайту. Залишки передаємо з прив'язкою до складів, ціни — з урахуванням правил знижок.
- Налаштування приймання замовлень. Замовлення йдуть із магазину в облікову систему зі складом, адресою, способом доставки та оплати. Налаштовуємо зворотну передачу статусів, щоб покупець бачив актуальний стан замовлення.
- Перевірка на бойових даних. Проганяємо обмін на реальному каталозі та реальних замовленнях: звіряємо кількість позицій, залишки, ціни, історію статусів. Окремо перевіряємо сценарії збою — обрив зв'язку, повторна передача, конфлікт змін.
- Налаштування моніторингу та журналювання. Логуємо кожен сеанс обміну, рахуємо розбіжності та оповіщаємо відповідального при помилках. Без цього збій виявляється за скаргою покупця, а не за сигналом системи.
- Передача регламентів. Віддаємо документацію щодо запуску обміну, дій при збоях, порядку додавання нових складів і правил цін. Навчаємо співробітників, які супроводжуватимуть інтеграцію.
Кожен етап закінчується перевірюваним результатом: узгодженою схемою, працюючим обміном на тестовому контурі, звіркою на бойових даних. Такий порядок дозволяє запускати синхронізацію без зупинки продажів і розуміти, де саме виникла розбіжність, якщо вона з'явилася.
Чим відрізняється обмін залишками від обміну замовленнями?
Це два різних потоки даних із протилежним напрямком і різною ціною помилки. Залишки йдуть з 1С у Magento 2: склад — єдине джерело правди щодо кількості, і завдання обміну — швидко донести число до вітрини, щоб покупець не оформив замовлення на те, чого немає.
Замовлення йдуть у зворотний бік: Magento 2 фіксує факт покупки, а 1С приймає його в облік. Тут пріоритет джерела зворотний, і плутати напрямки не можна — інакше отримаєте залишок, перезаписаний вітриною, або замовлення, втрачене під час синхронізації.
Обмін залишками терпимий до затримки й агресивний до частоти. Достатньо оновлювати каталог раз на кілька хвилин, але за всіма позиціями одразу, інакше на сайті залишиться «привид» товару, який уже розпродано.
Конфлікт даних тут вирішується просто: якщо 1С надіслала нуль — вітрина зобов'язана закрити позицію, навіть якщо хвилину тому показувала наявність. Зворотний пріоритет неприпустимий, інакше продажі на сайті будуть обганяти реальний склад.
Обмін замовленнями, навпаки, вимагає гарантії доставки кожного документа. Замовлення не можна «втратити при наступному оновленні» — воно має дійти до 1С рівно один раз, без дублів.
Тому тут працює черга з підтвердженням: вітрина надіслала замовлення, дочекалася відповіді облікової системи й лише тоді змінює статус. Статуси замовлень — окремий контур: «оплачено», «зібрано», «відвантажено» надходять із 1С і не повинні перетиратися даними сайту.
Конфлікт даних у замовленнях небезпечніший, ніж у залишках. Якщо покупець скасував замовлення на сайті, а 1С уже провела збирання — розбіжність доведеться розбирати вручну.
Тому ми розводимо потоки за окремими розкладами й правилами пріоритету: залишки — частий односторонній обмін, замовлення — надійна доставка з журналом і повторними спробами. Такий поділ прибирає 90% розсинхронів ще до того, як вони доходять до бухгалтерії.
Кейс: як обмін перестав втрачати замовлення та ціни
До впровадження обмін будувався на регламентних завданнях: вивантаження каталогу раз на добу, залишки — раз на кілька годин, замовлення забиралися пакетом.
Між вікнами обміну накопичувалася черга, і частина замовлень, оформлених у момент вивантаження, не знаходила відповідності за кодом номенклатури — вони осідали в проміжній таблиці й потребували ручного розбору.
Ціни на сайті жили окремим життям: поки менеджер правил прайс в обліковій системі, вітрина показувала старе значення, і розбіжність трималася до наступного циклу.
Що змінили
Перевели обмін на подієву модель: зміни номенклатури, цін і залишків публікуються в чергу одразу під час проведення документа, а не за розкладом.
Замовлення забираються інкрементально за ідентифікатором останньої успішної синхронізації — повторна обробка ідемпотентна, дублі відсікаються на вході.
Для зіставлення позицій завели явний реєстр відповідностей між обліковими кодами та ідентифікаторами вітрини, а нечіткі збіги за назвою прибрали з логіки.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Частка втрачених замовлень | 3-4% у пікові дні | поодинокі випадки, розбираються за логом |
| Час розбіжності цін | до 24 годин | секунди після проведення документа |
| Ручні правки на день | 40-60 операцій | 2-5, переважно нові позиції |
| Розбір черги помилок | вручну, без історії | за журналом із трасуванням до документа |
Окремо закрили відкат: якщо обмін падає на середині пакета, стан відкочується до останньої підтвердженої точки, а не залишається частково застосованим. Це прибрало клас інцидентів, коли половина замовлень пішла в облікову систему, а половина зависла.
Magento 2 і 1С залишаються пов'язаними через проміжний шар, який можна перезапустити без зупинки вітрини.
Сумніви щодо сумісності, доступів і відкату
Найчастіше запитання на цій стадії — що буде з обміном, коли на боці каталогу оновлять схему атрибутів або на боці обліку змінять реквізити номенклатури.
Відповідаємо чесно: обмін будується не на жорстких прив'язках до полів, а на правилах зіставлення, тому розширення довідника не ламає потік — нові властивості підхоплюються за мапінгом, а невідомі складаються в чергу на розбір із повідомленням відповідального.
Сумісність версій і права доступу фіксуємо на старті: сервісний користувач отримує лише ті об'єкти, які беруть участь в обміні, а не повний доступ до бази.
Що якщо обмін зламається вночі або в розпал розпродажу?
Обмін іде пакетами з журналюванням кожного кроку, тому збій не залишає «половину» даних: незавершений пакет відкочується цілком і повторюється за розкладом.
Відповідальний отримує повідомлення із зазначенням, на якому кроці й по якому об'єкту зупинилося, а розбіжність між каталогом і обліком видно у звірці — вона запускається автоматично й показує розбіжності за залишками та замовленнями.
План відкату описано заздалегідь: повернення до попередньої схеми обміну й повторне вивантаження з облікової системи як джерела істини.
Що якщо у нас своя команда супроводу? Передаємо документацію обміну й регламент підтримки — за ними ваші інженери зможуть розбирати типові ситуації без нас. Що якщо правила зіставлення зміняться? Мапінг винесено в налаштовуваний довідник, правки не потребують переписування коду обміну.
Після здачі ви отримуєте на руки:
- схему потоків даних між обліковою системою та каталогом із зазначенням періодичності й обсягів;
- карту зіставлення полів: номенклатура, ціни, залишки, замовлення, статуси;
- конфігурацію сервісного користувача з мінімально необхідними правами доступу;
- журнал обміну й налаштовані повідомлення про помилки з адресатами;
- інструкцію щодо плану відкату й повторної синхронізації;
- регламент підтримки із зонами відповідальності та строками реакції;
- чеклист приймання обміну за кожним типом даних.
Опишіть вашу конфігурацію — які довідники беруть участь в обміні та як часто потрібні залишки — повернемося з оцінкою та планом робіт.
Терміни налаштування обміну за етапами
Налаштування обміну 1С і Magento 2 відбувається хвилями: спочатку піднімаємо контур на тестовій копії, потім переносимо на робочий контур. Такий порядок дозволяє побачити реальні терміни впровадження на ваших даних, а не на усереднених.
Етапи обміну частково йдуть паралельно: каталог і залишки можна вести однією гілкою, замовлення підключати після стабілізації номенклатури. Тому сумарний термін зазвичай коротший, ніж проста сума рядків таблиці.
Magento 2 чутливий до якості довідників: якщо в 1С є дублі або порожні обов'язкові поля, обмін зупиниться на них, а не на коді. Тому обстеження винесено в окремий етап — воно знімає основні ризики щодо термінів.
