Как после выгрузки документа изменить его состояние в источнике средствами Конвертации данных 2.0?

В процессе интеграции между конфигурациями на базе 1С часто возникает задача: после того как документ был успешно выгружен в целевую систему, необходимо изменить его статус внутри базы-источника. Например, снять флаг Выгружать, чтобы документ не попадал в очередь на повторную выгрузку. Рассмотрим, как это реализовать средствами Конвертация данных 2.0 и какие подводные камни нас ожидают.

Реализация изменения объекта через обработчик ПВД

Если специфика вашей задачи допускает прямую модификацию данных после их выгрузки, наиболее простым способом будет использование обработчика ПослеВыгрузки в Правилах Выгрузки Данных (ПВД). Давайте разберем этот процесс по шагам.

Для выполнения этой задачи нам потребуется получить объект, произвести его изменение и записать его обратно в базу данных. Важно учитывать, что в момент работы обработчика объект находится в режиме чтения, поэтому нам нужно воспользоваться методом ПолучитьОбъект().

Рассмотрим пример кода, который необходимо вставить в обработчик ПослеВыгрузки:

Документ = Объект.Ссылка.ПолучитьОбъект();
Документ.Выгружать = Ложь; // Устанавливаем статус, предотвращающий повторную выгрузку

Если Документ.Проведен Тогда
    Документ.Записать(РежимЗаписиДокумента.Проведение, РежимПроведенияДокумента.Неоперативный);
Иначе
    Документ.Записать(РежимЗаписиДокумента.Запись);
КонецЕсли;

Важные замечания по коду:

1. Мы используем ПолучитьОбъект() для работы с объектной моделью данных, что позволяет нам менять значения реквизитов.
2. Метод Записать() вызывается с параметрами режима записи, чтобы корректно обработать состояние документа (проведенный он или нет).
3. При использовании такого подхода помните, что запись происходит немедленно. Если выгрузка идет в рамках большого транзакционного пакета, это может повлиять на блокировки таблицы.

Архитектурные риски и ограничения

Несмотря на то что приведенный выше код успешно решает поставленную задачу, профессиональное сообщество 1С-разработчиков выделяет ряд серьезных рисков, о которых необходимо знать:

• Отсутствие контроля доставки: Обработчик ПослеВыгрузки срабатывает в момент формирования XML-файла. Это не гарантирует, что данные были успешно загружены в базу-приемник. Если произойдет ошибка при чтении файла, статус в источнике все равно будет изменен на «Выгружено», и повторная синхронизация станет невозможной без ручного исправления.
• Работа с закрытыми периодами: Если вы пытаетесь изменить документ за прошлый год, который закрыт датой запрета редактирования, метод Записать() выдаст ошибку, что приведет к остановке всей процедуры выгрузки.
• Производительность: Постоянное обращение к ПолучитьОбъект() и запись документов при выгрузке больших объемов данных создает высокую нагрузку на СУБД и может вызывать взаимные блокировки (deadlocks).

Альтернативные подходы: Планы обмена

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

Почему стоит выбрать планы обмена:

1. Надежность: Платформа сама отслеживает изменения в объектах через механизмы регистрации.
2. Гарантия доставки: Вы можете гибко управлять тем, что считается «выгруженным», основываясь на подтверждении приема данных (квитировании).
3. Безопасность: Не нужно программно снимать даты запрета редактирования или принудительно перепроводить документы, что исключает ошибки доступа.

Даже в «самописных» конфигурациях создание Плана обмена не требует участия библиотеки стандартных подсистем (БСП). Достаточно добавить объект в метаданные, указать состав (документы, справочники) и прописать логику регистрации изменений в модуле объекта при записи. Это даст вам надежный инструмент, который не зависит от успеха конкретной выгрузки в XML.

Рекомендация для разработчиков

Если задача носит временный характер или объем данных крайне мал, вы можете воспользоваться кодом из примера выше. Однако, если ваша система обмена рассчитана на постоянную эксплуатацию, настоятельно рекомендуем перевести логику на Планы обмена или использовать специализированные Регистры сведений для хранения статусов обмена. Такой подход позволит избежать проблем с «потерянными» документами и обеспечит стабильную работу системы в будущем.