Мультивалютность и цены в валюте на 1С-Битрикс

Как только магазин выходит за пределы одной валюты — продаёт импортный товар, работает с зарубежными поставщиками, показывает цены гостям из других стран или просто закупает в долларах, а продаёт в рублях — начинается интересное. Цена перестаёт быть одним числом. У неё появляется валюта, курс, правило пересчёта, округление, а ещё вопрос «в чём мы, собственно, принимаем деньги». Ошибиться здесь легко, а стоит это доверия покупателя: увидел одну цену в каталоге, другую в корзине, третью в заказе — и ушёл. Эта статья — практическое руководство по мультивалютности в 1С-Битрикс: модуль «Валюты», курсы, хранение и вывод цен в валюте, валюта заказа и оплаты.

Разберём по-инженерному: как устроен модуль валюты в Битриксе, чем базовая валюта отличается от дополнительных, откуда берётся курс валют и зачем к нему наценка, какие есть модели хранения цен, как правильно выводить цену в валюте пользователя, что такое валюта заказа и почему она может не совпадать с валютой показа, и как всё это уживается с обменом цен из 1С. Материал опирается на нашу практику разработки магазинов с оплатой и доставкой и мультирегиональных проектов. Дисклеймер: конкретные ставки, курсы и налоговые нюансы всегда сверяйте с бухгалтером — здесь мы говорим о технической и продуктовой стороне.

Кому и зачем нужна мультивалютность

Мультивалютность — не украшение, а ответ на конкретную бизнес-задачу. Прежде чем настраивать модуль, полезно честно понять, зачем валюта нужна именно вам: от этого зависит модель хранения цен и вся дальнейшая логика.

• Продажа импортного товара. Закупка идёт в валюте поставщика, а розничная цена привязана к курсу. Валюта здесь — способ держать маржу при колебаниях курса.
• Показ цен разным аудиториям. Магазин показывает цену в валюте, привычной покупателю (для гостей из других стран или для B2B-клиентов, мыслящих в долларах), но принимает деньги в рублях.
• Учёт в нескольких валютах. Компания ведёт часть операций в валюте и хочет, чтобы это отражалось в ценах и заказах.
• Прайсы для оптовиков и дилеров. B2B-цены иногда исторически ведутся в валюте контракта, и их нужно корректно показать и пересчитать.

Важно с самого начала разделить два принципиально разных сценария. Первый — «валюта как учётная привязка»: товар мыслится в валюте (курс поставщика), а продаётся в рублях с пересчётом. Второй — «валюта как витрина»: покупатель видит цену в валюте и, возможно, платит в ней. Первый сценарий для российского рынка встречается гораздо чаще, и именно вокруг него строится большинство настроек. Если же вы принимаете деньги строго в рублях, вам, скорее всего, нужна не «полная мультивалютность оплаты», а грамотный пересчёт валютных закупок в рублёвую розницу — и это заметно проще.

Модуль «Валюты»: что он делает

В 1С-Битрикс за валюты отвечает отдельный модуль «Валюты» (Currency). Он не привязан к какому-то одному месту витрины — это общий справочник, которым пользуются каталог, цены, корзина, заказы и отчёты. Понимание, что модуль «Валюты» — это фундамент, а не деталь оформления, экономит массу времени.

Что хранит и умеет модуль:

• Справочник валют. Список валют магазина: код (RUB, USD, EUR и т.д.), название, символ.
• Курсы. Для каждой валюты — её курс относительно базовой, с датой. Курс может меняться во времени, и система хранит историю.
• Правила форматирования. Как показывать сумму: символ валюты, его положение (до или после числа), разделители разрядов, число знаков после запятой.
• Округление. Параметры округления при пересчёте — сколько знаков и по какому правилу.
• Функции пересчёта. Механизм, который переводит сумму из одной валюты в другую по курсу — им пользуются каталог и корзина.

Ключевой момент: модуль «Валюты» описывает валюты и курсы, но сам по себе не решает, в какой валюте задана цена конкретного товара. За это отвечает тип цены (о нём отдельный раздел). То есть валюта живёт на двух уровнях: справочник валют и курсов — в модуле «Валюты», а привязка цены к валюте — в настройках типов цен каталога. Смешивать эти уровни в голове — источник путаницы, поэтому дальше мы аккуратно их разделим.

Базовая валюта и дополнительные

Первое решение при настройке — какая валюта будет базовой (главной). Базовая валюта — это точка отсчёта: её курс всегда равен единице, а курсы всех остальных валют показывают, сколько базовой валюты стоит одна единица дополнительной. Для российского магазина базовой почти всегда делают рубль, потому что в нём ведётся учёт и принимаются деньги.

Дальше добавляются дополнительные валюты — те, в которых нужно задавать цены или показывать их покупателю. Для каждой указывается курс к базовой. Например, если базовая валюта — рубль, а доллар стоит условные 90 рублей, то курс доллара — это и есть «сколько рублей в одном долларе». Именно через базовую валюту система переводит любую сумму из одной валюты в другую: сначала в базовую, потом в целевую.

Из устройства «через базовую» вытекает практический вывод: базовую валюту выбирают один раз и надолго. Смена базовой валюты — это смена точки отсчёта для всех курсов и хранимых пересчётов, операция тяжёлая и рискованная. Поэтому базовой делают ту валюту, в которой вы точно будете вести учёт и принимать деньги в обозримом будущем, даже если сегодня половина товара закупается в долларах.

Курсы валют: ручные, ЦБ, наценка

Курс — сердце мультивалютности. Именно от него зависит, во сколько превратится валютная цена при показе и оплате. В 1С-Битрикс курс валюты можно вести тремя принципиально разными способами, и выбор здесь — это баланс контроля и удобства.

• Ручной курс. Вы сами вбиваете курс каждой валюты и меняете его, когда нужно. Максимальный контроль, но требует дисциплины: забыли обновить — продаёте по устаревшему курсу.
• Автозагрузка с внешнего источника. Система периодически забирает официальные курсы (типично — с сайта ЦБ) и обновляет их сама. Удобно и надёжно, но курс ЦБ — это не тот курс, по которому вам продавать.
• Курс с наценкой к источнику. Берётся внешний курс и к нему добавляется ваша наценка (процент или фиксированная величина). Это «золотая середина»: автоматизм плюс защита маржи.

Почему нельзя просто продавать по курсу ЦБ? Потому что официальный курс — это ориентир, а не цена, по которой бизнес покупает валюту. Реальная закупка валюты почти всегда дороже официального курса, плюс есть колебания между обновлениями. Если продавать строго по курсу ЦБ, при каждом скачке вы будете терять на разнице. Поэтому к загруженному курсу добавляют наценку — своего рода запас на волатильность и на разницу между официальным и реальным курсом.

Для большинства магазинов с импортным товаром оптимален третий вариант: автозагрузка курса с наценкой. Он снимает рутину ежедневного обновления и одновременно защищает от торговли себе в убыток. Размер наценки — коммерческое решение, которое стоит согласовать с финансами: слишком маленькая не покроет колебания, слишком большая отпугнёт ценой.

Автозагрузка курса с ЦБ и наценка

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

Что важно продумать при настройке автозагрузки:

• Расписание обновления. Как часто забирать курс — обычно раз в сутки. Слишком частые обновления делают цену дёрганой, слишком редкие — оторванной от реальности.
• Момент применения. В какой момент новый курс начинает действовать на витрине. Тут кроется риск: если курс сменился, пока товар лежит в корзине, покупатель увидит другую сумму (об этом — в разделе про плавающий курс).
• Наценка на волатильность. Насколько курс продажи выше загруженного. Это ваш буфер на колебания между обновлениями.
• Поведение при сбое загрузки. Что делать, если источник недоступен: использовать последний известный курс — да; обнулить — категорически нет.

Две модели хранения цен

Это, пожалуй, главное архитектурное решение мультивалютности. Есть два принципиально разных подхода к тому, как хранить цену товара, если валют несколько. Выбор модели определяет всё дальнейшее: удобство поддержки, поведение цены при смене курса, красоту чисел на витрине.

Модель А: одна цена + пересчёт по курсу

Цена товара задаётся один раз в одной валюте (обычно базовой). В остальных валютах она не хранится, а вычисляется «на лету» по текущему курсу. Условно: у товара есть цена в рублях, а долларовая и евровая цены считаются делением на курс в момент показа.

Модель Б: своя цена в каждой валюте

Для товара заводится отдельная цена в каждой валюте — они хранятся независимо. Долларовая цена не считается из рублёвой, а задаётся вручную (или приходит из учётной системы). Курс при показе уже не участвует: что задано, то и показывается.

На практике часто применяют гибрид: базовую цену ведут в одной валюте и пересчитывают по курсу для учётных задач, а для витринной валюты, где важен маркетинг и ровные ценники, задают отдельную цену. Главное — сознательно выбрать модель под задачу, а не получить её случайно. Если вы торгуете импортом и хотите, чтобы цена автоматически шла за курсом, — это модель А. Если для вас важнее ровные ценники и полный контроль — модель Б.

Тип цены и его валюта

В каталоге 1С-Битрикс цена товара — это не просто число, а связка «тип цены + значение + валюта». Типы цен (например, «Розничная», «Оптовая», «Дилерская») задаются в настройках каталога, и у каждого типа своя роль. Важнейшая деталь для мультивалютности: у каждой цены есть валюта, и именно она определяет, в чём выражено число.

Из этого следует несколько практичных вещей:

• Валюта привязана к цене, а не к товару. У одного товара розничная цена может быть в рублях, а специальная — в другой валюте, если так задумано.
• Разные типы цен — разные валюты. Оптовую цену можно вести в валюте контракта, а розничную — в рублях; это законно и распространено.
• Показ зависит от типа и валюты. Витрина показывает цену выбранного типа в её валюте (или пересчитанной, если так настроено).
• Права на типы цен. Кто какие типы цен видит — настраивается по группам пользователей, что удобно для B2B.

Тема типов цен тесно связана с ценообразованием для разных групп покупателей: розница, опт, дилеры. Как выстроить эту систему целиком — от групп клиентов до персональных прайсов — мы подробно разбираем в материалах про B2B-ценообразование; здесь же важно зафиксировать: валюта цены задаётся на уровне типа цены и должна существовать в модуле «Валюты». Если тип цены ссылается на валюту, которой нет в справочнике, цена просто не покажется корректно.

Округление и форматирование

Как только появляется пересчёт по курсу, немедленно появляется и проблема хвостов после запятой. Разделили рублёвую цену на курс — получили число вроде 34,7183. Показывать его так нельзя, надо округлить. И тут важно, чтобы округление было единым и предсказуемым по всему магазину.

В модуле «Валюты» для каждой валюты настраиваются:

• Число знаков после запятой. Сколько десятичных разрядов показывать: для рубля обычно два (копейки), для некоторых валют может быть иначе.
• Правило округления. Как обходиться с хвостом при пересчёте — округлять до заданного числа знаков.
• Символ валюты и его позиция. Например, «1 000 ₽» (символ после числа) или «$1,000» (символ до числа).
• Разделители. Чем отделять разряды и дробную часть — пробел, запятая, точка.

Главное правило: округление задаётся один раз на уровне валюты и соблюдается на всех этапах — вывод в каталоге, корзина, оформленный заказ, чек. Если на витрине одно число знаков, а в заказе другое, суммы перестают сходиться, и появляются те самые «копеечные» расхождения, из-за которых бухгалтерия задаёт неудобные вопросы. Про эту проблему подробнее — в отдельном разделе.

Вывод цены в валюте пользователя

Настроили валюты, курсы и хранение — теперь надо показать цену покупателю в удобной ему валюте. Здесь важно понимать, что «валюта пользователя» может определяться по-разному, и логика должна быть явной, а не случайной.

Откуда берётся валюта показа:

1. По региону/языку. Если магазин мультирегиональный или мультиязычный, валюта может зависеть от региона или языковой версии: русская версия — рубли, международная — доллары.
2. По выбору пользователя. В шапке стоит переключатель валюты; выбор запоминается и имеет приоритет над автоматикой.
3. По умолчанию. Если ничего не выбрано, показывается валюта по умолчанию — как правило, базовая.

Технически вывод цены в нужной валюте — это либо показ хранимой цены в этой валюте (модель Б), либо пересчёт базовой цены по курсу (модель А) с форматированием по правилам валюты. В шаблоне вывода важно не считать курс «руками» в разных местах, а пользоваться штатными функциями пересчёта и форматирования модуля «Валюты» — тогда округление и оформление будут едиными. Разнобой возникает именно там, где кто-то однажды написал свой пересчёт в обход модуля.

Валюта показа против валюты оплаты

Это раздел, который спасает от самых болезненных недоразумений. В мультивалютном магазине есть три разные сущности, и путать их нельзя.

• Валюта показа (витрины). В чём покупатель видит цену в каталоге и карточке товара.
• Валюта заказа. В чём сумма зафиксирована в оформленном заказе.
• Валюта оплаты. В чём деньги реально уходят платёжному провайдеру.

Для абсолютного большинства российских магазинов реальная схема такая: показывать можно в любой валюте для удобства, но заказ фиксируется и деньги принимаются в рублях, потому что российские платёжные системы работают с рублём. Значит, если валюта показа отличается от рубля, в момент оформления сумма пересчитывается в рубли по курсу — и именно рублёвая сумма уходит в оплату и в чек. Это ключевая развилка: витрина может быть мультивалютной, а касса — рублёвой, и в этом нет противоречия, если пересчёт сделан честно и предсказуемо. Как подключается сама рублёвая оплата — в отдельной статье про подключение ЮKassa, СБП и Т-Кассы.

Пересчёт при оплате

Раз деньги принимаются в рублях, а показывать цену могли в другой валюте, то в цепочке «показ → заказ → оплата» обязательно есть точка пересчёта. И самый важный вопрос — по какому курсу и в какой момент этот пересчёт происходит. От ответа зависит, совпадёт ли сумма, которую покупатель видел, с суммой, которую он заплатит.

Правильная логика:

1. Покупатель формирует корзину — видит цены в валюте показа (или уже в рублях).
2. Оформляет заказ — в этот момент система фиксирует курс и итоговую рублёвую сумму заказа.
3. Заказ уходит в оплату — платёжному провайдеру передаётся зафиксированная рублёвая сумма.
4. Оплата и чек — деньги и кассовый чек идут в рублях по этой зафиксированной сумме.

Критично, чтобы курс фиксировался в момент оформления, а не пересчитывался заново на шаге оплаты. Иначе получается разрыв: заказ оформлен на одну рублёвую сумму, а к оплате провайдеру ушла другая, потому что за это время обновился курс. Это прямой путь к недовольству покупателя и к расхождениям в учёте. Зафиксированная в заказе сумма — это «договор» с покупателем на конкретную цифру, и менять её задним числом из-за курса нельзя.

Валюта заказа и её фиксация

Заказ в 1С-Битрикс — это не только список товаров, но и зафиксированные суммы. У заказа есть своя валюта, и суммы позиций, доставки и итога хранятся в ней. Для мультивалютного магазина здесь важны два момента.

Во-первых, валюта заказа обычно совпадает с валютой оплаты. Если деньги принимаются в рублях, заказ логично вести в рублях: тогда сумма заказа, сумма к оплате и сумма чека — это одна и та же цифра, и ничего дополнительно пересчитывать не нужно. Это самая устойчивая конфигурация для российского рынка.

Во-вторых, суммы в заказе — снимок на момент оформления. Даже если завтра курс изменится и валютная цена товара «уедет», в уже созданном заказе останется та сумма, которая была зафиксирована. Это правильно: заказ отражает договорённость, а не текущий рыночный курс. Поэтому при разборе жалоб «а на сайте было дешевле» смотрят на дату заказа и курс на тот момент, а не на сегодняшний ценник.

Из этого вытекает и требование к обмену заказами с учётной системой: в 1С заказ должен приходить с корректной валютой и зафиксированными суммами, чтобы бухгалтерия видела ровно то, что заплатил покупатель. Как настроить такой обмен заказами и статусами оплаты, мы подробно разбираем в статье про интеграцию магазина с 1С — валютные заказы там подчиняются тем же принципам, просто с явно указанной валютой.

Язык + валюта + регион

Мультивалютность редко живёт в вакууме. Обычно она соседствует с мультиязычностью и мультирегиональностью, и важно понимать, что это три независимые оси, которые не обязаны совпадать. Их путают, и получают странные конфигурации.

• Язык интерфейса — на каком языке подписи, кнопки, тексты. Это про перевод интерфейса и контента.
• Валюта — в чём показаны цены. Это про модуль «Валюты» и типы цен.
• Регион — какой город/область у покупателя. Это про цены, склады, доставку, контакты.

Эти оси пересекаются, но не жёстко. Русскоязычный покупатель может хотеть видеть цену в долларах; международная версия сайта может показывать цены в рублях для российских клиентов за рубежом; регион влияет на цену и склад, но не обязательно на валюту. Хорошая архитектура разделяет эти настройки, а не сваливает в одну «версию сайта». Тогда добавить, скажем, ещё одну валюту не значит городить новую языковую версию.

Особенно тесно валюта переплетается с регионами: разные города — разные цены и склады, а иногда и разные валюты для B2B-контрактов. Как выстроить региональную структуру целиком — поддомены, определение города, подмену цен и складов — мы разбираем в отдельном материале про мультирегиональность, поддомены и SEO, а под ключ реализуем в рамках разработки мультирегионального сайта. Здесь же зафиксируем принцип: валюта, язык и регион настраиваются отдельно и комбинируются, а не дублируют друг друга.

Импорт валютных цен из 1С

Большинство серьёзных магазинов не вбивают цены руками, а получают их из учётной системы через стандартный обмен между 1С и Битриксом. Для мультивалютности здесь есть своя специфика, которую надо продумать до первой выгрузки.

Как валюта попадает в обмен:

• Валюта у типа цены. В выгрузке у каждого типа цены указана валюта. Розничная может идти в рублях, оптовая — в валюте контракта.
• Соответствие справочников. Валюта из 1С должна существовать в модуле «Валюты» Битрикса с тем же кодом, иначе цена не подхватится корректно.
• Несколько типов цен. Обмен умеет передавать несколько типов цен на товар, каждый со своей валютой — это удобно для розницы и опта одновременно.
• Курсы. Курсы валют можно вести на стороне Битрикса (автозагрузка с наценкой), даже если сами цены приходят из 1С — это часто удобнее.

Самая частая ошибка обмена — рассогласованные справочники. В 1С валюта называется или кодируется одним образом, в Битриксе — другим, и цена приезжает не в ту валюту или не подхватывается вовсе. Поэтому перед первым обменом валют и типов цен сверяют справочники на обеих сторонах: коды валют, названия типов цен, соответствие. Это скучная, но обязательная подготовка — она экономит дни отладки «почему опт приехал в рублях вместо долларов».

Товары под импорт: закупка в валюте

Отдельно стоит разобрать самый частый российский сценарий — товары под импорт. Здесь валюта нужна не для витрины, а для учёта и ценообразования: закупка идёт в долларах или евро, а продажа — в рублях. Логика такая.

1. Закупочная цена в валюте. В учётной системе у товара хранится цена закупки в валюте поставщика — это защищает от того, чтобы «забыть», сколько товар реально стоил.
2. Пересчёт по курсу с наценкой. Розничная цена считается из закупочной по рабочему курсу (с наценкой на волатильность) плюс торговая наценка.
3. Выгрузка розницы в рублях. На витрину и в заказ уходит уже рублёвая розничная цена — покупатель видит и платит рубли.
4. Обновление при движении курса. Когда курс существенно меняется, розничные цены пересчитываются — вручную по регламенту или автоматически, если так настроено.

Ключевое отличие этого сценария от «мультивалютной витрины»: покупатель вообще не видит валюту закупки. Для него магазин полностью рублёвый. Валюта работает «под капотом» — в учёте и в правиле пересчёта. Это заметно упрощает и оплату (она рублёвая), и 54-ФЗ (чек в рублях), и обмен с 1С. Поэтому если ваша задача — именно продавать импорт в рублях, не усложняйте: вам нужна не полноценная мультивалютная касса, а корректная привязка розницы к курсу закупки.

Плавающий курс: цена в корзине и заказе

Теперь — самая коварная проблема мультивалютности, из-за которой чаще всего приходят жалобы. Называется она «плавающий курс», и суть в том, что цена, пересчитанная по курсу, может измениться между моментами, когда покупатель её видел.

Как это происходит при модели «одна цена + пересчёт»:

• Покупатель добавил товар в корзину — увидел одну сумму (пересчёт по текущему курсу).
• Между этим и оформлением прошла ночная автозагрузка курса с ЦБ — курс обновился.
• При оформлении сумма пересчиталась по новому курсу — и покупатель видит другую цифру.
• Результат: «в корзине было одно, в заказе другое» — недоверие и брошенная корзина.

Корень проблемы в том, что цена не хранится, а вычисляется каждый раз заново по актуальному курсу. Решение — зафиксировать курс и сумму в момент оформления заказа и дальше их не пересчитывать. Тогда, что бы ни случилось с курсом после, в заказе останется та сумма, которую покупатель подтвердил. Это ровно тот же принцип фиксации, что мы обсуждали в разделах про оплату и валюту заказа, — здесь он проявляется особенно наглядно.

Дополнительные меры, снижающие остроту проблемы: обновлять курс в спокойное время (ночью), не делать это слишком часто, а для витринной валюты, где важна стабильность ценника, использовать модель «своя цена в каждой валюте» — там курс на витрине вообще не участвует, и цена не «плавает». Выбор зависит от того, что для вас важнее: автоматическое следование за курсом или стабильность увиденной цены.

Округление и «копеечные» расхождения

Второй классический источник боли — округление. Оно кажется мелочью, но именно на нём разваливается сходимость сумм, и бухгалтерия начинает ловить расхождения на копейку-другую. Механизм такой: при пересчёте по курсу получаются длинные дробные числа, их приходится округлять, а если округлять на разных этапах по-разному — итоги перестают биться.

Типичные ловушки:

• Округление на разных уровнях. Округлили цену позиции, потом сумму строки, потом итог заказа — и на каждом шаге потеряли по чуть-чуть.
• Разное число знаков. На витрине два знака после запятой, в расчёте — больше, в чеке — своё. Суммы не совпадают.
• Пересчёт итога vs сумма позиций. Итог, посчитанный из округлённых позиций, может не совпасть с итогом, пересчитанным напрямую.
• Собственный пересчёт в обход модуля. Где-то в шаблоне кто-то посчитал курс «руками» с другим округлением — и появилось расхождение.

Лекарство простое по формулировке и требующее дисциплины на практике: задайте единые правила округления для каждой валюты в модуле «Валюты» и используйте штатные функции пересчёта и форматирования везде — в каталоге, корзине, заказе, чеке. Не пишите собственных пересчётов курса в шаблонах. Тогда все этапы округляют одинаково, и суммы сходятся. Когда расхождение всё же появилось, ищут именно место, где округление отличается от общего правила, — почти всегда это «самодельный» пересчёт в обход модуля валют.

Настройка мультивалютности пошагово

Соберём всё в практический порядок действий. Так выглядит настройка мультивалютности на 1С-Битрикс от нуля до работающей витрины (названия пунктов могут немного отличаться по версиям).

1. Определите базовую валюту. Выберите валюту учёта и оплаты (обычно рубль) и задайте её главной в модуле «Валюты» — её курс равен единице.
2. Добавьте дополнительные валюты. Заведите валюты, в которых будете задавать или показывать цены; укажите код, символ, форматирование и число знаков.
3. Настройте курсы. Выберите способ: ручной, автозагрузка или автозагрузка с наценкой. Для импорта — обычно автозагрузка с наценкой на волатильность.
4. Задайте округление. Для каждой валюты пропишите число знаков после запятой и правило округления — единые для всего магазина.
5. Настройте типы цен и их валюты. Свяжите розницу, опт, дилерские цены с нужными валютами; проверьте, что все валюты есть в справочнике.
6. Выберите модель хранения. Решите: одна цена + пересчёт по курсу или своя цена в каждой валюте (или гибрид) — под свою задачу.
7. Настройте вывод цены. В шаблоне используйте штатные функции пересчёта и форматирования; определите логику выбора валюты показа.
8. Зафиксируйте валюту заказа и оплаты. Убедитесь, что заказ и оплата идут в рублях (для российского магазина) и курс фиксируется при оформлении.
9. Настройте обмен с 1С. Сверьте справочники валют и типов цен на обеих сторонах, прогоните тестовый обмен, проверьте, что цены приехали в нужных валютах.
10. Проверьте цепочку целиком. Каталог → корзина → заказ → оплата → чек: суммы совпадают, округление сходится, курс зафиксирован.

Шаблон вывода цены в валюте

Немного о технической стороне вывода — без кода, но с принципами, которые важно соблюсти в шаблоне. Именно здесь чаще всего появляются расхождения, поэтому правила простые и строгие.

• Пересчёт — только через модуль «Валюты». Не умножайте и не делите на курс «руками» в шаблоне; пользуйтесь штатными функциями пересчёта, чтобы округление было единым.
• Форматирование — тоже штатное. Символ валюты, разделители и число знаков берите из настроек валюты, а не хардкодьте «₽» и запятые в разметке.
• Валюта показа — из явной логики. Определите один раз, откуда берётся валюта (выбор пользователя, регион, умолчание), и используйте её последовательно.
• Кеширование с учётом валюты и курса. Если цены кешируются, ключ кеша должен учитывать валюту показа и актуальность курса, иначе покажется устаревшая цена.
• Экранирование и безопасность. Любые данные, попадающие в разметку, выводятся безопасно; цена — это число, но подписи и символы тоже проходят через штатные средства.

Главная мысль раздела повторяет лейтмотив всей статьи: не изобретайте свой пересчёт курса и своё округление в шаблоне. Модуль «Валюты» уже умеет и переводить суммы, и форматировать их по правилам валюты. Любая «самодеятельность» в шаблоне — это будущее расхождение сумм между витриной и заказом. О том, как в принципе устроены шаблоны и компоненты вывода в Битриксе, можно почитать в наших материалах по разработке, а для валют достаточно правила «всё через модуль».

Частые ошибки

Проблемы мультивалютности повторяются из проекта в проект. Зная их заранее, вы сэкономите дни отладки и нервы покупателей и бухгалтерии.

• Неудачно выбрана базовая валюта. Базовой сделали не ту валюту, в которой ведётся учёт и оплата, а потом пришлось менять точку отсчёта — тяжёлая операция. Выбирайте базовую валюту один раз и осознанно.
• Продажа строго по курсу ЦБ. Загрузили курс без наценки и теряете на каждом колебании. К автозагруженному курсу почти всегда нужна наценка на волатильность.
• Плавающий курс в корзине и заказе. Цена меняется между корзиной и оформлением из-за обновления курса. Фиксируйте курс и сумму в момент оформления заказа.
• Разное округление на этапах. Округляли по-разному в каталоге, корзине и чеке — суммы не бьются на копейки. Единое правило округления через модуль «Валюты».
• Самодельный пересчёт в шаблоне. Кто-то посчитал курс «руками» в обход модуля — появилось расхождение. Только штатные функции пересчёта и форматирования.
• Рассогласованные справочники при обмене с 1С. Валюты и типы цен на двух сторонах не совпали — цены приехали не в ту валюту. Сверяйте справочники до первого обмена.
• Путаница валюты показа и оплаты. Показали в долларах, а покупатель не понял, что заплатит в рублях. Явно предупреждайте о валюте оплаты рядом с ценой.
• Курс без подстраховки при сбое. Автозагрузка не сработала — и цены обнулились или устарели. Держите последний известный курс как запасной.
• Лишняя сложность там, где нужен просто пересчёт. Ради импорта в рублях развернули полноценную мультивалютную кассу. Часто достаточно привязки розницы к курсу закупки.

Чек-лист

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

1. Базовая валюта выбрана осознанно — валюта учёта и оплаты, курс равен единице.
2. Дополнительные валюты заведены с кодами, символами и форматированием.
3. Курсы настроены: способ выбран (ручной / ЦБ / ЦБ + наценка), есть подстраховка при сбое.
4. Наценка к курсу задана и согласована с финансами — не продаёте по чистому курсу ЦБ.
5. Округление единое для каждой валюты и соблюдается на всех этапах.
6. Модель хранения выбрана: одна цена + курс, своя цена в валюте или гибрид — под задачу.
7. Типы цен и их валюты согласованы со справочником валют.
8. Валюта показа определяется по явной логике (выбор / регион / умолчание).
9. Валюта заказа и оплаты зафиксирована (обычно рубли), курс фиксируется при оформлении.
10. Обмен с 1С проверен: справочники валют и типов цен совпадают, цены приезжают верно.
11. Цепочка сумм сходится: каталог → корзина → заказ → оплата → чек без расхождений.
12. Покупатель предупреждён о валюте оплаты, если показ отличается от рубля.

Вывод

Мультивалютность в 1С-Битрикс — это не одна галочка, а связка из модуля «Валюты», курсов, модели хранения цен и правил пересчёта. Фундамент закладывается двумя решениями: правильно выбранной базовой валютой и осознанной моделью хранения — одна цена с пересчётом по курсу или своя цена в каждой валюте. От этих двух выборов зависит вся дальнейшая логика, и переделывать их на живом магазине дорого.

Три вещи спасают от большинства проблем. Первое — наценка к загруженному курсу, чтобы не продавать себе в убыток. Второе — фиксация курса и суммы в момент оформления заказа, чтобы цена в корзине и в заказе не расходилась. Третье — единое округление через модуль «Валюты» без самодельных пересчётов в шаблонах, чтобы суммы всегда сходились до копейки. А для самого частого российского сценария — продажи импорта в рублях — часто и вовсе не нужна полноценная мультивалютная касса: достаточно грамотно привязать розницу к курсу закупки, а деньги принимать в рублях. Как подключить сам приём рублёвой оплаты, мы разбираем в статье про ЮKassa, СБП и Т-Кассу, а другие материалы по теме собраны в рубрике «Оплата и доставка».