В практике работы с распределенными информационными базами и при синхронизации между различными конфигурациями (например, 1С:Бухгалтерия предприятия 3.0 и 1С:Комплексная автоматизация 2) технические специалисты часто сталкиваются со странным поведением системы: документ внезапно оказывается помеченным на удаление, хотя ни один пользователь этого не делал. При этом ни в Журнале регистрации, ни в Истории изменений объекта не удается найти внятных следов того, кто и когда совершил это действие. Рассмотрим подробнее, почему это происходит, как работает механизм очистки данных и как правильно организовать передачу документов за закрытые периоды.
Первое, с чем мы сталкиваемся при расследовании — это отсутствие записей в стандартных инструментах мониторинга. Вы открываете Журнал регистрации и видите события Данные.Изменение или Данные.Проведение, но события Данные.Отмена проведения или явной пометки на удаление пользователем нет — решить проблему поможет журналирование изменений и фиксация удаления объектов в 1С. Проанализируем ситуацию с точки зрения архитектуры платформы 1С.
Когда данные поступают в базу через механизм синхронизации (Enterprise Data), запись объектов происходит в специальном программном режиме. Для этого используется свойство ОбменДанными.Загрузка = Истина. Рассмотрим, к чему это приводит:
Загрузка. Это делается для ускорения обмена и предотвращения зацикливания.ПередЗаписью, ПриЗаписи), что позволяет загружать объекты «как есть», даже если они не соответствуют текущим правилам валидации в целевой базе.Выясним причину, по которой версионирование может не фиксировать пометку удаления. Если в настройках Хранения истории изменений для конкретного типа документа не установлена опция «Версионировать при обмене данными», то любые изменения, пришедшие по синхронизации, просто пролетят мимо истории версий.
Рассмотрим сценарий, описанный пользователями: бухгалтер меняет дату документа с прошлого месяца на текущий, проводит синхронизацию, а затем возвращает дату обратно. Казалось бы, документ просто должен обновиться, но система помечает его на удаление. Разберемся по шагам, что происходит в «мозгах» синхронизации.
В современных конфигурациях на базе БСП (Библиотеки стандартных подсистем) реализован механизм контроля соответствия данных фильтрам выгрузки. Когда в настройках синхронизации задана «Дата начала выгрузки», система создает логическую границу.
Соответствия объектов информационных баз. Теперь система «знает», что Объект_А в Бухгалтерии соответствует Объекту_А в Комплексной автоматизации по их внутренним идентификаторам (GUID).В этот момент срабатывает логика: если объект ранее уже был передан в другую базу, но теперь он «выпал» из фильтра (по дате, по организации или по другому условию), система считает, что в целевой базе этого объекта больше быть не должно. Проанализируем, как это реализуется технически: в план обмена для целевой базы записывается не само изменение документа, а специальное сообщение о регистрации удаления.
При следующем сеансе связи база-источник говорит целевой базе: «Помнишь документ с этим GUID? Так вот, он больше не входит в нашу выборку, удали его у себя». Целевая база, следуя инструкции, помечает документ на удаление.
Логика разработчиков 1С здесь прозрачна: синхронизация должна обеспечивать идентичность данных в рамках заданных правил. Если вы установили правило «Выгружать документы только с 1 января», а в целевой базе болтается документ от 15 декабря, который попал туда «случайно» (из-за ваших манипуляций с датами), это считается нарушением целостности фильтров. Механизм самоочистки устраняет это несоответствие.
Посмотрим на пример того, как программно может выглядеть проверка условия выгрузки в коде правил обмена (упрощенно):
Процедура ПередВыгрузкойОбъекта(Отказ, Объект)
Если Объект.Дата < ДатаНачалаВыгрузки Тогда
// Если объект уже был выгружен ранее,
// система инициирует его удаление в приемнике
ЗарегистрироватьУдалениеВПриемнике(Объект.Ссылка);
Отказ = Истина;
КонецЕсли;
КонецПроцедуры
Вместо того чтобы «обманывать» систему перемещением дат документов (что само по себе является плохой практикой, так как искажает последовательность событий и может влиять на расчеты), разберем правильные методы решения задачи.
Способ 1. Использование обработки «Регистрация изменений для обмена данными» — для этой задачи есть обработка массовой регистрации объектов в планах обмена.
В любой типовой конфигурации есть встроенная обработка (ее можно найти через «Параметры синхронизации данных» — «Состав отправляемых данных»). Она позволяет:
Способ 2. Временное изменение настроек синхронизации
Если необходимо перенести пачку документов за прошлый период, выполните следующие шаги:
При таком подходе документы за прошлый период останутся в целевой базе и не будут помечены на удаление, так как на момент обмена они «законно» входили в период выгрузки.
Способ 3. Настройка версионирования при обмене — поможет инструмент восстановления удаленных объектов и истории версий.
Чтобы в будущем видеть, кто именно (какой узел обмена) пометил документ на удаление, рекомендуем изменить настройки версионирования. Зайдите в раздел Администрирование — Общие настройки — История изменений — Настройки хранения. Для нужных документов установите режим «При записи» и обязательно проверьте, чтобы в дополнительных настройках (если они доступны в вашей версии БСП) было разрешено создание версий при загрузке данных.
Если вам все же нужно найти подтверждение в Журнале регистрации, попробуйте настроить фильтр не по событию «Данные.Изменение», а по событию «Обмен данными». При выполнении синхронизации через ОбменДанными.Загрузка = Истина, платформа фиксирует специфические системные события. Также обратите внимание на транзакции: пометка на удаление при обмене часто происходит в рамках одной большой транзакции загрузки пакета данных, и в журнале это может выглядеть как один блок действий под именем пользователя ExchangeUser (или аналогичного).
Ситуация, когда документ «сам» помечается на удаление — это не глюк и не ошибка программы, а результат работы алгоритма поддержания актуальности фильтров. Система стремится к тому, чтобы в базе-приемнике находились только те объекты, которые удовлетворяют правилам обмена в базе-источнике.
Основные выводы:
ОбменДанными.Загрузка отключает стандартное версионирование, если не заданы специальные настройки.