При работе с распределенными информационными базами (УРБД) в платформе 1С:Предприятие 7.7 разработчики часто сталкиваются с жестким ограничением правил миграции. Типичная ситуация: в компании функционирует центральный офис и несколько магазинов (периферийных баз). По умолчанию для приходных накладных настраивается правило миграции «Место создания и центр». Это гарантирует, что документы, созданные на точках, попадают в офис, но не засоряют базы других магазинов.
Однако, как только открывается новая торговая точка, где нет квалифицированного оператора (например, работает только кассир), возникает необходимость оформлять приходные накладные непосредственно в центральном офисе и отправлять их строго в один конкретный магазин. Если оставить правило «Место создания и центр», документ, созданный в офисе, вообще не уйдет на периферию, так как местом его создания является центр. Если же переключить правило на «Все информационные базы», то накладные для нового магазина полетят во все торговые точки, неоправданно раздувая их базы данных и раскрывая коммерческую информацию.
В этой статье мы подробно рассмотрим и проанализируем четыре проверенных временем способа решения этой задачи, начиная от простых организационно-программных схем и заканчивая низкоуровневым вмешательством в таблицы регистрации изменений.
---
Этот метод хорош тем, что он реализуется исключительно штатными средствами платформы 1С 7.7 и не требует прямого вмешательства в системные таблицы базы данных. Мы используем логику работы УРБД в своих интересах.
Рассмотрим по шагам принцип работы этой схемы:
IDDOC). Оператор меняет дату на текущую, заполняет контрагента, склад, табличную часть товарами и проводит документ.Главный недостаток этого метода — необходимость постоянного контроля наличия свободных заготовок и некоторое неудобство для операторов центрального офиса, которым приходится работать с уже существующими объектами вместо создания новых «в один клик».
---
Это технически более сложный, но максимально автоматизированный для пользователя путь. Каждое изменение или создание объекта в 1С 7.7 регистрируется в специальной таблице. Для файловой версии (DBF) это файл 1SUPDTS.DBF, для SQL-версии — таблица _1SUPDTS.
Выясним структуру таблицы регистрации изменений 1SUPDTS:
IDDOC для документов).Проанализируем ситуацию: если документ создан в центральной базе, 1С не запишет в эту таблицу строку для периферийной базы, так как это не предусмотрено правилом миграции. Наша задача — программно «обмануть» систему обмена и принудительно добавить запись в эту таблицу.
Посмотрим на пример реализации этого механизма при проведении документа в центральной базе. Мы можем использовать встроенный объект XBase для работы с файлом регистрации изменений напрямую:
Процедура ПриЗаписи()
// Проверяем, что документ записывается именно в Центральной Базе
Если ИмяТекущейБазы() = "ЦБ" Тогда
// Определяем код базы-получателя (например, Магазин №3 имеет код "М03")
КодПолучателя = "М03";
// Получаем внутренний IDDOC документа (9-символьный вид)
ВнутреннийИдентификатор = ЗначениеВСтрокуВнутреннее(ТекущийДокумент());
IDDOCДок = Сред(ВнутреннийИдентификатор, 11, 9);
// Открываем таблицу регистрации изменений напрямую
ТаблицаРегистрации = СоздатьОбъект("XBase");
ТаблицаРегистрации.ОткрытьФайл(КаталогИБ() + "1SUPDTS.DBF");
// Позиционируемся или добавляем новую запись
ТаблицаРегистрации.Новая();
ТаблицаРегистрации.DBSIGN = КодПолучателя;
// Укажем TYPEID для нашего вида документа (можно получить через Метаданные)
ТаблицаРегистрации.TYPEID = " 1DL"; // Пример ID типа документа ПриходнаяНакладная
ТаблицаРегистрации.OBJID = IDDOCДок;
ТаблицаРегистрации.Записать();
ТаблицаРегистрации.ЗакрытьФайл();
КонецЕсли;
КонецПроцедуры
Важное предупреждение: При работе с DBF-файлами напрямую крайне важно следить за монопольным доступом и индексами. Если во время записи таблицы 1SUPDTS другой пользователь будет выполнять штатные операции, это может привести к повреждению файла. Поэтому этот метод требует высокой квалификации разработчика и осторожности.
---
Этот метод представляет собой гибрид первых двух вариантов. Он исключает риски прямого повреждения файлов базы данных, но при этом автоматизирует процесс адресации документов.
Разберем по шагам, как настроить такую архитектуру:
ТП (Точка-Получатель). Реальный обмен с этой базой никогда производиться не будет, файл переноса для нее создавать не нужно.ТП. Теперь любой документ этого вида, созданный в центре, автоматически регистрируется системой УРБД для отправки в базу ТП.1SUPDTS, предназначенные для получателя ТП.DBSIGN в таблице 1SUPDTS, заменяя фиктивный код ТП на реальный код магазина (например, М03).---
Если мы абсолютно не хотим вмешиваться в системные таблицы платформы и рисковать целостностью базы данных, рассмотрим разработку механизма на уровне бизнес-логики конфигурации.
Создадим новый документ под названием ТранспортПоступления. Настроим для него правило миграции «Все информационные базы». Данный документ будет содержать те же реквизиты шапки и табличную часть, что и обычная приходная накладная, а также дополнительный обязательный реквизит МагазинПолучатель.
Алгоритм работы выглядит следующим образом:
ТранспортПоступления, указывает в реквизитах конкретный магазин (например, Магазин №3), заполняет спецификацию товаров и проводит его.ПриЗагрузкеДанных (в глобальном модуле периферийной базы) мы пишем код обработки:
Процедура ОбработкаТранспорта()
// Проверяем, предназначен ли документ нашему магазину
Если СокрЛП(МагазинПолучатель.Код) = СокрЛП(Константа.КодТекущейБазы) Тогда
// Проверим, не создавали ли мы уже документ на основании этого транспорта
ДокРеал = СоздатьОбъект("Документ.ПриходнаяНакладная");
Если ДокРеал.НайтиПоРеквизиту("ДокументОснование", ТекущийДокумент(), 1) = 0 Тогда
// Создаем реальную локальную приходную накладную
ДокРеал.Новый();
ДокРеал.Контрагент = Контрагент;
ДокРеал.Склад = Склад;
ДокРеал.ДокументОснование = ТекущийДокумент();
// Копируем табличную часть из транспортного документа
ВыбратьСтроки();
Пока ПолучитьСтроку() = 1 Цикл
ДокРеал.НоваяСтрока();
ДокРеал.Номенклатура = Номенклатура;
ДокРеал.Количество = Количество;
ДокРеал.Цена = Цена;
ДокРеал.Сумма = Сумма;
КонецЦикла;
ДокРеал.Записать();
ДокРеал.Провести();
КонецЕсли;
Иначе
// В чужих магазинах этот транспортный документ просто игнорируется,
// либо его можно автоматически помечать на удаление, чтобы не занимать место.
КонецЕсли;
КонецПроцедуры
Этот метод гарантирует 100% стабильность работы распределенной базы, так как не использует недокументированных возможностей и прямого обращения к СУБД/DBF файлам. Единственным минусом является незначительное увеличение объема передаваемого почтового трафика, так как транспортный документ физически обходит все периферийные базы, хоть и обрабатывается только одной.
---
Мы подробно разобрали различные варианты решения проблемы избирательной миграции документов. Выбор конкретного метода зависит от масштаба вашей информационной системы и уровня квалификации программиста: