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

Общие принципы реализации


Внутренний идентификатор

Каждый предопределенный элемент имеет внутренний идентификатор, который соответствует идентификатору объекта информационной базы, соответствующего данному предопределенному элементу.

Обновление конфигурации базы данных

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

Поведение идентификаторов предопределенных элементов при копировании и объединении конфигураций

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

Теперь рассмотрим, как описанные принципы влияют на поведение предопределенных элементов в различных механизмах платформы 1С:Предприятие 8.

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

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

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

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

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

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

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

Обмен данными

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

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

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