Обновлено: 05.07.2024

Общие правила обмена объектами метаданных между конфигурациями

В процессе разработки часто возникает необходимость переноса объектов метаданных между конфигурациями. Платформа 1С:Предприятие 8 предоставляет несколько механизмов, которые в той или иной степени позволяют решать данную задачу. К ним относятся:

• Копирование объектов метаданных через буфер обмена
• Объединение конфигурации с файлом
• Загрузка конфигурации из файла
• Хранилище конфигурации
• Обновление конфигурации, находящейся на поддержке
• Обновление конфигурации базы данных

В данной статье рассматриваются некоторые особенности работы этих механизмов, которые позволяют прогнозировать результат перемещений объектов по "цепочкам" конфигураций и правильно выбирать соответствующий механизм. Следует заметить, что статья не является подробным руководством по использованию данных механизмов.

Сопоставление объектов. Имя и идентификатор объекта метаданных

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

Механизм Способ сопоставления Поведение идентификатора при перемещении объектаКопирование через буфер обмена Сопоставление не используется. Объект всегда вставляется как новый. ИзменяетсяОбъединение конфигураций Сопоставление по имени. При отсутствии соответствия по имени – сопоставление по внутреннему идентификатору. Возможна ручная установка соответствия. При копировании нового объекта изменяется. При объединении двух объектов, между которыми обнаружено соответствие, не изменяется.Сохранение в файл и загрузка конфигурации При загрузке выполняется полная замена на новую конфигурацию. Сопоставление не используется. Не изменяетсяХранилище конфигурации При подключении к хранилищу выполняется загрузка конфигурации. При последующих операциях - сопоставление по идентификаторам. Не изменяетсяОбновление конфигурации базы данных Сопоставление по идентификаторам. В случае нарушения соответствия, данные информационной базы будут потеряны. Не изменяетсяОбновление конфигурации находящейся на поддержке

При отключенной возможности изменений – сопоставление по идентификаторам. При включенной возможности изменений – сопоставление по идентификаторам, которые в некоторых случаях могут отличаться. В некоторых ситуациях возможна ручная установка соответствия.

При отключенной возможности изменений идентификатор не изменяется. При включенной возможности изменений возможны разные варианты. Однако сохранение соответствий при использовании данного механизма гарантируется.

Три уровня работы механизмов

Таким образом, механизмы переноса объектов можно разделить по трем уровням:

1. Механизмы которые требуют и обеспечивают строгое соответствие идентификаторов. К ним относятся сохранение / загрузка конфигурации, работа с хранилищем конфигурации, обновление конфигурации базы данных и обновление конфигурации, находящейся на поддержке при отключенной возможности изменений.
2. Механизмы, которые используют соответствие по идентификаторам, но не гарантируют их неизменность. К ним относится обновление конфигурации, находящейся на поддержке при включенной возможности изменений.
3. Механизмы, которые не используют и не обеспечивают неизменность идентификаторов. К ним относятся копирование через буфер обмена и объединение конфигурации.

Можно определить следующее правило:

Для обеспечения корректного сопоставления объектов уровень механизмов нельзя понижать.

Например, имеются две конфигурации: одна, в которой ведется разработка и вторая - в "рабочей" базе. Новые версии разрабатываемой конфигурации переносятся при помощи механизма загрузки конфигурации с последующим обновлением конфигурации базы данных. Используемый механизм переноса объектов относится к первому уровню, и идентификаторы при переносе не изменяются. Предположим, что для очередного обновления был использован механизм объединения конфигураций. Проблемы при этом не возникнет, поскольку для "старых" объектов, присутствовавших в предыдущих версиях, идентификаторы не изменились. Однако новые объекты попали в "рабочую" базу с измененными идентификаторами. Для дальнейших переносов новых версий нужно будет использовать только механизм объединения конфигураций, поскольку при выполнении загрузки (то есть при понижении уровня механизма со второго на первый), идентификаторы некоторых объектов "восстановятся" с точки зрения конфигурации разработки, но изменятся с точки зрения "рабочей" конфигурации. В этом случае при обновлении конфигурации базы данных произойдет потеря данных.

Примеры

Параллельное создание объектов

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

Восстановление автоматической поддержки конфигурации поставщика

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

Примеры анализа цепочки изменений конфигурации

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

Например, конфигурация хранилища была сохранена в файл. Это механизм первого уровня. В другой базе было выполнено объединение конфигурации с этим файлом. Уровень повысился до третьего. Затем возникла необходимость подключить эту базу к хранилищу. Механизм хранилища работает на первом уровне, поэтому при этом будет возможна потеря данных.

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

Для получения более подробной информации по поведению идентификаторов и сопоставлению объектов, мы рекомендуем ознакомиться с циклом статей "Поставка и поддержка конфигураций".

между базами бух 30 и зуп 31 была настроена синхронизация, но не верно.

физлица и их счета были есть в обеих базах

при попытке настроить заново с нуля не сопоставляется часть данных,
например, есть физлицо с одинаковым ФИО, датой рождения и кодом или его банковский счет. эти данные одинаковые и их можно найти в обеих базах.

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

релиз зуп 31 3.1.6.38
релиз бух 30 3.0.61.37

Помогла статья?

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

Все комментарии (19)

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

Тогда сопоставление должно пройти автоматически. Проверьте, возможно, Вы используете не типовые правила? Также можно сопоставить объекты вручную.

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

при этом в обеих базах в обычной форме списка справочника аналоги есть с точностью до символа.

я проверял, в поле Выводить стоит Несопоставленные данные
Что интересно, когда выбираю Все данные, новые аналоги для несопоставленных не появляются в противоположном списке.

попробовал заменить ФИО в БУХ на фио из ЗУП, не помогло.

самое интересное: попробовал сделать синхронизацию с этими настройками, дубли не возникли.

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

здесь пример сопоставления счетов сотрудников (втч. на гпх)
посмотрел в бухгалтерии у сотрудников указаны счета и в справочнике Контрагенты, и в справочнике Физические лица

убрал название компании. оно одинаковое в бух и зуп до символа

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

Уточните пожалуйста, а Вы в итоге пытались запустить синхронизацию в таком неправильно сопоставленном виде? Хоть что-то синхронизировались? Хоть какие-то данные переносились? Если нет, то попробуйте, только сделайте копии баз, чтобы потом откатиться к этим копиям, а то ведь несопоставленные физ. лица и счета по идеи должны задвоится. Напишите тогда, что получилось, действительно ли они задвоились?

Вы можете задать еще вопросов

Доступ к форме "Задать вопрос" возможен только при оформлении полной подписки на БухЭксперт8

Вы можете оформить заявку от имени Юр. или Физ. лица Оформить заявку

Нажимая кнопку "Задать вопрос", я соглашаюсь с
регламентом БухЭксперт8.ру >>

В пятницу о приятном: в ЗУП 3.1.18 появились новые возможности быстрой донастройки отчетов.

Семинар отличный! Лектор много вопросов разьяснил! СПАСИБО!

Вы можете задать еще вопросов

Доступ к форме "Задать вопрос" возможен только при оформлении полной подписки на БухЭксперт8

Вы можете оформить заявку от имени Юр. или Физ. лица Оформить заявку

Нажимая кнопку "Задать вопрос", я соглашаюсь с
регламентом БухЭксперт8.ру >>

Конфигурация 1С состоит из объектов: Константы , Документы , Регистры и ряда других. У каждого есть свои реквизиты: дата, номер, сумма и т. д. При обращении к переменной, которая не является объектом, либо при обращении к неверному типу объекта будет выходить оповещение, что Значение не является значением объектного типа.

Причины

• Основная — неверное обращение к объекту конфигурации.
• Дополнительная — обновление релиза или платформы и сохраненные настройки пользователя.

Неверное обращение к объекту

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

Возможно, она уже исправлена

либо есть вариант обхода ошибки до исправления в последующем обновлении.

Рассмотрим на примерах почему возникают подобные ошибки.

Создадим запрос по регистру накопления Взаиморасчеты с сотрудниками с некоторыми полями из него.

В запросе в поле Физическое лицо указали реквизит Код, обозначив при этом в представлении, что это данные по физическому лицу. Далее, выгрузив запрос в таблицу значений, обработаем полученные данные, при этом попытаемся сообщить, какое физическое лицо в данный момент обрабатывается.

В результате выполнения цикла получим ошибку Значение не является значением объектного типа (Наименование).

Следующий пример ошибки — обратимся к функции и передадим в нее параметры несоответствующего типа. У функции ОбработатьДанные два параметра: Объект и ФизическоеЛицо. Вместо передачи элемента типа справочник Физические лица передан параметр Ложь .

При выполнении кода будет выдана ошибка.

Происходит это из-за того, что функция пытается получить данные ИНН из типа данных Булево. Для исправления достаточно правильно передать параметр.

Также часто встречается ошибка, когда при написании кода в каком-то условии элементу присваивается неопределtнное значение, а в дальнейшем идет обращение как к объекту, без учета ранее сделанных изменений.

В данном примере необходимо либо добавлять проверку при получении даты для _Объект на значение Неопределено , либо изменить условие, которое приводит к ошибке.

Сохраненные настройки пользователя

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

Скорее всего, в следующем обновлении разработчики устранят данную проблему, а пока можно попробовать очистить настройки конкретного пользователя. Для начала следует сделать архив базы. Далее в развернутой копии выполнить следующие действия:

• зайти в раздел Администрирование ;
• открыть в панели действий пункт Настройки пользователей ;
• выбрав нужного пользователя, очистить его настройки.

Сначала можно попробовать очистить не все настройки, а только настройку того элемента, при работе с которым возникла ошибка. Например, при работе с должностями возникла ошибка, поэтому необходимо попробовать по правой кнопке мыши очистить настройки именно справочника Должности .

См. также:

Если Вы еще не подписаны:

Активировать демо-доступ бесплатно →

или

Оформить подписку на Рубрикатор →

После оформления подписки вам станут доступны все материалы по 1С:Бухгалтерия, записи поддерживающих эфиров и вы сможете задавать любые вопросы по 1С.

Помогла статья?

Получите еще секретный бонус и полный доступ к справочной системе БухЭксперт8 на 14 дней бесплатно

Похожие публикации

.У вас нет доступа на просмотр Чтобы получить доступ:Оформите коммерческую.Ошибка возникает при создании нового документа. При записи программа 1С.У вас нет доступа на просмотр Чтобы получить доступ:Оформите коммерческую.

Карточка публикации

Данную публикацию можно обсудить в комментариях ниже.
Обратите внимание! В комментариях наши кураторы не отвечают на вопросы по программам 1С и законодательству.
Задать вопрос нашим специалистам можно по ссылке >>

Вы можете задать еще вопросов

Доступ к форме "Задать вопрос" возможен только при оформлении полной подписки на БухЭксперт8

Вы можете оформить заявку от имени Юр. или Физ. лица Оформить заявку

Нажимая кнопку "Задать вопрос", я соглашаюсь с
регламентом БухЭксперт8.ру >>

Как не попасть в ловушку, работая с контрагентами из ЕАЭС

[17.11.2021 запись] Практический переход на ФСБУ 6 и ФСБУ 26 в 1С

Переход на ФСБУ 6/2020 «Основные средства» в 1С по альтернативному алгоритму

Изменения в 2021 году, о которых нужно знать бухгалтеру

[11.10.2021 запись] Учет ОС по-новому: ФСБУ 6/2020, ФСБУ 26/2020, ФСБУ 25/2018

[29.10.2021 запись] Пообъектный учет ОС и подходы к определению и пересмотру СПИ

Механизм сопоставления данных при обмене через универсальный формат

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

Для решения этой задачи как раз и предназначен механизм сопоставления данных.

В идеальном случае данные синхронизируемых приложений могли бы сопоставляться по уникальным внутренним идентификаторам объектов (GUID). Но для этого необходимо, чтобы добавление данных, подлежащих синхронизации, осуществлялся только в одном приложении, а в другом эти данные появлялись исключительно в результате синхронизации. В этом случае GUID в двух приложениях у одинаковых объектов будут одинаковыми, и по ним можно будет однозначно сопоставить объекты.

На практике соблюдать данное требование не всегда возможно, особенно в случае настройки синхронизации между приложениями, работа в которых велась независимо. Это связано с тем, что у двух одинаковых объектов, созданных параллельно в каждом приложении, будет два разных GUID.

В некоторых случаях данные не могут быть сопоставлены по GUID по причине его отсутствия (особые случаи, которые не рассматриваются в данной статье).

Для успешного сопоставления объектов с разными GUID должно быть место для хранения информация об их соответствии. Таким местом является регистр сведений Публичные идентификаторы синхронизируемых объектов (далее РПИ ). Структура регистра представлена в таблице:

Узел информационной базы ПланОбменаСсылка Ссылка на узел плана обмена (настройку обмена), для которой хранится соответствие. Ссылка

СправочникСсылка,
ПланВидовХарактеристикСсылка,
ДокументСсылка Ссылка на объект текущего приложения. Идентификатор Строка (36) GUID объекта, полученного от приложения-корреспондента.

При получении данных записи в регистре могут появляться на нескольких этапах (см. рисунок 1). Подробное описание самих алгоритмов сопоставления см. далее.

Рисунок 1. Этапы, на которых могут быть сделаны записи в РПИ

Этапы, помеченные пунктиром, опциональные: при выполнении сеанса обмена в автоматическом режиме отсутствуют этапы 1 и 2, при выполнении в интерактивном режиме этап 2 может быть пропущен пользователем.

В процессе обмена данные РПИ обеспечивают следующую функциональность:

1. Сопоставление объектов при получении данных (см. рисунок 2-а).
2. Обработка получаемых данных (замена ссылок) с целью обеспечения ссылочной целостности (см. рисунок 2-b).
3. Обработка отправляемых данных (замена ссылок) для исключения повторного сопоставления на стороне приложения-корреспондента уже сопоставленных данных (см. рисунок 2-b).

Рисунок 2. Использование данных РПИ при получении и при отправке данных.

Прикладная логика, определяющая порядок автоматического сопоставления объектов при получении, содержится в правилах конвертации объектов (ПКО), предназначенных для получения данных.

Все компоненты (правила обработки данных, правила конвертации объектов и т.д.), определяющие прикладную логику обработки данных в процессе их получения, либо отправки (подробнее в статье Методика работы с конфигурацией "Конвертация данных 3.0" ) формируют так называемый менеджер обмена . Код менеджера обмена разрабатывается в общем модуле (подробное описание см. в документации по БСП , в разделе Обмен через универсальный формат ). Модуль создается автоматически с помощью КД3.0 на основе настроенных правил обмена либо вручную в конфигураторе (см. пример - общий модуль _ДемоМенеджерОбменаЧерезУниверсальныйФормат демо-конфигурации БСП ).

Вариант автоматического сопоставления (идентификации) объектов при получении задается с помощью свойства ВариантИдентификации ПКО и может принимать одно из трех значений:

1. ПоУникальномуИдентификатору - идентификация по GUID,
2. СначалаПоУникальномуИдентификаторуПотомПоПолямПоиска - идентификация по GUID и полям поиска,
3. ПоПолямПоиска - идентификация по полям поиска,

Еще одним свойством, определяющим логику сопоставления, является массив полей поиска, определяемый в свойстве ПоляПоиска ПКО.

Рисунок 3. Настройки идентификации в модуле менеджера и в КД3.0.

В таблице 1 представлено описание использования данных настроек при автоматическом сопоставлении на разных этапах получения данных:

Этап анализа данных (при загрузке через помощник синхронизации данных)

Ручное сопоставление (при загрузке через помощник синхронизации данных)

Идентификация по РПИ .

Идентификация по GUID.

Запись соответствий в РПИ: делается, если соответствие нашлось при выполнении п.3.

Сопоставлять можно со всеми объектами соответствующего типа, для которых нет соответствий в РПИ .

Запись соответствий в РПИ: делается по результатам сопоставления.

Идентификация по РПИ .

Идентификация по GUID среди объектов, отсутствующих в РПИ .

Запись соответствий в РПИ: делается для либо с исходным GUID, либо с вновь сгенерированным, п. 1 не дал результата но объект с таким GUID уже есть в РПИ .

По GUID и полям поиска

Аналогично варианту "По GUID".

Идентификация по РПИ .

Идентификация по GUID.

Запись соответствий в РПИ: см. выше.

См. колонку "Загрузка данных"

Запись соответствий в РПИ: не делаются.

Таблица 1. Правила работы настроек идентификации.

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

Ограничение.
При сопоставлении на этапе анализа данных применяется только 1-й вариант поиска.

Переход к следующему варианту осуществляется в двух случаях:

1. У загружаемого объекта не заполнено какое-либо из полей, которое указано в варианте поиска.
2. Вариант поиска не дал результата.

Если в загружаемом объекте есть информация об исходном GUID и вариант идентификации для объекта "По GUID" или "По GUID и полям поиска", то поиск выполняется среди всех объектов заданного типа, кроме тех, для которых в РПИ уже установлены соответствия.

В остальных случаях поиск осуществляется среди всех объектов информационной базы соответствующего типа.

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

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

Особенность.
На этапе загрузки данных вариант поиска Номер + Дата для документов работает следующим образом: номер искомого документа проверяется на точное соответствие, дата определяет интервал, в котором проводится поиск по номеру. Сам интервал определяется как период уникальности номеров документа, в который входит указанная дата. Например, если номера документов уникальны в пределах месяца и задана дата 10 декабря 2001 года, то поиск будет проводиться в интервале с 01 по 31 декабря 2001 года.
На этапе анализа данных этот вариант поиска будет работать как обычно: оба поля будут проверяться на точное соответствие.

Читайте также:

  
• Удалить спецсимволы из строки oracle
  
• Программа для заметок для ipad
  
• Как создать второй сайт на 1с битрикс
  
• Как вырезать звук из видео в fl studio
  
• Как перенести строку в excel