Как убрать запись из «Среза последних» регистра сведений, не удаляя её физически?

← На главную

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

Почему «зануление» ресурсов не работает

Частая ошибка — попытка очистить ресурсы записи (например, установить 0 или ПустаяСсылка), чтобы запись «исчезла» из отчетов. Важно понимать, что РегистрСведений хранит данные в разрезе измерений. Когда вы записываете документ, который якобы «закрывает» сделку, вы просто создаете новую запись с теми же измерениями, но измененными ресурсами.

Виртуальная таблица СрезПоследних работает на уровне СУБД: она выбирает запись с самым поздним периодом для каждого уникального набора измерений. Если в регистре есть запись с пустыми ресурсами, СрезПоследних воспримет её как самую актуальную и включит в выборку. Таким образом, физическое удаление или распроведение документа-регистратора остается единственным способом полностью исключить запись из результата запроса к этой виртуальной таблице.

Архитектурные подходы к решению задачи

Если ваша бизнес-логика требует отображать только «активные» сделки, не нагружая систему «мусорными» записями в срезе, рассмотрим наиболее эффективные способы решения этой задачи.

1. Использование регистра накопления

Это «золотой стандарт» 1С для учета остатков. Вместо регистра сведений создайте РегистрНакопления.

Открытие сделки — это Приход (увеличение ресурса).
Закрытие сделки — это Расход (уменьшение ресурса до нуля).

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

2. Добавление признака активности

Если по каким-то причинам переход на РегистрНакопления невозможен, используйте в РегистреСведений дополнительное измерение Активность (булево).

В этом случае логика работы будет выглядеть так:


// Пример логики закрытия сделки
Запись = РегистрыСведений.НашиСделки.СоздатьМенеджерЗаписи();
Запись.Сделка = СсылкаНаСделку;
Запись.Активность = Ложь; // Помечаем сделку как закрытую
Запись.Записать();

В запросе вы сможете легко отфильтровать ненужные данные:


ВЫБРАТЬ
    Срез.Сделка
ИЗ
    РегистрСведений.НашиСделки.СрезПоследних(&ТекущаяДата, ) КАК Срез
ГДЕ
    Срез.Активность = ИСТИНА

3. Оптимизация работы с «архивными» данными

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

Резюме

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

Провести рефакторинг и перейти на РегистрНакопления, если речь идет об учете остатков.
Внедрить измерение-флаг Активность, если функционал регистра сведений критически важен.
Избегать попыток искусственного «обнуления» ресурсов — это не даст желаемого результата и приведет к избыточности данных в базе.

Помните: правильная архитектура данных на этапе проектирования — залог производительности вашей системы в будущем!