Как правильно реализовать учет обращений в периодическом регистре сведений?

При разработке собственных конфигураций часто возникает необходимость вести учет состояний объектов, например, обращений сотрудников или клиентов. Начинающие разработчики часто сталкиваются с трудностями при попытке «дозаписать» данные в периодический регистр сведений из разных документов. Давайте разберем, как спроектировать эту систему правильно, избегая ошибок проектирования.

Определим архитектурные принципы

Главная ошибка, которую мы часто встречаем — это попытка использовать регистр сведений как хранилище всех атрибутов объекта. Запомните: Регистр сведений предназначен для хранения состояний и связей, в то время как первичные данные (суть обращения, автор, подразделение) должны находиться в справочнике или документе.

Для создания надежной системы используйте следующий подход:

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

Как реализовать механизм заполнения табличной части

Рассмотрим, как правильно выбирать нерассмотренные обращения. Основная задача — исключить из выборки те записи, которые уже получили статус «Рассмотрено». Для этого мы используем виртуальную таблицу СрезПоследних.

Рассмотрим пример кода для получения списка нерассмотренных обращений на сервере:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |    ИдеиСрезПоследних.Обращение КАК Обращение,
    |    ИдеиСрезПоследних.СрокРеализации КАК СрокРеализации
    |ИЗ
    |    РегистрСведений.Идеи.СрезПоследних(&Период, ) КАК ИдеиСрезПоследних
    |ГДЕ
    |    ИдеиСрезПоследних.Рассмотрено = ЛОЖЬ
    |    И ИдеиСрезПоследних.Подразделение = &Подразделение";

Запрос.УстановитьПараметр("Период", ТекущаяДата());
Запрос.УстановитьПараметр("Подразделение", Объект.Подразделение);

Результат = Запрос.Выполнить();
Объект.Идеи.Загрузить(Результат.Выгрузить());

Обратите внимание: мы используем метод Загрузить() для табличной части. Это значительно производительнее, чем перебор записей в цикле с использованием метода Добавить().

Решение проблемы с «Булево» и дублированием

В ходе обсуждения мы выяснили, что перенос поля с типом Булево (например, Рассмотрено) из измерений в реквизиты регистра позволяет избежать проблем с дублированием данных в виртуальных таблицах. Когда Рассмотрено является ресурсом, СрезПоследних всегда возвращает только одно последнее актуальное состояние для каждого объекта-измерения.

Основные рекомендации по проведению документов

Никогда не пытайтесь изменять записи, созданные другими документами напрямую. Это ведет к нарушению целостности данных. Каждый документ должен выполнять свои записи в регистр. Если статус обращения меняется:

1. Ваш документ рассмотрения должен создать новую запись в регистре с тем же измерением Обращение, но с новым значением ресурса Рассмотрено = Истина.
2. При следующем запросе СрезПоследних автоматически подтянет вашу новую запись, так как она будет иметь более позднюю дату, чем предыдущая.
3. Таким образом, старые записи остаются в базе для истории, а система всегда видит актуальный статус.

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