Table of Contents
DDL1-5 CAS7-1: Restauration composants de la zone agents
Table of Contents
| Phase PCA | DDL1-5 Elaboration de la solution de secours |
|---|---|
| Phase FdR | Phase B |
| Quartier FdR | B6 Restauration composants de la zone agents |
| Objet étude | recensement des bases à restaurer |
Traducteur/Routage
Urbanisation du projet
- POSEIDON est un système applicatif centralisé permettant la réalisation d'échanges de données entre la DGFiP et ses usagers. POSEIDON alimente le routage en déposant via STF les fichiers en provenance des partenaires EDI dans un répertoire de livraison. Le flux retour est assuré par le module PEDI qui communique avec POSEIDON par appels de service Les éléments qui concourent à la communication entre POSEIDON et le routage sont hébergés directement sur la plateforme de routage.
- La plate forme de routage assure le lien entre Poseidon (vecteur de transmission avec les partenaires EDI) et les serveurs de traduction.
Routage
En sortie, le module PEDI fait les appels vers Poseidon pour un partenaire considéré avec le connecteur indiqué dans le fichier /produits/PEDI/onfig/connecteur.conf. Ce fichier est constitué de lignes de la forme partenaire=connecteur
Les fichiers réceptionnés sur le serveur de routage en provenance de POSEIDON (cela peut être du CFT IP ou du FTPS) sont transférés dans le répertoire /silo/routage/cftip/arrivee/poseidon.
Ces fichiers sont accompagnés d’une fiche descriptive (.psed).
La séquence de traitement des fichiers est vérifiée pour chaque partenaire à partir de l’information stockée dans le répertoire /silo/routage/cftip/arrivee/sequence. Chaque fichier est ensuite ventilé dans le répertoire du partenaire /silo/routage/cftip/arrivee/R[xxxxxxx].
Si la séquence de traitement n’est pas respectée pour un partenaire donné les fichiers de ce
dernier sont bloqués jusqu’à obtention de la bonne séquence.
Traitement du flux en provenance de POSEIDON
Soure: /produits/routage/scripts/EDIArrivee/traitementDuFluxPoseidon.sh
- vérifier que le répertoire du patenaire existe si non le creer
- récupération de la sequence attendue le fichier sequence est stocké dans le répertoire
/edi/arrivee/cftip/sequence( nom du fichier : Rxxxxxxx.seq, contenu du fichier : le numero de sequence attendu pour ce partenaire)
Transfret des fichiers de Compte Rendu
Soure: /produits/routage/scripts/EDIDepart/TransfertCompteRendu.sh
- Transfret des fichiers sur le serveur TradeXpress par ftp
- ou bien mise à disposition sur les répertoires de départ pour les transferts par CFT (test de la presence et des droits d'ecriture sur le repertoire de sortie + creation du repertoire du pedi si absent + routage vers le repertoire de depart)
Traduction
Le nom du dictionnaire du traducteur pour la correspondance EDI ⇒ NDOC/NREF est stocké dans la base de donnée du module applicatif.
Ce fichier, identifié par le paramètre NOM_DICO de la table CONFIGURATION, permet de traduire les données EDIFACT en données exploitables par le système d’information de la DGFiP, à savoir des codes NDOC/NREF.
Entités en relation et chemin critique
| chemin critique envoi | il faut s'assurer de récupérer le fichier connecteur.conf à jour des partenaires PEDI |
|---|---|
| chemin critique récue le séquencement ne soit pas bloquant, comment est géré celui-ci ? | |
| chemin critique traduction | il faut s'assurer que le dictionnaire utilisé (identifié par le paramètre NOM_DICO de la table CONFIGURATION) est en adéquation avec la version NDOC/NREF utilisée. |
EDI MAPB TVA
Urbanisation du projet
Cas d’utilisation: Traiter les dépôts Déclaration et/ou Paiement EDI TVA
| N° | Activité élémentaire | Entités en relation |
|---|---|---|
| 1.2. | Contrôle de la validité du ou des partenaire(s) EDI déclaré(s) | Pour vérifier la validité des partenaires EDI, “donneur d'ordre” et “émetteur”, déclarés dans le dépôt, le système demande au SA Gestion Filière EDI de restituer la validité des habilitations de ces partenaires EDI à la date du dépôt. |
| 1.3. | Contrôle de présence des données d’identification, et de validité formelle des données présentes dans T-IDENTIF | Le système demande à N-DOC de restituer le numéro de version (le plus élevé) du formulaire T-IDENTIF applicable à la date du dépôt. Puis le système demande à N-REF de restituer les attributs et synonymes de chaque référence fiscale contenue dans le formulaire T-IDENTIF valide à la date du dépôt. |
| 1.5. | Contrôle de la validité des données d’identification déclarée | Le système demande à PERS de restituer, pour le SIREN (ou IDSP) déclaré, l’ITIP, et les données associées de la personne (Raison sociale, Titre, ..) |
| Le système recherche dans R-OCFI une OCFI TVA | ||
| 1.6. | Contrôle de la validité du régime et de l’adhésion à Déclarer TVA EDI | Le système demande au bouchon R-OCFI de restituer les modalités valides pour cette OCFI |
| 1.7. | Contrôle de la validité des types de formulaires déposés, ainsi que des combinaisons de formulaires autorisés en fonction du régime du redevable au moment de la période déclarée | Pour chaque formulaire valide présent dans le dépôt, le système demande à N-DOC de restituer le numéro de version (le plusélevé) du formulaire applicable pour la période déclarée (paramètre date = date de fin de période déclarée). Pour chaque formulaire valide présent dans le dépôt, le système demande à N-REF de restituer les attributs et synonymes dechaque référence fiscale contenue dans les formulaires récupérés. |
| Le système recherche les modalités valides pour cette OCFI pour la période de bornage calculée dans activité élémentaire «Contrôle de la validité du régime et de l’adhésion à Déclarer TVA EDI»(Restitution des modalités de l’OCFI dont la période de validité comprend tout ou partie de la période de recherche) | ||
| 1.8. | Vérification de la concordance de la période déclarée avec la période attendue. Détermination de la date limite de dépôt réelle et de la date limite de substitution de la déclaration | Le système recherche dans R-OCFI les exploitations associées à cette OCFI |
| 1.9. | Contrôle de la validité du régime et de l’adhésion à Déclarer | Le système recherche les modalités valides pour cette OCFI pour la période de bornage de la TVAGROUPE |
| 1.11. | Vérification de la concordance de la période déclarée avec la période attendue. Détermination de la date limite de dépôt réelle et de la date limite de substitution de la déclaration liée à la TVA GROUPE | Le système demande à R-OCFI de restituer l’adresse fiscale valide à la date de fin de période déclarée |
| 1.13. | Recherche du SAGES du service compétent | Le système demande à TOPAD 2 de restituer le code SAGES du service compétent (IFU dans SIE) |
| 2.2. | Contrôle de validité du télépaiement | Le système demande à OPALE de restituer au format BIC/IBAN, la liste de références bancaires valides stockées dans le référentiel des comptes bancaires Ref_CB ainsi que les coordonnées du titulaire, la RUM (Référence Unique de Mandat), la validité au protocole SEPA_B2B. |
| 3.3. | Contrôle de la validité du compte bancaire déclaré | Le système demande à OPALE de vérifier la validité du compte bancaire, [DS-17 / REF-CB OS1_ContrôlerCB] |
| 4.1. | Contrôle des calculs dans les formulaires déclaratifs | Le système appelle CA-PRO pour effectuer les calculs |
| 7.5. | Générer le Compte Rendu de Traitement | Le système transmet le dépôt, avec les parties et sections qui le composent «En-tête, Evènement, Formulaires», à ACQUI PRO PIVOT via l’offre de service “Créer dépôt” |
| 8.4. | Envoi du message à SATELIT | Pour chaque message (télépaiement) contenu dans le flux, SATELIT reçoit une demande de service de ACQUI EDI |
| 9.1. | Envoi des traces générées au MAS OSATIS | Pour chaque trace existante et rattachée à un dépôt le système transmet le message au SA suivi Filière EDI OSATIS via l’offre de service «enregistrerTraces». [DS-30] |
Le composant Gestion Filière EDI (GFE) est commun à aux projets ACQUI EDI-TVA et ACQUI EDI-TDFC et permet de gérer des objets métiers, spécifiques à ces filières.
Il n’a pas été retenu de gérer ces objets spécifiques dans les référentiels COPERNIC.
Le service restituerAccreditationPedi (CONTRATGFEMASACCREDITATIONEDI1):
- Restitue l’accréditation des PEDI aux MAP Batch TVA ou TDFC
- Reçoit des MAP des demandes d ’accréditation (de plusieurs dépôts) pour un PEDI émetteur (et un PEDI donneur d ’ordre si présent) à une date donnée (la date de réception de l ’interchange)
- Recherche dans la table PEDI la présence de l ’identifiant du PEDI puis vérifie par rapport à la date d ’habilitation et la date de révocation la validité de son accréditation
- Retourne les booléens Connu et Valide
Cas d’utilisation: Traiter les dépôts Demande de remboursement de crédit de TVA
| N° | Activité élémentaire | Entités en relation |
|---|---|---|
| 1.5. | Contrôle de la validité des données d’identification déclarées | Le système demande à PERS de restituer, pour le SIREN (ou IDSP) déclaré, l’ITIP, et les données associées de la personne (Raison sociale, Titre, ..) [DS-3] |
| Le système recherche une OCFI TVA à partir des paramètres ITIP + numéro externalisable de l’OCFI[DS-4] | ||
| 3.1. | Contrôle des calculs dans les formulaires DRCTVA | Le système appelle CA-PRO pour effectuer les calculs |
| 4.1. | Décodage de l’adresse fiscale de l’OCFI | Le système demande à R-OCFI de restituer la dernière adresse fiscale valide à la date du traitement [DS-11] |
| 4.2. | Recherche du SAGES du service compétent | Le ystème demande à TOPAD 2 de restituer le code SAGES du service compétent (IFU dans SIE) [DS-15] |
| 5.3. | Envoi du flux au SA Gestion Filière EDI | Générer une trace «état du TLRA» pour OSATIS |
| 6.4. | Envoi d’un dépôt EDI TVA à ACQUI PRO PIVOT | Cette activité a pour objectif de transmettre à ACQUI PRO PIVOT les messages générés par l’activité «Constituer le message pour ACQUI PRO PIVOT». Ces messages contiennent des dépôts de type «Demande de remboursement intégrable». |
Entités en relation et chemin critique
| entités en relation | PERS, R-OCFI, TOPAD2, N-DOC, N-REF, OPALE (REF-CB), CA-PRO, Gestion Filières EDI, ACQUI PIVOT, OSATIS |
|---|---|
| chemin critique | il faut disposer du SA Gestion Filière EDI à jour afin de restituer la validité des habilitations de ces partenaires EDI à la date du dépôt. |
EFI MAPB Z2Z3
Cas d’utilisation: Mettre à disposition de PIVOT un dépôt ou une demande de remboursement
Transférer les dépôts non encore envoyés depuis le MAS Delta vers le MAS Pivot et qui n’ont pas été générés par le superviseur (le superviseur est un automate chargé de surveiller le bon fonctionnement d’Acqui EFI TVA. Pour cela, le superviseur dépose une déclaration plusieurs fois par jour. Le dépôt concerne toujours la même ocfi du même dossier).
Ce CU situé en Zone 3, se charge de transférer les dépôts (déclarations et demandes de remboursement) de Zone 2 à Zone 3 puis de les marquer comme envoyés ou en échec de transmission à Pivot.
| Activité élémentaire | Entités en relation |
|---|---|
| Extraire les dépôts à transmettre à Pivot | Parcourir la base Delta EFI avec l’appel à la DS1 pour extraire les dépôts qui n’ont pas été envoyés à Pivot |
| Transmettre ces données à Pivot | appel à PIVOT via DS2 |
| Marquer l’état des dépôts de la liste à TRANSMIS ou échec en fonction du retour de PIVOT | appel à PIVOT via la DS3 |
| Enregistrer une trace dans le MAS OSATIS (suivi filière) | Pour chaque dépôt de la liste , enregistrer une trace suivi filière dans le MAS OSATIS via la DS4 correspondant au résultat d’intégration dans PIVOT |
Cas d’utilisation: Mettre à disposition de OSATIS les traces stockées dans le MAS DELTA
Ce CU situé en Zone 3, se charge de transférer les traces de Zone 2 à Zone 3 dans le MAS OSATIS puis de les supprimer du MAS DELTA une fois envoyées.
| Activité élémentaire | Entités en relation |
|---|---|
| Extraire les dépôts à transmettre à OSATIS | Parcourir la base Delta EFI avec l’appel à la DS1 pour extraire les dépôts qui n’ont pas été envoyés à OSATIS. |
| Transmettre ces données à OSATIS | appel OSATIS via la DS2 |
| Supprimer les dépôts de la liste du MAS DELTA | appel OSATIS via la DS3 |
Entités en relation et chemin critique
| entités en relation | MAS PIVOT, Base Delta, MAS OSATIS |
|---|---|
| chemin critique | volumétrie des données qui devront être stockées en l'absence d'OSATIS |
Dictionnaire de la feuille de route
Gestion Filière EDI
| impacte | phase B6 Restauration composants de la zone agents |
|---|---|
| phase B7 Restauration composants de la zone usagers | |
| atelier | B6-1 dérouler les DEX C5_ sauvegarde_restauration à programmer |
| contributeurs | SI-2C (fraîcheur des données) |
| SI-1C : DAP2 (contrôle restauration) | |
| SI-2B : MEMO (réinjection du catalogue/restauration) |
Un atelier B6-1 dérouler les DEX C5_ sauvegarde_restauration doit être étudier la restauration du MAS GFE, N-REF, N-DOC, REF-CB et REF-DELEG.
Dans la feuille de route les phases B6 Restauration composants de la zone agents et B7 Restauration composants de la zone usagers changent de statut (retrait du statut sans objet en cas de démarrage bases vides)
Traducteurs/routage
| impacte | phase B6 Restauration composants de la zone agents |
|---|---|
| phase B7 Restauration composants de la zone usagers | |
| atelier | B6-1 dérouler les DEX C5_ sauvegarde_restauration à programmer |
| contributeurs | SI-2C (fraîcheur des données) |
| SI-1C : DAP2 (contrôle restauration) | |
| SI-2B : MEMO (réinjection du catalogue/restauration) |
L'atelier B6-1 dérouler les DEX C5_sauvegarde_restauration doit être inclure l'étude des éléments suivants :
- récupération d'un fichier
/produits/PEDI/config/connecteur.confà jour - création de l'arborescence de stockage (
/produits/routage/scripts/creation_arborescence.sh) à effectuer en cas d'installation initiale sans récupération de l'arborescence/silo - étude des conséquences d'un répertoire
/edi/arrivee/cftip/sequencevide. - Génération du dictionnaire des traducteurs en adéquation avec la version NDOC/NREF utilisée
Base DELTA
| impacte | Mention dans la feuille de route |
|---|---|
| atelier | sans objet |
La feuille de route doit faire mention de la nécessité de renforcer la surveillance du taux d'occupation de la base DELTA.