Types de données

• Code type (champ CODTYP)

Le code du type de données est composé de 1 à 3 caractères alphanumériques. Les mots réservés d'adonix sont interdits.

• Intitulé (champ ZINTITTYP)

Destiné notamment à figurer sur les états et les écrans dans lesquels le code de la fiche peut être saisi ou sélectionné. Ce texte permet de donner une description en clair de la fiche concernée.

• Objet lié (champ OBJLIEN)

Permet d'indiquer, le cas échéant, l'objet associé au type de données. La table liée gérée par l'objet est affichée.

La présence d'un code objet déclenche automatiquement:

• Le contrôle d'existence
• Les fenêtres de sélection et sélection avancée 
• La possibilté d'un tunnel vers la gestion de l'objet
• La possibilité d'afficher les propriétés de l'enregistrement courant de l'objet

• Table liée (champ FICLIEN)

• Code activité (champ CODACT)

La validation du dossier Adonix ne mettra pas à jour les types de données dont le code activité commence par X Y ou Z.

• Module (champ MODULE)

Module d'appartenance du paramétrage.

• Type interne (champ TYPTYP)

Permet d'indiquer le type interne du type de données. Les types possibles sont :

• Alphanumérique : chaîne de caractères, d'une longueur maximale de 255 caractères, dont la longueur peut être donnée dans la rubrique correspondante. Si la longueur n'est pas donnée, elle devra être donnée dans la longueur du champ au moment de l'utilisation du type.
• Menu local : entier compris entre 1 et 255.
• Entier court : entiers compris entre -32768 et 32767.
• Entier long : entiers compris entre -2^31 et +2^31-1.
• Décimal : il s'agit d'un champ numérique d'au plus 32 chiffres significatifs, dont la longueur est donnée sous la forme N.M (N étant le nombre de chiffres avant la virgules, et N le nombre de chiffres après). Cette longueur peut être donnée directement au niveau du type ou dans le champ longueur défini au niveau du champ qui utilisera le type. Selon la base de données, ce type de champ peut être stocké sous forme flottante ou fixe dans la base de données. Le premier cas, correspond à oracle : dans ce cas, ce qui compte, quand on définit un format N.M, c'est en réalité la précision totale - N+M - de stockage. Le deuxième cas correspond à SQL server : le nombre de positions avant et après la virgule doit être clairement défini. Le champ format (qui peut être variable) définira alors plus précisément la répartition des chiffres entre la partie entière et la partie décimale.
• Date : il s'agit de dates comprises entre le 01 janvier 1600 et le 31 décembre 9999 (sachant qu'une date nulle, symbolisée [0/0/0] existe).
• Blob : il permet de stocker et gérer des images.
• Clob : permet de stocker dans la base de donnée, des textes de longueur variable au format « rtf » ou « txt » et de les gérer.
• Flottant et Double sont des types qu'il est recommandé de ne pas utiliser (formats liés à la machine).

• Longueur (champ LNGTYP)

Permet d'indiquer, le cas échéant, la longueur pour les chaînes de caractères ou les numériques. Si celle-ci est à 0 la longueur sera alors saisie pour chaque variable de ce type.

Pour les blob, comme pour les clob, il faut saisir la longueur qui sera une longueur maximale de stockage. La codification est la suivante :

• Format adonix (champ FORTYP)

Permet d'indiquer le format 'adonix' du type de données. Ce format doit être en cohérence avec le type interne. Le format doit être conforme à la syntaxe d'adonix. Seule, la partie située à droite des ":" doit figurer dans cette zone. Ex : 10X , 3A2B. Le détail des syntaxes existantes est donnée dans la documentation correspondante.

 Pour un format variable, faire précéder de "=". Ex : =[F:DEV]FM92

Un bon exemple de ce type de format variable peut être visualisé avec les types MD1 à MD4. Ces formats sont utilisés pour des montants exprimés dans une devise. On utilise, par exemple pour MD1, le format =GDEVFMT. Cette variable globale est alimentée dans l'action INIDEV déclarée dans ce même type de donnée.

• Options (champ OPTION)

Ces options sont matérialisées par des caractères qui peuvent se concaténer lorsque plusieurs options sont nécessaires. Il est possible de choisir ces options grâce à une fenêtre de sélection. On trouvera une description détaillée de toutes les options possibles.

• No menu local (champ NOLIB)

Numéro du menu local. Si celui-ci est à 0, il sera saisi pour chaque variable de ce type.

• Paramètre (champ PARTAB)

Permet d'optimiser l'affichage des gros tableaux. Ceci est réservé au type de donnée du standard, car il nécessite un traitement particulier, dans le superviseur.

• Paramétre : représente le code paramétre à saisir en gestion d'écran sur le type de donnée.
• Variable : représente la zone qui sera initialisée par la valeur du paramétre dans l'action avant_saisie de la variable de bas de tableau.

• Format tableau (champ OPTTAB)

• Variable (champ VARTAB)

Permet d'optimiser l'affichage des gros tableaux. Ceci est réservé au type de donnée du standard, car il nécessite un traitement particulier, dans le superviseur.

• Paramétre : représente le code paramétre à saisir en gestion d'écran sur le type de donnée.
• Variable : représente la zone qui sera initialisée par la valeur du paramétre dans l'action avant_saisie de la variable de bas de tableau.

• Valeur par défaut (champ VALDEF)

Ce champ permet de saisir une formule de calcul pour attribuer une valeur par défaut aux zones de ce type.

Un exemple peut être vu sur le type CRY, qui définit le code pays : la variable GPAYS, qui définit le pays local, est proposée en valeur par défaut pour tous les champs de ce type. Cette valeur par défaut est automatiquement proposée sur les zones des écrans utilisant ce type de donnée. Cependant, si une zone utilisant ce type de donnée a sa propre valeur par défaut dans l'écran, c'est cette dernière qui est prise en compte; dans ce cas, la valeur par défaut du type de donnée est ignorée.  

• Type action (champ ACTTYP)

Ce tableau permet de déclarer des actions cataloguées dans le dictionnaire des actions. L'objectif est que sur tous les champs ayant ce type de donnée, les actions définies ici s'exécuteront systématiquement.

Si un même type d'action est défini à la fois sur le type de donnée et sur la zone d'écran, les actions s'exécuteront consécutivement et dans l'ordre suivant : celle du type de donnée puis celle du champ. Il y a un cas particulier pour les actions « sélection », « bouton » et "icône", pour lesquelles, seule, l'action de la zone d'écran s'exécutera.

Ce tableau permet de définir les actions particulières associées à la zone. Les types d'actions possibles sont:

• Avant-zone : Action avant toute saisie ou affichage de la zone. On peut l'utiliser par exemple pour définir le format de la zone.
• Init_bouton : Permet de définir les intitulés de bouton du menu contextuel.
• Init : Permet d'initialiser une zone.
• Avant_saisie : Action effectuée avant chaque saisie. on peut l'utiliser par exemple pour positionner mkstat et ne pas la saisir.
• Contrôle : Permet de tester la validité de la zone.
• Après-zone : Effectuée après le contrôle si celui-ci est valide. Permet par exemple d'affecter ou d'afficher d'autres zones.
• Après-modif : idem mais n'est déclenchée que si la zone a été modifiée.
• Sélection : Déclenchée par la touche F12.
• Bouton 1 : Déclenché par la touche F9 (réservée pour les tunnels)
• Bouton 2 à 20 : La touche F4 permet d'avoir la liste des menus contextuels.
• Avant_ligne : Uniquement pour les tableaux déroulants, permet de faire quelque chose à chaque fois qu'on entre en modification d'une ligne.
• Après_ligne : Uniquement pour les tableaux déroulants, permet de faire quelque chose après chaque saisie de ligne.
• Clic : Uniquement pour les champs icônes. Permet le déclenchement d'une action au clic sur l'icône.

• Action (champ ACTION)

Indiquez les actions à effectuer de manière systématique sur ce type de données.
On ne renseignera pas à ce niveau, d'actions STD, SPE ou SPV qui sont liées à une fonction particulière.
On peut renseigner plusieurs actions pour un même type d'action, sauf pour les actions  « sélection », « bouton » ou "icône".

• Exécution (champ EXEACT)

Ce champ permet de définir le contexte d'exécution de l'action:

• Interactive : cas de la saisie en ligne.
• Import / Web service : cas d'alimentation de la fiche en mode web service ou import. L'exécution des actions sur les champs est réalisée lorsque tous les champs sont renseignés.
• Toujours : dans tous les cas.

• Toutes langues existantes (champ ALLLAN)

Si cette case est cochée, toutes les langues sont prises en compte pour l'opération.

Si la case n'est pas cochée, on prendra, selon les cas :

• la langue par défaut de l'utilisateur, si aucun code langue n'est saisi.
• la langue saisie par ailleurs sinon.

• Langue (champ LAN)

Permet de définir la langue de génération (quand la case permettant de générer dans toutes les langues n'est pas cochée).

• Tous types (champ ALLTYP)

Si cette case est cochée, tous les types de documentation sont pris en compte pour la génération. Il est à noter que, dans ce cas, on limite la génération aux documentations standard (seules les documentations de code inférieur à X sont prises en compte).

• Type (champ TYPEDOC)

Permet de définir le type de documentation à prendre en compte dans le traitement (quand on n'a pas coché la case pour les prendre tous en compte).

• Codes documentations (champ FUNDEB)

Permet de donner une borne sur les codes à prendre en compte pour la génération de documentation.

• champ FUNFIN

• Génération ADOCUMENT (champ GENDOC)

Ce radio-bouton permet créer/mettre à jour le squelette de la documentation (hiérarchie des paragraphes) à partir des éléments techniques trouvés dans le dictionnaire des données. On peut choisir de reprendre uniquement les documentations existantes ou créer de nouvelles documentations si besoin.

Les liens de documentation sont également pris en compte. Les paragraphes susceptibles d'être créés sont définis dans l'annexe technique correspondante.

• champ GENFIN

Ce radio-bouton permet de générer la documentation finale à partir du contenu des paragraphes de documentation. Cette documentation est créée dans différents sous-répertoires du répertoire défini par le paramètre utilisateur DIRDOC.

Il faut utiliser la génération "Selon code activité" pour obtenir la génération des documentations des fonctions ayant des codes activités >= "X"
La génération "Complète" ne traite que les codes activités standards.

• Uniquement les documentations validées (champ HLPVLD)

Permet de générer le document final uniquement pour les documentations validées.

• Aides sur champs liées aux documentations (champ HLPLNKFLD)

Si cette case est cochée, on traite spécifiquement les aides sur champs relatives aux documentations sur fonction ou objet traitées par ailleurs. Pour savoir quelles sont les aides sur champ à traiter, on explore les écrans associés aux paragraphes de documentation correspondants.

• Autres aides sur champs (champ HLPFLD)

Si cette case est cochée, on crée la documentation finale à partir du contenu des paragraphes de documentation. Cette documentation est créée dans le sous-répertoire FLD du répertoire défini par le paramètre utilisateur DIRDOC.

• Codes aides sur champs (champ HLPDEB)

Permet de donner une borne sur les codes à prendre en compte pour la génération de documentation.

• champ HLPFIN

• Répertoire de génération (champ REPERT)