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