Что делать, если в 1С:Управление торговлей 11 пропали документы продажи из списка?

← На главную

Представьте стандартную рабочую ситуацию: пользователь открывает привычный журнал «Документы продажи (все)» в конфигурации «1С:Управление торговлей 11» (или аналогичных решениях нового поколения, таких как ERP 2 или Комплексная автоматизация 2), чтобы проверить недавние отгрузки. Но вместо сотен документов за текущий год он видит пустой экран или всего несколько старых записей многолетней давности. При этом документы физически существуют в базе данных: их можно найти через глобальный поиск, открыть из панели «История», увидеть в структуре подчиненности или в отчетах по продажам. Они не помечены на удаление, они проведены, но в общем списке их просто нет.

В этой статье мы подробно разберем, почему возникает эта техническая иллюзия исчезновения документов, проанализируем архитектурные особенности современных конфигураций 1С и изучим пошаговые методы полного восстановления нормального отображения журналов документов.

Почему документы исчезают из списков: техническая суть проблемы

В старых версиях программ 1С (например, Управление производственным предприятием 1.3 или Управление торговлей 10.3) динамические списки в журналах документов строились напрямую по таблицам базы данных соответствующих документов. Если существовал документ РеализацияТоваровУслуг, он гарантированно выводился в список, если не было жестких отборов.

В современных конфигурациях ERP-класса разработчики применили совершенно иной подход для оптимизации быстродействия системы. Список «Документы продажи» (а также «Документы закупки», «Внутренние документы») представляет собой сложный динамический список, который физически строится на основе данных специального вспомогательного регистра — Регистра сведений «Реестр документов» (РегистрСведений.РеестрДокументов).

Этот регистр аккумулирует в себе ключевые метаданные обо всех операциях: дату, номер, сумму, организацию, контрагента, договор, статус и тип документа. Когда пользователь открывает журнал продаж, программа обращается не к самим документам, а к этому регистру. Это позволяет мгновенно строить объединенные реестры по десяткам различных видов документов без снижения производительности СУБД.

Следовательно, если документ физически существует в базе, но отсутствует в списке, это означает только одно: в регистре сведений «Реестр документов» по какой-то причине отсутствует или повреждена запись, соответствующая этому документу.

Рассмотрим основные причины, которые приводят к рассинхронизации данных между документами и реестром:

Проблемы со справочником «Ключи реестра документов». Регистр РеестрДокументов тесно связан со служебным справочником КлючиРеестраДокументов. При записи или проведении любого документа система автоматически генерирует уникальные аналитические ключи. Если в справочнике ключей произошел сбой (например, появились дубли из-за некорректного распределенного обмена данными или сбоя СУБД), новые записи в реестр просто не могут физически записаться.
Зависание или сбой отложенного обновления информационной базы. При обновлении крупных релизов 1С (например, при переходе на платформу 11.5 и выше) структура регистра реестра часто претерпевает изменения. В этот момент запускаются регламентные задания фонового (отложенного) обновления данных. Если база данных огромная, этот процесс может выполняться десятки часов или аварийно завершиться из-за нехватки памяти, оставив часть документов без записей в реестре.
Создание документов в обход стандартных механизмов платформы. Если документы загружались в базу из внешних источников (через API, сторонние обработки, файлы Excel) и при этом запись производилась в режиме ОбменДанными.Загрузка = Истина, то стандартные подписки на события и процедуры ПередЗаписью и ПриЗаписи игнорируются. Как результат — документ в базе есть, а запись в реестр документов не создана.
Сбои в механизме ограничения прав на уровне записей (RLS). Если документы скрыты только у обычных пользователей, но видны под полными правами, проблема кроется в ошибке шаблонов RLS для регистра реестра. При сбое кэша прав доступа RLS может ложно скрывать существующие в реестре записи.

---

Пошаговые методы решения проблемы

Рассмотрим пошагово практические сценарии исправления ситуации — от простых диагностических действий до глубокого технического восстановления данных.

Шаг 1. Первичная диагностика через функции технического специалиста

Для начала нам необходимо убедиться, действительно ли дело в регистре «Реестр документов». Проведем простую проверку:

Включим режим технического специалиста (если он отключен) через Главное меню -> Настройки -> Параметры -> флаг «Режим технического специалиста».
Откроем меню «Функции для технического специалиста».
В строке поиска введем «Реестр документов» и перейдем в одноименный регистр сведений.
Попробуем установить отбор по любому «пропавшему» документу (например, по его номеру или точной дате).

Если в открывшемся регистре записей по документу нет, значит, мы верно диагностировали проблему. Переходим к процедурам восстановления.

Шаг 2. Перезаполнение и исправление ключей реестра документов

В большинстве случаев проблема кроется в повреждении структуры ключей. Разработчики 1С предусмотрели штатный механизм для исправления подобных коллизий. Выполним следующие действия:

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

Важно: Процесс генерации ключей на крупных информационных базах может занять значительное время и создать существенную нагрузку на сервер СУБД. Рекомендуется выполнять эту операцию в периоды минимальной активности пользователей.

Шаг 3. Локальное принудительное обновление регистра реестра

Если документы пропали выборочно (например, только за конкретный месяц или созданные определенным пользователем), мы можем заставить систему принудительно перезаписать эти документы. При перезаписи документа в обычном режиме платформа автоматически выполнит подписку на событие записи и сформирует корректную строчку в регистре сведений РеестрДокументов.

Для массовой перезаписи без изменения реквизитов воспользуемся стандартным инструментом:

Перейдем в раздел НСИ и администрирование -> Обслуживание -> Корректировка данных -> Групповое изменение реквизитов.
В поле «Изменять» выберем объект Реализация товаров и услуг.
С помощью кнопки «Добавить отбор» настроим правила для выбора только тех документов, которые пропали из списка (например, отбор по конкретному периоду даты или автору документа).
Нажмем кнопку «Дополнительные параметры» внизу формы.
Критически важно: снимем флаг (или переведем в значение Ложь) параметр «Выполнять в режиме загрузки». Если этого не сделать, документы перезапишутся без вызова обработчиков событий, и реестр не обновится! Также рекомендуется установить флаг «Отключить блокировки».
В табличной части выбора реквизитов для изменения ничего выбирать не нужно (или можно выбрать малозначимый реквизит, например, добавить пробел в поле «Комментарий»).
Нажмем кнопку «Изменить реквизиты».

Система поочередно откроет, перезапишет и закроет каждый выбранный документ, попутно генерируя правильные записи в регистре реестра.

Альтернативный программный метод перезаписи документов для разработчиков

Если у вас есть доступ к консоли кода или групповой обработке с возможностью выполнения произвольного алгоритма на встроенном языке 1С, вы можете выполнить принудительное обновление реестра программно. Разберем шаблон кода, выполняющий эту операцию порционно с контролем транзакций:


Выборка = Документы.РеализацияТоваровУслуг.Выбрать(НачалоДня(ТекущаяДата() - 30), КонецДня(ТекущаяДата()));
Пока Выборка.Следующий() Цикл
    // Проверим, заблокирован ли объект, чтобы не прерывать выполнение всей обработки
    Попытка
        ДокОбъект = Выборка.ПолучитьОбъект();
        // Отключаем режим загрузки, чтобы отработали все подписки на события регистра
        ДокОбъект.ОбменДанными.Загрузка = Ложь;
        
        // Записываем документ в режиме проведения, если он был проведен
        Если ДокОбъект.Проведен Тогда
            ДокОбъект.Записать(РежимЗаписиДокумента.Проведение);
        Иначе
            ДокОбъект.Записать(РежимЗаписиДокумента.Запись);
        EndIf;
    Исключение
        ЗаписьЖурналаРегистрации("ОшибкаПерезаписиРеестра",
            УровеньЖурналаРегистрации.Ошибка, , ,
            "Не удалось перезаписать документ: " + Выборка.Ссылка + ". Ошибка: " + ОписаниеОшибки());
    КонецПопытки;
КонецЦикла;

Шаг 4. Проверка отложенных обработчиков обновления программы

Если инцидент с пропажей документов произошел непосредственно после очередного обновления конфигурации, обязательно нужно проверить статус выполнения отложенных процедур обновления:

Перейдем по пути: НСИ и администрирование -> Обслуживание -> Результаты обновления программы.
Кликнем по гиперссылке «Отложенные обработчики обновления».
Проанализируем список незавершенных задач. Обратим особое внимание на процедуры, в названии которых фигурируют слова «РеестрДокументов», «КлючиРеестра» или «ЗаполнениеРегистров».
Если какая-то из задач остановлена по ошибке или зависла в статусе «Выполняется», выделим ее и запустим вручную с помощью кнопки «Запустить заново».

После успешного завершения всех процедур отложенного обновления документы должны автоматически вернуться в динамические списки.

Шаг 5. Сброс кэша RLS и пользовательских настроек формы

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

Проанализируем и исправим настройки видимости:

Откроем форму списка «Документы продажи (все)».
Нажмем кнопку «Еще» -> «Установить стандартные настройки». Это сбросит все возможные скрытые отборы по хозяйственным операциям или статусам документов, которые пользователь мог случайно выставить.
Если сброс настроек не помог, выполним очистку кэша пользователя через меню Администрирование -> Настройки пользователей и прав -> Персональные настройки -> Очистка настроек. Удалим настройки формы списка документов продажи для проблемного сотрудника.
При использовании RLS (ограничения прав на уровне записей) запустим регламентное задание «Обновление прав доступа», которое принудительно пересчитает таблицы ограничений для пользователей на основе актуальных ключей доступа.

Систематическое выполнение этих шагов гарантирует полное восстановление нормального функционирования динамических списков документов продажи в любой современной конфигурации на платформе 1С:Предприятие 8.3.