При эксплуатации распределенных информационных баз (УРБД) на платформе 1С:Предприятие 7.7 часто возникает классическая архитектурная проблема. Центральная база (ЦБ) переводится на высокопроизвительную СУБД MS SQL, что снимает ограничения на объем данных. Однако периферийные базы (ПБ) на торговых точках остаются работать в файловом формате DBF из-за экономии на лицензиях СУБД или слабого оборудования на местах.
Со временем таблицы регистров накопления (в частности, партионный регистр RA328.dbf) на периферии неумолимо приближаются к критическому физическому лимиту СУБД Clipper/FoxPro — 2 ГБ. База начинает работать нестабильно, происходят сбои при индексации, а файлы обмена переносят гигабайты избыточной информации (например, приходы от поставщиков, которые на точках вообще не требуются). Разберем по шагам, как решить эту проблему, исключить лишние данные из миграции и оптимизировать работу партионного учета на филиалах.
---
Штатный механизм УРБД регистрирует изменения всех измененных объектов для всех баз, куда разрешена миграция по правилам конфигурации. Чтобы предотвратить попадание ненужных документов и их движений в файлы обмена для конкретных периферийных баз, мы можем принудительно очищать системную таблицу регистрации изменений 1SUPDTS перед запуском процесса выгрузки.
Проанализируем структуру таблицы 1SUPDTS. Она содержит три ключевых поля:
DBSIGN — код информационной базы-получателя.TYPEID — тип зарегистрированного объекта (справочник, документ и т.д.).OBJID — внутренний идентификатор объекта.Поскольку центральная база у нас работает под управлением MS SQL, мы можем выполнять транзакции очистки мгновенно с помощью прямого SQL-запроса перед стартом обмена. Рассмотрим пример такого запроса, который удаляет регистрацию документов перемещения для ПБ, если склад-получатель в документе не соответствует складу этой периферийной базы:
-- Пример SQL-запроса для очистки лишней регистрации документов в ЦБ
DELETE FROM _1supdts
WHERE DBSIGN = 'П01' -- Код периферийной базы ПБ1
AND TYPEID = 'DM' -- Идентификатор типа метаданных документа ПеремещениеТМЦ
AND OBJID IN (
SELECT ID
FROM _1SJOURN
WHERE IDDOC = OBJID
AND SP345 <> ' 125 ' -- SP345 - реквизит СкладПолучатель (ID нужного склада ПБ1)
);
Для предотвращения конфликтов блокировок («дедлоков») во время активной работы пользователей в ЦБ, данный запрос следует выполнять в рамках быстрой транзакции либо использовать хинты оптимизатора SQL (например, WITH (ROWLOCK)). Если очистку требуется производить на стороне файловой периферийной базы (под DBF), рекомендуется использовать внешнюю компоненту 1CPP и драйвер VFPOLEDB, который позволяет выполнять SQL-запросы к DBF-файлам в режиме Exclusive=No без монопольной блокировки таблиц:
// Пример кода на языке 1С 7.7 для очистки DBF через 1CPP
Коннектор = СоздатьОбъект("ADODB.Connection");
Коннектор.ConnectionString = "Provider=VFPOLEDB.1;Data Source=" + КаталогИБ() + ";Deleted=Yes;Exclusive=No;";
Коннектор.Open();
Запрос = "DELETE FROM 1supdts WHERE DBSIGN = 'ЦБ' AND TYPEID = 'DR' AND OBJID IN (SELECT ID FROM ...)";
Коннектор.Execute(Запрос);
Коннектор.Close();
---
Одной из главных причин разрастания партионных регистров на филиалах является то, что при перемещении товаров из центра на точку мигрирует вся цепочка партиеобразующих документов. Если товар пришел в центр по импортному поступлению, то на ПБ улетает и само это поступление, и его проводки. В результате ПБ хранит данные о закупках, которые ей не нужны.
Рассмотрим альтернативный вариант — переход на ордерную схему перемещения товара, состоящую из двух независимых документов:
При такой схеме у каждого филиала формируется собственный локальный партионный учет. Себестоимость партии на ПБ может заполняться на основании данных перемещения из центра (по средневзвешенной или учетной цене), но при этом сама база филиала полностью изолирована от документов прихода головного офиса. Чтобы связать цепочку документов для сквозной отчетности в ЦБ, достаточно добавить в приходный документ ПБ текстовый реквизит НомерДокументаИсточника.
---
Если мы решаем просто не выгружать в периферийную базу первичные приходные документы (например, ПоступлениеТМЦ), но при этом выгружаем элементы справочника Партии, реквизит ДокументОприходования в справочнике на ПБ примет вид <Объект не найден>[ID] (так называемая «битая ссылка»).
Выясним причину, почему это не является критичным для типовой конфигурации «Торговля и Склад 7.7» (TiС):
Партии (например, к реквизитам ЗакупочнаяЦена, Поставщик, СтранаПроисхождения).ДокументОприходования) при проведении по партиям практически никогда не считывается через точку. Он служит лишь визуальной ссылкой для пользователей.Таким образом, наличие битых ссылок в партиях технически не нарушает корректность списания себестоимости на точках. Если же битые ссылки вызывают эстетический дискомфорт у пользователей или мешают формированию локальных отчетов, можно применить программное создание «заглушек» (пустых документов-болванок) на ПБ:
// Функция автосоздания заглушки для исключения "Объект не найден"
Процедура СоздатьЗаглушку(ТипДокумента, ИдентификаторДокумента)
Док = СоздатьОбъект("Документ." + ТипДокумента);
Если Док.НайтиПоИдентификатору(ИдентификаторДокумента) = 0 Тогда
Док.Новый();
Док.УстановитьАтрибут("НомерДок", "ЗАГЛУШКА_" + ИдентификаторДокумента);
Док.УстановитьАтрибут("Комментарий", "Создано автоматически для исправления битой ссылки УРБД");
Док.Записать();
// Метод установки системного ИД для точного соответствия ссылке
УстановитьСистемныйИД(Док, ИдентификаторДокумента);
КонецЕсли;
КонецПроцедуры
---
Для минимизации нагрузки на базы филиалов можно использовать механизм разделения программного кода проведения документов в зависимости от того, в какой базе выполняется код. Разберем по шагам, как это реализовать:
ПеремещенияТМЦ) используем директиву #ЗагрузитьИзФайла или системную функцию проверки кода базы.Это позволит полностью отключить ведение тяжелого партионного регистра RA328 на ПБ, где в нем нет управленческой необходимости (например, на розничных точках без оптовых отгрузок), оставив там легкий количественный учет.
---
Для крупных распределенных сетей отличным решением является гибридный подход, совмещающий надежность штатного УРБД и гибкость Модуля обмена данными (МОД) от компании «Рарус»:
1SUPDTS автоматически при любой транзакции записи объектов). Это гарантирует, что ни одно изменение не будет потеряно.1SUPDTS, анализирует их по сложным правилам (например, очищает табличные части документов по чужим складам, убирает движения по партиям) и формирует компактные XML-файлы для отправки на точки.1SUPDTS.Этот подход позволяет сократить объем баз данных на точках в 5–10 раз без внесения радикальных изменений в конфигурацию и без риска рассинхронизации данных.