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