При проведении регулярного обслуживания базы данных «1С:Бухгалтерия» через процедуру Тестирования и исправления (ТиИ) администраторы и программисты часто сталкиваются с сообщением об ошибке логической целостности. Текст ошибки выглядит следующим образом:
Проверка логической целостности. РегистрБухгалтерии.Хозрасчетный.Ресурс.СуммаНУ Операция 0Р00-000015 от 06.05.2018 23:59:59:1 ОбщийРеквизит.ОбластьДанныхОсновныеДанные = 0 Значение должно быть NULL.
В этой статье мы подробно разберем, почему возникает данная ошибка, насколько она критична для ведения учета, и рассмотрим пошаговые методы её устранения.
---
Первое, на что обращают внимание пользователи при анализе лога ТиИ — это строка ОбщийРеквизит.ОбластьДанныхОсновныеДанные = 0. Из-за этого возникает ложное предположение, что проблема связана с механизмом разделения данных (технологией фреша/облачного сервиса) или неверным типом общего реквизита.
Проанализируем реальное положение дел. Строка с упоминанием общего реквизита — это всего лишь контекстное указание области данных, в которой СУБД обнаружила проблемную запись. В конфигурациях, созданных на базе Библиотеки стандартных подсистем (БСП), поле области данных присутствует в таблицах физически всегда, даже если разделение отключено. Значение = 0 говорит о том, что запись находится в стандартной (основной) области данных.
Сама же ошибка локализована в объекте РегистрБухгалтерии.Хозрасчетный.Ресурс.СуммаНУ. Платформа сообщает, что в проводке конкретного документа (в нашем примере — Операция 0Р00-000015) значение ресурса налогового учета СуммаНУ заполнено числом (чаще всего обычным математическим нулем 0), тогда как на уровне базы данных там обязан храниться пустой тип — NULL.
---
Для того чтобы понять природу этой ошибки, вспомним, как устроена архитектура регистров бухгалтерии в платформе «1С:Предприятие 8». Хранение числовых ресурсов (таких как СуммаНУ, ВалютнаяСумма или Количество) напрямую зависит от настроек конкретного счета в Плане счетов:
0).СуммаНУ физически не должен существовать. На уровне СУБД (MS SQL, PostgreSQL и др.) в эту ячейку записывается значение NULL.Если в поле, которое по правилам метаданных должно иметь значение NULL, оказывается записано число (даже нулевое), платформа расценивает это как нарушение логической целостности базы данных.
---
Рассмотрим основные сценарии, при которых в базе данных появляются подобные «висячие» нулевые значения вместо положенных NULL:
ОбменДанными.Загрузка = Истина, обходятся стандартные платформенные проверки. Если обработка явно записывает нулевые значения в ресурс без оглядки на признаки счета, возникает данная коллизия.---
Данная ошибка не является критичной для повседневной работы пользователей:
NULL в пустую ячейку или математический ноль.Но есть важные скрытые риски. Несоответствие типов данных в СУБД может приводить к некорректной работе виртуальных таблиц (например, при получении оборотов и остатков за периоды). Это выражается в «раздвоении» строк в сложных отчетах или возникновении непредвиденных ошибок при последующих обновлениях конфигурации. Поэтому исправлять логическую целостность базы данных нужно обязательно.
---
Рассмотрим три основных способа исправления ошибки: от автоматического до ручного и программного.
Это рекомендуемый и самый безопасный способ для большинства пользователей.
Важно: Перед выполнением любых административных процедур обязательно создайте резервную копию (бэкап) информационной базы!
NULL.Если база данных имеет огромный объем (сотни гигабайт) и полный запуск тестирования занимает слишком много времени, а ошибка зафиксирована всего по одной-двум операциям, можно исправить проблему локально в режиме «1С:Предприятие».
NULL вместо нуля.Если документов с ошибками много, а запускать длительное ТиИ нет возможности, мы можем написать простую обработку, которая точечно исправит набор записей регистра бухгалтерии без полного перепроведения документов (что важно для закрытых периодов).
Посмотрим на пример кода, который считывает движения по проблемному регистратору, проверяет заполненность ресурса СуммаНУ для счетов без признака налогового учета и принудительно устанавливает значение NULL:
// Ссылка на проблемный документ, полученная, например, через поиск по номеру и дате
ДокументСсылка = Документы.ОперацияБух.НайтиПоНомеру("0Р00-000015", Дата("20180506235959"));
Если НЕ ДокументСсылка.Пустая() Тогда
// Создаем набор записей регистра бухгалтерии с отбором по нашему регистратору
НаборЗаписей = РегистрыБухгалтерии.Хозрасчетный.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Установить(ДокументСсылка);
НаборЗаписей.Прочитать();
БылиИзменения = Ложь;
Для Каждого Запись Из НаборЗаписей Цикл
// Проверяем счет дебета
Если ЗначениеЗаполнено(Запись.СчетДт) Тогда
Если НЕ Запись.СчетДт.НалоговыйУчет И Запись.СуммаНУ <> Неопределено И Запись.СуммаНУ <> NULL Тогда
Запись.СуммаНУ = NULL;
БылиИзменения = Истина;
КонецЕсли;
КонецЕсли;
// Проверяем счет кредита
Если ЗначениеЗаполнено(Запись.СчетКт) Тогда
Если НЕ Запись.СчетКт.НалоговыйУчет И Запись.СуммаНУ <> Неопределено И Запись.СуммаНУ <> NULL Тогда
Запись.СуммаНУ = NULL;
БылиИзменения = Истина;
КонецЕсли;
КонецЕсли;
КонецЦикла;
// Записываем изменения обратно в базу данных без прохождения лишних проверок проведения
Если БылиИзменения Тогда
НаборЗаписей.ОбменДанными.Загрузка = Истина;
НаборЗаписей.Записать();
Сообщить("Движения документа успешно скорректированы!");
Иначе
Сообщить("Корректировка не требуется, ошибки не найдены.");
КонецЕсли;
КонецЕсли;
Этот программный метод позволяет быстро и безопасно устранить точечные расхождения в структуре данных СУБД, не затрагивая при этом логику закрытия месяцев и не изменяя последовательность проведения документов.