Что делать, если после обновления в 1С пропали элементы справочника?

← На главную

Ситуация, когда после планового обновления конфигурации 1С пользователи обнаруживают отсутствие элементов в справочниках (например, «Склады», «Контрагенты» или «Номенклатура»), часто вызывает панику. Кажется, что данные безвозвратно удалены, а работа базы нарушена. Однако в большинстве случаев данные физически остаются в базе, а их «исчезновение» обусловлено либо техническими особенностями процесса обновления, либо человеческим фактором. Рассмотрим подробно, как провести расследование, найти пропавшие объекты и восстановить их работоспособность.

Первичная диагностика: проверка «видимости» данных

Прежде чем приступать к программному восстановлению, проанализируем, действительно ли элементы удалены. Разберем по шагам простейшие методы проверки:

Проверка отборов в форме списка. Часто пользователи случайно устанавливают фильтры (например, по конкретной группе или пометке на удаление), из-за чего часть элементов скрывается. Рекомендуется открыть справочник через меню «Все функции» (или «Функции для технического специалиста») — Справочники — Склады. Это позволит увидеть «чистый» список без предустановленных экранных настроек.
Проверка ссылочной целостности в документах. Найдем любой старый документ, в котором гарантированно использовался «пропавший» склад. Если в поле склада вместо названия мы видим надпись <Объект не найден> и длинную последовательность символов (GUID), значит, элемент действительно удален из базы. Если же название склада отображается корректно, но его нет в списке — проблема в правах доступа или кэше.
Поиск переименований. Проанализируем ситуацию: не мог ли кто-то из сотрудников с полными правами просто изменить название объекта? В 1С:Бухгалтерии 3.0 это «классика» жанра. Для проверки воспользуемся инструментом Журнал регистрации.

Использование Журнала регистрации для поиска виновных

Разберем ситуацию: если элемент не пропал, а был изменен, это мгновенно отобразится в логах системы. Журнал регистрации — это первый инструмент администратора. Настроим фильтр:

Период: с момента начала обновления до текущего времени.
Событие: Данные — Изменение.
Объект: Справочник.Склады (или нужный вам справочник).

Если в журнале зафиксировано событие «Изменение» от имени пользователя (например, Главбуха) сразу после обновления, мы увидим старое и новое состояние объекта. Это самый быстрый способ выяснить, что «пропавший» склад на самом деле теперь называется иначе.

Техническая диагностика через Консоль запросов

Чтобы окончательно убедиться в наличии или отсутствии записи в таблице базы данных, проанализируем данные через консоль запросов. Это исключит влияние программных фильтров конфигурации и механизмов RLS (ограничение прав на уровне записей). Выполним простой запрос:

ВЫБРАТЬ Ссылка, Наименование, ПометкаУдаления ИЗ Справочник.Склады

Если запрос возвращает искомые элементы, значит, проблема кроется в настройках прав доступа или в «битом» индексе полнотекстового поиска. В современных версиях (начиная с 3.0.67) 1С часто использует фоновое обновление данных. Пока этот процесс не завершен, индексы могут быть неактуальны, и поиск через строку в форме списка не будет давать результатов.

Очистка кэша и обновление индексов

Иногда после обновления «битый» локальный кэш пользователя искажает отображение списков. Проанализируем ситуацию: если один пользователь видит склад, а другой — нет, выполним следующие действия:

Удалим информационную базу из списка в стартере 1С и добавим её заново.
Запустим базу с параметром /ClearCache.
В самой программе перейдем в Администрирование — Поддержка и обслуживание — Управление полнотекстовым поиском и нажмем «Обновить индекс».

Восстановление данных по идентификатору (GUID)

Если проверка показала, что в документах вместо склада отображается <Объект не найден> (8491...гуид...), нам необходимо восстановить объект именно с тем же внутренним идентификатором. Если мы просто создадим новый склад с таким же именем, документы его «не увидят», так как связь в 1С идет по уникальному идентификатору (UUID), а не по названию.

Рассмотрим пример кода для восстановления связи:


// Предположим, мы узнали GUID из надписи "Объект не найден" в документе
НужныйGUID = Новый УникальныйИдентификатор("00000000-0000-0000-0000-000000000000"); // вставьте ваш GUID
Ссылка = Справочники.Склады.ПолучитьСсылку(НужныйGUID);

// Создаем новый объект с этой ссылкой
НовыйОбъект = Справочники.Склады.СоздатьЭлемент();
НовыйОбъект.УстановитьСсылкуНового(Ссылка);

// Заполняем реквизиты, которые помним
НовыйОбъект.Наименование = "Восстановленный склад";
НовыйОбъект.Записать();

После выполнения этого кода во всех документах, где ранее была ошибка <Объект не найден>, автоматически появится наш «Восстановленный склад».

Перенос данных из копии через XML

Если элементов пропало много, разберем вариант с использованием типовой обработки «Выгрузка и загрузка данных XML» (её можно найти на ИТС или в составе инструментов разработчика). Посмотрим на алгоритм:

Откроем старую копию базы (до обновления).
В обработке выберем только справочник «Склады». Можно настроить отбор по конкретным пропавшим элементам.
Выгрузим данные в файл.
В новой рабочей базе откроем ту же обработку и выполним загрузку.

Важно помнить, что при загрузке через XML объекты сопоставляются по UUID, поэтому все связи в документах восстановятся автоматически.

Настройка прав и предотвращение инцидентов

Выясним причину, почему такие ситуации становятся возможными. Часто это связано с избыточными правами сотрудников. Например, бытует мнение, что для работы с сервисом «1С-Отчетность» бухгалтеру необходимы «Полные права». Это не так. В современных конфигурациях достаточно назначить профили Бухгалтер и Администратор отчетности.

Также рекомендуется включить Версионирование объектов (Администрирование — Общие настройки — История изменений). Это позволит:

Видеть, кто и когда изменил название склада.
Сравнивать версии объекта.
Откатывать изменения к предыдущему состоянию без программирования и восстановления копий.

Подводя итог, можно сказать: в любой непонятной ситуации с «пропажей» данных первым делом проверяйте Журнал регистрации и наличие битых ссылок в документах. Это сэкономит часы времени, которые могли бы быть потрачены на ненужное восстановление всей базы из резервной копии.