В процессе сопровождения и администрирования баз данных «1С:Предприятие 8.3» одной из частых задач является очистка нормативно-справочной информации (НСИ). Мы регулярно объединяем дубли контрагентов, партнеров или договоров с помощью стандартных обработок вроде «Поиск и замена дублей». Однако мало кто догадывается, что такое простое действие может нарушить целостность регистров бухгалтерии на физическом уровне.
В данной статье мы подробно разберем, почему после массовой замены контрагентов (например, при переносе продаж с различных торговых точек на одного головного контрагента) программа начинает вести себя непредсказуемо: списывает партии «в минус» на забалансовом счете 004.01 («Товары, принятые на комиссию»), «не видит» остатки в оборотно-сальдовой ведомости (ОСВ) или выдает фантомные остатки по затратным счетам (например, по 26 счету). Мы проанализируем физическую структуру хранения данных 1С и изучим пошаговое руководство по исправлению этих ошибок.
Для того чтобы понять природу ошибки, рассмотрим, как платформа 1С хранит данные в СУБД (MS SQL, PostgreSQL и др.) для регистра бухгалтерии Хозрасчетный. Каждый регистр состоит из набора измерений, ресурсов и реквизитов. Одним из ключевых измерений в «1С:Бухгалтерии» является Подразделение. На некоторых счетах учет по подразделениям может быть выключен в настройках учетной политики или параметров учета.
Давайте сопоставим два состояния базы данных:
NULL (полное отсутствие данных).NULL в базу данных записывается физическая Пустая ссылка справочника — например, Справочники.ПодразделенияОрганизаций.ПустаяСсылка().Для обычного пользователя пустая ссылка и NULL выглядят одинаково — как пустое поле в отчете. Однако для СУБД и внутренних механизмов платформы 1С это принципиально разные сущности:
NULL, отчет игнорирует строки с пустой ссылкой подразделения. В результате остатки в ОСВ «пропадают».Для того чтобы убедиться в наличии поврежденных записей в регистре бухгалтерии, мы можем написать и запустить простой запрос в консоли запросов. С его помощью мы найдем строки, где измерение заполнено пустой ссылкой вместо положенного NULL (или значения Неопределено на уровне платформы):
ВЫБРАТЬ
ХозрасчетныйДвижения.Регистратор КАК ДокументРегистратор,
ХозрасчетныйДвижения.НомерСтроки КАК НомерСтроки,
ХозрасчетныйДвижения.Счет КАК СчетУчета,
ХозрасчетныйДвижения.Подразделение КАК ЗначениеПодразделения
ИЗ
РегистрБухгалтерии.Хозрасчетный КАК ХозрасчетныйДвижения
ГДЕ
ХозрасчетныйДвижения.Счет = &ПараметрСчет
И ХозрасчетныйДвижения.Подразделение <> НЕОПРЕДЕЛЕНО
И ХозрасчетныйДвижения.Подразделение = ЗНАЧЕНИЕ(Справочник.ПодразделенияОрганизаций.ПустаяСсылка)
Если этот запрос возвращает строки документов (особенно тех, в которых производилась замена контрагентов), это подтверждает физическое повреждение логической структуры регистра бухгалтерии.
Исправлять подобные ошибки вручную перепроведением документов крайне опасно и неэффективно, особенно если период уже закрыт для редактирования. Для автоматического исправления поврежденных полей мы воспользуемся штатным механизмом платформы.
Рассмотрим пошаговый алгоритм лечения базы данных:
.1cd или выгрузки в .dt). Рекомендуется сначала выполнить процедуру на копии базы данных.Администрирование — Тестирование и исправление....Выполнить и дождитесь окончания процесса. В зависимости от объема базы данных операция может занять от нескольких минут до нескольких часов.Во время логической проверки платформа обнаружит, что в поле Подразделение для счета 004.01 содержится недопустимый тип данных (пустая ссылка вместо отсутствия значения). Платформа автоматически очистит эти поля, вернув им корректное системное значение NULL. После этого проведение реализаций и списание партий восстановится в штатном режиме.
Часто после исправления логической целостности базы данных или некорректной работы обработок пользователи сталкиваются со следующей аномалией на затратных счетах (например, на счете 26 «Общехозяйственные расходы»):
Остатки) показывает зависшие суммы по подразделениям.Обороты, ОстаткиИОбороты) по тем же самым аналитикам выдают нулевые значения.Выясним причину этой проблемы. Регистр бухгалтерии на уровне СУБД состоит из двух ключевых таблиц:
При логическом исправлении или удалении документов таблицы движений очищаются, но таблицы итогов могут вовремя не обновиться. В результате в таблице итогов «зависают» фантомные остатки, которые не подкреплены реальными проводками документов. Это классический слёт (рассинхронизация) итогов.
Для исправления этой ситуации нам необходимо полностью пересчитать итоги в базе данных. Выполнить это можно двумя способами.
Мы можем запустить процедуру из того же окна Тестирования и Исправления:
Администрирование — Тестирование и исправление....Выполнить. Платформа полностью очистит таблицы итогов всех регистров накопления и регистров бухгалтерии, после чего рассчитает их заново на основе реальных физических движений.Если база данных имеет внушительный объем, и вы не хотите прерывать работу пользователей, пересчитать итоги можно выборочно для конкретного регистра в режиме «1С:Предприятие»:
Администрирование — Обслуживание.Регламентные операции и выберите гиперссылку Управление итогами.Хозрасчетный).Управление итогами и выберите команду Пересчитать итоги. При необходимости вы можете указать период, начиная с которого будет запущен пересчет.После завершения пересчета фантомные остатки на счете 26 исчезнут, и все виртуальные таблицы будут показывать одинаковые (нулевые) результаты. В завершение рекомендуется запустить обработку «Закрытие месяца» за проблемные периоды, чтобы программа корректно перераспределила и закрыла затраты на финансовый результат.