Как реализовать использование разных валют для одного вида цен в 1С:Управление торговлей 11

В типовой конфигурации 1С:Управление торговлей 11 (а также в ERP и Комплексной автоматизации) пользователи часто сталкиваются с ограничением: один Вид цены жестко привязан к одной валюте. Это создает неудобства, когда часть товаров закупается и оценивается в рублях, а часть — в долларах или евро, но при этом в документах продажи хочется использовать единую колонку цен. Рассмотрим подробно, почему так происходит и какие существуют пути решения этой задачи.

Анализ технического ограничения регистра цен

Для начала разберем внутреннюю структуру системы. Все цены в 1С хранятся в регистре сведений ЦеныНоменклатуры. В этом регистре Валюта является ресурсом, а не измерением. Проанализируем, что это означает на практике: для уникальной комбинации «Номенклатура + Вид цены + Характеристика» в одну точку времени может существовать только одна запись. Если мы попытаемся записать для одного и того же товара цену в USD, а следом — в RUB, вторая запись просто затрет первую.

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

Вариант 1. Связанные виды цен и расчет по формулам (Стандартный метод)

Это самый правильный метод с точки зрения архитектуры 1С. Мы не ломаем типовой функционал, а используем механизм компоновки данных. Рассмотрим алгоритм настройки по шагам:

1. Создаем два «технических» вида цен: Базовая (USD) с валютой доллар и Базовая (RUB) с валютой рубль. Способ задания — «Ручное назначение».
2. Создаем основной вид цены, который будет использоваться в продажах, например, Розничная (RUB). Валюта этого вида цены — рубль.
3. В настройках Розничной цены выбираем способ задания «Наценка на другой вид цен» или «Произвольный запрос».
4. Если используем формулы, прописываем логику выбора. Система будет проверять наличие цены в той или иной валюте и конвертировать ее в рубли по актуальному курсу.

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

Вариант 2. Использование произвольного запроса в правилах расчета

Если логика выбора валюты сложнее, чем просто «заполнено/не заполнено», воспользуемся схемой компоновки данных (СКД). Рассмотрим пример логики запроса, который можно внедрить в правило расчета цены:

ВЫБРАТЬ
    Номенклатура,
    ВЫБОР
        КОГДА ЦенаUSD > 0 ТОГДА ЦенаUSD * КурсВалюты
        ИНАЧЕ ЦенаRUB
    КОНЕЦ КАК Цена
ИЗ
    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, )

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

Вариант 3. Группировка видов цен для удобства интерфейса

Чтобы пользователь не путался в десятках видов цен, в последних версиях УТ 11 реализован механизм групп. Мы можем объединить Виды цен по валютам в одну группу. В рабочем месте «Цены номенклатуры (прайс-лист)» это позволит:

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

Вариант 4. Автоматизация через расширение (для продвинутых пользователей)

Если бизнес-процесс требует, чтобы в документе «Установка цен номенклатуры» была именно одна колонка «Цена» и рядом колонка «Валюта» (как это было в старых версиях 7.7), можно прибегнуть к доработке через расширение конфигурации. Разберем принцип работы такой доработки:

1. В расширении добавляем в табличную часть документа УстановкаЦенНоменклатуры реквизит ВалютаСтроки.
2. Перехватываем процедуру проведения документа (ПередЗаписью или ОбработкаПроведения).
3. Программно распределяем строки документа: если в строке указаны USD — записываем данные в один ВидЦены, если RUB — в другой.

Важно: При таком подходе структура регистра ЦеныНоменклатуры остается типовой. Мы меняем только интерфейс ввода данных для пользователя, а в базе данных всё хранится корректно по разным видам цен. Это позволяет безболезненно обновлять конфигурацию в будущем.

Риски и последствия изменения структуры регистра

Рассмотрим, почему крайне не рекомендуется добавлять Валюту в измерения регистра сведений ЦеныНоменклатуры. Если вы решитесь на это, приготовьтесь к следующим проблемам:

• Дублирование строк в подборе: При выборе товара в «Заказе клиента» система увидит две действующие записи (в RUB и USD) и не сможет автоматически определить, какую цену подставить. Это вызовет программную ошибку или заставит пользователя выбирать цену вручную для каждой строки.
• Ошибки в отчетах: Типовые отметы (Прайс-лист, Анализ цен) не рассчитаны на наличие валюты в измерениях. Они начнут «двоить» позиции, выводя товар дважды, что сделает аналитику бесполезной.
• Трудоемкое обновление: Регистра цен — один из самых нагруженных объектов системы. Любое изменение его структуры потребует сложной реструктуризации базы данных при каждом обновлении конфигурации.

Подведем итог: Оптимальным решением для 1С:УТ 11 является создание нескольких базовых видов цен по количеству используемых валют и одного результирующего (продажного) вида цены, который собирает данные по формуле или запросу. Это сохраняет целостность системы и обеспечивает необходимую гибкость в управлении ценообразованием.