Votre modèle de données pour la gestion du crédit et le recouvrement

SAP ECC
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

Ce modèle présente clairement les attributs de données et les activités indispensables à l’analyse de votre processus de gestion du crédit et de recouvrement. Il contient également des conseils pratiques pour extraire ces informations de votre système SAP ECC. Appuyez-vous sur cette ressource pour préparer une collecte de données précise et efficace.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Conseils d’extraction pour SAP ECC
Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Attributs de gestion du crédit et de recouvrement

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail la gestion du crédit et le recouvrement dans SAP ECC.
3 Obligatoire 8 Recommandé 10 Facultatif
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
Obligatoire Recommandé Facultatif

Activités de gestion du crédit et de recouvrement

Voici les principales étapes et les jalons du processus à consigner dans votre journal d’événements pour découvrir le processus avec précision et repérer les goulots d’étranglement.
5 Recommandé 9 Facultatif
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
Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de SAP ECC

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

Démarrez l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.