Nous présentons ici une amélioration dans la gestion des chemins commerciaux visant à interdire l'utilisation de certains couples de journaux "origine -> destination".

Dans GICA, on peut créer un nombre quasi illimité de journaux commerciaux. Un code journal est défini par 3 positions alpha-numérique (par exemple CA2 pour "Caisse 2"). Pour chaque journal créé, il faut lui attribuer un des types suivants:

Devis / Offre, Commande client, Note d'envoi (Bordereau de livraison) ou Facture /Note de crédit/Pro-Forma. Il faut également lui associer des paramètres comme "Lié au stock", "Lié à la compta", ... Par exemple, un journal de Pro-Forma sera de type F (présentation comme une facture) mais sans corrélation avec le stock et la compta.

GICA gère automatiquement la cohérence des chemins possibles entre ces différents journaux. Par exemple, il autorise le sens "Offre -> Commande -> Livraison -> Facturation" mais pas l'inverse. Autre exemple, il vérifie qu'on n'établit pas une facture liée au stock à partir d'un bordereau également lié au stock pour éviter un double décompte sur le disponible des articles. D'autres vérifications sont intégrées dans GICA mais cela ne peut pas empêcher de créer des chemins commerciaux non désirés.

Par exemple, je crée le journal WEB pour les commandes reçues par le E-commerce et je crée le journal BOW pour les livraisons de ces commandes. Par contre, j'ai 2 journaux COM et BOR pour les commandes et livraisons hors site Web. GICA ne m'interdira pas d'établir un BOR à partir d'une commande WEB ou inversément, d'établir un BOW à partir d'une COM.

Du fait de ces différents cas, beaucoup d'utilisateurs nous ont demandé de programmer des interdictions entre certaines origines et destinations pour les journaux commerciaux. L'amélioration présentée ici permet de régler ces interdictions via le module des ACCES.

Prenons l'exemple précédent et ajoutons 2 règles dans les ACCES:

Règle 1: Interdire le chemin WEB -> BOR.
Règle 2: Interdire le chemin COM -> BOW.

Comme pour toute règle du module des ACCES, il y a 4 éléments:

1) Le menu de départ.
2) La commande dans ce menu.
3) L'utilisateur concerné (* = tous).
4) Le mot de passe (vide=autorisé, *=interdit, mot=autorisé avec ce mot de passe).

Par exemple,  pour retirer la compta du menu GICA pour l'utilisateur "xy", on ajoutera la règle  [ GICA, COMPTA , xy , * ] dans ACCES.

Ce que nous avons fait, c'est détourner cette syntaxe pour la gestion des chemins entre journaux commerciaux.
L'élément 1 de la règle sera ORGXYZ où XYZ est le journal d'origine.
L'élément 2 sera DESXYZ où XYZ est le journal destination.
Voici donc les 2 règles à ajouter pour notre exemple:

[ ORGWEB, DESBOR, *, * ]
[ ORGCOM, DESBOW, *, * ]

Comme on le constate, il sera aussi possible de réserver un chemin à certains utilisateurs en interdisant ce chemin à tous et en l'autorisant pour les utilisateurs concernés (avec ou sans mot de passe). Ceci pourrait être utilisé pour l'établissement de certains documents comme une note de crédit ou un retour marchandise.

Pour éviter de devoir créer une multitude de règles dans certains cas, nous avons ajouté la possibilité de programmer une seule règle pour une série de journaux. Prenons l'exemple d'une utilisation multi-magasins de GICA où on a pris comme méthode d'utiliser le 3ème caractère des codes journaux pour indicer les 6 magasins. Imaginons que nous ayons des bordereaux de livraison codés NE1, NE2, ..., NE6, des journaux pour les "retour marchandises" codés RM1, ..., RM6, des journaux de facturation pour les NE[1-6] codés FA1, ..., FA6 et enfin des notes de crédit pour les RM[1-6] codés NC1, ... NC6.
Pour interdire de faire une NC à partir d'un NE ou de faire une FA à partir d'une RM, voici les 2 règles à ajouter dans ACCES:

[ ORGRM*, DESFA*, *, * ]
[ ORGNE*, DESNC*, *, * ]

L'utilisation du caractère '*' en troisième position du code journal, signifie que tous les codes journaux dont les 2 premiers caractères coincident font partie de la liste. Attention donc que si, par exemple, on avait un journal NEX et un journal NCY, alors il sera interdit d'établir un document NCY à partir d'un document NEX.  

A noter que ces "ACCES" ne priment pas sur les règles de cohérence internes à GICA. Par exemple, on ne pourra pas créer un ACCES qui permettrait d'établir une facture liée au stock à partir d'un bordereau également lié au stock.

Cette amélioration apportera plus de confort et de sécurité dans l'utilisation de GICA.