Admin : /* Onglet Standard */

2019-04-04T14:25:33Z

‎Onglet Standard

imported>Admin : 1 révision importée

2019-03-06T09:11:23Z

1 révision importée

imported>Gbarret : /* Onglet Standard */

2018-10-18T14:53:54Z

‎Onglet Standard

Nouvelle page

Documentation exportation vers eDoc

=Introduction=
Ce document a pour but de présenter le fonctionnement de l’option d’exportation vers eDoc de Mapping Suite, la manière d’utiliser cette option et les prérequis nécessaires.
Les fonctionnalités eDoc sont apparues dans M-PS en révision 35665 en v8.0.5. M-Designer et M-Connect ne sont pas impactés.
L’option d’exportation eDoc a pour but de convertir un fichier XPS en flux documentaire eDoc et d’envoyer celui-ci par SFTP au serveur eDoc.

Cette option se trouve sous la rubrique :
Workflow  ajout de composant, icone verte XPS to Web format  To eDoc

=Prérequis=
==Métadonnées nécessaires==
L’option d’exportation vers eDoc prend en entrée un fichier XPS d’une ou plusieurs pages, contenant des métadonnées. Ces métadonnées sont de deux types :
* Les métadonnées eDoc : métadonnée obligatoire pour le fonctionnement de eDoc
* Les métadonnées Chorus : numéro de facture, numéro de client, etc…
===Les métadonnées eDoc ===
Ces métadonnées sont obligatoires pour eDoc, quel que doit l’usage (Chorus, RH…) et leurs noms doivent être respectés.
La casse n’est pas importante, mais celle indiquée sert de référence.

{| class="wikitable"
! Nom de la métadonnée
! Description
|-
| DoId
| Donneur d’ordre, mettre ici le code client unique, par exemple MP001 (CustomerID).
|-
| EtId
| Etablissement, mettre ici le code unique qui identifie l’établissement. En absence d’établissements remettre le code du DoId.
|-
| IdDestinataire
| Identifiant unique du destinataire pour cet ET. Apparaitra dans la colonne « Destinataire » de l’interface eDoc.
|-
| Type_IUN
| Type du destinataire (de 1 à 7), indique si c’est un NIR ou un SIRET.
|-
| IUN
| Identifiant Unique National pour le destinataire. N° de NIR pour un salarié, n° SIRET pour une personne morale.
|-
| RIC
| RIC du coffre tier (s’il existe).
|-
| Type_Document
| Identifiant indiquant le type de document. Apparaitra dans la colonne « Type de Document » de l’interface eDoc.
|-
| Date_Document
| Date du document (facture…).
|-
| Description
| Description du document (Titre du document). Apparaîtra dans la colonne « Description » de l’interface eDoc.
|-
| ED_Destinataire
| Identifiant du destinataire (ex : SIRET).
|-
| ED_DestinataireMode
| Mode de diffusion de ce document pour les destinataires. Absent si émetteur = destinataire.
|-
| ED_Emetteur
| Indique si l’archivage doit être fait côté émetteur. Egale à la valeur de DoId ou de EtId.
|-
| ED_EmetteurMode
| Dans le cas ou « ED_Emetteur » est présent ce champ doit contenir "Archivage" ou "Stockage".
|}

===Renseignements avancés sur les métadonnées eDoc===
Voici quelques consignes pour renseigner la valeur de ces données.
Il y a rejet du flux si une valeur obligatoire est absente.
{| class="wikitable"
! Nom
! Obligatoire
! Instructions
|-
| DoId
| Oui
| Identifiant de client eDoc. 
|-
| EtId
| Oui
| Identifiant d’établissement. 
|-
| IdDestinataire
| Oui
| Matricule du salarié ; cas de la famille de document DOSSIER_RH. 
SIRET (société) ; cas de la famille de document DOSSIER_FINANCIER.
|-
| Type_IUN
| Oui
| Valeur de 1 à 7 (incluses). 
Passage en erreur si différent.
|-
| IUN
| Oui
| Numéro NIR (pour un salarié comme destinataire). 
SIRET (Pour une société comme destinatrice).
|-
| RIC
| Non
| Identifiant d’un coffre tiers.
|-
| Type_Document
| Oui
| RàS
|-
| Date_Document
| Oui
| RàS
|-
| Description
| Non
| RàS
|-
| ED_Destinataire
| Non
| Identifiant unique. 
SIRET (pour une société).
|-
| ED_DestinataireMode
| Non
| Si la famille de document est DOSSIER_FINANCIER ou DOSSIER_RH_NUL, alors sa valeur contient « emailPj », « emailLien », « Stockage » ou bien « Archivage ». 
Passage en erreur si différent. 
Si la famille de document est DOSSIER_RH, il faut la supprimer. Elle est supprimée automatiquement dans ce cas. 
Si ED_Emetteur = ED_Destinataire, il faut la supprimer. Elle est supprimée automatiquement dans ce cas.
|-
| ED_Emetteur
| Non
| Contient soit la même valeur que DoId soit la valeur de EtId. 
Sinon elle doit être supprimée. Elle est supprimée automatiquement dans ce cas.
|-
| ED_EmetteurMode
| Non
| A supprimer s’il n’y a pas d’ED_Emetteur. Elle est supprimée automatiquement dans ce cas. 
Sinon, sa valeur vaut « Archivage » ou « Stockage ». 
Passage en erreur si différent.
|}

===Les métadonnées Chorus ===
Ces métadonnées sont nécessaires pour Chorus. Leurs noms sont à définir par l’utilisateur et eDoc doit être configuré pour transmettre ces métadonnées vers Chorus.
La casse (majuscule / minuscule) est importante.

Nom de la métadonnée Description
Chorus_SiretEmetteur Siret Emetteur
Chorus_SiretDestinataire Siret Destinataire (payeur)
Chorus_NoFacture N° facture
Chorus_DateFacture Date de facture
Chorus_MontantHt Montant HT
Chorus_MontantTtc Montant TTC
Chorus_MontantTva Montant TVA
Chorus_MontantNaP Net à payer
Chorus_NoEngagement N° d’engagement
Chorus_CodeService Code service (Selon les organismes d’état)

==Méthodes d’ajout de métadonnées==
Toutes ces métadonnées (eDoc et Chorus) peuvent être inclues dans le fichier XPS de plusieurs manières :
===Par M-Designer===
Les métadonnées peuvent être ajoutées par la maquette M-Designer, si leurs valeurs se trouvent dans le fichier de donnée déclenchant l’application de la maquette.
Dans ce cas, il sera possible d’ajouter une métadonnée possédant des valeurs différentes au fil des pages du document. Et avec un champ d’éclatement, il est possible obtenir plusieurs fichiers de factures (type fichierCible_[[VALEUR_D_ECLATEMENT]].pdf).
===Par workflow===
Les métadonnées peuvent être ajoutées par le workflow après la création du fichier XPS, les métadonnées devront dans ce cas être accessible par le workflow : par un fichier texte/xml ou par SQL.
Dans ce cas les métadonnées sont ajoutées sur l’ensemble du document avec une même valeur.

===Par MAP_XPS===
Les métadonnées peuvent être ajoutées au fichier XPS par map_xps.

Exemple d'ajout au fichier MonFichierXPS.xps de l'index DoID avec pour valeur "MAVALEURDOID" :
map_xps -infile:/home/maptopale/MonFichierXPS.xps -addCriteria:DoId=MAVALEURDOID

==Configuration du compteur==
Afin de numéroter les envois auprès d’eDoc, nous utilisons un compteur global. Aussi, nous avons mis en place dans mapping.conf, la variable configurable <code>EDOC_COUNTER_FULLPATH</code>. 
Sa valeur doit être le chemin vers un fichier comprenant son nom, en chemin absolu. Il faut que ce fichier soit accessible en lecture-écriture. Il n’est pas obligé d’exister.

Il faudra donc ajouter cette information dans le fichier mapping.conf, comme cela :
<block name="EDOC">
<group>
<element>
<info name="[EDOC_COUNTER_FULLPATH]">C:\Mapping\M-PS\Settings\eDocCounter.txt</info>
</element>
</group>
</block>

===Remarques===
Le compteur n’est qu’un simple indicateur d’unicité des envois pour eDoc, le désordre et les trous sont tolérés.
Il n’est pas incrémenté avant la création du ZIP final. Ainsi les échecs avant l’utilisation du compteur n’entrainent pas l’incrémentation :
* Une erreur à la lecture du flux d'entrée
* Une erreur à la génération des pdf
* Une erreur à la vérification des index eDoc
* Une erreur à la génération du XML eDoc
Par contre, si des erreurs se produisent après l'incrémentation, le compteur garde sa valeur modifiée :
* Une erreur à la création du fichier ZIP de sortie (dans le répertoire Temp mapping)
* Une erreur à la suppression des fichiers temporaires
* Une erreur à l'envoi par sFTP (ce n'est pas le connecteur qui le fait, il faut utiliser une boite sFTP pour cela)

=Utilisation=
L’option d’exportation vers eDoc se fait par l’intermédiaire de deux boites de workflow : conversion pour eDoc et envoi SFTP :

La boite de conversion vers eDoc prend en entrée un fichier XPS contenant toutes les métadonnées nécessaires. Cette opération produit en sortie un fichier ZIP contenant les fichiers nécessaires à eDoc (PDF et XML). Ce fichier est ensuite transféré par SFTP à l’aide de la boite de workflow de transfert sécurisé.
Il est possible et recommandé d’utiliser ces deux boites dans deux files d’attentes différentes en envoyant le résultat de la boite eDoc vers une file d’attente se chargeant de l’envoi SFTP.

==Paramétrage de la conversion vers eDoc==

===Onglet Standard===
L’onglet Standard contient les options concernant les fichiers à générer.

* <big>Nom du fichier d’entrée</big>
*;'''Obligatoire.'''
*;Nom du fichier XPS en entrée de la boite. Par défaut est un champ de type « param » initialisé avec le paramètre <code>MAP_FILE_IN</code>.

* <big>Nom du fichier de sortie</big>
*;'''Obligatoire.'''
*;Nom du fichier zip en sortie de la boite. Par défaut est un champ de type « param » initialisé avec le paramètre <code>MAP_FILE_OUT</code>.

* <big>Nom du fichier PDF</big>
*;'''Obligatoire.'''
*;Nom du fichier PDF à générer.
*;Il est possible de donner un nom dynamique au PDF pour générer plusieurs fichiers en éclatant le fichier XPS d’entrée.
*;Par exemple si le fichier XPS contient plusieurs factures, et une métadonnée <code>NUM_FACT</code> indiquant le numéro de facture, alors l’utilisation d’un nom de PDF dynamique du type <code>facture_[[NUM_FACT]].pdf</code> permettra de regrouper chaque facture dans un PDF diffèrent.

* <big>Nom du profil</big>
*;'''Optionnel.'''
*;Nom du profil de conversion utilisé pour la conversion PDF.

===Onglet Infos===
L’onglet Infos regroupe certaines informations utiles à la génération du fichier XML.

* <big>Titre du document</big>
*;'''Obligatoire.'''
*;Titre du document qui sera inclus dans la balise <code>GeneralInfo</code> du fichier xml d’index.
*;Possédant la valeur <code>MAP_TITLE</code> par défaut, qui correspond au titre du job en cours de traitement.

* <big>Commentaire</big>
*;'''Optionnel.'''
*;Commentaire du document qui sera inclus dans la balise <code>GeneralInfo</code> du fichier xml d’index.
*;Vide par défaut.

* <big>DocFamily</big>
*;'''Obligatoire.'''
*;Type du document qui sera inclus dans la balise GeneralInfo du fichier xml d’index.
*;Par défaut cette liste déroulante est sur <code>DOSSIER_FINANCIER</code>.
*;Peut valoir <code>DOSSIER_RH_NUL</code>, <code>DOSSIER_RH</code> ou <code>DOSSIER_FINANCIER</code>.

* <big>CustomerName</big>
*;'''Obligatoire.'''
*;Nom de la société générant les flux.
*;Par défaut à « MAPPING ».

* <big>CustomerID</big>
*;'''Obligatoire.'''
*;Code de la société générant les flux.
*;Par défaut à « 519 »

===Onglet Options===
L’onglet options contient une option fixée par la norme eDoc mais qui pourrait bouger.

* <big>Page de code pour le fichier XML (pas pdf)</big>
*;'''Optionnel.'''
*;Permet de choisir une page de code pour le fichier XML générer.
*;Par défaut à « 88591 », c’est-à-dire codepage 8859-1 (alias Latin-1).

==Paramétrage de l’envoi SFTP==
La seule particularité est d’utiliser la variable MAP_EDOC_NAME comme nom de fichier sur le serveur. Celle-ci est utilisée pour nommer le fichier ZIP envoyé. Seul ce nom fourni par MAP_EDOC_NAME respecte la norme de nommage de eDoc.

==Exemple de workflow==

=Résultat=
==eDocFactory==
Un fichier envoyé est traité en 2 étapes :
* En début de traitement, on reçoit un Accusé de réception. C’est un fichier retour (.ar) reçu par sFTP qui indique la date de réception.
* En fin de traitement, on reçoit un Compte rendu. C’est un fichier retour (.ft) reçu par sFTP qui indique que le flux a été compris sans erreur.
Les documents apparaissent ensuite dans l’espace des destinataires (configuration de ce comportement via les « consentements »).

@@ Ligne 217 : / Ligne 217 : @@
 *;Nom du fichier PDF à générer.
 *;Il est possible de donner un nom dynamique au PDF pour générer plusieurs fichiers en éclatant le fichier XPS d’entrée.
-*;Par exemple si le fichier XPS contient plusieurs factures, et une métadonnée <code>NUM_FACT</code> indiquant le numéro de facture, alors l’utilisation d’un nom de PDF dynamique du type <code>facture_[[NUM_FACT]].pdf</code> permettra de regrouper chaque facture dans un PDF diffèrent.
+*;Par exemple si le fichier XPS contient plusieurs factures, et une métadonnée <code>NUM_FACT</code> indiquant le numéro de facture, alors l’utilisation d’un nom de PDF dynamique du type <code>facture_<nowiki>[[NUM_FACT]]</nowiki>.pdf</code> permettra de regrouper chaque facture dans un PDF diffèrent.
 * <big>Nom du profil</big>

← Version précédente	Version du 6 mars 2019 à 09:11
(Aucune différence)

Doc: eDoc extension - Historique des versions

Admin : /* Onglet Standard */

imported>Admin : 1 révision importée

imported>Gbarret : /* Onglet Standard */