Sommaire

1. Introduction

Cette nouvelle version de la gestion de la relation des Tiers permet de rassembler dans une application tous les échanges relatifs à une entité. Elle remplace l’ancienne version de la GRT qui n’est plus maintenue.

Une entité peut-être un client, un fournisseur, un article, une affaire, un document commercial d’achat ou de vente, un document de production et bien plus encore dans la mesure où il est possible en paramétrage d’inclure les applications concernées en mode conteneur dans n’importe laquelle des applications de l’ERP (voir la procédure en annexe)  et ainsi définir des nouvelles entités autour desquelles vous allez pourvoir échanger.

En standard, l’échange autour des entités suivantes est possible : 

Open

2. Les applications de la nouvelle relation tiers.

Trois applications sont disponibles dans le module « Communication ». Leurs fonctionnements est identique. 

Open

La relation client V2 : Elle permet de visualiser et de créer des messages essentiellement pour l’entité « Client ». Elle est présente en conteneur de la fiche client dans l’onglet « Relation clients ». Les échanges sont contextualisés pour le client chargé dans l’application.

Tous les échanges relatifs au client y sont visibles y compris les échanges qui concernent un document commercial pou le client concerné.

La relation fournisseur V2 : Même principe que la relation clients côté fournisseurs. Le code entité est un code Fournisseur.

Elle est présente en conteneur de la fiche fournisseur.

La relation tiers V2 : Elle permet de visualiser et de créer des actions commerciales sans contexte particulier, pour l’ensemble des entités. C’est cette application qui est utilisées en mode conteneur dans toutes les entités autres que clients et fournisseurs. L’onglet concerné porte le nom « Relations tiers ».

Exemple en « Commandes et accusés réception » :

Il est possible d’y échanger entre utilisateurs de l’ERP, sans contextualiser les fils de discussion avec une entité dans cette application.

3. L’Entête des applications

3.1. Le mode « Liste » de chacune des applications

Il présente l’ensemble des messages de tous les utilisateurs dans le contexte de l’entité sélectionné, si le module est en mode conteneur. Il permet aussi de créer des messages dont vous êtes l’émetteur (utilisateur connecté).

La suppression ou la modification d’un message n’est autorisée que dans la mesure où vous êtes l’émetteur de l’action. 

S’il s’agit de l’application « Gestion de la Relation Tiers V2 », tous les messages sont visibles quelques soit l’entité.

S’il s’agit de l’application « Gestion de la Relation Clients V2 », tous les messages qui ont un code entité client sont visibles.

S’il s’agit de l’application « Gestion de la Relation Fournisseur V2 », tous les messages qui ont un code entité fournisseur sont visibles.

3.1.1. Les filtres

3.1.2. Exemple d’utilisation des filtres

L’utilisateur Silog souhaite consulter toutes ses réunions planifiées non encore lues, dont la date est postérieure au 20/10/2021.

Il doit donc paramétrer un filtre de la façon suivante :

1 : Il s’agit des messages ou actions reçus.

2 : Il s’agit des messages ou actions non lus.

3 : Il s’agit des action de type 3, c’est le code correspondant aux « Réunions ».

4 : La date doit être égale ou postérieure au 21/10/2021.

Voici la liste des valeurs numériques possibles pour la saisie des filtres dans le bandeau au dessus du mode « Liste » (3) pour les champs qui stockent une valeur numérique.

Le type d’action est une valeur comprise entre 0 et 6.

La priorité de l’action est une valeur comprise entre 0 et 2. 

Le statut de l’action est une valeur comprise entre 0 et 2.

3.2. Le mode « Page » : L’onglet « Général »

 Un double clic sur un des éléments du mode liste permet d’accéder au mode page. Il présente le détail du message ou de l’action sélectionné(e). 

Un listage arborescent permet de consulter le fil de toute la discussion dans lequel se trouve l’élément sélectionné. Il est possible ainsi de consulter les données échangées.

Dans ce fil de discussion, un code couleur permet d’identifier les lignes destinées à l’utilisateur connecté, dans l’exemple « Lucie » :

En vert si Lucie est en destinataire principal.

En bleu si Lucie est en copie du message.

En grisé si l’action est terminée.

En gras si Lucie n’a pas lu le message.

La consultation détaillée de chaque élément du fil de discussion est accessible sur sélection du nœud de l’arbre concerné.

Ainsi le positionnement sur le message 1-2-1 positionne l’enregistrement sur la fiche concerné.

3.2.1. Créer un message

La création d’un nouveau message se fait via le mode « Création » de l’application.

3.2.2. Répondre à un message

Trois méthodes :

1 : Via le bouton présent dans l’onglet « Général », ce bouton permet soit de répondre  uniquement à l’émetteur du message sélectionné, soit de répondre à tout le monde (émetteur du message et destinataire en copie à l’exception des destinataires en Cci…) :

2 : Via le mode création en alimentant la zone « Fille de » :

Une fois  le numéro du message sélectionné, le numéro de l’action fille est renuméroté.

3 : Via le menu contextuel du fil de discussion voir le paragraphe suivant.

3.2.3. Les actions possibles dans le fil de discussion.

3.2.3.1. Si je suis l’émetteur 

• Modifier : Je suis autorisé à modifier le message sélectionné. L’application se positionne en modification sur le message concerné.

• Supprimer l’action : Je suis autorisé à supprimer le message et ses fils.

• Répondre/Répondre à tous : L’application passe en création d’un nœud supplémentaire dans le fil de discussion en mettant comme destinataire l’émetteur du message d’origine si l’item « Répondre a été sélectionné » sinon tous les destinataire en copie à l’exception des Cci seront aussi associés au nouveau message. L’objet portera le radical « RE : ».

• Classer « Terminée » : Pour changer le statut du message à « Terminée ». Si l’action est effectuée sur un nœud, tous les fils seront considérés comme « Terminé », le message initiateur est le maitre.

• « Réouvrir l’action » : Pour Réouvrir une action terminée.

3.2.3.2. Si je suis le destinataire

• Répondre/répondre à tous : L’application passe en création d’un nœud supplémentaire dans le fil de discussion en mettant comme destinataire l’émetteur du message d’origine si l’item « Répondre a été sélectionné » sinon tous les destinataire en copie à l’exception des Cci seront aussi associés au nouveau message. L’objet portera le radical « RE : ».

• Marquer toutes les actions mères/filles lue(s) ou à l’inverse « Marquer toutes les actions mères/filles non lues. Pour changer le statut lu/non lu d’un message ou de plusieurs messages. Cela concerne uniquement les messages dont je suis le destinataire.

3.2.4. La liste des champs

• Action Numéro : Il s’agit du numéro du message.

• Case à cocher « Modèle » : Cette zone permet de créer un modèle de message qui servira de cannevas lors de la création d’un nouveau message. La création d’un message à partir d’un modèle s’effectue en important le modèle concerné dans la zone « Modèle ».

•  Fille de : Lorsqu’il s’agit d’une réponse à un message, ce champ permet de voir le code du message père.

•  Modèle : Cette zone est visible en création, elle permet de prérenseigner toutes les zones avec les données alimentées dans un modèle. Le bouton d’import permet de sélectionner le modèle concerné. Un modèle est un message de type « Modèle » (Case à cocher « Modèle »).

•  Code Entité : Lorsque la discussion concerne une entité, on dit que le fil de discussion est contextualisé. C’est le cas lorsque la création d’un message est effectuée dans le contexte d’une autre application. Par exemple lorsque la création s’effectue dans le cadre de l’application « Clients », alors le code entité est automatiquement renseigné avec le code client en cours et le code application « CLI ».

•  Contact : Lorsque le code entité concerne un client ou un fournisseur, cette zone permet de sélectionner le contact tiers concerné par cet échange.

Un listage d’import permet de sélectionner le contact concerné.

Ce champ accueille le Nom et le Prénom du contact.

• Affaire : Cette zone permet de renseigner le numero d’affaire concerné. Ce numéro d’affaire est automatiquement alimenté dans le cas où le message est créé dans le contexte d’un document qui possède un numéro d’affaire, dans une commande par exemple, un lancement ou directement dans l’application affaire.

• Section : Code section de l’affaire.

• Campagne : Cette zone permet de renseigner le code de la campagne si le message concerne une campagne. Il est alimenté automatiquement dans le contexte de l’application « Campagnes ».

• N°Piece : Dans le contexte d’un document de ventes ou d’achat, cette zone est automatiquement alimentée avec le numéro de la pièce concernée. Elle permet de contextualiser l’échange dans une application.

• Objet : Zone obligatoire, elle permet de saisir un objet pour le message concerné.

• Destinataires : Un bouton permet d’alimenter le corps de l’application avec les destinataires du message. En destinataire principal A, en copie Cc, Ou en Copie cachée Cci. La liste « Destinataire » montre les enregistrements du corps de l’application. En gras les destinataires n’ayant pas lu le message.

Le bouton permet de sélectionner les destinatires A …, Cc … ou Cci…:

Un filtre permet de filtrer les contacts :

o    Contacts de l’annuaire interne (Utilisateurs ERP),

o    Les contacts du tiers de l’entité associée au message,

Tous les contacts (Internes, contacts clients et contacts fournisseurs). 

• Messages : Saisir dans cette zone le détail du message.

• Pièces jointes : Cette zone permet d’insérer des pièces jointes au message en cours. Les pièces jointes sont automatiquement enregistrées dans le chemin paramétré dans les paramètres de la GRT (« Traitements/Paramètres par défaut »). 

Ce chemin doit être un chemin accessible en partage pour tous les utilisateurs. Les pièces insérées sont automatiquement copiées dans ce répertoire dans un sous répertoire dont le nom est le numéro du message origine du fil de discussion (niveau 1).  Ainsi toutes les pièces d’un fil de discussion sont enregistrées dans le même répertoire, dans la base de données, seuls les noms des fichiers sont sauvegardés.

Le bouton permet d’ouvrir la fenêtre de l’explorateur.  Effectuer un cliqué glissé du fichier concerné.

Lorsque le message concerne un évènement ou une réunion, un fichier d’extension « ics » est joint au message. Il peut être ouvert et enregistré dans un agenda Outlook, par exemple.

• Modèle de mail : Par défaut c’est le modèle de mail associé à l’utilisateur (Voir annexe 1). Si l’utilisateur en cours n’a pas de modèle de mail, alors c’est le modèle de mail par défaut qui est utilisé. Cette zone est modifiable.

Le modèle de mail à utiliser par défaut est renseigné dans « Traitements/Paramètres par défaut ».

La configuration des serveurs d’envoi de mail et des modèles de mail est décrite dans le chapitre « Envoyer des courriels ». 

• Type d’action : C’est le type de message, à sélectionner dans la liste parmi les éléments suivants :

• La date de relance est obligatoire si le statut est « Attente de réponse ».

• La fréquence est modifiable, par défaut alimentée à 7 jours si une réponse est attendue. Il s’agit du nombre de jours tolérés sans réponse avant d’envoyer une nouvelle relance.

Voir la gestion des relances.

• Priorité : C’est la priorité, à sélectionner :

 Dans le fil de discussion (ou Echange), un symbole coloré permet d’indiquer le caractère d’urgence.   

• Statut : C’est le statut, à sélectionner :

Si la valeur est « Attente de réponse », la date de la relance est obligatoire.

• Caractère : C’est la valeur du caractère associée à l’utilisateur (Voir annexe 1). Cette zone est modifiable.

• Support contact : C’est la valeur du support associée à l’utilisateur (Voir annexe 1). Cette zone est modifiable.

• Application : Nom de l’application associée au message. Lorsque l’application est contextualisée au sein d’une application mère, cette zone s’alimente automatiquement avec le code de l’application mère dans laquelle à été créé le message, elle n’est pas saisissable.

Si le message est créé sans contextualisation, depuis l’application de la relation tiers, alors elle permet de contextualiser le message si nécessaire.

Lorsque cette zone est alimentée manuellement, un listage apparaît pour sélectionner la pièce ou l’entité concernée.

Lorsque cette zone n’est pas alimentée cela signifie :

• Soit qu’il s’agit d’un échange entre utilisateur ERP sans contexte particulier.

• Soit qu’il s’agit d’un échange importé de l’ancienne GRT, pour lequel le traitement d’import n’a pas eu la possibilité d’identifier clairement le contexte de l’échange, c’est le cas par exemple d’un code entité qui existerait à la fois comme code client et comme code fournisseur. Dans ce cas, il est possible de saisir manuellement le code application concerné en modification si l’utilisateur est l’émetteur de l’action pour recontextualiser le fil de discussion. Tous les pères et/ou fils hériteront de cette contextualisation.

4. L’onglet « Actions non terminées en retard »

Cet onglet permet de lister les messages en cours ou en attente de réponses pour l’utilisateur ERP connecté. Il peut s’agir :

• Soit des messages non terminés dont l’utilisateur ERP est l’émetteur et dont la date d’échéance est dépassée.

Si la date de relance n’est pas renseignée, c’est la date de création de l’action qui est prise en compte comme date.

Lorsqu’il s’agit d’une action qui ne concerne pas un évènement ou une réunion, l’heure de positionnement de l’action est 8h00.

•  Soit des messages non terminés dont l’utilisateur ERP est le destinataire A ou Cc.. ou Cci... et dont la date de relance est dépassée. Si la date de relance n’est pas renseignée, c’est la date de création de l’action qui est prise en compte comme date pour le retard.

Un code couleur par type de messages ou d’actions permet de les distinguer.

Le menu contextuel permet de clôturer en masse les messages ou actions.

Sélectionner les messages concernés puis sélectionner le mode de clôture désiré, soit les actions sélectionnées, soit les actions sélectionnées et toutes les filles concernées. Seuls les messages ou les actions dont l’émetteur est l’utilisateur connecté et tous ces fils seront traités.

Dans l’exemple, les messages ou actions terminées disparaissent du rapport.

Il est possible d’ouvrir une action ou un message pour modifier son contenu et ou répondre :

5. L’onglet « Les actions à traiter »

Le principe est similaire au rapport précèdent. Il montre les actions ou les messages à traiter. A partir de la date du jour.

6. L’onglet « Planning des actions »

C’est une vision transposée, à dates des actions dont l’utilisateur est l’émetteur ou le destinataire.

Le filtre de date permet de visualiser les retards si la date de début saisie est antérieure à la date du jour.

7. L’onglet « Variables libres  »

Cet onglet présente toutes les variable libres de l’application.

20 variables alphanumériques (texte long) et 20 variables numériques.

Les libellés sont des libellés génériques, Dans la parenthèse se trouve le nom de la variable correspondant à l’ancienne GRT pour vous permettre de réattribuer un libellé plus parlant en modifiant le libellé utilisateur  via le dictionnaire multilingues.

Pour cela, sur le libellé concerné faire un [clic Gauche + CTRL], dans la barre des tâche apparaît l’icône , cliquer dessus.

L’identifiant du libellé apparaît. sélectionner les jumelles.

Double cliquer sur la ligne qui apparaît et modifier le libellé.

Exemple :

Valider via le bouton OK.

Faire  “Enregistrer” puis fermer la fenêtre. Relancer L’ERP pour voir le résultat.

8. Le corps de l'application

C’est dans le corps de l’application que les destinataires des actions ou des messages sont sauvegardés. Le corps est alimenté à chaque fois qu’un destinataire est ajouté dans l’entête. Il est possible d’ajouter des destinataires dans le corps de l’application en mode création, c’est de cette façon qu’il faut procéder si vous souhaitez piloter l’application en macro-commande.

La liste des champs :

• Utilisateur GP : Identifiant utilisateur ERP destinataire du message, lorsque le destinataire concerné est un utilisateur interne.

• Type du tiers : Quatre possibilités.

• Client : Lorsque le destinataire est un client.

• Fournisseur : Lorsque le destinataire est un fournisseur.

• Interne : Lorsque le destinataire est un utilisateur ERP.

• Externe : Lorsque le destinataire n’est ni un client ni un fournisseur ni un utilisateur de l’ERP. 

• Type de destinataire :

• Destinataire : Prénom + Nom du destinataire importé du contact sélectionné ou saisi lorsque le type de tiers est « Externe ».

• Nom du tiers : Nom de la société s’il s’agit d’un client ou d’un fournisseur.

• Adresse mail : Adresse mail du contact, modifiable.

• Date de lecture : Non modifiable, date de lecture du mail, lorsque cette date est renseignée cela signifie que le message ou l’action a été lu par le destinataire. Le statut « lu » est automatiquement attribué lorsque le destinataire répond au message ou à l’action ou lorsque le destinataire passe le statut « Lu »  sur un message manuellement dans un fil de discussion.

• Lu : Coché si la date de lecture est renseignée.

• Ancienne date de lecture modifiée par une relance : Lorsque le traitement de relance est exécuté et qu’il concerne une action ou un message dont le destinataire avait comme statut « lu ». Le destinataire concerné repasse à non lu. Et l’ancienne date de lecture alimente cette zone.

• Date de première notification : Alimentée si le message a été envoyé par mail.

• Notifié par mail : Coché si l’action ou le message a été envoyé par mail.

• Date de dernière relance : Date de la dernière relance effectuée par le traitement de relance.

• Commentaire.

9. Notifications

Lorsque l’utilisateur connecté reçoit un message de la GRT, le compteur des notifications de messges ERP système s’incrémente, pour alerter qu’un message mérite une attention. La GRT emprunte le canal des messages réservés au système ERP pour notifier l’utilisateur.

Un clic sur la bulle permet de lister les messages.

Pour ne plus voir le message dans la bulle des notifications faire : « Marquer comme LU ». il s’agit d’un marquage « LU » pour la bulle de notification, cela ferme l’alerte système, mais il ne s’agit pas du même statut ‘LU’ que celui de l’application de la gestion de la relation tiers. Le message conserve son statut « Non lu » dans la Gestion de la Relation tiers V2.

10. La gestion des relances

Le traitement « Relancer les destinataires » traite tous les messages de type « Action (1) » en attente de réponse qui ont une date de relance alimentée à l’attention d’utilisateurs internes s’ils sont destinataires principaux.

Il s'agit des actions non terminées pour lesquelles le nombre de réponses reçues est inférieur au nombre de réponses attendues.

Première relance :

Si la date de relance saisie dans l’entête est strictement inférieure à la date système et si l'action est en attente de réponse, alors une relance est envoyée par mail aux destinataires principaux (utilisateurs ERP) qui n’ont pas répondus et seulement à ceux qui souhaitent une notification par mail des relances. Le statut « Lu » repasse à « Non Lu » pour les destinataires concernés (avec basculement de l’ancienne date de lecture dans la zone « Ancienne date de lecture modifiée par une relance », la  date de lecture est blanchie si elle était renseignée et la date de dernière relance est alimentée, pour les destinataires concernés.

Pour les relances suivantes :

Si après la première relance, des destinataires n’ont toujours pas répondu, alors le traitement teste la date de dernière relance renseignée pour chaque destinataire n’ayant pas répondu à laquelle il ajoute la fréquence de la relance  saisie dans l’entête. Si la date système est strictement supérieure à cette date alors le traitement génère la relance et de la même façon qu’il l’a fait lors de la première relance, il effectue la mise à jour des informations relatives aux destinataires (Lu=> Non lu, Mise à jour des date de lectures et de la date de derrière relance). Et ainsi de suite pour chaque relance. Un mail de relance est également envoyé si le paramètre « Réception des actions à relancer par email » est activé pour l’utilisateur concerné

Le traitement des relances est aussi géré via une tâche EDI JOB, cette tâche se nomme « SIL_GRT_RELANCE ». Il est ainsi possible de créer un automate qui exécute ce traitement de relance une fois par jour via, par exemple, le planificateur de tâche Windows (voir la doc concernée  «I.6. Exécuter une tâche en paramétrage - ERP Silog », pour la procédure de mise en place,

11. Importer les actions de l’ancienne GRT et recontextualiser les actions de l’ancienne GRT

11.1. Le traitement d’import des données de l’ancienne GRT

La nouvelle GRTV2 n’est pas connectée aux données de l’ancienne GRT, il n’y a pas d’impératif à reprendre les données de l’ancienne GRT.

Ces données peuvent représenter un volume conséquent d’actions clôturées qu’il ne serait pas souhaitable de reprendre. Il peut cependant, être intéressant d’importer un ou plusieurs échanges de l’ancienne GRT, dans le cadre du suivi d’un en cours.

Le traitement « Importer les actions de l’ancienne GRT » permet de traiter soit l’import de toutes les données, soit un import sélectif des données de l’ancienne GRT. 

 La fenêtre suivante permet de paramétrer les données à importer :

11.1.1 : Filtre SQL

• Pour importer des données sélectives, saisir le filtre de la clause « Where » à passer à la requête. La fenêtre de droite est une aide contextuelle, des exemples de syntaxes de filtres SQL sont donnés à titre indicatif, ils sont à adapter.

• Pour importer toutes les données de l’ancienne GRT, laisser le filtre vide.

OUI : Les fils de discussion importés de l’ancienne GRT qui n’ont pas été modifiés dans la nouvelle GRTV2 seront supprimés, et les données correspondant au nouveau filtre seront importées.

NON : L’import sera cumulatif avec les données déjà importées de l’ancienne GRT.

Les enregistrements provenant de l’ancienne GRT ont la colonne « La clé de l’ancienne GRT » alimentée dans le mode « Liste ».

11.1.2 : Valider l’import via le bouton OK.

Le message suivant demande si le précédent import doit être supprimé.

11.2. La recontextualisation des actions de l’ancienne GRT

Dans l’ancienne GRT, un échange n’était pas lié à une application de l’ERP, cela signifie qu’un échange lié à un code atelier « 4025 » était aussi visible dans l’application « Clients » et « Fournisseurs » si ce code « 4025 » existait dans l’application « Clients » et « Fournisseurs ». 

Dans la nouvelle GRTV2, chaque échange est contextualisé : un code entité, un code application et un numéro de pièce si nécessaire.

Lors de l’import des actions de l’ancienne GRT, le traitement tente de recontextualiser les échanges. Il affecte un code application lorsque cela est possible de façon automatique. Et cela est possible si ce dernier ne détecte pas de doublons de code dans les différentes entités traitées lors de l’import.

Lorsque le traitement ne parvient pas à recontextualiser un échange, la recontextualisation est à faire manuellement via l’import d’un code application dans le message (action de l’ancienne GRT) en mode modification. Cela suffit pour recontextualiser tout le fil de discussion concerné.

12. Annexes

8.1. Annexe 1 : Les utilisateurs de la relation tiers

C’est dans l’application « Utilisateurs » de la nouvelle gestion des droits que sont gérés les paramètres des utilisateurs de ce module. Il s’agit des utilisateurs de l’ERP.

8.1.1. La création des utilisateurs de la gestion de la relation tiers

Elle peut être manuelle, la procédure de création est similaire à n’importe laquelle des applications SILOG.

Elle peut aussi s’effectuer en important les utilisateurs de l’ancienne version des droits utilisateurs. Le basculement des utilisateurs de l’ancien module de la gestion des droits utilisateurs n’est pas fait automatiquement lors de la mise en place de cette version car un travail préalable de l’administrateur peut s’avérer nécessaire.

Un traitement existe pour basculer les utilisateurs de l’ancienne gestion des droits. Il se nomme « Importer les utilisateurs des anciens droits ».

8.1.2. Les informations à renseigner pour chaque utilisateur

• Code Utilisateur : Code utilisateur dans l’ERP, c’est le code utilisateur utilisé pour se connecter à l’ERP.

• Nom : Nom de l’utilisateur.

• Prénom : Prénom de l’utilisateur.

• E-mail : Adresse mail de l’utilisateur. C’est l’adresse utilisée pour les notifications par mail.

• Modèle de mail : Sélectionner le modèle de mail pour l’utilisateur concerné. Si cette zone n’est pas alimentée, le modèle de mail associé à l’application GRT sera appliqué. La configuration des serveurs d’envoi de mail et des modèles de mail est décrite dans la documentation « IV. Envoyer des Courriels - C9 - ERP Silog  ».   

• Diffusion par mail : Côcher cette option pour déclencher l’envoi d’un mail de notification pour les messages destinés à cet utilisateur.

• Réception des actions à relancer par email : Côcher cette option pour que les relances à la destination de cette utilisateur soient notifiées par mail.

• Caractère document (par défaut) : Valeur par défaut du caractère du document utilisé par la relation tiers lors de la saisie d’un message pour cet utilisateur.

Support document (par défaut) : Valeur par défaut du support du document utilisé par la relation tiers lors de la saisie d’un message pour cet utilisateur.

8.2. Annexe 2 : Ajouter la relation tiers à une application non prévue dans le standard

Prenons l’exemple de l’application « Pays » :

8.2.1. Etape 01 : Créer deux fichiers évènements

Dans le répertoire de l’application ciblée :

PARAMETRAGES\EVENEMENTS\TOUTESBASES\NomApplication 

 1 : « APRESCREATE.evt » : Ce dernier alimentera les zones du contexte de l’application lors de la création d’un message relatif à une entité Pays.

 2 : « APRESLECTE.evt » : Ce dernier permettra de contextualiser les messages selon l’entité affiché dans l’application mère.

 Dans notre exemple :

8.2.2. Etape 02 : Alimenter ces deux fichiers

Voici le modèle de syntaxe à saisir dans chacun des deux fichiers « Evènements ».

 grt_init_var_global (Paramètre1, Paramètre2, Paramètre3, Paramètre4, Paramètre5)

 La fonction comporte 5 paramètres alphanumériques.

8.2.3. Etape 03 : Insérer le conteneur de la relation tiers dans l’application ciblée.

Ajouter un onglet dans l’application concernée, le nom du masque à ajouter est « GRT_APP ».

Avant de réaliser cela copier le masque « GRT_APP.dfm » présent dans le répertoire « …/Defaut/MskBase » de l’ERP dans le répertoire « …/Defaut/MskUtil ».

Procédure :

Dans le prolongement des onglet de l’application concernée, dans notre exemple « PAYS », éditer le masque des onglets via la combinaison de touches [alt gr + clic droit]. 

Une fois le masque ouvert dans l’éditeur d’objets, double-cliquer sur un des onglets (1), la fenêtre de définition des onglets s’ouvre (2) puis cliquer sur nouveau (3).

Saisir un libellé à l’onglet (1), puis saisir le nom du masque « GRT_APP » (2), puis valider (3). 

Enregistrer le masque (1) dans le répertoire de tous les utilisateurs de l’ERP (2) « MSKUTIL » (3). La procédure est terminée. 

La relation tiers est maintenant disponible dans l’application (2) « Pays », après avoir rechargé les masques dans l’application (1).