← На главную

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

Причины возникновения дублей IDDOC в файловой базе

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

1. Сбой счетчика в системной таблице 1SUIDCTL.DBF. Именно здесь фиксируется последнее выданное значение уникального номера. При аварийном завершении работы сеанса 1С (падение питания, зависание процесса, обрыв сетевого соединения) актуальное значение счетчика может не записаться на диск, в результате чего новый документ получает номер, который уже был присвоен ранее.
2. Сетевое кэширование и механизм SMB Oplocks. При совместной работе пользователей с файловой базой через общий сетевой ресурс Windows применяет так называемые «оппортунистические блокировки» (Opportunistic Locks). Если два пользователя одновременно создают и записывают документы, клиенты могут считать одно и то же неактуальное значение из кэша, что приводит к генерации идентичных идентификаторов.
3. Повреждение индексов (*.CDX). При повреждении индексных файлов встроенный механизм платформы не видит уже существующий документ с таким идентификатором и разрешает запись дубля.
4. Ошибки настройки распределенной информационной базы (УРБД). Идентификатор документа формируется с учетом префикса базы данных. Если в разных узлах распределенной базы задан одинаковый код узла ИБ, при выгрузке и загрузке данных возникнет наложение идентификаторов.

Особенности структуры идентификатора IDDOC

Прежде чем переходить к ручной правке таблиц, проанализируем структуру идентификатора. В 1С 7.7 внутренний номер формируется в 36-ричной системе счисления (Base36, использующей цифры 0–9 и латинские буквы A–Z). Это означает, что просто прибавить единицу в привычном десятичном формате нельзя: значение необходимо рассчитывать именно по основанию 36.

Идентификатор имеет длину до 9 символов, где младшие разряды представляют собой порядковый номер, а старшие (до трех символов) — код информационной базы. Кроме того, документ связывается с множеством вспомогательных таблиц базы данных:

1. 1CJOURN — общий журнал документов.
2. DH* и DT* — таблицы шапки и табличной части конкретного вида документа.
3. _1SCRDOC — таблица подчиненных документов и графов отбора (поля CHILDID и PARENTVAL).
4. _1SOPER и _1SENTRY — бухгалтерские операции и проводки (поле DOCID).
5. RA* и RG* — таблицы движений и итогов регистров оперативного учета (поле IDDOC).
6. Таблицы справочников SC* и периодических реквизитов 1SCONST, если в них присутствуют ссылки на данный документ. В случае реквизитов неопределенного типа ссылка состоит из 4-значного кода вида документа (IDDOCDEF) и самого идентификатора.

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

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

1. Находим оба документа-дубля в пользовательском интерфейсе (по номеру, дате или через общий журнал).
2. Открываем один из сбойных документов и копируем его стандартным действием платформы. При сохранении нового документа платформа присвоит ему свежий, заведомо уникальный идентификатор, а также корректно сформирует движения по регистрам и бухгалтерские проводки.
3. Используем внешнюю обработку и метод НайтиСсылки(), чтобы обнаружить все места, где старый документ был указан в качестве значения реквизита, родительского документа или основания.
4. Перенаправляем найденные ссылки на созданную копию документа.
5. Распроводим сбойный исходный документ, помечаем его на удаление и удаляем через штатное удаление помеченных объектов. Если платформа блокирует удаление из-за коллизии, очищаем движения документа и удаляем его строку непосредственно из таблицы 1CJOURN.

Способ 2. Ручная правка таблиц DBF

Если документы имеют сложную подчиненность, период закрыт от редактирования или база вовсе не открывается штатными средствами, рассмотрим подробнее порядок прямой коррекции через DBF-редактор. Обязательно делаем полную резервную копию базы перед началом манипуляций!

1. Определяем, какой из двух документов с одинаковым IDDOC будет изменен.
2. Открываем таблицу 1CJOURN.DBF и определяем максимальный существующий IDDOC.
3. Вычисляем новое значение: берем максимальный идентификатор и увеличиваем его значение в 36-ричном формате.
4. Заменяем старый IDDOC на новое значение в таблице 1CJOURN, а также в таблицах шапки (DH<НомерТаблицы>) и табличной части (DT<НомерТаблицы>) изменяемого документа.
5. Проверяем наличие проводок и движений: если документ проведен, заменяем идентификатор в таблицах операций _1SOPER, проводок _1SENTRY, движений регистров RA*, а также в таблице подчиненных документов _1SCRDOC.
6. Корректируем значение счетчика в файле 1SUIDCTL.DBF. Если в счетчике оставить старый номер, следующий созданный в программе документ снова получит уже занятый идентификатор.
7. Удаляем все файлы индексов с расширением *.CDX из каталога информационной базы.
8. Запускаем 1С:Предприятие в монопольном режиме для выполнения автоматической переиндексации, после чего запускаем конфигуратор и выполняем полное «Тестирование и исправление информационной базы».

Как предотвратить появление дублей IDDOC в дальнейшем

Устранение уже возникшей коллизии решает проблему лишь временно. Чтобы исключить повторные сбои, применим системные меры защиты:

1. Перевод пользователей в терминальный режим (RDP). Это лучший способ работы с файловыми базами 1С 7.7. Когда все клиенты выполняют процессы локально на сервере, исключаются сетевые коллизии файлового кэширования и сетевые разрывы.
2. Отключение кэширования SMB (Opportunistic Locks). Если база продолжит работать через общую сетевую папку, на файловом сервере и клиентских ПК необходимо отключить SMB2/SMB3 Directory Caching и Oplocks. Это гарантирует немедленный сброс транзакций счетчиков на диск.
3. Переход на клиент-серверную версию (SQL). При работе с Microsoft SQL Server выдача уникальных идентификаторов и блокировка таблиц контролируются сервером СУБД, что полностью предотвращает появление дублирующихся записей.