Historisation des échéances
Cet utilitaire permet de resynchroniser la table d'historisation des échéances (HISTODUD) qui est mise à jour lorsque le code activité HDU est actif, et dès qu'une échéance est modifiée.
Cette resynchronisation peut être de deux types :
- premier cas : détection d'anomalies sur les enregistrements existants et correction de ces anomalies, mais sans création de nouveaux enregistrements. Dans ce cas, la resynchronisation/correction réalise deux types de contrôle :
- la recherche d'incohérences entre, d'une part les données de la table de référence (GACCDUDATE), et d'autre part les données de la table d'historisation des échéances (HISTODUD).
Si des incohérences sont détectées entre les deux tables, la table HISTODUD est remise à jour via la resynchronisation sur la base du contenu de la table GACCDUDATE. - la vérification de cohérence de certaines données propres à la table HISTODUD sur la base d'un certain nombre de règles.
- deuxième cas : effacement des enregistrements existants (s'ils existent) et la création de nouveaux enregistrements d'historisation :
- la reconstitution des enregistrements d'historisation a pour vocation de supprimer les enregistrements déjà constitués et de créer de nouveaux enregistrements, y compris dans le cas où le code activité HDU serait activé en cours d'exploitation.
Cette reconstitution de l'historisation ne s'appuie pas sur les flux des modules en amont de la comptabilité mais sur le lettrage(en savoir plus...).
Pré-requis
Reportez-vous à la documentation de Mise en oeuvre
Gestion de l'écran
Les deux cases à cocher Resynchronisation et Effacement permettent de retenir l’un ou l’autre des deux modes opératoires de mise à jour de la table HISTODUD.
La case Trace détaillée permet de disposer d'une liste des enregistrements impactés ou créés par la resynchronisation.
Combinaisons possibles et impacts
Resynchronisation | Effacement | Trace détaillée | Impacts | Exemples d'informations obtenues dans la trace | |
Non | Non | Non | Fichier trace listant les anomalies dans les enregistrements existants. Aucune correction ni création. | Pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 (151016) | Avec l'information du numéro d’échéance historisée ([F:HDU]NUMHDU) ainsi que la nature de l’anomalie (comme une DATEVT incorrecte). |
Oui | Non | Non | Correction des anomalies détectées sur les enregistrements existants. Fichier trace listant les anomalies corrigées. | Pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 (151020) |
|
Non | Oui | Non | Fichier trace listant les enregistrements que l’utilitaire est susceptible de créer s'il est lancé en réel (sans tenir compte de ceux déjà existants). | Pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 | Avec en dernier l'information de la DATEVT appliquée si l’utilitaire est lancé en mode réel. |
Non | Oui | Oui | Fichier trace listant les enregistrements existants qui seront effacés si l'utilitaire est lancé en mode réel. Fichier trace listant les enregistrements que l’utilitaire est susceptible de créer s'il est lancé en mode réel (sans tenir compte de ceux déjà existants). | *** 150983 10/02/11 Pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 | L’enregistrement à supprimer est identifié via son [F:HDU]NUMHDU et sa DATEVT. Avec en dernier l'information de la DATEVT qui va être appliquée si l’utilitaire est lancé en mode réel. |
Oui | Oui | Non | Suppression des enregistrements existants et création des nouveaux enregistrements d’historisation des échéances. | Pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 |
|
Oui | Oui | Oui | Suppression des enregistrements existants et création des nouveaux enregistrements d’historisation des échéances. | Pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 |
|
Ecran de saisie
Présentation
Champs
Les champs suivants sont présents dans cet onglet :
En-tête
| Pas d'aide liée à ce champ. |
Critères
| Pas d'aide liée à ce champ. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bloc numéro 3
| La resynchronisation est réalisée uniquement sur les enregistrements dont l'Etat DUDSTA a pour valeur 'deux', ce qui correspond à une échéance liée à un document comptabilisé (par opposition par exemple aux échéances liées à des factures non comptabilisées). Un certain nombre de zones de la table HISTODUD ne sont pas mises à jour, à savoir :
Certains champs sont re-synchronisés par application d'une règle, à savoir :
|
| L’option ‘Effacement’ créée de nouveaux enregistrements d’historisation. Les données du fichier des échéances constituent le point de départ de cette création.
LIMITE n°1La resynchronisation avec effacement ne s’appuie pas sur les flux dans les modules en amont de la comptabilité mais sur l’événement comptable qu’est le lettrage. Exemple : LIMITE n°2La resynchronisation avec effacement ne permet pas de gérer le cas d’une annulation de règlement qui interviendrait a posteriori de cette resynchronisation. Exemple : En relançant une resynchronisation avec effacement sur le tiers concerné, les nouvelles données de l'historique sont reconstituées sans cette limite. |
| Si la trace détaillée est demandée, le fichier trace est complété par la liste des enregistrements HISTODUD susceptibles d'être supprimés lors de la phase d'effacement (avec ou sans resynchronisation). |
Principes techniques de mise à jour de la table d'historisation des échéances
La table d'historisation des échéances HISTODUD est exploitée par les fonctions de consultation de balance âgée à date (CONSBAH et CONSBAHF) et par l’édition de la balance âgée historisée BALAGEHIST.
Cette table est mise à jour dès qu’une échéance est créée puis à chaque mise à jour d'une échéance.
Toutes les zones caractérisant une échéance ne sont pas historisées. Ainsi, le mode de règlement, le niveau de BAP, les données relatives aux relances ne sont pas des informations dont les mises à jour sont suivies.
Les principales zones de la table HISTODUD exploitées sont :
- la date d’évènement (DATEVT) qui correspond à la date comptable à laquelle a lieu l’évènement.
- l’état de l’échéance (DUDSTA) qui précise si une échéance est liée à une pièce comptabilisée ou simplement à un document saisi (par exemple une facture saisie mais non comptabilisée).
- DUDSTA=2 si l’échéance est associée à une pièce comptabilisée,
- DUDSTA est différent de 2 si l’échéance est associée à une pièce non comptabilisée. le tiers et le collectif de l’échéance (BPR et SAC) qui contiennent le tiers et le compte collectif sur lesquels l’échéance est comptabilisée.
- le champ Soldée (FLGCLE) qui caractérise l’échéance par rapport à son solde, peut prendre les valeurs suivantes :
- si FLFCLE=1 ou 0, l'échéance est non réglée/soldée ou réglée/soldée partiellement,
- si FLGCLE=2, l'échéance est réglée/soldée définitivement (montant de l'échéance AMTCUR = montant réglé comptabilisé PAYCUR et AMTCUR<>0 ; ou AMTCUR=0 et montant de l'échéance AMTLOC = montant réglé comptabilisé PAYLOC),
- si FLFCLE=3, l'échéance ‘historisée’ est supprimée,
- si FLGCLE=4, l'échéance est réglée/soldée ‘temporairement’ (montant de l’échéance AMTCUR=montant réglé comptabilisé au titre de l’échéance PAYCUR + montant provisoire réglé au titre de l’échéance TMPCUR).
Précisions sur la zone Date d'évènement
A - Dans le cas d’une comptabilisation de facture, la date d’évènement correspond à la date comptable de la facture.
B - Dans le cas d’un lettrage partiel ou complet d’une échéance (via l'imputation directe d’un règlement à l’échéance ou le lettrage comptable), pour la/les échéances réglées, la date d’événement correspond à la date comptable la plus élevée des pièces du groupe au moment du lettrage.
Exemple :
Soit :
- un règlement d’un acompte intervenu en date comptable T1,
- la comptabilisation d’une facture en date comptable T2,
- comptabilisation de la reprise d’acompte en date comptable T3.
Les pièces du groupe seront considérées comme soldées en DATEVT=date comptable des pièces du groupe la plus élevée et donc T3.
Dans le cas d’une échéance partiellement ou totalement soldée définitivement (et donc associée à une ligne d’écriture avec un code lettrage minuscule ou majuscule), la date d’évènement retenue à chaque lettrage correspond à la date comptable maximale des pièces du groupe au moment du lettrage (et donc à MTCDATMAX de GACCENTRYD).
Selon la méthode de lettrage, l’alimentation de la table HISTODUD et de cette date d’évènement varient.
Exemple :
Soit une facture comptabilisée en date T1 pour 1.000 €, suivie de deux règlements en date T2 et T3 :
- un de 600 € en date comptable T2
- un de 400 € en date comptable T3.
Deux cas sont à distinguer :
- la facture est d’abord réglée partiellement pour 600 (règlement comptabilisé en T2) puis soldée via le règlement de 400 (comptabilisé en T3),
- les trois pièces sont comptabilisées séparément et le lettrage n’est fait qu’a posteriori, via le lettrage comptable (fonctions LETTRAGE ou LETTRAUTO).
Dans le premier cas, l’historisation va refléter l’historique de lettrage :
- en date de référence T1, la facture va apparaitre pour son montant total,
- en date T2, la facture va apparaitre pour un solde de 400,
- en date T3, la facture ne va plus apparaitre.
Dans le deuxième cas, s’agissant d’un lettrage manuel de trois pièces comptables, la date d’évènement va aussi être la date comptable la plus élevée mais le résultat va être quelque peu différent :
- en date de référence T1, la facture va apparaitre pour son montant total,
- en date T2 la facture pour son montant total de 1000 € et le règlement de 600 € apparaissent,
- en date T3, la facture et le règlement n'apparaissent plus.
Le résultat du premier scénario peut être obtenu de la même façon via le lettrage comptable si la facture et le règlement de 600 € sont lettrés dans une première manipulation. Le groupe de lettrage de deux pièces avec le règlement de 400 € sont ensuite lettrés dans une deuxième manipulation.
Ces manipulations sont possibles dans la mesure où l’historique de lettrage aura été reconstitué par l’utilisateur via la décomposition des étapes de lettrage manuel.
C - Dans le cas d’un transfert de collectif, aucun nouvel enregistrement ne sera créé, les précédents enregistrements étant mis à jour pour le code collectif, la date évènement ne bougeant pas.
D - Dans le cas d’une fusion de tiers, le principe est identique à celui du transfert de collectifs : aucune création de nouvel enregistrement dans la table HISTODUD, mais une simple mise à jour des enregistrements existants sans modification de la date d'évènement.
Tâche batch
Cette fonction peut être lancée en batch. La tâche standard ACCRECHDU est prévue à cet effet.
Messages d'erreur
Outre les messages génériques, les messages d'erreur suivants peuvent apparaître lors de la saisie :
Certains champs directement liés à la table de référence GACCDUDATE sont mis à jour, les messages d'erreur étant alors identiques à ceux utilisés en resynchronisation des échéances, à savoir :
- ACCNUM : Numéro interne incorrect
- CPY : Société incorrecte
- FCY : Site incorrect
- CUR : Devise incorrecte
- SNS : Sens incorrect
- SAC : Collectif incorrect
- BPR / BPRTYP / BPRPAY : Tiers incorrect