Обмен данными и параметр «Загрузка = Истина» в 1С 8.3: что это такое

При обмене данными в 1С 8.3 в коде обработчиков, подписок на события и модулей объектов часто встречается конструкция вида Если ОбменДанными.Загрузка Тогда Возврат; или параметр Загрузка = Истина. Это специальный режим записи объектов, при котором платформа пропускает ряд стандартных проверок и бизнес-логику, чтобы ускорить загрузку и не исказить переносимые данные.

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

Понимание этого механизма критично в трёх ситуациях: при настройке типовой синхронизации между базами, при разработке собственных правил обмена и при массовой загрузке данных через обработки (например, перенос из другой учётной системы). Ошибки в работе с этим режимом — одна из главных причин рассинхронизации баз, «потерянных» движений документов и невозможности провести загруженные объекты вручную.

Что именно делает режим «Загрузка = Истина»

Когда у объекта свойство ОбменДанными.Загрузка равно Истина, платформа при записи изменяет поведение сразу по нескольким направлениям. Во-первых, не выполняется автоматический контроль заполнения реквизитов с признаком «Проверка заполнения — Выдавать ошибку»: объект запишется, даже если обязательное поле пустое. Во-вторых, для документов не выполняется проведение — документ записывается в том состоянии, в котором пришёл, включая признак «Проведен» и сами движения, если они передаются вместе с объектом.

В-третьих, типовые обработчики и подписки на события, написанные по стандартам БСП (библиотеки стандартных подсистем), в начале содержат проверку Если Объект.ОбменДанными.Загрузка Тогда Возврат; — то есть прикладная логика (заполнение по умолчанию, пересчёт итогов, контроль остатков, отправка уведомлений) при загрузке не срабатывает. Это сделано намеренно: данные уже «посчитаны» в базе-источнике, и повторный расчёт может их исказить.

Где встречается этот параметр

Чаще всего конструкцию видят в трёх местах. Первое — модуль объекта или подписка на событие в конфигурации: строка Если ОбменДанными.Загрузка Тогда Возврат; в начале обработчиков ПередЗаписью, ПриЗаписи, ОбработкаПроверкиЗаполнения. Это защита, которую ставит разработчик, чтобы его код не мешал обмену.

Второе место — типовые планы обмена и правила конвертации (КД 2 и КД 3, «Конвертация данных»). В обработчиках правил конвертации объектов и событий есть параметр Загрузка, по которому правило определяет, выполняется сейчас загрузка или выгрузка, и ветвит логику. Третье — универсальные обработки загрузки (например, загрузка из табличного документа), где в коде явно пишется НовыйОбъект.ОбменДанными.Загрузка = Истина; перед вызовом Записать().

Параметр в правилах конвертации

В обработчиках «Перед записью», «При записи», «После загрузки» правил конвертации переменная Загрузка принимает значение Истина, когда объект записывается в базу-приёмник. Это позволяет написать разную логику для выгрузки и загрузки в одном правиле. Например, при загрузке можно дозаполнить реквизит, который отсутствует в источнике, а при выгрузке — сформировать дополнительные данные для приёмника.

Почему без этого режима обмен работает плохо

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

Отдельная проблема — производительность. При синхронизации больших объёмов каждый лишний пересчёт и каждая проверка умножаются на количество объектов. Режим загрузки позволяет платформе записывать данные максимально быстро, а все проверки целостности выполнить отдельно после завершения обмена.

Как правильно использовать режим при самостоятельной загрузке

Если вы пишете собственную обработку загрузки (например, переносите справочник контрагентов из файла или из другой базы), типовой порядок действий выглядит так: создать или найти объект, заполнить реквизиты, установить ОбменДанными.Загрузка = Истина, записать. Для документов дополнительно решается вопрос с проведением: либо документ загружается как непроведённый и проводится штатно после загрузки, либо загружается с признаком «Проведен» вместе с движениями.

НовыйКонтрагент = Справочники.Контрагенты.СоздатьЭлемент();
НовыйКонтрагент.Наименование = СтрокаДанных.Наименование;
НовыйКонтрагент.ИНН = СтрокаДанных.ИНН;
НовыйКонтрагент.ОбменДанными.Загрузка = Истина;
НовыйКонтрагент.Записать();

Важный нюанс: после записи с Загрузка = Истина объект может оказаться «некорректным» с точки зрения прикладной логики — например, без заполненного обязательного реквизита. Если такой объект потом открыть в форме и попытаться записать вручную, пользователь получит ошибку контроля заполнения. Поэтому после массовой загрузки полезно выполнить проверку: открыть несколько загруженных объектов и попробовать их перезаписать или провести вручную.

1. 1
   Сделайте резервную копию базы-приёмника или выполняйте загрузку сначала в копии
2. 2
   Установите ОбменДанными.Загрузка = Истина у каждого записываемого объекта
3. 3
   Заполните минимально необходимые реквизиты, включая те, что нужны прикладной логике позже
4. 4
   Запишите объекты, желательно в одной транзакции с контролем ошибок
5. 5
   После загрузки выборочно откройте объекты и проверьте возможность ручной записи и проведения
6. 6
   Проверьте связанные данные: движения документов, записи регистров сведений, подчинённые объекты

Типовые проблемы и их признаки

Самая частая жалоба — «документы загрузились, но не проводятся». Причина почти всегда в том, что документ записан в режиме загрузки с признаком «Проведен», но его движения либо не загружены, либо рассчитаны по логике источника и не соответствуют настройкам приёмника. При попытке перепровести такой документ вручную срабатывают проверки приёмника (остатки, закрытые периоды, заполнение реквизитов), и проведение отклоняется.

Вторая типовая ситуация — дубли элементов справочников. Если в правилах обмена не настроен корректный поиск по уникальному идентификатору или ключевым полям, а загрузка идёт в режиме Загрузка = Истина, контроль уникальности прикладного уровня не сработает, и в базе появятся два «ООО Ромашка» с разными ссылками. Режим загрузки здесь не виноват сам по себе — он просто не защищает от ошибок в правилах поиска.

Третья проблема — «тихое» расхождение регистров. Если при обмене документы грузятся без движений, а движения должны формироваться при проведении, но проведение в приёмнике не выполняется, регистры накопления и бухгалтерии в двух базах расходятся без каких-либо сообщений об ошибках. Обнаруживается это обычно только при сверке отчётов.

Как проверить, что обмен прошёл корректно

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

Если проверка выявила расхождения, сначала смотрите протокол обмена (журнал регистрации с отбором по событию обмена данными): там фиксируются ошибки записи конкретных объектов. Затем проверяйте правила поиска и правила конвертации свойств — в типовых конфигурациях их можно скорректировать через настройку синхронизации, в собственных — через «Конвертацию данных».

Когда режим загрузки использовать нельзя

Есть ситуации, где установка Загрузка = Истина — прямой путь к испорченным данным. Нельзя использовать режим загрузки при интерактивной работе пользователя: формы и командный интерфейс должны показывать ошибки заполнения, а не молча записывать объект. Нельзя применять его, если прикладная логика обязана выполниться — например, при загрузке документа, который по правилам учёта должен создать связанные записи в регистрах сведений.

Также осторожность нужна при доработке обработчиков обмена: добавление в обработчик «После загрузки» кода, который записывает другие объекты, может вызвать рекурсивную загрузку или блокировки при параллельной работе. Любые такие доработки сначала тестируются на копии базы с реальным объёмом данных.

Частые вопросы