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