После проведения обновления нетиповой или кастомизированной конфигурации 1С программисты и администраторы иногда сталкиваются со странным поведением системы: открывая журнал документов (например, Кадровый учет), они обнаруживают, что из него исчезли все документы до даты обновления. При этом новые документы создаются, проводятся и отлично отображаются в журнале. Более того, если открыть стандартный список конкретного вида документов (например, через все функции или форму списка документов Прием на работу), то все «пропавшие» документы на месте — они физически существуют в базе данных, они проведены и не повреждены.
В этой статье мы подробно разберем, почему возникает этот сбой, как устроены журналы документов на уровне базы данных СУБД и какими способами можно быстро восстановить отображение исторических данных.
Для того чтобы эффективно решить проблему, нам необходимо понять внутреннее устройство платформы 1С. Журнал документов — это не просто виртуальное представление, собирающее данные «на лету» из разных таблиц. С технической точки зрения журнал документов в 1С хранит так называемые вторичные данные.
В СУБД (будь то Microsoft SQL Server, PostgreSQL или файловый вариант базы 1Cv8.1CD) под каждый журнал создается собственная физическая таблица с именем вида _DocumentJournal[Индекс]. Когда вы записываете или проводите любой документ, входящий в этот журнал, платформа параллельно делает запись в таблицу этого документа (например, _Document[Индекс]) и дублирует ключевые индексируемые реквизиты (Дата, Номер, Ссылка, Проведен, а также графы журнала) в таблицу соответствующего журнала документов.
При обновлении конфигурации, когда меняется состав граф журнала, типы входящих реквизитов или список регистрируемых документов, платформа должна выполнить реструктуризацию таблицы журнала — пересоздать её на уровне СУБД и заново наполнить историческими данными. Если во время этого процесса произошел микросбой сети, транзакция СУБД откатилась или возникли ошибки кэширования метаданных, то таблица журнала создается пустой или заполняется некорректно. В результате новые документы в нее пишутся без проблем, а связи со старыми документами оказываются разорванными.
Рассмотрим четыре проверенных способа, как восстановить консистентность таблиц и вернуть пропавшие документы в журнал.
Это самый быстрый, изящный и безопасный способ, который заставляет СУБД полностью пересоздать физическую таблицу журнала документов и принудительно перезаполнить её данными из первоисточников (таблиц документов).
Разберем этот метод по шагам:
.dt или бэкап средствами СУБД).Документы -> Журналы документов и найдите ваш проблемный журнал (например, КадровыйУчет).ВременнаяГрафаРеструктуризации. Укажите для нее любой простой тип данных (например, Число или Строка) и не привязывайте к ней реквизиты документов._DocumentJournal. В ходе этого процесса СУБД считает все документы из базы данных и запишет их актуальные свойства в обновленную таблицу журнала.ВременнаяГрафаРеструктуризации и еще раз нажмите F7 для применения изменений.После выполнения этой процедуры зайдите в режим предприятия и проверьте журнал документов — все исторические записи гарантированно вернутся на свои места.
Если по каким-то причинам вы не можете вносить изменения в структуру метаданных конфигурации (например, конфигурация находится на строгой поддержке без возможности изменения), то можно обновить таблицу журнала программным путем. Так как запись в журнал происходит в момент физической записи самого документа, нам достаточно программно перезаписать «пропавшие» документы.
Для этого мы можем использовать внешнюю обработку (например, «Групповая обработка справочников и документов») или написать простой скрипт в консоли кода. Нам нужно отобрать документы нужного типа (например, ПриемРаботниковВОрганизацию), у которых дата меньше даты обновления, получить их объекты и записать в режиме обычной записи (без перепроведения, чтобы не нарушить движения регистров и не заблокировать базу данных).
Рассмотрим пример кода:
// Определяем дату, до которой документы пропали из журнала (дата отсечки)
ДатаОтсечки = '20190916000000'; // Пример даты: 16.09.2019
// Выбираем документы, которые физически есть в базе, но пропали из журнала
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ПриемРаботников.Ссылка КАК Ссылка
|ИЗ
| Документ.ПриемРаботниковВОрганизацию КАК ПриемРаботников
|ГДЕ
| ПриемРаботников.Дата < &ДатаОтсечки";
Запрос.УстановитьПараметр("ДатаОтсечки", ДатаОтсечки);
РезультатЗапроса = Запрос.Выполнить();
ВыборкаДетальныеЗаписи = РезультатЗапроса.Выбрать();
ПроводкаРазрешена = Истина;
Пока ВыборкаДетальныеЗаписи.Следующий() Цикл
// Получаем объект документа для перезаписи
ДокОбъект = ВыборкаДетальныеЗаписи.Ссылка.ПолучитьОбъект();
Попытка
// Записываем документ БЕЗ проведения, чтобы обновить только его представление в журнале
ДокОбъект.Записать(РежимЗаписиДокумента.Запись);
Сообщить("Успешно обновлен в журнале документ: " + ДокОбъект);
Исключение
Сообщить("Ошибка записи документа " + ДокОбъект + ": " + ОписаниеОшибки(), СтатусСообщения.Важное);
КонецПопытки;
КонецЦикла;
Этот способ абсолютно безопасен для ведения учета, так как режим РежимЗаписиДокумента.Запись не очищает и не изменяет движения по регистрам бухгалтерии или накопления, а лишь обновляет заголовочные сведения документа и принудительно регистрирует его в таблицах связанных журналов.
Стандартный механизм проверки целостности базы данных также умеет восстанавливать таблицы журналов. Однако простое «исправление ошибок» без изменения настроек по умолчанию часто не решает проблему, так как платформа пропускает физическую пересборку некоторых индексов.
Чтобы запустить глубокое восстановление таблиц журналов, выполните следующие действия:
Администрирование -> Тестирование и исправление....Очищать ссылки или Не изменять (в зависимости от вашей политики работы со "битыми" ссылками).Бывают исключительные ситуации, когда на самом сервере базы данных в таблицах журналов все записи присутствуют, но на рабочих местах пользователей или на сервере приложений 1С закэшировалась старая схема метаданных, из-за чего платформа программно отсекает вывод старых строк в форму списка обычного приложения.
Для диагностики и устранения кэш-ошибок выполните следующие рекомендации:
%userprofile%\AppData\Local\1C\1Cv8
%userprofile%\AppData\Roaming\1C\1Cv8
Проанализировав все четыре метода, мы можем сделать вывод, что наиболее эффективным и наименее трудозатратным является Решение 1 (Фиктивная реструктуризация в Конфигураторе), так как оно требует минимум времени, не затрагивает логику проведения документов и отрабатывает на уровне ядра СУБД, гарантируя стопроцентный результат восстановления видимости документов в любых журналах платформы 1С.