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