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.
      SEEWARNING 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

SEEREFERTTO 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)
  /  / : Date incorrecte => 10/02/11

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)
   15/09/11 : Date incorrecte => 10/02/11

 

 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
Création pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 12/02/11
Création pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 10/02/11

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
Création pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 12/02/11
Création pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 10/02/11

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.
Fichier trace listant les nouveaux enregistrements créés par l'utilitaire.

Pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1
Création pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 (151017) 12/02/11
Création pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 (151018) 10/02/11

 

 Oui

 Oui

 Oui

Suppression des enregistrements existants et création des nouveaux enregistrements d’historisation des échéances.
Fichier trace listant les enregistrements effacés et les nouveaux enregistrements créés par l'utilitaire.

Pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1
***151017 /  / 
***151018 /  / 
Création pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 (151019) 12/02/11
Création pièce FAC FCRHDU10102VEN00001 Ligne 1 Echéance 1 (151020) 10/02/11

 

Ecran de saisie

En-tête

Société (champ CPY)

Pas d'aide liée à ce champ.

Critères

Tous sites (champ ALLFCY)

Pas d'aide liée à ce champ.

Site (champ FCY)
Tous types de tiers (champ ALLTYPBPR)
Type de tiers (champ TYPBPR)
Tous tiers (champ ALLBPR)
Tiers début (champ BPRSTR)
Tiers fin (champ BPREND)
Tous collectifs (champ ALLSAC)
Groupe de collectif (champ GRPSAC)
Collectif (champ SAC)

Bloc numéro 3

Resynchronisation (champ RECUP)

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 :

  • la clé NUMHDU,
  • les champs de traçabilité CREDAT et CREUSR,
  • les champs permettant de faire le lien avec la table de référence GACCDUDATE : TYP, NUM, LIG et DUDLIG,
  • d'autres champs divers, tels que FLGPAZ, DUDDAT, PAYDAT et TYPDUD.

Certains champs sont re-synchronisés par application d'une règle, à savoir :

  • champ Soldée : ce champ caractérise l’échéance par rapport à son solde et il peut prendre les valeurs suivantes :
    • '0' ou '1' lorsque l'échéance n'est pas soldée ou soldée partiellement,
    • '2' lorsque l'échéance est 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),
    • '3' lorsque l'échéance historisée a été supprimée,
    • '4' lorsque l'échéance est soldée temporairement (montant de l'échéance AMTCUR = montant réglé comptabilisé PAYCUR + montant réglé non comptabilisé TMPCUR et AMTCUR<>0 ; ou AMTCUR=0 et montant de l'échéance AMTLOC = montant réglé comptabilisé PAYLOC + montant réglé non comptabilisé TMPLOC).

      La valeur de ce champ est contrôlée et éventuellement corrigée uniquement pour les cas où elle est différente de '3'.
      Pour les enregistrements d'historisation ayant un champ Soldée différent de '3', les zones Montant échéance en devise (AMTCUR), Montant devise locale (AMTLOC), Montant réglé (PAYCUR), Réglé société (PAYLOC), Montant réglé provisoire (TMPCUR) et Règlement provisoire soc (TMPLOC) sont lues pour ensuite ré-évaluer la valeur du champ Soldée suivant la règle définie ci-dessus.
  • champ Date d'évènement :
    • dans le cas où le Montant réglé est supérieur à '0', l'utilitaire resynchronise la date d'évènement par rapport à la date comptable maximale du groupe de lettrage : en effet l'utilitaire retrouve la ligne d'écriture à l'origine de l'échéance via le numéro de compte ACCNUM de la table des pièces comptables GACCENTRYD. Comme la ligne est lettrée (la ligne Montant 'MTC' de la table GACCENTRYD n'est pas vide), l'utilitaire prend en compte le montant de la date comptable maximale de lettrage 'MTCDATMAX' de la ligne de la table GACCENTRYD.
    • dans le cas où l'échéance n'est pas soldée (si le champ Soldée est inférieur à 2), l'utilitaire resynchronise la date d'évènement par rapport à la date comptable ACCDAT de la pièce (la date est  retrouvée via le numéro de compte ACCNUM de la table GACCENTRYD).

SEEINFO Les champs liés aux montants ne font pas l'objet d'une resynchronisation :

  • les zones de montant de l'échéance (AMT*),
  • les zones de montant réglé (PAY*),
  • les zones de montant réglé provisoire (TMP*).
Effacement (champ DEL)

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.

  • pour une échéance DUD sans lien avec la table des lignes d'écritures GACCENTRYD, l’historique créé va être :
    • un seul enregistrement avec [F:HDU]DUDSTA = 0  (document origine non comptabilisé) et avec [F:HDU]DATEVT initialisé avec la date d’échéance [F:DUD]DUDDAT,
  • pour une échéance DUD avec un lien avec GACCENTRYD et sans lettrage ([F:DAE]MTC à vide), l’historique créé va être :
    • un enregistrement avec [F:HDU]DUDSTA = 0  (document origine non comptabilisé) et avec [F:HDU]DATEVT initialisé avec la date d’échéance [F:DUD]DUDDAT,
    • un enregistrement avec [F:HDU]DUDSTA = 2  (document comptabilisé) et avec [F:HDU]DATEVT initialisé avec la date comptable de la pièce [F:HAE]ACCDAT,
  • pour une échéance DUD avec un lien avec GACCENTRYD et un lettrage ([F:DAE]MTC différent de vide), l’historique créé va être :
    • un enregistrement avec [F:HDU]DUDSTA = 0  (document origine non comptabilisé) et avec [F:HDU]DATEVT initialisé avec la date d’échéance [F:DUD]DUDDAT,
    • un enregistrement avec [F:HDU]DUDSTA = 2  (document comptabilisé) et avec [F:HDU]DATEVT initialisé avec la date comptable de la pièce [F:HAE]ACCDAT,
    • un enregistrement avec [F:HDU]DUDSTA = 2  (document comptabilisé) et avec [F:HDU]DATEVT initialisé avec la date comptable maximale du groupe de lettrage [F:DAE]MTCDATMAX.
LIMITE n°1

La 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.
De ce fait, pour un groupe de pièces lettrées, la mise à jour du solde ne peut être constatée au fur et à mesure mais uniquement à la date comptable maximale du groupe de lettrage ([F:DAE]MTCDATMAX).

Exemple :
Dans le cas d’une facture lettrée minuscule avec deux règlements A et B de dates comptables A et B différentes, les nouveaux enregistrements créés constateront le solde de la facture à la date comptable la plus élevée des deux, B, et non pas successivement et progressivement aux dates comptables de chacun des deux règlements.
A la date comptable du règlement A, la balance âgée va donc restituer la facture pour son montant total d’origine, ainsi que le règlement A, pour son montant total aussi, soit un solde global représentant bien le net.
A la date comptable du règlement B, la balance âgée ne va restituer que la facture pour son solde net (déflaqué donc du montant des règlements A et B).

LIMITE n°2

La  resynchronisation avec effacement ne permet pas de gérer le cas d’une annulation de règlement qui interviendrait a posteriori de cette resynchronisation.
Soit un groupe constitué d’au moins deux règlements de dates comptables différentes, ce groupe ayant ‘subi’ l’effacement avec resynchronisation. Si une annulation comptable est ensuite constatée sur un des règlements du groupe (autre que celui avec la date comptable la plus élevé), la mise à jour de l’historisation de l’annulation ne permettra pas de détecter l’annulation ; la situation intermédiaire constatée dans la balance âgée ne tiendra pas compte de cette annulation.

Exemple :
Soit la comptabilisation d'une facture de 10.000 en date comptable du 01/03/11.
Soit la comptabillisation d'un règlement A de 500 en date comptable du 08/03/11.
Soit la comptabillisation d'un règlement B de 600 en date comptable du 14/03/11.
Suit une resynchronisation avec effacement.
Suit une annulation comptable du règlement A en date comptable du 08/03/11.
Balance agée du 08/03/11 : la facture apparaît pour un solde de 10.000 et le règlement pour -500, soit un solde de 9.500. L'annulation n'a pas été prise en compte.
Balance agée du 14/03/11 : la facture apparaît pour un solde de 9.400.

En relançant une resynchronisation avec effacement sur le tiers concerné, les nouvelles données de l'historique sont reconstituées sans cette limite.

Trace détaillée (champ TRC)

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).

SEEWARNING 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.

SEEINFO  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

Tables mises en oeuvre

SEEREFERTTO Reportez-vous à la documentation de Mise en oeuvre