Почему документы при XML-обмене появляются в базе только после нескольких попыток загрузки?

При использовании стандартной обработки «Универсальный обмен данными в формате XML» (особенно при переносе данных из «Управление торговлей 10.3» в «Бухгалтерию предприятия 3.0») пользователи часто сталкиваются с парадоксальной ситуацией: счетчик объектов при выгрузке и загрузке показывает положительный результат, но сами документы в списках конфигурации-приемника отсутствуют. Также бывают случаи, когда документы загружаются не полностью (например, без аналитики или статей затрат), и только после третьего или четвертого повторения процедуры данные «доезжают» до базы. Рассмотрим подробно причины этого явления и разберем алгоритм диагностики.

Различие между «объектами» и «документами»

Первое, на что мы должны обратить внимание — это ловушка интерпретации лога загрузки. Проанализируем ситуацию: обработка сообщает, что выгружено и загружено 144 объекта. Это совершенно не означает, что в базе должно появиться 144 документа Требование-Накладная. В число этих объектов входят:

1. Сами документы.
2. Элементы справочников (Номенклатура, Склады, Контрагенты, СтатьиЗатрат).
3. Наборы записей регистров сведений.

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

Проблема ссылочной целостности и «пустых» реквизитов

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

Проанализируем пример со статьей затрат. Если при первой загрузке статья затрат была создана как объект, но ссылка в документе на нее не успела «привязаться» из-за порядка следования объектов в XML-файле, документ останется пустым. При повторном запуске обмена ссылка на статью уже существует в базе-приемнике, и механизм поиска объектов по идентификатору (GUID) успешно сопоставляет данные. Именно поэтому на 10-й раз данные могут «подтянуться» — к этому моменту вся необходимая ссылочная масса уже накоплена в базе.

Кэширование динамических списков и серверные особенности

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

1. Кэш конфигурации: на локальной машине могут храниться старые представления объектов.
2. Обновление динамических списков: списки документов в управляемом интерфейсе (БП 3.0) не всегда обновляются мгновенно после программной записи объектов, если запись происходила в другом сеансе или через фоновое задание.

Если вы загрузили данные и не видите их, попробуйте выполнить команду «Обновить» (клавиши Shift + F5) или полностью перезайти в программу. Если после перезахода документы появились, значит, проблема была в обновлении интерфейса.

Проверка через Журнал регистрации

Вместо того чтобы гадать, почему документы не появились, проанализируем Журнал регистрации в базе-приемнике. Это самый надежный способ диагностики. Нам необходимо выполнить следующие шаги:

1. Открыть «Администрирование» — «Обслуживание» — «Журнал регистрации».
2. Установить фильтр по периоду (время начала и окончания загрузки).
3. Отфильтровать события по важности «Ошибка» и «Предупреждение».
4. Найти события, связанные с объектом Данные.Запись.

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

Режим записи объектов: ОбменДанными.Загрузка

Разберем важную настройку в обработке «Универсальный обмен данными». В окне загрузки есть флаг «Использовать режим обмена данными для объектов». Рассмотрим, на что он влияет:

• Если флаг установлен: При записи объекта свойство ОбменДанными.Загрузка устанавливается в значение Истина. Это отключает большинство встроенных проверок конфигурации (подписки на события, проверки заполнения, запреты изменения). Документ записывается «как есть» из файла.
• Если флаг снят: Документ записывается как будто его вводит пользователь вручную. В БП 3.0 это приводит к тому, что начинают работать механизмы дозаполнения счетов учета, проверки прав доступа и корректности аналитики. Если в файле из УТ 10 нет полной информации для БП 3.0, запись будет заблокирована.

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

Диагностика через код обработчиков

Если вы являетесь разработчиком правил обмена, проверьте код в событии ПослеЗагрузки для ПВД или ПКО. Иногда там встречаются конструкции, которые пытаются провести документ сразу после записи:

Если Объект.Проведен Тогда
    Попытка
        Объект.Записать(РежимЗаписиДокумента.Проведение);
    Исключение
        Сообщить("Документ не проведен: " + ОписаниеОшибки());
    КонецПопытки;
КонецЕсли;

Если в документе не хватает данных для проведения, он может не только не провесться, но и (в зависимости от настроек транзакции) откатить свою запись. Выясним причину через отладку: используйте параметр РежимОтладки в обработке обмена, чтобы пошагово проследить за процессом записи каждого из 144 объектов.

Итоги и план действий

Чтобы решить проблему «исчезающих» документов, выполните следующие действия:

1. Убедитесь, что вы загружаете данные в режиме ОбменДанными.Загрузка = Истина.
2. Проверьте Журнал регистрации на наличие ошибок записи — это даст ответ, почему объект «обработан», но не «сохранен».
3. Проверьте настройки прав доступа. Если вы загружаете данные под пользователем с ограниченными правами, он может не иметь прав на запись определенных реквизитов, что приведет к отказу в записи всего документа.
4. Выполните принудительное обновление списка документов в БП 3.0 после загрузки.
5. Если данные загружаются не полностью, проверьте соответствие типов в правилах обмена (КД 2.0): возможно, поиск объектов идет по внутреннему идентификатору, который не совпадает в двух базах, и требуется настройка поиска по полям (например, по Наименованию или Артикулу).

Помните, что универсальный обмен XML — это не просто копирование файлов, а сложный процесс десериализации объектов, сильно зависящий от логики конфигурации-приемника.