Balance âgée historisée
La balance âgée historisée permet, pour une date de référence donnée, de reconstituer le solde comptable à cette date.
Cet état peut donc être mis en regard de la balance générale auxiliaire pour disposer de la justification du solde comptable à la date de référence.
Cette édition se veut également être un outil de travail utile pour le suivi des échéances clients et fournisseurs.
Pré-requis
Dans le cas où cette édition doit être comparée à l’édition de la balance générale auxiliaire du grand-livre auxiliaire, le critère 'Règlements non validés' doit être positionné à 'Non'.
Les pièces en simulation active sont systématiquement prises en compte, les pièces en simulation inactive ne le sont jamais.
Liste des critères
|
Paramètre |
Intitulé paramètre |
Type |
|---|---|---|
|
societe |
Société |
|
|
sitedeb |
Borne de sites |
|
|
coldeb |
Borne de collectifs |
SAC |
|
grpcol |
Groupe de collectifs |
|
|
tiersdeb |
Borne de tiers |
|
|
borne1 |
Nb de jours 1 |
C |
|
borne2 |
Nb de jours 2 |
C |
|
borne3 |
Nb de jours 3 |
C |
|
borne4 |
Nb de jours 4 |
C |
|
borne5 |
Nb de jours 5 |
C |
|
ecrisim |
Ecritures de simulation (Menu local Non, Oui) |
|
|
datref |
Date référence |
D |
|
sens |
Sens (Menu local Débit, Crédit) |
|
|
detpce |
Détail par échéance (Menu local Non, Oui) |
|
|
tri |
Ordre de tri (Menu local Numéro, Intitulé, Intitulé court) |
|
|
impselections |
Impression des sélections (Menu local Non, Oui) |
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.