← На главную

Ситуация, когда после штатной процедуры «Тестирование и исправление» (ТиИ) в программе 1С «разлетаются» остатки по бухгалтерским счетам, часто вызывает панику у ответственных специалистов и закономерные вопросы со стороны руководства. На первый взгляд кажется, что процедура, призванная лечить базу, ее ломает. Однако в большинстве случаев происходит обратное: система приводит учет в соответствие с фактическим состоянием данных. Разберем детально, почему это происходит, как работают механизмы 1С при исправлении ошибок и почему под удар попадают именно счета взаиморасчетов.

Запускаются ли программные обработчики при тестировании и исправлении?

Один из первых вопросов, возникающих у разработчика: влияют ли на процесс изменения данных наши кастомные подписки на события или код в модулях наборов записей? Проанализируем работу платформы в режиме ТиИ. При выполнении процедур «Проверка логической целостности» и «Проверка ссылочной целостности» предопределенные процедуры ПередЗаписью или ПриЗаписи для наборов записей Регистров Бухгалтерии (и других регистров) НЕ запускаются.

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

Механизм удаления «фантомных» записей и его влияние на ОСВ

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

1. Таблицы движений (регистры): Здесь хранятся детальные записи о каждой операции (кто, когда, сколько). Каждая запись обязательно должна быть привязана к документу-регистратору.
2. Таблицы итогов: Это агрегированные данные (остатки и обороты), которые платформа использует для быстрого формирования отчетов, таких как Оборотно-сальдовая ведомость (ОСВ).

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

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

Влияние ссылочной целостности на аналитику (субконто)

Выясним причину, по которой «летят» именно счета 60 (Расчеты с поставщиками), 68 (Налоги) и 76 (Расчеты с прочими дебиторами и кредиторами). Эти счета объединяет одно — наличие обязательной и часто сложной аналитики (Контрагенты, Договоры, Документы расчетов, Виды налогов).

В настройках ТиИ для объектов с «битыми» ссылками (когда ссылка указывает на несуществующий в справочнике элемент) предусмотрено несколько вариантов действий:

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

Счета 60, 68 и 76 наиболее подвержены этому, так как по ним ведется учет в разрезе субконто, которые часто подвергаются программному изменению или некорректным переносам данных, что и порождает «битые» ссылки.

Расхождение таблиц итогов и процедура пересчета

Посмотрим на ситуацию с точки зрения хранения агрегатов. Иногда в базе данных 1С таблицы итогов «замусориваются» и перестают соответствовать реальности. При запуске тестирования и исправления система выполняет полный пересчет итогов.

Рассмотрим это на примере. Допустим, в таблице итогов по счету 60 числится остаток 1000 рублей. Но если мы сложим все физические записи движений (документы), то получим 800 рублей. До тестирования ОСВ «лгал», показывая 1000 рублей, обращаясь к таблице итогов. После ТиИ система пересчитала итоги на основе реальных движений, и в ОСВ теперь отображается честный остаток — 800 рублей. Бухгалтер видит это как «пропажу» 200 рублей, хотя на самом деле этих денег в базе в виде документов никогда и не было.

Как объяснить ситуацию ИТ-директору и бизнесу?

Для аргументированного объяснения причин изменения данных стоит использовать следующую логику:

1. Обнаружение скрытых дефектов: Тестирование и исправление не создает новые ошибки, а выявляет и устраняет ранее накопленные нарушения целостности БД.
2. Физическое отсутствие данных: Если остатки уменьшились, значит, в базе существовали записи, не подтвержденные документами (фантомы) или ссылающиеся на удаленные элементы справочников.
3. Приведение к достоверности: Состояние ОСВ после ТиИ является единственно верным и математически обоснованным состоянием текущей базы данных. До процедуры отчеты показывали недостоверную информацию из-за поврежденных индексов или итоговых таблиц.

Рекомендации по предотвращению проблем

Чтобы избежать неожиданностей при проведении профилактических работ, рекомендуем следовать определенному алгоритму:

Во-первых, перед запуском ТиИ обязательно выполните Технологический анализ бухгалтерского учета (штатный отчет в 1С:Бухгалтерии). Он покажет наличие «битых» ссылок и объектов с пометкой «Объект не найден» еще до начала исправления.

Во-вторых, всегда делайте резервную копию непосредственно перед тестированием. Если объем изменений слишком велик, лучше сначала проанализировать ошибки в копии базы.

В-третьих, если база серверная (на SQL), полезно сначала выполнить регламентные операции на уровне СУБД (обновление статистики и реиндексация), а уже потом запускать логические проверки 1С. Это поможет исключить ошибки, связанные с физическим повреждением страниц данных на диске.

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