Как правильно выделить фирму в отдельную базу при УРБД в 1С 7.7?

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

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

1. Создать в Центральной базе новую фирму «СВ» и новый узел обмена, выгрузить начальные данные в пустую папку.
2. Сохранить из этой папки файлы настроек УРБД (1sdbset, 1sdwnlds, 1supdts и 1ssystem).
3. Скопировать рабочую базу «СП» (где есть все данные) в новую папку для «СВ».
4. В исходной базе «СП» удалить все документы новой фирмы «СВ».
5. В новой скопированной базе «СВ» удалить все документы по остальным фирмам (оставив только нужные).
6. Подложить сохраненные системные файлы УРБД в новую базу и запустить обмен.

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

Проблема №1: Несанкционированное удаление документов в Центральной базе

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

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

Решение:

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

1. Самый простой (но радикальный) способ для файловой базы — физически очистить или удалить файл 1supdts.dbf перед первым обменом. Это сотрет всю очередь исходящих сообщений. Внимание: при этом вы потеряете регистрацию изменений и по тем объектам (например, новым справочникам), которые действительно нужно было отправить в ЦБ.
2. Более тонкий способ, если база работает на MS SQL Server — выборочно очистить таблицу _1SUPDTS. Мы можем удалить из нее только те строки, где зафиксировано именно удаление объектов (обычно они имеют признак DELETED = '1' или статус 'D'), оставив обычные изменения нетронутыми.

Проблема №2: Конфликт маршрутизации и DBSIGN

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

Посмотрим на структуру идентификатора документа. В 1С 7.7 каждый объект имеет уникальный код — IDDOC, длиной 9 символов. Первые 6 символов — это уникальный номер в рамках базы, а последние 3 символа — это код базы-создателя (так называемый DBSIGN).

Если исходная база «СП» имела код узла 001, то все исторические документы скопированной фирмы «СВ» имеют в конце своего IDDOC символы 001. Когда мы подключили новую базу к обмену под новым кодом (например, 002), мы не изменили внутренние идентификаторы старых документов.

Что произойдет дальше?

Рано или поздно пользователь в новой базе «СВ» (узел 002) откроет старый документ (созданный еще в узле 001) и перепроведет его, либо просто изменит комментарий. База зарегистрирует изменение и отправит документ в Центр.

Центральная база примет измененный документ. Однако, система маршрутизации УРБД посмотрит на IDDOC документа, увидит там суффикс 001 и решит, что «родной» базой для этого документа по-прежнему является база «СП»! При следующем обмене Центральная база выгрузит эти изменения обратно в базу «СП», где этот документ вообще-то был удален в самом начале нашего разделения. Возникнет коллизия, появление документов-фантомов и полная неразбериха в учете.

Решение проблемы DBSIGN:

Оставлять «чужие» dbsign в базе категорически нельзя. Необходимо провести сложную процедуру замены суффиксов во всех таблицах, где упоминаются документы. Это делается прямыми запросами к СУБД (MS SQL) или скриптами в FoxPro для DBF-версий.

Вам потребуется обновить последние 3 символа поля IDDOC на новый код узла во множестве таблиц:

1. В общем журнале документов (1SJOURN).
2. В таблицах шапок каждого вида документа (DH*).
3. В табличных частях (DT*).
4. В таблицах движений регистров (RA*) и проводках (1SENTRY), если требуется сохранить историю движений.

Пример логики для SQL (только как иллюстрация подхода к замене):

-- Извлечение кода DBSIGN из IDDOC
-- DBSIGN = SUBSTRING(IDDOC, 7, 3)

-- Концепция обновления (требует точного написания под конкретные таблицы)
UPDATE _1SJOURN
SET IDDOC = SUBSTRING(IDDOC, 1, 6) + 'НовыйКод'
WHERE SUBSTRING(IDDOC, 7, 3) = 'СтарыйКод'

После любых манипуляций с таблицами напрямую обязательно требуется полная переиндексация базы!

Альтернативный метод: Использование «Де-УРБД»

Чтобы избежать описанных проблем с синхронизацией удалений и рисками повреждения ЦБ, опытные специалисты часто используют метод временного отключения от УРБД.

Рассмотрим этот алгоритм по шагам:

1. Делаем копию исходной базы в новую папку.
2. Превращаем копию в обычную локальную базу. Для этого удаляем файлы обмена (1sdbset.*, 1sdwnlds.*, 1supdts.*). В файле 1ssystem.dbf (или таблице _1SSYSTEM в SQL) очищаем поле DBSIGN и обнуляем DBSETUUID.
3. Запускаем базу конфигуратором, делаем любое фиктивное изменение, сохраняем. Теперь это полностью независимая база.
4. Спокойно удаляем в ней все ненужные документы по другим фирмам. Поскольку база больше не в УРБД, никакие таблицы изменений не заполняются, Центру ничего не угрожает.
5. После очистки данных, мы можем либо подключить эту локальную базу обратно к УРБД как новый узел (прописав ей новые системные файлы), либо — что является самым чистым и правильным путем — перенести оставшиеся очищенные данные с помощью универсального обмена XML в официально созданную, чистую периферийную базу. Перенос через XML автоматически сформирует правильные IDDOC для новой базы.

Дополнительный нюанс: ограничение выгрузки в 2 Гб

При попытке создать периферийную базу штатным средством через Конфигуратор, вы можете столкнуться с тем, что система выдаст ошибку, если объем выгружаемых данных превышает 2 Гб. Это ограничение встроенного ZIP-архиватора 1С 7.7.

Если ваши базы объемные и работают на SQL, штатную выгрузку можно обойти. Создается копия базы ЦБ средствами SQL (через backup/restore) под новым именем. Затем в этой копии с помощью SQL-скрипта корректируются таблицы настроек _1SDBSET и _1SSYSTEM: статус базы меняется с Центральной на Периферийную, и ей принудительно назначается новый код DBSIGN. После этого из нее вырезаются лишние данные. Этот метод требует глубокого понимания архитектуры, но позволяет разворачивать узлы любого размера.

Подводя итог, выделение фирмы копированием базы — это не просто «скопировал и удалил». Это сложный процесс, требующий контроля над таблицами регистрации изменений (1supdts) и обязательной корректировки внутренних идентификаторов (dbsign). Если проигнорировать эти технические требования, вы получите разрушенную логику обмена и потерю данных в центральной системе.