Каждый технический специалист или опытный бухгалтер в среде «1С:Предприятие» рано или поздно сталкивается с загадочным поведением базы данных. Одна из таких крайне неприятных ситуаций — внезапное исчезновение документов из журналов (например, из списка «Банковские выписки»), хотя физически документы остаются в базе данных, их проводки и движения не нарушены, а прямым запросом к СУБД или через универсальный отчет их можно без проблем открыть. Особенно часто этот симптом проявляется после выполнения регламентного Тестирования и исправления (ТИИ) или очередного обновления конфигурации.
В этой статье мы подробно разберем, почему возникает этот сбой, как устроена связь между физическими таблицами документов, расширениями и журналами, а также рассмотрим пошаговое руководство по гарантированному восстановлению видимости документов без потери важных пользовательских данных.
Для того чтобы понять природу этой ошибки, нам необходимо заглянуть «под капот» платформы «1С:Предприятие 8.3». Рассмотрим, каким образом функционирует журнал документов Банковские выписки. На самом деле этот журнал в типовых конфигурациях (таких как «Бухгалтерия предприятия 3.0», «Комплексная автоматизация» или «ERP») строится на базе общего журнала документов Деньги.
Журнал документов в СУБД — это отдельная индексированная таблица (в терминах SQL она обычно имеет префикс _DocumentJournal). Сама по себе эта таблица не содержит детальных данных документов, а лишь хранит ссылки на них, даты, номера, проведенность и ключевые реквизиты индексации для быстрого построения динамических списков. Когда пользователь открывает журнал банковских выписок, платформа делает запрос именно к этой индексной таблице, а не сканирует тяжелые таблицы документов Списание с расчетного счета и Поступление на расчетный счет напрямую.
Теперь проанализируем, что происходит, когда в базу данных внедряются расширения конфигурации. Если разработчик заимствует стандартный документ (например, СписаниеСРасчетногоСчета) в расширение для того, чтобы добавить новые реквизиты, платформа вынуждена изменить структуру таблиц СУБД:
_Document471) создается дополнительная суррогатная таблица с суффиксом _X1 (например, _Document471_X1). В ней физически сохраняются значения тех реквизитов, которые были добавлены через расширение.Деньги разрушается.Во время запуска утилиты Тестирование и исправление платформа обнаруживает эти расхождения. Она видит, что связи между метаданными нарушены, считает индексные записи в журнале поврежденными и просто вычищает строки документов из таблицы журнала документов, оставляя при этом сами физические документы нетронутыми в таблицах документов. В итоге бухгалтер открывает журнал выписок и видит пустой список, хотя баланс сходится, проводки активны, а отчет по счету 51 показывает корректные обороты.
Дополнительно эта проблема усугубляется сбоями в служебных регистрах сведений, таких как ДанныеПервичныхДокументов и ЖурналИзмененияДокументов, которые используются в управляемом интерфейсе для оптимизации отображения данных.
---
Прежде чем приступать к лечению базы данных, нам необходимо убедиться, что мы столкнулись именно с этой проблемой. Для этого проведем диагностику с помощью несложного запроса. Мы можем запустить обработку «Консоль запросов» и выполнить два простых обращения к базе данных.
Сначала проверим физическое наличие самих документов в базе за определенный период (когда они «пропали»):
ВЫБРАТЬ
Ссылка КАК ДокументСсылка,
Проведен,
ПометкаУдаления,
Дата,
Номер
ИЗ
Документ.СписаниеСРасчетногоСчета
ГДЕ
Дата МЕЖДУ &НачалоПериода И &КонецПериода
Если этот запрос возвращает все наши документы, значит, физически они целы. Теперь выполним второй запрос — непосредственно к журналу документов Деньги, который отвечает за вывод информации в банковские выписки:
ВЫБРАТЬ
Ссылка КАК ДокументСсылка,
Дата,
Номер,
ТипЗначения(Ссылка) КАК ТипДокумента
ИЗ
ЖурналДокументов.Деньги
ГДЕ
Дата МЕЖДУ &НачалоПериода И &КонецПериода
И ТипЗначения(Ссылка) = ТИП(Документ.СписаниеСРасчетногоСчета)
Если первый запрос выводит документы, а второй по тем же самым документам возвращает пустой результат, диагноз поставлен точно: нарушена регистрация документов в журнале из-за конфликта реструктуризации расширения.
---
Поскольку проблема кроется в заимствовании документа расширением, для исправления ситуации нам придется временно исключить этот документ из расширения или полностью удалить расширение. Внимание! Если в расширении созданы собственные уникальные реквизиты этого документа, в которых пользователи уже успели заполнить важные данные, простое удаление расширения безвозвратно уничтожит эти колонки в СУБД (те самые таблицы с суффиксом _X1).
Рассмотрим, как правильно обезопасить данные перед процедурой восстановления:
Выгрузка и загрузка данных XML. Выполните выгрузку документов Списание с расчетного счета и Поступление на расчетный счет в файл. Данная обработка умеет корректно выгружать свойства объектов вместе с реквизитами расширений.Конфигурация -> Расширения конфигурации).СписаниеСРасчетногоСчета (и/или ПоступлениеНаРасчетныйСчет) и удалите его из метаданных расширения. Если расширение не критично или полностью завязано на эти документы — временно удалите само расширение из списка.F7), согласившись с изменениями структуры метаданных. На данном этапе физические таблицы СУБД будут приведены к типовому стандартному виду без суффиксов расширений.---
Теперь наша задача — заставить платформу «1С:Предприятие» заново просканировать физические таблицы документов и восстановить отсутствующие индексные записи в таблице журнала документов Деньги. Сделать это вручную невозможно, но утилита тестирования и исправления отлично справляется с этой задачей при правильной настройке параметров.
Разберем по шагам, как настроить и запустить процесс:
Администрирование -> Тестирование и исправление....При наличии ссылок на несуществующие объекты установите значение Создавать объекты;При частичной потере данных объектов также установите значение Создавать объекты.Если оставить эти параметры в значении "Очищать ссылки" или "Ничего не предпринимать", платформа не сможет принудительно перерегистрировать утерянные связи документов с журналом и служебными регистрами.
После завершения тестирования платформа выведет отчет о проделанной работе. В этом отчете вы увидите многочисленные строки следующего содержания:
Проверка логической целостности. Документ.ПоступлениеНаРасчетныйСчет ...
ОбщийРеквизит.ОбластьДанныхОсновныеДанные = 0
Документ не зарегистрирован в журнале Деньги. Создана новая запись в журнале.
Это верный признак того, что утерянные связи успешно восстановлены, платформа обнаружила физические документы и заново прописала их индексы в системный журнал.
---
Теперь нам необходимо вернуть систему в рабочее состояние для пользователей:
Списание с расчетного счета и Поступление на расчетный счет успешно отображаются в журнале Банковские выписки.F7.Выгрузка и загрузка данных XML в режиме предприятия и загрузите сохраненный ранее файл. Данные расширения безболезненно запишутся поверх восстановленных документов без нарушения целостности журнала.---
Для предотвращения повторения этой коварной проблемы мы рекомендуем придерживаться нескольких простых правил при администрировании и разработке в среде 1С: