← На главную

При работе в 1С:Управление производственным предприятием (УПП) версии 8.2 (редакция 1.3) часто возникает необходимость контролировать действия пользователей, в частности, ограничивать максимальный процент ручной скидки, который они могут применять в документах продажи, таких как «Заказ Покупателя» и «Реализация товаров и услуг». Стандартные механизмы, например, установка скидок для номенклатуры или распределение по ценовым группам, зачастую не помогают, поскольку ручной ввод может перекрывать эти настройки. Давайте рассмотрим, как решить эту задачу, используя как доработки конфигурации, так и анализируя возможности типовых решений.

Подход 1: Программная доработка в процедуре "Ценообразование.ПолучитьСуммуДокументаБезСкидки"

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

Разберем процесс по шагам:

1. Активация возможностей автоматических скидок.

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

2. Добавление свойства для хранения ограничения.

   Для того чтобы хранить максимальный процент ручной скидки, который можно устанавливать для каждого пользователя или группы, мы добавим новое свойство в ПланыВидовХарактеристик.НастройкиПользователей. Назовем его, например, ОграничениеРучнойСкидки. Это позволит нам гибко управлять лимитами для разных сотрудников, не изменяя код каждый раз.

3. Внедрение кода в процедуру ценообразования.

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

   Вот пример кода, который необходимо вставить:

   Скопировать код

   
   // { Обработаем ограничение на макс % ручной скидки
   МаксПроцент = УправлениеПользователями.ПолучитьЗначениеПоУмолчанию("ОграничениеРучнойСкидки");
   Если ЗначениеЗаполнено(МаксПроцент) И ТабличнаяЧасть.ВыгрузитьКолонки.Колонки.Найти("ПроцентСкидкиНаценки") <> Неопределено Тогда
       ЕстьНарушение = Ложь;
       Для каждого СтрокаТабличнойЧасти Из ТабличнаяЧасть Цикл
           Если СтрокаТабличнойЧасти.ПроцентСкидкиНаценки > МаксПроцент Тогда
               СтрокаТабличнойЧасти.ПроцентСкидкиНаценки = МаксПроцент;
               ЕстьНарушение = Истина;
           КонецЕсли;
       КонецЦикла;
       Если ЕстьНарушение Тогда
           Сообщить("Максимальный процент Ручной скидки установлен = " + МаксПроцент);
       КонецЕсли;
   КонецЕсли;
   // }
   

   Давайте разберем, что делает этот код:

   • Получение максимального процента: Сначала мы получаем значение максимального процента скидки для текущего пользователя, используя функцию УправлениеПользователями.ПолучитьЗначениеПоУмолчанию("ОграничениеРучнойСкидки"). Если это значение не установлено, то ограничение не применяется.
   • Проверка наличия колонки: Мы проверяем, существует ли колонка ПроцентСкидкиНаценки в табличной части документа. Это обеспечивает универсальность кода для различных документов.
   • Итерация по строкам: Далее мы проходим по каждой строке табличной части документа.
   • Корректировка процента: Для каждой строки мы проверяем, превышает ли введенный пользователем ПроцентСкидкиНаценки установленный МаксПроцент. Если превышает, мы принудительно устанавливаем ПроцентСкидкиНаценки равным МаксПроцент.
   • Информирование пользователя: Если хотя бы в одной строке было обнаружено нарушение и произведена корректировка, мы сообщаем пользователю об этом, указывая установленный максимальный процент.
4. Улучшение: хранение в правах пользователей.

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

5. Важный нюанс: пользователи с полными правами.

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

Подход 2: Прямая доработка в поле ввода "% Ручной скидки"

Существует более простой, но менее гибкий вариант программной доработки, который был предложен в обсуждении. Он заключается во внесении кода непосредственно в процедуру обработки поля ввода процента ручной скидки.

1. Внедрение кода в событие поля ввода.

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

   Пример кода:

   Скопировать код

   
   Если СтрокаТабличнойЧасти.ПроцентРучнойСкидки > 30 Тогда
       СтрокаТабличнойЧасти.ПроцентРучнойСкидки = 0;
   КонецЕсли;
   

   Этот код проверяет, если введенный процент ручной скидки превышает 30%, и в этом случае сбрасывает его до 0. Вы можете настроить логику сброса на желаемое значение, например, до максимального разрешенного (30%).

2. Применение для ролей.

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

Недостатки этого подхода:

• Значение максимальной скидки (в данном примере 30%) жестко закодировано, что требует изменения конфигурации при каждом изменении лимита.
• Этот код нужно вставлять в каждое поле ввода процента ручной скидки в каждом документе, где необходимо ограничение.
• Он может быть обойден, если скидка применяется через другие механизмы, а не прямым вводом в это поле.

Подход 3: Попытка использования типового механизма "Не отпускать товар с ценой ниже определенного типа"

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

1. Описание идеи.

   Суть идеи заключалась в следующем: создать специальный тип цен, который бы отражал минимально допустимую цену товара после применения максимальной скидки (например, розничная цена минус 30%). Затем в правах пользователя установить настройку "Не отпускать товар с ценой ниже определенного типа", привязав ее к этому новому типу цен.

   Шаги для реализации:

   1. Создание нового типа цен: Необходимо было бы создать новый тип цен, например, «Продажные цены-Макс%(30)скидки». Логика расчета этого типа цен должна была бы быть: Розничная цена * (1 - 0.30) или Розничная цена - 30%.
   2. Настройка дополнительных прав: В настройках дополнительных прав пользователя (или группы пользователей) мы бы выбрали опцию "Не отпускать товар с ценой ниже определённого типа" и указали наш новый тип цен «Продажные цены-Макс%(30)скидки».
2. Почему этот вариант не сработал.

   Пользователь в обсуждении сообщил, что этот подход у него не сработал. Мы выясним причину. Механизм "Не отпускать товар с ценой ниже определенного типа" в 1С:УПП 8.2 предназначен для контроля итоговой цены продажи, а не для прямого ограничения процента ручной скидки. Он срабатывает на этапе проведения документа или при фиксации цены, проверяя, не опустилась ли конечная цена ниже заданного порога. Однако, он не предотвращает сам ввод большого процента скидки в соответствующее поле. Пользователь все равно может ввести 50% скидки, и лишь потом при попытке сохранить или провести документ система выдаст ошибку, что цена ниже разрешенной. Кроме того, взаимодействие этой функциональности с автоматическими и ручными скидками может быть нетривиальным и требовать специфических настроек, которые не всегда очевидны или доступны в старых версиях конфигурации. Таким образом, этот метод не является прямым решением для ограничения именно процента, а служит скорее инструментом контроля минимальной прибыльности.

Подход 4: Программное восстановление цены после расчета скидок

Еще один вариант, упомянутый в дискуссии, представляет собой вариацию программной доработки:

• Общая идея: После того как система произведет все расчеты скидок и наценок, включая ручные, мы должны пройтись по товарам в табличной части документа. Если итоговая цена на какой-либо товар опустилась ниже заданного минимального уровня (или если процент скидки превысил максимум), мы программно восстанавливаем цену до допустимого значения. Этот подход похож на первый, но акцентирует внимание на моменте проверки – уже после всех вычислений.

Сохранение функциональности при обновлениях конфигурации

Когда мы вносим изменения непосредственно в конфигурацию, возникает закономерный вопрос: что будет при очередном обновлении? Давайте проанализируем ситуацию:

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

Современные типовые механизмы ограничения скидок в 1С (на основе дополнительных источников)

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

1. Настройка ограничений по пользователям/группам пользователей.

   В современных системах можно напрямую задать максимальный процент ручной скидки для конкретного пользователя или группы пользователей. Это позволяет гибко управлять полномочиями сотрудников. Например, в профилях групп доступа можно установить флажок "Ограничивать ручные скидки" и указать максимальное значение. Если флажок установлен, а значение обнулено, пользователь вообще не сможет применять ручные скидки. Путь для настройки обычно находится в разделе "НСИ и администрирование" → "Настройки пользователей и прав" → "Пользователи", где в карточке пользователя есть кнопка "Правила продаж" для установки лимитов.

2. Настройка ограничений в соглашениях с клиентами.

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

3. Ограничения по ценовым группам.

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

4. Полное отключение ручных скидок.

   Если ручные скидки не должны использоваться вовсе, предусмотрена возможность их полного отключения в разделе "НСИ и администрирование" → "Настройка НСИ и разделов" → "CRM и маркетинг", что позволяет работать только с автоматическими скидками.

5. Приоритет ограничений.

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

6. Контроль для пользователей с полными правами.

   Как и в УПП 8.2, в современных версиях ограничения ручных скидок обычно не действуют для пользователей с ролями "Полные права" или аналогичными, которые позволяют обходить проверки. Для контроля таких пользователей необходимо либо пересмотреть их профили доступа, либо реализовать дополнительные механизмы аудита.

7. Использование автоматических скидок вместо ручных.

   Современные версии 1С позволяют настроить сложные автоматические скидки, которые срабатывают по заданным условиям (сумма, количество, комплекты, категории, ценовые группы, получатели, расписание) и при этом могут быть "назначаемыми вручную". Это дает менеджерам выбор из предопределенных, контролируемых вариантов скидок, минимизируя потребность в полностью произвольном ручном вводе.

8. Минимизация доработок.

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

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