При разработке отчетов в системе «1С:Предприятие 8» программисты часто сталкиваются с дилеммой: какую виртуальную таблицу регистра накопления выбрать для получения корректных данных и как правильно организовать отборы для пользователей. Ситуация усложняется, если в текущей конфигурации по какой-то причине временно отсутствуют движения по регистрам, и разработчик пытается построить отчет напрямую по табличным частям документов.
В этой статье мы подробно рассмотрим, почему обращение к табличным частям документов для построения аналитических отчетов является критической архитектурной ошибкой. Мы также разберем, какую виртуальную таблицу регистра накопления остатков следует использовать для отчета «Движение номенклатуры», и пошагово решим проблему настройки иерархических отборов (по группам и элементам) в Системе компоновки данных (СКД).
Регистр накопления с видом Остатки предоставляет разработчику три виртуальные таблицы. Рассмотрим их назначение, чтобы определить наиболее подходящую для нашей задачи:
Остатки — предназначена для получения среза данных на определенный момент времени. Она возвращает только актуальные остатки ресурсов, без информации о том, какими хозяйственными операциями и документами они были сформированы. Использовать её для отчета по движениям бессмысленно, так как мы не увидим приходов и расходов.Обороты — возвращает совокупные изменения (приход и расход) за указанный период времени. Она полезна, когда нужно проанализировать чистые объемы операций (например, сколько всего было продано товара за месяц), но она не предоставляет информации о начальном и конечном остатках на складах.ОстаткиИОбороты — наиболее мощная виртуальная таблица, которая объединяет в себе возможности первых двух. Она возвращает начальный остаток, обороты (приход и расход в различных разрезах, включая регистраторы) и конечный остаток за заданный интервал времени.Для реализации полноценного отчета по движениям номенклатуры (карточки движения товара, ведомости по товарам на складах) нам идеально подходит именно таблица ОстаткиИОбороты. Она позволяет в одном запросе получить полную картину динамики изменения складских запасов.
Рассмотрим важную техническую деталь, связанную с периодичностью и границами периодов при работе с этой таблицей в СКД. При получении остатков платформа «1С:Предприятие» по умолчанию рассчитывает остаток на начало указанной секунды. Если конечная дата вашего отчета установлена как 31.12.2025 23:59:59, то движения, совершенные в эту самую последнюю секунду, могут не войти в расчет конечного остатка.
Чтобы избежать этой проблемы при ручном написании запросов, разработчики передают в параметры виртуальной таблицы объект Граница со значением ВидГраницы.Включая. В СКД эта проблема решается автоматически, если правильно настроены роли полей периодов, либо путем ручной передачи параметров в настройки компоновки данных. СКД умеет самостоятельно приводить конечную дату к концу дня или использовать границы, если в параметрах виртуальной таблицы указаны стандартные переменные &НачалоПериода и &КонецПериода.
Иногда у разработчиков возникает соблазн построить отчет непосредственно по физическим таблицам документов (например, обратиться к табличной части Товары документа РеализацияТоваровУслуг). Мотивацией обычно служит то, что «документ временно не делает движений при проведении» или «регистр еще не спроектирован». Рассмотрим подробнее, почему такой подход является грубейшим антипаттерном в среде 1С.
1. Катастрофическое падение производительности
Регистры накопления хранят информацию в СУБД в специально оптимизированном виде. Платформа 1С поддерживает таблицы итогов, которые рассчитываются и сохраняются на конец каждого месяца. Когда мы обращаемся к виртуальной таблице остатков, СУБД не сканирует все документы с начала времен. Она берет уже рассчитанные итоги за ближайший месяц и быстро добавляет к ним движения за небольшой «хвост» дней. Запрос выполняется мгновенно.
Если же мы пишем запрос к табличной части документа, СУБД вынуждена выполнить полное сканирование (Full Table Scan) тяжелых физических таблиц за весь указанный период. На реальной базе с тысячами документов такой отчет просто повесит систему или приведет к превышению времени ожидания блокировки СУБД.
2. Отсутствие индексов по аналитическим разрезам
В регистрах накопления все измерения (такие как Номенклатура, Склад, Контрагент) автоматически индексируются СУБД. Это гарантирует высокую скорость фильтрации и поиска данных. В табличных частях документов реквизиты (например, Количество или даже Номенклатура в некоторых случаях) не имеют необходимых индексов для быстрого построения сложных аналитических выборок. Попытка наложить тяжелый отбор по номенклатуре на табличную часть приведет к крайне медленной работе СУБД.
3. Логическая недостоверность данных
Документы в информационной базе могут находиться в самых разных состояниях: они могут быть не проведены, помечены на удаление или находиться в процессе редактирования. Если строить отчет по табличной части, в него могут ошибочно попасть черновые данные из непроведенных документов. Регистр накопления гарантирует, что в нем содержатся записи только по фактически проведенным, актуальным и одобренным системой документам.
4. Проблемы масштабирования и поддержки кода
Представим, что сегодня в вашей системе номенклатуру списывает только документ РеализацияТоваровУслуг. Вы написали отчет по его табличной части. Завтра в систему добавляется новый документ — СписаниеТоваров или ПеремещениеТоваров. Чтобы ваш отчет продолжал показывать корректные данные, вам придется полностью переписывать запрос, объединяя таблицы разных документов через оператор ОБЪЕДИНИТЬ ВСЕ. Если бы отчет изначально строился по регистру накопления, он бы продолжил работать автоматически, так как новые документы просто делали бы движения по этому единому регистру.
При попытке построить отчет по табличной части документов разработчики часто сталкиваются с интерфейсной проблемой: СКД не позволяет пользователю выбрать группу (папку) справочника номенклатуры в качестве значения отбора, разрешая выбирать только конечные элементы. Проанализируем причины этого поведения и разберем методы решения.
Когда запрос обращается к табличной части документа, СКД не всегда может однозначно определить точный тип выбираемого поля. Особенно это актуально, если реквизит имеет составной тип данных или если запрос содержит сложные левые соединения. Если СКД не уверена, что поле строго относится к конкретному справочнику, она блокирует отображение иерархического дерева и не позволяет выбирать папки.
Для решения этой проблемы мы должны принудительно типизировать поле в тексте запроса с помощью конструкции ВЫРАЗИТЬ. Посмотрим на пример:
ВЫБРАТЬ
ВЫРАЗИТЬ(РеализацияТовары.Номенклатура КАК Справочник.Номенклатура) КАК Номенклатура,
РеализацияТовары.Количество КАК Количество
ИЗ
Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТовары
После явного приведения типов СКД четко определит связь поля со справочником Номенклатура и активирует механизмы работы с иерархией.
Даже если тип поля определен верно, в настройках самой схемы компоновки данных может стоять жесткое ограничение на выбор только элементов. Нам необходимо вручную скорректировать эту настройку. Разберем этот процесс по шагам:
Номенклатура.Эта простая настройка мгновенно снимет ограничение на уровне платформенного интерфейса, и пользователи смогут выбирать папки номенклатуры при интерактивной настройке отчетов.
Очень часто разработчики и пользователи совершают ошибку, выбирая вид сравнения Равно или В списке при попытке отфильтровать данные по папке справочника. Логика работы СУБД в данном случае проста: в физической таблице документов или движений регистра всегда хранятся ссылки исключительно на конкретные элементы (карточки товаров), но никогда не хранятся ссылки на папки (группы).
Если мы установим отбор Номенклатура Равно [Группа "Бытовая техника"], система будет искать записи, у которых в поле номенклатуры записана именно эта группа. Таких записей не существует, и отчет вернет пустой результат.
Для корректной фильтрации по иерархии необходимо использовать специальные виды сравнения:
При использовании этих операторов СКД автоматически преобразует отбор в соответствующий SQL-запрос с поиском по иерархии справочника.
Выясним, как СКД обрабатывает отборы физически. Если мы накладываем отбор на поле виртуальной таблицы регистра остатков, СКД выполняет интеллектуальную оптимизацию. Она переносит наше условие отбора непосредственно внутрь параметров виртуальной таблицы. В итоге СУБД выполняет запрос следующего вида:
ВЫБРАТЬ
ТоварыНаСкладах.Номенклатура,
ТоварыНаСкладах.В НаличииОстаток
ИЗ
РегистрНакопления.ТоварыНаСкладах.Остатки(&Период, Номенклатура В (&СписокНоменклатуры)) КАК ТоварыНаСкладах
СУБД выбирает из базы данных уже отфильтрованный, минимальный объем информации. Если же мы строим отчет по табличной части документа, СКД лишена возможности такой оптимизации. Ей придется выполнить тяжелый запрос к физической таблице, подставив условие фильтрации в самый конец через конструкцию ГДЕ:
ВЫБРАТЬ
РеализацияТовары.Номенклатура,
РеализацияТовары.Количество
ИЗ
Документ.RealizationТоваровУслуг.Товары КАК РеализацияТовары
ГДЕ
РеализацияТовары.Номенклатура В (&СписокНоменклатуры)
Это заставляет СУБД проделывать колоссальную лишнюю работу по чтению неиндексированных данных, что лишний раз доказывает необходимость использования регистров накопления.
Рассмотрим пример правильного построения запроса для схемы компоновки данных с использованием виртуальной таблицы ОстаткиИОбороты регистра накопления ТоварыНаСкладах:
ВЫБРАТЬ
ТоварыНаСкладахОстаткиИОбороты.Номенклатура КАК Номенклатура,
ТоварыНаСкладахОстаткиИОбороты.Склад КАК Склад,
ТоварыНаСкладахОстаткиИОбороты.ВНаличииНачальныйОстаток КАК НачальныйОстаток,
ТоварыНаСкладахОстаткиИОбороты.ВНаличииПриход КАК Приход,
ТоварыНаСкладахОстаткиИОбороты.ВНаличииРасход КАК Расход,
ТоварыНаСкладахОстаткиИОбороты.ВНаличииКонечныйОстаток КАК КонечныйОстаток,
ТоварыНаСкладахОстаткиИОбороты.Регистратор КАК Регистратор
ИЗ
РегистрНакопления.ТоварыНаСкладах.ОстаткиИОбороты({&НачалоПериода}, {&КонецПериода}, Авто, , ) КАК ТоварыНаСкладахОстаткиИОбороты
В данном запросе фигурные скобки {} вокруг параметров &НачалоПериода и &КонецПериода указывают СКД на то, что эти параметры являются необязательными и управляются непосредственно через пользовательские настройки компоновки данных. Платформа самостоятельно позаботится о передаче дат и наложении оптимизированных отборов по номенклатуре и складам непосредственно внутрь виртуальной таблицы.
Мы проанализировали ключевые аспекты построения отчетов по движениям запасов в системе «1С:Предприятие 8». Проектирование отчетов напрямую по табличным частям документов — это тупиковый путь, который гарантированно приведет к зависанию информационной базы при увеличении объема данных. Единственным верным архитектурным решением является использование регистров накопления и их виртуальной таблицы ОстаткиИОбороты.
Все сложности с настройкой иерархических отборов по папкам справочников легко решаются явным приведением типов ВЫРАЗИТЬ в запросе, настройкой параметров редактирования поля в СКД и обучением пользователей правильному выбору видов сравнения В группе.