Статья описывает наиболее частые(на мой взгляд) проблемы, с которыми сталкиваются программисты 1С при разработке отчетов на СКД. Люди с большим опытом работы с этим механизмом, скорее всего, не найдут здесь ничего нового.
Поскольку механизм СКД де-факто является стандартом разработки отчетов, то даже начинающие разработчики имеют с ним дело. Иногда из-за недостатка опыта или по невнимательности допускают ошибки которые приводят к неожиданным результатам.
Оглавление
- Выбранные поля в разных элементах структуры. Автополе и отключенное поле
- Расположение итогов = нет
- Ресурсы рассчитываются только для группировок
- Параметр Период – Стандартный период
- Параметры Период, НачалоПериода, КонецПериода
- Установка параметров выражением НайтиПоКоду(), НайтиПоНаименованию()
- Отборы в наборе данных объект
- Некорректный расчет итогов
Выбранные поля в разных элементах структуры. Автополе и отключенное поле
Нередко возникает ситуация, когда структура отчета имеет множество вложенных элементов (группировок). Это нормально. Бывает такое, что у каждой группировки отдельно указаны свои выбранные поля.
Рис. 1. Индивидуальная настройка полей выбора в каждой группировке
Рис. 2. В группировке отключено использование выбранного поля
В общем, это не плохо, когда вы контролируете какие поля в каждой группировке. Но для того чтобы понять, в какой группировке какие поля выводятся – придется прощёлкать все группировки. Также бывают ситуации, что на уровне отчета выбраны одни поля, а поскольку в выбранных полях группировки отсутствует Автополе, то они не выводятся, и приходится проверять настройки.
Вывод: Я рекомендую по максимуму располагать выбранные поля на уровне Отчет, а в группировках дополнять/исключать поля совместно с автополем.
Бывает еще такая ситуация: на уровне отчета указываются несколько выбранных полей, в группировке в выбранных полях есть Автополе, и добавлено поле Сумма, но его использование отключено. На первый взгляд отключенное поле не будет оказывать влияние не результат, но это не так – убедиться в этом можно, развернув Автополе.
Рис. 3. Какие поля будут выведены при такой структуре отчета?
Рис. 4. Перечень полей, если развернуть Автополе
В итоге в детальных записях будут выведены все выбранные поля с вышестоящих группировок, кроме поля Сумма (т.к. оно отключено), т.е. поля Покупатель, Товар.
Вывод: Такое поведение кажется неявным, тем не менее отсутствие выбранного поля <> присутствие поля с отключенным использованием.
Рис. 5. Результат при такой настройке
Расположение итогов = нет
Наверное, самые частые грабли, которые я видел на форумах. К счастью, это легко проверяется. Симптомы: разработчик добавляет в выбранные поля ресурсы, но ресурсы не выводятся в отчет. Как правило, разработчик хочет добиться отключения общих итогов по горизонтали или по вертикали, а получается так. Структура, как правильно имеет следующий вид:
Рис. 6. Настройки
Но в итоге отчет выглядит следующим образом:
Рис. 7. Вид отчета с настройкой Расположение итогов = нет
Все дело в настройках на вкладке дополнительно – Расположение итогов = нет. Установив эту настройку, ресурсы вообще не выводятся. Здесь надо четко понимать расположение итогов – отвечает за вывод всех ресурсов в группировке, Расположение общих итогов, Расположение общих итогов по горизонтали, по вертикали – отвечает за то, где будет располагаться секция Итого по группировке.
Рис. 8. Настройка Расположение итогов, Расположение общих итогов.
Для чего может пригодиться управление дополнительными параметрами Расположение итогов, Расположение группировок продемонстрировано в этом видео: и здесь.
Вывод: Не отключайте расположение итогов, вам скорее всего нужна настройка Расположение общих итогов :-)
Ресурсы рассчитываются только для группировок
Значения ресурсов не вычисляются для детальных записей, но есть нюансы. Например, в схему добавлено вычисляемое поле ТоварыВГруппе
Рис. 9. Вычисляемое поле
Поле сделано ресурсом - для него указано выражение ресурса.
Рис. 10. Выражения ресурсов
Если в детальных записях будет присутствовать хотя бы одно поле, не являющееся ресурсом, например поле Регистратор, то результат будет следующим…
Рис. 11. Настройки компоновки. В детальных записях поле Регистратор
Значение ресурса не будет вычислено (и соответственно выведено) в детальных записях:
Рис. 12. Значение ресурса не определено в детальных записях
Но, есть небольшой нюанс – если детальные записи вложены в группировку и в детальных записях выводятся только ресурсы, то в поле ресурса выводится значение из вышестоящей группировки. И, честно говоря, не знаю, для чего может понадобиться вкладывать в группировку детальные записи, состоящие только из ресурсов.
Рис. 13. Детальные записи в группировке
Вывод: не ищите значение ресурсов среди детальных записей, они рассчитываются в группировках и общих итогах
Параметр Период – Стандартный период
Для удобства ввода начала и окончания периода отчета используется следующий прием – в параметры отчета добавляется параметр с типом СтандартныйПериод. Например, мы разрабатываем отчет по продажам за период, флаг Автозаполнение в наборе данных запрос стоит, автоматически будут созданы параметры НачалоПериода, КонецПериода. Мы добавляем параметр Период с типом СтандартныйПериод, включаем ограничение доступности для параметров НачалоПериода, КонецПериода.
Рис. 14. Настройки параметров периода
Далее, дорабатываем схему, добавляем в запрос виртуальную таблицу СрезПоследних (СрезПервых, Остатки). Перечень параметров отчета при этом не поменялся, параметр Период, который мы добавили никуда не делся, и кроме того, его тип как был СтандартныйПериод так и остался. При такой конфигурации схемы при её компоновке будет ошибка:
Рис. 15. Ошибка: Несоответствие типов
Все верно – т.к. в параметр Период, виртуальной таблицы СрезПоследних передано значение типа СтандарныйПериод.
Для исправления ошибки в параметр виртуальной таблицы надо передавать значение правильного типа (Дата), а не СтандарныйПериод.
Вывод: Чтобы избежать путаницы, я рекомендую параметру с типом СтандарныйПериод присваивать имя, отличное от Период, например «ПериодОтчета»
Рис. 16. Параметры Период, СтандартныйПериод на своем месте
Параметры Период, НачалоПериода, КонецПериода
При использовании в СКД флага Автозаполнение в схему буду добавлены параметры виртуальных таблиц: Период – для виртуальных таблиц СрезПервых, СрезПоследних, Остатки, а так же НачалоПериода, КонецПериода – для виртуальных таблиц Обороты, ОстаткиИОбороты. Бывают случаи, когда необходимо использовать виртуальную таблицу с пустым параметром периода и проморгать, что для нее будет использоваться такой параметр, хотя в нашем случае мы хотели бы оставить параметр пустым.
Например, надо получить текущие остатки на складе на одну дату, в ценах на другую дату.
Вот такой запрос:
ВЫБРАТЬ
ТоварныеЗапасыОстатки.Товар КАК Товар,
ТоварныеЗапасыОстатки.Склад КАК Склад,
ТоварныеЗапасыОстатки.КоличествоОстаток КАК КоличествоОстаток,
ЦеныТоваровСрезПоследних.Цена КАК Цена
ИЗ
РегистрНакопления.ТоварныеЗапасы.Остатки КАК ТоварныеЗапасыОстатки
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныТоваров.СрезПоследних(&ПериодЦены, ВидЦен = &ВидЦен) КАК ЦеныТоваровСрезПоследних
ПО ТоварныеЗапасыОстатки.Товар = ЦеныТоваровСрезПоследних.Товар
Для виртуальной таблицы Остатки будет использован стандартный параметр – Период, для таблицы среза – ПериодЦены. Но для таблицы СрезПоследних СКД при Автозаполнении так же определит параметр Период (это не видно в тексте запроса) – параметр расширения языка запросов для СКД. В этом случае, если параметр Период используется – то именно его значение будет подставлено в запрос, созданный компоновщиком макета и результат будет неверный. Вот такой текст будет сгенерирован компоновщиком.
ВЫБРАТЬ
ТоварныеЗапасыОстатки.Товар КАК Товар,
ТоварныеЗапасыОстатки.КоличествоОстаток КАК КоличествоОстаток,
ЦеныТоваровСрезПоследних.Цена КАК Цена,
ПРЕДСТАВЛЕНИЕССЫЛКИ(ТоварныеЗапасыОстатки.Товар) КАК ТоварПредставление
ИЗ
РегистрНакопления.ТоварныеЗапасы.Остатки(&П) КАК ТоварныеЗапасыОстатки
ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныТоваров.СрезПоследних(&П, ВидЦен = &ВидЦен) КАК ЦеныТоваровСрезПоследних
ПО ТоварныеЗапасыОстатки.Товар = ЦеныТоваровСрезПоследних.Товар
Чтобы этого избежать можно указывать параметры в расширении языка запросов. А для диагностики я рекомендую пользоваться инструментом Консоль СКД (любой консолью, которая показывает текст и параметры компоновщика макета)
Вывод: для диагностики в подобных ситуациях рекомендую анализировать текст запроса, сгенерированный компоновщиком макета с помощью любой консоли СКД.
Установка параметров выражением НайтиПоКоду(), НайтиПоНаименованию()
Случай, когда в схеме для параметров прописывается выражение вида:
Справочник.Контрагенты.НайтиПоКоду("444")
Здорово, что в СКД так можно делать – написать выражение на встроенном языке, которое будет вычислено при компоновке результата. Но! А что будет если в результате поиска ничего не будет найдено? Правильно – параметру будет присвоена пустая ссылка и мы об этом не узнаем, т.к. ограничение доступности для этого параметра стоит.
Рис. 17. Выражения в параметрах СКД
Вывод: Я рекомендую устанавливать значения параметров компоновки данных в событии ПриКомпоновкеРезультата, при чем, проверяя все результаты поисков и сообщая о непредвиденных результатах пользователю.
Отборы в наборе данных объект
Если добавить набор данных объект и для полей набора данных не указать свойство Тип значения, то в настройках отбора будет доступно лишь сравнение с полем компоновки данных. На скриншоте ниже для Поле1 – не указан тип и система не будет знать из какого справочника предлагать пользователю значения сравнения, для поля Поле2 – указан тип справочник Контрагенты, соответственно в элементе отбора будут предлагаться элементы этого справочника.
Рис. 18. Набор данных объект. Для Поле1 не указан Тип значения.
Рис. 19. Отбор по полю набора данных объект, для которого не указан тип значения.
Вывод: при использовании набора данных объект, если предполагается отбор по полю – указываем его тип в настройках. Можно указывать тип для всех полей
Некорректный расчет итогов
Когда в СКД выбираем таблицу ОстаткиИОбороты и в данных появляется периодичность, т.е. поле содержащее в себе период записи - секунда, день, месяц, год, то для корректного расчета начального, конечного остатка требуется правильно указать роли полей набора данных: Период, Измерения, поле Начального, Конечного остатка.
Рис. 20. Пример правильной настройки ролей
Тем не менее, для того чтобы СКД правильно расставила порядок, одного поля Регистратор недостаточно, нужно еще поле Период и оно даже есть в нашем наборе данных (на скриншоте). Но, если это поле не используется в настройках компоновки, то компоновщик макета его удаляет и результат в группировках может быть вычислен неправильный. Чтобы такого не было – в роли поля Период ставим флаг Обязательное.
Бывают сложные случаи, разрешить которые можно только понимая, как СКД считает итоги. Какие бывают вариации:
1. В наборе данные присутствуют данные виртуальной таблицы ОстаткиИОбороты, но выбирается только Начальный или только Конечный остаток
2. Объединение виртуальной таблицы ОстаткиИОбороты еще с какими-то данными
Описано в статье СКД: Корректный расчет остатков по нескольким регистрам, в этом видео
p.s. Очень надеюсь, что статья прояснила некоторые моменты для тех, кто только осваивает механизм СКД.