Каждый специалист, работающий с базами данных на платформе 1С:Предприятие 7.7, рано или поздно сталкивается с загадочными техническими сбоями. Один из самых известных и пугающих симптомов — внезапное появление астрономической суммы 9 999 999 999 999.99 в дебете и аналогичной отрицательной суммы в кредите в оборотно-сальдовой ведомости (ОСВ), например, по счету 51 ("Расчетные счета") или субконто Банковские счета.
В этой статье мы подробно разберем природу этого явления, выясним причины его возникновения и рассмотрим пошаговые методы устранения проблемы — от простых профилактических мер до глубокого восстановления поврежденных таблиц базы данных.
Для начала проанализируем, откуда берется именно это число. В платформе 1С 7.7 для хранения денежных сумм в таблицах базы данных (как в формате DBF, так и на MS SQL Server) используется фиксированный тип данных Numeric(15,2). Это означает, что под число отводится ровно 15 знаков, из которых 2 знака зарезервированы под дробную часть (копейки).
Число 9 999 999 999 999.99 (9 триллионов 999 миллиардов...) представляет собой **максимально возможное число**, которое физически способна вместить ячейка памяти данного формата. Когда в системе происходит математический сбой (например, деление на ноль в ядре платформы, переполнение буфера или чтение поврежденных данных), программа не может корректно вычислить итог и записывает в таблицу предопределенный верхний лимит — так называемый "потолок" разрядности.
Появление подобных "девяток" в ОСВ на начало периода или при проведении документов типа Выписка всегда указывает на техническое повреждение структуры данных. Рассмотрим наиболее частые причины:
.cdx): В файловых базах данных (DBF) индексы отвечают за быструю выборку и связь между таблицами. Если в процессе записи или проведения документа произошло аварийное завершение работы компьютера (отключение электроэнергии, сетевой сбой, зависание), индексы "сбиваются" и начинают указывать на пустые или некорректные области физической памяти. При расчете итогов платформа считывает этот "мусор" и преобразует его в максимальное число.1SBKTTL (итоги по счетам) и 1SBKTTLC (итоги по субконто). Если транзакция записи проводок прервалась на середине, контрольная сумма в этих таблицах искажается.Выписка образуется ссылка на несуществующий элемент справочника. В интерфейсе это отображается как <Объект не найден>. Попытка рассчитать сальдо по поврежденной аналитике приводит к переполнению регистра.Важное предупреждение: Перед началом любых восстановительных работ в базе данных обязательно создайте её резервную копию! Скопируйте всю папку с базой данных на внешний накопитель или в архив. Все операции должны производиться строго в монопольном режиме, когда в программе нет других пользователей.
Начнем с самого простого и безопасного шага, который рекомендуют опытные специалисты на форумах. Очень часто для исправления ситуации достаточно заставить платформу обновить таблицы итогов штатными средствами.
Если этот метод помог и девятки исчезли, значит, имел место легкий логический сбой при записи документов. Если же система выдала ошибку или остатки не изменились, переходим к более глубоким методам.
Если проблема вызвана повреждением индексов в DBF-версии базы, стандартные процедуры могут не сработать. Нам потребуется полностью обновить индексную карту системы.
*.cdx. Это служебные индексные файлы, в них не хранятся сами данные, поэтому их удаление абсолютно безопасно.*.cdx и удалим их (или временно перенесем в отдельную пустую папку за пределами базы).После автоматического восстановления индексов откроем ОСВ по счету 51 и проверим остатки.
Этот комплексный инструмент позволяет исправить физические ошибки структуры таблиц и восстановить нарушенные связи между объектами метаданных.
Бывают ситуации, когда повреждения в таблицах предварительно рассчитанных итогов настолько серьезны, что штатный пересчет просто пропускает их или завершается аварийно. В этом случае мы можем применить "хирургический" метод — принудительно удалить таблицы итогов и воссоздать их "с нуля" на основе первичного журнала проводок (таблица 1SENTRY), который обычно остается целым.
1SBKTTL.DBF и 1SBKTTL.CDX (таблица итогов по счетам)1SBKTTLC.DBF и 1SBKTTLC.CDX (таблица итогов по субконто)Этот метод гарантированно очищает базу от любых "фантомных" сумм и зависших остатков.
Если "девятки" появляются только после проведения конкретного документа Выписка во втором квартале, проблема кроется в заполнении самого документа. Давайте локализуем его.
Проанализируем журнал документов. Попробуем поочередно распроводить выписки за проблемный период. Если после распроведения определенной выписки остатки на начало следующего дня пришли в норму, значит, мы нашли источник сбоя. Откроем этот документ и проверим:
Для автоматизации поиска пустых или некорректных субконто в документах выписок мы можем использовать несложный программный код. Напишем простую обработку, которая перебирает документы за период и проверяет заполнение аналитики:
Процедура НайтиОшибкиВВыписках()
Док = СоздатьОбъект("Документ.Выписка");
Док.ВыбратьДокументы(НачДата, КонДата);
Пока Док.ПолучитьДокумент() = 1 Цикл
Если Док.Проведен() = 1 Тогда
Док.ВыбратьСтроки();
Пока Док.ПолучитьСтроку() = 1 Цикл
// Проверяем заполнение банковского счета
Если ПустоеЗначение(Док.Субконто1) = 1 Тогда
Сообщить("Внимание! В документе " + Док + " в строке " + Док.НомерСтроки + " не заполнено Субконто1!");
КонецЕсли;
КонецЦикла;
КонецЕсли;
КонецЦикла;
КонецПроцедуры
Запустим данную обработку. При обнаружении проблемных строк удалим их, перенаберем вручную (не копированием!) и заново проведем документ.
Применяя эти шаги последовательно, мы гарантированно избавимся от некорректного отображения сумм и вернем учет в рабочее русло.