Les conditions d'envoi du message
Comment répondre à un message ?
Exemple 1 : Le système de validation des demandes d'achat
Exemple 2 : Re jalonner les OF ouverts en cas de modification de gamme
Exemple 3 : Faire une mise à jour sur la base de données
Exemple 4; initialiser un champ à partir d’un autre
- Principe
Le système de messagerie interne permet
1. d'avertir des utilisateurs des actions à entreprendre ou simplement de les informer sur des éléments saisis ; exemple : envoi d’un message à un responsable de service lorsqu’il a une demande d’achat à valider. Ces messages sont de types
a. Les messages pour action : Ils obligent le destinataire à faire une mise à jour (par exemple valider une demande d'achat ou mettre à jour une demande de prix, etc.)
b. Les messages pour information : Une simple consultation est alors nécessaire (avertissement du blocage d'un client, de la réception d'une pièce manquante, etc.)
2. de faire des mises à jour complémentaires ; exemple : mettre un code particulier dans le type de nomenclature si la création a été faite automatiquement par interface
3. d’exécuter une tâche ; exemple : en cas de modification de gamme, rejalonner immédiatement tous les of ouverts
L'envoi ainsi que le contenu des messages est entièrement paramétrable.
Le principe est le suivant : une action (ajout, modification ou suppression d'un élément) permet de déclencher l'envoi d'un message à un ou plusieurs destinataires.
- Destinataires
Les destinataires de chacun des messages sont également paramétrables. Ils peuvent être de trois catégories :
1. Un utilisateur référencé : Une action permet d'avertir une personne fixe
2. Un service : Tous les utilisateurs d'un service sont prévenus
3. Un utilisateur non fixe : il est possible par exemple, lors du blocage d'un client de prévenir automatiquement le représentant lié.
@ : Dans tous les cas, le destinataire du message est un utilisateur référencé
- Traitement du message
La suppression du message est différente selon son type :
ü Si le message est 'Pour action', la suppression va être automatiquement faite lorsque l'action sera effectuée
ü Si le message est 'Pour information', la suppression devient manuelle.
.
Un message est toujours lié à un événement. L'écran de mise à jour des différents messages possibles vous permet, pour une transaction, de régler tous les messages.
 |
Sur cet écran, vous voyez que sur la transaction CLIENT, lorsque le champ INTERDIT-COMMANDE, va être MODIFIE pour prendre la valeur 'O', le REPRESENTANT associé au client est automatiquement averti (pour information) du blocage du client.
· La transaction déclic est le nom de l'écran qui est à l'origine du message
· L'événement déclic est associé à la barre d'outils ; Toute mise à jour peut être à l'origine d'un message. Vous trouverez donc dans la liste des valeurs possibles, les notions de création, de modification et celle de suppression.
· Le numéro de Ligne permet de définir plusieurs messages pour la même transaction
· Si indique la condition d'envoi du message.
La syntaxe de ce champ est une syntaxe Centura et non une Syntaxe Oracle
& Attention vous devez toujours faire précéder le nom d'un item par le signe ':'.
& Les items que vous décrivez ici doivent obligatoirement être sélectionnés dans le critère de sélection.
& En cas de modification, les items de l'ancienne version doivent être précédés du mot 'OLD' et ceux de la nouvelle version du mot 'NEW'. Ainsi pour envoyer un message si le code pays du client change, vous allez taper
:OLD.PAYS != :NEW.PAYS
dans l'exemple du client interdit de commande on envoie un message au moment où le client passe en interdiction de commande, les mises à jour suivantes qui ne concernent plus l'interdiction de commande ne génèrent plus de message (alors que le client est toujours interdit de commande).
= permet de tester l'égalité (exemple :NEW.PAYS = '001' pour tester que le nouveau pays est '001').
!= permet de tester la différence (exemple :NEW.PAYS != :OLD.PAYS pour tester que le pays a été modifié).
& Il faudra le plus souvent tester à la fois la valeur attendue - celle qui doit déclencher le message - et le fait qu'elle a véritablement changée pour éviter une génération intempestive des messages. En effet si on teste uniquement que le nouveau pays est '001' cela signifie que chaque mise à jour de client dont le pays est '001' générera un nouveau message...
& Toutes les rubriques de la base de données doivent être testées en tant que chaîne de caractères (donc entre guillemets - ' -) même si ce sont des dates ou des nombres.
& Les dates dans la base de données sont très précises. Si on ne les formatent pas elles sont de la forme : 2001-07-18-09.35.59.000000 donc difficiles à tester. On a alors intérêt à formater cette date pour la rendre exploitable. Cette opération doit être faite dans la rubrique 'Critères de sélection'. Sous Oracle la commande SQL est TO_CHAR(date_a_formater,'format'). Le format étant une combinaison de DD pour le jour, MM pour le mois et YY pour l'année courte, YYYY pour l'année longue, HH24 pour l'heure, MI pour les minutes et SS pour les secondes. Exemple : TO_CHAR(d_obsolescence,'YYYY/MM/DD') peut être comparé à '2099/12/31'.
Pour tester qu'une date est nulle par exemple, vous devrez mettre :
 |
Pour les nombres il faudra tester la valeur attendue également entre guillemets -'- exemple : :new.stock_mini = '1200.25'
 |
L'exemple ci-dessus permet de détecter toute nouvelle ligne de commande ajoutée à une commande existante.
Le contenu ainsi que le(s) destinataire(s) du message à envoyer sont décrits dans le cadre du bas de l'écran
· Ainsi le destinataire peut être un utilisateur précis, un service de la société[1] ou un utilisateur dépendant du contexte (c'est le cas sur l'exemple en cours).
ü Si le destinataire est un utilisateur, choisissez 'Utilisateur' dans le premier champ. La picking alors en fonction vous présente le contenu de la table associée. Le message qui va être envoyé ne le sera qu'à cette personne.
ü Si l'utilisateur est un service, deux cas peuvent se présenter :
1. Si le message est 'Pour information', il est envoyé à chaque employé du service qui va le consulter et le supprimer.
2. Si le message est 'Pour Action' ; il n'est alors envoyé qu'une seule fois (au service) mais sera alors consulté par tous les employés. Le premier qui va faire l'action demandée va automatiquement supprimer le message (Le traitement d'un message).
ü Il peut arriver que le destinataire ne soit pas une personne fixe mais dynamique. Dans ce cas vous allez déterminer le champ de la table.
Par exemple, lorsqu'un demandeur fait une demande d'achat, le destinataire du message est différent en fonction de la catégorie de produit commandé. Le destinataire sera alors le DECIDEUR1 de la demande. De même si ce décideur refuse la demande, le destinataire du message est le DEMANDEUR.
· Le type de message vous permet de classer vos messages par catégories. Cette information est envoyée au destinataire en plus du message lui-même et de la clé. Il n'existe à priori que deux types de messages : celui pour information et un autre pour action. Mais vous pouvez en ajouter[2] afin que l'action à faire soit plus précise. Tout nouveau type créé est obligatoirement 'Pour Action'.
Ainsi un destinataire peut recevoir par exemple :
|
Type de message |
Contenu du message |
Clé |
|
Pour information |
Client bloqué |
135643 |
|
Pour contrôle |
Un nouvel article vient d'être créé, veuillez compléter la fiche |
103.0615 |
|
Pour validation |
Demande d'achat à valider |
DA980023 |
F : La fonction d'envoi est maintenant prête ; Le message sera envoyé en temps réel lors de la validation de la transaction d'origine.
- Les utilisateurs dépendants du contexte
o Sur une fiche article
ü Le responsable de réception (achats) est repris sur toutes les commandes
ü Le responsable de vente (ventes) est également repris sur les commandes
o Sur un contrat
ü Le responsable
o Sur une demande d'achat
ü Le demandeur
ü Le décideur
o Sur une fiche client
ü Le représentant
- Message externe
Si vous cochez cette case, le message sera envoyé directement dans la messagerie (Outlook ou Lotus) du destinataire, un message vous demande de confirmer l’envoi du message est immédiat.
Dans ce champ, au format Sql, vous devez sélectionner tous les items qui vont vous servir pour
Ø Formater votre condition d'envoi ('Si')
Ø La liste des objets à transmettre au destinataire
Ø Le destinataire du message lorsqu'il est de type 'Champ de la table'
Exemple de message : sur toute réception venant d'un fournisseur précis, il faut demander un contrôle qualité supplémentaire
 |
Sélection du numéro de bon de réception du code du fournisseur et de son nom
Ø Le code du tiers est utilisé dans la rubrique 'Si'
Ø Le numéro du bon de réception ainsi que le nom court du fournisseur sont envoyés comme information dans le mail.
· Comment sélectionner le bon de réception ?
Le message 
que vous envoyez doit être lié au bon que
vous êtes en train d'enregistrer.
Le cadre Lancement automatique est utilisé par le destinataire du message.
Lorsque celui-ci consultera sa messagerie il pourra bien entendu lire le message envoyé et pourra avoir un accès direct à la 'transaction à lancer' (par double-clic sur le message). La transaction s'ouvrira automatiquement en pré-affichant directement toutes les informations (exemple : si la 'transaction à lancer' est ARTICLES ; elle s'ouvrira directement avec les données de l'article correspondant au message). Le premier objet transmis doit être alors la clé de la transaction exemple : le code de l'article si on ouvre la transaction ARTICLES, le numéro de commande si on ouvre la transaction CDECLIENT.
La liste des objets à transmettre est une liste d'items issus de la base de données dont les valeurs doivent être communiquées au destinataire du message. Dans l'exemple ci-dessus, le destinataire va avoir pour information le numéro du bon de réception en cause ainsi que le nom court du fournisseur. Cette liste peut être au plus égale à 20 items.
Comme pour le cadre des conditions d'envoi ('Si'), en cas de modification, vous devez préciser si l'item fait partie de la nouvelle trame ('NEW') ou bien de l'ancienne ('OLD').
Clés de la sélection doit contenir les champs permettant de déterminer l'unicité d'une entité .Elle n'est à renseigner que si les critères de sélection entraînent la sélection de plusieurs enregistrements et qu'on souhaite comparer les anciennes valeurs de champs par rapport aux nouvelles.
Dans l'exemple ARTICLES (cf 3.2.) un seul enregistrement est sélectionné donc Clés de la sélection n'est pas indispensable au contraire de l'exemple suivant : On souhaite détecter tous les changements de prix effectués sur les lignes de commande : Le problème est que la transaction CDECLIENT fonctionne à partir du numéro de la commande mais qu'elle permet de mettre à jour plusieurs lignes de commande en une seule fois. La sélection des lignes de commande ne pourra donc se faire que par ce numéro (dfpicNoCde). On commence donc par sélectionner toutes les lignes de la commande et on filtre ensuite les seules lignes qui ont un prix différent de celui avant mise à jour. Le test Si ne peut fonctionner que si Clés de la sélection est correctement renseigné. Si on ne met rien on risque de comparer le prix de la ligne 1 avec le prix de la ligne 2... Il faut donc aider TOLTECH et lui dire qu'il faut comparer les prix uniquement si le numéro de ligne est le même : ligne dans Clés de la sélection
Un élément de la barre d'outils (l'enveloppe) vous permet de savoir si vous avez ou non reçu un message auquel vous devez répondre.
Cette icône change d'aspect automatiquement si en cours de journée vous recevez un nouveau message (un cachet rouge est affiché en plus).
Le traitement batch BATCHMGR doit fonctionner en permanence. Il permet d'acheminer les messages envoyés vers leur(s) destinataire(s).
L'activation de cette icône affiche une fenêtre dans laquelle vous trouvez la liste de vos messages en attente.
Afficher le contenu du message en choisissant la ligne.
Un double clic sur un message permet de chaîner sur la transaction de mise à jour correspondante.
Le message est automatiquement supprimé lors de la validation de la demande d'achat (ou la suppression si elle a été refusée).
Une demande d'achat peut être validée par 5 utilisateurs différents et ceci de façon hiérarchique. En fonction de la famille d'achat, vous devez définir des responsables qui interviennent en fonction du montant de la demande (voir mise à jour d'une demande d'achat).
En création de demande d'achat, avertir le premier décideur (responsable de service ou bien celui de la famille d'achat) qu'il y a une demande à valider.
L'écran de validation peut se présenter de la façon suivante :
Le destinataire va alors recevoir un
message du type suivant :
La demande peut alors être soit acceptée, soit refusée. Dans le premier cas, un deuxième responsable peut automatiquement être averti d'une validation à faire ; dans le deuxième cas c'est l'émetteur qui va être averti.
Si la demande est acceptée, elle peut être validée par le responsable suivant
L'écran est alors presque le même que lors de la création. Seuls Le critère de sélection (qui tient maintenant compte de la réponse 1) et la condition d'envoi du message sont différents.
Ce système de validation peut donc être étendu à 5 décideurs qui vont intervenir en cascade.
Si la demande est refusée, il faut en avertir l'émetteur
 |
- En cas de modification de gamme, on regénère la gamme d'exécution de tous les OF non encore lancés
FOR c1 IN (select g.article, o.ordre from gammes g, ordres_fab o
where o.no_gamme=g.no_gamme AND o.societe=g.societe and o.etablissement=g.etablissement and o.societe=^strSociete and o.etablissement=^strEtablissement and g.no_gamme=:dfNoGamme and o.article=:dfArticle and o.article = g.article and o.etat in ('P','O')) {
ExecuterTransaction('OF','dfOF=c1.ordre;pbRegenereGamme', sLDummy);}
Derrière le mot « ExecuterTransaction », mettre, dans l’ordre
- Le nom de la transaction
- Les paramètres (il peut y en avoir plusieurs)
- L’action à faire (bouton PbMaj, …)
& Ne pas mêler de For …. Avec un Update
A chaque mise à jour du plan d’un article, mise à jour d’une date sur la fiche complémentaire article
Note : Vous pouvez inclure plusieurs instructions
Par exemple
Mise à jour de la date du jour dans des items des tables Art_Comp_1 et Art_Comp_2
For c1 IN (select article,no_plan from articles where article=:dfArticle) {
SqlImmediate("Update art_comp_1 set dfdate01=sysdate where article='c1.article' ");
SqlImmediate("Update art_comp_2 set dfdate02=sysdate where article='c1.article' ");
}
Note : Le SqlImmediate ne peut être utilisé que dans une boucle "For" ; ce qui est inclus entre les accolades doit être des fonctions Centura
Bloquer une commande si le mini de facturation du fournisseur n'est pas atteint
Update commandes_four c set c.blocage='MC' where c.commande = :dfpicNoCde and exists (select commande from facturations_fours ff, commandes_four cf where ff.tiers=cf.tiers_facturation and commande=:dfpicNoCde and mini_facturation > mt_htb)
Sur un ordre de fabrication le magasin d'entrée des pièces est égal au magasin de sortie des composants
Update ordres_fab set magasin_entree = magasin_sortie, emplacement_entree = emplacement_sortie where ordre = :dfOF
Dans cet exemple, la désignation du fournisseur est égale à la désignation interne si l’on ne tape qu’un seul caractère
Set hWndForm.LienArtFour.dfLibArtFour = VisStrChoose(SalStrLength(hWndForm.LienArtFour.dfLibArtFour) = 1, hWndForm.LienArtFour.dfLibArticle, hWndForm.LienArtFour.dfLibArtFour)
Exemple 5 ; Donner une trame à l'automate Toltech
FOR C1 IN (select ordre, article, q_avancee, phase from operations_of Where blabla…) {
SqlPLSQLCommand(hSqlOracle, 'CHARGE_INTERFACE("DECFABTPS", "C1.ORDRE;C1.ARTICLE;C1.Q_AVANCEE;C1.PHASE;",SalDateCurrent(), 0)' );
}
L'avantage de cette solution est de mettre à exécution immédiate, par le serveur, une instruction qui va passer par Toltech Batch.
On peut aussi simuler une transaction TOLTECH comme dans l’exemple suivant :
WHILE C1 IN (T$colValidation = 'O' AND NEW.T$colQteFabriquee != OLD.T$colQteFabriquee ) {
ExecuterTransaction("SAISIETEMPS", "dfOF=C1.colOF;dfOperation=C1.PHASE;dfBonneRealisee=C1.T$colQteFabriquee;pbValidation;pbCreation;", sLDummy);
}
Dans cet exemple, un utilisateur saisit une quantité dans la colonne T$colQteFabriquee et pour confirmer son action, saisit également O dans la colonne T$colValidation. Comme action, il lance en direct la transaction SAISIETEMPS en lui passant les paramètres en ligne. On génère ici une macro commande dynamique qui lance la transaction et charge les champs dans l’ordre d’apparition sur la ligne et finit par appuyer sur pbCreation. Vous pouvez ainsi automatiser des transactions complexes de TOLTECH en créant une transaction simple de haut niveau.
Pour contrôler vos scripts
Ajouter ceci à la fin de votre script (juste avant le ‘}’)
SalMessageBox(sLDummy,’BAD’,0)
Si le système détecte un message d’erreur, il sera lors affiché
Pour le désactiver, faire précéder cette chaîne de ‘//’.