pre traitement cre niv :

TCFIJCG = TPFAP.ISKI1.CFIJCG.S010SORT.CRERNIV vers TPFAP.ISKI1.CFIJCG.FICRNIV.VAC1

T8CFIJCG = envoi TPFAP.ISKI1.CFIJCG.FICRNIV.VAC1 vers T0P0.CFIJCG.FICRNIV.VAC1.TXT (idf = XGENCR01)

T8CCJFC1 = TPFAP.ISKI1.CFIJCG.FICRNIV.VAC1 vers TPFAP.ISKI1.CFIJCG.SAV.TRESOLC(+1)

traitement cre niv :

old traitement cre niv reunica :

TCRAJ20 = récupération consozec TPFAP.ISKI1.CFIJCG.FICRNIV.VAC1 TCRAJ21

TCRAJ22 ⇒ émission fichier trésorerie via mailbatch

TCRAJ23 ⇒ émission fichier compta via mailbatch

new traitement cre niv reunica UR:

T8FIJCC3 = dépose consozec TPFAP.ISKI1.CFIJCG.FICRNIV.VAC1

T8FIJCC8

T8FIJCC9 ⇒ dépose fichier compta PR\T0P0\GRECCO\Autres T0P0.DEMANDES_DE_VIREMENT_POUR_LA_TRESORERIE.csv

T8FIJCCA ⇒ dépose fichier compta PR\T0P0\GRECCO\Autres T0P0.CR_DU_TRAITEMENT_DES_CRE_DE_NIVELLEMENT.csv

explications

Depuis la MAD 16_09 le traitement des “cre de nivellement” a été dupliquer et rapatrié sur la plateforme Reunica UR Les fichiers généré par le traitement UR se trouve dans le répertoire PR/T0P0/GRECCO/Autres

Le traitement des “cre de nivellement” sur la plateforme Reunica a été conservé pour l'instant dans un but de contrôle. A terme le traitement de la plateforme Reunica UR il devra être décommissionner et il n'y aura plus de mail.

Dans le répertoire U:\Retraite\Reunica_Entreprise\PR\T0P0\GRECCO\Autres\20161019 le fichier 20161019_850011-T0P0.CR_DU_TRAITEMENT_DES_CRE_DE_NIVELLEMENT.csv est celui qui aurait du être transmis par la plateforme Reunica le 20/10

Pour moi la trésorerie récupéré le fichier des cre de nivellement dans le fichier joint dumailbatch(confirmer parkiryba)Puis Coda traite le creKyribagénérépar la trésorerie

les flux traiter par CODA peuvent être trouvé dans le répertoire CODA PR\DATA\TRESO\done\traites

Particularité mensuelle

Une fois par mois ( en début de mois ) la trésorerie doit le traiter le paiement de l'échéance des Allocataires (gros volumes)

La date d’échéance des prélèvements SEPA peut induire un decalage dans le traitement des echeance et un retard.

exemple le 02/11/2016

Pouvez-vous vérifier pourquoi sur les 2 périmètres AG2R et REUNICA les bandes sepa de la vacation du 27/10 soir ont été générées avec une date d’échéance au 31/10/2016 pour les lots les plus importants alors que jour était fermé ?
Il me semble que dans ce type de cas (jour férié, fermé ou week-end), l’échéance est ramenée au dernier jour ouvré du mois.
le problème provient de la date d’échéance des prélèvements SEPA (pour la vacation du 27/10 au soir) qui était le 31/10 alors que ce jour est fermé au lieu du 28/10.
Côté Grecco, ces ordres de paiements seront validés dans la vacation de ce soir. Ils seront pris en compte dans le fichier des demandes de virement demain matin.
Après analyse de la situation, le 31/10/2016 (fermé chez AG2R et REUNICA) n’est pas présent dans la table des jours « fériés » utilisée par les traitements SEPA pour le calcul de la date d’échéance des ORP (TC1TJOU).