При работе с конфигурациями на платформе 1С:Предприятие 8 пользователи часто сталкиваются с необходимостью сохранения специфических комбинаций отборов и группировок. Эти комбинации, называемые вариантами отчетов, позволяют быстро переключаться между разными срезами данных без повторной ручной настройки. Однако при переносе баз, выгрузке данных или глубоком администрировании возникает закономерный вопрос: где физически в базе данных располагаются эти сохраненные параметры. Понимание структуры хранения критически важно для разработчиков и системных администраторов, занимающихся миграцией или восстановлением данных.
В этой статье мы детально разберем внутреннее устройство подсистемы отчетов и механизмов сохранения пользовательских настроек. Вы узнаете, какие системные таблицы задействованы в процессе, как отличить настройки конкретного пользователя от общих настроек для всех и как корректно извлечь эти данные при помощи запросов или обработки выгрузки. Мы рассмотрим как стандартные механизмы платформы, так и специфические случаи, связанные с автономным режимом работы и обновлением конфигураций.
Логика работы механизма вариантов отчетов
Механизм вариантов отчетов в 1С построен на принципе разделения логики формирования данных и визуального представления этих данных пользователю. Когда вы настраиваете отчет, система не просто запоминает текущее состояние полей на экране, она сериализует структуру компоновки данных в специальный формат. Этот формат затем сохраняется в информационной базе как объект метаданных или запись в регистре сведений, в зависимости от типа отчета и версии платформы.
Важно понимать разницу между "Настройками" (отборы, поля, сортировки) и самим "Вариантом" (именованный набор настроек). Настройки могут быть временными и действовать только до закрытия окна, тогда как вариант подразумевает постоянное сохранение в базе для последующего использования. Платформа использует механизм СКД (Система Компоновки Данных) для обработки этих структур. При сохранении варианта система создает ссылку на конкретный макет отчета и привязывает к нему XML-представление настроек.
Хранение осуществляется с учетом прав доступа. Если вариант сохранен как "Общий", он становится доступен всем пользователям с соответствующими правами. Если же сохранение произведено в личный раздел, запись маркируется идентификатором текущего пользователя. Это разграничение реализуется на уровне записей в таблицах базы данных, что позволяет гибко управлять видимостью отчетов без изменения кода конфигурации.
⚠️ Внимание: При обновлении типовой конфигурации механизмы хранения вариантов отчетов могут быть изменены разработчиком. Всегда проверяйте релиз-ноты перед массовой выгрузкой настроек, так как структура служебных таблиц может измениться.
Табличная структура хранения в SQL
Для технических специалистов, работающих напрямую с СУБД (MS SQL, PostgreSQL), важно знать конкретные имена таблиц, где resides информация о вариантах. В большинстве современных конфигураций (УТ 11, ЗУП 3.1, БП 3.0) используется регистр сведений с именем ВариантыОтчетов или аналогичным. Однако физическое имя таблицы в базе данных будет сгенерировано платформой и может иметь вид _InfoRgVariantsOfReports или содержать хэш-сумму имени метаданных.
Основные данные хранятся в виде BLOB-объектов или длинных строк, содержащих XML-сериализацию. Ключевыми полями такой таблицы обычно являются:
- 📂 Ссылка — уникальный идентификатор варианта отчета.
- 👤 Пользователь — ссылка на справочник пользователей (пустое значение означает общий доступ).
- ⚙️ Настройки — поле типа ХранениеЗначения, содержащее сериализованные параметры СКД.
- 📝 Описание — текстовое наименование варианта, видимое в интерфейсе.
Помимо основного регистра, может использоваться таблица _InfoRgSettings для хранения глобальных настроек системы отчетов. В ней фиксируются параметры по умолчанию, которые применяются, если пользователь не выбрал конкретный сохраненный вариант. Структура этой таблицы часто включает поля для хранения версии схемы компоновки данных, что позволяет платформе автоматически конвертировать старые настройки при изменении метаданных отчета.
Технические детали полей BLOB
Внутри поля настроек хранится не просто XML, а бинарная сериализация объекта 1С, которая при чтении через запрос SQL выглядит как нечитаемая последовательность байт. Для расшифровки необходимо использовать функции платформы или специальные утилиты конвертации.
Анализ через Конфигуратор и Тонкий клиент
Если у вас нет прямого доступа к серверу баз данных, вы можете проанализировать структуру хранения средствами самой платформы 1С. В режиме Конфигуратора можно открыть дерево метаданных и найти объект, отвечающий за отчеты. Чаще всего это справочник или регистр сведений с именем, содержащим слова "Варианты" или "НастройкиОтчетов". Просмотр структуры этого объекта покажет типы полей и их назначение.
В режиме пользователя (Тонкий клиент) существует скрытый механизм просмотра технических имен полей. Включив режим отладки или используя внешние обработки, можно вывести список вариантов отчетов в табличном документе и увидеть их внутренние идентификаторы. Это полезно при написании обработок для массового копирования настроек между базами. Команда ПолучитьВариантыОтчета() в коде возвращает коллекцию объектов, каждый из которых содержит ссылку на хранилище.
Для анализа содержимого конкретного варианта можно воспользоваться универсальным отчетом, если он доступен в вашей конфигурации. Настроив его на вывод по регистру сведений вариантов отчетов, вы сможете увидеть список всех сохраненных настроек. Однако сами параметры отбора внутри ячеек таблицы будут отображаться в виде объектов, которые требуют дополнительного раскрытия для просмотра деталей.
| Объект метаданных | Тип хранения | Доступность | Пример имени в БД |
|---|---|---|---|
| ВариантыОтчетов | Регистр сведений | Пользовательский | _InfoRgVariantsOfReports |
| НастройкиОтчетов | Регистр сведений | Системный | _InfoRgReportSettings |
| МакетыОтчетов | Справочник | Общий | _ReferenceReportsLayouts |
| ПользовательскиеНастройки | Табличное значение | Временный | (не сохраняется в БД) |
Используйте обработку "Универсальный обмен данными в формате XML" для выгрузки вариантов отчетов. Она корректно обрабатывает сложные типы данных внутри настроек СКД.
Особенности хранения в файловом варианте базы
В файловом варианте работы 1С (файл .1CD) данные хранятся в собственном бинарном формате платформы, а не в таблицах SQL. Физически варианты отчетов "зашиты" внутри этого файла в виде страниц данных. Прямое редактирование такого файла сторонними утилитами невозможно и приведет к повреждению базы. Для извлечения настроек необходимо использовать штатные средства платформы или ODBC-драйвер 1С.
При подключении к файловой базе через ODBC, система транслирует запросы к виртуальным таблицам, которые по структуре аналогичны таблицам SQL-версии. Это означает, что логика запросов для получения списка вариантов отчетов остается неизменной независимо от типа СУБД. Разница заключается лишь в производительности: выборка из большого количества вариантов в файловой базе может занимать больше времени из-за особенностей индексации.
Особое внимание следует уделить блокировкам. При сохранении нового варианта отчета в многопользовательском файловом режиме платформа устанавливает монопольную блокировку на соответствующую таблицу регистра сведений. Если в этот момент другой пользователь попытается изменить свои настройки, он может получить сообщение о конфликте блокировок. Это нормальное поведение системы, обеспечивающее целостность данных.
⚠️ Внимание: Никогда не пытайтесь редактировать файл .1CD в hex-редакторе для изменения настроек отчетов. Это гарантированно приведет к ошибке "Таблица базы данных повреждена" при следующей попытке открытия базы.
Перенос настроек между информационными базами
Частой задачей администраторов является перенос настроенных вариантов отчетов из тестовой базы в продуктивную или между разными филиалами компании. Стандартная обработка выгрузки/загрузки данных (XML) поддерживает выгрузку регистров сведений, где хранятся варианты. Однако при загрузке могут возникнуть конфликты, если в целевой базе уже существуют варианты с такими же именами или идентификаторами.
Для безопасного переноса рекомендуется использовать специализированные обработки, которые проверяют наличие дублей перед записью. Алгоритм действия обычно следующий:
- 🔄 Считать все варианты из базы-источника.
- 🔍 Проверить наличие вариантов с аналогичным именем в базе-приемнике.
- 💾 Записать новые варианты, присвоив им новые уникальные идентификаторы при необходимости.
- ✅ Обновить ссылки на используемые в настройках справочники (если коды справочников в базах различаются).
Проблема может возникнуть, если в настройках отчета используются ссылки на конкретные элементы справочников (например, "Организация: ООО Ромашка"). Если в новой базе этот элемент имеет другой уникальный идентификатор (UUID), отчет может выдать ошибку при открытии. В таких случаях требуется дополнительная обработка данных для подмены ссылок на актуальные GUID целевой базы.
☑️ Подготовка к переносу вариантов отчетов
Программное управление и очистка устаревших данных
Со временем в базе данных может накопиться большое количество устаревших вариантов отчетов, созданных бывшими сотрудниками или в ходе тестирования. Это не только захламляет интерфейс выбора, но и увеличивает размер базы данных. Для очистки можно написать небольшую обработку на встроенном языке 1С, которая удалит записи из регистра сведений по определенному критерию (например, по владельцу или дате создания).
// Пример кода для удаления вариантов отчета конкретного пользователя
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
| ВариантыОтчетов.Ссылка КАК Ссылка
|ИЗ
| РегистрСведений.ВариантыОтчетов КАК ВариантыОтчетов
|ГДЕ
| ВариантыОтчетов.Пользователь = &Пользователь";
Запрос.УстановитьПараметр("Пользователь", ТекущийПользователь());
Результат = Запрос.Выполнить();
Выборка = Результат.Выбрать();
Пока Выборка.Следующий() Цикл
Объект = Документы.ВариантыОтчетов.СоздатьМенеджерОбъекта().ПолучитьОбъект(Выборка.Ссылка);
// Логика удаления зависит от конкретной конфигурации
КонецЦикла;
При программном создании новых вариантов отчетов важно соблюдать правило уникальности имен в рамках одного пользователя. Платформа не всегда автоматически контролирует дублирование, и попытка сохранить вариант с именем, которое уже существует в личном списке пользователя, может привести к перезаписи старого варианта без предупреждения. Всегда выполняйте проверку существования перед записью.
Регулярная очистка неиспользуемых вариантов отчетов улучшает производительность системы и упрощает навигацию для пользователей, но требует осторожности при удалении общих вариантов.
Диагностика проблем с отображением настроек
Иногда пользователи сталкиваются с ситуацией, когда сохраненный вариант отчета перестает открываться или отображается с ошибкой "Неверная структура настроек". Это часто происходит после обновления конфигурации, когда разработчики изменили состав полей отчета или удалили некоторые измерения. Старые настройки содержат ссылки на несуществующие поля метаданных, что вызывает сбой при десериализации.
В таких случаях помогает сброс настроек отчета к заводским. В интерфейсе 1С обычно есть кнопка "Восстановить настройки по умолчанию" или аналогичная. Если интерфейс не позволяет это сделать из-за ошибки, можно удалить проблемную запись напрямую из таблицы вариантов отчетов через консоль запросов (при наличии прав администратора). После удаления система создаст новый вариант с настройками по умолчанию при следующем запуске отчета.
Также стоит проверить права доступа. Если вариант был создан как общий, но впоследствии права на чтение соответствующего справочника или регистра были отозваны у группы пользователей, они не смогут увидеть этот вариант в списке. Диагностика прав доступа проводится через режим "Предприятие" с правами администратора безопасности.
Где точно находится таблица с вариантами отчетов в SQL?
Имя таблицы зависит от имени объекта метаданных в конфигураторе. Если объект называется "ВариантыОтчетов", то в SQL Server таблица будет называться _InfoRgVariantsOfReports. Если имя содержит пробелы или спецсимволы, они заменяются на подчеркивания. Точное имя можно узнать, выполнив запрос к системным таблицам базы данных с фильтром по префиксу _InfoRg.
Можно ли перенести варианты отчетов между разными конфигурациями (например, из БП в УТ)?
Технически выгрузить данные можно, но работать они не будут. Структура полей, измерений и ресурсов в отчетах разных конфигураций кардинально отличается. Попытка загрузить настройки отчета из одной конфигурации в другую приведет к ошибке структуры СКД. Перенос возможен только между базами с идентичной или совместимой конфигурацией.
Почему после обновления 1С пропали все сохраненные варианты отчетов?
При обновлении конфигурации может измениться внутренняя структура метаданных отчета. Если изменения критические, платформа помечает старые настройки как несовместимые и скрывает их. В некоторых случаях требуется ручная конвертация настроек или создание новых вариантов на основе обновленных макетов. Проверьте журнал регистрации на наличие ошибок при открытии отчетов.
Как узнать, кто создал конкретный вариант отчета?
В таблице регистра сведений вариантов отчетов есть поле "Пользователь" (или "Владелец"). Если вариант общий, это поле пустое. Если личный — там хранится ссылка на пользователя. Через консоль запросов можно вывести список вариантов с указанием имени пользователя, который их создал, используя соединение с регистром сведений "Пользователи".
Влияет ли количество сохраненных вариантов отчетов на скорость работы 1С?
Да, влияет, но незначительно. Основное замедление происходит в момент открытия формы отчета, когда система загружает список доступных вариантов в поле выбора. Если у пользователя сохранены тысячи вариантов, выпадающий список может формироваться несколько секунд. На скорость формирования самих данных отчета количество сохраненных вариантов не влияет.