Почему при обмене в 1С 7.7 изменения из периферийной базы затираются центральной?

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

Внутреннее устройство механизма автообмена и приоритет узлов в 1С 7.7

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

Для платформы понятие времени между двумя сеансами обмена считается единым неделимым моментом времени. Если один и тот же объект был изменен и в центральной, и в периферийной базе, платформа не сравнивает системное время или метки изменения объектов. При загрузке пакета из ЦБ в ПБ версия центрального узла безусловно перетрет все локальные правки.

Рассмотрим, как работает фиксация и квитирование (подтверждение) изменений:

1. Регистрация изменений ведется на уровне таблиц базы данных: список измененных объектов фиксируется в системной таблице _1SUPDTS (или файле 1SUPDTS.DBF), а служебная информация о переданных и принятых пакетах — в таблице 1SDWNLDS. Структура узлов описывается в 1SDBSET.
2. Документ в 1С 7.7 мигрирует как неделимый ведущий объект со всеми своими движениями, строками и проводками.
3. Когда база-источник формирует файл выгрузки, объект попадает в пакет, но отметка о необходимости выгрузки с него не снимается до тех пор, пока от базы-приемника не придет ответный файл с подтверждением успешного приема данных.
4. Если ЦБ выгрузила документ, а ПБ еще не вернула квитанцию о приеме, то при каждой следующей выгрузке из ЦБ этот документ будет повторно отправляться в ПБ, затирая любые локальные правки, сделанные пользователями периферии за это время.

Способ 1. Программное разграничение прав на редактирование объектов

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

Выясним, с помощью каких встроенных функций УРБД можно определить происхождение объекта и текущий узел:

1. ИБСозданияОбъекта(<Объект>) — возвращает строковый трехсимвольный идентификатор информационной базы, где объект был изначально создан.
2. ТекущаяИБЦентральная() — возвращает 1, если код выполняется в центральной базе, и 0, если в периферийной.
3. ТекущаяИБКод() — возвращает код текущей базы данных.

Посмотрим на пример реализации проверки в модуле формы документа в процедуре ПриОткрытии:

Процедура ПриОткрытии()
    // Запрещаем редактирование документов периферийной базы в центральной
    Если ТекущаяИБЦентральная() = 1 Тогда
        Если ИБСозданияОбъекта(ТекущийДокумент()) <> ТекущаяИБКод() Тогда
            Форма.ТолькоПросмотр(1);
            Предупреждение("Документ создан в филиале! Редактирование в центральной базе запрещено.", 5);
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Дополнительно защитим объект на уровне модуля документа в предопределенной процедуре ПриЗаписи, чтобы исключить программную перезапись:

Процедура ПриЗаписи()
    Если ТекущаяИБЦентральная() = 1 Тогда
        Если ИБСозданияОбъекта(ТекущийДокумент()) <> ТекущаяИБКод() Тогда
            Сообщить("Запрещена запись документа, созданного в другой ИБ!", "!");
            СтатусВозврата(0);
            Возврат;
        КонецЕсли;
    КонецЕсли;
КонецПроцедуры

Способ 2. Тонкая настройка областей миграции и ручная регистрация изменений

Рассмотрим возможности конфигуратора для ограничения передачи лишних данных между базами:

1. Область миграции метаданных: В свойствах каждого документа или справочника можно выбрать область миграции, например «Место создания и ЦБ» или правила фильтрации по реквизитам (по подразделению, фирме или складу). Это исключит передачу чужих документов между периферийными узлами.
2. Отключение авторегистрации: Для часто перепроводимых в ЦБ документов можно отключить флаг «Автоматическая регистрация изменений». В этом случае изменения регистрируются программно с помощью метода РегистрацияИзменений(<Объект>, <Режим>) только при реальной модификации реквизитов пользователем, что убережет документы от ложной выгрузки при регламентном групповом перепроведении.

Способ 3. Построение корректного регламента пакетного обмена

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

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

1. Формирование и выгрузка пакета данных из периферийной базы (ПБ).
2. Доставка пакета в центральную базу (ЦБ) и его обязательная загрузка.
3. Выполнение необходимых регламентных процедур в ЦБ.
4. Формирование ответной выгрузки из ЦБ (в этот момент сформируется квитанция о принятии предыдущего пакета ПБ).
5. Доставка пакета ЦБ в ПБ и финальная загрузка в периферийный узел.

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