При настройке регулярного обмена данными между конфигурациями 1С на базе Библиотеки стандартных подсистем (БСП) часто возникает вопрос: что произойдет с документами, которые уже находятся в базе-приемнике, если мы передвинем дату начала выгрузки в настройках синхронизации на более поздний период? Существует распространенное мнение, что система автоматически пометит "старые" документы на удаление, так как они перестанут соответствовать условиям фильтра. Разберем эту ситуацию подробно, проанализируем внутренние механизмы платформы и выясним, как провести настройку без потери данных.
В современных конфигурациях 1С реализован механизм контроля соответствия данных настроенным фильтрам. Когда мы устанавливаем дату начала выгрузки, мы создаем фильтр. Если документ уже был передан в базу-приемник, а затем мы меняем дату начала обмена на более позднюю, система может расценить это как ситуацию, в которой «объект перестал соответствовать условиям отбора».
Рассмотрим, как это работает на практике. В типовых правилах синхронизации при изменении настроек фильтрации (в том числе даты) система может инициировать регистрацию удаления для объектов, которые ранее входили в обмен, а теперь — нет. Это делается для поддержания идентичности данных в двух базах: если документ больше не должен «участвовать» в обмене, он должен быть удален из приемника, чтобы не искажать отчетность. Однако важно понимать, что это происходит не магическим образом, а через таблицу РегистрацияИзменений (планы обмена).
Проанализируем ситуацию, когда данные изначально были перенесены не через штатный механизм синхронизации, а с помощью обработки Универсальный обмен данными в формате XML. Это ключевой момент. В этом случае:
RegisterRecords) записей об этих документах нет.Важный нюанс: Если вы сначала настроили регулярный обмен, выгрузили часть данных, а потом решили «откатить» или «подвинуть» дату — риск удаления возрастает, так как записи в плане обмена уже существуют.
Выясним причину, почему в одних случаях документы удаляются физически, а в других — только помечаются на удаление. Нужно четко разделять два технологических подхода:
DeletionMark = Истина. Это дает администратору шанс восстановить данные, если настройки были изменены ошибочно.Самым надежным способом защиты документов в базе-приемнике является использование механизма «Даты запрета загрузки данных». Рассмотрим алгоритм действий:
Перед тем как выполнить первый обмен после изменения даты, проанализируем состав накопленных изменений. Для этого воспользуемся стандартной обработкой Регистрация изменений для обмена. Выполним следующие шаги:
Для ручной очистки регистрации можно использовать программный метод (в консоли кода), чтобы не удалять тысячи записей вручную через интерфейс:
ПланОбменаУзел = ПланыОбмена.СинхронизацияДанныхЧерезУниверсальныйФормат.НайтиПоНаименованию("Узел_УХ");
Выборка = ПланыОбмена.ВыбратьИзменения(ПланОбменаУзел, 1);
Пока Выборка.Следующий() Цикл
ОбъектИзменения = Выборка.Данные;
Если ТипЗнч(ОбъектИзменения) = Тип("ДокументСсылка.РеализацияТоваровУслуг") Тогда
Если ОбъектИзменения.Дата < '20190101' Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(ПланОбменаУзел, ОбъектИзменения);
КонецЕсли;
КонецЕсли;
КонецЦикла;
При использовании ручного переноса через XML с последующим переходом на регулярный обмен, критически важно, чтобы Уникальные Идентификаторы (GUID) объектов в обеих базах совпадали. Если при XML-выгрузке не была установлена опция «Использовать формат обмена с сохранением ИД», то при начале регулярного обмена система не сможет сопоставить документы. В результате вы получите дубликаты документов в базе-приемнике, а старые (ручные) документы могут остаться нетронутыми, но «оторванными» от процесса синхронизации.
ПриОтправкеДанных, объект может уйти в приемник.Таким образом, изменение даты начала обмена — процедура не опасная, если понимать, как система работает с регистрацией изменений и идентификаторами объектов.