При создании прайс-листов или аналитических отчетов в 1С часто возникает задача отобразить разные типы цен (например, «Закупочная», «Оптовая», «Розничная») в отдельных колонках для одной и той же номенклатуры. В системе компоновки данных (СКД) это можно реализовать несколькими способами: от жесткого прописывания в запросе до динамического формирования колонок через настройки структуры. Рассмотрим подробнее каждый из этих подходов, разберем их плюсы и минусы, а также изучим профессиональные приемы оптимизации таких отчетов. Если исходные данные поступают от внешних поставщиков в виде файлов, можно настроить автоматический сбор прайс-листов с почты, FTP или HTTP для их загрузки и обработки.
Этот метод часто выбирают начинающие разработчики. Суть заключается в том, чтобы для каждого вида цены создать отдельную временную таблицу или вложенный запрос, а затем соединить их со справочником номенклатуры. Проанализируем пример кода, который позволяет получить данные для двух видов цен:
ВЫБРАТЬ
ЦеныСрезПоследних.Цена КАК Цена,
ЦеныСрезПоследних.Номенклатура КАК Номенклатура
ПОМЕСТИТЬ Розничные
ИЗ
РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, ВидЦены = &ВидЦеныРозничная) КАК ЦеныСрезПоследних;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
ЦеныСрезПоследних.Номенклатура КАК Номенклатура,
ЦеныСрезПоследних.Цена КАК Цена
ПОМЕСТИТЬ Закупочные
ИЗ
РегистрСведений.ЦеныНоменклатуры.SрезПоследних(&Период, ВидЦены = &ВидЦеныЗакупочная) КАК ЦеныСрезПоследних;
////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
СпрНоменклатура.Ссылка КАК Номенклатура,
Розничные.Цена КАК РозничнаяЦена,
Закупочные.Цена КАК ЗакупочнаяЦена
ИЗ
Справочник.Номенклатура КАК СпрНоменклатура
ЛЕВОЕ СОЕДИНЕНИЕ Розничные КАК Розничные ПО СпрНоменклатура.Ссылка = Розничные.Номенклатура
ЛЕВОЕ СОЕДИНЕНИЕ Закупочные КАК Закупочные ПО СпрНоменклатура.Ссылка = Закупочные.Номенклатура
ГДЕ
НЕ СпрНоменклатура.ЭтоГруппа
Преимущества этого способа: мы получаем четко определенные поля (колонки), с которыми легко работать в настройках СКД как с обычными ресурсами. Мы можем легко вычитать их друг из друга или применять к ним специфическое оформление.
Недостатки: этот подход абсолютно не универсален. Если завтра в компании появится новый вид цены (например, «Дилерская»), вам придется переписывать запрос, добавлять новую временную таблицу и еще одно соединение. Кроме того, большое количество соединений может негативно сказаться на производительности при работе с огромными справочниками номенклатуры.
Более правильным и гибким методом в СКД является использование группировки по полю ВидЦены. В этом случае запрос остается максимально простым, а структура отчета формируется динамически. Разберем этот процесс по шагам.
Во-первых, подготовим запрос к виртуальной таблице СрезПоследних регистра сведений. Нам не нужно фильтровать виды цен в самом тексте запроса:
ВЫБРАТЬ
ЦеныНоменклатуры.Номенклатура КАК Номенклатура,
ЦеныНоменклатуры.ВидЦены КАК ВидЦены,
ЦеныНоменклатуры.Цена КАК Цена
ИЗ
РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&Период, ) КАК ЦеныНоменклатуры
Затем выполним следующие настройки в схеме компоновки данных:
Цена. В качестве выражения обычно используется Сумма(Цена) или Максимум(Цена). Это критически важный шаг: без добавления цены в ресурсы система не сможет сопоставить значение цены с пересечением строки товара и колонки вида цены.Номенклатура.ВидЦены.Цена.Теперь при формировании отчета система сама создаст столько колонок, сколько различных видов цен будет найдено в результате запроса. Если пользователь в настройках (на вкладке Отбор) укажет конкретные виды цен, в отчете отобразятся только они. Чтобы дополнить такой отчет рыночными данными, можно использовать парсинг цен на маркетплейсах и цен конкурентов для получения актуальных значений.
Выясним причину, по которой отчеты "Прайс-лист" часто требуют дополнительных доработок, и разберем способы их реализации. Одной из таких задач является автоматический мониторинг цен конкурентов или дилеров в интернете для регулярного контроля рыночной ситуации.
Работа с характеристиками и единицами измерения. В современных конфигурациях (УТ 11, ERP) цена часто привязана не только к товару, но и к его характеристике. Чтобы избежать дублирования строк или неверного суммирования, обязательно добавляйте поле Характеристика в группировку строк (вместе с номенклатурой или под ней). Также важно выводить поле Упаковка или ЕдиницаИзмерения, чтобы пользователь понимал, за какой объем товара указана цена.
Расчет наценки между колонками. Если вы используете динамические колонки (Способ 2), вычислить разницу между «Розничной» и «Закупочной» ценой через простое вычитание полей нельзя, так как это значения одной и той же колонки ресурса, но в разных группировках. Для таких задач в СКД предусмотрена функция ВычислитьВыражение. Рассмотрим пример выражения для вычисляемого поля, которое поможет найти разницу между двумя типами цен:
ВычислитьВыражение("Сумма(Цена)", "ВидЦены", , "Первая", "Первая") - ВычислитьВыражение("Сумма(Цена)", "ВидЦены", , "Последняя", "Последняя")
Оформление пустых значений. Проанализируем ситуацию, когда для некоторых товаров цена не установлена. В отчете это будет выглядеть как пустая ячейка. Чтобы сделать отчет более профессиональным, воспользуемся Условным оформлением. Настроим правило: если Цена равна 0 или не заполнена, выводить в поле Текст значение "По запросу" или выделять ячейку серым цветом. Для автоматического исключения пустых колонок из отчета пригодится способ скрытия столбцов при отсутствии данных в СКД.
Оптимизация параметров виртуальной таблицы. При работе с регистром ЦеныНоменклатуры крайне важно передавать параметр Период именно в параметры виртуальной таблицы СрезПоследних. Если вы просто наложите отбор по дате на уже выбранные данные, 1С сначала выберет все записи за все время, а потом отфильтрует их, что приведет к огромным задержкам на больших базах. Всегда проверяйте, чтобы в конструкторе запроса на закладке "Параметры виртуальных таблиц" стоял соответствующий параметр.
Таким образом, мы рассмотрели два основных подхода к выводу цен в колонки. Первый способ (через соединения) хорош для жестко заданных структур, а второй (через группировки колонок) — для создания гибких и масштабируемых отчетов, которые не требуют вмешательства программиста при изменении бизнес-процессов компании.