Почему не синхронизируется пометка на удаление документов между УТ 11 и БП 3.0 и как это исправить?

При настройке обмена между конфигурациями Управление торговлей 11 и Бухгалтерия предприятия 3.0 пользователи часто сталкиваются с ситуацией, когда пометка документа на удаление не передается в базу-приемник. В некоторых случаях система даже выдает критическую ошибку, прерывая обмен. Давайте разберемся, почему это происходит и как программно настроить корректное поведение системы.

Причины возникновения ошибки

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

Когда обмен данными пытается передать состояние «Пометка удаления» для документа, который в базе-приемнике находится в статусе «Проведен», транзакция записи прерывается ошибкой. Система сообщает, что проведенный документ не может быть помечен на удаление, так как это нарушает последовательность бизнес-логики.

Решение 1: Модификация функции ПрочитатьОбъект

Одним из наиболее действенных способов решения является внесение правок в модуль обработки Конвертация объектов ИБ. Мы можем изменить алгоритм обработки данных при загрузке. Суть метода заключается в перехвате события записи: если документ пришел с пометкой на удаление, мы принудительно переключаем РежимЗаписи в состояние ОтменаПроведения.

Рассмотрим, как это реализовать в функции ПрочитатьОбъект:

// Если хотим провести документ, помеченный на удаление, 
// то пометку удаления снимаем, либо меняем режим записи
Если Объект.ПометкаУдаления И (РежимЗаписи = РежимЗаписиДокумента.Проведение) Тогда
    РежимЗаписи = РежимЗаписиДокумента.ОтменаПроведения;
КонецЕсли;

При таком подходе, вместо того чтобы пытаться записать проведенный документ с пометкой, система сначала отменяет его проведение, что позволяет корректно установить пометку на удаление и завершить процесс синхронизации без ошибок.

Решение 2: Корректировка правил регистрации (Общий модуль)

Еще один способ — вмешательство в работу общего модуля ОбменДаннымиСобытия. Иногда проблему можно решить путем изменения логики отбора свойств для обмена. Если мы исключим условие обязательного проведения документа в правилах, обмен будет проходить «мягче».

Вы можете использовать дополнение к функции ПравилоРегистрацииСтруктурой:

Для каждого строчка из Результат.ОтборПоСвойствамОбъекта.Строки цикл
    Если строчка.СвойствоОбъекта = "Проведен" Тогда
        Результат.ОтборПоСвойствамОбъекта.Строки.Удалить(строчка);
        прервать;
    КонецЕсли;
КонецЦикла;

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

Практические рекомендации по обмену

Помимо программных доработок, мы рекомендуем придерживаться следующих правил:

1. Соблюдайте порядок действий: Если вы планируете удалить документ, сначала отмените его проведение в базе-источнике, установите пометку, и только после этого выполняйте синхронизацию.
2. Проверка через Журнал регистрации: Если обмен прерывается, всегда открывайте журнал регистрации. В нем вы сможете увидеть, какой именно документ вызывает исключение (например, РКО или Отчет о розничных продажах).
3. Использование стандартных средств: Если документ «завис» и не уходит в другую базу, воспользуйтесь обработкой Регистрация изменений для обмена. Выберите узел обмена и принудительно зарегистрируйте объект повторно.
4. Актуализация правил: Регулярно обновляйте файлы правил обмена (Конвертация данных). Разработчики 1С часто выпускают обновления, где подобные конфликты обработки проведенных документов уже устранены на уровне самих алгоритмов XML-выгрузки.

Работая с обменами, всегда делайте резервную копию перед внесением любых правок в программный код. Помните, что изменения в общих модулях — это серьезное вмешательство, которое требует тщательного тестирования на копии базы.