Votre modèle de données pour la gestion du crédit et le recouvrement
Votre modèle de données pour la gestion du crédit et le recouvrement
- Attributs recommandés à collecter
- Activités clés à suivre
- Conseils d’extraction pour SAP ECC
Attributs de gestion du crédit et de recouvrement
| Nom | Description | ||
|---|---|---|---|
|
Heure de l’événement
EventTime
|
Horodatage indiquant le moment où une activité ou un événement précis s’est produit. | ||
|
Description
L’heure de l’événement consigne la date et l’heure précises de chaque activité du processus. Elle constitue le fil chronologique du journal d’événements, permet d’ordonner les activités et de calculer les durées qui les séparent. Cet horodatage est indispensable au calcul des indicateurs temporels, comme le temps de cycle de résolution des litiges, le délai de comptabilisation des paiements et le nombre moyen de jours entre l’échéance et le paiement. Il permet de repérer les goulots d’étranglement en mettant en évidence les longues attentes entre deux étapes consécutives.
Pourquoi est-ce important ?
Cet attribut est essentiel pour ordonner correctement les événements et calculer les indicateurs de performance liés au temps, comme les temps de cycle et les durées.
Où trouver ces données
Provient de différents champs de date et d’heure des tables SAP, comme BUDAT (date de comptabilisation) ou CPUDT/CPUTM (date et heure de saisie de la pièce) dans BKPF, ou de tables propres aux événements.
Exemples
2023-01-15T09:30:00Z2023-02-10T14:00:00Z2023-02-28T11:25:10Z
|
|||
|
Nom de l’activité
ActivityName
|
Nom de l’activité métier ou de l’événement survenu à un moment précis du cycle de vie de la facture. | ||
|
Description
Cet attribut décrit une étape ou un événement précis du processus de gestion du crédit et de recouvrement, comme « Facture comptabilisée », « Exécution d’une campagne de relance » ou « Pièce de paiement entrant comptabilisée ». Ces activités constituent les nœuds de la carte de processus. L’analyse de leur séquence, de leur fréquence et de leur durée permet aux entreprises de visualiser le déroulement réel du processus, de repérer les écarts par rapport aux procédures standard et de localiser les goulots d’étranglement. Par exemple, l’analyse du parcours après une « Exécution d’une campagne de relance » peut révéler l’efficacité de la stratégie de relance.
Pourquoi est-ce important ?
Les activités constituent les éléments de base de la carte de processus et permettent de visualiser et d’analyser le déroulement du processus, ses variantes et ses exceptions.
Où trouver ces données
Il s’agit d’un attribut dérivé, généralement construit en associant des codes de transaction (TCODE), des types de pièces (BLART) ou des modifications de champs spécifiques dans différentes tables SAP, par exemple BKPF, BSID, MHNK et UDM_CASE, à des noms d’activité compréhensibles.
Exemples
Facture comptabiliséeExécution d’une campagne de relancePromesse de paiement enregistréePièce de paiement entrant comptabiliséeFacture compensée
|
|||
|
Numéro de facture
InvoiceNumber
|
Identifiant unique de la facture client, qui sert d’identifiant principal du cas pour le processus de gestion du crédit. | ||
|
Description
Le numéro de facture, appelé Belegnummer (BELNR) dans SAP, identifie de manière unique chaque pièce client. En Process Mining, il est essentiel, car il relie toutes les activités associées, de la comptabilisation et des relances jusqu’au paiement ou au passage en pertes, au sein d’un même cas. Analyser le processus à partir du numéro de facture comme identifiant de cas permet d’obtenir une vue complète du cycle de vie de la facture. Vous pouvez ainsi suivre des indicateurs clés comme le délai moyen de paiement client (DSO), repérer les goulots d’étranglement du recouvrement et évaluer l’efficacité des différentes stratégies de recouvrement pour chaque facture.
Pourquoi est-ce important ?
Cette clé essentielle relie tous les événements du parcours d’une facture et permet de retracer et d’analyser l’ensemble du processus, du crédit à l’encaissement.
Où trouver ces données
Présent dans plusieurs tables de comptabilité financière de SAP ECC, principalement dans BKPF (en-tête de pièce comptable) et BSEG (poste de pièce comptable), sous le champ BELNR.
Exemples
190000000119000000451900000102
|
|||
|
Chargé de recouvrement
Sachp
|
Le comptable ou le chargé de recouvrement affecté au compte client. | ||
|
Description
Cet attribut identifie la personne ou le groupe chargé du recouvrement pour un compte client donné. Dans SAP, il s’agit souvent du comptable (SACHP) indiqué dans la fiche de données de base du client. Cette dimension est essentielle pour suivre les performances de l’équipe de recouvrement. Elle permet de créer des Dashboards, comme « Vue d’ensemble de l’ancienneté des factures », filtrés par chargé de recouvrement, afin de répartir la charge de travail et de comparer les résultats des personnes ou des équipes. Elle permet notamment de déterminer quels chargés de recouvrement obtiennent les meilleurs résultats pour régler les factures en retard.
Pourquoi est-ce important ?
Permet d’analyser les performances et de répartir la charge de travail de l’équipe de recouvrement en associant les cas et leurs résultats à des personnes ou à des groupes.
Où trouver ces données
Généralement présent dans les données de la société de la fiche client (table KNB1, champ SACHP).
Exemples
J. SmithÉquipe AINTL-COLL
|
|||
|
Date d’échéance
NetDueDate
|
Date à laquelle le paiement de la facture doit être effectué conformément aux conditions convenues. | ||
|
Description
La date d’échéance est la date limite à laquelle le client est censé régler une facture. Elle est calculée à partir de la date de base de la facture et des conditions de paiement. Dans SAP, la date d’échéance nette est souvent disponible dans le champ FAEDT. Cette date est fondamentale pour la gestion du crédit : elle sert de référence pour mesurer le respect des délais. Elle permet de calculer des indicateurs comme le nombre moyen de jours entre l’échéance et le paiement, et de déclencher les activités de recouvrement une fois l’échéance dépassée. L’analyse des retards par rapport à cette date est au cœur de l’analyse du recouvrement.
Pourquoi est-ce important ?
Il s’agit de la référence principale pour mesurer le respect des délais de paiement et de calculer le nombre de jours de retard ainsi que les indicateurs associés.
Où trouver ces données
Cette date est souvent directement disponible dans les tables de postes clients, comme BSID, sous le champ FAEDT (date d’échéance nette). Elle peut également être calculée à partir de la date de base (ZFBDT) et des conditions de paiement (ZTERM).
Exemples
2023-02-142023-03-312023-04-15
|
|||
|
Jours de retard
DaysOverdue
|
Nombre de jours écoulés depuis la date d’échéance de la facture. | ||
|
Description
Cet indicateur calcule le nombre de jours entre la date d’échéance de la facture et sa date de lettrage. Pour les factures ouvertes, le calcul se fait à partir de la date du jour. Le nombre de jours de retard est un indicateur fondamental pour l’analyse des comptes clients. Il constitue la mesure principale du Dashboard « Vue d’ensemble de l’ancienneté des factures » et sert à prioriser les activités de recouvrement. Son évolution à l’échelle globale peut donner une indication de la santé générale des créances clients.
Pourquoi est-ce important ?
Cet indicateur central mesure directement les retards de paiement. Il sert à prioriser les efforts de recouvrement et à évaluer la santé du processus.
Où trouver ces données
Attribut calculé selon la formule suivante : (date de lettrage ou date du jour) − date d’échéance nette.
Exemples
0153295
|
|||
|
Montant de la facture
Dmbtr
|
Montant total de la facture dans la devise locale. | ||
|
Description
Cet attribut correspond au montant total de la facture. Dans SAP, il est souvent enregistré dans le champ DMBTR, qui indique le montant en devise locale. Le montant de la facture est un axe d’analyse important. Il permet de donner la priorité au recouvrement des factures de montant élevé et de déterminer s’il existe un lien entre le montant de la facture, les retards de paiement et les litiges. Vous pouvez filtrer la carte de processus pour ne conserver que les factures dépassant un certain seuil.
Pourquoi est-ce important ?
Apporte un contexte financier à l’analyse du processus et permet de comparer les résultats selon la valeur des factures et de donner la priorité au recouvrement des montants élevés.
Où trouver ces données
Champ standard DMBTR (montant en devise locale) dans des tables telles que BSEG, BSID et BSAD.
Exemples
1500.0012500.50750.25
|
|||
|
Niveau de relance
Mahns
|
Niveau de relance le plus élevé atteint pour la facture. | ||
|
Description
Le niveau de relance (MAHNS dans SAP) indique le nombre de relances envoyées pour une facture en retard et reflète l’intensité de la procédure de relance. Cet attribut est essentiel pour évaluer le processus de relance. Il est utilisé directement dans le Dashboard « Efficacité des relances par niveau » pour mesurer le pourcentage de factures réglées après chaque relance. Cette analyse permet d’affiner la stratégie de relance, par exemple en modifiant le calendrier ou le contenu des courriers aux niveaux qui donnent peu de résultats.
Pourquoi est-ce important ?
Mesure directement l’intensité des efforts de recouvrement, un élément essentiel pour évaluer l’efficacité de la stratégie de relance.
Où trouver ces données
Présent dans le poste client de la table BSID, sous le champ MAHNS. L’historique des campagnes de relance figure dans les tables MHNK (en-tête) et MHND (données).
Exemples
1234
|
|||
|
Nom d’utilisateur
UserName
|
Identifiant de l’utilisateur qui a exécuté l’activité. | ||
|
Description
Cet attribut identifie l’utilisateur responsable d’un événement, comme la comptabilisation d’une facture ou la création d’un dossier de litige. Dans SAP, cette information figure souvent dans des champs tels que ERNAM (créé par) ou USNAM. L’analyse par utilisateur permet de comprendre la répartition de la charge de travail, de repérer les besoins de formation et de détecter d’éventuels problèmes de conformité. Elle peut, par exemple, montrer si certains utilisateurs sont régulièrement associés à des écarts ou à des retards, ou si les personnes les plus performantes suivent une variante de processus plus efficace.
Pourquoi est-ce important ?
Cet attribut permet d’analyser les performances et les comportements des personnes dans le processus, afin de repérer les meilleurs résultats, les besoins de formation et les déséquilibres de charge de travail.
Où trouver ces données
Généralement présent dans les tables d’en-tête, comme BKPF, sous USNAM (nom d’utilisateur) ou ERNAM (nom de la personne ayant créé l’objet).
Exemples
SMITHJRDOECFO-ADMIN
|
|||
|
Numéro de client
Kunnr
|
Identifiant unique du client. | ||
|
Description
Le numéro de client (KUNNR dans SAP) est la clé unique d’un compte client. Il relie une transaction aux données de base du client concerné, notamment son historique de paiement, ses informations de crédit et ses coordonnées. En Process Mining, cet attribut est essentiel pour segmenter l’analyse. Il permet de comparer les performances du processus entre clients, de repérer ceux qui paient régulièrement en retard et d’analyser les différences entre les stratégies de recouvrement appliquées aux comptes stratégiques et aux autres comptes. Il est indispensable aux Dashboards tels que l’ancienneté des factures et le respect des conditions de paiement.
Pourquoi est-ce important ?
Permet d’analyser le processus du point de vue des clients, de repérer les comportements propres à certains clients ou groupes de clients et d’adapter les stratégies de recouvrement.
Où trouver ces données
Champ standard KUNNR dans les tables de postes clients (BSID, BSAD) et les tables d’en-tête des pièces (BKPF, si le champ est renseigné).
Exemples
10002050CUST-7890
|
|||
|
Segment de clientèle
CustomerSegment
|
Classification des clients, par exemple selon leur taille, leur secteur d’activité ou leur importance stratégique. | ||
|
Description
Le segment de clientèle regroupe les clients qui présentent des caractéristiques similaires. Il est souvent dérivé du groupe de comptes client (KTOKD) dans SAP ou d’autres champs personnalisés des données de base client. La segmentation de l’analyse du processus à partir de cet attribut permet de repérer si certains groupes ont des délais de paiement plus longs, davantage de litiges ou réagissent mieux à certaines activités de recouvrement. Ces informations sont essentielles pour optimiser les stratégies de recouvrement et adapter les échanges avec les clients.
Pourquoi est-ce important ?
Permet d’analyser les performances du processus selon les types de clients et d’adapter les stratégies ainsi que la répartition des ressources.
Où trouver ces données
Souvent dérivé du champ du groupe de comptes client (KTOKD) dans la table des données de base client KNA1, ou d’autres champs personnalisés.
Exemples
Comptes clésPetites et moyennes entreprisesSecteur publicInterne
|
|||
|
Catégorie de risque
Ctlpc
|
Classification du risque de crédit du client. | ||
|
Description
La catégorie de risque (CTLPC dans SAP) regroupe les clients selon leur solvabilité et leur historique de paiement. Cette classification sert à effectuer des contrôles de crédit automatisés et à orienter les stratégies de recouvrement. L’analyse du processus par catégorie de risque peut révéler des différences importantes. Elle permet de voir si les clients à haut risque suivent des parcours différents ou connaissent des délais de paiement nettement plus longs. Ces informations aident à vérifier la pertinence de la classification des risques et à adapter l’intensité du recouvrement au niveau de risque.
Pourquoi est-ce important ?
Permet d’analyser le processus de recouvrement en fonction du risque, de vérifier les modèles de risque et d’adapter les stratégies de recouvrement.
Où trouver ces données
Présent dans les données centrales de gestion du crédit du client, dans la table KNKK, champ CTLPC.
Exemples
001002RISQUE ÉLEVÉ
|
|||
|
Code société
Bukrs
|
Identifiant de l’entité juridique (code société) à laquelle appartient la facture. | ||
|
Description
Le code société (BUKRS dans SAP) désigne une entité juridique indépendante pour laquelle des états financiers sont établis. Il s’agit d’une unité organisationnelle fondamentale de SAP Financials. Cet attribut est essentiel pour filtrer et comparer les performances des processus entre les différentes entités juridiques d’un groupe. Il permet de vérifier si les processus de recouvrement sont standardisés ou si leurs résultats varient sensiblement, par exemple en matière de DSO ou de taux de litiges, d’un code société à l’autre.
Pourquoi est-ce important ?
Permet de segmenter l’analyse des processus par entité juridique, ce qui est essentiel pour comparer les performances au sein des grandes organisations multinationales.
Où trouver ces données
Champ standard BUKRS présent dans presque toutes les tables financières, notamment BKPF, BSEG, BSID et BSAD.
Exemples
10002000US01
|
|||
|
Conditions de paiement
Zterm
|
Code correspondant aux conditions de paiement convenues avec le client. | ||
|
Description
Le code des conditions de paiement (ZTERM dans SAP) définit les modalités de règlement, notamment l’échéance et les éventuels escomptes pour paiement anticipé. Il est généralement renseigné dans les données de base du client, puis repris sur les factures. L’analyse par conditions de paiement permet de comprendre leur incidence sur les comportements de paiement. Le Dashboard « Respect des conditions de paiement et incidence », par exemple, montre dans quelle mesure les conditions sont respectées et leur effet sur le nombre de jours de retard. Ces éléments peuvent éclairer le choix des conditions de paiement à proposer aux différents segments de clientèle.
Pourquoi est-ce important ?
Décrit l’accord contractuel relatif au paiement et permet d’analyser si certaines conditions améliorent les délais de paiement ou entraînent davantage de litiges.
Où trouver ces données
Champ standard ZTERM, présent dans les données de base du client (KNB1) et dans les tables des documents financiers (BSEG).
Exemples
0001NT30ZD60
|
|||
|
Créance passée en perte
IsWrittenOff
|
Indicateur booléen précisant si la facture a finalement été passée en perte au titre d’une créance irrécouvrable. | ||
|
Description
Cet indicateur dérivé est généralement défini sur « vrai » lorsqu’une facture est lettrée avec un motif ou un type de document spécifique signalant un abandon de créance. Il permet d’identifier les cas qui entraînent une perte financière. Cet attribut est essentiel au calcul de l’indicateur « Taux d’abandon de créances irrécouvrables » et aux Dashboards associés. Il permet d’analyser les causes profondes en étudiant les caractéristiques des factures et des clients fréquemment concernés, afin d’améliorer les politiques de crédit et l’efficacité du recouvrement.
Pourquoi est-ce important ?
Identifie les issues du processus qui entraînent une perte financière et permet d’en rechercher les causes afin de réduire les créances irrécouvrables et d’améliorer la politique de crédit.
Où trouver ces données
Attribut dérivé. La logique repose généralement sur l’identification des motifs de lettrage (BSEG-RSTGR) ou des types de document (BKPF-BLART) associés aux abandons de créances.
Exemples
truefalse
|
|||
|
Dernière actualisation des données
LastDataRefreshTimestamp
|
Horodatage indiquant la dernière extraction ou mise à jour des données dans l’outil de Process Mining. | ||
|
Description
Cet attribut enregistre la date et l’heure du chargement de données le plus récent. Il permet aux équipes métier de savoir si les données qu’elles analysent sont à jour. Lorsqu’elles consultent des Dashboards et des analyses, cet horodatage leur indique si les données comprennent les transactions les plus récentes ou si un décalage est connu. Ces métadonnées sont essentielles pour établir la confiance dans les résultats de l’analyse.
Pourquoi est-ce important ?
Indique si les données sont à jour, ce qui est essentiel pour prendre des décisions à partir des informations les plus récentes disponibles sur le processus.
Où trouver ces données
Cette valeur est générée et enregistrée par le pipeline d’extraction et de chargement des données (ETL) lors de leur actualisation.
Exemples
2023-03-01T02:00:00Z2023-03-02T02:00:00Z2023-03-03T02:00:00Z
|
|||
|
Document de lettrage
Augbl
|
Numéro du document ayant lettré la facture, généralement un paiement ou un avoir. | ||
|
Description
Le numéro du document de lettrage (AUGBL dans SAP) relie un poste ouvert, comme une facture, au document qui l’a soldé. Lorsqu’une facture est payée, le numéro du document de paiement est enregistré comme document de lettrage de cette facture. Ce champ est essentiel pour confirmer qu’une facture a été lettrée et la relier à l’événement de paiement ou d’avoir correspondant. Il sert à identifier l’activité « Facture lettrée » et à vérifier que le processus de bout en bout est correctement représenté.
Pourquoi est-ce important ?
Établit le lien explicite entre une facture et son document de règlement, ce qui est essentiel pour modéliser correctement les événements de lettrage.
Où trouver ces données
Champ standard AUGBL dans les tables des postes clients BSID (vide tant que le poste est ouvert) et BSAD (renseigné après le lettrage).
Exemples
140000000114000000551400000120
|
|||
|
ID du litige
DisputeCaseId
|
Identifiant unique du litige associé à la facture. | ||
|
Description
Lorsqu’un client conteste une facture, un dossier de litige peut être créé dans le module Dispute Management de SAP. Cet identifiant permet de retrouver ce dossier de manière unique. Il permet d’analyser en détail le traitement des litiges. Il est indispensable au calcul de l’indicateur « Temps de cycle de résolution des litiges » et aide à comprendre pourquoi les litiges sont créés, comment ils sont traités et quelles en sont les issues habituelles. Il permet d’isoler le sous-processus de gestion des litiges du flux de recouvrement standard.
Pourquoi est-ce important ?
Relie les activités de recouvrement aux dossiers de litige, afin d’analyser spécifiquement l’efficacité du traitement des litiges et leurs causes profondes.
Où trouver ces données
Présent dans les tables SAP Dispute Management, notamment UDM_CASE_ATTR00. Nécessite le module SAP Dispute Management.
Exemples
400000000021400000000157400000000305
|
|||
|
Identifiant du système source
SourceSystemId
|
Identifiant du système source dont les données ont été extraites. | ||
|
Description
Cet attribut indique le système d’origine, par exemple une instance SAP ECC précise comme « ECCPRD100 ». Il est utile lorsque l’environnement comprend plusieurs systèmes ERP ou que les données proviennent de différentes sources. Il permet de filtrer et de comparer les processus entre systèmes ou régions. La provenance des données reste ainsi claire, ce qui facilite également le diagnostic des problèmes d’extraction.
Pourquoi est-ce important ?
Cet attribut précise l’origine des données, notamment dans les environnements informatiques complexes. Il garantit leur traçabilité et permet d’effectuer des analyses propres à chaque système.
Où trouver ces données
Généralement ajouté lors de l’extraction des données. Dans SAP, le nom du système logique (LOGSYS) peut être utilisé.
Exemples
SAPECC_PROD_100ECC_EU_200US_FIN_ERP
|
|||
|
Limite de crédit
Klimk
|
Montant total de la limite de crédit accordée au client. | ||
|
Description
La limite de crédit (KLIMK dans SAP) correspond au montant maximal de crédit accordé à un compte client. Elle constitue un élément important de la gestion du risque de crédit. Cet attribut est essentiel pour le Dashboard « Précision des limites de crédit et créances irrécouvrables ». En analysant le lien entre la limite accordée et les abandons de créances, une entreprise peut évaluer l’efficacité de sa politique de crédit. Il permet également de suivre des indicateurs comme le « Taux de révision des limites de crédit » et de vérifier la pertinence des évaluations initiales.
Pourquoi est-ce important ?
Apporte un éclairage sur le risque de crédit et permet d’évaluer si les politiques de crédit préviennent les créances irrécouvrables sans freiner les ventes.
Où trouver ces données
Présent dans les données centrales de gestion du crédit du client, dans la table KNKK, champ KLIMK.
Exemples
10000.0050000.00250000.00
|
|||
|
Type de document
Blart
|
Type de document financier, par exemple une facture, un avoir ou un paiement. | ||
|
Description
Le type de document (BLART dans SAP) classe les documents comptables. Par exemple, « RV » peut désigner une facture client, « DZ » un paiement client et « DG » un avoir. Les activités utilisées pour le Process Mining sont dérivées des données, mais le type de document d’origine apporte un contexte important. Il peut servir à vérifier les résultats ou à mener une analyse financière plus détaillée. Il aide à comprendre la nature des opérations traitées et à filtrer l’analyse pour se concentrer sur certains types de documents, comme les factures clients.
Pourquoi est-ce important ?
Apporte un contexte financier en classant les opérations. Il permet de filtrer l’analyse ou de vérifier les noms d’activités dérivés des données.
Où trouver ces données
Champ standard BLART dans la table d’en-tête des documents BKPF.
Exemples
RVDZDGAB
|
|||
Activités de gestion du crédit et de recouvrement
| Activité | Description | ||
|---|---|---|---|
|
Date d’échéance dépassée
|
Cet événement calculé indique que la facture est officiellement échue. Il ne s’agit pas d’un événement explicite du système : il est déduit en comparant la date d’échéance nette de la facture à la date du jour ou à l’horodatage d’une activité ultérieure. | ||
|
Pourquoi est-ce important ?
Cet événement marque le passage de la facturation courante au processus de recouvrement. Il déclenche le calcul du nombre de jours de retard et le lancement des procédures de relance, et sert de base aux rapports d’ancienneté des créances.
Où trouver ces données
Il s’agit d’un événement calculé, obtenu en comparant la date d’échéance nette du poste de facture ouvert (BSID-NETDT) à la date du système ou à l’horodatage d’un autre événement.
Données à recueillir
Calculé en comparant la date d’échéance nette de la facture (BSID-NETDT) à une chronologie.
Type d’événement
calculated
|
|||
|
Exécution d’une campagne de relance
|
Cette activité correspond à l’exécution du programme automatique de relance pour une facture échue. Pour chaque facture incluse dans une campagne, le système consigne le niveau de relance, la date et d’autres informations. | ||
|
Pourquoi est-ce important ?
Le suivi des relances est essentiel pour évaluer l’efficacité de la stratégie de recouvrement. Il permet de déterminer quels niveaux de relance incitent le plus souvent les clients à payer et de repérer ceux qui ne répondent pas.
Où trouver ces données
Il s’agit d’un événement explicite. Les détails des campagnes de relance sont enregistrés dans les tables de données correspondantes, principalement MHNK, qui contient la date de la campagne (LAUFD) et le niveau de relance (MAHNS) pour chaque facture relancée.
Données à recueillir
Extrayez les enregistrements de la table MHNK en reliant le code société, le compte et la date de relance.
Type d’événement
explicit
|
|||
|
Facture compensée
|
Cet événement marque la clôture effective d’une facture, généralement après réception et affectation du paiement intégral. Il est déduit lorsque le poste de facture passe de la table des postes ouverts (BSID) à celle des postes compensés (BSAD). | ||
|
Pourquoi est-ce important ?
Il s’agit du principal événement de fin positif du processus. Le temps nécessaire pour atteindre cette étape constitue un élément central du DSO. L’analyse des parcours qui y mènent permet de repérer les bonnes pratiques.
Où trouver ces données
Il s’agit d’un événement déduit. La compensation est repérée par la présence d’un document de compensation (AUGBL) et d’une date de compensation (AUGDT) pour le poste de facture dans la table des postes compensés BSAD.
Données à recueillir
Utilisez la date de compensation (BSAD-AUGDT) du poste de facture concerné comme horodatage de l’événement.
Type d’événement
inferred
|
|||
|
Facture comptabilisée
|
Correspond à la création d’une pièce de facture client dans le module de comptabilité financière. Cet événement est enregistré explicitement lorsqu’un document de facturation des ventes et de la distribution (SD) est transféré en comptabilité ou qu’une facture FI est saisie directement, ce qui crée des écritures dans les tables BKPF et BSEG. | ||
|
Pourquoi est-ce important ?
Il s’agit de l’événement de début principal du cycle de vie de la facture. Le temps écoulé entre cette étape et le paiement est essentiel pour mesurer le délai moyen de paiement client (DSO) et l’efficacité globale du processus.
Où trouver ces données
Cet événement explicite est enregistré lors de la création d’une pièce comptable. Son horodatage peut être récupéré dans la table d’en-tête des pièces BKPF, dans le champ CPUDT ou BKTXT, pour le numéro de pièce de facture correspondant (BELNR).
Données à recueillir
Repérez dans la table BKPF les événements de création de pièces FI dont le type est pertinent, par exemple « RV » ou « DR ».
Type d’événement
explicit
|
|||
|
Facture passée en pertes
|
Correspond à la décision de comptabiliser une facture impayée en perte et de la classer comme créance irrécouvrable. Cette opération est enregistrée par une écriture financière spécifique qui compense la facture d’origine et transfère le montant sur un compte de créances irrécouvrables. | ||
|
Pourquoi est-ce important ?
Il s’agit du principal événement de fin négatif, qui signale un échec du processus de crédit ou de recouvrement et une perte financière directe. L’analyse de ces cas est essentielle pour améliorer les politiques de crédit et les stratégies de recouvrement.
Où trouver ces données
Il s’agit généralement d’une écriture explicite ou d’un événement déduit de l’opération de compensation. La compensation est effectuée à l’aide d’un code de transaction et d’un code motif spécifiques indiquant un passage en pertes. L’analyse de la pièce de compensation permet de confirmer l’opération.
Données à recueillir
Repérez les pièces de compensation utilisant un code motif spécifique pour les passages en pertes (BSEG-RSTGR), ou dont la contrepartie est comptabilisée sur un compte de charges pour créances irrécouvrables.
Type d’événement
inferred
|
|||
|
Avoir comptabilisé
|
Correspond à la création d’une pièce d’avoir sur un compte client, souvent pour corriger une erreur de facturation ou résoudre un litige. Cette pièce est créée explicitement dans le module FI. | ||
|
Pourquoi est-ce important ?
Les avoirs résultent directement de défaillances en amont du processus, comme une erreur de prix ou d’expédition. L’analyse de leur fréquence et de leurs causes profondes est essentielle pour améliorer le processus et réduire les pertes de revenus.
Où trouver ces données
Cet événement explicite est enregistré lors de la création d’une pièce comptable de type avoir, par exemple « DG ». Son horodatage peut être récupéré dans la table d’en-tête des pièces BKPF.
Données à recueillir
Repérez dans la table BKPF les événements de création de pièces FI de type avoir, par exemple « DG » ou « G2 ».
Type d’événement
explicit
|
|||
|
Contact de recouvrement consigné
|
Un agent de recouvrement a contacté le client au sujet d’une facture échue, par exemple par téléphone ou par e-mail. L’agent consigne généralement cette activité manuellement dans le système. | ||
|
Pourquoi est-ce important ?
Cette activité mesure le travail manuel de l’équipe de recouvrement. En comparant la fréquence et le moment des contacts aux paiements ultérieurs, vous pouvez évaluer l’efficacité des actions des agents.
Où trouver ces données
Si SAP FSCM Collections Management est utilisé, l’activité est consignée sous la forme d’un « Customer Contact ». Les détails sont stockés dans les tables liées à la liste de travail et à l’historique des contacts du service de recouvrement, souvent en lien avec UDM_CASE.
Données à recueillir
Extrayez les journaux de contacts clients des tables SAP FSCM Collections Management concernées.
Type d’événement
explicit
|
|||
|
Facture bloquée pour paiement
|
Indique qu’un blocage manuel ou automatique a été appliqué à la facture, empêchant son paiement. Ce blocage est enregistré par un indicateur spécifique sur le poste de facture dans la table BSEG. | ||
|
Pourquoi est-ce important ?
Les blocages de paiement sont une cause importante de retards et d’exceptions dans le processus. Savoir quand et pourquoi les factures sont bloquées permet d’en déterminer les causes profondes, de réduire les retards de paiement et d’améliorer la trésorerie.
Où trouver ces données
Ce statut est généralement déduit d’une modification du champ de blocage de paiement (BSEG-ZLSPR) sur le poste de facture. Les journaux de modifications de ce champ, dans les tables CDHDR et CDPOS, peuvent fournir des horodatages explicites.
Données à recueillir
Repérez les modifications du champ BSEG-ZLSPR sur le poste de la pièce de facture et utilisez la table CDHDR pour obtenir les horodatages.
Type d’événement
inferred
|
|||
|
Litige enregistré
|
Correspond à l’enregistrement officiel d’un litige client lié à une facture, par exemple en cas d’écart de prix ou de quantité. Cet événement explicite est consigné dans le module SAP FSCM Dispute Management. | ||
|
Pourquoi est-ce important ?
Un litige bloque le processus de paiement et mobilise des ressources internes pour être résolu. Le suivi de sa création est la première étape pour analyser les délais de résolution, les causes profondes et les effets sur le DSO.
Où trouver ces données
Si SAP FSCM Dispute Management est utilisé, il s’agit d’un événement explicite. La création du dossier de litige est consignée dans des tables telles que UDM_CASE ou SCMG_T_CASE_ATTR, avec un horodatage de création.
Données à recueillir
Extrayez la date et l’heure de création des tables de gestion des dossiers, par exemple UDM_CASE, pour les dossiers liés à la facture.
Type d’événement
explicit
|
|||
|
Litige résolu
|
Le litige lié à la facture a fait l’objet d’une enquête et une solution a été trouvée. Ce résultat est généralement enregistré par une modification du statut du dossier dans SAP FSCM Dispute Management. | ||
|
Pourquoi est-ce important ?
La résolution d’un litige débloque le processus de paiement. Mesurer le temps entre la création du litige et sa résolution constitue un indicateur clé pour repérer les inefficacités de son traitement.
Où trouver ces données
Cet événement est déduit d’une modification du statut du dossier de litige. Les journaux de modifications (CDHDR/CDPOS) du champ de statut dans des tables telles que UDM_CASE fournissent l’horodatage.
Données à recueillir
Repérez, dans les journaux de modifications, l’horodatage auquel le statut du dossier de litige passe à « Closed » ou « Resolved ».
Type d’événement
inferred
|
|||
|
Pièce de paiement entrant comptabilisée
|
Correspond à l’enregistrement initial d’un paiement client dans le système, souvent avant son affectation à des factures précises. Cet événement explicite crée une pièce de paiement, par exemple de type DZ. | ||
|
Pourquoi est-ce important ?
Cette étape marque la réception des fonds. Le délai entre cet événement et l’événement final « Facture compensée » correspond au processus d’affectation du paiement, qui peut constituer un goulot d’étranglement important.
Où trouver ces données
Il s’agit d’un événement explicite, enregistré lors de la création d’une pièce de paiement dans la table BKPF et identifiable par certains types de pièces, par exemple « DZ ». La date de comptabilisation (BKPF-BUDAT) sert d’horodatage.
Données à recueillir
Repérez dans la table BKPF les créations de pièces dont le type est lié aux paiements, par exemple « DZ ».
Type d’événement
explicit
|
|||
|
Poste résiduel créé
|
Cet événement survient lors de l’affectation d’un paiement lorsqu’un client règle une facture en partie et que le petit solde restant est comptabilisé comme un nouveau poste ouvert. Il est déduit des détails de l’opération de compensation. | ||
|
Pourquoi est-ce important ?
Les postes résiduels signalent des écarts de paiement et génèrent du travail supplémentaire. Leur suivi permet de repérer les clients qui paient régulièrement un montant inférieur au montant dû et de mettre en évidence les problèmes de prix ou de facturation à l’origine de litiges.
Où trouver ces données
Il s’agit d’un événement déduit. Lorsqu’une opération de compensation, par exemple via F-28, compense une facture d’origine et crée également une nouvelle pièce de poste ouvert pour le montant restant, un poste résiduel est créé. Vous pouvez le repérer en examinant les postes de la pièce de compensation.
Données à recueillir
Analysez les pièces de compensation (BKPF-AUGBL) pour repérer les cas où un nouveau poste ouvert est créé avec une référence à la facture d’origine.
Type d’événement
inferred
|
|||
|
Promesse de paiement enregistrée
|
Un client a contacté le service de recouvrement et s’est engagé à effectuer un paiement avant une date précise. Cet événement est enregistré explicitement si SAP FSCM Collections Management est utilisé. | ||
|
Pourquoi est-ce important ?
Les promesses de paiement sont un résultat important des activités de recouvrement. L’analyse de leur création, de leur respect et de leur non-respect permet d’évaluer l’efficacité des actions des agents et de prévoir les encaissements.
Où trouver ces données
Si SAP FSCM Collections Management est utilisé, il s’agit d’un événement explicite. Les détails des promesses de paiement sont enregistrés dans des tables telles que UDM_P2P_ATTR, liées au partenaire commercial et à la facture.
Données à recueillir
Extrayez l’horodatage de création des tables de promesses de paiement, telles que UDM_P2P_ATTR dans SAP FSCM.
Type d’événement
explicit
|
|||
|
Promesse de paiement non tenue
|
Cet événement calculé indique qu’un client n’a pas payé à la date convenue dans le cadre d’une promesse de paiement. Il est déduit de l’absence de paiement correspondant à la date promise. | ||
|
Pourquoi est-ce important ?
Repérer les promesses non tenues permet d’intensifier les efforts de recouvrement au bon moment. Un taux élevé peut signaler des problèmes dans la stratégie de recouvrement ou une dégradation de la situation financière des clients.
Où trouver ces données
Il s’agit d’un événement déduit ou calculé. Il est déterminé en comparant la date promise (dans UDM_P2P_ATTR) à la date de compensation effective de la facture. Si aucun paiement n’est reçu à la date promise, la promesse est considérée comme non tenue.
Données à recueillir
Comparez la date promise dans UDM_P2P_ATTR à la date de compensation de la facture. Si la compensation intervient après la date promise, la promesse n’a pas été tenue.
Type d’événement
calculated
|
|||
Guides d’extraction
Prêt à démarrer ?
Utilisez ce modèle pour préparer vos données et commencer à analyser votre processus de gestion du crédit et du recouvrement. Optimisez-le dès aujourd’hui afin d’accélérer les encaissements et de réduire les risques.
Accélérez vos encaissements : optimisez dès maintenant la gestion du crédit et du recouvrement
Réduisez de 30 % le temps de cycle entre le crédit et l’encaissement, et améliorez votre rentabilité.
Aucune carte bancaire requise. Configuration en quelques minutes.