Работа с крупными файловыми базами (от 10 ГБ и выше) в современных конфигурациях, таких как 1С:Комплексная автоматизация 2.4 или 1С:ERP, часто сопряжена с техническими рисками. Одной из наиболее серьезных проблем является «разрушение» регистров бухгалтерии, которое проявляется в виде задвоения оборотов в ОСВ, пустых карточек счетов при наличии движений и ошибок уникальности записей. В этой статье мы подробно разберем, как диагностировать подобные сбои и какими методами восстановить работоспособность системы, если штатные средства не помогают сразу.
Проанализируем ситуацию: при достижении базой определенного объема, файловая СУБД 1CD начинает испытывать трудности с индексацией. Основное ограничение файлового варианта заключается не в общем размере файла базы данных, а в размере каждой конкретной таблицы или её индекса. Для формата 8.3 это ограничение составляет 4 ГБ на одну таблицу. В конфигурации КА 2.4 таблицы итогов и значений субконто регистра бухгалтерии (такие как AccRgED) растут экспоненциально.
Рассмотрим конкретную ошибку: «В таблице AccRgED обнаружены неуникальные записи». Таблица AccRgED (Extra Dimensions) хранит аналитику по субконто. Когда в ней появляются дубли ключей, система перестает корректно собирать итоги. В результате в Оборотно-сальдовой ведомости мы видим задвоенные суммы, хотя в самих документах проводки выглядят корректно. Это происходит потому, что отчеты строятся не по физическим записям движений, а по предварительно рассчитанным таблицам итогов, которые и оказываются повреждены.
Первым делом всегда следует использовать встроенные механизмы платформы. Разберем правильную последовательность действий при возникновении ошибок уникальности:
Если ТИИ выдает сообщения об исправлении неуникальных записей в таблице AccRgED60004 (или аналогичных), это хороший знак. Однако, как показывает практика, после этого ОСВ может продолжать «врать». Это происходит из-за того, что исправленные записи не всегда автоматически синхронизируются с рассчитанными итогами.
Многие специалисты ошибочно полагают, что выгрузка и загрузка базы через .dt файл автоматически пересчитывает все итоги. Проанализируем это заблуждение: в последних версиях платформы 8.3 механизм выгрузки может сохранять текущее состояние таблиц итогов для ускорения последующей загрузки. Поэтому после ТИИ необходимо выполнить принудительный пересчет:
Перейдем в режим 1С:Предприятие, откроем Функции для технического специалиста — Стандартные — Управление итогами. Здесь следует отключить использование итогов для регистра Хозрасчетный, а затем включить их снова. Это действие инициирует полную очистку физических таблиц итогов и их перезаполнение на основе записей регистра движений. Рассмотрим пример программного управления итогами, если интерфейсный метод недоступен:
РегистрыБухгалтерии.Хозрасчетный.УстановитьИспользованиеИтогов(Ложь);
// Выполняем запись изменений
РегистрыБухгалтерии.Хозрасчетный.УстановитьИспользованиеИтогов(Истина);
// Платформа запустит фоновое задание пересчета
Если повреждения базы слишком глубокие (например, chdbfl продолжает ругаться даже после ТИИ), лучшим решением будет использование архивной копии. Допустим, у нас есть копия от числа X, а текущая дата — Y. Нам нужно перебросить документы за этот период.
Разберем, почему стандартная Конвертация данных 2.1 может «вылетать» на тяжелых конфигурациях типа КА 2.4. Это связано с огромным объемом метаданных, которые не помещаются в оперативную память 32-битного конфигуратора при выгрузке описания конфигурации. В этом случае мы рекомендуем использовать обработку «Выгрузка и загрузка данных XML». Она работает напрямую с объектами, не требуя создания сложных правил обмена.
Часто после успешной загрузки документов через XML-файл пользователи сталкиваются с тем, что документы в базе есть (их можно найти через поиск ссылок или консоль запросов), но они отсутствуют в журналах документов (например, в журнале документов продажи). Выясним причину этого явления.
В современных конфигурациях на базе 1С:ERP 2.0 (КА 2.4, УТ 11) списки документов строятся не динамическим считыванием таблиц самих документов, а по специальному вспомогательному регистру сведений РеестрДокументов. Если вы переносили только сами объекты (например, РеализацияТоваровУслуг), записи в этом регистре могли не создаться автоматически. Чтобы документы «появились» в журналах, выполним следующие действия:
РеестрДокументов запросом.
ДокументыОбъект = Документы.РеализацияТоваровУслуг.Выбрать(НачалоПериода, КонецПериода);
Пока ДокументыОбъект.Следующий() Цикл
Объект = ДокументыОбъект.ПолучитьОбъект();
// Иногда достаточно просто вызвать Записать() в режиме ОбменДанными.Загрузка = Истина
Объект.ОбменДанными.Загрузка = Истина;
Объект.Записать();
КонецЦикла;
Подведем итог нашему исследованию. Для восстановления «поехавшей» файловой базы КА 2.4 необходимо применить комплексный подход: исправление физической структуры (ТИИ), логическое обновление итогов и синхронизация вспомогательных регистров (Реестр документов). Рассмотрим главные выводы:
Помните, что перед любыми манипуляциями с таблицами итогов или тестированием базы обязательно создание резервной копии. Работа с регистрами бухгалтерии в крупных базах требует терпения, так как пересчет итогов может занимать длительное время, но это единственный способ гарантировать достоверность финансовой отчетности.