Почему не срабатывает вид минимально допустимых цен продаж в 1С:ERP 2.5 и как это исправить

Механизм контроля минимальных цен в 1С:ERP Управление предприятием 2.5 (а также в 1С:УТ 11 и 1С:КА 2) является критически важным для соблюдения маржинальности продаж. Однако часто возникают ситуации, когда, несмотря на все настройки, система позволяет менеджеру провести Заказ клиенту с ценой ниже допустимого порога. В этой статье мы подробно разберем, как работает этот механизм, проанализируем причины его "молчания" и научимся правильно настраивать систему контроля. Для анализа и проверки фактических цен продажи с учетом скидок по менеджерам и документам пригодится отчет для анализа изменений цен продажи.

Разберем логику работы минимальных цен

Для начала проанализируем, как 1С:ERP понимает, что цена в документе является недопустимой. В системе нет единой "глобальной" настройки минимальной цены, которая применяется ко всем продажам без исключения. Вместо этого используется иерархическая связка. Посмотрим на этот процесс по шагам:

1. В справочнике Виды цен создается специальный вид цены (например, "Минимальная цена продажи").
2. Для обычных "продажных" видов цен (например, "Оптовая" или "Розничная") в поле "Минимально допустимая цена продажи" указывается созданный ранее минимальный вид цены.
3. При заполнении документа Заказ клиенту система проверяет цену в строке товара и сравнивает ее со значением, установленным в регистре для того вида цены, который назначен "минимальным" для используемого в документе вида цен.

Если эта цепочка разрывается на любом этапе, контроль не сработает. Рассмотрим подробнее основные причины возникновения проблем.

Причина №1: Роль "Отклонение от условий продаж"

Выясним одну из самых распространенных организационных ошибок. В системе 1С:ERP существует роль Отклонение от условий продаж. Проанализируем её влияние на процесс проведения документа:

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

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

Причина №2: Статус документа и логика согласования

Проанализируем программный код и логику работы общих модулей. В типовых конфигурациях проверка часто завязана на статус документа. Посмотрим на пример кода, который встречается в общем модуле ПродажиСервер в процедуре ПроверитьКорректностьЗаполненияДокументаПродажи:

НужноСогласовать = Не (ВсеСтрокиОтменены ИЛИ ОтклонениеОтУсловийПродаж ИЛИ ДокументПродажи.Согласован ИЛИ СогласованВ1СДокументооборот);

Если НужноСогласовать И (ДокументПродажи.Статус <> Перечисления.СтатусыЗаказовКлиентов.НеСогласован) Тогда
    // Здесь происходит вызов проверки цен
КонецЕсли;

Как мы видим, переменная НужноСогласовать становится Ложь, если у пользователя есть право на отклонение или если документ уже имеет статус Согласован. В этом случае проверка просто игнорируется. Если вы тестируете функционал, всегда создавайте новый документ с чистого листа, так как при изменении прав старые документы могут сохранять статус согласования в скрытых реквизитах.

Причина №3: Отсутствие связки в справочнике видов цен

Рассмотрим детально настройку справочника Виды цен. Довольно часто пользователи полагают, что достаточно установить галочку "При оптовой и розничной продаже" в виде минимальных цен. Однако этого недостаточно.

Разберем алгоритм правильной настройки:

1. Зайдем в настройки вашего основного вида цены, по которому идет продажа.
2. Найдем реквизит "Минимально допустимая цена продажи".
3. Убедимся, что там выбран именно тот вид цены, который вы считаете пороговым.

Если в основном виде цены это поле пустое, система не будет знать, с чем сравнивать цену в заказе, и пропустит любую скидку.

Причина №4: Отсутствие установленных цен

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

В этом случае система видит "пустое" значение (ноль). С точки зрения логики программы любая цена больше нуля является допустимой. Всегда проверяйте наличие актуальных записей в регистре цен на дату документа!

Пример программной доработки для массового контроля

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

// Пример модификации условия в функции ТекстЗапросаРегистрСведенийЦеныНоменклатуры
ТекстЗаменыУсловиеВидЦены1 = 
    "ВидЦены В (
    |    ВЫБРАТЬ
    |        ВидМинимальноДопустимыхЦенПродажСписок.ВидыЦен КАК ВидЦены
    |    ИЗ
    |        РегистрСведений.ВидМинимальноДопустимыхЦенПродажСписок КАК ВидМинимальноДопустимыхЦенПродажСписок)";

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

Итоговый чек-лист для запуска контроля цен

Подведем итог и составим план действий для проверки работоспособности механизма:

1. Проверяем права: У пользователя не должно быть ролей Отклонение от условий продаж и Ценообразование без контроля ограничений.
2. Настраиваем связи: В каждом продажном виде цен указан "Вид минимально допустимых цен".
3. Устанавливаем значения: Проведен документ Установка цен номенклатуры для минимального вида цен.
4. Смотрим соглашения: Если в Соглашении с клиентом жестко зафиксирован вид цены, убеждаемся, что именно для него настроены ограничения.
5. Тестируем на новом документе: Создаем новый Заказ клиенту в статусе На согласовании (или Не согласован) и пробуем установить цену ниже минимума.

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