← На главную

При активной работе в распределенных информационных базах (УРБД) на платформе 1С:Предприятие 7.7 (формат DBF) администраторы и разработчики нередко сталкиваются с ошибками целостности данных. Одной из наиболее сложных проблем является появление записей вида «Объект не найден (код/префикс)» в отчетах по остаткам (например, зависшие резервы товаров), а также сообщения тестирования и исправления (ТиИ): «Проверка уникальности внутреннего идентификатора документов... Исправить вручную».

Разберем детально, почему возникают такие коллизии, как устроена идентификация объектов в 1С 7.7 и какими способами можно восстановить корректную работу базы данных.

Выясним причину возникновения ошибки:

1. Структура идентификатора: Внутренний идентификатор документа (IDDOC) и элемента справочника (ID) в 1С 7.7 представляет собой 9-значную строку в 36-ричной системе счисления. Первые 6 символов отводятся под порядковый номер созданного объекта в узле, а последние 3 символа — под префикс (код) узла распределенной базы.
2. Коллизия узлов УРБД: Если двум периферийным базам по ошибке был присвоен одинаковый код узла или счетчик объектов в одной из баз рассинхронизировался (например, из-за аварийного завершения работы или восстановления копии), разные базы могут сгенерировать одинаковый IDDOC для двух совершенно разных документов (например, для документа «ПеремещениеТМЦ» и «ЗаявкаПокупателя»).
3. Зависшие движения в регистрах: Когда документ физически удаляется в одном узле или удаляется с нарушением ссылочной целостности, записи в таблицах движений регистров (RA*.DBF) или итогов (RG*.DBF) могут остаться. В регистрах сохраняются движения по несуществующему документу, что проявляется как «Объект не найден» и формирует некорректный резерв или остаток ТМЦ.

Важное ограничение платформы: Штатная процедура «Тестирование и исправление ИБ» в Конфигураторе 1С 7.7 не может автоматически разрешать дубли внутренних идентификаторов документов и справочников. При нахождении одинаковых IDDOC платформа выдает предупреждение «Исправить вручную» и пропускает операцию. Поэтому требуется ручное вмешательство.

Способ 1. Разделение задублированных идентификаторов через редактирование DBF-таблиц

Рассмотрим по шагам процесс устранения коллизии идентификаторов при помощи прямого редактирования таблиц базы данных DBF-редактором (перед выполнением работ обязательно создаем полную резервную копию каталога ИБ):

1. Определяем структуру таблиц: Открываем файл описания структуры метаданных 1cv7.dd (находится в каталоге информационной базы) в любом текстовом редакторе. Находим по именам документов и справочников физические имена таблиц:
   • 1SJOURN.DBF — общий журнал всех документов;
   • DHxxxx.DBF и DTxxxx.DBF — таблицы шапки и табличной части проблемного документа (где xxxx — номер таблицы из 1cv7.dd);
   • 1SCRDOC.DBF — таблица подчиненных документов;
   • 1SCONST.DBF — таблица периодических реквизитов (поле DOCID);
   • RAxxxx.DBF — таблицы движений регистров, в которые документ формирует проводки.
2. Генерируем новый уникальный IDDOC: Чтобы не нарушить сквозную нумерацию, создаем в монопольном режиме 1С новый пустой документ нужного вида («ПеремещениеТМЦ»), закрываем программу, открываем 1SJOURN.DBF и берем сгенерированный 9-значный IDDOC новой записи.
3. Перепривязываем данные документа:
   • В таблице шапки DHxxxx.DBF для нужной записи меняем старый IDDOC на новый.
   • В таблице табличной части DTxxxx.DBF заменяем IDDOC во всех строках этого документа.
   • В таблице журнала 1SJOURN.DBF проверяем запись: если запись документа была перезаписана другим видом документа из-за коллизии, формируем корректную строку с новым IDDOC, правильным кодом типа документа IDDOCDEF, номером и датой.
   • В таблицах движений регистров RAxxxx.DBF, а также в 1SCRDOC.DBF заменяем старый идентификатор на новый.
4. Исправляем дубликаты в справочниках: Если ошибка возникла в справочнике (например, «Цены»), в соответствующей таблице SCxxxx.DBF находим записи с одинаковым полем ID. У одной из записей заменяем ID на уникальное значение с одновременным обновлением ссылок в подчиненных таблицах и периодических реквизитах (1SCONST.DBF).
5. Переиндексация базы: Удаляем все файлы индексов с расширением *.CDX из каталога информационной базы и запускаем 1С:Предприятие в монопольном режиме для автоматического восстановления индексов.

Способ 2. Очистка «висячих» остатков и удаление пустых ссылок

Если проблемный документ (например, неподтвержденная заявка покупателя) больше не нужен, но продолжает держать остатки в резерве и отображается как <Объект не найден>, проанализируем порядок действий по очистке движений:

1. В файле 1cv7.dd находим номер таблицы регистра остатков/резервов (таблицы RAxxxx.DBF и RGxxxx.DBF).
2. Открываем таблицу движений RAxxxx.DBF в DBF-редакторе, находим записи, в которых значение IDDOC совпадает с идентификатором удаленного документа (из текста ошибки Объект не найден>(3298915/ПБ4)), и удаляем эти строки физически (с последующей упаковкой таблицы PACK).
3. Удаляем файлы *.CDX и запускаем базу в монопольном режиме.
4. Заходим в меню «Операции» -> «Управление итогами» и выполняем пересчет итогов с переносом точки актуальности (ТА), либо запускаем в Конфигураторе «Тестирование и исправление ИБ» только с установленным флагом «Пересчет итогов». Зависший резерв будет полностью списан.

Способ 3. Синхронизация через центральную базу УРБД

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

1. В центральной базе открываем проблемный документ, вносим любое незначительное изменение (или перевыбираем комментарий) и сохраняем его. При этом документ регистрируется к выгрузке в узел обмена.
2. Формируем файл выгрузки данных из центрального узла в периферийный.
3. Загружаем файл обмена в периферийную базу. Платформа перезапишет заголовок и табличные части объекта актуальными данными из центра.
4. Если документ в центральной базе был ранее удален штатной обработкой удаления помеченных объектов, выполняем тестирование и исправление с опцией восстановления объектов в центральном узле, после чего повторяем процедуру обмена.

Для предотвращения повторного появления подобных коллизий обязательно проверьте уникальность кодов всех узлов в меню «Администрирование» -> «Распределенная ИБ» -> «Управление»: каждый узел должен иметь уникальный код длиной до 3 символов, который никогда не повторяется в рамках всей распределенной структуры.