Votre modèle de données Order to Cash - Facturation et émission des factures
Votre modèle de données Order to Cash - Facturation et émission des factures
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction pour SAP S/4HANA
Attributs du processus Order to Cash - Facturation et émission des factures
| Nom | Description | ||
|---|---|---|---|
| Numéro de facture InvoiceNumber | Identifiant unique d’un document de facturation, utilisé comme identifiant principal du dossier dans le processus de facturation. | ||
| Description Le numéro de facture, appelé numéro de document de facturation dans SAP, identifie de manière unique chaque transaction de facturation. Il constitue la clé centrale reliant toutes les activités associées, de la création et de la comptabilisation de la facture à la réception et au rapprochement du paiement. Dans le Process Mining, cet attribut est essentiel pour corréler les dossiers. Tous les événements associés au même numéro de facture sont regroupés dans une même instance de processus, ce qui permet d’analyser de bout en bout le cycle de facturation de chaque facture. Vous pouvez ainsi suivre les temps de cycle, repérer les écarts et analyser le parcours de chaque facture. Pourquoi c’est important Il s’agit de l’identifiant fondamental qui relie toutes les activités de facturation associées au sein d’un même dossier et rend possible l’analyse du processus de bout en bout. Où les obtenir Table SAP : VBRK, champ : VBELN Exemples 900012349000567890009012 | |||
| Heure de l’événement EventTime | Horodatage précis indiquant le moment où une activité ou un événement s’est produit. | ||
| Description L’heure de l’événement fournit la date et l’heure de chaque activité et constitue la structure chronologique du processus. Cet horodatage est essentiel pour calculer les durées, les temps de cycle et les temps d’attente entre les différentes étapes du processus de facturation. Dans l’analyse, l’heure de l’événement sert à ordonner les activités, à calculer des indicateurs clés de performance tels que le délai moyen de recouvrement et le temps de cycle de génération des factures, ainsi qu’à identifier les goulots d’étranglement liés au temps. Elle offre une vision dynamique du processus, en montrant l’évolution des performances et la durée de chaque étape du cycle de facturation. Pourquoi c’est important Il fournit la séquence chronologique des événements, indispensable au calcul de toutes les métriques temporelles, notamment les temps de cycle et les durées. Où les obtenir Extrait de différents champs de date et d’heure selon l’activité, tels que la date et l’heure de création (VBRK-ERDAT, VBRK-ERZET), les horodatages de modification (CDHDR-UDATE, CDHDR-UTIME) ou la date de comptabilisation (BKPF-BUDAT). Exemples 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Nom de l’activité ActivityName | Nom de l’activité métier ou de l’événement survenu dans le processus de facturation, par exemple « Facture générée » ou « Paiement reçu ». | ||
| Description Le nom de l’activité décrit une étape ou un jalon précis du cycle de facturation. Ces activités sont dérivées de différents éléments de données SAP, tels que les codes de transaction, les changements de statut des documents ou certaines entrées de journal, afin de reconstituer un flux de processus séquentiel. L’analyse de la séquence et de la fréquence de ces activités constitue le cœur du Process Mining. Elle permet de visualiser la cartographie du processus, de découvrir les variantes fréquentes et rares, d’identifier les goulots d’étranglement entre les étapes et de mesurer la fréquence des activités sans valeur ajoutée, comme les reprises ou les annulations. Pourquoi c’est important Cet attribut définit les étapes du processus et permet de visualiser les cartographies de processus ainsi que d’analyser le flux, les variations et les goulots d’étranglement. Où les obtenir Est dérivé de différentes sources, notamment des codes de transaction (SY-TCODE), des statuts des documents de modification (tables CDHDR/CDPOS) ou des journaux des flux de travail métier, par exemple SWW_WI2OBJ. Exemples Facture généréeFacture comptabiliséePaiement client reçuFacture annulée | |||
| Date d’échéance du paiement PaymentDueDate | Date à laquelle le client est censé avoir payé la facture. | ||
| Description La date d’échéance du paiement est calculée à partir de la date de facture et des conditions de paiement convenues. Elle correspond à la date limite de réception du paiement avant que la facture ne soit considérée comme échue. Cet attribut est essentiel pour suivre l’efficacité du recouvrement et prévoir la trésorerie. Il intervient directement dans le calcul du KPI de taux de paiement à temps et dans la segmentation des factures des rapports d’ancienneté. L’analyse des écarts entre la date d’échéance et la date réelle de paiement permet d’évaluer l’efficacité des différentes conditions de paiement. Pourquoi c’est important Il fixe la date limite de paiement du client et joue donc un rôle essentiel dans le calcul des taux de paiement à temps et la gestion des créances clients. Où les obtenir Cette date n’est pas stockée directement. Elle est calculée à partir de la date de facture (VBRK-FKDAT) et de la clé des conditions de paiement (VBRK-ZTERM), à l’aide des fonctions standard de détermination des dates de SAP. Exemples 2023-04-192023-05-012023-06-17 | |||
| Date de facture InvoiceDate | Date officielle à laquelle la facture a été émise au client. | ||
| Description La date de facture, également appelée date de facturation dans SAP, sert de point de départ à de nombreux calculs financiers. C’est à partir de cette date que sont déterminés les conditions de paiement, les dates d’échéance et l’ancienneté de la créance. Cette date est un attribut essentiel au niveau du dossier pour l’analyse financière. Elle sert de référence au calcul du KPI de délai moyen de recouvrement et à la création de rapports d’ancienneté des factures impayées, indispensables à la gestion de la trésorerie et du recouvrement. Pourquoi c’est important Il s’agit de la date de référence des calculs financiers, qui sert de point de départ au délai moyen de recouvrement, aux dates d’échéance et à l’analyse de l’ancienneté des factures. Où les obtenir Table SAP : VBRK, champ : FKDAT Exemples 2023-03-202023-04-012023-05-18 | |||
| Heure de fin EndTime | Horodatage précis indiquant le moment où une activité ou un événement a été terminé. | ||
| Description L’heure de fin marque l’achèvement d’une activité. Dans le Process Mining, elle est souvent déduite de l’heure de début de l’activité suivante dans le dossier, ou extraite directement si le système journalise les événements de début et de fin. Cet attribut est essentiel au calcul du temps de traitement des activités individuelles. En soustrayant l’heure de début de l’heure de fin, il est possible de mesurer la durée de chaque étape, ce qui est indispensable à l’analyse des goulots d’étranglement, notamment pour repérer les retards lors de l’approbation des factures. Pourquoi c’est important Il permet de calculer la durée exacte, c’est-à-dire le temps de traitement, de chaque activité, un élément fondamental de l’analyse des goulots d’étranglement. Où les obtenir Il s’agit d’un attribut dérivé pour le Process Mining. Il est généralement calculé comme le StartTime de l’événement suivant dans la séquence du dossier. Dans certains cas, des tables spécifiques peuvent enregistrer les heures d’achèvement. Exemples 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Montant de la facture InvoiceAmount | Valeur nette totale de la facture. | ||
| Description Cet attribut représente la valeur monétaire totale des biens ou services facturés, hors taxes. Il constitue une donnée financière fondamentale pour chaque dossier de facture. Le montant de la facture est utilisé dans de nombreuses analyses. Il permet de segmenter le processus selon la valeur, par exemple pour vérifier si les factures de montant élevé sont traitées différemment ou subissent davantage de retards. Il sert également de base au reporting financier et au calcul de la valeur totale des créances impayées. Pourquoi c’est important Il quantifie la valeur financière de chaque facture et permet une analyse par valeur, une priorisation du recouvrement ainsi qu’une évaluation de l’impact financier. Où les obtenir Table SAP : VBRK, champ : NETWR Exemples 1500.0025000.50125.75 | |||
| Nom d’utilisateur UserName | Identifiant de l’employé ayant exécuté l’activité. | ||
| Description Cet attribut enregistre l’identifiant utilisateur SAP responsable d’un événement donné, par exemple la création d’une facture, la comptabilisation d’un document ou le lettrage d’un paiement. Il établit le lien entre les étapes du processus et les personnes ou équipes qui les exécutent. L’analyse par nom d’utilisateur aide à repérer les collaborateurs les plus performants, les besoins de formation ou les déséquilibres dans la répartition de la charge de travail. Elle est également essentielle pour l’analyse de la conformité, car elle indique qui a réalisé les activités importantes, et pour comprendre les différences dans l’exécution d’un même processus selon les utilisateurs. Pourquoi c’est important Il relie les activités du processus à des utilisateurs précis et permet d’analyser la charge de travail, les performances et la conformité à l’échelle individuelle ou collective. Où les obtenir Pour les événements de création, cette information se trouve dans VBRK-ERNAM. Pour les modifications ultérieures, elle figure dans des tables d’historique des modifications telles que CDHDR-USERNAME ou dans les journaux des flux de travail. Exemples CBURNSHSIMPSONLLEONARD | |||
| Nom du client CustomerName | Nom du client auquel la facture a été adressée. | ||
| Description Cet attribut identifie la dénomination légale du client facturé. Il provient des données centrales de référence des clients dans SAP. L’analyse du processus par client permet d’identifier les tendances propres à certains comptes. Elle peut notamment révéler quels clients paient régulièrement en retard, lesquels soulèvent le plus de litiges ou pour lesquels le processus de facturation est le moins efficace. Ces informations permettent d’adapter la gestion de la relation client et les stratégies de recouvrement. Pourquoi c’est important Il permet une analyse centrée sur le client et aide à identifier les comportements de paiement, la fréquence des litiges et les inefficacités du processus pour certains comptes. Où les obtenir Extrait de la table des données de référence clients KNA1 (champ : NAME1), via l’identifiant du payeur dans l’en-tête de la facture (VBRK-KUNRG). Exemples Centrale électrique de SpringfieldKwik-E-MartCyberdyne Systems | |||
| Région Region | Région géographique du client. | ||
| Description L’attribut Région indique la zone géographique, par exemple un État ou une province, associée à l’adresse du client. Ces données figurent généralement dans la fiche de référence du client. Cet attribut est essentiel au Dashboard de performance régionale de la facturation. Il permet de comparer des indicateurs tels que les temps de cycle, les taux d’erreur et le délai moyen de recouvrement entre différentes régions. Cette comparaison peut mettre en évidence des écarts régionaux dans l’exécution des processus, la conformité ou l’efficacité, et orienter des améliorations ciblées ainsi que la standardisation des bonnes pratiques. Pourquoi c’est important Il permet de comparer les performances de facturation entre différentes zones géographiques, d’identifier les écarts régionaux et de standardiser les processus. Où les obtenir Extrait de la table des données de référence clients KNA1 (champ : REGIO), via l’identifiant du payeur dans l’en-tête de la facture (VBRK-KUNRG). Exemples CANYTXBA | |||
| Code société CompanyCode | Unité organisationnelle pour laquelle la transaction financière est enregistrée. | ||
| Description Le code société est une entité organisationnelle fondamentale de SAP Financials. Il représente une société juridiquement indépendante pour laquelle des états financiers sont établis. Chaque document de facturation est affecté à un code société donné. L’analyse par code société est essentielle dans les organisations comprenant plusieurs sociétés. Elle permet de comparer les performances des processus, les indicateurs financiers tels que le délai moyen de recouvrement et la conformité entre différentes entités juridiques. Elle fournit un filtre organisationnel de haut niveau pour tous les Dashboards de processus. Pourquoi c’est important Il permet de segmenter l’analyse des processus par entité juridique, de comparer les performances et de consolider les données financières à l’échelle de l’organisation. Où les obtenir Table SAP : VBRK, champ : BUKRS Exemples 10002000US01 | |||
| Conditions de paiement PaymentTerms | Code définissant les conditions de paiement, notamment le délai accordé pour régler la facture. | ||
| Description Les conditions de paiement sont des modalités prédéfinies convenues avec un client, qui déterminent la date à laquelle une facture doit être réglée. Elles peuvent par exemple être « Net 30 » (paiement sous 30 jours) ou « 2/10 Net 30 » (remise de 2 % en cas de paiement sous 10 jours, sinon paiement sous 30 jours). L’analyse par conditions de paiement permet d’en évaluer l’efficacité. En mettant en relation les différentes conditions avec le délai réel de réception du paiement, l’entreprise peut déterminer lesquelles encouragent le mieux les règlements rapides et les ajuster afin d’améliorer sa trésorerie. Pourquoi c’est important Il définit le calendrier de paiement convenu et permet d’analyser les conditions qui favorisent le mieux le règlement ponctuel des factures par les clients. Où les obtenir Table SAP : VBRK, champ : ZTERM Exemples Z030Z060ZB60 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière extraction ou actualisation des données associées à cet événement. | ||
| Description Cet attribut enregistre la date et l’heure de la dernière extraction des données depuis le système source. Il s’agit d’un champ de métadonnées essentiel pour évaluer l’actualité des données analysées. Ces informations servent à vérifier la récence de l’analyse et à gérer les calendriers d’actualisation. Elles permettent aux parties prenantes de connaître l’actualité des données lorsqu’elles prennent des décisions à partir des Dashboards et des analyses de Process Mining. Pourquoi c’est important Il indique l’actualité des données, un élément essentiel pour accorder sa confiance à l’analyse et comprendre sa pertinence au regard de la situation opérationnelle actuelle. Où les obtenir Cet horodatage est généré et ajouté à chaque enregistrement lors du processus d’extraction et de chargement des données (ETL). Exemples 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Devise Currency | Code devise du montant de la facture. | ||
| Description Cet attribut précise la devise dans laquelle les montants de la facture sont exprimés, par exemple USD, EUR ou JPY. Il fournit le contexte nécessaire à l’interprétation de toutes les valeurs monétaires. Dans une organisation internationale, la devise est indispensable à l’exactitude des analyses et du reporting financiers. Elle permet d’agréger correctement les données financières en convertissant tous les montants dans une devise de reporting commune et de comparer les performances de facturation entre des régions utilisant des devises locales différentes. Pourquoi c’est important Il fournit le contexte nécessaire à l’interprétation de toutes les valeurs monétaires et garantit l’exactitude des analyses et du reporting financiers, notamment dans les organisations internationales. Où les obtenir Table SAP : VBRK, champ : WAERK Exemples USDEURGBP | |||
| Motif de l’avoir CreditMemoReason | Code motif indiquant pourquoi un avoir a été émis. | ||
| Description Lorsqu’une facture est incorrecte et doit faire l’objet d’un avoir, un motif est généralement attribué au document d’avoir. Cela fournit une méthode structurée pour catégoriser les sources des erreurs de facturation. Cet attribut contribue directement au KPI de taux d’erreur de facturation. En regroupant et en analysant les motifs des avoirs, l’entreprise peut identifier les erreurs les plus fréquentes, comme les erreurs de prix ou les retours de produits. Cette analyse permet d’améliorer les processus afin de réduire les corrections financières et les reprises. Pourquoi c’est important Il catégorise les motifs d’émission des avoirs, ce qui aide à repérer les sources les plus fréquentes d’erreurs de facturation et à améliorer la qualité. Où les obtenir Table SAP : VBRK, champ : AUGRU (motif de commande). Ce champ est utilisé pour les demandes d’avoir ou de facture complémentaire qui sont ensuite facturées. Exemples 001 - Écart de prix002 - Qualité insuffisante005 - Retour client | |||
| Motif du litige CustomerDisputeReason | Motif indiqué par le client pour contester une facture. | ||
| Description Lorsqu’un client conteste une facture, le motif du litige est souvent enregistré. Il peut s’agir d’une erreur de prix, d’une quantité incorrecte ou de marchandises endommagées. Ces informations peuvent être stockées dans le module SAP Dispute Management ou sous forme de notes textuelles. L’analyse des motifs de litige est fondamentale pour le KPI de taux d’erreur de facturation et l’analyse associée. Elle aide à identifier les causes profondes des erreurs de facturation, afin de traiter les problèmes systémiques des processus en amont, d’améliorer la qualité des factures et de renforcer la satisfaction client. Pourquoi c’est important Il explique pourquoi les factures sont contestées et fournit une indication directe sur les causes profondes des erreurs de facturation et de l’insatisfaction client. Où les obtenir Si SAP Dispute Management est utilisé, ces informations peuvent se trouver dans des tables telles que UDM_DISPUTE. Dans le cas contraire, elles peuvent être déduites des codes motif de documents associés ou de champs textuels. Exemples Prix incorrectÉcart de quantitéMarchandises endommagées reçues | |||
| Numéro de commande client SalesOrderNumber | Identifiant de la commande client d’origine à l’origine de la facture. | ||
| Description Le numéro de commande client relie le document de facturation aux activités commerciales précédentes. Une même commande client peut donner lieu à une ou plusieurs factures, et ce lien fournit le flux documentaire complet. Cet attribut est essentiel à une analyse Order-to-Cash réellement menée de bout en bout. Il permet d’étendre la vue du processus en amont et de relier les problèmes de facturation à leurs causes potentielles lors de la création de la commande ou de son exécution. Il aide notamment à calculer le temps de cycle global de génération de la facture à partir de la livraison de la commande. Pourquoi c’est important Il relie la facture à la commande client d’origine et permet d’étendre la vision du processus Order-to-Cash au-delà de la seule facturation. Où les obtenir Table SAP : VBRP (données de poste du document de facturation), champ : AUBEL Exemples 100001231000045610000789 | |||
| Payée à temps IsPaidOnTime | Indicateur booléen précisant si la facture a été payée à sa date d’échéance ou avant celle-ci. | ||
| Description Cet attribut calculé compare la date réelle de paiement à la date d’échéance prévue. Il prend la valeur « true » si le paiement a été effectué à temps et « false » s’il a été effectué en retard. Cet indicateur simplifie le calcul et la visualisation du KPI de taux de paiement à temps. Il permet de filtrer et de segmenter facilement les factures afin d’analyser les caractéristiques de celles qui sont payées en retard par rapport à celles qui sont réglées à temps. Il peut révéler des tendances liées à certains clients, régions ou conditions de paiement qui entraînent des retards. Pourquoi c’est important Il simplifie la mesure des performances en indiquant clairement si chaque facture a été payée « à temps » ou « en retard », et contribue directement au KPI de taux de paiement à temps. Où les obtenir Il s’agit d’un champ calculé. La logique compare l’horodatage de l’activité « Paiement client reçu » à la valeur de l’attribut « PaymentDueDate ». Exemples truefalse | |||
| Statut du paiement PaymentStatus | Statut actuel du paiement de la facture, par exemple ouverte, payée ou en retard. | ||
| Description Le statut du paiement donne une vue instantanée de la position d’une facture dans le cycle de recouvrement. Il ne correspond pas à un champ unique dans SAP, mais est déduit du statut de lettrage du document comptable associé. Cet attribut est essentiel au Dashboard d’ancienneté des factures impayées. Il permet de segmenter toutes les factures ouvertes selon leur statut et leur ancienneté, afin d’aider l’équipe de recouvrement à prioriser efficacement ses actions. Le suivi des transitions entre les statuts permet également de surveiller le processus de recouvrement lui-même. Pourquoi c’est important Il fournit une vue claire et immédiate du statut de recouvrement d’une facture, indispensable à la gestion des créances et à la priorisation des actions de recouvrement. Où les obtenir Déduit du statut de lettrage du document comptable (VBRK-BELNR) dans des tables financières telles que BSID (postes ouverts) et BSAD (postes lettrés). Exemples OuvertePayéeEn retardPartiellement payée | |||
| Système source SourceSystem | Identifie le système source précis à partir duquel les données ont été extraites. | ||
| Description Cet attribut précise l’origine des données, ce qui est particulièrement utile dans les environnements comprenant plusieurs instances SAP ou d’autres systèmes intégrés. Il inclut généralement l’identifiant du système et le numéro de mandant. Dans l’analyse, il aide à distinguer les processus et les performances entre différents systèmes ou entités organisationnelles. Il garantit la traçabilité des données et fournit le contexte nécessaire, notamment lorsque des données provenant de plusieurs sources sont combinées pour obtenir une vision globale du processus. Pourquoi c’est important Il fournit un contexte essentiel sur l’origine des données, garantit leur lisibilité dans les environnements multisystèmes et contribue à la gouvernance des données. Où les obtenir Il s’agit généralement d’une valeur statique définie lors de l’extraction des données, qui combine souvent l’identifiant du système (SY-SYSID) et le mandant (SY-MANDT). Exemples S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Type de document de facturation BillingDocumentType | Code qui catégorise le document de facturation, par exemple une facture, un avoir ou une annulation. | ||
| Description Le type de document de facturation est un champ clé qui catégorise les transactions du processus de facturation. Il détermine la manière dont le document est traité, notamment sa plage de numéros et ses règles de comptabilisation. Cet attribut permet de filtrer le processus afin d’analyser certains types de transactions. Vous pouvez par exemple créer une vue distincte consacrée aux avoirs pour comprendre les motifs et le flux des corrections financières, ou analyser séparément les factures standard et les annulations afin d’obtenir une vision plus précise du processus de facturation principal. Pourquoi c’est important Il catégorise les transactions et permet de concentrer l’analyse sur des flux documentaires précis, comme les factures standard, les avoirs ou les annulations. Où les obtenir Table SAP : VBRK, champ : FKART Exemples F2G2S1L2 | |||
Activités du processus Order to Cash - Facturation et émission des factures
| Activité | Description | ||
|---|---|---|---|
| Facture clôturée | Cette activité indique l’état final d’une facture payée avec succès. Elle est fonctionnellement équivalente à « Paiement encaissé et rapproché » et indique que le processus associé à cette facture est terminé. | ||
| Pourquoi c’est important Sert d’événement de fin principal du parcours nominal. Mesurer le temps de cycle total jusqu’à cette étape donne une vision complète du cycle de facturation, de bout en bout. Où les obtenir Déduit du statut du poste client dans le document comptable. Un poste est clôturé ou « lettré » lorsque les champs de date de lettrage (BSEG-AUGDT) et de document de lettrage (BSEG-AUGBL) sont renseignés. Collecte Déduit du renseignement de la date de lettrage (AUGDT) dans la table BSEG/ACDOCA pour le poste de facture. Type d’événement inferred | |||
| Facture comptabilisée | Représente l'enregistrement réussi du document de facturation dans le module de comptabilité financière. Il s'agit d'une étape importante, car la facture devient un poste officiel de créance client et génère des écritures dans le grand livre. | ||
| Pourquoi c’est important Cette activité confirme que la facture est un document financier légal. Le délai entre sa création et son enregistrement constitue un indicateur clé de performance, qui met en évidence l'efficacité du traitement interne. Où les obtenir Cet événement est capturé lors de la création du document comptable correspondant. Le document de facturation (VBRK-VBELN) est lié au document comptable (BKPF-BELNR) via VBRK-BELNR, et la date d'enregistrement est BKPF-BUDAT. Collecte Capturé à partir de la date d'enregistrement (BUDAT) du document comptable dans la table BKPF liée au document de facturation. Type d’événement explicit | |||
| Facture générée | Cette activité correspond à la création du document de facturation dans le système. Il s'agit d'un événement explicite enregistré lorsqu'un utilisateur exécute une transaction telle que VF01 ou lorsqu'un traitement en arrière-plan crée la facture, ce qui entraîne l'ajout d'une nouvelle entrée dans la table d'en-tête du document de facturation. | ||
| Pourquoi c’est important Il s'agit de l'événement de début principal du processus de facturation. L'analyse du délai entre l'exécution de la commande et cette activité est essentielle pour mesurer le délai du cycle de création des factures et identifier les premiers retards du processus. Où les obtenir Enregistré dans la table VBRK de SAP S/4HANA (Billing Document: Header Data) lors de la création. La date de création (VBRK-ERDAT) et l'heure (VBRK-ERZET) servent d'horodatage. Collecte L'événement est capturé à partir de l'horodatage de création de l'enregistrement du document de facturation dans la table VBRK. Type d’événement explicit | |||
| Paiement client reçu | Cette activité indique l'enregistrement d'un paiement entrant d'un client dans le système financier. À ce stade, le paiement n'est pas nécessairement encore affecté à une facture précise, mais les fonds ont bien été enregistrés. | ||
| Pourquoi c’est important Il s'agit d'une étape importante pour calculer le Days Sales Outstanding (DSO). Elle signifie que les fonds ont été reçus, même si le rapprochement reste à effectuer. Où les obtenir Extrait de la date de comptabilisation (BKPF-BUDAT) du document de paiement client, généralement de type « DZ » dans la table BKPF. Collecte L’événement repose sur la création du document de paiement dans BKPF/BSEG. Type d’événement explicit | |||
| Paiement encaissé et rapproché | Représente le moment où le paiement reçu du client est rapproché et utilisé pour lettrer le poste ouvert de la facture dans le sous-grand livre clients. Cette activité clôt la transaction d’un point de vue financier. | ||
| Pourquoi c’est important Mesure l’efficacité du processus d’affectation des encaissements. Les retards à cette étape peuvent donner une image inexacte de la situation réelle des comptes clients et générer un travail inutile pour les équipes de recouvrement. Où les obtenir Cet événement est capturé à partir de la date de lettrage (BSEG-AUGDT) du poste de la facture d’origine dans le document comptable. Cette date est renseignée lorsqu’un document de lettrage solde le poste. Collecte Extrait du champ de date de lettrage (AUGDT) de la table BSEG/ACDOCA pour le poste de facture. Type d’événement explicit | |||
| Avoir créé | Cette activité représente la création d’un avoir, émis à un client pour corriger une surfacturation ou accorder un crédit au titre de marchandises retournées. Il est souvent lié à une facture d’origine. | ||
| Pourquoi c’est important Met en évidence les problèmes qui entraînent des ajustements financiers après la facturation. L’analyse des avoirs peut révéler des erreurs de prix, des problèmes liés aux produits ou d’autres causes profondes de pertes de revenus. Où les obtenir Créé explicitement comme nouveau document de facturation dans VBRK, avec un type de facturation spécifique aux avoirs, par exemple « G2 ». Il fait souvent référence à la commande client ou à la facture d’origine. Collecte Capturé lors de la création, dans VBRK, d’un document de facturation associé à un type de facturation d’avoir. Type d’événement explicit | |||
| Comptabilisation de la facture bloquée | Cet événement se produit lorsqu'une facture est créée, mais automatiquement bloquée avant son enregistrement en comptabilité financière pour diverses raisons, telles que des contrôles de crédit ou des incohérences de données. Ce statut est déduit du champ de statut d'enregistrement du document de facturation. | ||
| Pourquoi c’est important Identifie les goulots d’étranglement lorsque les factures sont créées, mais ne sont pas immédiatement libérées pour la finance, ce qui retarde l’ensemble du cycle d’encaissement. Il s’agit d’un indicateur important de problèmes de qualité des données ou de gestion du crédit. Où les obtenir Déduit du champ de statut d'enregistrement de la table d'en-tête du document de facturation (VBRK-RFBSK). Un statut tel que « A » (document de facturation bloqué pour transmission à FI) indique un blocage. Collecte Déduit en vérifiant la valeur du champ de statut d'enregistrement (VBRK-RFBSK) immédiatement après la création de la facture. Type d’événement inferred | |||
| Date d'échéance du paiement atteinte | Il s'agit d'un événement calculé représentant la date à laquelle le paiement de la facture est officiellement exigible selon les conditions de paiement convenues. Ce n'est pas un événement transactionnel, mais une date dérivée des données de la facture. | ||
| Pourquoi c’est important Cette date fournit une référence essentielle pour mesurer le respect des délais de paiement et analyser les comportements de paiement des clients. Elle permet de distinguer les paiements effectués à temps des paiements en retard. Où les obtenir Calculé à partir de la date de référence du paiement (BSEG-ZFBDT) et des conditions de paiement enregistrées dans le poste client du document comptable. Collecte Dérivé en ajoutant le nombre de jours prévu par les conditions de paiement à la date de référence du paiement figurant dans le poste du document comptable (BSEG). Type d’événement calculated | |||
| Facture annulée | Se produit lorsqu’une facture précédemment créée est annulée, ce qui implique généralement la création d’un document d’annulation correspondant. Cette opération contre-passe la facture d’origine ainsi que son impact comptable. | ||
| Pourquoi c’est important Signale des reprises, des corrections ou des erreurs de facturation. Une fréquence élevée d’annulations révèle des problèmes importants en amont, lors de la saisie des commandes clients ou de la configuration de la facturation. Où les obtenir Capturé lors de la création d’un document de facturation d’annulation, par exemple de type « S1 ». Ce nouveau document dans VBRK fait référence au numéro de la facture d’origine dans le champ VBRK-SFAKN. Collecte L’événement est capturé à partir de la date de création, dans VBRK, du document d’annulation faisant référence à la facture d’origine. Type d’événement explicit | |||
| Facture envoyée au client | Cette activité indique le moment où la facture est transmise au client, par exemple par impression, e-mail ou EDI. Le mécanisme de capture dépend de la configuration de la gestion des sorties dans SAP. | ||
| Pourquoi c’est important Il s'agit du début officiel du délai de paiement du point de vue du client. Les retards d'envoi de la facture ont un impact direct sur le Days Sales Outstanding (DSO) et la trésorerie. Où les obtenir L'événement peut être enregistré explicitement dans les tables de contrôle des sorties, comme NAST pour les anciennes méthodes ou son équivalent dans S/4HANA. S'il n'est pas enregistré explicitement, il est souvent déduit comme survenant au même moment que « Invoice Posted To Accounting ». Collecte Vérifiez les journaux de traitement dans les tables de gestion des sorties afin de trouver l'horodatage associé au type de sortie de la facture. Type d’événement explicit | |||
| Litige client ouvert | Cette activité se produit lorsqu'un client conteste une facture et que le litige est ensuite enregistré officiellement dans le système. Elle nécessite l'utilisation du module SAP Dispute Management. | ||
| Pourquoi c’est important Elle met en évidence les problèmes de précision de la facturation, de qualité des produits ou de prestation de services qui entraînent des retards de paiement. L'analyse des motifs de litige peut aider à traiter les causes profondes et à améliorer la satisfaction client. Où les obtenir Enregistré lors de la création d'un dossier de litige dans les tables Dispute Management, par exemple UDM_CASE, qui est lié au poste du document comptable. Collecte Capturé à partir de l'horodatage de création du dossier de litige associé à la facture. Type d’événement explicit | |||
| Relance de paiement envoyée | Représente l'envoi au client d'une relance de paiement ou d'un avis de recouvrement pour une facture échue. Il s'agit d'un événement explicite généré par la procédure automatisée de relance. | ||
| Pourquoi c’est important Permet d'analyser l'efficacité du processus de relance. Il aide à déterminer si les relances accélèrent les paiements et quels niveaux de relance ont le plus d'impact. Où les obtenir Enregistré dans les tables d'historique des relances (MAHNV, MHND) lors de l'exécution de la relance (transaction F150) pour le poste ouvert de la facture. Collecte Capturé à partir de la date d'exécution de l'avis de relance enregistrée dans les tables d'historique des relances. Type d’événement explicit | |||
| Reprise de facturation identifiée | Événement calculé qui identifie une boucle de reprise dans laquelle une facture a été annulée, puis une nouvelle facture générée pour la même commande client. Il ne s’agit pas d’une transaction unique, mais d’une séquence d’événements. | ||
| Pourquoi c’est important Contribue directement au KPI de taux de reprise de facturation en quantifiant les corrections effectuées. Cela aide à localiser les inefficacités et à mesurer le coût de la non-qualité dans le processus de facturation. Où les obtenir Ce schéma est calculé en identifiant un événement « Facture annulée » suivi d’un nouvel événement « Facture générée », les deux faisant référence au même document source, par exemple un numéro de commande client. Collecte Déduit de la détection, pour la même référence de commande client, d’une séquence « Facture annulée » puis « Facture générée ». Type d’événement calculated | |||
Guides d'extraction
Étapes
- Prérequis : Assurez-vous de disposer d'un compte utilisateur dans SAP S/4HANA avec les autorisations nécessaires pour interroger les vues Core Data Services (CDS). Vous devez notamment disposer d'un accès en lecture aux vues telles que I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase et I_DunningHistory.
- Accéder à l'outil d'extraction des données : Connectez-vous à votre système SAP S/4HANA. Vous pouvez utiliser différents outils pour exécuter des requêtes SQL sur les vues CDS, notamment SAP HANA Studio, DBeaver connecté via le client SAP HANA ou le module complémentaire SAP Analysis for Microsoft Excel. Dans ce guide, nous partons du principe que vous utilisez un client SQL standard.
- Identifier les paramètres du système : Avant d'exécuter la requête, identifiez les codes société concernés et la période à analyser. Il est recommandé de commencer par un périmètre limité, par exemple les données des 3 à 6 derniers mois, afin de conserver des temps d'exécution raisonnables.
- Préparer la requête SQL : Copiez la requête SQL complète fournie dans la section « query » de ce document dans le client SQL de votre choix.
- Personnaliser les espaces réservés : Modifiez les valeurs correspondantes dans la requête. Remplacez
'YYYY-MM-DD'par vos dates de début et de fin. Remplacez'XXXX'par le ou les codes société concernés. Vous devrez peut-être également adapter l'espace réservé correspondant aux types de documents d'avoir, par exemple'G2', selon la configuration de votre système. - Exécuter la requête : Exécutez la requête SQL modifiée sur la base de données SAP S/4HANA. La durée d'exécution dépendra du volume de données compris dans la période sélectionnée.
- Vérifier les résultats : Une fois la requête terminée, examinez le résultat. Celui-ci doit prendre la forme d'une table plate où chaque ligne représente une activité du processus de facturation. Il s'agit de votre Event Log.
- Transformer les données, si nécessaire : La requête est conçue pour produire un Event Log propre. Vérifiez toutefois le format des horodatages afin de vous assurer qu'il est compatible avec votre outil de Process Mining. La requête utilise
ABAP_SYSTEM_UTCL_TO_TIMESTAMPpour convertir les valeurs en horodatages UTC standard, généralement compatibles avec la plupart des outils. - Exporter l'Event Log : Exportez l'ensemble du résultat depuis votre client SQL dans un fichier CSV. Vérifiez que le fichier est encodé en UTF-8 afin d'éviter les problèmes de caractères.
- Importer dans ProcessMind : Importez le fichier CSV généré dans la plateforme ProcessMind en associant les colonnes du fichier, telles que InvoiceNumber, ActivityName et EventTime, aux champs correspondants de l'outil.
Configuration
- Période : Définissez les dates de début et de fin dans la clause
WHEREde la première expression de table commune (CTE). Une période de 3 à 6 mois est recommandée pour une première analyse, afin de trouver un équilibre entre le volume de données et les performances. Le filtre porte surBillingDocumentDate. - Code société : Filtrez une ou plusieurs valeurs
CompanyCodeafin de limiter l'extraction aux entités juridiques concernées. Ce filtre est essentiel pour maîtriser le périmètre des données. - Types de documents : La requête contient une logique permettant d'identifier les avoirs à partir de
BillingDocumentType. Vous devez configurer l'espace réservé, par exemple('G2', 'CR'), avec les types de documents utilisés pour les avoirs dans votre organisation. - Prérequis : L'accès aux vues CDS sous-jacentes est obligatoire. Il nécessite des rôles et autorisations spécifiques attribués par votre équipe de sécurité SAP. En outre, pour des activités telles que « Customer Dispute Opened » ou « Payment Reminder Issued », les modules SAP correspondants, SAP Dispute Management et SAP Financials Dunning, doivent être activement utilisés dans votre système.
- Performances : La requête utilise plusieurs jointures et unions. Pour les volumes très importants, par exemple plusieurs années de données, envisagez de l'exécuter en dehors des heures de pointe ou d'appliquer des filtres plus restrictifs afin de limiter le premier chargement.
a Exemple de requête sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Étapes
- Vérifiez que vous disposez d'un accès direct en lecture au schéma SAP HANA contenant les tables de facturation et les tables financières associées. Demandez au responsable du système le nom du schéma, les informations de connexion, la période autorisée, le périmètre des codes société, les types de documents de facturation ainsi que les éventuels filtres client ou région. Ne remplacez dans la requête que les espaces réservés liés à la connexion et aux filtres.
- Vérifiez les sources de données SAP S/4HANA concernées et la correspondance de leurs champs dans le système cible. La requête utilise VBRK et VBRP pour les données de facturation et nécessite des sources configurées pour la comptabilité, la gestion des sorties, la gestion des litiges, les relances, les paiements entrants, le lettrage et les relations entre documents. Ne remplacez les espaces réservés entre crochets pour les sources et les champs qu'après les avoir validés dans le dictionnaire de données du système.
- Configurez la période d'extraction avec un horodatage de début inclus et un horodatage de fin exclu. Une période de 3 à 6 mois est recommandée pour la première exécution. Limitez l'extraction par code société et, si nécessaire, par type de facturation afin de maîtriser le volume et d'éviter de mélanger des processus de facturation distincts.
- Exécutez la requête avec un utilisateur de base de données HANA disposant d'un accès en lecture seule. La requête crée une ligne d'événement pour chaque activité explicitement extraite. Elle ne s'appuie pas sur ProcessMind pour déduire les événements. Les activités calculées, notamment Payment Due Date Reached et Billing Rework Identified, sont générées par la logique SQL et renvoyées sous forme de lignes.
- Validez le schéma renvoyé. L'Event Log doit contenir InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region et EndTime. Vérifiez que InvoiceNumber, ActivityName et EventTime sont renseignés pour chaque ligne.
- Validez la sémantique et les relations entre les événements. Comparez les lignes Invoice Generated avec les données de création des en-têtes de facturation, les lignes Invoice Posted To Accounting avec le statut de comptabilisation, les lignes Invoice Sent To Customer avec les enregistrements de sortie, les lignes de paiement avec les pièces comptables et les lignes de lettrage avec les postes de facture lettrés. Examinez toutes les sections dépendant d'espaces réservés avant une utilisation en production.
- Normalisez le résultat pour ProcessMind. Conservez une ligne par événement, utilisez un type d'horodatage et un fuseau horaire cohérents, conservez InvoiceNumber sous forme de texte afin de préserver les zéros initiaux et vérifiez que les valeurs d'ActivityName correspondent exactement aux noms d'activités requis. Triez par InvoiceNumber et EventTime, en ajoutant un ordre secondaire déterministe lorsque plusieurs événements partagent le même horodatage.
- Exportez le résultat au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Mappez InvoiceNumber comme identifiant de cas, ActivityName comme colonne d'activité et EventTime comme horodatage de l'événement. Ajoutez les attributs recommandés lorsqu'ils sont disponibles, puis importez le fichier via le processus d'importation ProcessMind configuré et effectuez une dernière vérification du nombre de lignes et d'activités.
Configuration
- Période : Commencez par une période de 3 à 6 mois. Utilisez un horodatage de début inclus et un horodatage de fin exclu afin d'éviter les doublons entre les exécutions incrémentielles.
- Identifiant de cas : Utilisez InvoiceNumber issu de l'en-tête du document de facturation. Conservez-le sous forme de chaîne, car les numéros de documents SAP peuvent commencer par des zéros.
- Activités requises : L'extraction doit renvoyer des lignes explicites pour Invoice Generated, Invoice Posting Blocked, Invoice Posted To Accounting, Invoice Sent To Customer, Payment Due Date Reached, Customer Dispute Opened, Payment Reminder Issued, Customer Payment Received, Cash Applied/Reconciled, Invoice Closed, Invoice Cancelled, Credit Memo Created et Billing Rework Identified.
- Filtres : N'appliquez les filtres Company Code, type de document de facturation, organisation commerciale, client, région et date qu'après avoir confirmé les champs correspondants et le périmètre métier dans le système cible. Ne partez pas du principe que tous les types de documents de facturation suivent le même processus comptable ou de sortie.
- Configuration des sources : VBRK et VBRP sont les principales sources de facturation. Les sources comptables, de sortie, de litige, de relance, de paiement, de lettrage et de flux de documents doivent être configurées selon la version SAP S/4HANA déployée et les modules activés. Remplacez les références entre crochets par des objets et des champs validés.
- Événements calculés : Payment Due Date Reached est dérivé des conditions de paiement et des données d'échéance. Billing Rework Identified est dérivé des séquences d'annulation et de création ultérieure d'une facture. Il s'agit de lignes d'événements générées par SQL, et non d'enregistrements transactionnels natifs.
- Performances : Appliquez les filtres de date, de code société, de type de facturation et de numéro de document dans chaque requête source. Ne sélectionnez que les colonnes nécessaires, évitez les jointures non restreintes avec de grandes tables comptables, traitez la période par lots mensuels ou hebdomadaires et utilisez les plans d'exécution de la base pour repérer les jointures coûteuses.
- Extraction incrémentielle : Utilisez un watermark stable fondé sur les horodatages de création ou de comptabilisation des sources. Retravaillez une petite fenêtre de chevauchement afin de capturer les enregistrements de sortie, de paiement, de litige et de lettrage arrivés tardivement, puis dédupliquez à l'aide de InvoiceNumber, ActivityName et EventTime, ainsi que de la clé du document source concerné.
- Autorisations : L'utilisateur d'extraction doit disposer d'autorisations de lecture sur les objets et les champs du schéma HANA sélectionné. Vérifiez que l'accès direct à la base de données est autorisé par la politique de sécurité de votre organisation et que les exigences relatives au traitement des données personnelles ou clients sont respectées.
- Prérequis fonctionnels : Les données de gestion des sorties, d'intégration comptable, de gestion des litiges, de relance, de paiement entrant et de lettrage ne sont disponibles que si les fonctions correspondantes sont configurées et utilisées dans le système. L'absence de modules ou d'enregistrements sources entraîne l'absence d'activités, et non la déduction d'événements.
- Fuseau horaire : Uniformisez les horodatages selon le fuseau horaire requis par ProcessMind. Documentez si les horodatages sources sont stockés en UTC, dans l'heure locale du système ou dans un autre fuseau configuré.
a Exemple de requête sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Prêt à commencer ?
Utilisez ce modèle pour accélérer la préparation de vos données et commencer à optimiser votre processus Order to Cash - Facturation et émission des factures. Commencez dès aujourd’hui à transformer vos données SAP S/4H4ANA en analyses concrètes.
Optimisez la facturation Order to Cash pour accélérer de 30 % vos encaissements
Éliminez les inefficacités et réduisez dès aujourd'hui de 30 % la durée de votre cycle de facturation.
Aucune carte bancaire requise. Commencez en quelques minutes.