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