← На главную

Мы сталкиваемся с распространенной проблемой в 1С:ЗУП 3.1 при использовании Универсального отчета: параметры времени, которые мы устанавливаем в заголовке отчета (например, 2020, 2021 или 2022 годы), отображаются в параметрах отчета (выделенных красным) как неизменный 2019 год. Это происходит, когда мы строим отчет на основе непериодических регистров сведений. Разберем, почему возникает такая ситуация и как ее можно решить.

Анализируем суть проблемы: Почему возникает такая ситуация?

Как известно, УниверсальныйОтчет в 1С:ЗУП 3.1 — это мощный инструмент для гибкого формирования отчетов по различным объектам системы, включая справочники, документы, регистры сведений и регистры накопления. Однако, несмотря на его универсальность, при работе с непериодическими регистрами сведений возникают сложности с передачей параметров времени.

Разберем ключевые моменты:

1. Непериодические регистры сведений: В отличие от периодических регистров, данные в непериодических регистрах не имеют строгой привязки ко времени на уровне структуры самого регистра. Хотя записи в них могут содержать поля типа «Дата», сами данные не хранятся в привязке к определенным временным срезам.
2. Особенности работы Универсального отчета с периодом: Универсальный отчет по умолчанию разработан так, чтобы максимально эффективно работать с различными типами объектов. Для объектов, которые по своей природе не зависят от временных промежутков (например, справочники), параметр «Период» может быть вовсе не предусмотрен или работать специфически. Для непериодических регистров СКД (Система Компоновки Данных), лежащая в основе отчета, может некорректно обрабатывать или не передавать выбранный период.
3. Причина некорректного отображения: На форумах и в различных источниках указывают, что в типовом решении 1С:ЗУП 3.1 "криво реализован перенос параметров в отборы в случае непериодического регистра". Это означает, что механизм Универсального отчета не всегда правильно проецирует значение параметра «Период», выбранного пользователем в шапке отчета, в запросы или отборы полей, отвечающих за время внутри СКД. В результате, вместо переданного периода, отчет использует какое-то фиксированное значение по умолчанию, которое, как мы видим, почему-то зафиксировано на 2019 годе. Мы наблюдаем, что если просто вывести данный регистр и параметры времени без дополнительной настройки отчета, даты будут текущие, что еще раз подчеркивает проблему именно в механизме передачи параметров внутри сложной структуры Универсального отчета.

Таким образом, проблема кроется в несовершенстве механизма передачи временных параметров для непериодических регистров в стандартной реализации Универсального отчета, что приводит к игнорированию выбранного периода и подстановке значения по умолчанию.

Решение 1: Ручная правка отчета через Блокнот (или любой XML-редактор)

Один из пользователей форума подтвердил, что смог решить проблему, отредактировав отчет в Блокноте. Это возможно, поскольку УниверсальныйОтчет, как и большинство отчетов 1С, основан на СистемеКомпоновкиДанных (СКД). Определение СКД хранится в XML-формате, и ручная правка означает непосредственное изменение этого XML-файла.

Давайте рассмотрим шаги, которые мы можем предпринять для такой правки:

1. Сохранение отчета: Прежде всего, нам необходимо получить доступ к схеме компоновки данных отчета. Если отчет является внешней обработкой или имеет возможность сохранения макета, сохраните его в виде файла (например, .erf или .xml). Если это встроенный отчет конфигурации, вам потребуется доступ к конфигуратору, чтобы выгрузить схему компоновки данных. Обычно это можно сделать через контекстное меню отчета в конфигураторе: Схема компоновки данных -> Выгрузить схему компоновки данных.
2. Открытие в редакторе: Откройте сохраненный файл (или выгруженный XML-файл схемы) в текстовом редакторе, например, в Блокноте, Notepad++ или любом другом XML-редакторе.
3. Поиск и изменение параметров в XML: Внутри XML-файла схемы компоновки данных нам нужно найти и скорректировать места, отвечающие за определение и использование параметров периода.
   • Определение параметров: Найдите раздел <parameters>. Убедимся, что параметры, отвечающие за период (обычно НачалоПериода и КонецПериода), корректно определены. Проверьте их тип данных (DataType должен быть Дата) и свойство Use (должно быть Always или InReport). Если эти параметры отсутствуют или некорректно определены, мы можем добавить или исправить их. Например:
     Скопировать код

     
     <parameter name="НачалоПериода">
         <value xsi:type="xs:dateTime">2023-01-01T00:00:00</value>
         <use>Always</use>
         <choiceParameterLinks/>
         <title xsi:type="v8:LocalStringType">
             <v8:item>
                 <v8:lang>ru</v8:lang>
                 <v8:content>Начало периода</v8:content>
             </v8:item>
         </title>
         <dataPath xsi:type="xs:string">НачалоПериода</dataPath>
         <titleLocation>Auto</titleLocation>
         <extendedEdit>DontUse</extendedEdit>
     </parameter>
     <parameter name="КонецПериода">
         <value xsi:type="xs:dateTime">2023-12-31T23:59:59</value>
         <use>Always</use>
         <choiceParameterLinks/>
         <title xsi:type="v8:LocalStringType">
             <v8:item>
                 <v8:lang>ru</v8:lang>
                 <v8:content>Конец периода</v8:content>
             </v8:item>
         </title>
         <dataPath xsi:type="xs:string">КонецПериода</dataPath>
         <titleLocation>Auto</titleLocation>
         <extendedEdit>DontUse</extendedEdit>
     </parameter>
     

     Важно, чтобы <value> не содержал жестко закодированного 2019 года, а был либо пустым, либо содержал динамическое значение по умолчанию, либо вовсе не присутствовал, полагаясь на передачу из внешнего источника.

   • Использование в запросе: Перейдем к разделу <dataSets> и найдем внутри него <dataSetQuery>. Здесь находится текст запроса, который выбирает данные из регистра. Важно убедиться, что условия отбора по периоду включены в запрос явно. Даже если регистр непериодический, но содержит поле даты (например, ДатаСобытия), мы должны использовать его для фильтрации. Пример:
     Скопировать код

     
     <query>
         ВЫБРАТЬ
             РегистрСведенийНаш.Поле1,
             РегистрСведенийНаш.ДатаСобытия,
             ...
         ИЗ
             РегистрСведений.НашНепериодическийРегистр КАК РегистрСведенийНаш
         ГДЕ
             РегистрСведенийНаш.ДатаСобытия МЕЖДУ &НачалоПериода И &КонецПериода
     </query>
     

     Если в запросе нет условий МЕЖДУ &НачалоПериода И &КонецПериода или аналогичных, это может быть причиной игнорирования периода. Мы должны добавить эти условия.

   • Связь параметров с настройками отчета: Иногда проблема может быть в том, что параметры СКД не связаны с параметрами, которые отображаются в пользовательских настройках отчета. В типовом Универсальном отчете эта связь обычно автоматическая, но при сбоях может потребоваться более глубокий анализ раздела <reportParameters> и <settings> в XML, чтобы убедиться, что НачалоПериода и КонецПериода корректно сопоставлены с элементами пользовательских настроек.
4. Сохранение и загрузка: После внесения изменений сохраните XML-файл. Затем загрузите отредактированную схему компоновки данных обратно в отчет (через конфигуратор Схема компоновки данных -> Загрузить схему компоновки данных) или откройте отредактированный внешний отчет/обработку в режиме 1С:Предприятия.

Этот метод требует осторожности и базовых знаний XML и СКД, так как любая синтаксическая ошибка может привести к неработоспособности отчета. Однако, как видим, он может быть эффективным быстрым решением.

Решение 2: Разработка собственного отчета на СКД

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

Создание собственного отчета на СКД предоставляет нам полный контроль над запросами, параметрами и логикой формирования данных. Рассмотрим основные шаги:

1. Создание новой обработки или отчета: В конфигураторе мы создаем новый объект конфигурации типа «Отчет» или «Обработка».
2. Определение схемы компоновки данных:
   • Создание набора данных-запроса: Открываем редактор схемы компоновки данных. Создаем новый набор данных типа «Запрос». В конструкторе запроса мы явно выбираем необходимые поля из нашего непериодического регистра сведений.
   • Явное указание параметров периода в запросе: Это ключевой момент. В тексте запроса мы обязательно включаем параметры НачалоПериода и КонецПериода и используем их для фильтрации данных по полю даты в регистре. Например, если в нашем непериодическом регистре есть поле ДатаСобытия, запрос будет выглядеть так:
     Скопировать код

     
     ВЫБРАТЬ
         РегистрСведенийНаш.Поле1,
         РегистрСведенийНаш.ДатаСобытия,
         РегистрСведенийНаш.Измерение2,
         РегистрСведенийНаш.Ресурс1
     ИЗ
         РегистрСведений.НашНепериодическийРегистр КАК РегистрСведенийНаш
     ГДЕ
         РегистрСведенийНаш.ДатаСобытия МЕЖДУ &НачалоПериода И &КонецПериода
     

   • Определение параметров СКД: Переходим на закладку «Параметры» в редакторе СКД. Здесь мы добавляем параметры НачалоПериода и КонецПериода. Обязательно устанавливаем для них тип «Дата» и определяем их свойства использования (например, «Включать в пользовательские настройки» и «Редактировать»). Мы можем также задать значения по умолчанию, которые будут подставляться, если пользователь их не укажет.
   • Настройка полей, отборов и группировок: На закладках «Поля», «Отборы», «Порядок», «Группировки» и «Макеты» мы настраиваем внешний вид и содержание нашего отчета в соответствии с бизнес-требованиями.
3. Создание макета (при необходимости): Мы можем использовать стандартный макет или разработать собственный, если требуется специфическое оформление.
4. Формирование отчета в пользовательском режиме: После сохранения и обновления конфигурации, наш новый отчет будет доступен пользователям. Он будет корректно обрабатывать выбранный ими период, так как мы явно указали его использование в запросе и параметрах СКД.

Этот подход более трудоемкий, но он обеспечивает максимальную гибкость, надежность и предсказуемость в работе отчета.

Выводы и рекомендации

Проблема с некорректным отображением года (фиксированный 2019) в параметрах времени Универсального отчета 1С:ЗУП 3.1 при работе с непериодическими регистрами является известной "особенностью" или ограничением типового механизма. Вероятно, это связано с тем, что Универсальный отчет по умолчанию работает с таблицами и не всегда учитывает специфическую логику обработки временных данных для непериодических объектов в части передачи параметров.

Мы предлагаем следующие рекомендации:

• Если нам нужно быстрое и локальное решение для относительно простого отчета, мы можем попробовать ручную правку XML-схемы компоновки данных в Блокноте. Однако, мы должны помнить о потенциальных рисках и необходимости понимания структуры СКД.
• Для критически важных задач, сложных отчетов, объединяющих несколько источников данных, или требующих расчета сложных показателей, мы настоятельно рекомендуем разработку собственного отчета на базе СКД. Этот подход дает нам полный контроль над запросами, параметрами и логикой формирования отчета, обеспечивая стабильность и корректность данных.

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