В практике администрирования и сопровождения систем на платформе «1С:Предприятие 8» одна из самых пугающих и интригующих ситуаций — это внезапное исчезновение документа из базы данных. Пользователи утверждают, что документ точно был, велся учет, возможно, выполнялось проведение. Однако при поиске в динамических списках, через консоль запросов и даже при стандартном тестировании и исправлении (ТИИ) документ обнаружить не удается.
Особенно загадочно ситуация выглядит тогда, когда в Журнале регистрации (ЖР) в режиме «Конфигуратор» мы видим частичные следы документа (например, изменения или проведение), но в режиме «1С:Предприятие» по этому же документу нет ровным счетом ничего. В этой статье мы подробно разберем, почему возникает эта техническая коллизия, как устроена логика отображения Журнала регистрации и как по шагам найти «пропавший» документ с помощью его уникального идентификатора (GUID).
Для начала проанализируем причину, по которой одно и то же событие Журнала регистрации выглядит по-разному в зависимости от режима запуска системы. Это ключевой момент, который часто сбивает с толку начинающих разработчиков и системных администраторов.
Дело в том, что платформа 1С использует два разных механизма для отображения поля «Данные»:
Передача товаров ЛеОО-000793 от 17.06.2019). Для этого платформа на лету обращается к таблицам СУБД по уникальному идентификатору (GUID) этого объекта. Если пользователь открыл старый документ ЛеОО-000929, изменил в нем номер на ЛеОО-000793, поменял дату и нажал «Записать», то физический GUID документа в базе данных остался прежним. В результате в режиме Предприятия все старые записи ЖР для этого GUID автоматически начинают отображаться с новым представлением — ЛеОО-000793. Попытка найти старый номер через поиск в Предприятии не даст результатов, так как объект уже имеет другие реквизиты..lgf или .lgd). В этих файлах в момент записи события фиксируется жесткая строка представления на тот конкретный момент времени. Если в 16:24 документ назывался ЛеОО-000929, то в файле лога запишется именно эта строка. Даже если через минуту документ переименуют, статичная текстовая запись в Журнале регистрации внутри Конфигуратора сохранит историческое название.Таким образом, если в Конфигураторе мы видим старый номер, а в Предприятии по этому номеру пустота — это первый и самый верный признак того, что документ не удален, а просто изменен (перезаписан) пользователем. Чаще всего это происходит, когда вместо копирования существующего документа (клавиша F9) пользователь случайно открывает старый документ, редактирует его данные и сохраняет.
Ниже мы подробно разберем пошаговый алгоритм, как доказать эту гипотезу и вернуть данные в исходное состояние.
Чтобы распутать этот клубок, нам понадобится резервная копия базы данных (бэкап) за тот период, когда документ гарантированно существовал под своим старым номером и датой. Наша главная задача на данном этапе — получить его УникальныйИдентификатор.
Развернем резервную копию в файловом варианте или на тестовом SQL-сервере. Запустим базу в режиме «1С:Предприятие». Найдем нужный нам документ (например, ЛеОО-000929). Нам необходимо программно извлечь его GUID. Для этого мы можем воспользоваться внешней обработкой или написать простой код в групповой обработке данных:
// Пример кода для получения GUID в тестовой копии базы данных
ИмяДокумента = "ПередачаТоваровМеждуОрганизациями";
НомерПоиска = "ЛеОО-000929";
ДатаПоиска = '20190617162430'; // Точная дата или примерный период
СсылкаНаДокумент = Документы[ИмяДокумента].НайтиПоНомеру(НомерПоиска, ДатаПоиска);
Если Не СсылкаНаДокумент.Пустая() Тогда
СтрокаGUID = Строка(СсылкаНаДокумент.УникальныйИдентификатор());
Сообщить("Успешно! Уникальный идентификатор (GUID) документа: " + СтрокаGUID);
Иначе
Сообщить("Документ с номером " + НомерПоиска + " в резервной копии не найден!");
КонецЕсли;
Запишем полученную строку GUID (например, 5f3c2a1a-4b9d-11e9-810a-00155d012101). Это наш главный ключ, по которому мы будем производить дальнейшие поиски в «живой» рабочей базе.
Теперь переходим в рабочую информационную базу. Нам необходимо проверить, существует ли в ней объект с таким уникальным идентификатором, и если да, то какие реквизиты (номер, дата, проведен/не проведен) он имеет в данный момент. Для этой задачи подойдёт обработка для поиска ссылки по известному уникальному идентификатору.
Для этого мы воспользуемся возможностью платформы получать ссылку на любой объект по его GUID. Напишем и запустим в рабочей базе несложный программный код:
// Поиск и анализ объекта по GUID в рабочей базе данных
СтрокаGUID = "5f3c2a1a-4b9d-11e9-810a-00155d012101"; // Подставьте ваш GUID, полученный на Шаге 1
ИмяДокумента = "ПередачаТоваровМеждуОрганизациями";
УИД = Новый УникальныйИдентификатор(СтрокаGUID);
СсылкаНаДокумент = Документы[ИмяДокумента].ПолучитьСсылку(УИД);
Попытка
// Пытаемся прочитать объект из базы данных
ОбъектДокумента = СсылкаНаДокумент.ПолучитьОбъект();
Если ОбъектДокумента = Неопределено Тогда
Сообщить("Внимание! Документ с данным GUID физически УДАЛЕН из рабочей базы!");
Иначе
Сообщить("Документ найден под другими реквизитами!");
Сообщить("Текущий Номер: " + ОбъектДокумента.Номер);
Сообщить("Текущая Дата: " + Строка(ОбъектДокумента.Дата));
Сообщить("Проведен: " + ?(ОбъектДокумента.Проведен, "Да", "Нет"));
Сообщить("Автор документа (Ответственный): " + Строка(ОбъектДокумента.Ответственный));
КонецЕсли;
Исключение
Сообщить("Ошибка при попытке получить объект: " + ОписаниеОшибки());
КонецПопытки;
Если в результате выполнения этого кода система вывела нам информацию, что документ найден, но под номером ЛеОО-000793 — значит, наша гипотеза полностью подтвердилась! Документ никуда не пропадал, из базы его никто не стирал. Пользователь просто открыл старую «Передачу товаров», переписал в ней ключевые реквизиты, заполнил новую табличную часть и перепровел документ.
Теперь, когда у нас есть ссылка на измененный объект, мы можем детально восстановить картину происшествия. Выясним, кто именно из пользователей совершил эту ошибку, в какое время и под какой учетной записью. Для такого анализа также можно использовать отчет для мониторинга действий пользователей по журналу регистрации.
Для этого выполним следующие действия:
Передача товаров между организациями.ЛеОО-000793).Перед нами развернется полная хронологическая история жизни этого GUID. Мы увидим ранние записи, где в Конфигураторе фигурировал номер ЛеОО-000929, и увидим переломный момент (дату и время), когда пользователь открыл этот документ и перезаписал его. В колонках «Пользователь» и «Компьютер» будет четко указано имя виновника инцидента. Это позволит полностью закрыть внутреннее расследование проблемы.
Что делать, если на Шаге 2 наша обработка выдала сообщение: Документ с данным GUID физически УДАЛЕН из рабочей базы!? Рассмотрим другие распространенные технические сценарии, из-за которых данные могут физически исчезнуть, оставив ложные следы в системе.
Журнал регистрации 1С пишется на уровне сервера приложений во внешние файлы (в новых версиях это база SQLite 1Cv8.lgd, в старых — текстовые файлы .lgf). Запись логов ЖР происходит асинхронно или параллельно с основной транзакцией в SQL.
Рассмотрим ситуацию:
tempdb на SQL-сервере, рвется сетевое соединение или СУБД фиксирует взаимоблокировку (Deadlock).В результате мы получаем классическую рассинхронизацию: в Журнале регистрации написано, что документ успешно записан или проведен, но в СУБД его физически нет. Для минимизации таких проблем рекомендуется своевременно обновлять платформу 1С и следить за стабильностью работы СУБД.
Если документ пропал абсолютно бесследно (нет записей ни в Журнале регистрации в Конфигураторе, ни в Предприятии, а консоль запросов выдает пустой результат), высока вероятность прямого вмешательства администратора базы данных в СУБД.
При выполнении SQL-запроса DELETE FROM ... напрямую в таблицах базы данных сервер приложений 1С вообще не задействуется. Платформа не перехватывает это событие, и в Журнал регистрации не записывается ровным счетом ничего. Такое удаление часто практикуется неквалифицированными специалистами при попытках исправить битые ссылки или очистить базу "по-быстрому". Восстановить такой документ можно только из резервной копии СУБД.
Документ мог быть удален стандартным программным методом ДокументОбъект.Удалить(). Это действие часто выполняют внешние обработки, механизмы синхронизации (например, при некорректно настроенном обмене между «Управление торговлей» и «Бухгалтерия предприятия») или интеграционные модули WMS/CRM-систем.
При непосредственном удалении в Журнале регистрации обязательно фиксируется событие «Данные.Удаление». Проверьте ЖР за весь день инцидента без фильтрации по конкретному объекту, установив только отбор по событию «Данные.Удаление» и классу метаданных Документ.ПередачаТоваровМеждуОрганизациями.
Иногда возникает ситуация-иллюзия: документ физически присутствует в базе данных SQL, запросы его находят, но в динамическом списке («Журнал документов») у конкретного пользователя его не видно. Тестирование и исправление (ТИИ) не выявляет ошибок.
Это связано с повреждением локального кэша метаданных на компьютере пользователя. Для решения проблемы выполните очистку кэша по шагам:
%userprofile%\AppData\Local\1C\1Cv8%userprofile%\AppData\Roaming\1C\1Cv8/ClearCache в настройках информационной базы в окне запуска.Чтобы исключить возможность «тихой» перезаписи исторических документов пользователями, рекомендуем настроить несколько встроенных механизмов платформы:
Применяя данные подходы и используя пошаговую методику поиска по GUID, вы всегда сможете оперативно расследовать любые инциденты, связанные с пропажей данных, и гарантировать стабильную работу вашей учетной системы.