Les familles d’erreur et les codes erreurs sont accessibles dans l’explorateur “Studio”.
Familles d’erreur
Les familles d’erreur sont une info essentielle portée par l’entête d’erreur.
Les champs sont les suivants :
-
Famille : c’est la référence de la famille d’erreur
-
Description : Libellé de la famille. Ceci est informatif.
-
Origine : “[1] Dev”, “[2] Paramétrage standard” ou “[3] Client”. Permet de savoir d’où vient la famille d’erreur et de gérer les droits en conséquences. Seul le “[3] Client” est accessible pour un utilisateur “lambda”.
-
Outil Visu : Choix de l’outil (PSD ou TDY) permettant de visualiser le ou les détails de cette famille d’erreur. Il est possible d’utiliser les outils fournis en paramétrage standard (notamment le masque erreur de base ➡️ PSD/IS_ErDetB) ou de créer son propre outil pour afficher des infos spécifiques.
-
Champs Add. : permet de déclarer les infos supplémentaires à stocker sur un détail d’erreur. Cette déclaration est obligatoire pour ajouter une info lors de la création du détail d'erreur. C’est une liste chainée avec séparateur virgule.
-
Mails : liste chainée des adresses mail qui doivent recevoir un mail à chaque création d’entête d'erreur de cette famille. Augmente la visibilité de l’apparition d’une erreur.
Mail envoyé si le type de message sortant “0” est en HTML
Mail envoyé si le type de message sortant “0” n'est pas en HTML
Nous n’avons pas plus d’info à mettre sur le mail car ce sont les seules infos connues au moment de création de l’entête d’erreur.
-
Utilisateurs : permet de filtrer les erreurs que l’on voit dans les outils de visualisation. Par défaut un utilisateur voit toutes les erreurs. Si on le rattache à une ou plusieurs familles alors il ne voit que les erreurs liées à ces familles. Le rattachement peut se faire à l’utilisateur ou à la classe.
-
Active : Si une famille n’est pas active les erreurs liées ne seront pas visibles dans les outils de visualisation. Par contre les créations d’erreur sur cette famille seront pris en compte. Donc si on réactive cette famille on verra les erreurs créées pendant la phase de “non activation”.
Les familles commençant par “IS_” et de couleur roses sont du paramétrage standard livrés par Elcia-ERP. Ce sont notamment les familles utilisées par le scrutateur. Les seules informations modifiables par un utilisateur “lambda” sont les mails et les utilisateurs.
La suppression des familles erreurs est une suppression logique.
La suppression physique s’effectue avec le traitement ADM-AP :
Code erreur
Les codes erreur sont une info essentielle portée par un détail d’erreur.
Les champs sont les suivants :
-
Code : c’est la référence du code erreur
-
Description : c’est le message d’erreur que l’on verra dans les outils de visualisation. Le message peut être écrasé au moment de la création du détail d’erreur. Si les erreurs sont créés via la procédure “IS_ErBas” (voir chapitre suivant) il est possible de mettre des codes (&1, &2, etc…) pour mettre des valeurs dynamiques dans le message d’erreur.
-
Niveau : ”[1] Info”, ”[2]Alerte”, ”[3] Erreur” ou “[4]Critique”. Indication sur la gravité du problème.
-
Famille : Famille d’erreur à laquelle est rattachée le code erreur.
-
Origine : Non saisissable. Information héritée de la famille d’erreur. “[1] Dev”, “[2] Paramétrage standard” ou “[3] Client”. Permet de savoir d’où vient le code erreur et de gérer les droits en conséquences. Seul le “[3] Client” est accessible pour un utilisateur “lambda”.
-
Actif : Si un code erreur n’est pas actif les erreurs liées ne seront pas visibles dans les outils de visualisation. Par contre les créations d’erreur seront pris en compte. Donc si on réactive le code erreur on verra les erreurs créées pendant la “non activation”.
La suppression des codes erreurs est une suppression logique.
La suppression physique s’effectue avec le traitement ADM-AP :
