La plupart des écrans de saisie de mouvements du progiciels sont paramétrables par l'utilisateur, par le biais de transactions. Ces transactions permettent de définir, parmi un ensemble de champs standards, quels sont ceux qui doivent apparaître dans l'écran de l'utilisateur. Cette génération de transaction se fait par duplication, puis modification d'écrans modèles.

De même, certaines fonctions de paramétrage provoquent la génération de code à partir d'éléments de paramétrage (c'est le cas pour les statistiques, les variables associées aux paramètres, par exemple).

Cette génération de code se fait normalement au cours de chaque opération de paramétrage, mais il arrive, parce qu'un écran modèle a été modifié par exemple, que la régénération du code soit nécessaire pour toutes les transactions d'un type donné. Cette fonction permet de déclencher cette régénération.

Il est à noter que les transactions sont désormais définies dans un dictionnaire dédié.

Gestion de l'écran

Onglet Ecran préliminaire

Au lancement de la fonction, un premier écran, listant les modules, permet (en répondant Oui en regard) de définir globalement quelles sont les revalidations nécessaires.

Onglet Ecran de saisie des transactions

Une fois le premier écran validé, on voit apparaître le détail des éléments qui peuvent être revalidés dans un deuxième écran. Il est possible de définir alors plus finement quels éléments doivent être revalidés. Cette revalidation se fait dans toutes les langues du dossier. Selon le nombre de transactions à revalider et le nombre de langues, cette phase peut être longue ; il est donc recommandé de choisir de façon la plus restrictive possible les éléments à revalider.

Il y a deux types de transactions : les transactions superviseur, et les transactions liées aux différents applicatifs écrits en technologie adonix.

Transactions superviseur

Les transactions superviseur susceptibles d'être revalidées sont les suivantes :

Code

Définition du code ou des écrans concernés

 ACN

L'ensemble du code lié aux consultations définies en développement.

AMI

Le code lié aux transaction système paramétrées.

APCY

Les tables par société. Ceci ne concerne pas tous les progiciels adonix, mais uniquement ceux qui ont des déclinaisons de données paramétrables par société. La structure des tables est alors régénérée et les tables revalidées si nécessaire.

AWA

Le code lié à l'exécution des règles de Workflow.

 AWW

Les écrans et fenêtres des plans de travail du Workflow.

GLOBTYP

Le code généré pour définir les variables associées aux types de données (notamment les variables nommées GLONXXX, qui définissent la longueur du code alphanumérique de type XXX).

GTC

Les écrans de consultation à partir de leur paramétrage.

RQT

Le code et les écrans générés à partir du paramétrage du requêteur.

STAT

Le code généré lors du paramétrage des statistiques, afin de constituer les cumuls demandés.

On trouvera dans une documentation annexe le détail des transactions applicatives pouvant être revalidées.

Tâche batch

Cette fonction peut être lancée en batch. La tâche standard GENMSKTRT est prévue à cet effet.

Messages d'erreur

Il n'y a pas de message d'erreur autre que les messages d'erreur génériques.

Tables mises en oeuvre

SEEREFERTTO Reportez-vous à la documentation de Mise en oeuvre