Как исправить некорректные остатки в ОСВ после прерванной свертки базы 1С?

Свертка информационной базы — это сложная и ресурсоемкая процедура, особенно когда речь идет о высоконагруженных системах с большим объемом данных. Ситуация, когда процесс прерывается на полуслове, а оборотно-сальдовая ведомость (ОСВ) начинает показывать «фантомные» остатки на 01.01.1900, является классическим симптомом нарушения логической и физической целостности таблиц итогов. Разберем детально, почему это происходит и как восстановить работоспособность базы без полного отката к архиву.

Анализируем причины: что означает этап №5 и дата 01.01.1900?

Проанализируем состояние базы через константу СтатусСверткиИнформационнойБазы. Значение ТекущийЭтапСвертки = 5 указывает на то, что система находилась в процессе удаления движений регистров и установки пометок на удаление у старых документов. Если сеанс прервался именно в этот момент, мы получаем «рассинхрон»: часть записей в регистрах накопления и бухгалтерии была удалена, а часть осталась, при этом документы-регистраторы могут быть уже помечены на удаление или вовсе отсутствовать в физических таблицах.

Появление остатков на 01.01.1900 объясняется особенностью хранения дат в СУБД (например, Microsoft SQL Server). Пустая дата в 1С (0001-01-01) при определенных сбоях или некорректных прямых запросах может интерпретироваться системой как минимально возможная дата. Если в таблицах итогов или движений появились записи с «битой» датой, ОСВ при формировании за «пустой» период (с самого начала времен) подхватит эти значения и выведет их в начало отчета.

Шаг 1: Проверка документов «Ввод остатков»

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

// Пример вызова процедур завершения свертки
ПроцедурыСверткиИБ.АктивизироватьВводОстатков();
ПроцедурыСверткиИБ.СброситьПоследовательностьПослеСвертки();

Важно убедиться, что документы ВводОстатков не только существуют, но и имеют корректные движения по всем регистрам. Если документы помечены на удаление или не проведены, ОСВ будет показывать нулевые или некорректные данные на дату свертки.

Шаг 2: Глубокий пересчет итогов через отключение

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

1. Полностью отключите использование итогов для всех регистров накопления и бухгалтерии. Это действие физически очистит таблицы _AccumRgT и _AccRgT в базе данных SQL.
2. Выполните операцию «Установить период рассчитанных итогов» на нужную дату (конец месяца, предшествующего свертке).
3. Снова включите использование итогов. Система будет вынуждена пересчитать все итоги «с нуля», опираясь исключительно на таблицы движений (документы).

Важный момент: если проблема кроется в самих записях движений (таблицы _AccumRg), то этот метод лишь зафиксирует ошибку. В таком случае потребуется поиск «битых» записей.

Шаг 3: Поэтапное Тестирование и Исправление (ТиИ)

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

1. Реиндексация таблиц информационной базы. Это поможет восстановить индексы, которые могли «полететь» при аварийном завершении фонового задания.
2. Проверка логической целостности. Выберите режим «Только отчет», чтобы понять масштаб бедствия, не внося изменений.
3. Очистка ссылок на несуществующие объекты. Это критически важно после свертки, так как в регистрах могут остаться записи, ссылающиеся на уже удаленные документы (битые ссылки в поле Регистратор).
4. Пересчет итогов (только после выполнения предыдущих пунктов).

Шаг 4: Поиск фантомных записей через SQL (для клиент-серверных баз)

Если ОСВ продолжает показывать остатки на начало 1900 года, проанализируем ситуацию на уровне СУБД. Нам нужно найти записи в регистрах, у которых период меньше даты свертки или равен «нулевой» дате. Пример логики запроса для SQL Management Studio (замените _AccumRg123 на имя таблицы вашего проблемного регистра):

-- Поиск записей с некорректной датой
SELECT * FROM _AccumRg123 
WHERE _Period < '2016-01-01 00:00:00'

Если такие записи найдены, и они не относятся к документам Ввод остатков, их необходимо удалить средствами 1С (через набор записей с отбором) или, в крайнем случае, средствами SQL (только при наличии опыта и бэкапа!).

Шаг 5: Технологический прием «Выгрузка-Загрузка»

Рассмотрим совет из сообщения №7 — выгрузку в .dt или XML. Для баз объемом более 100 Гб выгрузка в XML практически невозможна из-за ограничений памяти. Однако, стандартная выгрузка в .dt и последующая загрузка в новую чистую базу данных иногда творит чудеса. В процессе загрузки 1С полностью пересоздает структуру таблиц и индексов, что позволяет избавиться от «фантомных» записей, которые могли возникнуть в кэше или из-за физического повреждения страниц данных в SQL.

Рекомендации по завершению процесса

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

Константы.СтатусСверткиИнформационнойБазы.Установить(0);
// Или другое значение, соответствующее финалу в вашей конфигурации

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