Maison / Réseaux sociaux / Un élément prédéfini n'est pas unique 8.3. Erreurs dans les éléments prédéfinis. Maintenant en affaires

Un élément prédéfini n'est pas unique 8.3. Erreurs dans les éléments prédéfinis. Maintenant en affaires

L'idée même de travail programmatique avec des éléments prédéfinis, à mon avis, est très correcte. Il y a juste quelques nuances à prendre en compte lors du travail.

Vous devez d'abord comprendre clairement par vous-même qu'il existe des éléments prédéfinis dans la configuration et qu'il existe des éléments prédéfinis dans l'infobase (IB). Les éléments SI techniquement prédéfinis sont les éléments les plus courants des annuaires, dans lesquels l'attribut "PredefinedDataName" indique à quel élément de configuration prédéfini ils correspondent. Ils ne sont pas différents des éléments ordinaires. En conséquence, tout élément ordinaire de sécurité de l'information peut être rendu prédéfini, tout élément prédéfini peut être rendu ordinaire. Pour ce faire, entrez simplement la valeur souhaitée dans les accessoires. "NomDonnéePrédéfini".

Régulièrement, cette propriété ne contient pas la valeur fournie par le développeur. En conséquence, des erreurs se produisent dans le travail de 1C. Du critique, dans lequel le travail est en principe impossible, au non critique, dans lequel la logique des algorithmes est violée.

Il est conditionnellement possible de distinguer trois types d'erreurs :
1. "L'élément prédéfini est absent des données" ;

3. Indication erronée d'un élément prédéfini ;

1. "L'élément prédéfini est absent des données" - oh l'absence d'un élément prédéfini décrit dans la configuration dans les données du SI.

C'est le type d'erreur le plus facile à déboguer et à corriger. Sa simplicité est que la plateforme signale correctement cette situation "L'élément prédéfini est absent des données" et il est assez clair comment y remédier.

Lors de l'accès à l'élément manquant dans le code "Annuaires.Types d'informations de contact. Email de la personne de contact", un message s'affiche

Lors de l'accès à l'élément dans la requête "VALUE(Catalog.KindsofContactInformation.EmailContactPerson)" le message suivant s'affiche :

Une telle erreur se produit si l'élément est décrit dans la configuration, mais l'élément ne lui est pas associé dans la base de données.

Pour commencer, précisons que cette situation n'est pas toujours erronée. Il est tout à fait possible d'utiliser des données prédéfinies dans une sorte de logique de programme qui, pour la plupart des utilisateurs, peut ne pas être utilisée. Dans ce cas, afin de ne pas encombrer l'annuaire de tous les utilisateurs de la configuration, il est logique de définir des éléments prédéfinis dans la configuration, mais de ne pas les créer dans tous les IB, mais uniquement pour les IB dans lesquels la logique de configuration requise est utilisée. Dans ce cas, le programmeur peut spécifier la propriété "Ne pas mettre à jour les données prédéfinies" pour le répertoire et créer les éléments par programmation lors de l'accès aux fonctionnalités du module. Soit permettre à l'utilisateur de lier indépendamment les éléments prédéfinis du module aux éléments habituels dont il dispose.

De plus, la création automatique d'éléments prédéfinis n'est pas utilisée lorsque vous travaillez en mode RIB. Étant donné que les nouveaux éléments doivent être transférés depuis la base centrale et non créés dans des nœuds avec des UID différents.

Ceux. parfois c'est une erreur de se référer à un élément sans correspondance, plutôt qu'à l'existence d'un tel élément lui-même.

Il est nécessaire d'analyser pourquoi l'élément n'a pas été créé. Il peut être nécessaire de le créer lorsqu'un mode de programme est exécuté. Par exemple, après avoir effectué un échange en RIB. Ou peut-être qu'il a été supprimé accidentellement.

Si la logique prévoit le remplissage d'éléments prédéfinis non pas automatiquement, mais dans un mode séparé, alors avant d'utiliser l'appel par nom " Annuaires.Types d'informations de contact.E-mail de la personne de contact" pour éviter une exception, il est souhaitable de vérifier que l'élément est déjà dans la base de données. Si l'élément est manquant, alors informez l'utilisateur à ce sujet et expliquez quel mode il doit effectuer pour remplir l'élément. Pour une telle vérification , vous pouvez interroger les données.

Demande = Nouvelle demande ; Query.Text = "SELECT | Types d'informations de contact. Lien | FROM | Répertoire. Types d'informations de contact AS Types d'informations de contact | WHERE | Types d'informations de contact. Nom des données prédéfinies = "" CourrielContactPersonne"" ; ElementMissingData = Query.Execute().Empty();

S'il s'agit toujours d'une erreur dans les données de la base de données, il est alors nécessaire de se lier à un élément prédéfini de l'élément IB. Ceux. il est nécessaire d'expliquer au système à quel élément du SI le code de programme doit se référer par ce nom. Techniquement, la liaison consiste simplement à spécifier le nom d'un élément prédéfini dans le "PredefinedDataNamePredefinedDataName"de l'élément IB. Pour l'installer, il suffit d'exécuter le code suivant :

2. "L'élément prédéfini n'est pas unique" - héléments prédéfinis annoncés :

Cette situation est que plusieurs éléments IB sont liés à un élément prédéfini. Dans ce cas, lors de l'accès au nom prédéfini, l'élément sera sélectionné au hasard. Cette situation est toujours fausse. Sa complexité est que la plate-forme n'en fait état d'aucune façon. C'est juste que les algorithmes commencent à mal fonctionner.

La plate-forme signalera uniquement une erreur "L'élément prédéfini n'est pas unique" lors de la tentative de modification d'un élément dupliqué.

Tant que personne n'a besoin de modifier l'élément, personne ne sera au courant de l'erreur.

De tels doublons peuvent être créés, par exemple, si RIB est utilisé pour l'annuaire et que le mode "Mettre à jour automatiquement" est spécifié dans les propriétés des données prédéfinies. Dans ce cas, lors d'un échange, une instance des données prédéfinies sera créée lors de la mise à jour de la configuration. La deuxième instance des éléments prédéfinis portant le même nom sera transférée de la base de données centrale lors de l'échange.

Aussi, ces doublons se produiront lors de l'utilisation du traitement de l'échange entre configurations si différents éléments du SI correspondent à des éléments prédéfinis dans des bases de données différentes. Dans ce cas, une instance de données prédéfinies est déjà dans la base de données, la seconde viendra lors du chargement des données avec un UID différent. Si vous effectuez des migrations de données, vous devez décider quels éléments de base de données sont considérés comme principaux et les utiliser dans la base de données subordonnée. Dans la base subordonnée, vous devez remplacer l'utilisation d'anciens éléments par des éléments de la base principale.

De telles erreurs dans la base de données peuvent être détectées par une requête telle que :

SELECT Types d'informations de contact. Nom des données prédéfinies, QUANTITÉ (DIFFÉRENTS types d'informations de contact. Lien) AS Nombre d'annuaires FROM prédéfinis. Types d'informations de contact AS Types d'informations de contact GROUP BY Types d'informations de contact. Nom des données prédéfinies AYANT DES QUANTITÉS (DIFFÉRENTS types d'informations de contact. Lien) > 1

Cette requête renverra une liste d'éléments prédéfinis avec plus d'un élément IB associé.

S'il existe de tels éléments, il est nécessaire de supprimer la connexion avec celle prédéfinie pour l'un d'entre eux. Ceux. il est nécessaire de déterminer sans ambiguïté pour le système à quel élément du SI le code de programme doit se référer lors de l'utilisation de ce nom. Pour ce faire, il suffit d'exécuter le code.

3. Mauvaise indication d'un élément prédéfini.

L'erreur réside dans le fait que l'élément prédéfini ne correspond pas à l'élément fourni par la logique du programme. Ces erreurs sont les plus difficiles à diagnostiquer. Contrairement aux deux premiers types, la configuration ne peut pas être vérifiée automatiquement pour ces erreurs. Ils ne peuvent être identifiés qu'en analysant la logique du travail. En cas de doute, vous pouvez vérifier si le bon élément est utilisé.

Pour ce faire, il vous suffit d'exécuter l'une des commandes.

//Définir l'élément IB lié au rapport prédéfini requis (Directory.Types of Contact Information.Email of the ContactPerson) //Définir l'élément prédéfini auquel le rapport sélectionné est lié (ReferenceToElement.PredefinedDataName)

Lorsque de telles erreurs sont détectées, il est nécessaire de supprimer le lien incorrect vers l'ancien élément et d'ajouter un lien vers le nouvel élément. Le code d'opération est similaire au code de correction des deux premiers types d'erreurs.

Eh bien, brièvement sur les erreurs lorsque programme de travail ou en mode configuration :

"L'élément prédéfini n'appartient pas<Имя справочника>" - une erreur se produit lors de la tentative d'écriture d'un élément prédéfini avec un nom qui ne correspond pas au nom dans le configurateur.

"Les objets non prédéfinis ne peuvent pas avoir d'entrées de type de sous-dimension prédéfinies" - une erreur se produit lors de la tentative de rendre un élément de plan comptable prédéfini non prédéfini. Pour éliminer les erreurs, il est nécessaire de retirer le drapeau "Prédéfini" de chaque ligne du sous-contact de l'élément.

"Les objets non prédéfinis ne peuvent pas avoir d'entrées de calcul de prospect prédéfinies"- une erreur se produit lors de la tentative de rendre un élément prédéfini du plan de types de calcul non prédéfini. Pour éliminer les erreurs, il est nécessaire de supprimer le drapeau "Prédéfini" de chaque ligne du type de calcul principal de l'élément.

"Les éléments prédéfinis ne sont pas uniques"- une erreur est levée dans le configurateur lors de la mise à jour base d'informations sur une version de configuration sans mode de compatibilité 8.3.4. Il est nécessaire de vérifier les doublons avant de les mettre à jour et de les éliminer.

"Le nom de l'élément prédéfini n'est pas unique" - une erreur se produit lorsqu'il y a plusieurs éléments prédéfinis du même nom dans la configuration lors de la mise à jour vers la plateforme8.3.6.2332 et supérieur. Il est nécessaire d'éliminer les doublons dans la configuration.

Pour travailler avec des données prédéfinies, je recommande de traiter . Il peut effectuer toutes les actions avec des données prédéfinies, et peut également vérifier la configuration dans son ensemble pour la présence d'erreurs des deux premiers types (éléments doublés et manquants) dans tous les objets du SI (annuaires, plans de comptes, PVC, PVR).

Lorsque vous travaillez sur la plate-forme 1C:Enterprise 8.x, il devient souvent nécessaire de lier dans le code du programme des éléments ordinaires (non prédéfinis) des répertoires. Par exemple, une organisation peut avoir cinq types de prix qui sont utilisés dans presque tous les mécanismes. Parallèlement, l'accès programmatique à un prix précis s'effectue, au mieux, soit par un squeak sur le code dans l'annuaire, au pire, par le nom de l'élément.

J'ai vu comment dans les rapports, pour obtenir le prix demandé, la sélection était utilisée par le type de prix dans la requête par son nom (voir la capture d'écran suivante).

En conséquence, nous obtenons un rapport instable qui cessera de fonctionner lorsque le nom du type de prix sera modifié. Si vous vous liez au code de l'élément, il y a toujours la possibilité de le changer. Par exemple, en raison d'une violation de l'unicité des codes de recherche, l'administrateur peut commencer à renuméroter les objets, ce qui entraînera une modification des codes des éléments et le rapport ne fonctionnera plus correctement.

De plus, si vous vous liez au nom ou au code des éléments du répertoire, alors lorsque vous recevez un lien vers l'élément, une recherche sera toujours effectuée dans la table du répertoire. Malgré le fait que les détails du système standard sont indexés par le SGBD, leur recherche dans certains cas peut nécessiter des ressources importantes. De plus, il serait plus rationnel de ne pas effectuer requête de recherche selon la table de référence, si, disons, la référence à l'élément est déjà "connue à l'avance".

Comme solution, vous pouvez stocker un lien vers chaque élément fréquemment utilisé du répertoire "Types de prix d'article" dans des constantes distinctes et en obtenir des valeurs dans la requête. Cependant, dans ce cas, le développeur devra ajouter une constante distincte pour chacun de ces éléments. La situation deviendra beaucoup plus compliquée si de tels éléments ne se trouvent pas seulement dans le répertoire "Types de prix de la nomenclature", mais également dans d'autres répertoires ("Catégories d'objets", "Qualité", "Nomenclature" et autres). Alors le nombre de constantes dans le système peut augmenter plusieurs fois !

Bien sûr, il serait possible d'ajouter des éléments prédéfinis à chacun des répertoires et y accéder deviendrait beaucoup plus facile. Cependant, la modification des objets génériques rendrait plus difficile la mise à jour de la configuration à partir des packages du fournisseur.

Il existe une approche plus optimale à la fois en termes de développement de la structure des métadonnées de configuration et en termes de performances du système. A propos de lui aujourd'hui et sera discuté.

Solution unique

L'essence de la solution universelle sera la suivante : un répertoire sera créé, dans lequel le développeur ajoutera des éléments prédéfinis. L'attribut "Valeur" a été ajouté au dictionnaire dont le type dépend des valeurs pour lesquelles la correspondance "Elément prédéfini du dictionnaire -> Valeur associée" sera créée. La structure des métadonnées du répertoire ressemble à ceci (voir la capture d'écran suivante).

Pour obtenir un élément prédéfini la meilleure option est d'utiliser la méthode globale "Valeur prédéfinie(<Имя>)" . En tant que paramètre, le chemin complet vers l'élément prédéfini est passé à la méthode. La syntaxe est similaire à la fonction de langage de requête "VALUE()" .

Pour la commodité du développement, je recommande de déplacer la fonction pour obtenir la valeur associée à l'élément prédéfini dans module commun. DANS test de configuration, disponible en téléchargement depuis le lien en fin d'article, un module commun "Valeurs des éléments prédéfinis" a été créé avec une fonction d'export "GetPredefinedElementValue(<ИмяПредопределенногоЭлемента>)" . Le code programme de la fonction reçoit une référence à un élément prédéfini, puis par requête reçoit les valeurs de l'attribut "Valeur". La capture d'écran suivante montre la liste complète de la fonction.

Comme on peut le voir, la fonction forme une requête à l'attribut "Valeur" de l'élément prédéfini passé en paramètre. Le paramètre de la fonction est une chaîne avec le nom d'un élément prédéfini.
Pour bon fonctionnement du mécanisme créé, il faut associer un élément prédéfini en mode utilisateur à un élément régulier du dictionnaire en sélectionnant l'élément approprié dans l'attribut "Valeur". Passons à la question de l'impact sur les performances.

Impact sur les performances

Réalisation d'un speed test pour les deux options de recherche : par nom et par lien à partir d'un élément prédéfini. La recherche a eu lieu dans le répertoire "Marchandises" avec 20 000 entrées. Lors de la réalisation de tests sur la base de fichiers, les résultats suivants ont été obtenus :

Les résultats ont montré que pour la version fichier de travail, l'utilisation d'éléments prédéfinis pour obtenir des éléments fréquemment utilisés d'autres répertoires est presque 4 fois plus lente !

Dans la version client-serveur du travail, les résultats des tests montrent une image complètement différente. La vitesse d'obtention d'un lien vers l'élément souhaité n'a pas diminué de manière significative (l'un des tests a montré 0,002 seconde pour la recherche par nom et 0,0008 seconde pour parcourir un élément prédéfini), mais la fiabilité du programme a considérablement augmenté !

conclusions

Dans les cas où il est souvent nécessaire de se lier à des éléments ordinaires du répertoire, je recommande de ne pas utiliser de liaison par code ou par nom. Cette approche réduit la fiabilité et les performances du système.

En travaillant avec la plate-forme, j'ai rencontré à plusieurs reprises des situations où, après avoir changé le nom, par exemple, le travail de la majorité des rapports non standard s'est écrasé pour l'élément de l'ouvrage de référence "Types de prix de nomenclature".

Plus les algorithmes sont associés aux éléments usuels des annuaires par un code ou un nom, moins le système est stable.

De plus, cette approche vous permettra de ne pas modifier les objets de configuration typiques si vous devez leur ajouter un élément prédéfini. À l'avenir, cela facilitera quelque peu le processus de mise à jour de la configuration.

Téléchargements :

  1. Déchargement d'une base de données de test avec des exemples de l'article.

Tout le monde connaît la différence entre les éléments prédéfinis et les éléments normaux : "Les éléments prédéfinis sont créés en mode Configurateur et ne peuvent pas être supprimés en mode 1C:Enterprise." En mode utilisateur, vous pouvez distinguer un élément prédéfini de ceux ajoutés par les utilisateurs par une icône spéciale (voir la capture d'écran suivante).

Fondamentalement, les éléments prédéfinis sont créés par les développeurs afin de leur lier des algorithmes dans divers objets de configuration. Par exemple, dans la configuration "Manufacturing Enterprise Management" du référentiel "Qualité", les développeurs ont ajouté un élément prédéfini "Nouveau".

Cet élément est utilisé dans de nombreux modules de configuration. Ainsi, dans le document "Réception des biens et services" lors de l'affichage dans tous les registres où il y a une dimension "Qualité", la valeur d'un élément prédéfini est substituée. Ce qui suit est une liste de remplissage du tableau d'affichage selon le registre "GoodsOrganizations":

// MARCHANDISES PAR REGISTRE GoodsOrganizations. MoveSet = se déplace. MarchandisesOrganisations ; Si ReceiptType = Énumérations. Types d'entrées de marchandises. Entreposer ensuite // Récupère une table de valeurs qui correspond à la structure du jeu d'enregistrements du registre. MoveTable =MoveSet. Décharger() ; // Remplir la table des mouvements. Usage général. LoadToValueTable(TableByProducts,TableMovements) ; // Champs manquants. Tableau des mouvements. FillValues(Organisation, "Organisation" ) ; Tableau des mouvements. FillValues(Undefined , "Commissaire" ) ​​; Tableau des mouvements. FillValues(References. Quality. New , " Quality " ) ; // Remplir la qualité à partir d'un élément prédéfini

Ainsi, les caractéristiques des éléments prédéfinis et leur objectif sont assez simples. Considérons comment ils sont stockés dans les tables de base de données et comment cela diffère des éléments ordinaires.

Différences

Dans la configuration de test, le répertoire "Marchandises" a été créé. Le groupe "Éléments de test" y est créé. Vous pouvez voir le contenu du groupe dans la capture d'écran au début de l'article. Pour le livre de référence "Produits" dans la base de données SQL, il existe une table correspondante "_Reference37" avec la structure suivante :

Mais comment déterminer la correspondance entre les détails de l'arborescence de configuration et les champs de la table SQL ?

Utilisons la méthode standard du contexte global "GetDatabaseStorageStructure()", qui renverra un tableau de valeurs avec une description de la structure du tableau.

Dans la table de valeurs "Champs", on voit la correspondance entre les champs de la table SQL et les détails de l'objet dans l'arborescence des métadonnées. Dans notre exemple, nous considérons la structure du répertoire "Produits". Tous les dictionnaires ont un attribut standard "Predefined" de type booléen, qui est défini sur TRUE pour les éléments prédéfinis :

D'après le tableau avec la structure de stockage des répertoires dans la base de données, nous pouvons certainement dire que le champ "Predefined" correspond au champ "IsMetadata". Si nous visualisons le contenu de la table "_Reference37" dans la base de données SQL, nous verrons ce qui suit :

Dans l'entrée de l'élément prédéfini, la valeur du champ "IsMetadata" est définie sur "0x01", ce qui correspond au flag TRUE. Pour les éléments normaux, la valeur est définie sur "0x00". C'est la principale différence entre les éléments prédéfinis et les éléments ordinaires. Tous les autres champs sont stockés dans la base de données de la même manière que les champs des éléments ordinaires ajoutés par les utilisateurs.

Les éléments prédéfinis peuvent trouver une utilité très intéressante. Avec leur aide, vous pouvez interdire la suppression / marquage pour suppression d'un groupe d'éléments dans le répertoire et d'autres objets où ils peuvent être ajoutés. Si nous essayons de supprimer ou de marquer pour suppression le groupe "Éléments de test". nous obtenons les erreurs suivantes :

Ainsi, les éléments prédéfinis rendent le groupe dans lequel ils sont placés également "prédéfini".

Achèvement

Les éléments prédéfinis font partie intégrante de la plupart des configurations. Leur utilisation simplifie la mise au point et rend la construction du fonctionnel logiquement plus « harmonieuse » et solide.

Dans la quatrième leçon de notre nous continuerons à nous familiariser avec le programme. Aujourd'hui nous sommes sur exemples pratiques connaître etdes répertoires hiérarchiques, ainsi qu'apprendre à créer des éléments prédéfinis.

Timing 4 leçons du cours :

00:19 Changements dans le répertoire Employés après avoir terminé les devoirs de la 3e leçon du cours
00:35 Modification de l'ordre des détails dans les répertoires
02:54 Création d'un répertoire Nomenclature
03:40 Création et configuration d'un répertoire hiérarchique
05:10 Création des groupes Services et Biens dans le répertoire Nomenclature
06:05 Remplir le répertoire Nomenclature
07:14 3 façons de transférer un élément de répertoire vers un autre groupe
08:21 Création d'un répertoire Entrepôts
09:19 Création d'éléments de répertoire prédéfinis
11:25 Remplir le répertoire Entrepôts
12:20 Faites un test sur le matériel 4 leçons

Annuaire hiérarchique– un répertoire avec possibilité de hiérarchisation de ses éléments. Par exemple, dans le référentiel Nomenclature, des groupes peuvent être créés : Biens, Services, etc., dans lesquels se trouvent les éléments liés à ces groupes. De plus, les groupes de répertoires peuvent inclure d'autres groupes, créant ainsi une structure hiérarchique à plusieurs niveaux.

De plus, les répertoires supportent un autre type de hiérarchie, dans lequel les éléments du répertoire n'appartiendront pas à des groupes, mais à d'autres éléments du même répertoire. Ce genre de hiérarchie hiérarchie des éléments) peut être utilisé, par exemple, lors de la création d'un répertoire Subdivision, où une subdivision (une subdivision dans ce cas est un élément du répertoire, pas un groupe) peut inclure plusieurs autres subdivisions. Ce type de hiérarchie est rarement utilisé.

Formulaires d'annuaire- représentation visuelle du répertoire. Selon les actions que nous voulons effectuer avec notre répertoire, nous devons afficher le répertoire dans "différentes vues". Ainsi, à la 4ème leçon du cours, nous avons édité l'ordre des détails sous forme de liste et sous forme d'élément de référence.

Le système crée (génère) des formulaires automatiquement, mais, si nécessaire, le développeur peut "dessiner" lui-même les formulaires.

Au total, il existe 5 formulaires (types de formulaires) pour les annuaires :

  • forme de l'élément– pour créer ou éditer un élément de répertoire ;
  • formulaire de groupe- pour créer ou modifier un groupe d'annuaires ;
  • formulaire de liste– pour afficher la liste des éléments du répertoire ;
  • formulaire de sélection- permet de sélectionner un des éléments d'un champ de formulaire ce manuel. Par exemple, pour sélectionner un entrepôt spécifique dans le répertoire Entrepôts dans le champ Entrepôt du document Entrée de marchandises ;
  • formulaire de sélection de groupe- permet de sélectionner un des groupes de cet annuaire dans le champ d'un certain formulaire.

Éléments de répertoire prédéfinis- des éléments de répertoire créés par le développeur en mode Configurateur, et accessibles depuis le langage 1c intégré par nom.

Il existe une différence fondamentale entre les éléments de répertoire réguliers et prédéfinis. Les éléments ordinaires ne sont pas permanents dans la configuration. Pendant le travail de l'utilisateur, ils peuvent être créés, modifiés et supprimés et, pour cette raison, ils ne doivent pas être invoqués lors de l'exécution d'algorithmes (le code et le nom de l'élément peuvent être modifiés par l'utilisateur).Les éléments prédéfinis, en revanche, sont persistants. Au cours du travail, même si l'utilisateur renomme un tel élément, il est accessible à partir du langage 1c intégré. Ceci est réalisé en faisant en sorte que l'élément prédéfini ait des accessoires Nom, qui n'est pas disponible pour l'utilisateur. Les éléments de répertoire ordinaires n'ont pas cet attribut.

Important! Techniquement, l'utilisateur a la possibilité de supprimer un élément de répertoire prédéfini, mais, en règle générale, les utilisateurs se voient refuser le droit de supprimer des éléments de répertoire prédéfinis.

Devoir pour la leçon 4 du cours

Les devoirs pour la quatrième leçon du cours seront mis à votre disposition immédiatement après avoir réussi le test théorique.

Bonne journée.

Aujourd'hui, nous allons parler de l'innovation de la plateforme 8.3 concernant les éléments prédéfinis.

Introduction

Permettez-moi de vous rappeler qu'auparavant, dans la pratique, je voulais très souvent regarder l'élément répertoire pour connaître son nom prédéfini. Par exemple, vous avez créé deux contreparties prédéfinies et les avez nommées IPSidorov et OOOMeteor. Et ils y ont cousu une logique.

Lorsque tout a été débogué et mis au point, il s'est avéré que la tâche était définie dans l'autre sens et que la logique pour IP est nécessaire pour OOO, et la logique de OOO pour IP. "Pas de problème", disons-nous, et en mode entreprise, nous renommons les éléments. Après tout, entrer dans le code est beaucoup plus difficile. Une année passe et une nouvelle tâche vous est confiée : mettre en place un peu plus de logique pour IP Sidorov. Vous montez dans le configurateur, écrivez la logique, commencez à vérifier et rien ne fonctionne, car dans le configurateur IPSidorov et dans l'entreprise - Meteor LLC. Le cerveau est cassé et je veux détruire ce râteau. La manière la plus simple et la plus visuelle est d'afficher le nom d'un élément prédéfini sous forme de liste. Voici une embuscade, vous ne pouvez obtenir le nom d'une embuscade prédéfinie en 8.2 que par une méthode. Et la méthode est son propre inconvénient, elle ne peut pas être obtenue dans la demande. Ceux. le premier inconvénient est d'obtenir le nom du prédéfini par référence au répertoire.

Le deuxième inconvénient est lorsque nous avons déjà un élément de répertoire et que nous devons le rendre prédéfini. Nous créons un élément prédéfini et obtenons deux éléments dans la référence. L'un est prédéfini, l'autre est un travailleur auquel tous nos documents font référence. Remplacer des liens aide certainement, mais si la base de données est volumineuse, c'est difficile.

Maintenant en affaires

La première chose est que le répertoire a maintenant la propriété "Mettre à jour les données prédéfinies".

Que nous apporte ce champ ? S'il est défini sur "Ne pas mettre à jour automatiquement", alors en ajoutant un élément prédéfini, nous ne le verrons pas immédiatement dans le répertoire. Ceux. les métadonnées n'ont rien à voir avec les données. Et s'il n'est pas créé dans le répertoire, y accéder par son nom via le gestionnaire de répertoires provoquera une erreur de syntaxe.

Très intéressant, mais pourquoi ? Comment crée-t-on un élément dans le répertoire ? Et comme vous le souhaitez, vous pouvez le créer, ou vous pouvez le lier à un existant. Le dictionnaire a maintenant l'attribut "PredefinedDataName". Nous créons un élément de dictionnaire par programmation comme d'habitude via "Directories.Accounts.CreateItem()" et remplissons son attribut "PredefinedDataName" égal au nom de l'élément prédéfini. Ou, si l'élément existe déjà, nous obtenons son objet et remplissons à nouveau le "PredefinedDataName" dedans. Tous.

Et enfin du sirop

Ce nouveaux accessoires, non seulement il est lisible et inscriptible, mais il est également disponible dans les requêtes. Ainsi, vous pouvez lui imposer des conditions dans les requêtes, déterminer s'il est prédéfini ou non.

Merci pour votre attention.