← На главную

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

В этой статье мы подробно разберем, почему возникает эта проблема, как устроен механизм авторегистрации изменений в УРИБ 1С 7.7, почему раздуваются файлы итогов регистров и таблицы регистрации, а также как настроить стабильный обмен на современных операционных системах Windows Server x64.

---

Причина 1: Ссылочная целостность и авторегистрация партионных документов

Выясним главную причину, по которой документы «от царя Гороха» (например, за 2016 год) начинают выборочно попадать в файлы обмена после запуска обновленной системы. В типовой конфигурации «Торговля и склад 7.7» (ТиС) ключевым механизмом является партионный учет товаров.

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

1. При проведении текущих документов (например, Реализация или ОтчетККМ) система списывает товар со складов.
2. Если на остатках склада числится старый товар (который завис, был возвращен или остатки по которому перенеслись некорректно), алгоритм проведения списывает его по партиям прошлых лет.
3. В качестве партии в регистре ПартииНаличие выступает элемент справочника Партии, у которого есть реквизит ДокументОснование. Этим документом-основанием как раз и является старая приходная накладная или реализация (например, за 2016 год).
4. Платформа 1С 7.7 строго следит за ссылочной целостностью данных в распределенной базе. Когда текущий документ, содержащий ссылку на старую партию, выгружается в периферийную базу, УРИБ автоматически анализирует связанные объекты. Чтобы на периферийной базе не возникла битая ссылка вида <Объект не найден>, система принудительно регистрирует в таблице изменений сам документ-основание (ту самую реализацию 2016 года) и отправляет его в обмен.

Решение проблемы: Это штатное поведение системы. Если старые партии физически остались в базе (например, на остатках числятся незакрытые старые партии), система будет отправлять документы-основания в ПБ при первом же их движении. Чтобы избежать этого, перед сверткой необходимо тщательно выверить и «схлопнуть» остатки по партиям, перенеся их на один служебный документ ввода остатков, и полностью избавиться от ссылок на документы прошлых периодов.

---

Причина 2: Разница в размерах файлов итогов RG на ЦБ и ПБ

Проанализируем еще одну частую проблему: файл движений регистра партий (RA*) на центральной и периферийных базах весит примерно одинаково, а вот файл итогов и остатков (RG*) на периферийных базах оказывается в два раза больше, чем на ЦБ.

Здесь играют роль два фактора:

1. Незакрытые («грязные») остатки. На периферийные базы документы могут мигрировать выборочно (в зависимости от настроек миграции складов, фирм или контрагентов). Если в ПБ попадают только расходные документы, но не приходят приходные (или наоборот), то итоги по регистру в разрезе аналитики «не закрываются» в ноль. В базе плодятся тысячи записей с нулевым количеством, но ненулевой суммой (или наоборот), из-за чего таблица RG* стремительно раздувается.
2. Отсутствие упаковки таблиц. В формате DBF записи при обнулении остатков физически не удаляются из файла, а лишь помечаются как удаленные. Если на ЦБ регулярно выполняется тестирование и исправление (ТИИ), то на ПБ таблицы итогов могут годами накапливать этот «мусор».

Для исправления ситуации выполним полный пересчет итогов по конкретному регистру. Разберем по шагам, как инициировать полный пересчет итогов для одного регистра (например, партий), чтобы не тратить время на пересчет всей базы:

1. Создайте резервную копию базы данных.
2. Перейдите в каталог базы данных и найдите файлы нужного регистра (например, для регистра «ПартииНаличие» это будут файлы RGXXXX.dbf/cdx и RAXXXX.dbf/cdx, где XXXX — внутренний идентификатор регистра в файле 1cv7.dd).
3. Скопируйте эти файлы в отдельную временную папку.
4. В рабочей папке удалите только файл итогов RGXXXX.dbf и его индекс RGXXXX.cdx, оставив файл движений RAXXXX.dbf.
5. Запустите 1С:Предприятие в монопольном режиме.
6. Перейдите в меню «Операции» — «Управление оперативным учетом». Нажмите кнопку изменения точки актуальности (ТА) — сдвиньте ее назад на первый документ, а затем верните обратно на текущую дату.
7. Система автоматически пересчитает и физически пересоздаст файл итогов RGXXXX.dbf с нуля, удалив все незакрытые пустые записи. Размер файла существенно уменьшится.

---

Причина 3: Раздувание таблицы регистрации изменений 1supdts.dbf

Таблица 1supdts.dbf хранит информацию обо всех измененных объектах, которые ожидают отправки в периферийные базы. В процессе интенсивного обмена этот файл может раздуваться до огромных размеров (в сотни мегабайт), хотя активных записей в нем может быть всего несколько десятков.

Это связано со спецификой работы СУБД DBF. При успешном завершении обмена 1С помечает записи в 1supdts.dbf как удаленные (в начале строки ставится символ *), но физически строка остается в файле и продолжает занимать место на диске.

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

1. Запустите Конфигуратор монопольно.
2. Откройте меню «Администрирование» — «Тестирование и исправление ИБ».
3. Установите флажок «Упаковка таблиц» и запустите процесс.

Если вам требуется очистить зависшие или ошибочные регистрации изменений вручную (когда обмен завершен, файлы обмена пусты, но таблица изменений забита «мусором»), можно использовать DBF-редакторы для выполнения команды ZAP или PACK для файла 1supdts.dbf. После этого размер файла мгновенно уменьшится до минимальных 70-80 КБ.

---

Причина 4: Проблема работы УРИБ на Windows Server 2008/2012 x64 (русские префиксы баз)

Разберем важную системную проблему, упомянутую в обсуждении. При работе 1С 7.7 в терминальном режиме на современных 64-битных операционных системах (начиная с Windows Server 2008 x64) часто наблюдается сбой, при котором система «гоняет по кругу» одни и те же старые документы в обмене.

Причина кроется в кодировке и сортировке (OrdNoChan):
Платформа 1С 7.7 чувствительна к кодовой странице и региональным настройкам ОС. Если коды информационных баз в УРИБ заданы кириллицей (например, префиксы баз ЦБ, ПБ1, ПБ2), то из-за различий в механизмах сравнения строк и сортировки на уровне ядра Windows x64 1С 7.7 некорректно обрабатывает подтверждения приема пакетов от периферийных баз.

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

Рекомендации по устранению сбоя:

• При создании распределенной информационной базы всегда используйте для кодов (префиксов) баз только латинские символы в верхнем регистре (например, CB, PB1, PB2).
• Избегайте использования кириллицы в путях к каталогам обмена.
• Для решения проблем с кодовой страницей на современных ОС используйте специальный пустой файл-маркер dbfnocollate.lst (или примените патч отключения проверки кодовой страницы OrdNoChan в конфигураторе).

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