Как реализовать гибкую систему групповых наценок в УТ 11, КА и ERP?

Перенос старой логики наценок из 7.7 в современные системы на платформе 1С 8.3 часто вызывает сложности из-за различий в архитектуре справочников. Рассмотрим, как реализовать механизм, при котором для одного типа цен наценка зависит от специфики товара или сегмента, не раздувая при этом справочник ВидыЦен до сотен элементов.

Использование собственного регистра сведений

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

1. Создаем регистр сведений, например, НаценкиПоСегментам.
2. Добавляем в регистр следующие измерения и ресурсы:
   • ВидЦены (Тип: СправочникСсылка.ВидыЦен)
   • СегментНоменклатуры (Тип: СправочникСсылка.СегментыНоменклатуры)
   • БазовыйТипЦены (Тип: СправочникСсылка.ВидыЦен)
   • ПроцентНаценки (Тип: Число)
3. В процедуре расчета цен в документе УстановкаЦенНоменклатуры используем запрос к этому регистру.

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

Реализация через расширения конфигурации

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

В расширении мы можем модифицировать методы модуля менеджера или формы, отвечающие за расчет цен. Примерная логика обработчика:

// Пример логики получения наценки для товара
Функция ПолучитьПроцентНаценки(Товар, ВидЦены)
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ
        |   Наценки.ПроцентНаценки КАК Процент,
        |   Наценки.БазовыйТипЦены КАК БазовыйТип
        |ИЗ
        |   РегистрСведений.НаценкиПоСегментам КАК Наценки
        |ГДЕ
        |   Наценки.ВидЦены = &ВидЦены
        |   И Наценки.СегментНоменклатуры В (ВЫБРАТЬ Сегмент ИЗ РегистрСведений.НоменклатураСегмента ГДЕ Номенклатура = &Товар)";
    
    Запрос.УстановитьПараметр("Товар", Товар);
    Запрос.УстановитьПараметр("ВидЦены", ВидЦены);
    
    Результат = Запрос.Выполнить();
    // Дальнейшая обработка результата...
КонецФункции

Интеграция с типовыми механизмами

Рассмотрим важный аспект интеграции с типовой логикой:

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

Почему не стоит создавать сотни видов цен?

Разберем риски, которые возникают при создании огромного количества видов цен:

• Перегрузка документов: Документы УстановкаЦенНоменклатуры будут содержать избыточный объем данных, что замедлит проведение.
• Сложность администрирования: Пользователям будет тяжело ориентироваться в прайс-листах, если их количество исчисляется сотнями.
• Производительность запросов: Система будет вынуждена постоянно обращаться к раздутым регистрам цен, что негативно скажется на скорости формирования отчетов.

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

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