1С-Битрикс і Prom.ua: де рветься обмін замовленнями та залишками
Обмін замовленнями 1С-Битрикс і Prom.ua рідко ламається повністю — частіше він «майже працює»: частина даних доїжджає, частина висить у журналі, а розбіжності накопичуються мовчки.
Через кілька тижнів бухгалтерія бачить замовлення, яких немає на складі, а менеджер майданчика — залишки, яких немає в обліковій системі. Ціна такого «майже» — ручна звірка вечорами, скасування після оплати й покупець, який отримав відмову по товару, що був у наявності.
Перший розрив — замовлення. Якщо вивантаження йде за розкладом, повторний запуск після збою знову надсилає ті самі позиції, і з’являються дублі замовлень під час вивантаження.
Лікується це не «повторним надсиланням», а зовнішнім ідентифікатором: кожен запис пов’язується з документом в обліковій системі, і повторний прийом розпізнається як уже оброблений. Тоді збій завдання не перетворюється на два відвантажені комплекти.
Другий розрив — залишки. Розбіжність залишків маркетплейс і склад накопичується, коли у вивантаження не потрапляють резерви, товари «під замовлення» та позиції в складанні.
Майданчик продовжує продавати за останнім зрізом, склад — за фактом, і розрив зростає з кожним відвантаженням. Тут важлива не частота обміну, а правило розрахунку доступної кількості та єдина точка, яка його рахує.
Третій розрив — статуси. Замовлення живе у двох незалежних списках: на майданчику свій набір станів, в обліковій системі свій, і зв’язок між ними тримається на ручних позначках менеджера. Варто пропустити зміну — і оплачене замовлення значиться новим, а відвантажене висить в очікуванні.
Далі розбираємо, як це закривається: де ставити ідемпотентний прийом, як рахувати доступний залишок і як звести статуси до одного джерела правди.
Що дає вибудуваний обмін: ефект у термінах і відмовах
Поки обмін тримається на ручному перенесенні, кожне замовлення і кожна правка залишку — це операція людини, а отже затримка й ризик помилки.
Вибудуваний обмін переводить ці дії в регламент: номенклатура, ціни, залишки та замовлення ходять між обліковою системою і майданчиком Prom.ua без участі оператора. Перевірити ефект можна за чек-листом нижче — кожен пункт вимірюваний.
- Автоматичний обмін залишками. Кількість на вітрині збігається зі складським обліком у межах циклу вивантаження: товар не продається двічі й не висить «у наявності» без запасу.
- Швидкість оновлення статусів замовлення. Зміна стану в обліку доходить до кабінету майданчика за хвилини — покупець бачить рух за замовленням, менеджер працює з актуальною картиною без уточнювальних дзвінків.
- Зменшення ручних операцій. Вивантаження каталогу, перерахунок цін і перенесення замовлень переходять у регламент: там, де було кілька десятків дій на день, залишається контроль винятків.
- Усунення розсинхронізації даних. Одна картка — один артикул: зіставлення за кодом, а не за назвою, знімає дублі та розбіжності залишків між системами.
- Стійкість до обривів. Недоступність майданчика або облікової системи не валить вивантаження: черга добирає пропущені події після відновлення зв’язку.
- Повернення та скасування. Зворотні рухи потрапляють в облік автоматично, залишок повертається на склад без ручної правки.
- Прозорість. Журнал показує, що і коли пішло, де стало і чому — розбір займає хвилини замість годин пошуку.
Якщо пункт не виконується — отже обмін налаштований частково, і саме цю ділянку доопрацьовують першою.
Способи обміну між 1С-Битрикс і Prom.ua: порівняння підходів
«1С-Битрикс» і Prom.ua по-різному зберігають одне й те саме: у майданчика своя структура категорій і обов’язковий набір атрибутів, у сайту — своя модель розділів і властивостей.
Тому обмін будують не «в лоб», а через один із контурів зв’язку, і вибраний контур визначає, як швидко майданчик побачить нову ціну або залишок і що станеться при збої на будь-якій зі сторін.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Прямий обмін через програмний інтерфейс маркетплейсу | Невеликий каталог, важлива постійна актуальність цін і залишків, замовлення потрібно забирати одразу | Залежність від доступності чужого майданчика, ліміти на кількість звернень, помилка видна лише в момент виклику |
| Обмін за розкладом пакетами | Каталог від сотень позицій, залишки змінюються кілька разів на день, припустима затримка | Відставання між вивантаженням і публікацією, при збої завдання мовчки пропускає цикл — потрібен контроль звітів |
| Проміжне сховище даних | Кілька майданчиків або каналів продажів, складні правила націнок і зіставлення категорій | Потребує окремої бази та регламенту звірки, дорожче в супроводі |
| Ручне вивантаження прайсу файлом | Разові акції, пробний запуск на частині асортименту | Людський фактор, розбіжності в залишках, не масштабується |
На практиці найстійкіша комбінація: обмін за розкладом тягне каталог, ціни та залишки, програмний інтерфейс забирає замовлення й статуси, а проміжне сховище згладжує невідповідність структур і зберігає журнал зіставлення товарів.
Контур добираємо під навантаження — обсяг каталогу, частоту зміни цін і те, яка система вважається джерелом істини щодо залишку.
Етапи налаштування обміну: від аудиту даних до передачі регламентів
Обмін між каталогом на 1С-Битрикс і маркетплейсом Prom.ua ламається не в момент налаштування, а на розбіжностях у даних: довідники розсинхронізовані, одиниці виміру не збігаються, залишки виїжджають швидше, ніж майданчик їх приймає.
Тому впровадження інтеграції поетапно йде від аудиту даних до регламенту — інакше після запуску кожного вивантаження доводиться розбирати, чому позиція є в кабінеті, але не продається.
- Обстеження. Фіксуємо, які довідники беруть участь в обміні: номенклатура, категорії, ціни, склади, статуси замовлень. Рахуємо обсяг — скільки позицій іде в Prom.ua, як часто змінюються ціни та залишки.
- Аудит довідників і номенклатури. Шукаємо дублі, позиції без категорії, нульові та від’ємні залишки, розходження одиниць виміру. Без цього зіставлення доведеться переробляти після перших вивантажень.
- Схема зіставлення. Визначаємо, яке поле пов’язує товар в 1С з карткою на майданчику: зовнішній ідентифікатор, артикул або код. Прописуємо правила для нових позицій і для тих, що вже опубліковані.
- Налаштування обміну. Задаємо напрямок потоків (товари, ціни, залишки в один бік, замовлення — у зворотний), розклад вивантажень і пріоритет джерела даних при конфлікті.
- Тестовий прогін. Ганяємо обмін на невеликому зрізі каталогу й розбираємо відповідь майданчика: відмови, биті посилання, позиції без ціни. Правки вносимо в правила, а не в окремі картки.
- Перевірка на бойових обсягах. Вивантажуємо повний каталог, звіряємо контрольні суми за кількістю та цінами, перевіряємо, що замовлення з майданчика коректно потрапляє в облікову систему.
- Передача та регламент супроводу. Віддаємо карту зіставлення, порядок ручного запуску, перелік типових помилок із причиною та дією, а також відповідальних з обох сторін.
Що залишається у замовника: конфігурації, схеми, регламенти
Результат робіт — не факт запущеного обміну, а комплект артефактів, за яким ваша команда далі веде зв’язку з маркетплейсом без нас. Нижче — що саме передається і яке завдання закриває кожен документ.
- Налаштовані профілі обміну: вивантаження каталогу, залишків і цін, прийом замовлень і синхронізація статусів — кожен профіль зі своїм розкладом, фільтром за розділом і правилами зіставлення номенклатури.
- Схема потоків даних: карта «джерело → приймач», перелік передаваних полів, довідники відповідності товарів, складів, одиниць виміру та статусів замовлень.
- Регламент обробки розбіжностей: що робити при відмові вивантаження, конфлікті залишків, дублі замовлення або незнайденій позиції — і який випадок потребує ручного втручання.
- Політики доступу: окремі облікові записи для обміну, мінімально необхідні права, порядок ротації ключів і журнал змін налаштувань.
- Інструкція для оператора: як перевірити стан обміну, де дивитися журнал, як запустити повторну синхронізацію і до кого ескалювати збій.
- Тестовий контур: копія зв’язки на тестових даних, де правки в правилах зіставлення перевіряються до викочування в робочий контур.
Після запуску ви змінюєте асортимент і підключаєте нові розділи, не замовляючи доопрацювання під кожну зміну. Схема й регламенти описують, як це робити самостійно; ми підключаємося там, де потрібне доопрацювання логіки.
Кейс: обмін замовленнями та залишками для роздрібної мережі
Роздрібна мережа з чотирма складами й кількома тисячами товарних позицій торгувала через Prom.ua, а облік вела в обліковій системі.
Замовлення менеджери забирали з особистого кабінету вручну, залишки вивантажували двічі на добу — при активних продажах наявність розходилася з реальною вже до обіду.
До: ручна обробка та розбіжності
Без участі людини проходило не більше 12% замовлень. Залишок на складі наздоганяв маркетплейс за 3-4 години, а за підсумками місяця близько 7% замовлень сходилися з розбіжностями за складом або кількістю: їх розбирали вручну, звіряючи листування з покупцем і рухи по складу.
Після: обмін без оператора
Зібрали двосторонній обмін: замовлення забираються за подією, залишки перераховуються при кожному русі по складу, а не за розкладом.
Кожна операція отримує ідентифікатор, тому повторне вивантаження не створює дублів, а невдалі виклики йдуть у чергу з повторами та журналом, який видно в адмінці.
Частка замовлень без ручного втручання зросла до 96%, реакція на зміну складу скоротилася до пари хвилин, розбіжності — менше половини відсотка за місяць. Менеджери переключилися на повернення, заміни та нестандартні доставки, а журнал обміну став основним інструментом звірки.
Чим відрізняється обмін за подією від обміну за розкладом?
Різниця в тому, що запускає вивантаження. Обмін за розкладом — завдання планувальника: раз на заданий інтервал воно збирає накопичені зміни й надсилає їх пакетом.
Обмін за подією стартує одразу після правки — змінилася ціна, залишок або статус замовлення, вивантаження пішло, не чекаючи наступного циклу.
Для каталогу в Prom.ua це питання ціни помилки: поки дані чекають свого часу, покупець оформлює замовлення за старою ціною, а менеджер потім розбирає розбіжність вручну. Подієва схема скорочує вікно розбіжності з десятків хвилин до секунд.
| Режим запуску | Коли підходить | Обмеження |
|---|---|---|
| За подією | Ціни, залишки, статуси замовлень — там, де розбіжність одразу б’є по продажу | Масова правка каталогу дає пік коротких звернень до майданчика |
| За розкладом | Довідники, описи, фото, характеристики — змінюються рідко, до затримки некритичні | Вікно розбіжності дорівнює інтервалу між запусками |
| Змішаний | Великий каталог з активними продажами | Потрібна черга й правило, яка сутність іде яким каналом |
Навантаження на сервер при обміні в подієвій схемі вище й нерівномірніше: переоцінка каталогу на десятки тисяч позицій перетворюється на потік одиночних вивантажень.
Тому події ставлять у чергу, склеюють зміни за коротке вікно в один пакет і обмежують число одночасних обробників — пік гаситься, а свіжість даних залишається. Відмова майданчика обробляється повтором, інакше частина змін губиться мовчки.
На практиці беруть змішаний контур: замовлення, ціни та залишки — за подією, описи й медіа — за розкладом у нічне вікно. Частота синхронізації даних і розмір пакета добираються за вимірами, а не за замовчуванням.
Часті технічні сумніви при налаштуванні обміну
Обмін між каталогом 1С-Битрикс і Prom.ua — не разове вмикання, а постійний режим: збій зв’язку, правки каталогу або підключення нового постачальника перевіряють його на міцність. Зібрали те, що найчастіше уточнюють до старту.
Що буде, якщо вивантаження обірветься на середині?
Обмін іде порціями, і результат кожної фіксується в журналі. Повторний запуск після обриву продовжується з останньої підтвердженої позиції, а не з початку: прийняті картки та замовлення не дублюються, а в журналі видно, на якому кроці зник зв’язок.
Як виключити задвоєння замовлень?
Замовлення зіставляється за зовнішнім ідентифікатором: повторно надісланий запис оновлює статус, а не створює другий. Якщо замовлення змінили і на майданчику, і в обліковій системі, спір вирішується за часом останньої зміни, а розбіжність потрапляє у звіт.
Чому номенклатура вивантажилася частково?
Причина майже завжди в даних: товар без прив’язки до категорії майданчика, порожні обов’язкові атрибути, дублі артикулів, нульовий залишок або відсутня ціна. По кожній відсіяній позиції у звіті вказано причину, і після правки її довантажують окремим запуском.
Чи простоюватиме магазин під час налаштування?
Ні. Первинна синхронізація та налагодження йдуть на копії каталогу, а бойовий обмін вмикається в узгоджене вікно. Якщо щось піде не так, повернення до попереднього режиму — одна операція, вітрина продовжує приймати замовлення.