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