В процессе работы с программой «1С:Бухгалтерия 3.0» специалисты иногда сталкиваются с аномальным поведением отчета «Оборотно-сальдовая ведомость» (ОСВ). Одной из наиболее загадочных проблем является появление «непобедимого» начального сальдо на счетах затрат, чаще всего на 26 счете. Суть проблемы заключается в том, что при формировании отчета за любой период, даже за годы до начала ведения учета в базе, система показывает входящий остаток. При этом стандартные инструменты, такие как «Тестирование и исправление» (ТИИ) или очистка кэша, не приносят результата. Рассмотрим подробно, почему это происходит и как исправить ситуацию.
Прежде чем приступать к радикальным мерам, проанализируем ситуацию. Фантомное сальдо — это расхождение между реальными записями в таблице движений (регистр бухгалтерии Хозрасчетный) и предварительно рассчитанными данными в таблицах итогов. В нормальных условиях эти данные должны совпадать, но из-за сбоев при обновлении, некорректного выключения питания или ошибок платформы итоги могут «зависнуть».
Для начала разберем, что именно нужно проверить в первую очередь:
01.01.0001 или из далекого будущего. Такие записи не видны в стандартных интервалах отчета, но влияют на расчет остатков.Остатки показывает сумму, а запрос к таблице ДвиженияССубконто за этот же период пуст — мы имеем дело с битыми итогами.Если стандартное ТИИ через конфигуратор не помогло, попробуем запустить пересчет итогов программно. Это можно сделать с помощью внешней обработки или через «Групповое изменение реквизитов» (выполнив произвольный код). Разберем пример кода, который принудительно инициирует обновление данных в регистре Хозрасчетный.
Рассмотрим следующий фрагмент кода:
// Полный пересчет всех итогов регистра
РегистрыБухгалтерии.Хозрасчетный.ПересчитатьИтоги();
// Обновление текущих итогов на актуальную дату
РегистрыБухгалтерии.Хозрасчетный.ПересчитатьТекущиеИтоги();
// Пересчет за конкретный период, где наблюдается проблема
// Например, если сальдо появилось в 2021 году
РегистрыБухгалтерии.Хозрасчетный.ПересчитатьИтогиЗаПериод('20210101', '20211231');
Этот метод более глубоко воздействует на базу данных, чем обычная галочка в ТИИ, так как методы ПересчитатьИтоги() инициируют низкоуровневые процедуры СУБД по очистке и заполнению итоговых таблиц. Для выполнения этой процедуры без ручного написания программного кода можно использовать обработку для пересчета итогов регистров с логированием.
Выясним причину, по которой ТИИ может игнорировать ошибку. Стандартный механизм тестирования часто проверяет только те периоды, которые лежат в диапазоне установленной даты актуальности итогов. Если «мусорная» запись находится за пределами этого диапазона, она остается нетронутой.
Разберем самый эффективный способ решения проблемы, который помог многим пользователям. Нам необходимо изменить границы периода итогов в пользовательском режиме:
01.01.2000).В этот момент платформа 1С выполняет физическое удаление таблиц итогов за старые периоды и их полную перестройку. Именно это действие чаще всего окончательно «побеждает» фантомные суммы на 26 счете.
Если база работает на MS SQL Server и предыдущие шаги не помогли, проанализируем ситуацию на уровне СУБД. Проблема может крыться в основной таблице движений, где записи существуют, но не привязаны к регистратору (битые записи) или имеют некорректные значения в полях разделителей данных.
Проанализируем структуру: данные регистра Хозрасчетный хранятся в таблице с префиксом _AccRg. Мы можем выполнить запрос к SQL-таблице, чтобы найти записи по счету 26, которые не отображаются в интерфейсе 1С. Однако стоит помнить, что любое прямое изменение данных в SQL крайне опасно и должно выполняться только опытным администратором после создания резервной копии.
Посмотрим, какие еще факторы могут влиять на 26 счет:
NULL значениями в полях аналитики, что сводит с ума механизм расчета итогов.Подведем итог. Если вы столкнулись с «глюком» ОСВ по 26 счету, не спешите переустанавливать платформу или выгружать базу в dt. Последовательно выполните действия:
РегистрыБухгалтерии.Хозрасчетный.ПересчитатьИтоги().Как показывает практика, именно принудительное смещение границы итогов заставляет систему физически очистить кэшированные суммы в таблицах базы данных и сформировать корректную картину бухгалтерского учета.