Налаштування оптових цін за обсягом замовлення 1С-Бітрікс

Чому оптові ціни в Битрикс не спрацьовують у кошику

Великий покупець збирає кошик на десятки позицій, а під час оформлення бачить роздрібну вартість.

Правила за обсягом замовлення в системі заведені, але розрахунок у кошику їх не підхоплює: умова прив'язана до картки товару або до групи покупця, а вартість перераховується за базовою ціною в момент додавання й більше не оновлюється, коли кількість змінюється.

Друга типова поломка — порядок застосування умов. Оптові ціни в Битрикс часто зібрані з кількох незалежних механізмів: знижка за обсяг, знижка на категорію, персональна угода з клієнтом.

Вони не узгоджені між собою, тому перемагає те правило, яке застосувалося останнім, а не те, яке вигідніше покупцеві. Варто прибрати позицію або опуститися нижче порогу — ціна не повертається до початкової, і підсумок у рахунку розходиться з тим, що клієнт бачив у кошику.

Ціна такої помилки — ручний перерахунок замовлень. Менеджер відкриває кожне велике оформлення, звіряє обсяг із прайсом, править рядки вручну: на потоці це десятки операцій за зміну, затримка рахунку й розбіжності між кошиком, документом і відвантаженням.

Окремо заважає кешування каталогу — оновлений прайс не доїжджає до вітрини, поки не скинуто кеш, і покупець продовжує бачити стару ціну.

Причини зазвичай одні й ті самі: не описана матриця порогів, умови навішані поверх стандартного розрахунку, немає набору перевірних сценаріїв на перерахунок у разі зміни складу замовлення. Далі розбираємо, як це закривається — від постановки правил до перевірки на реальних замовленнях.

Що дає автоматичний розрахунок за обсягом замовлення

Оптові умови перестають бути домовленістю в листуванні й стають частиною каталогу: у Битрикс тип ціни прив'язується до групи покупців, а поріг спрацьовує за сумою замовлення або за кількістю позицій у кошику. Перевірка відбувається в момент додавання товару, а не в момент узгодження з менеджером.

Перерахунок виконується на боці каталогу, тому підсумкова ціна й знижка видні покупцеві ще в кошику — до надсилання заявки.

Це й є автоматичний розрахунок за обсягом: знижка зростає ступенями, і клієнт на кожній наступній позиції бачить, скільки додати, щоб потрапити до наступного порогу.

Далі замовлення йде в облікову систему вже із застосованим типом ціни, тому рахунок, відвантаження й документ збігаються за сумами та позиціями.

Ручне виправлення рахунку після оформлення — найчастіше джерело розбіжностей між тим, що пообіцяли клієнтові, і тим, що потрапило до накладної.

Ефект видно в цифрах: швидкість оформлення замовлення зростає, бо зникає листування з перерахунком; частка замовлень, які менеджер править вручну, падає до поодиноких випадків; помилки у відвантаженнях, пов'язані з неузгодженою ціною, зникають як клас. Умови для груп покупців — опт, дилер, роздріб — задаються окремо й не перетинаються між собою.

Способи задати умови за обсягом: порівняння підходів

Умову за обсягом можна задати кількома механізмами, і вони не взаємозамінні: кожен тримає свою зону відповідальності — від кошика до облікової системи.

Різниця проявляється в тому, де зберігається правило, на якому кроці воно спрацьовує і що ламається під час зростання асортименту та кількості договорів.

Межа між підходами проходить по моменту, коли обсяг стає відомий. Правила кошика рахують за фактом замовлення, групи та прайс-листи задають умову заздалегідь, облікова система виводить його з накопиченої історії.

Поєднувати схеми можна, але в кожного правила має бути один власник — інакше в разі повернення або часткового скасування позиції ціна перерахується двічі, і покупець побачить розбіжність між сайтом і рахунком.

Етапи налаштування: від аудиту каталогу до передачі

Правила оптових цін ламаються не в момент налаштування, а на етапі рішення: якщо пороги та пріоритети не зафіксовані до початку робіт, менеджери отримують розбіжності з розрахунком у 1С, а покупці — різні ціни на однакові кошики.

Тому роботу ведемо за регламентом: спочатку розбираємо структуру каталогу й типи покупців, лише потім вмикаємо розрахунок.

1. Аудит каталогу й типів покупців: дивимося розділи, торгові пропозиції та властивості, за якими визначається обсяг, звіряємо типи цін на сайті з базою 1С, знаходимо позиції без прив'язки до ціни — вони першими дають збої.
2. Схема правил розрахунку на погодження: фіксуємо пороги за кількістю та сумою, пріоритет правил при перетині, поведінку на межі порогу та спосіб округлення — до того, як щось увімкнено на живому каталозі.
3. Налаштування рівнів цін і прив'язок правил до розділів і груп покупців: одна лінійка не повинна перекривати іншу, для кожної групи явно визначено джерело ціни.
4. Прогін на тестовому контурі: копія каталогу й обміну, сценарії на одну одиницю, рівно на поріг, на поріг плюс одиниця і на змішаний кошик, звірка результату з розрахунком менеджера.
5. Перенесення налаштувань на робочий контур: у вікно низького навантаження, з вибірковою звіркою цін за групами та контрольним списком позицій, де раніше були розбіжності.
6. Навчання й передача: регламент правки порогів, щоб менеджер змінював умови без розробника, опис логіки та журнал змін.

Кожен етап закривається перевіркою, тому розбіжності ловляться до ввімкнення правил, а не після скарг покупців.

Що входить до комплекту передачі: правила й регламенти

Правила оптових цін працюють рівно доти, доки їх можна передати іншій людині. Тому впровадження закінчується не ввімкненим налаштуванням, а комплектом документації: за ним менеджер, контент-редактор і адміністратор майданчика далі діють без нас.

• Налаштовані правила розрахунку: пороги за кількістю, крок знижки, пріоритет правил при перетині умов і поведінку кошика на граничних значеннях.
• Профілі покупців і прив'язка груп до типів цін — яка категорія клієнтів бачить яку ціну в каталозі, у картці товару та під час оформлення замовлення.
• Схема розрахунку з прикладами на реальних кошиках: від спрацьованого порогу до підсумкової суми в замовленні, включно з округленням і поєднанням знижок.
• Інструкція для менеджера: як видати індивідуальні умови поза загальною сіткою, як перевірити застосоване правило в замовленні та що робити в разі конфлікту умов.
• Регламент змін: хто погоджує новий поріг, як правка проходить перевірку на тестовому контурі та в який момент потрапляє в робочу систему.
• Порядок ведення довідників: як додавати нові групи товарів, що оновлювати під час перегляду цін постачальника та як позначати правила, строк дії яких минув.
• Журнал версій правил із датою та відповідальним — щоб повернути попередні умови, якщо нова сітка дала несподіваний результат.

Такий комплект прибирає головний ризик: знання про те, як рахується оптова ціна, перестає жити в листуванні та в голові одного адміністратора, а зміна порогу перетворюється на регламентну операцію.

Кейс: як прибрали ручний перерахунок великих замовлень

Оптовий постачальник із кількома складами приймав замовлення через особистий кабінет на 1С-Битрикс, але знижка за обсягом жила не в системі, а в голові менеджера: суму угоди рахували вручну й вписували в рахунок.

Кожне п'яте велике замовлення йшло клієнтові з перерахунком — пауза від кількох годин до доби, якщо менеджер був на іншому дзвінку.

Що змінили

Налаштували рівні оптових цін, прив'язані до обсягу замовлення в кошику: поріг за сумою позицій, поріг за кількістю одиниць однієї номенклатури та окремі умови для груп товарів.

Правила рахуються на боці сервера в момент оформлення — ціна перераховується в кошику й фіксується в замовленні, а ручне виправлення суми потребує окремого права доступу.

Результат

Метрики тримаються не за рахунок посилення контролю, а тому що розрахунок став єдиним джерелом ціни: рахунок, відвантаження й документ в обліковій системі формуються з одного значення.

Це закрило й людський фактор — менеджер більше не може відвантажити за ціною, якої немає в правилах.

Що робити, якщо оптові умови вже налаштовані вручну?

Ручні правила рідко живуть в одному місці: знижка може бути зашита в картці покупця, у групі користувачів, у персональних умовах договору та в доопрацюванні, яке рахує кошик.

Правила нашаровуються одне на одного, порядок їх застосування вже ніхто не пам'ятає, і правка однієї ставки ламає розрахунок у частини оптовиків.

Тому починаємо з інвентаризації налаштувань: вивантажуємо всі джерела, де взагалі задається ціна, — правила розрахунку кошика, прив'язки груп, договірні умови, нештатні доопрацювання в шаблонах, обмін з обліковою системою.

За кожним пунктом фіксуємо умову спрацьовування, власника та пріоритет. Виходить реєстр, за яким видно, які правила дублюють одне одного, а які вже не спрацьовують на жодному замовленні.

Перехід без простою будуємо так: нова схема розрахунку працює паралельно зі старою, а перемикання відбувається лише після звірки.

Прогоняємо обидва розрахунки на реальній історії замовлень і розбираємо кожну розбіжність — ціна в кошику, підсумок у рахунку, значення у відвантаженні. Поки цифри не збігаються в усіх типів покупців, попередній механізм залишається робочим.

Окремо закриваємо зворотну сумісність. Домовленості з конкретними покупцями переносимо як персональні винятки поверх нових правил, щоб клієнт не побачив іншу ціну в наступному відвантаженні. Зовнішній обмін продовжує віддавати ті самі дані в попередньому вигляді.

Саме перемикання ставимо у вікно мінімального навантаження й тримаємо старий контур під рукою для швидкого повернення. Так оптові ціни переїжджають в керовану схему, а поточні відвантаження й домовленості з покупцями залишаються недоторканими.

Технічні питання, які задають найчастіше

Об'ємних і накопичувальних знижок майже ніколи не буває одна: правила ділять за категоріями, сумами та групами покупців. Основні сумніви виникають там, де умови перетинаються або зустрічаються з індивідуальними домовленостями. Розберемо поведінку системи за замовчуванням і те, що налаштовується під ваш процес.

Як рахується округлення підсумку?

Округлення налаштовується окремо для рядка й для підсумку замовлення, а знижка рахується до податку або після — це змінює кінцеву суму.

Порядок фіксується в самому правилі, тому той самий кошик завжди дає однаковий результат, а розбіжність із розрахунком менеджера пояснювана й перевірювана.

Чи сумісно це з договірними умовами?

Індивідуальні угоди мають пріоритет над автоматикою: для контрагента заводиться персональне правило, яке перекриває загальні пороги. Договірні ціни можна обмежити строком або обсягом відвантаження, а після його закінчення система сама повернеться до стандартної сітки.

Чи вплине налаштування на вже оформлені замовлення?

Ціна й знижка фіксуються в момент оформлення, тому зміна правил не перераховує закриті та поточні замовлення. Масовий перерахунок виконується лише окремою операцією — запускаємо її усвідомлено, після погодження списку.

Обговоримо задачу — повернемося з оцінкою та планом

Перша розмова — про дані, а не про презентації. Щоб повернутися з оцінкою робіт і планом впровадження, нам потрібно зрозуміти структуру каталогу: як влаштовані типи цін, чи є вже знижки від кількості, як вивантаження з 1С потрапляє на сайт і що відбувається з ціною в кошику.

За цими ввідними одразу видно, чи потрібне доопрацювання обміну або задача закривається правилами в наявному контурі «Битрикс».

• Вивантаження каталогу: скільки товарів і торгових пропозицій, чи є варіанти за кольором, розміром, фасуванням.
• Поточні типи цін і правила знижок: від обсягу в штуках, від суми замовлення або за категоріями.
• Джерело цін: вивантаження з 1С, ручне заповнення, прайс постачальника — і як часто він оновлюється.
• Приклади реальних замовлень: які обсяги вважаються оптовими й як має змінюватися ціна на кожному кроці.
• Вимоги до відображення: показувати шкалу знижок у картці та кошику, рахувати ціну одразу або після підтвердження менеджером.
• Ролі та доступи: хто затверджує оптові ціни, хто бачить їх до публікації, чи потрібні окремі умови для груп покупців.
• Схема обміну: як часто синхронізуються ціни та залишки, що робити в разі розбіжності й хто відповідає за конфлікт даних.

Якщо чогось зі списку немає під рукою — не страшно, зберемо разом: зазвичай достатньо вивантаження каталогу й короткої розмови з тим, хто веде прайс.

Опишіть задачу, укажіть, де зараз болить — і ми повернемося з оцінкою робіт, порядком впровадження та точками, де потрібна ваша перевірка.