Роздільні кошики в Бітрикс: де ламається замовлення на маркетплейсі
Штатний магазин 1С-Бітрікс збирає все в одне замовлення: кошик один, оплата одна, статус один. Поки товари продає один постачальник, схема працює.
На маркетплейсі в кошику опиняються позиції різних продавців — і штатна логіка перетворюється на джерело помилок оформлення замовлення.
Перший розрив — на кроці підтвердження. Замовлення створюється як єдина сутність, хоча позиції різних продавців потребують роздільних умов доставки, строків відвантаження й отримувачів оплати.
Менеджер отримує змішану заявку, продавець не бачить ні своїх позицій, ні суми, яка належить йому за підсумком.
Далі розходяться статуси замовлень. Платформа змінює стан усього замовлення цілком, хоча один продавець уже відвантажив, другий ще збирає, а третій зняв свою позицію.
Часткове відвантаження й часткове повернення не відображаються коректно: покупець бачить неправильний стан, а підтримка звіряє все вручну за вивантаженнями.
Помилки оформлення замовлення спливають пізніше — два рахунки на один кошик, повторне списання під час перезбирання, втрачена позиція після правки складу. Кожну таку ситуацію менеджер розрулює руками, і кожна з'їдає час покупця.
Роздільні кошики в Бітрикс закривають це на рівні архітектури: оформлення замовлення маркетплейсу дробиться за продавцями ще на вході, а не правиться після. Розбираємо, як це влаштовано і на що дивитися під час впровадження.
Що змінюється після впровадження: швидкість збирання і менше відмов
Головний ефект видно на часі збирання замовлення: кошики формуються за продавцями автоматично, і менеджеру більше не потрібно вручну розносити позиції одного замовлення за різними постачальниками.
Комплектація, склад і спосіб доставки підставляються з налаштувань продавця, а не перебиваються руками. На практиці збирання скорочується в рази — те, що займало десять-п'ятнадцять хвилин на замовлення, вкладається в хвилину-дві перевірки.
Зростає частка замовлень без правок. Раніше після оформлення менеджер правил склад, доставку або підсумкові умови — система зводила позиції різних продавців в один розрахунок.
Після розділення кошиків кожна частина рахується за своїми правилами, і ручні правки залишаються лише там, де справді потрібна людина.
Зникає цілий клас відмов під час оформлення — той, що виникав через змішування позицій різних продавців. Покупець бачить окремі кошики з прозорим складом, строком і умовами доставки, тому не покидає замовлення на кроці, де сума або доставка раптом змінювалися.
Загалом це прискорює обробку заявок: менше повернень на доопрацювання, коротший шлях від оформлення до передачі продавцю, рівномірніше навантаження менеджерів.
Метрики, за якими звіряємо результат після впровадження, — час збирання замовлення, частка замовлень без правок, кількість відмов на кроці оформлення і швидкість обробки заявки. Усі вони знімаються з журналів і звітів системи, а не оцінюються на око.
Одне замовлення чи кошик продавця: порівняння підходів
На рівні оформлення замовлення маркетплейс вирішує одне завдання: покупець платить один раз, а продавці отримують лише свої позиції. На 1С-Бітрікс це реалізується трьома способами, і вибір між ними визначає, де рахуються доставка, комісія й повернення.
| Схема | Коли підходить | Обмеження |
|---|---|---|
| Єдиний кошик | каталог одного продавця або спільний склад | доставка й статуси не розділяються: затримка однієї позиції тримає все замовлення |
| Кошик продавця | кожен продавець везе товар сам | покупець оформлює кілька замовлень підряд, зростає частка незавершених оформлень |
| Гібридна схема розділення | змішаний асортимент, частина позицій зі свого складу | потрібен шар, який ділить замовлення за продавцями і зводить статуси назад |
Різниця проявляється не в оформленні, а в бізнес-логіці: у єдиному кошику доставка рахується однією сумою, у кошику продавця — за кожним відправником окремо, а гібрид збирає обидві моделі.
Перемикання між схемами після запуску майже завжди означає перезбирання розрахунку доставки й статусів, тому вибір фіксують до початку робіт.
На практиці орієнтуються на дві ознаки: скільки продавців трапляється в одному замовленні і хто відповідає за доставку. Якщо продавець один або товар їде зі спільного складу, єдиного кошика достатньо.
Щойно покупець регулярно збирає замовлення з позицій різних постачальників, вигідніша гібридна схема — вона зберігає для покупця одне замовлення, а продавцю віддає лише його рядки та його виплати.
Як проходить впровадження: аудит, схема, налаштування, приймання
Роздільні кошики не можна увімкнути одним налаштуванням — схему збирають під конкретну логіку продавців, доставки й повернень.
Тому робота йде етапами: спочатку фіксуємо, як замовлення оформлюється зараз, потім проєктуємо цільову модель і лише після цього торкаємося робочого контуру. Нижче — шість кроків, з яких складається впровадження.
-
Аудит оформлення замовлення. Проходимо шлях покупця від додавання товару до оплати й розбираємо, де кошик змішує позиції різних продавців, як у цей момент рахується доставка і які модулі втручаються в розрахунок. На виході — карта вузьких місць із зазначенням місць, де логіка зав'язана на єдиного постачальника.
-
Проєктування схеми замовлення. Описуємо кошик як набір незалежних частин: у кожної позиції свій продавець, свої умови доставки, свій статус і своя сума. Окремо фіксуємо поведінку за часткової оплати, скасування однієї позиції та повернення.
-
Налаштування правил доставки й оплати. Розводимо розрахунок за продавцями і складами, визначаємо, коли поставки об'єднуються, а коли йдуть окремими відправленнями, і як це відображається в рахунку та повідомленнях.
-
Міграція замовлень. Переносимо історію в нову модель, щоб старі замовлення відкривалися коректно, а статуси й суми збігалися з попередніми. Прогоняємо перенесення на копії та звіряємо вивантаження до і після.
-
Приймання сценаріїв. Погоджуємо чек-лист і перевіряємо на ньому реальні шляхи: замовлення в кількох продавців, скасування однієї частини, повернення, повторна оплата, робота під навантаженням. Замовник проходить сценарії сам і бачить результат.
-
Передача в підтримку. Віддаємо схему даних, опис правил, регламент типових звернень та інструкції для менеджерів — щоб зміни надалі вносилися без розбору логіки заново.
Далі рішення живе як звичайний контур: нові продавці підключаються за описаними правилами, а не переписують оформлення замовлення. Опишіть своє завдання — повернемося з оцінкою та планом робіт.
Конфігурації, схеми даних і регламенти обробки замовлень
Пакет документації збирається по ходу проєкту, а не в кінці: кожна схема описує те, що вже перевірено на стенді. Тому замовник отримує не «як мало бути», а актуальну картину робочого контуру — за нею можна вносити правки своїми силами або віддавати нам окремі доопрацювання.
- Конфігурація модуля оформлення — які кошики закріплені за продавцями, правила консолідації позицій в одне замовлення, обмеження щодо доставки та мінімальної суми на кожну частину.
- Схема даних замовлення — сутності, в яких зберігається розділення за продавцями, зв'язки позицій, платежів і відвантажень, щоб звітність за частинами сходилася з підсумком.
- Шаблони статусів і листів — логіка переходів окремо для кожної частини замовлення та повідомлення покупцю й продавцям на кожному кроці.
- Інструкція для менеджерів — як розібрати замовлення з кількома продавцями, що робити за скасування чи повернення однієї позиції, де дивитися причину розходження.
- Карта інтеграцій — що і в якому напрямку обмінюється даними з обліковою системою, складом, платежами й доставкою, включно з точками відмови обміну.
- Регламенти обробки — розклад обміну, правила повторного надсилання за збою, порядок ручного втручання та межі, за якими підключаємося ми.
- Набір тестових сценаріїв — замовлення з різними комбінаціями продавців, часткові скасування й повернення; на ньому перевіряють кожну правку після релізу.
Документація лежить поруч із кодом у системі контролю версій, а не окремим архівом на диску. Зміна в схемі чи регламенті проходить той самий шлях, що й код: правка, перевірка на стенді, запис у журнал змін.
Кейс маркетплейсу: менше помилок у замовленнях і швидше збирання
До: один кошик на всіх продавців
Клієнт — маркетплейс на 1С-Бітрікс з кількома сотнями продавців у спільному каталозі. Кошик був єдиний: покупець складав товари різних магазинів в одне замовлення, а розкладання позицій за продавцями робив код на етапі збереження.
Приблизно одне замовлення з сорока змішувалося — продавець отримував чужий рядок, а розрахунок доставки будувався за чужим набором. Кожне таке звернення підтримка розбирала вручну: звірити склад, узгодити з двома продавцями, переоформити замовлення й повернути гроші.
Що змінили
Ми розвели кошик, оформлення та замовлення за продавцями: у кожного свій кошик, свій розрахунок доставки, свої статуси. Підсумкова сума й промо рахуються на рівні покупця, щоб знижки та бонуси не розпадалися на частини.
Додали перевірки під час збереження замовлення — розходження складу ловиться до запису в базу, а не після. Окремо описали перенесення кошика під час входу з іншого пристрою та за зміни складу.
Що сталося за метриками
Змішування позицій зникло як клас: після запуску не зафіксовано жодного замовлення з чужим рядком. Збирання замовлення в продавця скоротилося приблизно вдвічі — чужі позиції більше не доводиться відсіювати вручну.
Звернення до підтримки щодо складу замовлення впали майже в п'ять разів, а правки в уже оформлені замовлення стали поодинокими.
Що робити, якщо оформлення замовлення вже налаштовано за старою схемою
Перемикання не роблять одним релізом: оформлення замовлення — точка, де помилка коштує втрачених продажів, тому нова схема вмикається поверх старої й знімається лише після того, як обидва контури відпрацювали паралельно.
У 1С-Бітрікс це вирішується на рівні обробників оформлення та прив'язки кошика до продавця: поки розділення вимкнено, компоненти працюють як раніше.
Далі — поетапне вмикання. Спочатку нова логіка прогоняється на копії: замовлення в кількох продавців, часткове скасування, повернення.
Потім роздільні кошики вмикаються для однієї групи продавців, а решта торгує за попередньою схемою; розширення йде за групами з контролем частки успішних оформлень і звернень до підтримки.
Міграція активних замовлень іде окремим кроком: із замовленням пов'язані платіж, рахунок, резерв товару та повідомлення продавцю, тому масова перезапис неприпустима.
Замовлення в проміжних статусах дограються за старими правилами, а новий контур бере лише ті, що ще не пішли в оплату. Оплачений кошик не розсипається на частини заднім числом.
Зворотна сумісність тримається на читабельності старих записів: звіти, листи та обмін з обліковою системою продовжують бачити звичні поля. Без перевірки цього ламається не оформлення, а вивантаження замовлень і звірка з бухгалтерією.
Основні ризики під час перемикання — розсинхрон статусів, дублі позицій за одночасного створення кошиків і втрата зв'язку замовлення з продавцем.
Їх знімають регламентом: вмикання у вікно низького навантаження, журнал переходів за замовленнями й швидкий відкат прапорця до попередньої поведінки.
Оплата, доставка й статуси замовлень: часті технічні сумніви
Роздільні кошики ламають звичну схему, де замовлення — одна транзакція. Щойно в ньому товари кількох продавців, доставка рахується окремо за кожним, оплата ділиться на частини, а в покупця з'являється кілька статусів замість одного. Нижче — спірні місця, які найчастіше піднімають до старту робіт на Бітрикс.
Як рахується доставка, якщо товари в різних продавців?
Вартість і строк рахуємо за кожним продавцем окремо — від його складу, габаритів відправлення та доступних служб. У кошику показуємо розбивку за відправленнями, щоб покупець розумів, чому підсумок відрізняється від однієї посилки, і не покидав оформлення на цьому кроці.
Чи можна провести оплату однією операцією, а не кількома списаннями?
Так, якщо платіжний сервіс підтримує розщеплення платежу: сума списується один раз і розподіляється між продавцями, комісія майданчика утримується автоматично.
Якщо сервіс такого не вміє — робимо послідовні списання або утримання до підтвердження всіх частин замовлення, щоб майданчик не розраховувався за продавця зі своїх коштів.
Що покупець бачить за статусами, якщо частини замовлення їдуть окремо?
У замовлення залишається загальний статус — оплачено, в дорозі, завершено, — а всередині кожен продавець веде свій: зібрано, передано в доставку, доставлено. Повідомлення йдуть за кожною частиною, тому покупець не отримує «замовлення доставлено», коли приїхала лише половина.
Як частини замовлення потрапляють в облікову систему?
Замовлення вивантажується з розбивкою за продавцями: окремі реалізації, окремі документи з доставки, узгоджені статуси й повернення. Період закривається без ручної звірки, а взаєморозрахунки з кожним продавцем видно порядково.
Якщо вашого сценарію в списку немає — опишіть його, розберемо окремо й повернемося з оцінкою та планом.Обговоримо завдання: повернемося з оцінкою та планом робіт
Щоб обговорити завдання предметно, надішліть поточну схему оформлення замовлення та правила роботи продавців: як зараз збирається кошик, у який момент позиції розділяються за продавцями, які обмеження щодо доставки, самовивозу й оплати діють для кожної сторони. Цього достатньо, щоб оцінити обсяг робіт, а не будувати здогади.
На розбір ви отримаєте:
- розбір поточної схеми замовлення: де кошик спільний, які дані губляться під час розбивки і що заважає рахувати вартість доставки за кожним продавцем;
- карту точок інтеграції — властивості кошика, обробники оформлення, обмін з обліковою системою та статуси замовлень;
- оцінку обсягу робіт за етапами: доопрацювання компонентів, правила розділення позицій, логіка промокодів і знижок на кількох продавців;
- план впровадження з порядком робіт — від прототипу на тестовому стенді до викладки на робочий сайт;
- регламент приймання: набір сценаріїв замовлення, які перевіряємо перед передачею, і порядок відкату до попередньої схеми;
- перелік змін у шаблонах листів, особистому кабінеті та вивантаженнях, щоб бухгалтерія й менеджери бачили роздільні замовлення без ручної правки.
Опишіть завдання у зручній формі — повернемося з оцінкою обсягу та планом впровадження, вкажемо ризики й етапи, на яких знадобиться доступ до адміністративної частини та тестового стенду.
