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
- Directives d'extraction pour SAP ECC
Attributs de gestion du crédit et de recouvrement
| Nom | Description | ||
|---|---|---|---|
|
Heure de l'événement
EventTime
|
L'horodatage indiquant quand une activité ou un événement spécifique s'est produit. | ||
|
Description
L'Heure de l'événement enregistre la date et l'heure précises de chaque activité du processus. C'est l'épine dorsale chronologique du journal d'événements, permettant l'ordonnancement des activités et le calcul des durées entre elles. En analyse, cet horodatage est fondamental pour calculer tous les KPI basés sur le temps, tels que le temps de cycle de résolution des litiges, la latence d'enregistrement des paiements et les jours moyens entre la date d'échéance et le paiement. Il permet la découverte des goulots d'étranglement en mettant en évidence les longs temps d'attente entre les étapes consécutives.
Pourquoi c'est important
Cet attribut est essentiel pour séquencer correctement les événements et calculer toutes les métriques de performance liées au temps, telles que les temps de cycle et les durées.
Où obtenir
Provenant de divers champs de date et d'heure dans les tables SAP, tels que BUDAT (Date de comptabilisation) ou CPUDT/CPUTM (Date/Heure de saisie du document) dans BKPF, ou des tables spécifiques aux événements.
Exemples
2023-01-15T09:30:00Z2023-02-10T14:00:00Z2023-02-28T11:25:10Z
|
|||
|
Nom de l'activité
ActivityName
|
Le nom de l'activité commerciale ou de l'événement qui s'est produit à un point spécifique du cycle de vie de la facture. | ||
|
Description
Cet attribut décrit une étape ou un événement spécifique au sein du processus de gestion du crédit et des encaissements, tel que 'Facture enregistrée', 'Cycle de relance exécuté' ou 'Document de paiement entrant enregistré'. Ces activités constituent les nœuds de la cartographie des processus. En analysant la séquence, la fréquence et la durée entre ces activités, les entreprises peuvent visualiser leur flux de processus réel, identifier les écarts par rapport aux procédures standard et localiser les goulots d'étranglement. Par exemple, l'analyse du chemin après 'Cycle de relance exécuté' peut révéler l'efficacité de la stratégie de relance.
Pourquoi c'est important
Les activités sont les éléments constitutifs de la cartographie des processus, permettant la visualisation et l'analyse du flux de processus, des variantes et des exceptions.
Où obtenir
C'est un attribut dérivé, typiquement construit en mappant les codes de transaction (TCODE), les types de document (BLART) ou les changements de champs spécifiques de diverses tables SAP (par ex. BKPF, BSID, MHNK, UDM_CASE) à des noms d'activité conviviaux.
Exemples
Facture comptabiliséeLancement de relance exécutéPromesse de paiement crééeDocument de paiement entrant enregistréFacture apurée
|
|||
|
Numéro de facture
InvoiceNumber
|
L'identifiant unique de la facture client, qui sert d'identifiant de cas principal pour le processus de gestion du crédit. | ||
|
Description
Le numéro de facture, connu sous le nom de Belegnummer (BELNR) dans SAP, identifie de manière unique chaque document de créances clients. En process mining, ce numéro est crucial car il relie toutes les activités connexes, de la comptabilisation et de la relance au paiement ou à la radiation éventuelle, en un seul cas cohérent. L'analyse du processus avec le numéro de facture comme identifiant de cas permet une vue complète du cycle de vie de la facture. Cela aide à suivre les métriques clés comme les Jours de vente en suspens (DSO), à identifier les goulots d'étranglement dans le processus de recouvrement et à comprendre l'efficacité des différentes stratégies de recouvrement pour des factures spécifiques.
Pourquoi c'est important
C'est la clé essentielle qui relie chaque événement du parcours d'une facture, rendant possible le traçage et l'analyse du processus crédit-cash de bout en bout.
Où obtenir
Trouvé dans diverses tables de comptabilité financière dans SAP ECC, principalement dans BKPF (En-tête de Document Comptable) et BSEG (Segment de Document Comptable) en tant que champ BELNR.
Exemples
190000000119000000451900000102
|
|||
|
Agent de recouvrement
Sachp
|
Le comptable ou l'agent de recouvrement affecté au compte client. | ||
|
Description
Cet attribut identifie la personne ou le groupe responsable de la gestion des recouvrements pour un compte client spécifique. Dans SAP, il s'agit souvent du Comptable (SACHP) défini dans la fiche client. Cette dimension est cruciale pour la gestion de la performance au sein de l'équipe de recouvrement. Elle permet de créer des tableaux de bord comme 'Aperçu de l'ancienneté des factures' filtrés par agent de recouvrement, aidant à gérer les charges de travail et à comparer l'efficacité des différents agents ou équipes. Elle répond aux questions sur les agents de recouvrement les plus efficaces pour résoudre les factures en souffrance.
Pourquoi c'est important
Permet l'analyse des performances et la gestion de la charge de travail de l'équipe de recouvrement en attribuant les cas et les résultats à des individus ou des groupes spécifiques.
Où obtenir
Typiquement trouvé dans les données du code société maître client (table KNB1, champ SACHP).
Exemples
J. SmithÉquipe AINTL-COLL
|
|||
|
Date d'échéance
NetDueDate
|
La date à laquelle le paiement de la facture est contractuellement dû. | ||
|
Description
La date d'échéance est la date limite à laquelle un client est censé payer une facture. Elle est calculée en fonction 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. C'est la référence par rapport à laquelle la ponctualité est mesurée. Elle est utilisée pour calculer des KPI comme les 'Jours moyens entre la date d'échéance et le paiement' et pour déclencher les activités de recouvrement lorsqu'elle est dépassée. L'analyse des retards par rapport à cette date est une activité principale de l'analyse des encaissements.
Pourquoi c'est important
C'est la référence principale pour mesurer la ponctualité des paiements et est essentielle pour calculer les jours de retard et les KPI connexes.
Où obtenir
Cette date est souvent directement disponible dans les tables de postes clients comme BSID sous 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
|
Le nombre de jours calculé depuis que la date d'échéance d'une facture est dépassée. | ||
|
Description
Cette métrique calcule le nombre de jours entre la date d'échéance de paiement d'une facture et la date à laquelle elle a été compensée. Pour les factures ouvertes, elle est calculée en fonction de la date actuelle. Les Jours de retard sont une métrique fondamentale pour toutes les analyses des créances clients. C'est la mesure principale du tableau de bord 'Aperçu de l'ancienneté des factures' et est utilisée pour prioriser les activités de recouvrement. L'analyse des tendances de cette métrique au niveau agrégé peut indiquer la santé globale des créances d'une entreprise.
Pourquoi c'est important
C'est une métrique de performance essentielle qui quantifie directement les retards de paiement et est utilisée pour prioriser les efforts de recouvrement et mesurer la santé du processus.
Où obtenir
Attribut calculé. La logique est : (Date de compensation ou Date actuelle) - Date d'échéance nette.
Exemples
0153295
|
|||
|
Montant de la facture
Dmbtr
|
La valeur totale de la facture dans la devise locale. | ||
|
Description
Cet attribut représente la valeur monétaire totale de la facture. Dans SAP, il est souvent stocké dans le champ DMBTR pour le montant en devise locale. Le montant de la facture est une dimension critique pour l'analyse. Il permet de prioriser les efforts de recouvrement sur les factures de grande valeur et de comprendre s'il existe une corrélation entre la valeur de la facture et les retards de paiement ou les occurrences de litiges. Il peut être utilisé pour filtrer la cartographie des processus afin de se concentrer uniquement sur les factures au-dessus d'un certain seuil.
Pourquoi c'est important
Fournit un contexte financier au processus, permettant une analyse basée sur la valeur et la priorisation des efforts de recouvrement sur les articles de grande valeur.
Où obtenir
Champ standard DMBTR (Montant en devise locale) dans des tables comme BSEG, BSID et BSAD.
Exemples
1500.0012500.50750.25
|
|||
|
Niveau de relance
Mahns
|
Le niveau de relance (rappel) le plus élevé qui a été atteint pour la facture. | ||
|
Description
Le niveau de relance (MAHNS dans SAP) indique le nombre d'avis de rappel envoyés pour une facture en souffrance, correspondant à l'intensité de la procédure de relance. Cet attribut est essentiel pour évaluer le processus de relance. Il est utilisé directement dans le tableau de bord 'Efficacité des relances par niveau' pour mesurer le pourcentage de factures payées après l'envoi de chaque avis de relance. Cette analyse aide à affiner la stratégie de relance, par exemple, en modifiant le calendrier ou le contenu des avis aux niveaux inefficaces.
Pourquoi c'est important
Mesure directement l'intensité des efforts de recouvrement, ce qui est crucial pour analyser l'efficacité de la stratégie de relance.
Où obtenir
Trouvé sur le poste client dans la table BSID en tant que champ MAHNS. L'historique des exécutions de relance se trouve dans les tables MHNK (en-tête) et MHND (données).
Exemples
1234
|
|||
|
Nom d'utilisateur
UserName
|
L'ID utilisateur de la personne ayant exécuté l'activité. | ||
|
Description
Cet attribut identifie l'utilisateur spécifique responsable d'un événement, tel que la comptabilisation d'une facture ou la création d'un dossier de litige. Dans SAP, cela est souvent stocké dans des champs comme ERNAM (Créé par) ou USNAM. L'analyse par utilisateur aide à comprendre la répartition de la charge de travail, à identifier les besoins en formation et à détecter les problèmes de conformité potentiels. Par exemple, elle peut révéler si certains utilisateurs sont constamment associés à des déviations ou des retards de processus, ou si les meilleurs performeurs suivent une variante de processus plus efficace.
Pourquoi c'est important
Il permet d'analyser la performance humaine et le comportement au sein du processus, aidant à identifier les meilleurs performeurs, les opportunités de formation et les déséquilibres de charge de travail.
Où obtenir
Typiquement trouvé 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
|
L'identifiant unique du client. | ||
|
Description
Le numéro client (KUNNR dans SAP) est la clé unique d'un compte client. Il lie une transaction aux données de base d'un client spécifique, y compris 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 vous permet de comparer la performance des processus entre différents clients, d'identifier les payeurs chroniquement tardifs et d'analyser comment les stratégies de recouvrement diffèrent pour les comptes stratégiques par rapport aux comptes non stratégiques. Il est fondamental pour des tableaux de bord comme l'ancienneté des factures et la conformité aux conditions de paiement.
Pourquoi c'est important
Permet une analyse centrée sur le client, aidant à identifier les schémas comportementaux pour des clients ou groupes de clients spécifiques et à adapter les stratégies de recouvrement.
Où obtenir
Champ standard KUNNR dans les tables de postes clients (BSID, BSAD) et les tables d'en-tête de document (BKPF, si renseigné).
Exemples
10002050CUST-7890
|
|||
|
Segment de clientèle
CustomerSegment
|
La classification du client, par exemple, basée sur la taille, le secteur ou l'importance stratégique. | ||
|
Description
Le Segment Client est une classification utilisée pour regrouper les clients ayant des caractéristiques similaires. Ceci est souvent dérivé du Groupe de Comptes Clients (KTOKD) dans SAP ou d'autres champs personnalisés dans les données de base client. Segmenter l'analyse des processus par cet attribut fournit des insights puissants. Cela peut révéler si certains segments ont des cycles de paiement plus longs, des taux de litiges plus élevés ou répondent mieux à des activités de recouvrement spécifiques. Ces informations sont vitales pour optimiser les stratégies de recouvrement et personnaliser les interactions avec les clients.
Pourquoi c'est important
Permet une analyse ciblée pour voir comment le processus fonctionne pour différents types de clients, permettant des stratégies et une allocation des ressources sur mesure.
Où obtenir
Souvent dérivé du champ Groupe de comptes clients (KTOKD) dans la table maître client KNA1, ou d'autres champs personnalisés.
Exemples
Comptes clésPetites et Moyennes EntreprisesGouvernementInterne
|
|||
|
Catégorie de risque
Ctlpc
|
Une classification du risque de crédit du client. | ||
|
Description
La Catégorie de risque (CTLPC dans SAP) regroupe les clients en fonction de leur solvabilité et de leur historique de paiement. Cette classification est utilisée pour piloter les vérifications de crédit automatisées et pour guider les stratégies de recouvrement. L'analyse du processus par Catégorie de risque peut fournir des informations approfondies. Elle peut montrer si les clients à haut risque suivent des chemins de processus différents ou ont des cycles de paiement significativement plus longs. Cette information est précieuse pour valider la précision de la classification des risques et pour ajuster l'intensité du recouvrement en fonction du risque.
Pourquoi c'est important
Permet une analyse basée sur les risques du processus de recouvrement, aidant à valider les modèles de risque et à adapter les stratégies de recouvrement de manière appropriée.
Où obtenir
Trouvé dans les données centrales de gestion du crédit pour un client dans la table KNKK, champ CTLPC.
Exemples
001002RISQUE ÉLEVÉ
|
|||
|
Code société
Bukrs
|
L'identifiant de l'entité juridique (code société) à laquelle appartient la facture. | ||
|
Description
Le Code société (BUKRS dans SAP) représente une entité juridique indépendante pour laquelle des états financiers sont créés. C'est une unité organisationnelle fondamentale dans SAP Financials. Cet attribut est essentiel pour filtrer et comparer la performance des processus entre différentes entités juridiques au sein d'une corporation. Il permet d'analyser si les processus de recouvrement sont standardisés ou s'il existe des variations significatives de performance, par exemple, en termes de DSO ou de taux de litiges, entre les différents codes société.
Pourquoi c'est important
Permet de segmenter l'analyse des processus par entité juridique, ce qui est crucial pour les grandes organisations multinationales afin de comparer leurs performances.
Où obtenir
Champ standard BUKRS dans presque toutes les tables financières, y compris BKPF, BSEG, BSID et BSAD.
Exemples
10002000US01
|
|||
|
Conditions de paiement
Zterm
|
Le code des conditions de paiement convenues avec le client. | ||
|
Description
Le code des conditions de paiement (ZTERM dans SAP) définit les conditions de paiement, telles que la date d'échéance et les éventuelles remises pour paiement anticipé. Ceci est généralement défini dans les données de base clients et copié sur les factures. L'analyse par conditions de paiement aide à comprendre comment différentes conditions impactent le comportement de paiement. Le tableau de bord 'Conformité et impact des conditions de paiement', par exemple, visualise comment l'adhésion aux conditions varie et son effet sur les jours de retard. Cela peut éclairer les décisions concernant les conditions de paiement à offrir aux différents segments de clientèle.
Pourquoi c'est important
Explique l'accord contractuel de paiement et aide à analyser si certaines conditions conduisent à une meilleure performance de paiement ou à plus de litiges.
Où obtenir
Champ standard ZTERM, trouvé dans les données de base clients (KNB1) et les tables de documents financiers (BSEG).
Exemples
0001NT30ZD60
|
|||
|
Dernière actualisation des données
LastDataRefreshTimestamp
|
L'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 offre une transparence aux utilisateurs professionnels sur la fraîcheur des données qu'ils analysent. Lors de l'examen des tableaux de bord et des analyses, cet horodatage aide les utilisateurs à comprendre si les données incluent les toutes dernières transactions ou s'il existe un décalage connu. C'est un élément critique de métadonnées pour établir la confiance dans les résultats analytiques.
Pourquoi c'est important
Informe les utilisateurs de l'actualité des données, ce qui est crucial pour prendre des décisions basées sur les informations de processus les plus récentes disponibles.
Où obtenir
Cette valeur est générée et stockée par le pipeline d'extraction et de chargement de données (ETL) lorsque les données sont actualisées.
Exemples
2023-03-01T02:00:00Z2023-03-02T02:00:00Z2023-03-03T02:00:00Z
|
|||
|
Document de Compensation
Augbl
|
Le numéro du document qui a compensé la facture, généralement un paiement ou un avoir. | ||
|
Description
Le numéro de document de compensation (AUGBL dans SAP) lie un poste non soldé, comme une facture, au document qui l'a réglée. Lorsqu'une facture est payée, le numéro du document de paiement est enregistré comme document de compensation pour cette facture. Ce champ est techniquement crucial pour confirmer qu'une facture a été compensée et pour la lier à l'événement de paiement ou d'avoir spécifique. Il constitue la base pour identifier l'activité 'Facture compensée' et pour garantir que le processus de bout en bout est correctement capturé.
Pourquoi c'est important
Fournit le lien explicite entre une facture et son document de règlement, ce qui est essentiel pour modéliser avec précision les événements de compensation.
Où obtenir
Champ standard AUGBL dans les tables de postes clients BSID (vide tant que le poste est ouvert) et BSAD (renseigné après compensation).
Exemples
140000000114000000551400000120
|
|||
|
Est radiée
IsWrittenOff
|
Un indicateur booléen qui précise si la facture a finalement été passée en pertes comme créance irrécouvrable. | ||
|
Description
Il s'agit d'un indicateur dérivé, typiquement défini à vrai si une facture est compensée à l'aide d'un code motif ou d'un type de document spécifique qui signifie une radiation. Il identifie les cas qui représentent une perte financière. Cet attribut est essentiel pour calculer le KPI 'Taux de radiation de créances irrécouvrables' et pour les tableaux de bord connexes. Il permet une analyse des causes profondes pour comprendre les caractéristiques des factures et des clients qui sont fréquemment radiés, ce qui peut aider à améliorer les politiques de crédit et l'efficacité du recouvrement.
Pourquoi c'est important
Identifie les résultats de processus qui entraînent des pertes financières, permettant d'analyser les causes profondes des créances irrécouvrables et d'améliorer la politique de crédit.
Où obtenir
C'est un attribut dérivé. La logique est typiquement basée sur l'identification de codes motif de compensation spécifiques (BSEG-RSTGR) ou de types de document (BKPF-BLART) utilisés pour les radiations.
Exemples
truefaux
|
|||
|
ID du cas de litige
DisputeCaseId
|
L'identifiant unique d'un dossier de litige lié à la facture. | ||
|
Description
Lorsqu'un client conteste une facture, un dossier de litige formel peut être créé dans le module de gestion des litiges de SAP. Cet identifiant unique permet d'identifier ce dossier. Disposer de cet identifiant permet une analyse détaillée du processus de résolution des litiges. Il est essentiel pour calculer le KPI 'Temps de cycle de résolution des litiges' et pour comprendre pourquoi les litiges sont créés, comment ils sont gérés et quels en sont les résultats courants. Cela aide à isoler le sous-processus des litiges du flux de recouvrement standard.
Pourquoi c'est important
Lie les activités de recouvrement aux dossiers de litiges formels, permettant une analyse ciblée de l'efficacité du processus de résolution des litiges et de leurs causes profondes.
Où obtenir
Trouvé dans les tables de SAP Dispute Management, telles que UDM_CASE_ATTR00. Nécessite l'utilisation du module SAP Dispute Management.
Exemples
400000000021400000000157400000000305
|
|||
|
ID du système source
SourceSystemId
|
L'identifiant du système source d'où les données ont été extraites. | ||
|
Description
Cet attribut spécifie le système d'origine, par exemple, l'instance SAP ECC spécifique comme 'ECCPRD100'. C'est important dans les environnements avec plusieurs systèmes ERP ou lors de l'intégration de données provenant de différentes sources. Il permet de filtrer et de comparer les processus entre différents systèmes ou régions. Cela assure la clarté de la lignée des données et aide à résoudre les problèmes d'extraction de données.
Pourquoi c'est important
Fournit un contexte crucial sur l'origine des données, en particulier dans les paysages informatiques complexes, assurant la traçabilité des données et permettant une analyse spécifique au système.
Où obtenir
Typiquement ajouté pendant le processus d'extraction de 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
|
Le montant total de la limite de crédit attribuée au client. | ||
|
Description
La Limite de crédit (KLIMK dans SAP) est le montant maximal de crédit accordé à un compte client. C'est un élément clé de la gestion du risque de crédit. Cet attribut est essentiel pour le tableau de bord 'Précision de la limite de crédit vs créances irrécouvrables'. En analysant la relation entre la limite de crédit attribuée et l'occurrence des radiations, une entreprise peut évaluer l'efficacité de ses politiques de crédit. Il prend également en charge des KPI comme le 'Taux de révision de la limite de crédit' pour vérifier si les évaluations initiales sont précises.
Pourquoi c'est important
Fournit un contexte sur le risque de crédit, permettant d'analyser si les politiques de crédit sont efficaces pour prévenir les créances irrécouvrables sans freiner les ventes.
Où obtenir
Trouvé dans les données centrales de gestion du crédit pour un client dans la table KNKK, champ KLIMK.
Exemples
10000.0050000.00250000.00
|
|||
|
Type de document
Blart
|
Le type de document financier, tel qu'une facture, un avoir ou un paiement. | ||
|
Description
Le Type de document (BLART dans SAP) classe les documents comptables. Par exemple, 'RV' pourrait être une facture client, 'DZ' un paiement client, et 'DG' un avoir. Bien que les activités soient dérivées pour le process mining, le type de document original fournit un contexte important et peut être utilisé pour la vérification ou pour une analyse financière plus détaillée. Il aide à comprendre la nature des transactions traitées et peut être utilisé pour filtrer l'analyse afin de se concentrer uniquement sur des types spécifiques de documents, comme les factures client.
Pourquoi c'est important
Fournit un contexte financier en classifiant les transactions, ce qui peut être utilisé pour filtrer l'analyse ou pour valider les noms d'activité dérivés.
Où obtenir
Champ standard BLART dans la table d'en-tête de document BKPF.
Exemples
RVDZDGAB
|
|||
Activités de gestion du crédit et de recouvrement
| Activité | Description | ||
|---|---|---|---|
|
Date d'échéance du paiement dépassée
|
Un événement calculé qui indique que la facture est officiellement en retard de paiement. Ce n'est pas un événement système explicite, mais il est dérivé en comparant la date d'échéance nette de la facture avec la date actuelle ou l'horodatage d'une activité ultérieure. | ||
|
Pourquoi c'est important
Cet événement marque la transition de la facturation standard au processus de recouvrement. C'est le déclencheur pour le calcul des jours de retard et l'initiation des procédures de relance, formant la base des rapports de vieillissement.
Où obtenir
Il s'agit d'un événement calculé. Il est dérivé en comparant la date d'échéance nette (BSID-NETDT) du poste de ligne de facture ouvert avec la date système ou l'horodatage d'un autre événement.
Capture
Calculé en comparant la date d'échéance nette de la facture (BSID-NETDT) à une chronologie.
Type d'événement
calculated
|
|||
|
Facture apurée
|
Cet événement marque la clôture réussie d'une facture, typiquement après réception et application du paiement intégral. Il est déduit lorsque le poste de ligne de facture passe de la table des postes non soldés (BSID) à la table des postes compensés (BSAD). | ||
|
Pourquoi c'est important
C'est l'événement de fin "positif" principal pour le processus. Le temps nécessaire pour atteindre cette activité est une composante essentielle du DSO. L'analyse des chemins qui mènent ici aide à identifier les meilleures pratiques.
Où obtenir
Il s'agit d'un événement inféré. La compensation est identifiée par la présence d'un document de compensation (AUGBL) et d'une date de compensation (AUGDT) pour le poste de ligne de facture, qui se trouve dans la table des postes compensés BSAD.
Capture
Utilisez la date de lettrage (BSAD-AUGDT) pour le poste de facture spécifique comme horodatage d'événement.
Type d'événement
inferred
|
|||
|
Facture comptabilisée
|
Représente la création d'un document de facture client dans le module de comptabilité financière. Cet événement est explicitement capturé lorsqu'un document de facturation des ventes et distribution (SD) est transféré à la comptabilité ou qu'une facture FI est saisie directement, créant des écritures dans les tables BKPF et BSEG. | ||
|
Pourquoi c'est important
C'est l'événement de début principal pour le cycle de vie de la facture. L'analyse du temps écoulé entre ce point et le paiement est cruciale pour mesurer les Jours de vente en suspens (DSO) et l'efficacité globale du processus.
Où obtenir
Il s'agit d'un événement explicite enregistré lors de la création d'un document financier. L'horodatage de l'événement peut être récupéré de la table d'en-tête de document BKPF (champ CPUDT ou BKTXT) pour le numéro de document de facture correspondant (BELNR).
Capture
Identifier les événements de création pour les documents FI avec des types de document pertinents (par ex. 'RV', 'DR') dans la table BKPF.
Type d'événement
explicit
|
|||
|
Facture passée en perte
|
Représente la décision d'absorber une facture impayée comme une perte, la classant comme créance irrécouvrable. Ceci est capturé par une écriture financière spécifique qui compense la facture originale et transfère le montant vers un compte de créances irrécouvrables. | ||
|
Pourquoi c'est important
C'est l'événement de fin "négatif" principal, signifiant un échec dans le processus de crédit ou de recouvrement et une perte financière directe. L'analyse de ces cas est critique pour améliorer les politiques de crédit et les stratégies de recouvrement.
Où obtenir
Il s'agit typiquement d'une écriture explicite ou d'un événement inféré basé sur la transaction de compensation. La compensation est effectuée à l'aide d'un code de transaction et d'un code motif spécifiques qui indiquent une radiation. Le document de compensation peut être analysé pour confirmer la radiation.
Capture
Identifier les documents de compensation où un code motif spécifique (BSEG-RSTGR) est utilisé pour les radiations, ou lorsque l'écriture de contrepartie est portée à un compte de charge de créances irrécouvrables.
Type d'événement
inferred
|
|||
|
Lancement de relance exécuté
|
Cette activité représente l'exécution du programme de relance automatique pour une facture en souffrance. Le système enregistre le niveau de relance, la date et d'autres détails pour chaque facture incluse dans un cycle de relance. | ||
|
Pourquoi c'est important
Le suivi des activités de relance est essentiel pour évaluer l'efficacité de la stratégie de recouvrement. Il aide à déterminer quels niveaux de relance sont les plus efficaces pour inciter au paiement et identifie les clients non réactifs.
Où obtenir
Il s'agit d'un événement explicite. Les détails des cycles de relance sont stockés dans les tables de données de relance, principalement MHNK (données de relance) qui contient la date d'exécution (LAUFD) et le niveau de relance (MAHNS) pour chaque facture relancée.
Capture
Extrayez les enregistrements de la table MHNK, en liant le code d'entreprise, le compte et la date de relance.
Type d'événement
explicit
|
|||
|
Avoir comptabilisé
|
Représente la création d'un document d'avoir sur un compte client, souvent pour corriger une erreur de facturation ou résoudre un litige. Ce document est explicitement créé dans le module FI. | ||
|
Pourquoi c'est important
Les notes de crédit sont une conséquence directe des défaillances de processus en amont, telles que des erreurs de prix ou d'expédition. L'analyse de leur fréquence et de leurs causes profondes est vitale pour l'amélioration des processus et la réduction des pertes de revenus.
Où obtenir
Il s'agit d'un événement explicite capturé lors de la création d'un document financier avec un type de document d'avoir (par ex. 'DG'). L'horodatage de l'événement peut être récupéré de la table d'en-tête de document BKPF.
Capture
Identifier les événements de création pour les documents FI avec des types de document d'avoir (par ex. 'DG', 'G2') dans la table BKPF.
Type d'événement
explicit
|
|||
|
Cas de litige créé
|
Représente l'enregistrement formel d'un litige client lié à une facture, tel qu'un écart de prix ou de quantité. Il s'agit d'un événement explicite enregistré dans le module de gestion des litiges SAP FSCM. | ||
|
Pourquoi c'est important
Les litiges bloquent le processus de paiement et nécessitent des ressources internes pour être résolus. Le suivi de la création des litiges est la première étape de l'analyse du temps de résolution, des causes profondes et de leur impact sur le DSO.
Où obtenir
Si la gestion des litiges SAP FSCM est utilisée, il s'agit d'un événement explicite. La création d'un dossier de litige est enregistrée dans des tables telles que UDM_CASE ou SCMG_T_CASE_ATTR, avec un horodatage de création.
Capture
Extrayez la date et l'heure de création des tables de gestion des cas (par exemple, UDM_CASE) pour les cas liés à la facture.
Type d'événement
explicit
|
|||
|
Cas de Litige Résolu
|
Le litige associé à la facture a été examiné et une résolution a été trouvée. Ceci est généralement capturé par un changement de statut sur le dossier de litige dans la gestion des litiges SAP FSCM. | ||
|
Pourquoi c'est important
La résolution d'un litige débloque le processus de paiement. Mesurer le temps entre la création et la résolution d'un litige est un KPI clé pour identifier les inefficacités dans le processus de traitement des litiges.
Où obtenir
Il s'agit d'un événement inféré à partir d'un changement de statut dans le dossier de litige. Les journaux de modifications (CDHDR/CDPOS) pour le champ de statut du dossier de litige dans des tables comme UDM_CASE fournissent l'horodatage.
Capture
Identifier l'horodatage lorsque le statut du dossier de litige passe à 'Fermé' ou 'Résolu' en analysant les journaux de modifications.
Type d'événement
inferred
|
|||
|
Contact de Recouvrement Enregistré
|
Un agent de recouvrement a contacté le client concernant une facture en retard, par exemple, par téléphone ou par e-mail. Cette activité est généralement enregistrée manuellement par le collecteur dans le système. | ||
|
Pourquoi c'est important
Cette activité mesure l'effort manuel de l'équipe de recouvrement. L'analyse de la fréquence et du calendrier des contacts par rapport aux paiements ultérieurs aide à déterminer l'efficacité des actions des agents de recouvrement.
Où obtenir
Si la gestion des encaissements SAP FSCM est utilisée, cela est enregistré comme un 'Contact client'. Les détails sont stockés dans des tables liées à la liste de travail des recouvrements et à l'historique des contacts, souvent liées à UDM_CASE.
Capture
Extrayez les journaux de contacts clients des tables pertinentes de la Gestion des Recouvrements FSCM.
Type d'événement
explicit
|
|||
|
Document de paiement entrant enregistré
|
Représente l'enregistrement initial d'un paiement d'un client dans le système, souvent avant qu'il ne soit appliqué à des factures spécifiques. Il s'agit d'un événement explicite créant un document de paiement, par exemple un document de type DZ. | ||
|
Pourquoi c'est important
Cela marque la réception des liquidités. Le décalage temporel entre cet événement et l'événement final 'Facture compensée' représente le processus d'application de trésorerie, qui peut être un goulot d'étranglement significatif.
Où obtenir
Il s'agit d'un événement explicite. Il est capturé à partir de la création d'un document de paiement dans la table BKPF, identifiable par des types de document spécifiques (par ex. 'DZ'). La date de comptabilisation (BKPF-BUDAT) sert d'horodatage.
Capture
Identifier la création de documents avec des types de document liés au paiement (par ex. 'DZ') dans la table BKPF.
Type d'événement
explicit
|
|||
|
Facture bloquée pour paiement
|
Indique qu'un blocage manuel ou automatique a été placé sur la facture, l'empêchant d'être payée. Ceci est capturé par un indicateur de blocage de paiement spécifique défini sur le poste de ligne de facture dans la table BSEG. | ||
|
Pourquoi c'est important
Les blocages de paiement sont une source majeure de retards et d'exceptions de processus. Identifier quand et pourquoi les factures sont bloquées est essentiel pour découvrir les causes profondes des paiements tardifs et améliorer le flux de trésorerie.
Où obtenir
Ce statut est typiquement inféré d'un changement dans le champ Blocage de paiement (BSEG-ZLSPR) sur le poste de ligne de facture. Les journaux de modifications pour ce champ (tables CDHDR et CDPOS) peuvent fournir des horodatages explicites.
Capture
Détectez les modifications du champ BSEG-ZLSPR pour le poste de document de facture, en utilisant la table CDHDR pour les horodatages.
Type d'événement
inferred
|
|||
|
Poste résiduel créé
|
Se produit lors de l'application d'un paiement lorsqu'un client sous-paie une facture, et le petit solde restant est enregistré comme une nouvelle position ouverte. Ceci est déduit des détails de la transaction de compensation. | ||
|
Pourquoi c'est important
Les postes résiduels indiquent des écarts de paiement et génèrent un travail supplémentaire. Leur suivi aide à identifier les clients qui sous-paient fréquemment et met en évidence les problèmes de tarification ou de facturation qui entraînent des litiges.
Où obtenir
Il s'agit d'un événement inféré. Lorsqu'une transaction de compensation (par ex. via F-28) compense une facture originale mais enregistre également un nouveau document de poste non soldé pour le montant restant, un poste résiduel est créé. Cela peut être identifié en vérifiant les postes de ligne du document de compensation.
Capture
Analysez les documents de compensation (BKPF-AUGBL) pour trouver les cas où un nouvel élément ouvert est créé avec une référence à la facture originale.
Type d'événement
inferred
|
|||
|
Promesse de paiement créée
|
Un client a contacté le service de recouvrement et a promis d'effectuer un paiement à une date spécifique. Cet événement est explicitement enregistré si la gestion des recouvrements SAP FSCM est utilisée. | ||
|
Pourquoi c'est important
Les promesses de paiement sont un résultat clé des activités de recouvrement. L'analyse de leurs taux de création, de réalisation et de rupture aide à mesurer l'efficacité des actions des agents de recouvrement et à prévoir les flux de trésorerie.
Où obtenir
Si la gestion des encaissements SAP FSCM est utilisée, il s'agit d'un événement explicite. Les détails de la promesse de paiement sont stockés dans des tables comme UDM_P2P_ATTR, liées au partenaire commercial et à la facture.
Capture
Extrayez l'horodatage de création des tables de promesses de paiement comme UDM_P2P_ATTR dans SAP FSCM.
Type d'événement
explicit
|
|||
|
Promesse de paiement non respectée
|
Un événement calculé indiquant qu'un client n'a pas effectué un paiement à la date convenue dans une 'Promesse de paiement'. Cela est déduit de l'absence d'un paiement correspondant à la date de la promesse. | ||
|
Pourquoi c'est important
L'identification des promesses non tenues est cruciale pour intensifier les efforts de recouvrement. Un taux élevé de promesses non respectées peut signaler des problèmes avec la stratégie de recouvrement ou la santé financière du client.
Où obtenir
Il s'agit d'un événement inféré ou calculé. Il est déterminé en comparant la date de promesse (provenant de UDM_P2P_ATTR) avec la date réelle de compensation du paiement pour la facture. Si aucun paiement n'est reçu à la date de promesse, la promesse est considérée comme non tenue.
Capture
Comparez la date de promesse dans UDM_P2P_ATTR avec la date de compensation de la facture. Si la date de compensation est postérieure à la date de promesse, la promesse a été rompue.
Type d'événement
calculated
|
|||