Supports de sélection

Code support

Ce champ permet d'attribuer un code identifiant à un support de sélection. Cet identifiant ne doit pas excéder quinze caractères.

Cible

Ce champ permet d'associer le support de sélection à une cible et par conséquent de le rendre exploitable.

Le champ Type permet de renseigner l'un des quatre types de supports de sélection. C'est une des valeurs du menu local 2965.

Le champ Désignation permet de saisir une description pour le support de sélection.

Description

Ce champ facultatif permet de saisir un texte synthétique renseignant l'utilisateur soit sur la nature du support lui-même, soit sur les différents bénéfices attendus de l'exploitation de ce dernier.

Traitement

Ce champ concerne uniquement les supports de type Traitement. Tant que l'utilisateur n'a pas cliqué sur le champ Type et sélectionné Traitement, le champ Traitement demeure non qualifié. Ce champ indique le nom du traitement associé au support de sélection lorsque celui-ci existe. Tous les traitements associés aux supports de sélection ont un nom composé d'un préfixe "ZSSP" suivi d'un numéro de chrono. Ils sont donc considérés comme des traitements spécifiques.

Chaque type requiert une utilisation différente de l'outil.

Support de type « Tous les enregistrements »

Ce support est le plus simple des supports de sélection.

De plus, l'utilisateur n'est en principe jamais amené à se soucier de sa création puisque celle-ci est prise en charge automatiquement par le système lors de la création d'une nouvelle cible.

L'utilisateur peut toutefois modifier la Désignation et la Description de ces supports.

Aucun composant ni traitement n'est à définir sur ce type de support. Ainsi, toutes ces fonctionnalités sont inactives.

Lors du recours à ce support à l'occasion d'un ciblage, celui-ci a pour effet de générer une population contenant la totalité des enregistrements contenus dans la table cible.

Support de type « Liaison de premier niveau »

Ce support a pour objet de définir des jointures inter-tables avec la table cible sur la seule base de champs indexés. Le recours à des jointures limitées à des champs indexés garantit un haut niveau de performance lors de l'exécution d'un ciblage.

En revanche, cette limitation réduit le spectre des possibilités standards d'associations inter-tables. Ces possibilités sont effectivement directement dépendantes de la description des index définis dans le dictionnaire des tables X3.

Néanmoins, la fonction de gestion des supports de sélection a pour objet de permettre la définition d'un nombre toujours plus important de nouveaux supports de sélection. Ces supports peuvent être réalisés sur la base d'index aussi bien standards que spécifiques.

De cette façon, même si un index critique pour une activité commerciale donnée est absent du dictionnaire standard X3, il est conseillé de définir un nouvel index spécifique qui servira de fondation à la construction d'un nouveau support de premier niveau.

La principale limitation de ce type de support réside surtout dans sa capacité à n'associer que des tables en relation directe avec la cible. Par exemple, la table des retours de ventes (SRETURN) pourrait faire l'objet d'un nouvel index spécifique SRHA pour le champ BPCORD.
De cette façon, un nouveau support de premier niveau sur les retours de ventes pourrait être construit. On voit bien ici qu'un retour est directement associé à un client.

En revanche, la table des lignes de retours (SRETURND) ne comporte pas de rappel du champ BPCORD dans sa définition. Il y a donc seulement une connexion indirecte entre la table SRETURND et la table BPARTNER. Cette relation transite via la table SRETURN. Dans cette situation, la table SRETURND ne saurait être intégrée dans un support de premier niveau.

Ainsi, l'arbitrage entre les différents types de supports est une étape essentielle dans la définition d'un ciblage.

Une fois cet arbitrage effectué, il convient de s'intéresser à la construction d'un support de premier niveau :

Niveau

Dans le cadre d'un support de premier niveau, ce champ est qualifié automatiquement avec une valeur qui ne doit jamais être différente de 1. En effet, la cible est toujours au niveau 0. Ce support n'autorise que des relations directes avec la cible et donc de niveau 1. Il est par conséquent interdit de saisir une valeur supérieure ou inférieure à 1.

Table

Cette zone permet de saisir la table à mettre en relation avec la cible. L'utilisateur est aidé pour cela au travers d'une liste de sélection associée ou bien d'un tunnel vers l'objet de gestion des tables X3.

Clé

Cette zone permet d'indiquer le champ dans la table liée qui contient la valeur correspondant à la clé primaire de la cible. L'utilisateur peut sélectionner ce champ parmi la liste des zones composant la table liée.

Par exemple, dans le cas d'une association de la table des Rendez-vous (BAPPOINT) avec la cible des Tiers, le champ contenant le nom du Tiers visité est APTCMP. C'est donc ce champ qui doit être mentionné dans la colonne « Clé ».

Table parent

Dans le cadre d'un support de premier niveau, le niveau parent est toujours connu du système. Cette information est donc toujours renseignée par défaut avec le code de la table cible.

Clé parent

Dans le cadre d'un support de premier niveau, le niveau parent est toujours connu du système. Cette information est donc toujours renseignée par défaut avec le nom du champ représentant la clé primaire de la table cible.

Index

Lorsque l'on relie une table à une cible, cela signifie que l'on a préalablement veillé à disposer d'un index permettant de réaliser la jointure souhaitée.

Si cet index est à composante unique, le système prendra alors automatiquement en charge la qualification des zones "Index" et "Composantes de clé". En effet, il dispose dans ce cas de toutes les informations nécessaires.

En revanche, si l'index est à composantes multiples, l'utilisateur est invité à indiquer l'index à utiliser pour réaliser la jointure. Ce dernier est aidé pour cela par une liste de sélection contenant tous les index disponibles dans la table à relier.

Filtre ou Composantes de clé

Cette zone est exploitée de façon différente d'un point de vue syntaxique suivant que l'on définit un support de premier niveau ou bien un support de regroupement.

Dans le cadre d'un support de premier niveau, il faut s'attacher à définir les valeurs des différentes composantes de l'index indiqué précédemment.

Le nombre de valeurs saisies doit être égal au nombre de composantes de clé de l'index. Il n'est pas possible d'utiliser uniquement la première ou la seconde partie d'un index.

Règles syntaxiques de saisie des composantes de clé :

• Chaque composante de clé doit être séparée par un point virgule.
• Chaque valeur alphanumérique doit être délimitée par des guillemets.
• Bien que non obligatoire, mais afin d'éviter tout risque de conflit de nom de variables, il est vivement conseillé de faire précéder chaque nom de champ par son abréviation standard de classe. Pour les champs de tables, l'abréviation de classe est formulée comme suit :

[F : suivie du code abrégé en trois lettres de la table dans le dictionnaire X3 puis ].

Par exemple, pour la table BPADDRESS : [F :BPA]

Rappel des règles de paramétrage :

La définition d'un support de premier niveau est soumise à certaines règles rappelées ci-dessous :

• Une table liée dans ce type de support ne peut être définie avec un niveau différent de 1.
• Une même table liée ne peut être utilisée plusieurs fois dans un même support avec des caractéristiques de relation différentes.
• Il n'est pas possible de bâtir une relation avec la cible au travers d'un sous-ensemble partiel des composantes d'un index. Toutes les composantes d'un index doivent trouver une valeur correspondante dans leur expression de lien.

Support de type « Regroupement de tables »

Ce support a pour objectif de définir un réseau arborescent ou hiérarchique de relations inter-tables aboutissant toutes à une même cible. Ce type de support ne doit être utilisé que lorsqu'il s'avère difficile, voire impossible de recourir à un support de premier niveau.

A la différence d'un support de premier niveau, ce type de support permet de définir des relations entre tables sur la base de champs non indexés. De plus, les relations ne sont pas réalisées uniquement avec une cible mais avec potentiellement n'importe quelle autre table partageant une caractéristique commune.

De cette façon, il est possible en partant d'une table isolée dans le dictionnaire X3, de remonter table après table jusqu'à une cible.

Par conséquent, ce type de support étend de façon très significative le spectre des possibilités de ciblages réalisables.

Construction d'un support de regroupement : l'exemple de la "Chaise"

On souhaite réaliser un support permettant de retrouver tous les tiers ayant commandé une chaise.

La définition du ciblage est la suivante :

Dans ce cas, le support de sélection apporte l'essentiel de l'intelligence de recherche pour permettre de retrouver des tiers à partir d'une fiche article.

La sémantique délivrée par le support de sélection pour le critère Article est : "Articles commandés". Le support doit donc permettre d'aboutir à la table des tiers en transitant via les commandes de ventes.

Le chemin proposé est le suivant :

Depuis une fiche article, il faut remonter aux lignes de commandes. Depuis une ligne de commande, il faut remonter à la commande. Depuis une commande, il faut remonter au tiers.

Le tableau ci-dessous dresse le parcours à accomplir :

A partir de la table de plus bas niveau ITMMASTER, il faut que le système remonte à la table des lignes de commande SORDERQ. Pour cela, il convient d'indiquer quel champ de la table parent (SORDERQ) contient la valeur "Chaise" (Chaise étant le code de l'article. Champ ITMREF). Dans SORDERQ, il s'agit également du champ dénommé ITMREF.

Ensuite, à partir de la table des lignes de commandes, il convient d'indiquer au système quel champ de la table parent contient le code de la commande. Dans les deux tables, ce champ s'appelle SOHNUM.

Enfin, à partir de la table des commandes, il faut indiquer au système quel champ de la table cible contient le code du tiers. Dans la table Tiers, il s'agit de BPRNUM. Dans la table des commandes, il s'agit de BPCORD.

Au terme de ce parcours, le système a pu déterminer quels tiers avaient commandé une Chaise.

Ce type d'arborescence de navigation peut-être reproduit à l'infini avec toutes les tables de son choix dans la mesure où les connexions nécessaires entre les tables existent.

Pour cela, voici quelques explications complémentaires sur les règles de construction des supports de type regroupement.

Niveau

Ce champ permet d'indiquer le niveau d'une table au sein de l'arborescence des relations inter-tables :

• Le niveau 0 correspond à la cible.
• Le niveau 1 correspond à une table directement reliée à la cible.
• Le niveau 2 correspond à une table reliée à une table de niveau 1.
  Etc.

Table

Ce champ permet d'inclure une nouvelle table au sein de l'arborescence des relations. L'utilisateur est aidé pour cela au travers d'une liste de sélection associée ou bien d'un tunnel vers l'objet de gestion des tables X3.

Clé

Cette zone permet d'indiquer le champ dans la nouvelle table incluse qui contient la valeur correspondant au champ équivalent dans la table parent. L'utilisateur peut sélectionner ce champ parmi la liste des zones composant la table.

Table parent

L'utilisateur est invité à indiquer ici le nom de la table de niveau supérieur dans l'arborescence des relations. L'utilisateur est aidé pour cela par une liste de sélection contenant toutes les tables de niveau immédiatement supérieur.

Clé parent

Cette zone permet d'indiquer le champ dans la table parent qui contient la valeur correspondant au champ équivalent dans la table de niveau inférieur. L'utilisateur peut sélectionner ce champ parmi la liste des zones composant la table.

Index

Cette zone n'a pas d'objet dans le cadre d'un support de regroupement. Elle est par conséquent désactivée.

Filtre ou Composantes de clé

Les associations de champ à champ sont faciles à définir et conviennent pour des relations à composante unique.

Néanmoins, certaines relations nécessitent des informations complémentaires pour être correctement établies.

La table des adresses (BPADDRESS) est un bon exemple. Celle-ci contient un champ BPANUM contenant le code de l'entité pour laquelle l'adresse est définie. Une relation construite comme suit paraît plausible :

Le problème réside dans le fait que le champ BPANUM peut contenir aussi bien un code Tiers qu'un code Société ou encore un code Site. Une information complémentaire est donc requise pour discriminer plus précisément la relation entre BPADRESS et BPARTNER. Cette information est stockée dans le champ BPATYP. Si l'on veut s'assurer de ne travailler que sur le sous-ensemble des adresses relatif aux tiers, il convient d'ajouter un filtre complémentaire à la relation :

La saisie du filtre complémentaire est soumise au respect de certaines règles syntaxiques :

• Chaque expression logique doit être séparée par un opérateur sous la forme suivante :

• Chaque valeur alphanumérique doit être délimitée par des guillemets.
• Bien que non obligatoire, mais afin d'éviter tout risque de conflit de nom de variables, il est conseillé de faire précéder chaque nom de champ par son abréviation standard de classe. Pour les champs de tables, l'abréviation de classe est formulée comme suit :

[F : suivie du code abrégé en trois lettres de la table dans le dictionnaire X3 puis ].

Par exemple, pour la table BPADDRESS : [F :BPA]

Rappel des règles de paramétrage :

La définition d'un support de regroupement est soumise à certaines règles :

• La définition d'une arborescence de relations inter-tables s'effectue toujours du haut vers le bas. Cela signifie que le premier niveau saisi est 1, suivi d'un niveau 2, puis 3, etc.
• Une même table ne peut être utilisée plusieurs fois dans un même support.
  Ainsi, si un ciblage requiert la combinaison d'une recherche portant à la fois sur les articles commandés et les articles facturés, deux supports de sélection distincts devront être utilisés conjointement.

Support de type « Traitement »

Ce support a pour objet de faciliter la rédaction et l'exécution d'un code applicatif destiné à générer une population d'une cible donnée dans le cadre d'un ciblage.

Ce type de support ne doit être utilisé que lorsqu'il s'avère difficile, voire impossible de recourir ou à un support de premier niveau, ou à un support de regroupement de tables.

Pour définir un support de ce type, il suffit de préciser son type Traitement et de confirmer sa création.

Définir le type du support comme Traitement a pour effet de désactiver la grille de saisie des composants du support, mais d'activer en revanche le menu Fonctions - Définition du traitement.

Pour débuter la conception du traitement, l'utilisateur doit cliquer sur le menu Fonctions - Définition du traitement.

Une fois le traitement généré, celui-ci peut-être indifféremment ouvert et modifié soit depuis le support de sélection, soit via le menu Développement - Dictionnaire traitements - Traitements.

Le support de sélection prend en charge la rédaction d'un squelette de traitement dont les différents objectifs sont :

• Permettre au traitement d'être appelé par la fonction de ciblage via une étiquette et une structure de paramètres normalisées.
• Accomplir les procédures récurrentes à tous traitements de ce type.
• Isoler dans des sous-routines les parties de codes plausiblement constantes, mais qui demeurent modifiables.
• Offrir la possibilité au programmeur dans les cas extrêmes de modifier la totalité des éléments composant le programme, afin de résoudre les cas les plus complexes et imprévus.

Le squelette du traitement est composé des différentes sections suivantes :

• BEGIN : Cette section a pour objet de déclarer les variables de travail et de nettoyer le fichier de stockage des populations résultant d'un ciblage.
  Cette section est incluse dans une sous-routine. Cela signifie qu'elle n'est généralement pas susceptible de subir des modifications.
• Section utilisateur destinée à ouvrir les tables : Cette section prend en charge l'ouverture de la table cible. Le programmeur est ensuite invité à y ouvrir les tables complémentaires nécessaires à l'exécution de son ciblage.
• Boucle utilisateur de recherche : Cette section est laissée à la diligence du programmeur sur laquelle il peut intervenir pour construire son intelligence de recherche.
• SETDATA : Cette section prend en charge la gestion transactionnelle de l'enregistrement des résultats de la recherche. Elle prend également en charge l'affectation des informations discriminantes nécessaires plus tard à la gestion du ciblage.
  Cette section est incluse dans une sous-routine. Cela signifie qu'elle n'est généralement pas susceptible de subir des modifications.
• Section destinée à préciser la clé primaire de la cible : Cette section permet au programmeur de modifier la clé primaire définie par le système pour la cible. Celle-ci est généralement correcte par défaut.
• WRITEDATA : Cette section procède à l'enregistrement physique d'un enregistrement de population dans la base de données. La gestion transactionnelle ainsi que la gestion d'erreurs sont assurées.
  Cette section est incluse dans une sous-routine. Cela signifie qu'elle n'est généralement pas susceptible de subir des modifications.
• TRANSACT : Cette gestion veille au respect du comportement optimisé de la gestion transactionnelle proposée par défaut dans le traitement.
  Cette section est incluse dans une sous-routine. Cela signifie qu'elle n'est généralement pas susceptible de subir des modifications.

La fin du traitement prend soin de désactiver les éventuels filtres posés sur la table cible.

Synthèse des qualités de chaque type de support

Afin de mieux comprendre les cas et le type de support de sélection adapté, le tableau ci-dessous dresse les qualités de chacun des différents types énumérés. Il ne reste ensuite plus qu'à arbitrer en fonction des contraintes d'un ciblage.