Мы часто сталкиваемся с ситуацией, когда при переносе данных между базами 1С с помощью Конвертации Данных (КД 2.1) процесс выгрузки-загрузки проходит без видимых ошибок. Отчет о загрузке сообщает, что объекты «загружены», но в целевой базе перенесенные данные (например, документы) так и не появляются. Эта проблема может быть весьма неочевидной, поскольку платформа не всегда выдает явные сообщения об ошибках записи. Давайте разберем основные причины и методы отладки для решения этой задачи.
В нашей ситуации, автор темы столкнулся с тем, что документы «Заказ покупателя» из ERP-системы не создавались в 1С:УНФ, хотя процесс загрузки завершался без ошибок. В итоге оказалось, что причиной был незаполненный обязательный реквизит.
Мы выяснили, что одной из наиболее частых причин такой проблемы является незаполнение обязательных для записи реквизитов объекта в целевой базе. Эти реквизиты могут быть не видны на форме документа или справочника, но их наличие является критически важным для успешной записи.
Рассмотрим подробнее ситуацию с документом «Заказ покупателя» в 1С:УНФ. Оказалось, что у этого документа существует реквизит ВидОперации, который является обязательным для записи, но при этом отсутствует на форме документа. Если этот реквизит не заполнен, платформа не сможет записать документ, даже если остальные данные корректны.
Для решения этой проблемы нам необходимо принудительно установить значение обязательного реквизита в обработчике события «После загрузки» (или «При загрузке») Правила Конвертации Объекта (ПКО) для соответствующего документа.
// В обработчике ПКО документа "ЗаказПокупателя"
// Событие: После загрузки
// Устанавливаем значение обязательного реквизита "ВидОперации"
// Предполагаем, что для данного сценария всегда используется "ЗаказНаПродажу"
Объект.ВидОперации = Перечисления.ВидыОперацийЗаказПокупателя.ЗаказНаПродажу;
После добавления этого кода документы «Заказ покупателя» начали успешно создаваться в целевой базе. Это подчеркивает важность детального анализа структуры и поведения объектов в целевой конфигурации, особенно при работе с нестандартными или скрытыми реквизитами.
Когда явные ошибки отсутствуют, но объекты не создаются, нам необходимо применить различные методы отладки для определения корня проблемы. Разберем основные шаги.
Первым шагом всегда рекомендуется использовать встроенные средства диагностики обработки загрузки данных. Мы можем включить вывод информационных сообщений, которые иногда могут подсказать, на каком этапе или при работе с каким объектом возникают сложности.
Как правило, в обработке загрузки данных (например, «Универсальный обмен данными XML») есть флаг или настройка, позволяющая включить расширенный вывод информации. Активируем его перед началом загрузки данных. Мы сделаем это сразу, так как это дает базовую информацию о процессе.
Важно: Это отличается от режима отладки, который используется для пошагового выполнения кода правил конвертации. Информационные сообщения дают общую картину процесса загрузки и могут указывать на общие проблемы, тогда как режим отладки предоставляет детализированный пошаговый анализ вашего кода в правилах конвертации или в модулях объектов.
Если информационные сообщения не дают достаточной картины, нам понадобится полноценная отладка. Это наиболее эффективный способ выяснить, что происходит на стороне целевой базы во время попытки записи объекта.
Убедимся, что у нас есть возможность подключиться отладчиком к целевой базе. Если база клиент-серверная, возможно, потребуется настройка сервера 1С Предприятия для отладки. Мы должны разрешить отладку на сервере 1С. В файловом варианте это проще, так как отладчик автоматически подключается к текущей сессии конфигуратора.
Основной вопрос при отладке в такой ситуации: «где поставить точку останова?». Поскольку проблема связана с записью объекта, нам необходимо установить точку останова непосредственно в модуле объекта того типа, который не создается.
Откроем конфигурацию целевой базы (Конфигуратор). Найдем нужный объект (например, документ «ЗаказПокупателя»). Откроем его модуль объекта. Наиболее релевантные места для постановки точек останова — это процедуры-обработчики событий записи:
ПередЗаписью(): Эта процедура выполняется перед тем, как объект будет записан в базу данных. Здесь часто происходят основные проверки и модификации данных, которые могут препятствовать записи. Если внутри этой процедуры устанавливается флаг Отказ = Истина, то запись будет отменена.ПриЗаписи(): Выполняется непосредственно во время записи объекта. Менее часто используется для отмены записи, но может содержать логику, которая приводит к ошибкам.ОбработкаЗаполнения(): Может быть вызвана при создании нового объекта и влиять на заполнение обязательных реквизитов. Если какой-то обязательный реквизит очищается или не заполняется здесь, это также может привести к проблемам с записью.Установим точки останова в начале этих процедур. При следующей загрузке данных отладчик должен остановиться в этих местах, позволяя нам пошагово отследить выполнение кода, проанализировать значения реквизитов и выяснить, какое условие не выполняется или какой реквизит не заполнен (или очищается) перед записью. Мы внимательно проследим за значением переменной Отказ.
// Пример в МодулеОбъекта документа "ЗаказПокупателя"
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
// !!! Установите здесь точку останова !!!
// На этом этапе мы можем проверить все значения реквизитов объекта
// и логику, которая может помешать записи.
Если Отказ Тогда
// Если здесь Отказ = Истина, значит, какая-то логика уже запретила запись
// Мы можем проанализировать, какой код выше установил этот флаг.
Возврат;
КонецЕсли;
// Например, если мы знаем о реквизите "ВидОперации", можем явно проверить его
Если НЕ ЗначениеЗаполнено(ЭтотОбъект.ВидОперации) Тогда
// Отладочное сообщение, которое мы увидим в окне отладчика или в сообщениях
Сообщить("Не заполнен вид операции документа 'Заказ покупателя'!");
Отказ = Истина; // Запрещаем запись
Возврат;
КонецЕсли;
// ... прочий код перед записью, который может содержать дополнительные проверки ...
// Внимательно изучаем все условия, которые могут установить Отказ = Истина
КонецПроцедуры
Помимо модулей объектов, не забываем о возможности отладки кода, который мы пишем в обработчиках Правил Конвертации (ПКО и ПКС). Если у нас есть сложная логика в обработчиках «Перед загрузкой», «При загрузке», «После загрузки», «Получение объекта», «Загрузка свойств», то установка точек останова там поможет убедиться, что данные формируются правильно перед передачей в целевой объект. Мы убедимся, что на этом этапе все необходимые реквизиты заполнены и имеют корректные значения.
Тщательно проанализируем все обработчики событий, которые мы добавили в правила конвертации: как общие для всей конвертации, так и специфичные для ПКО документа, который не создается. Иногда в этих обработчиках может быть логика, которая устанавливает флаг Отказ в Истина или очищает ключевые реквизиты, что предотвращает запись объекта. Мы внимательно перепроверим каждый обработчик, чтобы исключить такую возможность.
Помимо описанного выше случая с обязательным реквизитом, существует ряд других распространённых причин, по которым объекты могут не создаваться в целевой базе, даже если загрузка прошла без ошибок. Мы рассмотрим их, чтобы иметь полную картину возможных проблем.
Это одна из самых коварных причин. Пользователь, под которым мы выполняем загрузку данных в целевую базу, может не иметь достаточных прав для создания или изменения определенных типов объектов (например, документов, элементов справочников) или их реквизитов. Система 1С в таких случаях не всегда выдает явные ошибки, особенно если речь идет о программной записи объекта без интерактивного взаимодействия. Просто операция записи может быть молча проигнорирована.
Как проверить: Мы попробуем создать аналогичный объект вручную под тем же пользователем, под которым производится загрузка данных, или под пользователем с полными правами. Если создание запрещено или возникают ошибки, то проблема, скорее всего, в правах. Нам следует тщательно проверить настройки ролей и прав доступа для этого пользователя в целевой конфигурации, убедившись, что у него есть роли, дающие разрешения на добавление и изменение нужных объектов.
Мы уже упоминали о них в контексте отладки. Но стоит выделить это как отдельную причину. В самой конфигурации целевой базы (в модулях объектов, модулях форм, общих модулях) могут быть реализованы обработчики событий, такие как ПередЗаписью(), ПриЗаписи(), ОбработкаЗаполнения() и другие. Эти обработчики могут содержать сложную логику, которая:
Отказ = Истина при определенных условиях (например, если не выполнено какое-либо бизнес-правило).Очень часто именно здесь скрывается причина незаписи, особенно если конфигурация целевой базы дорабатывалась, и были введены дополнительные контроли.
Помимо явных, видимых на форме реквизитов, у многих объектов 1С есть скрытые, технические или системные обязательные реквизиты, которые должны быть заполнены для успешной записи. Примерами могут служить: Организация (для многих документов и справочников), ВидЦены, Статус, различные служебные перечисления, которые платформа ожидает увидеть заполненными. Такие реквизиты могут быть обязательными даже для программного создания объекта.
Если эти реквизиты не заполняются в ПКО или их значения неверны (например, мы передаем несуществующий вид операции или статус, или некорректную ссылку на организацию), объект не будет записан. Система может не выдавать явных ошибок, так как внутренняя логика 1С часто обрабатывает такие ситуации без вывода исключения на пользовательский уровень, просто игнорируя попытку записи.
Рекомендация: Мы всегда должны внимательно изучать структуру метаданных целевого объекта в конфигураторе и проверять, какие реквизиты помечены как «Заполнять при создании» или имеют особые требования к заполнению. Если мы обнаружим такой реквизит, нам потребуется явно указать его заполнение в правилах конвертации, возможно, через прямое присвоение или поиск соответствующего значения.
Некоторые реквизиты в 1С могут заполняться автоматически при создании нового элемента. Например, дата, номер, ответственный. Если эти автоматически заполненные значения вступают в конфликт с данными, которые мы передаем через конвертацию, или если логика автоматического заполнения ожидает определенных условий (например, наличия определенного вида операции, который мы не указали), это может помешать записи.
Пример: Если мы пытаемся передать номер документа, а в целевой базе настроена автоматическая нумерация с контролем уникальности, и наш номер уже существует, это может вызвать ошибку записи, или платформа попытается перенумеровать, что не всегда проходит гладко без дополнительных настроек. В этом случае, возможно, нам потребуется отключить передачу номера из источника или настроить правила так, чтобы номер генерировался целевой системой.
Платформа 1С имеет собственные механизмы контроля целостности и уникальности данных, которые срабатывают при записи. Если мы пытаемся записать объект, который нарушает эти правила, платформа может заблокировать запись.
При настройке Правил Конвертации Объектов (ПКО) мы указываем правила поиска существующих объектов (например, по коду, по наименованию, по GUID). Если система не находит существующий объект по заданным правилам, она пытается его создать. Но если данные для поиска не уникальны (например, несколько контрагентов с одинаковым наименованием, но разными ИНН), или правило поиска настроено некорректно (например, поиск только по наименованию, когда оно не уникально), это может привести к непредсказуемому поведению: создание дубликатов, ошибки записи, или невозможность найти существующий объект, что приводит к попытке создания нового, которая затем блокируется по другим причинам (например, из-за уникальности кода).
Рекомендация: Мы всегда должны использовать максимально уникальные поля для поиска (например, GUID, если он передается, или комбинацию нескольких полей, таких как ИНН и КПП для контрагентов, или код и наименование). Важно убедиться, что выбранные поля действительно обеспечивают уникальность в целевой базе.
После неудачной загрузки мы всегда должны проверить журнал регистрации целевой базы. Иногда именно там можно найти более подробные сообщения об ошибках или предупреждениях, связанных с записью объектов, даже если на уровне обработки конвертации они не отображались. Журнал регистрации может содержать информацию о том, какой именно реквизит не заполнен, какие права отсутствуют, или какое условие было нарушено. Это является важным источником информации для диагностики, особенно если отладчик не удалось подключить или он не дал полной картины.
Мы должны убедиться, что все связанные объекты, на которые есть ссылки в документе или другом переносимом объекте, корректно переносятся или уже существуют в целевой базе. Например, если документ «Заказ покупателя» ссылается на контрагента, договор, номенклатуру, склад или организацию, и эти ссылочные объекты не были найдены или созданы в процессе конвертации (или созданы с ошибками), то сам документ не сможет быть записан из-за нарушения ссылочной целостности.
Рекомендация: Нам необходимо настроить ПКО для всех связанных объектов, обеспечив их перенос до переноса основного документа. Важно соблюдать порядок загрузки: сначала справочники, затем документы, которые на них ссылаются. В правилах конвертации для ссылочных полей, которые не являются обязательными для создания нового объекта, но важны для его записи, можно использовать стратегию «создавать, если не найден» или «игнорировать, если не найден», в зависимости от бизнес-логики.
Проблема незаписи объектов при загрузке через Конвертацию Данных 2.1 может быть вызвана множеством факторов, от банального незаполнения обязательного реквизита до сложных взаимодействий серверного кода и прав доступа. Нам необходимо подходить к диагностике системно, начиная с анализа информационных сообщений и заканчивая пошаговой отладкой кода в модулях объектов целевой конфигурации. Вооружившись этими знаниями и инструментами, мы сможем эффективно находить и устранять причины, по которым объекты отказываются создаваться, и успешно завершать миграцию данных.