При настройке ценообразования в программе «1С:Управление торговлей» (редакция 11) пользователи часто сталкиваются со следующей проблемой: при выборе способа расчета цен по запросу из информационной базы по схеме «Максимальные цены поставщиков» система упорно выбирает цену из последнего или предпоследнего документа поступления, полностью игнорируя более высокие цены, которые были зафиксированы ранее.
Например, сценарий выглядит так. Сначала оформляется поступление товара по цене 240 рублей. Затем приходит новая партия по 210 рублей, а следом — еще одна по 215 рублей. Логика пользователя подсказывает, что максимальной ценой в базе является 240 рублей. Однако система при расчете выдает 215 рублей. Давайте подробно разберем, почему так происходит, как устроена встроенная методология «1С» и как перенастроить программу для получения реального исторического максимума цен за период.
Для того чтобы понять логику работы системы, проанализируем структуру хранения данных. Цены поставщиков в системе регистрируются в периодическом регистре сведений ЦеныНоменклатурыПоставщиков. Каждая новая запись в этом регистре «вытесняет» предыдущую для конкретного поставщика и конкретной номенклатуры.
Стандартная схема компоновки данных (СКД) «Максимальные цены поставщиков» обращается к виртуальной таблице регистра ЦеныНоменклатурыПоставщиков.СрезПоследних. Рассмотрим, как это влияет на результат:
СрезПоследних на определенную дату возвращает только одну, самую последнюю (актуальную на этот момент) цену по каждому поставщику.СрезПоследних вернет ровно одну запись — цену из последнего документа (в нашем примере это 215 рублей). Все предыдущие цены (240 и 210 рублей) считаются устаревшими и в выборку просто не попадают.МАКСИМУМ(Цена). Но так как в выборке присутствует только одна строка (215 рублей), функция применяется к единственному числу и возвращает его же.Важный вывод: разработчики фирмы «1С» закладывали в этот алгоритм идею выбора максимальной цены среди всех действующих поставщиков на текущий момент. То есть, если на сегодня у Поставщика №1 актуальная цена составляет 100 рублей, а у Поставщика №2 — 110 рублей, система выберет 110 рублей. Но если поставщик один, система всегда будет возвращать его последнюю действующую цену, так как история изменений цен для алгоритма «Среза последних» остается «за кадром».
Прежде чем приступать к изменению алгоритмов запроса, необходимо убедиться, что сами цены корректно регистрируются в информационной базе. Данные в регистр ЦеныНоменклатурыПоставщиков записываются только при выполнении определенных условий:
Приобретение товаров и услуг или Заказ поставщику) обязательно должен быть установлен флаг «Регистрировать цены поставщика автоматически».Соглашении с поставщиком (на вкладке условий закупок). Тогда при создании документов закупки флаг регистрации цен будет проставляться автоматически.Если для бизнес-процессов вашей компании жизненно необходимо выбирать именно исторический максимум цены поставщика за весь период работы (или за определенный интервал времени), стандартный запрос СКД в виде цен придется отредактировать. Сделать это можно, запустив программу в режиме «Толстого клиента» или воспользовавшись возможностью редактирования схемы компоновки данных произвольного вида цен.
Давайте разберем по шагам, как изменить логику выборки:
Шаг 1. Переход на работу с физической таблицей регистра. Нам необходимо отказаться от использования виртуальной таблицы СрезПоследних и обратиться напрямую к физической таблице регистра сведений РегистрСведений.ЦеныНоменклатурыПоставщиков, в которой хранятся абсолютно все записи об изменениях цен.
Оригинальный фрагмент стандартного запроса, получающий срез последних цен:
ИЗ РегистрСведений.ЦеныНоменклатурыПоставщиков.СрезПоследних(
{(КОНЕЦПЕРИОДА(&ДатаДокумента, ДЕНЬ))},
Партнер.Поставщик ...
) КАК ЦеныНоменклатурыСрезПоследних
Мы заменим его на обращение к физической таблице с установкой условия по периоду:
ИЗ РегистрСведений.ЦеныНоменклатурыПоставщиков КАК ЦеныНоменклатурыФизическаяТаблица
ГДЕ ЦеныНоменклатурыФизическаяТаблица.Период <= КОНЕЦПЕРИОДА(&ДатаДокумента, ДЕНЬ)
При таком подходе в выборку попадут абсолютно все цены, когда-либо зарегистрированные в системе до даты проведения расчета. Функция МАКСИМУМ(Цена) сгруппирует эти записи по номенклатуре (и характеристике) и выберет из них наибольшую цифру за всю историю ведения учета.
Обращение напрямую к физической таблице регистра сведений таит в себе скрытую опасность. На крупных базах с большим объемом документооборота и десятками тысяч позиций номенклатуры такой запрос со временем начнет выполняться крайне медленно, что приведет к зависанию системы при расчете цен. Цены пятилетней давности обычно не имеют практического значения для текущего ценообразования.
Разумным и профессиональным решением будет добавление дополнительного параметра — Глубины анализа данных (например, в месяцах или днях). Мы ограничим выборку исторического максимума разумным периодом.
Модифицируем условие в запросе СКД, используя функцию добавления к дате:
ГДЕ ЦеныНоменклатурыФизическаяТаблица.Период МЕЖДУ
ДОБАВИТЬКДАТЕ(&ДатаДокумента, "МЕСЯЦ", -&ГлубинаАнализа)
И КОНЕЦПЕРИОДА(&ДатаДокумента, ДЕНЬ)
В данном случае в СКД добавляется параметр &ГлубинаАнализа (целое число, например, 3, 6 или 12 месяцев). Система будет искать максимальное значение цены поставщика только в пределах этого временного интервала, что гарантирует высокую скорость проведения расчетов и актуальность получаемых данных.
Если вы планируете переход или уже работаете в обновленных версиях конфигураций (начиная с УТ 11.5, КА 2.5 и ERP 2.5), обратите внимание на архитектурные изменения в подсистеме ценообразования:
РегистрСведений.ЦеныНоменклатуры25. Старый регистр ЦеныНоменклатурыПоставщиков в новых версиях может не использоваться. При доработке запросов обязательно проверяйте, какая функциональная опция ценообразования активна в вашей базе.Используя описанные методики, вы сможете гибко настроить расчет цен под реальные требования вашего бизнеса, избежав при этом проблем с производительностью информационной базы.