Автонаповнення каталогу на Битрикс: де ламається обмін
Обмін з постачальниками формально працює: файл забирається, рядки розбираються, товари з'являються на сайті.
Розходиться все в деталях — і там, де розходження коштує продажів: ціна у постачальника змінилася, а картка ще добу живе зі старою; залишок обнулився, а кнопка «Купити» залишилася активною. Замовлення оформлюється на позицію, якої немає, і відмова приходить вже після оплати.
Причина майже завжди в зіставленні номенклатури. У постачальника свої артикули, у нас свої; зв'язка тримається на збігу назв, а назву постачальник править разом з ціною.
Виникають дублі, частина позицій мовчки випадає з вивантаження, а обмін, що впав на середині, залишає каталог в напівготовому стані — і цього ніхто не бачить, поки не зателефонує покупець.
Ручне викладення товарів маскує проблему, але не вирішує: менеджер звіряє прайси очима і править ціни вибірково. До кінця місяця каталог і дані постачальників розходяться так, що помилки в цінах шукають за претензіями покупців, а не за звітом.
Автонаповнення каталогу на Битрикс в такому режимі не економить час, а переносить ручну роботу на розбір наслідків.
Розбираємо, як це закривається: зіставлення за стійкими ключами, журнал розходжень залишків і пріоритети джерел ціни — щоб каталог відображав дані постачальників, а не останнє вдале вивантаження.
Автонаповнення: що йде з ручної роботи
До автоматизації викладення поставки — це ручний прохід по прайсу: завантажити файл, звірити артикули, проставити ціни, зняти з публікації те, чого немає на складі. На каталозі в кілька тисяч позицій цикл займає дні, і весь цей час сайт показує вчорашні залишки.
Автонаповнення каталогу розбирає фід, зіставляє рядки за артикулом і кодом виробника, застосовує правила за ціною, націнкою та одиницями виміру і публікує пачку цілком — той самий обсяг проходить хвилини замість днів.
Частка ручних правок каталогу скорочується до розбору винятків: рядків без артикулу, конфліктів за назвою, нових категорій. Все інше — округлення цін, приховування нульових залишків, приведення характеристик до єдиного вигляду — роблять правила обміну, а не контент-менеджер. Правки вносяться один раз у шаблон, далі застосовуються до кожного наступного прайсу.
Актуальність залишків перестає залежати від того, хто і коли згадав про оновлення. Обмін іде за розкладом, журнал фіксує кожну зміну ціни та кількості, тому розходження з обліковою системою видно відразу, а не після скарги покупця.
Йде цілий клас відмов: замовлення на відсутній товар, продаж за старою ціною, позиції-двійники з різних прайсів, «завислі» розділи з неповними картками.
Простій викладення закривається окремо: битий фід, зникла колонка або недоступне джерело не валять обмін цілком.
Рядки з помилками йдуть у чергу на розбір, інші позиції публікуються як зазвичай, а попередня версія даних зберігається — обмін завжди можна відкотити і не залишитися з порожнім каталогом.
Способи завантаження: розклад, події, ручний імпорт
Режим завантаження — не деталь реалізації, а те, від чого залежить, як швидко нова ціна постачальника доїде до картки товару. У 1С-Битрикс автонаповнення каталогу будується на кількох базових механіках, і кожна закриває свій клас постачальників. Нижче — за застосовністю та обмеженнями.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Обмін за розкладом | Постачальник віддає вивантаження раз на добу або рідше, обсяг — десятки тисяч позицій | Каталог оновлюється із затримкою до наступного запуску; довгий прогін конкурує за ресурси з сайтом |
| Завантаження за подією | Постачальник надсилає повідомлення про готовність нового вивантаження — листом або зверненням до адреси прийому | Потрібен захист від повторної обробки одного файлу і контроль, що постачальник дійсно надіслав сигнал |
| Ручний імпорт вивантаження | Разові закупівлі, сезонні колекції, постачальник без постійного каналу | Тримає менеджера, розходження в артикулах і залишках накопичуються, історія завантажень губиться |
| Сервіс-посередник обміну | П'ять і більше постачальників, у кожного свій формат і набір полів | Довше налаштування, зате єдиний контур нормалізації, черги та розбору помилок |
На практиці контури комбінують: розклад працює як страховка, подія — для постачальників, що віддають дані часто, ручний імпорт — для разових акцій. Такий набір закриває і свіжість цін, і стійкість до збоїв на стороні постачальника.
Будь-який варіант пише журнал завантажень: скільки позицій додано, змінено, відхилено і чому. Розходження стає видно до того, як його помітить покупець, а відкат до попереднього стану каталогу залишається можливим.
Етапи впровадження обміну з постачальниками
Порядок робіт вибудовуємо так, щоб розходження в даних знаходилися до публікації на живому каталозі, а не після. Спочатку розбираємо, що і в якому вигляді віддають постачальники, потім проектуємо структуру і тільки потім включаємо регулярний обмін.
- Аудит джерел даних. Дивимося, що віддає кожен постачальник: формат вивантаження, періодичність, стабільність колонок, дублі та порожні рядки.
- Проектування структури каталогу. Визначаємо розділи, властивості та торгові пропозиції так, щоб дані постачальників лягали без ручного доопрацювання.
- Зіставлення номенклатури. Будуємо зв'язку за артикулом і штрихкодом, описуємо правила для нових позицій і конфліктів, коли один товар приходить від кількох постачальників.
- Налаштування обміну. Збираємо покроковий імпорт з розкладом, журналом і відкатом невдалого прогону; окремо — оновлення цін і залишків.
- Прогін на тестовій копії сайту. Запускаємо обмін на копії з реальними обсягами: заміряємо час обробки, перевіряємо прив'язку до розділів, властивості та зображення.
- Приймальна перевірка. Проходимо контрольні позиції та сценарії відмови: файл не прийшов, змінилася колонка, обнулився залишок, постачальник надіслав порожню ціну.
- Передача регламенту супроводу. Фіксуємо, як підключити нового постачальника, що робити при зміні формату і як відключити джерело, не ламаючи каталог.
Далі обмін іде за цим регламентом: правки в правилах зіставлення і розкладі вносяться точково, без зупинки процесу. Каталог залишається актуальним сам, а не після ручної вичитки прайсів.
Конфігурації, схеми обміну та регламенти на виході
Автонаповнення — це не разове налаштування імпорту, а інфраструктура всередині проекту на 1С-Битрикс.
Після здачі залишаються налаштування, схеми, правила доступу та документація — за ними каталог розвивається далі, підключаються нові постачальники, а підтримку можна передати іншому інженеру без відновлення логіки по пам'яті.
- Схема обміну — джерела (прайс-листи, вивантаження, обмін через API постачальників), розклад запуску, порядок завантаження та місця зберігання вихідних файлів з архівом для перерозбору.
- Карта зіставлення — відповідність полів постачальника розділам каталогу, властивостям і торговим пропозиціям: вибір розділу, одиниці виміру, артикули, штрихкоди та кратності упаковки.
- Політики доступу — які ролі працюють з обміном, що доступно контент-менеджеру, а що адміністратору; окремо фіксуються права на зміну цін і залишків.
- Інструкція з оновлення каталогу — запуск обміну вручну, перезапуск кроку, що впав, перевірка результату та дії при розходженні залишків з постачальником.
- Правила публікації — що робити з товаром, що зник з прайсу: зняти з публікації, перевести в архів або залишити картку з нульовим залишком.
- Документація обміну — опис форматів, журнали обробки, схема руху даних і типові помилки з готовими рішеннями.
- Регламент контролю — звіти після кожного запуску, зона відповідальності та ознаки, за якими видно, що обмін почав деградувати.
Кейс: 40 000 позицій і три різних постачальника
До: ручна зведення трьох прайсів
Клієнт — дистриб'ютор з каталогом близько 40 000 позицій і трьома постачальниками, кожен з яких віддавав прайс у своєму форматі та зі своєю структурою категорій.
Менеджери зводили вивантаження вручну: повне оновлення асортименту займало 2-3 дні, і на момент публікації частина цін і залишків вже розходилася з реальністю. Частка ручних правок трималася на 25% — майже кожна четверта картка вимагала втручання.
Після: правила зіставлення та розклад
Ми описали правила прив'язки товару — за артикулом, штрихкодом і назвою, з пріоритетом постачальника при конфлікті цін, і винесли позиції, які автоматика не розпізнала, в окрему чергу на розбір.
Оновлення йде за розкладом: ціни та залишки перераховуються вночі, розходження за конкретними позиціями потрапляють у звіт.
На платформі 1С-Битрикс це шар поверх штатного каталогу — ядро та логіка вітрини не переписувалися, відкат до попереднього стану каталогу можливий у будь-який момент.
Повний цикл оновлення скоротився з 2-3 днів до 40 хвилин, частка ручних правок впала з 25% до 3%, навантаження на співробітників — приблизно втричі. Менеджери розбирають тільки винятки та спірні позиції, замість того щоб переносити рядки з чужих таблиць.
Чим обмін з обліковою системою відрізняється від завантаження фідів
Обмін з обліковою системою — це двосторонній протокол: джерело істини за залишками, цінами та замовленнями залишається в складському контурі, а каталог на сайті лише відображає його стан.
Вивантаження йде пакетами у форматі CommerceML — номенклатура, торгові пропозиції, склади, залишки, ціни. Записи зіставляються за зовнішнім ідентифікатором або артикулом, тому перейменування товару на вітрині не розриває зв'язок з обліковою системою. Назад йдуть замовлення та статуси, і менеджер не веде подвійний облік.
Завантаження торгових пропозицій з фідів постачальника влаштована інакше: це односторонній потік, де постачальник віддає прайс у своєму форматі, а ми приводимо його до структури каталогу і розкладаємо за розділами та властивостями.
Залишки тут — знімок на момент вивантаження, а не поточний стан складу; частина позицій приходить тільки з ціною та позначкою «під замовлення». Звідси обов'язкове правило деактивації: якщо позиції більше немає у фіді, вона не повинна мовчки залишатися в продажу.
Вибір способу обміну диктує модель роботи. Коли товар фізично лежить на своєму складі, обмін дає актуальні залишки та коректне резервування. Коли асортимент — довгий хвіст чужих постачальників, фіди закривають його без ручного введення карток.
На практиці частіше працює гібрид: ядро номенклатури синхронізується з обліковим контуром, а додаткові категорії наповнюються завантаженням.
Змішувати обидві схеми в одному розділі каталогу не можна: залишки та ціни починають перетирати одне одного, і вітрина розходиться зі складським обліком.
Тому ми розводимо джерела за розділами та властивостями і задаємо для кожного свій регламент — період обміну, пріоритет за ціною, поведінку при зникненні товару.
Технічні сумніви перед стартом
Обмін з постачальниками рідко йде гладко з першого запуску: у кожного вивантаження своя структура, артикули та логіка упаковки. Нижче — сумніви, які найчастіше спливають до старту, і те, як ми закриваємо їх на рівні правил обміну.
Як обмін уникає дублів, якщо у постачальника змінився артикул?
Зіставлення йде не за одним полем, а за зв'язкою: зовнішній код постачальника, артикул виробника, штрихкод. При зміні артикулу картка не перестворюється — оновлюється прив'язка, а рядок, який дав би другу картку, зупиняється перевіркою.
Що відбувається з позиціями, яких не виявилося у вивантаженні?
За замовчуванням такі товари не видаляються: вони знімаються з публікації або йдуть у статус «немає в наявності» за заданим правилом. Каталог зберігає описи та характеристики, а позицію, що повернулася, достатньо включити назад.
Як враховуються одиниці виміру та упаковка?
У вивантаженнях ціна часто вказана за упаковку, а покупець бачить вартість за одиницю. Задаємо коефіцієнт перерахунку та правила округлення в картці, щоб ціна, залишок і кратність замовлення збігалися між собою.
Сайт зупиняється на час обміну?
Ні. Обмін іде порціями з обмеженням навантаження, зміни публікуються після завершення порції. Переіндексація виконується окремо, тому вітрина залишається доступною і вікна простою не виникає.
Порядок старту і що потрібно з вашого боку
Перші дні йдуть не на код, а на розбір даних: поки не видно реального фіда, будь-яка оцінка автонаповнення каталогу тримається на припущеннях. Тому старт проекту починаємо з джерел і правил зіставлення — так склад робіт фіксується до першого рядка коду, а не уточнюється по ходу.
Що потрібно з вашого боку, щоб повернутися з оцінкою та планом:
- посилання на фіди постачальників і спосіб доступу — вивантаження за посиланням, файл на сервері або обліковий запис для захищеного каталогу;
- формат і періодичність оновлення: CSV, XML або YML, оновлення за розкладом або за запитом;
- приклад файлу цілком, а не фрагмент — на обрізку не видно порожніх полів, дублів і битого кодування;
- доступ до тестової копії сайту, щоб проганяти імпорт без ризику для живого каталогу;
- довідник відповідності: як товар постачальника пов'язаний з розділом, торговою пропозицією та властивостями;
- правила для спірних випадків — що робити з товаром, що зник, зміненою ціною і нульовим залишком;
- контакт з боку постачальника або вашої команди для уточнень за форматом.
Далі збираємо склад робіт: розбір фідів, правила зіставлення, регулярний імпорт з журналом запусків, обробка помилок і повідомлення про збої.
Після узгодження плану розгортаємо контур на тестовій копії, перевіряємо на реальному фіді і тільки потім включаємо оновлення на живому каталозі.
Опишіть задачу і надішліть посилання на вивантаження — повернемося з оцінкою, термінами та планом за етапами.