Как исправить задвоение движений документа по регистру ОстаткиТМЦ в 1С 7.7

В практике сопровождения баз 1С:Предприятие 7.7 (в частности конфигурации «Торговля и Склад 9.2») периодически возникает ситуация, когда в отчетах (например, в «Ведомости по остаткам ТМЦ») движения по конкретной накладной или реализации удваиваются. При этом снятие проведения или удаление документа из пользовательского интерфейса удаляет лишь одну строку движений, а вторая остается зафиксированной в регистрах. Повторное проведение документа снова приводит к появлению двух строк движений.

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

Анализ причин задвоения записей и движений

Для понимания природы ошибки проанализируем внутреннюю архитектуру хранения данных в платформе 1С 7.7 формата DBF:

1. Физическая структура документов: каждый документ регистрируется в общем журнале 1SJOURN.DBF, где ему присваивается уникальный буквенно-цифровой идентификатор IDDOC (в 36-ричной системе счисления). Шапка документа хранится в таблице DH<ID>.DBF, а табличная часть — в DT<ID>.DBF.
2. Связь с регистрами: движения регистров остатков записываются в таблицу движений RA<ID>.DBF, где поле IDDOC жестко связывает каждую строчку движения с конкретной записью в 1SJOURN.DBF. Ежемесячные остатки и остатки на Точку Актуальности (ТА) аккумулируются в таблице итогов RG<ID>.DBF.
3. Счетчик уникальных номеров и IDDOC: генерация новых идентификаторов контролируется системной таблицей 1SSYSTEM.DBF (полями CURRID и MAXID).

Основная причина возникновения фантомных дублей заключается в рассинхронизации системных таблиц. Если в распределенной информационной базе (РБД / УРИБ) выполняется ручное копирование файлов таблиц документов (1SJOURN.DBF, DH*.DBF, DT*.DBF, RA*.DBF) из центрального узла в периферийный без переноса системного файла 1SSYSTEM.DBF, генератор идентификаторов периферийной базы оказывается «позади» реального пула существующих записей. В результате программа создает новый документ с тем же номером и ссылочным кодом, что порождает дублирующие записи в 1SJOURN.DBF с разными IDDOC.

Дополнительными факторами могут являться сбои индексных файлов *.CDX при параллельной работе или отключенный контроль уникальности номеров документов в конфигураторе, позволяющий записать два разных документа с одинаковым печатным номером на одну дату.

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

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

1. Проверка через пользовательский интерфейс: откроем общий журнал документов, снимем все установленные отборы и интервалы, отсортируем список по номеру подозрительного документа и дате. Обратим внимание, не отображаются ли в списке два документа с одинаковым номером, созданные в разное время.
2. Проверка через DBF-редактор: закроем сеансы 1С и откроем файл 1SJOURN.DBF с помощью специализированного редактора таблиц (например, DBF Viewer, Sdbf или Advantage Data Architect). Выполним поиск по номеру проблемного документа в поле DOCNO.
3. Анализ поля IDDOC: если поиск возвращает две строки с одинаковым значением DOCNO, но разными значениями IDDOC, мы имеем дело с физическим дублированием записей в журнале. При этом в интерфейсе программы один из документов мог быть скрыт или визуально воспринимался как единственный.

Способы устранения дублирования движений

Рассмотрим варианты исправления ситуации в зависимости от сложности случая.

Способ 1. Корректировка через интерфейс 1С

Если в общем журнале отображаются оба документа-дубля, выполним следующие действия:

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

Способ 2. Очистка таблиц и пересчет итогов вручную

Если в базе образовались «зависшие» движения (записи в таблице RA*.DBF, для которых в 1SJOURN.DBF уже нет соответствующего документа), штатное перепроведение не поможет. В этом случае применим следующий порядок действий:

1. Определим идентификатор регистра «ОстаткиТМЦ» по файлу 1SBLOB.DBF или структуре метаданных. Таблица движений будет иметь вид RA<ID>.DBF, а итогов — RG<ID>.DBF.
2. С помощью DBF-редактора откроем RA<ID>.DBF и найдем записи с IDDOC, принадлежащим удаленному или дублирующему документу, после чего физически удалим эти строки (с выполнением операции Pack / сжатия таблицы).
3. Для исключения многодневного полного тестирования базы (ТИИ), которое на базах объемом более 15 ГБ может занимать несколько суток, выполним локальный пересчет: очистим только целевую таблицу итогов RG<ID>.DBF для проблемного регистра.
4. Запустим 1С монопольно и выполним пересчет итогов через меню «Операции» — «Управление бухгалтерскими итогами» / «Пересчет итогов» либо через перенос Точки Актуальности. При пустой таблице RG*.DBF платформа пересчитает итоги только по данному регистру на основе чистых движений из RA*.DBF.

Способ 3. Синхронизация счетчика 1SSYSTEM.DBF

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

1. Откроем 1SJOURN.DBF, отсортируем записи по полю IDDOC по убыванию и зафиксируем максимальное существующее значение идентификатора.
2. Откроем служебную таблицу 1SSYSTEM.DBF.
3. Проверим поле CURRID. Если его текущее значение меньше максимального IDDOC из журнала документов, вручную установим в CURRID значение максимального IDDOC с небольшим запасом вперед (в 36-ричном формате представления).
4. Сохраним изменения. Теперь новые создаваемые документы гарантированно получат уникальные идентификаторы, не пересекающиеся с уже существующими в базе.

Профилактика целостности базы данных

Для предотвращения подобных сбоев в распределенных информационных базах 1С 7.7 рекомендуется соблюдать следующие правила:

1. Отказ от прямого копирования таблиц: обмен между узлами РБД должен осуществляться исключительно штатными механизмами выгрузки/загрузки пакетов изменений (УРИБ).
2. Настройка префиксов номеров: для каждого узла распределенной системы в конфигурации должен быть жестко задан уникальный префикс автонумерации документов.
3. Контроль уникальности: в свойствах метаданных документов в Конфигураторе флаг «Уникальность номера» должен быть включен для каждого типа документа.
4. Контроль размера файлов: учитывая ограничение формата DBF в 2 ГБ на одну таблицу и индексный файл, для баз объемом от 10–15 ГБ необходимо регулярно контролировать размер таблиц 1SJOURN.DBF, RA*.DBF и соответствующих *.CDX, своевременно выполняя свертку базы или переход на формат SQL.