Почему не сходятся суммы в таблицах движений и итогов регистра 1С 7.7?

При прямой работе с базой данных 1С:Предприятия 7.7 на уровне СУБД MS SQL Server разработчики и администраторы часто обращаются к физическим таблицам регистров. Нередко возникает ситуация, когда математика регистра нарушается: в таблице движений (RA) зафиксировано множество приходных записей, а в таблице итогов (RG) остаток оказывается практически нулевым или вовсе отсутствует. Разберем внутреннее устройство регистров накопления 1С 7.7, выясним причину такого расхождения и рассмотрим методы восстановления целостности данных.

Математика хранения остатков и движений в 1С 7.7

Для понимания сути проблемы проанализируем структуру хранения данных регистра остатков в СУБД:

1. Таблица движений (RAxxxx): хранит детальные записи каждого документа. Поле DEBKRED определяет направление движения (0 — приход, 1 — расход), а поля SPxxxx содержат значения ресурсов.
2. Таблица итогов (RGxxxx): хранит рассчитанные входящие остатки на начало каждого расчетного периода (по умолчанию — первое число месяца, 00:00:00, поле PERIOD).
3. Точка Актуальности (ТА): глобальная позиция во времени, до которой рассчитаны все итоги. Остаток на ТА формируется как сумма остатка из RG на начало текущего месяца плюс/минус движения из RA от начала месяца до момента ТА.

Если Точка Актуальности актуальна, суммарный оборот за всю историю прихода и расхода теоретически должен соответствовать остатку на ТА:

-- Проверка движений за всю историю
SELECT SUM(CASE WHEN debkred = 0 THEN spXXXX ELSE -1 * spXXXX END) AS TotalFromRA
FROM RAXXXX;

-- Проверка остатков в таблице итогов за текущий период
SELECT SUM(spXXXX) AS TotalFromRG
FROM RGXXXX
WHERE period = @CurrPeriod;

Если в таблице RA присутствуют сотни записей с ненулевыми ресурсами, а в RG строк почти нет или сумма не сходится, имеет место нарушение целостности информационной базы.

Причины возникновения ошибки

Выясним основные факторы, приводящие к расхождению данных между RA и RG:

1. Жестко закодированные регламентные задания SQL (SQL Jobs): ядро 1С 7.7 не удаляет строки из таблицы RG при обнулении остатка, что со временем раздувает базу. Для оптимизации администраторы создают SQL-задания, удаляющие записи, где ресурсы равны нулю. Если в конфигураторе к регистру добавляется новый ресурс, в SQL создается новое поле (например, SP9999). Если текст SQL-скрипта не был обновлен, условие вида WHERE SP1 = 0 AND SP2 = 0 признает строку пустой и удалит ее, даже если по новому ресурсу SP9999 там был ненулевой остаток.
2. Изменение структуры метаданных без пересчета итогов: добавление измерений или смена периодичности регистра без полного регламентного пересчета.
3. Прямые вставки данных (Direct SQL): ручное добавление строк в RA внешними скриптами без синхронного обновления таблицы итогов RG и системной таблицы _1SSYSTEM.
4. Движения за Точкой Актуальности: документы, проведенные будущей датой (позже ТА), не попадают в расчет текущих итогов.

Способы исправления и восстановления итогов

Рассмотрим штатные и программные варианты восстановления правильных значений в таблице итогов.

1. Штатный пересчет итогов в Конфигураторе:

   Откроем информационную базу в режиме Конфигуратора, перейдем в меню Администрирование → Тестирование и исправление ИБ. В списке тестов оставим флаг исключительно на пункте «Пересчет итогов» и запустим выполнение. Платформа полностью очистит таблицы RG и заново рассчитает их на основе всех движений из RA.

2. Запуск пересчета в пакетном режиме:

   Для автоматизации ночного восстановления базы запустим Конфигуратор с параметром командной строки /T:

   1cv7.exe config /D"C:\Bases\Trade" /N"Admin" /P"Password" /T
3. Программный пересчет средствами встроенного языка 1С:

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

   ПересчитатьИтоги();

Рекомендации по безопасной оптимизации таблиц итогов

Если для ускорения работы базы используется внешняя процедура очистки пустых строк в SQL, исключим человеческий фактор:

1. Динамическое формирование условий SQL: скрипт очистки должен считывать системные представления INFORMATION_SCHEMA.COLUMNS или sys.columns, автоматически собирая проверку по всем колонкам, начинающимся на SP. Это исключит удаление данных при добавлении новых ресурсов в метаданные.
2. Монопольный режим выполнения: любые регламентные операции над таблицами RG и RA должны выполняться в технологическое окно при отсутствии активных пользователей, чтобы избежать взаимных блокировок (Deadlocks) с транзакциями проведения документов.