Как выборочно регистрировать изменения документов одного вида в УРБД 1С 7.7?

← На главную

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

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

Почему штатный метод РегистрацияИзменений() не решает задачу?

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

Встроенный язык 1С 7.7 предоставляет метод РегистрацияИзменений(Параметр), где параметр может принимать значения 1 (включить регистрацию) или 0 (отключить регистрацию). Однако этот метод работает исключительно в рамках тех правил миграции, которые жестко заданы для данного метаданного в Конфигураторе:

Если для документа «Чек ККМ» задано правило «Место создания — центр», то вызов РегистрацияИзменений(1) лишь принудительно запишет признак изменения для передачи в центральную базу (если документ создан на периферии), но платформа физически не сможет отправить его в другие периферийные базы, так как у нее нет такой инструкции в правилах автообмена.
Если попытаться передать только движения регистров (например, по регистру «Продажи» или «Остатки товаров») без передачи самого документа-регистратора, система выдаст ошибку либо эти движения будут потеряны. В 1С 7.7 жестко действует правило: нет документа — нет и его движений. Любая попытка записать движения напрямую в таблицы итогов без физического присутствия документа-регистратора в базе приведет к тому, что первая же процедура «Тестирования и исправления» (ТиИ) безвозвратно удалит эти «осиротевшие» записи.

Для обхода этого ограничения нам придется использовать более глубокие технические решения. Рассмотрим их по шагам.

Решение 1. Прямая модификация системной таблицы регистрации 1SUPDTS (для MS SQL Server)

Это наиболее технологичный способ, если ваша информационная база работает под управлением СУБД MS SQL Server. Все зарегистрированные изменения объектов, которые ожидают отправки при следующем сеансе УРБД, хранятся в специальной таблице _1SUPDTS (в файловой версии это файл 1SUPDTS.dbf).

Давайте разберем структуру таблицы _1SUPDTS:

TYPEID — внутренний числовой идентификатор типа метаданных (например, конкретного вида документа или справочника).
OBJID — уникальный 9- или 13-символьный идентификатор самого объекта (конкретного документа).
DBSIGN — трехсимвольный код информационной базы-получателя (соответствует кодам из таблицы _1SDBSET).

Выяснив это, мы можем программно добавлять записи в эту таблицу для нужных баз-получателей в момент проведения документа. Рассмотрим пример реализации с использованием внешней компоненты 1CPP.dll или прямого ADO-соединения:


// Примерный алгоритм в модуле документа "ЧекККМ" при проведении:
Процедура ОбработкаПроведения()
    // Основной код проведения документа
    // ...
    
    // Проверяем, является ли данный чек продажей сертификата
    Если ЭтоПродажаСертификата = 1 Тогда
        // Нам необходимо зарегистрировать этот документ во ВСЕ периферийные базы
        // 1. Получаем список всех периферийных баз (DBSTATUS = 'C' в таблице _1SDBSET)
        // 2. Для каждой базы выполняем прямую вставку в таблицу _1SUPDTS
        
        // Ниже приведен пример SQL-запроса через класс "ODBCRecordset" (компонента 1С++)
        ЗапросSQL = СоздатьОбъект("ODBCRecordset");
        
        ТекстЗапроса = "
        |INSERT INTO _1SUPDTS (TYPEID, OBJID, DBSIGN)
        |SELECT 
        |   :ИдТипаДокумента, 
        |   :ИдДокумента, 
        |   DBSIGN 
        |FROM 
        |   _1SDBSET 
        |WHERE 
        |   DBSTATUS = 'C'
        |";
        
        ЗапросSQL.УстановитьТекстовыйПараметр("ИдТипаДокумента", ПолучитьИдМетаданных(ТекущийДокумент()));
        ЗапросSQL.УстановитьТекстовыйПараметр("ИдДокумента", ЗначениеВСамойДлиннойСтрокеБД(ТекущийДокумент()));
        ЗапросSQL.Выполнить(ТекстЗапроса);
    КонецЕсли;
КонецПроцедуры

Важное предупреждение: Прямая запись в таблицы DBF-формата (1SUPDTS.dbf) крайне не рекомендуется в многопользовательском режиме. Без монопольного захвата таблицы или использования специализированных внешних компонент это гарантированно приведет к разрушению индексов файла 1SUPDTS.cdx и аварийному завершению работы пользователей.

Решение 2. Архитектурный обход — Разделение документов в метаданных

Если вы не хотите использовать прямые SQL-запросы или ваша база работает в файловом режиме (DBF), лучшим решением будет разделение сущностей на уровне конфигурации. Это самый стабильный и безопасный метод, который не зависит от платформенных багов.

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

Откроем Конфигуратор и найдем документ ЧекККМ.
Создадим его точную копию (клон) с идентификатором, например, ЧекНаПродажуСертификата.
Для обычного документа ЧекККМ оставляем стандартное правило миграции: «Место создания — центр». Это гарантирует, что рутинные продажи не будут засорять базы других торговых точек.
Для нового документа ЧекНаПродажуСертификата устанавливаем правило миграции: «Все информационные базы».
В интерфейсе кассира (в форме регистрации продаж) настраиваем автоматический выбор: если в корзину добавляется позиция с типом «Подарочный сертификат», программа должна создавать и проводить не обычный ЧекККМ, а именно ЧекНаПродажуСертификата.

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

Решение 3. Использование фиктивной «Транспортной Точки» (Гибридный метод)

Если создавать новый документ не хочется из-за сложности переделки большого количества отчетов, можно применить изящный трюк с виртуальным получателем в УРБД. Этот метод подходит как для SQL, так и для DBF версий.

Проанализируем этот сценарий:

В настройках распределенной базы в Конфигураторе создаем фиктивную периферийную базу с трехсимвольным кодом, например, "ТП" (Транспортная Половина). Реально выгрузку для этой базы делать никто никогда не будет.
Для документа ЧекККМ устанавливаем правило миграции «Место создания и центр», а в поле «Дополнительно» через запятую прописываем код нашей фиктивной базы ТП.
Теперь при записи абсолютно любого чека ККМ платформа автоматически генерирует строки регистрации в 1SUPDTS для центральной базы и для базы ТП.
Перед запуском штатного сеанса автообмена мы запускаем простой регламентный скрипт (обработку), который анализирует все записи в таблице 1SUPDTS, предназначенные для получателя ТП:
- Если документ, привязанный к этой записи, является обычным чеком, мы просто удаляем запись регистрации для базы ТП.
- Если это чек на продажу сертификата, мы заменяем в поле DBSIGN значение "ТП" на коды всех реальных периферийных баз (либо размножаем эту строчку для каждой из реальных баз).

Этот способ элегантен тем, что вам не нужно вручную генерировать внутренние идентификаторы типов метаданных (TYPEID) и документов (OBJID). Сама платформа создает корректные строки регистрации, а ваша задача сводится лишь к умной фильтрации и подмене адресата перед отправкой почты УРБД.

Решение 4. Переход на внешние системы обмена (МОД или XML)

Если бизнес-требования к миграции данных постоянно усложняются (например, требуется отправлять документы только по определенным складам, организациям или группам товаров), стандартный механизм УРБД 1С 7.7 становится слишком тесным.

В этом случае имеет смысл полностью или частично отказаться от платформенного обмена в пользу специализированных решений:

МОД (Модуль обмена данными) — популярное в среде 7.7 решение, позволяющее гибко настраивать правила регистрации любых объектов через визуальные правила, аналогичные современным «Конвертациям данных».
Самописные обмены на базе XML (с использованием компоненты v7plus.dll). В этом сценарии вы сами контролируете выгрузку: при записи документа, подлежащего отправке, выгружаете его структуру в XML-файл и отправляете по доступным каналам связи (FTP, Email, Web-сервисы) на конкретные точки. На точках специализированная обработка загружает этот файл и создает документ.

Резюме

Мы подробно разобрали особенности работы УРБД в 1С 7.7. Для решения проблемы выборочной миграции чеков ККМ наиболее предпочтительными являются два пути: создание отдельного вида документа для продажи сертификатов (как самый надежный и не требующий программирования низкоуровневых таблиц метод) либо прямая вставка записей в таблицу 1SUPDTS (для баз на MS SQL Server, где критически важно сохранить единую структуру документов).