Être dans un groupe selon la hiérarchie 1C 8. L'opérateur « dans la hiérarchie » dans la demande. Obtenir tous les parents d'un élément

12.12.2023Titre: Sécurité

Ildarovitch 6489 16.11.12 18:24 Actuellement sur le sujet

() Vladimir ! Je suis heureux que vous ayez prêté attention à l'article, d'autant plus que vous avez été l'un des premiers à voir (et à apprécier) cette technique lors de la discussion il y a deux ans : « Il est réaliste d'écrire une requête délicate ». Je n'ai pas posé de question intéressante par moi-même, mais je l'ai vue sur le forum. L'auteur de la question est Stanislav Sheptalov. Ensuite - le 24/10/12 (je viens de le remarquer, puisque le surnom est différent), un participant au forum a posé une question similaire, mais en application à la hiérarchie. Il s'avère que le problème PRATIQUE a été résolu. De plus, conformément à l'approche « scientifique », j'ai examiné des problèmes pratiques où cette technique pourrait être appliquée. J'ai trouvé 7 autres problèmes. 5 - dans cet article. Parmi eux se trouve le problème des cycles dans les spécifications, que j'avais précédemment promis de résoudre Ish_2 avec une seule requête. Je pense qu'Ish_2 saura vous convaincre de la pertinence de cette tâche - il y a consacré beaucoup de temps. La solution est courte, quelques lignes, donc extrêmement claires, formulées dans un style non procédural, par une exigence de résultat. Eh bien, d'autres problèmes ont été rencontrés dans les articles et sur le forum, et des solutions plus lourdes ont été proposées pour eux. Attendons donc un peu pour voir à quelle fréquence cela sera appliqué. C’est exactement le genre de retours que j’attends – de la part de ceux qui essaieront.
D'ailleurs, le fait que cette branche des mathématiques ne soit pas loin de la pratique et soit nécessaire aux comptables est attesté par le module général « Ajustement des coûts » dans BP2, que nous sommes en train de bricoler (fonctionnement instable de la requête standard). Nous parlons ici de briser les cycles du graphique de mouvement des objets et de construire un arbre couvrant.
Parlons maintenant de la structure de la base de données « pour une tâche spécifique ». La question a été posée sur la mise en œuvre de la tâche en 1C et, par conséquent, la tâche a été résolue en 1C. Si on vous demandait « quel bus pouvez-vous prendre pour vous rendre à la bibliothèque » et que vous répondiez qu'il est préférable de voler sur un dirigeable, alors vous ne seriez tout simplement pas compris (peut-être sauf pour ceux qui sont coincés dans un embouteillage à Moscou ). Au départ, la méthode fonctionnait dans un langage complètement différent.
En général, je ne pourrai pas vous convaincre si vous pensez que l'architecture de la plateforme 1C n'est pas bonne. Je ne peux qu'exprimer mon opinion. Développer un schéma de base de données à partir de zéro pour une tâche spécifique coûte cher. Si on le compare à la construction : 1C, ce sont des immeubles de grande hauteur en panneaux - des logements bon marché - un moyen d'automatisation de masse - dans des conditions exiguës, mais sans vouloir offenser. Les organisations individuelles peuvent embaucher Norman Foster pour mettre en œuvre avec précision leurs exigences. Les autres doivent utiliser des projets de masse bon marché - des SGBD relationnels avec un modèle objet rigide. De plus, je connais la triste expérience de l'utilisation de Cashe dans plusieurs projets. Aux yeux d’un développeur, tout ne semble pas aussi rose qu’en théorie. Le modèle objet 1C résiste à l'épreuve du temps : « de vastes territoires sont construits et habités ». De plus, cela se développe. Récemment, la technologie des sources de données externes a fait son apparition. Et si certaines tâches nécessitent une réactivité plus élevée (par exemple, les systèmes de facturation), vous pouvez désormais connecter de manière transparente 1C à un autre SGBD. C’est par exemple ainsi que nous échangeons avec des ERP importés.
Mais je ne voudrais quand même pas détourner la conversation du sujet principal - le travail des techniques proposées dans des tâches PRATIQUES détaillées.

Qu'est-ce qu'un annuaire 1C et pourquoi est-il nécessaire ? Le répertoire stocke des informations conditionnellement permanentes, c'est-à-dire des informations qui restent quasiment inchangées sur une longue période. Par exemple, le répertoire « Nomenclature » contient une liste de biens vendus ou produits. De plus, un répertoire peut contenir de nombreuses propriétés décrivant un élément de répertoire.

Si nous prenons le sexe d'une personne à des fins de comparaison, alors la liste est limitée et ne change pas, donc une énumération lui convient mieux.

Après avoir créé un nouveau répertoire, nous verrons l'image suivante.

Regardons tous ses favoris.

Basique

Ici sont indiqués le nom (identifiant dans la base de données) et le synonyme (nom d'utilisateur de l'annuaire). Un commentaire facultatif est celui qui peut expliquer le but du répertoire ou décrire ses fonctionnalités.

Hiérarchie

Sur cet onglet, vous pouvez configurer la profondeur d'imbrication des éléments du répertoire. Grâce à ce paramètre, il est pratique de différencier et de détailler les éléments selon certains critères. Par exemple, les produits « Armoires » se trouvent dans un groupe et les produits « Tables » dans un autre. Par défaut, lors de sa création, le répertoire présente liste d'éléments. Si vous cochez la case Répertoire hiérarchique, alors chaque élément peut être subordonné à un autre élément (groupe). Vous trouverez ci-dessous les options permettant de personnaliser ce signet et de modifier l'affichage en mode personnalisé.

Type de hiérarchie :

Hiérarchie des groupes et des éléments

Avec ce paramètre, les éléments ne peuvent être imbriqués que dans des groupes (dossiers).

Ici, comme vous pouvez le voir, tous les éléments et groupes ont les mêmes icônes et n'importe quel élément peut être imbriqué.

Placer les groupes en haut

Lorsque cette case est cochée, les groupes seront toujours en haut, sinon ils seront classés par ordre de tri, par exemple comme ceci :

Limiter le nombre de niveaux hiérarchiques

Si la case n'est pas cochée ici, alors l'imbrication est illimitée.

Si la case est cochée, vous pouvez spécifier le nombre de niveaux ci-dessous.

Les propriétaires

Sur le marque-page les propriétaires d'autres répertoires peuvent être indiqués par rapport auxquels celui-ci est subordonné. Le diagramme de relations des répertoires subordonnés est similaire au diagramme de relations d'un répertoire hiérarchique, sauf qu'ici un autre répertoire agit en tant que parent et est appelé propriétaire. Dans des configurations typiques, un bon exemple est la subordination du répertoire « Accords » au répertoire « Contreparties », car Il ne peut y avoir d’accord qui n’appartient à aucune contrepartie.

Le champ "Liste des propriétaires du répertoire" précise la liste des répertoires propriétaires des éléments de ce répertoire.

Ci-dessous dans le champ « Utilisation de la subordination » il est indiqué à quoi les éléments de ce répertoire seront subordonnés.

Comment savoir par programme si un répertoire est hiérarchique ou non

Pour ce faire, vous devez vous référer aux métadonnées

Il s'agit de HierarchicalDirectory = Metadata.Directories.Counterparties.Hierarchical ;

À suivre...

Les répertoires 1C sont un objet d'arborescence de métadonnées spécialisé qui sert à stocker des informations de référence statiques. Par exemple, dans les configurations typiques, vous pouvez voir les vues suivantes : , Nomenclature, Employés, Immobilisations, etc. En règle générale, les informations contenues dans les annuaires ne changent pas souvent. Les répertoires sont ensuite utilisés dans presque tous les objets comptables comme section comptable ou information de référence.

Nous verrons ci-dessous la configuration et la conception d'un répertoire à partir du configurateur en prenant comme exemple le répertoire « Nomenclature ».

Onglet de base

L'onglet « Basique » spécifie le nom, le synonyme, la représentation de l'objet et la description de l'objectif.

Onglet « Hiérarchie des répertoires »

Ici, la hiérarchie du répertoire est établie.

La hiérarchie dans 1C 8.3 est de deux types - " groupes et éléments" Et " éléments". Cela diffère en ce que dans le premier cas, seul un dossier (groupe) peut être un parent (dossier), et dans le second cas, un élément peut également être un parent.

"Placer les groupes en haut" - le drapeau est responsable de l'affichage des groupes sous forme de liste.

Également dans les paramètres, vous pouvez limiter le nombre de groupes dans la hiérarchie des répertoires en utilisant le paramètre approprié.

Onglet Propriétaires

Un répertoire peut être subordonné à un autre répertoire. Du point de vue de la configuration de 1C 8.3, cela signifie que l'attribut « Propriétaire » devient obligatoire pour l'élément subordonné. Un exemple d'une telle connexion entre annuaires dans les configurations standards « Nomenclature - Unités de mesure », « Contreparties - Contrats d'entrepreneurs ».

Le propriétaire du répertoire peut également être les objets de métadonnées suivants : , .

Onglet Données

Obtenez 267 leçons vidéo sur 1C gratuitement :

L'onglet le plus important du point de vue d'un programmeur. Il contient les détails du répertoire.

Le répertoire contient un ensemble de détails standards qui ne sont pas édités par le programmeur 1C 8.2 ; une liste d'entre eux peut être consultée en cliquant sur le bouton « Détails standard » :

Je vais m'attarder sur chacun plus en détail :

Ce groupe— un attribut de type booléen, indiquant s'il s'agit d'un groupe ou d'un élément. Disponible uniquement dans le répertoire hiérarchique. Note, la valeur de cet attribut ne peut pas être modifiée en 1C : mode Entreprise.
Code— accessoires, tapez un nombre ou une chaîne (généralement une chaîne). Un numéro attribué automatiquement par le système. Généralement calculé comme (code précédent + 1). Je recommande d'utiliser le type chaîne, car le tri des valeurs numériques ne fonctionne pas comme prévu. Peut être utilisé comme présentation d'annuaire dans une liste et dans des champs de saisie. Généralement utilisé pour rechercher un élément lors de la saisie d'une chaîne. Si vous devez supprimer le champ Code, entrez zéro dans la longueur de la ligne.
Nom— détails obligatoires, type de chaîne. La longueur maximale d'une ligne est de 150 caractères. Peut être utilisé comme présentation d'annuaire dans une liste et dans des champs de saisie. Généralement utilisé pour rechercher un élément lors de la saisie d'une chaîne. Si vous devez supprimer le champ Nom, entrez zéro dans la longueur de la ligne.
Parent— un attribut de type DirectoryLink.<ИмяТекущегоСправочника>. Disponible uniquement dans le répertoire hiérarchique. Pointe vers le parent supérieur dans la hiérarchie. Si l'Element ou le Groupe est à la racine du répertoire, la valeur Directory est spécifiée.<ИмяТекущегоСправочника>.EmptyLink.
Propriétaire— lien vers l'élément propriétaire de l'élément de répertoire actuel (groupe). Disponible uniquement dans le répertoire subordonné 1C.
Suppression du drapeau— accessoires de type booléen. Responsable de l’affichage de la « marque de suppression » dans le système. Un élément marqué pour suppression est considéré comme inutilisable, mais d'anciens mouvements de documents peuvent y rester.
Lien— champ de type chaîne. Cet attribut stocke un identifiant d'objet unique - GUID. Ce que nous voyons dans le système dans un affichage visuel appelé « lien » n’est qu’une représentation d’un objet. Ne peut pas être modifié.
Prédéfini- type booléen, affiche si l'élément est prédéfini, nous en reparlerons plus tard. Ne peut pas être modifié.

L'onglet « Données » indique également la représentation de l'annuaire dans le système ; avant la version 8.2.16, la représentation ne pouvait être que Code ou Nom. Dans les versions récentes de la plateforme (à partir de la 8.3), la vue peut être décrite indépendamment dans le module gestionnaire à l'aide du gestionnaire « ViewReceiveProcessing ».

Onglet Numérotation

Ici, vous pouvez spécifier les paramètres du répertoire concernant la numérotation. Il est recommandé d'utiliser la numérotation automatique. Le contrôle d'unicité est un indicateur qui permet, si nécessaire, de rendre le code unique. Si, avec l'indicateur activé, vous essayez d'écrire un élément de répertoire avec un code non unique, dans 1C, vous recevrez le message "Le code du répertoire est devenu non unique".

Série de codes - détermine comment numéroter le répertoire ; vous pouvez saisir la numérotation du répertoire par propriétaire. Par exemple, la contrepartie « Horns and Hooves » aura sa propre numérotation de contrats - « 1, 2, 3 », etc.

Onglet Formulaires

Les formulaires du répertoire sont décrits ici. Si la configuration est lancée à la fois en mode normal et en mode géré, alors il y aura deux onglets avec des formulaires par défaut : « principal » et « avancé » - différents pour les applications normales et gérées.

Cette page présente une fonctionnalité importante du répertoire - "". Il s'agit d'une fonction très pratique de 1C 8, qui permet, lors du remplissage des données dans le champ de saisie, de ne pas accéder au répertoire, mais de saisir son nom, son code, etc. et sélectionnez l'élément souhaité dans la liste déroulante. Cela ressemble à ceci :

Autre onglet

Sur l'onglet, vous pouvez accéder rapidement aux principaux modules du répertoire - le module objet et le module gestionnaire.

Vous pouvez également définir une liste d'éléments de répertoire prédéfinis sur la page. Ce sont des éléments qui ne peuvent pas être supprimés en mode Entreprise. Les éléments prédéfinis sont accessibles directement dans le configurateur par nom, par exemple : Directories.Nomenclature.Service.

Cet onglet détermine également le mode de blocage - automatique ou contrôlé. Utilisation de la recherche en texte intégral, ainsi que des informations de référence sur l'annuaire, disponibles en 1C : Mode Entreprise.

La conception « DANS LA HIÉRARCHIE » dans les requêtes 1C:Enterprise 8.x permet d'obtenir des éléments subordonnés d'un objet de configuration hiérarchique selon une sélection donnée. Aujourd'hui dans l'article nous allons regarder un exemple de son utilisation, ainsi que les actions de la plateforme côté SGBD et son impact sur les performances.

Usage

Regardons un exemple simple d'utilisation de la construction « DANS LA HIÉRARCHIE ». Lors de l'exécution de la requête suivante, les éléments subordonnés du répertoire hiérarchique « Produits » seront obtenus pour la valeur transmise de la variable « Lien ».

Dans la base de données de tests, le répertoire « Produits » contient les données de tests suivantes :

Bien entendu, l'image ne montre pas toutes les entrées du répertoire. La capture d'écran montre uniquement la structure de stockage des données dans le répertoire hiérarchique. La table de répertoire stocke 10 groupes de niveau supérieur, chacun contenant 5 groupes imbriqués de 200 éléments chacun.

Revenons à la demande de test. Passons le lien vers le groupe "Groupe - 1" au paramètre "&Link" (voir capture d'écran ci-dessus). Le résultat de la requête ressemblera alors à ceci :

Comme nous pouvons le voir, la requête a renvoyé un lien vers le groupe supérieur lui-même (passé en paramètre), ainsi que des groupes imbriqués contenant les éléments qu'ils contiennent. Ainsi, l'utilisation de la construction « DANS LA HIÉRARCHIE » permet d'obtenir facilement des données hiérarchiquement subordonnées.

Syntaxe du langage de requête 1C:Enterprise SQL classique très similaire à certains égards. Mais pour l'expression « IN HIERARCHY », il n'y a pas d'analogue dans le langage de requête SQL puisque, par exemple, pour l'expression du langage de requête de la plateforme « B », il existe un opérateur SQL similaire « IN ». Par conséquent, le travail de la plateforme avec le SGBD lors de l'utilisation de cet opérateur est intéressant.

Dans les coulisses

Alors, commençons. Par exemple, nous utiliserons la requête écrite précédemment pour le répertoire « Produits ». Nous analyserons les actions de la plateforme pour deux situations :

Nous passerons le groupe de niveau supérieur « Groupe 1 » comme paramètre « &Link » (comme nous l'avons fait précédemment).
Dans le paramètre nous passerons un lien vers le groupe "Groupe 1 - 1", imbriqué dans le groupe de niveau supérieur "Groupe 1".

Maintenant, dans l'ordre. Dans le premier cas, la plateforme effectuera les actions suivantes sur le serveur SQL :

1. Tout d'abord, une requête SQL est exécutée pour obtenir un lien vers le groupe d'annuaire passé en paramètre et tous les groupes subordonnés. Le résultat est placé dans la table temporaire "#tt1".

2. Dans la deuxième étape, la même requête est exécutée deux fois :

La capture d'écran contient des commentaires détaillés sur le texte de la requête SQL. En bref, la requête vous permet de sélectionner des éléments subordonnés pour des groupes référencés dans une table temporaire. La question demeure : « Pourquoi la requête est-elle exécutée deux fois ? La réponse ici est simple : d'abord, la requête reçoit des éléments subordonnés pour les groupes de premier niveau déjà contenus dans la table temporaire (voir point 1). La deuxième requête récupère ensuite les sous-éléments des sous-groupes de deuxième niveau. Aucun groupe d'annuaire n'étant présent au troisième niveau de la hiérarchie, cette requête n'est plus exécutée.

Dans notre cas, la deuxième requête renverra un résultat vide, puisqu'il n'y a pas d'éléments subordonnés pour les enregistrements situés au 3ème niveau de la hiérarchie (il n'y a pas de groupes là-bas).

3. Pour obtenir le résultat final de la requête, la plateforme génère la requête SQL suivante :

Le résultat de cette requête particulière peut être traité ultérieurement par des algorithmes dans le langage intégré de la plateforme. Ainsi, les entrées de la table temporaire "#tt1" sont utilisées pour définir la condition d'échantillonnage à partir de la table de référence "_Reference41".

4. Lors de la dernière étape, la plateforme 1C:Enterprise 8.x supprime la table temporaire « #tt1 », puisqu'elle ne sera plus utilisée à l'avenir.

Ceci termine le processus d'exécution de l'opérateur « DANS LA HIÉRARCHIE ». Permettez-moi de vous rappeler que la séquence d'actions considérée sur le serveur SQL a été effectuée lorsque nous avons transmis un lien vers le groupe de niveau supérieur « Groupe - 1 » vers une requête côté plateforme. Mais comment la plateforme se comportera-t-elle si nous passons un lien vers le groupe de deuxième niveau « Groupe - 1 - 1 » comme paramètre « &Lien » ? Tout se passera de la même manière, à l'exception du point suivant : ci-dessus, dans la deuxième étape d'exécution des requêtes SQL par la plateforme, il a été écrit que la requête pour obtenir des éléments subordonnés était exécutée deux fois - dans le cas de l'obtention d'éléments subordonnés pour le groupe "Groupe - 1 - 1" ce n'est pas le cas. La demande ne sera exécutée qu'une seule fois.

Le fait est que le nombre de demandes d'obtention d'éléments subordonnés dépend du nombre de groupes dans la hiérarchie. En d'autres termes, si le niveau hiérarchique des éléments contient au moins un groupe, alors le demande du point 2.

Impact sur les performances

Une utilisation incorrecte d'un opérateur dans une requête peut entraîner des performances système sous-optimales. L'opérateur considéré « EN HIÉRARCHIE » ne fait pas exception. Il doit être utilisé avec prudence, car il complique grandement l'algorithme d'exécution des requêtes SQL sur la base de données et augmente ainsi la charge sur le serveur SGBD.

Laissez-moi vous donner un exemple de requête sous-optimale qui peut entraîner les tristes conséquences mentionnées ci-dessus :

PRODUITS SÉLECTIONNÉS. Lien DEPUIS le répertoire. Produits COMME Produits OÙ (Produits. Lien DANS LA HIÉRARCHIE (& Lien) OU Produits. Lien DANS LA HIÉRARCHIE (& Lien1) OU Produits. Lien DANS LA HIÉRARCHIE (& Lien2) )

Comme vous pouvez le deviner, la requête va entraîner la génération de nombreuses requêtes SQL, ce qui se traduira par une diminution des performances du système d’information.

Tirez vos conclusions !

C'est à vous d'en tirer des conclusions. Permettez-moi simplement de dire que l'opérateur « DANS LA HIÉRARCHIE » est utilisé par la plateforme pour le système de composition des données lorsque les conditions de sélection incluent « DANS LE GROUPE », « DANS LE GROUPE DE LA LISTE » et autres. Je pense qu'il n'est pas nécessaire d'expliquer qu'avec des manipulations incorrectes, les utilisateurs peuvent mettre en place des sélections très complexes et augmenter plusieurs fois la charge sur le serveur 1C et le SGBD. Modifions les paramètres uniquement pour les utilisateurs expérimentés.

Et bien sûr, lorsque vous écrivez vos propres mécanismes, faites attention à l'opérateur « DANS LA HIÉRARCHIE ». Très pratique d’un côté et dangereux de l’autre.

Cette section montre des exemples de résolution de problèmes typiques lors de l'utilisation de répertoires hiérarchiques.

Obtention des éléments d'un répertoire hiérarchique subordonnés à un groupe donné

Pour obtenir des éléments subordonnés d'un répertoire hiérarchique, le langage de requête fournit la construction IN HIERARCHY. Exemple d'utilisation EN HIÉRARCHIE :

CHOISIR
Nomenclature.Code,
Nomenclature.PurchasePrice
DEPUIS

Dans cet exemple, tous les enregistrements du répertoire Nomenclature situés dans le groupe &Groupe seront obtenus, y compris lui-même, ses groupes subordonnés et les éléments appartenant aux groupes subordonnés.

Si nous ne nous intéressons qu'aux éléments et groupes situés directement dans un groupe donné, alors nous pouvons obtenir de tels éléments en définissant une condition sur le champ Parent. Exemple:

CHOISIR
Nomenclature.Code,
Nomenclature Nom AS Nom,
Nomenclature.PurchasePrice
DEPUIS
Annuaire.Nomenclature AS Nomenclature

OÙ
Nomenclature.Parent = &Groupe

Cette requête sélectionnera les groupes et les éléments subordonnés au groupe avec le lien &Groupe.

Vérifier la présence d'éléments subordonnés d'un élément de répertoire

Pour vérifier la présence d'enregistrements subordonnés d'un élément d'annuaire, vous pouvez utiliser une requête similaire à celle présentée :

Dans cet exemple, la référence à l'élément pour lequel vous souhaitez rechercher des enfants est écrite dans le paramètre de requête Parent. Après avoir exécuté une telle requête, vous devez vérifier que le résultat est vide. Si le résultat n’est pas vide, alors il existe des enregistrements subordonnés. Sinon - non. Exemple:

Si Request.Execute().Empty() Alors
Rapport("Aucune entrée");
Sinon
Rapport("Enregistrements disponibles");
fin si;

Obtenir tous les parents d'un élément

Le langage de requête ne fournit aucun moyen spécial pour récupérer tous les parents d'un élément. Vous pouvez utiliser des totaux hiérarchiques pour effectuer la tâche, mais l'obtention de totaux hiérarchiques est optimisée pour générer des totaux pour un grand nombre d'enregistrements et n'est pas entièrement efficace pour obtenir les parents d'un seul élément. Pour récupérer plus efficacement tous les enregistrements parents d'un élément, il est recommandé de parcourir ses parents par petites portions. Exemple:

ObjetActuel = ObjetArticle ;

Pendant que le cycle de la vérité
Request.SetParameter("CurrentItemItem", CurrentItemItem);
Résultat = Query.Run();
Si Résultat.Empty() Alors
Avorter;
fin si;
Sélection = Résultat.Select();
Sélection.Next();
Pour ColumnNumber = 0 Par Result.Columns.Quantity() - 1 Boucle
CurrentItemItem = Sélection[ColumnNumber] ;
Avorter;
Sinon
Rapport (CurrentItemItem);
fin si;
Fin du cycle ;

Si CurrentItemItem = Directories.Nomenclature.EmptyLink() Alors
Avorter;
fin si;
Fin du cycle ;

Dans cet exemple, tous les parents du lien enregistré dans la variable ElementNomenclature sont affichés dans la fenêtre de message de service. Dans le cycle, 5 parents lien sont sélectionnés.

Si le nombre de niveaux dans le répertoire est limité et petit, alors il est possible d'obtenir tous les parents avec une seule requête sans boucle.

Afficher un répertoire hiérarchique dans un rapport

Pour afficher un répertoire hiérarchique dans un rapport tout en préservant la hiérarchie, vous devez utiliser une requête semblable à la suivante :

CHOISIR
Nomenclature.Code,
Nomenclature Nom AS Nom,
Nomenclature.PurchasePrice
DEPUIS
Annuaire.Nomenclature AS Nomenclature
TRIER PAR
Prénom HIÉRARCHIE

Cette requête sélectionne tous les enregistrements du répertoire et les organise par hiérarchie. Le résultat sera classé par nom, en tenant compte de la hiérarchie.

Pour que les groupes de répertoires soient placés au-dessus des éléments, il est nécessaire de remplacer la clause ORDER BY dans cette requête par ce qui suit :

TRIER PAR
Nomenclature. Il s'agit de la HIÉRARCHIE du groupe,
Nom

Le résultat sera toujours ordonné hiérarchiquement, mais les groupes apparaîtront au-dessus des éléments.

Il est également possible de remplacer l’offre ORDER BY par l’option AUTO ORDER. Dans ce cas, le résultat sera ordonné en fonction des paramètres du répertoire, c'est-à-dire si le répertoire indique que les groupes doivent être situés au-dessus des éléments, alors ils seront situés au-dessus.

Il est également possible d'obtenir la structure hiérarchique du répertoire à partir des résultats.

CHOISIR
Nomenclature.Code,
Nomenclature Nom AS Nom,
Nomenclature.PurchasePrice

FROM Annuaire.Nomenclature AS Nomenclature

OÙ
(Nomenclature.ThisGroup = FAUX)

COMMANDER PAR Nom

Obtenir des totaux par hiérarchie

Pour obtenir des totaux par hiérarchie dans une requête, vous devez préciser le mot-clé HIERARCHY dans la clause SOFTWARE TOTAL après avoir précisé le champ par lequel les totaux seront calculés. Un exemple de rapport « Chiffre d'affaires des articles » avec obtention de totaux par hiérarchie :

CHOISIR

DEPUIS

HIÉRARCHIE de la nomenclature

Suite à cette demande, des totaux seront calculés non seulement pour chaque élément, mais également pour les groupes auxquels appartient tel ou tel élément.

Dans le cas où nous n'avons pas besoin de totaux pour les éléments, mais uniquement de totaux pour les groupes, nous devons utiliser la construction HIERARCHY UNIQUEMENT dans les totaux. Exemple:

CHOISIR
Comptabilisation de la nomenclatureTurnover.Nomenclature AS Nomenclature,
Comptabilisation de la NomenclatureChiffre d'affaires.Nomenclature.Présentation,
Comptabilisation de la NomenclatureTurnover.QuantityTurnover AS QuantityTurnover
DEPUIS
Registre d'accumulation.Nomenclature Comptabilité.Chiffre d'affaires COMMENT Nomenclature ComptabilitéChiffre d'affaires
MONTANT DES RÉSULTATS (QuantityTurnover) PO
Hiérarchie de nomenclature uniquement

Le résultat de cette requête sera un total d'enregistrements uniquement pour les groupes d'articles.