Cegid XRP Ultimate  |  I3   Actualisé le 06/10/2022
	Fondations
TCDOC - Actions réalisées par le traitement d'alimentation gtdoc et gtbin depuis satdo

Principe de fonctionnement

Ce traitement intervient classiquement en fin d'une chaîne de traitements qui permet d'alimenter la GED à partir d'un fichier d'une application externe (Readsoft®, Chorus Pro, etc.).    Pour mémoire, en voici un résumé :    1. Les fichiers émis par l'application externe sont placés sur le serveur de traitements, ou sur une machine accessible à partir de ce dernier ;    2. Un premier traitement, TFAAR, assure la lecture du fichier, ainsi que son chargement dans les tables sas des achats et dans la table sas de la GED (SATDO) ;    3. Un deuxième traitement, TTFCA, est ensuite invoqué, dont le rôle est double :           - Charger les tables d''exploitation des achats avec les indications présentes dans les tables sas des achats ;           - Mettre à jour la table sas de la GED (SATDO) afin d'y renseigner la colonne "nuesatdo", contenant le numéro interne des factures créées.    Attention : si la valeur testée 1 de l'occurrence INTDOC du paramètre AUTSAFAA vaut O, ce traitement assure automatiquement le référencement du document associé aux factures traitées dans GTDOC. Il ne gère dans ce cas que les types de documents centralisés. Si cette valeur vaut N, ce sera par appel à TCDOC que la mise à jour de la GED sera réalisée.    4. Le dernier traitement est celui-ci, TCDOC, afin :           - D'alimenter GTDOC avec le contenu de SATDO ;           - D'alimenter GTBIN avec le contenu des fichiers associés    TCDOC commence par extraire de la table SATDO les documents dont il pense pouvoir retrouver l'entité associée. Concrètement, sont retenus les enregistrements de cette table dont le "numéro entité" est renseigné (nuesatdo).    Le traitement effectue ensuite une boucle sur chacun des documents extraits. Pour chacun d'eux, TCDOC vérifie que l'entité à laquelle il est rattaché existe. Pour cela, il s'appuie sur des procédures de contrôle (à paramétrer). Si l'entité existe, le traitement construit l'identifiant du document à partir de l'établissement et du numéro d'entité indiqués dans SATDO.    Ceci fait, il insère et référence enfin le document dans GTDOC, et charge son image dans GTBIN.

Paramétrage des procédures de contrôle

Les procédures de contrôle sont utilisées afin de s'assurer que le document à insérer correspond à une entité existant dans le produit Cegid XRP Ultimate. L'entité sur laquelle on s'appuie alors est celle définie dans la colonne "entsatdo".    Déclaration de la procédure    Le principe est le suivant :    Soit X, l'entité à contrôler. Dans la transaction GPAR, créer l'occurrence PCX du paramètre TCDOC avec dans la chaîne 1 l'application à laquelle appartient la procédure (pour les achats, prendre sac) et dans le texte le nom de la procédure de contrôle. X désigne ici une suite libre de caractères.    Exemple : Supposons que l'entité à contrôler soit SAFAA. L'occurrence à créer est PCSAFAA du paramètre TCDOC avec chaîne 1 sac et texte pssafaaext    Paramétrage de la procédure    Déclarer la procédure à utiliser pour l'entité à contrôler ne suffit pas : il faut ensuite déclarer les liens entre les colonnes de SATDO d'une part, et les arguments attendus par la procédure de contrôle d'autre part.    Cela se fait également à l'aide des occurrences de GPAR, selon le principe suivant :    Soit X, l'entité à contrôler.    Créer l'occurrence PPXnn (nn désigne ici un numérique) du paramètre TCDOC avec dans la chaîne 1 le nom de l'argument de la procédure de contrôle et dans le texte le nom de la colonne de SATDO alimentant l'argument.    Exemple : Paramétrage du contrôle de SAFAA Les occurrences créées sont : PPSAFAA01 du paramètre TCDOC avec chaîne 1 numsafaa et texte nuesatdo et PPSAFAA02 du paramètre TCDOC avec chaîne 1 etssafaa et texte etssatdo    Pour l'entité SAFAA, ce paramétrage est livré en standard et il n'y a donc rien à faire.

Emplacement des fichiers image

Les fichiers image correspondant aux fichiers à charger dans GTBIN devront être placés sur le serveur de traitements ou sur une machine visible de ce dernier.    Le répertoire où les fichiers seront recherchés, est donné par le chemin (GPTH) associé à l'application GTI, le type QID et l'utilisateur PUBLIC.    Le nom du fichier est lu dans le champ FICSATDO. Il peut comporter des références à des sous-répertoires, mais celles-ci sont ignorées par défaut. N'est alors conservé que le nom du fichier seul.    Exemple : si le champ FICSATDO contient la valeur "factures/fac01052.pdf", TCDOC cherchera le fichier fac01052.pdf dans le répertoire des images.    Ce comportement est modifiable, et on peut demander à TCDOC de tenir compte pour sa recherche des sous-répertoires éventuellement présents. Pour cela, créer l'occurrence SDP pour le paramètre XLKPRM. Renseignez le texte de cette occurrence avec la valeur N.    Dans ce cas et pour reprendre l'exemple précédent, TCDOC cherchera le fichier factures/fac01052.pdf dans le répertoire des images.

Identifiant des documents

L'identifiant des documents est forcément dans ce cas etssatdo '^' nuesatdo. Il convient donc de veiller à ce que le type de document associé aux entités concernées respecte cette description.

Appel des WebServices pour l'association de documents

Possibilité de faire appel au WebService d'association des documents en ayant au préalable : - vérifier que le service GED_IN soit paramétré dans le référencement des services ; - associer au mnémonique TCDOC le paramètre PR1 avec la valeur WS.    Les types de documents basés et centralisés sont gérés. Pour chaque document à traiter, l'appel du service sera réalisé depuis le serveur de traitements.    Si ce service est appelé quand le type de fichier est basé, après association du document, le fichier d'origine peut être : - déplacé dans un nouveau répertoire (répertoire "processed" au même niveau que le fichier traité) ; - supprimé. Pour utiliser ce comportement, il faut associer au mnémonique le paramètre PR2 avec la valeur MOVE (déplacement) ou DELETE (suppression).