Как получить данные из табличных частей документов-регистраторов в отчетах 1С

При разработке сложных отчетов в системе «1С:Предприятие», особенно в таких конфигурациях как «Управление производственным предприятием» (УПП), разработчики часто сталкиваются с ситуацией, когда необходимых данных нет в измерениях или ресурсах регистров. Типичный пример — необходимость получить специфический реквизит из табличной части документа, который не выгружается в движения. Рассмотрим, как решить эту задачу технически и почему иногда стоит пересмотреть сам подход к получению данных.

Проблема обращения к табличным частям через поле «Регистратор»

В языке запросов 1С поле Регистратор имеет составной тип данных. Это означает, что система заранее не знает, к таблице какого именно документа ей придется обращаться. Напрямую обратиться через точку, например Регистратор.РасшифровкаПлатежа.СуммаВзаиморасчетов, невозможно по двум причинам:

1. Поле Регистратор может содержать десятки типов документов, и не у каждого из них есть табличная часть с таким именем.
2. Язык запросов 1С не поддерживает обращение к вложенным таблицам (табличным частям) через точку от ссылочного поля.

Разберем основные способы решения этой задачи, начиная от простых запросов и заканчивая архитектурно правильными методами.

Способ 1. Использование оператора ОБЪЕДИНИТЬ ВСЕ

Это самый прямолинейный метод. Если нам нужно вытащить данные из нескольких видов документов (например, «Платежное поручение исходящее» и «Платежный ордер: списание денежных средств»), мы должны составить отдельные запросы к каждой табличной части и объединить их. Проанализируем пример структуры такого запроса:

ВЫБРАТЬ
    ТЧ.Ссылка КАК Документ,
    ТЧ.СуммаВзаиморасчетов КАК Сумма
ИЗ
    Документ.ПлатежноеПоручениеИсходящее.РасшифровкаПлатежа КАК ТЧ
ГДЕ
    ТЧ.Ссылка В (&СписокРегистраторов)

ОБЪЕДИНИТЬ ВСЕ

ВЫБРАТЬ
    ТЧ.Ссылка,
    ТЧ.СуммаВзаиморасчетов
ИЗ
    Документ.ПлатежныйОрдерСписаниеДенежныхСредств.РасшифровкаПлатежа КАК ТЧ
ГДЕ
    ТЧ.Ссылка В (&СписокРегистраторов)

Важный момент: Чтобы запрос работал быстро, сначала рекомендуется выбрать список уникальных ссылок-регистраторов из нужного вам регистра во временную таблицу, а уже затем соединять или фильтровать по ним запросы к ТЧ. Это позволит избежать полного сканирования таблиц документов.

Способ 2. Связи наборов данных в СКД

Если вы строите отчет на Системе компоновки данных (СКД), можно обойтись без громоздких ОБЪЕДИНИТЬ ВСЕ в одном тексте запроса. Рассмотрим этот алгоритм по шагам:

1. Создаем первый набор данных — запрос к регистру (например, ДвиженияДенежныхСредств).
2. Создаем второй набор данных — запрос к табличным частям всех возможных документов-регистраторов, также используя ОБЪЕДИНИТЬ ВСЕ.
3. На закладке «Связи наборов данных» указываем связь по полю Регистратор (из первого набора) и Ссылка (из второго набора).

Преимущество этого метода в том, что СКД сама оптимизирует запрос. Если пользователь наложит фильтр, который оставит в отчете только один тип документа, СКД может проигнорировать обращения к остальным таблицам (в зависимости от настроек), что повысит производительность.

Методологический подход: Анализ через регистры бухгалтерии

Часто программисты пытаются лезть в табличные части документов потому, что не находят нужных цифр в управленческих регистрах. В случае с покупкой валюты в УПП, автор темы столкнулся с тем, что стандартные отчеты показывают суммы по курсу ЦБ, а не по фактическому курсу покупки. Выясним причину этого поведения.

В бухгалтерском и управленческом учете конвертация валюты обычно отражается через транзитные счета (например, счет 57 «Переводы в пути»). Когда вы покупаете 10 000 долларов за 430 000 рублей, в системе возникают следующие движения:

• Дт 57.11 — Кт 51: Списаны рубли (430 000 руб.).
• Дт 52 — Кт 57.11: Зачислена валюта по курсу ЦБ РФ (например, 420 000 руб. в эквиваленте).
• Дт 91.02 — Кт 57.11: Отражена разница между курсом покупки банка и курсом ЦБ (10 000 руб.).

Проанализировав эту ситуацию, мы понимаем, что реальные затраты (те самые 430 000 рублей) можно получить, не обращаясь к табличным частям документов, а просто просуммировав обороты по счету 57 или проанализировав корреспондирующие движения. Использование регистров бухгалтерии или регистра «Хозрасчетный» в УПП является более надежным способом, так как эти данные уже сбалансированы и проверены бухгалтером.

Почему обращение к табличным частям — это крайняя мера?

Рассмотрим причины, по которым опытные разработчики называют обращение к ТЧ в запросах «признаком неоптимального проектирования»:

1. Производительность: Табличные части документов не имеют индексов по прикладным полям (кроме Ссылка и НомерСтроки). Любой поиск или группировка по «Сумме» или «Номенклатуре» внутри ТЧ при большом объеме данных приведет к существенным задержкам.
2. Целостность данных: Движения в регистрах — это то, что реально попало в баланс и отчеты. Данные в табличной части могут быть изменены программно без перепроведения документа, что приведет к расхождению между вашим «самописным» отчетом по ТЧ и официальными данными базы.
3. Сложность поддержки: При добавлении нового типа документа-регистратора вам придется вручную переписывать все запросы, где используется объединение табличных частей.

Рекомендация: Если данных действительно нет в регистрах, но они критически важны для отчетов, правильным решением будет расширение состава реквизитов регистра (добавление новых ресурсов или реквизитов) и внесение изменений в процедуру проведения документов. Таким образом, данные будут «дублироваться» в регистр один раз при проведении, но зато отчеты будут летать, обращаясь к одной проиндексированной таблице.

Выяснив все нюансы, мы можем сделать вывод: обращение к ТЧ допустимо для разовых проверок или в небольших базах, но для промышленной эксплуатации в УПП или ERP следует использовать данные регистров накопления или бухгалтерии.