Dossiers

• Dossier (champ DOSSIER)

Le nom du dossier peut prendre 10 caractères alphanumérique maximum. La première lettre doit être alphanumérique.

• Nom (champ NOMDOS)

Saisissez la description de la fiche concernée.

Cet intitulé long est utilisé en titre dans les écrans et les états.

• Type de base (champ TYPDBA)

Définit la base utilisée pour créer le dossier. Cette base peut être SQL SERVER ou ORACLE. En fonction de la licence qui est utilisée, ce choix sera possible ou imposé.

• Volume (champ VOLUME)

Ce numéro de volume "SAFE X3" correspond au répertoire à partir duquel les fichiers physiques (hors base de données) décrivant les objets du dossiers sont implantés sur le serveur de traitement. Les volumes SAFE X3 sont définis dans le fichier "adxvolumes" sous le répertoire d'installation (contenu dans la variable d'environnement ADXDIR). Le volume par défaut est A, mais d'autres peuvent avoir été définis lors de l'installation du progiciel.

Il est possible de sélectionner le volume par la touche .

Cf. l'annexe technique sur les volumes en fin de la documentation de la gestion de dossier.

• Autonomie de la base (champ TYPCNM)

• Groupe fichier (champ GRPFIL)

Cette question posée dans le cas d'une base SQL server permet de définir si on crée ou pas des fichiers séparés pour stocker les index et les données (pour des bases conséquentes, c'est en général le cas).

• Taille données (champ SIZDAT)

Ces valeurs permettent de dimensionner les fichiers données et index de la base. La taille est exprimée en Méga-octets.

Ces valeurs n'ont d'intérêt que pour la création d'un dossier, et elles seront mises en général saisies en fin de définition des paramètres du dossier, juste avant la création effective d'un dossier. En effet, pour disposer d'une valeur estimative correcte, il importe d'avoir au préalable dimensionné les tables de la base par le biais de valeurs de dimensionnement (onglet Tables), et d'avoir défini plus précisément la structure des tables de la base par le biais de codes activité (onglets Options, Ecrans, Spécifiques).

• Taille index (champ SIZIDX)

• Format (champ CODDBA)

Définit le jeu de caractères utilisé pour stocker les champs caractères dans la base de données. Celui-ci peut prendre les valeurs ASCIIou UNICODE.

• Le format ASCII correspond à la gestion des langues européennes : chaque caractère est stocké sur un octet, les caractères accentués étant stockés sur des valeurs supérieures à 128.

• Le format UNICODE n'est utile que lorsqu'on veut gérer des langues dont le jeu de caractères nécessite plus de 256 combinaisons. C'est le cas du chinois, par exemple.
  Le client SAFE X3 est nativement UNICODE, il sait par conséquent gérer les textes de ce type. Il a le choix, au niveau de la base de données, d'utiliser l'un des deux formats : UCS2 ou UTF8.
  
  Le format UCS2 est un format d'origine Microsoft(TM), dans lequel tout caractère est stocké sur deux octets ; les caractères ASCII usuels ont le même code (mais l'un des deux octets sur lequel ils sont codés est nul). C'est le seul format de type UNICODE supporté par SQL server. Oracle admet pour sa part d'autres formats, et en particulier le format UTF8 qui est le plus fréquent. C'est un format dans lequel les caractères sont stockés sur un nombre variable d'octets (de 1 à 5 selon les cas, les caractères ASCII standard sont stockés sur un octet, les caractères accentués en utilisent deux ; au-delà, on retrouve les langues asiatiques). Il est à noter qu'Oracle supporte d'autres normes de codage (UCS3, UCS4, UTF16...) et que ces normes pourraient être utilisées (à condition de créer manuellement la base de données).

De façon interne et indépendante du format de la base (pour ses variables temporaires), le moteur SAFE X3 utilise le format UTF8 (les sources des traitements sont codés en UTF8), et le client Windows la norme UCS2.

• Dossier de référence (champ DOSREF)

Le dossier de "référence" doit être un dossier existant, dont les données du dictionnaire seront utilisés lors de l'initialisation du dossier. Un lien de filiation demeure entre un dossier et le dossier de référence. Ainsi, par défaut, si une ressource (traitement, table, état) n'est pas trouvée dans le dossier courant, elle est recherchée dans le dossier de référence, par un mécanisme d'héritage.

Cette valeur est reprise par défaut dans le dossier de copie, dossier à partir duquel, lors de la création du dossier, on peut également recopier certaines données (paramètres, plan comptable...) ainsi qu'indiqué dans l'onglet Init.

• Dossier de copie (champ DOSCOP)

Le dossier de copie, qui doit avoir été créé au préalable, est le dossier à partir duquel les données définies par l'onglet Init vont être copiées. Ce dossier peut être le dossier de référence, mais également un autre dossier de structure identique (par exemple, un dossier de paramétrage sur lequel les paramétrages ont été affinés lors de la phase d'analyse, sur lequel certaines données ont pu être introduites ou reprises par import). Il est important que la structure du dossier de copie soit équivalente (même si aucun contrôle ne peut être fait, des erreurs pourraient se produire lors de la copie si ce n'est pas le cas).

• Dossier historisé (champ DOSHIS)

Ce dossier ne peut pas être saisi directement en gestion de dossier. Il est renseigné lorsqu'un dossier d'historisation est créé après la création du dossier d'exploitation, par la fonction correspondante.

Le dossier d'historisation permet de stocker des données considérées comme non évolutives, que l'on souhaite pouvoir consulter à part.

• Date de début (champ STRDAT)

Cette date permet de définir la date de premier exercice d'un dossier nouvellement créé.

Cette date est fondamentale, car elle ne pourra plus être changée après coup. Elle correspond à la date de début du premier exercice à partir duquel on gère des données de l'entreprise avec le progiciel. Attention, il est souvent intéressant (pour des raisons de reprises d'à-nouveaux) de partir de l'exercice précédent celui où l'exploitation commence réellement.

Par défaut, les valeur des deux paramètres superviseur STRDAT et ENDDAT, qui définissent la période de connexion possible, seront définis par :

• STRDAT = Date saisie
• ENDDAT = max(STRDAT+ 12 mois, Date du jour)

Ces paramètres, modifiables par la suite, sont utilisés à la connexion dans le dossier. Il est contrôlé que la date saisie est comprise dans la fourchette de dates définie par ces 2 paramètres.

• Devise dossier (champ RPTCUR)

Permet de mettre à jour le paramètre SYSCUR du dossier. Ce paramètre ne peut plus être modifié par la gestion des dossiers après la génération du dossier.

• Dossier test (champ TSTFLG)

L'indicateur Dossier test signifie que ce dossier a vocation à recevoir une copie des traitements standard présents dans un patch, si celui est installé sur le dossier. Si cet indicateur n'est pas positionné, les traitements de patch ne sont intégrés qu'au niveau du dossier superviseur. Le fait d'avoir ce flag positionné permet de réaliser des tests d'intégration de patches sur un dossier. Une fois que les patches en question ont été définitivement intégrés dans l'environnement, il est conseillé de « faire le ménage » en supprimant les traitements installés précédemment (sinon, une prochaine installation de patches ou de version ne serait pas prise en compte sur ces traitements, ce qui risque de faire apparaître des dysfonctionnements). Un dossier en exploitation réelle ne doit pas avoir cet indicateur positionné.

• Dossier spécifique (champ SPEFLG)

Cette case à cocher signifie que les traitements spécifiques présents dans un patch seront installés sur le dossier même s'ils n'existaient pas auparavant. Les traitements spécifiques sont identifiés par leur nom : ils commencent soit par X, Y, ou Z, soit par SPE, soit ils commencent par CNS et se terminent par SPE. Si cet indicateur n'est pas positionné, seuls les traitements spécifiques précédemment existants sont remplacés dans le dossier par une nouvelle version présente dans un patch.

• Intitulé (champ LIBMOD)

• Actif (champ MODULE)

Ce tableau contient les modules retenus pour le dossier à générer. Seules les fonctions et les tables associées à des modules activés seront utilisables dans le dossier une fois qu'il aura été créé.

Il est recommandé de ne prendre que les modules réellement utiles. En effet, ceci permet de ne créer que les tables et objets réellement utilisés et diminue donc le temps de création et la place prise. Il sera toujours possible d'ajouter des modules après coup. La liste des modules et les contraintes éventuelles sont données en annexe en fin de la documentation décrivant la gestion de dossier.

• Taille images (champ BLBLNG)

Ce champ détermine la taille maximale prise par défaut dans les champs blob (binary large objects) stockés dans la base. Ces champs correspondent notamment aux images stockées dans la base de données.

Ce champ est défini comme une puissance de 2 : 1 équivaut à 2 Ko, 2 à 4 Ko, 3 à 8 Ko et ainsi de suite (la valeur correspondante est affichée, elle peut aller jusqu'à 20, qui correspond à 1 Go).

Il est à noter que chaque champ de type blob peut être dimensionné de façon différente dans la base (si le type de données porte la longueur de façon explicite, cette longueur par défaut n'est pas utilisée).

• champ BLBTXT

• Taille textes (champ CLBLNG)

Ce champ détermine la taille maximale prise par défaut dans les champs clob (character large objects) stockés dans la base. Ces champs correspondent notamment aux textes stockées dans la base de données.

Ce champ est défini comme une puissance de 2 : 1 équivaut à 2 Ko, 2 à 4 Ko, 3 à 8 Ko et ainsi de suite (la valeur correspondante est affichée, elle peut aller jusqu'à 20, qui correspond à 1 Go).

Il est à noter que chaque champ de type clob peut être dimensionné de façon différente dans la base (si le type de données porte la longueur de façon explicite, cette longueur par défaut n'est pas utilisée).

• champ CLBTXT

• Code (champ CODACT1)

Un code activité vous permet de :

• rendre optionnel un élément du dictionnaire si la valeur associée au code activité est nulle,
• signer les éléments spécifiques dès lors qu'ils sont marqués par un code commençant par X, Y ou Z,
• dimensionner un nombre de lignes maximum lorsque le code activité marque des éléments d'un tableau,

Si le code activité est désactivé :

• l'élément marqué n'est pas utilisable,
• le code associé n'est pas généré ou activé.

• Intitulé (champ LIBACT1)

Intitulé associé au code précédent

• Module (champ MODULE1)

Module d'appartenance auquel le code activité est rattaché. Si le module n'était pas actif, le code activité n'apparaîtrait pas dans ce tableau.

• Actif (champ FLACT1)

Si cette case à cocher est sélectionnée, les tables et écrans ou les champs de ces tables et écrans qui dépendent du code activité sont accessibles.

Si cette case à cocher n'est pas sélectionnée, les écrans et les tables, ou les champs qui en dépendent ne sont pas accessibles et n'apparaissent pas.

Attention: En exploitation, pour tout changement de positionnement de code activité, il est nécessaire de :

• Faire la modification du code activité dans la fiche dossier, à partir du dossier mère
• Valider le dossier fille.

• Code (champ CODACT2)

Un code activité vous permet de :

• rendre optionnel un élément du dictionnaire si la valeur associée au code activité est nulle,
• signer les éléments spécifiques dès lors qu'ils sont marqués par un code commençant par X, Y ou Z,
• dimensionner un nombre de lignes maximum lorsque le code activité marque des éléments d'un tableau,

Si le code activité est désactivé :

• l'élément marqué n'est pas utilisable,
• le code associé n'est pas généré ou activé.

• Intitulé (champ LIBACT2)

Intitulé associé au code précédent

• Module (champ MODULE2)

Module d'appartenance auquel le code activité est rattaché. Si le module n'était pas actif, le code activité n'apparaîtrait pas dans ce tableau.

• Actif (champ FLACT2)

Si cette case à cocher est sélectionnée, les tables et écrans ou les champs de ces tables et écrans qui dépendent du code activité sont accessibles.

Si cette case à cocher n'est pas sélectionnée, les écrans et les tables, ou les champs qui en dépendent ne sont pas accessibles et n'apparaissent pas.

Attention: En exploitation, pour tout changement de positionnement de code activité, il est nécessaire de :

• Faire la modification du code activité dans la fiche dossier, à partir du dossier mère
• Valider le dossier fille.

• Code (champ CODACT3)

Un code activité vous permet de :

• rendre optionnel un élément du dictionnaire si la valeur associée au code activité est nulle,
• signer les éléments spécifiques dès lors qu'ils sont marqués par un code commençant par X, Y ou Z,
• dimensionner un nombre de lignes maximum lorsque le code activité marque des éléments d'un tableau,

Si le code activité est désactivé :

• l'élément marqué n'est pas utilisable,
• le code associé n'est pas généré ou activé.

• Intitulé (champ LIBACT3)

Intitulé associé au code précédent

• Module (champ MODULE3)

Module d'appartenance auquel le code activité est rattaché. Si le module n'était pas actif, le code activité n'apparaîtrait pas dans ce tableau.

• Dim écran (champ DIME3)

Utilisez ce champ pour définir le nombre de sections utilisées dans les écrans et tables associées.

Une table peut être limitée par une taille minimum et maximum. Utilisez la formule suivante pour définir la dimension des tables :

min(max(MIN,SCREEN),MAX).

Ce champ est uniquement disponible pour les codes activité de type Dimensionnement .

• Mini BDD (champ DIMIN3)

Définit le nombre minimum de colonnes stockées dans la base de données (indépendamment du nombre vus dans l'écran, qui peut être inférieur). Ceci permet d'éviter à des états standard de faire référence à des colonnes susceptibles de ne pas exister selon le paramétrage.

• Maxi BDD (champ DIMAX3)

Définit la dimension maximale possible compte tenu des structures des tables dans la base de données.

• Code (champ DIMCOD)

Les éléments de dimensionnement sont utilisés dans le calcul des formules de dimensionnement pour estimer le nombre de lignes prévues dans chaque table et, partant de là, calculer la taille prévue des tables.

• Intitulé (champ ZDIMCOD)

• Module (champ MODULE5)

Sélectionnez un module pour le paramétrage.

Ce champ vous permet de renseigner si l'écran doit être créé dans la base de données du dossier. Il l'est si le module auquel l'écran est rattaché est actif pour le dossier.

• Valeur (champ NBR)

Ce nombre correspond à la valeur associé à l'élément de dimensionnement de la ligne.

• Module (champ MODTR)

Sélectionnez un module pour le paramétrage.

Ce champ vous permet de renseigner si l'écran doit être créé dans la base de données du dossier. Il l'est si le module auquel l'écran est rattaché est actif pour le dossier.

• O/N (champ TRVAL)

Une réponse positive à la question entraîne la validation des transactions associées au module.

• Langues (champ LAN)

Tableau permettant de saisir les langues avec lesquelles on pourra se connecter au dossier. La validation du dossier entraîne notamment la génération des écrans de saisie dans les toutes ces langues: cette opération est très consommatrice de ressources système.

• Réf. traduction (champ LANREF)

Cette case à cocher ne peut être cochée que si les deux conditions suivantes sont réunies :

• la langue est une langue non livrée en standard par l'éditeur
• cette langue n'est pas déjà cochée pour un autre dossier dans l'environnement courant (que l'on appelle également solution).

Elle permet de préciser que le dossier courant est le dossier de référence de traduction pour la  langue en question, c'est-à-dire qu'il est le dossier porteur des traductions les plus à jour pour la langue concernée.

Par défaut pour les langues livrées en standard, il s’agit bien sûr du dossier racine, ce qui explique que la case ne puisse pas être cochée dans un dossier normal; mais pour des langues « non standard » liberté est donnée à l'utilisateur de se définir un dossier référence de traduction.

Un contrôle vérifie l’unicité du dossier référence de traduction pour une langue, si on désire en changer, il faut d’abord décocher le dossier préalablement positionné.

Si pour une langue, il n’y a pas de dossier de référence de coché, est choisi dans l’ordre :

• le dossier racine (si la langue concernée y est définie)
• le premier dossier (dans l’ordre alphabétique) qui contient cette langue 

• Législation (champ LEGDOS)

• Options de copie (champ LIBCOP)

Chaque groupe correspond à un ensemble cohérent de tables du dossier de copie, tables dont le contenu peut être copié dans le dossier en cours de paramétrage lors de sa création.

Par clic droit sur le champ, on peut avoir accès à la liste des tables dont le contenu va être copié si on répond Oui.

• O/N (champ OPTINI)

En fonction de la réponse, les données sont copiées ou pas depuis le dossier de copie. Cette copie ne se fait que lors de la création du dossier, ou en cas de création des tables suite à l'activation d'un nouveau module.

• Langue par défaut (champ LANDEF)

Permet de mettre à jour le paramètre LANGAGE (langue principale) du dossier. Ce paramètre permet de définir une langue de connexion quand elle n'est pas précisée comme par exemple pour les traitements batch.

• Pays par défaut (champ CRYDEF)

Permet de mettre à jour, lors de la création du dossier, le paramètre CRYDEF. Ce paramètre correspond au pays proposé par défaut en saisie des adresses.

• Crible pour renommer (champ CHGCOD)

Ce champ permet de donner un crible qui définit une liste de codes de recodification. Si ce crible est renseigné, à la fin de la création, les paramètres recopiés depuis le dossier de référence seront renommés conformément aux règles de renommage définis par les codes considérés (pris dans l'ordre).

Ceci est particulièrement utile lorsqu'on souhaite par exemple créer un dossier mono-législation : certains codes de paramétrage, préfixés par un code législation, sont particulièrement lourds à utiliser dans ce cas, et la recodification peut simplifier l'utilisation des paramètres par la suite.

• Mise à jour écrans (champ CREMSK)

Ces champs sont toujours cochés dans un environnement normal de livraison. Ils servent à l'éditeur, dans un contexte de développement, de revalider un dossier pour tests en évitant la génération du code correspondant aux options présentées (écrans, objets, fenêtres, consultations).

• Fenêtres (champ CREWIN)

• Mise à jour objets (champ CREOBJ)

• Consultations (champ CRECNS)