> Amélioration continue des processus > Facturation Order to Cash > SAP S/4HANA > Modèle de données

Votre modèle de données Order-to-Cash, facturation et émission des factures

SAP S/4HANA

Attributs Order-to-Cash : facturation et émission des factures(21) Activités Order-to-Cash : facturation et émission des factures(13) Guides d’extraction(2)

Votre modèle de données Order-to-Cash, facturation et émission des factures

Ce modèle vous guide dans la collecte et la préparation des données de facturation issues de SAP S/4HANA. Il présente les attributs et les activités nécessaires à la création d’un journal d’événements adapté au Process Mining. Utilisez cette ressource pour organiser l’extraction des données et recueillir les informations nécessaires à une analyse pertinente.

Attributs recommandés à collecter
Activités clés à suivre
Conseils d’extraction pour SAP S/4HANA

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs Order-to-Cash : facturation et émission des factures

Voici les champs de données recommandés pour votre journal d’événements afin d’analyser en détail le processus Order-to-Cash de facturation et d’émission des factures.

3 Obligatoire 7 Recommandé 11 Facultatif

	Nom	Description
	Numéro de facture InvoiceNumber	Identifiant unique d’un document de facturation, utilisé comme identifiant de cas principal pour 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 sert de clé centrale pour relier 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. En Process Mining, cet attribut est essentiel pour regrouper les événements par cas. Tous les événements associés au même numéro de facture sont réunis dans une seule instance de processus, ce qui permet d’analyser le cycle de vie complet de chaque facture, de bout en bout. Vous pouvez ainsi suivre les temps de cycle, repérer les écarts et analyser le parcours de chaque facture. Pourquoi est-ce important ? Cet identifiant fondamental relie toutes les activités de facturation associées dans un même cas et permet l’analyse du processus de bout en bout. Où trouver ces données 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 indique la date et l’heure de chaque activité et constitue la trame 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 de la facturation. Lors de l’analyse, l’heure de l’événement sert à ordonner les activités, à calculer des indicateurs clés comme le délai moyen de paiement client et le temps de cycle de génération des factures, et à repérer les goulots d’étranglement liés aux délais. Elle donne une vue dynamique du processus, montrant l’évolution des performances et le temps nécessaire à chaque étape du cycle de facturation. Pourquoi est-ce important ? Elle établit l’ordre chronologique des événements, indispensable au calcul de toutes les mesures liées au temps, comme les temps de cycle et les durées. Où trouver ces données Extrait de différents champs de date et d’heure selon l’activité, par exemple 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 vie de la facturation. Ces activités sont déduites de différentes données SAP, comme les codes de transaction, les changements de statut des documents ou certaines entrées de journal, afin de reconstituer le déroulement du processus. L’analyse de la séquence et de la fréquence de ces activités est au cœur du Process Mining. Elle permet de visualiser le processus, de découvrir les variantes courantes ou rares, de repérer 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 est-ce important ? Cet attribut définit les étapes du processus. Il permet de visualiser les cartes de processus et d’analyser le déroulement, les variantes et les goulots d’étranglement. Où trouver ces données Déduit de différentes sources, notamment des codes de transaction (SY-TCODE), des statuts des documents de modification (tables CDHDR/CDPOS) ou des journaux de flux de travail métier (par exemple, SWW_WI2OBJ). Exemples Facture généréeFacture comptabilisée en comptabilitéPaiement du client reçuFacture annulée
	Date d’échéance du paiement PaymentDueDate	Date à laquelle le client est censé régler 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 à laquelle le paiement doit être reçu pour que la facture ne soit pas en retard. Cet attribut est essentiel au suivi de l’efficacité du recouvrement et aux prévisions de trésorerie. Il sert directement au calcul de l’indicateur de taux de paiement à temps et au classement des factures dans les rapports d’ancienneté. L’analyse des écarts entre la date d’échéance et la date de paiement réelle permet d’évaluer l’efficacité des différentes conditions de paiement. Pourquoi est-ce important ? Elle fixe la date limite de paiement du client, ce qui permet de calculer le taux de paiement à temps et de gérer les comptes clients. Où trouver ces données Cette date n’est pas enregistré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 d’émission de la facture 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. Elle détermine les conditions et les échéances de paiement ainsi que l’ancienneté de la créance. Cet attribut, défini au niveau du cas, est essentiel à l’analyse financière. Il sert de référence pour calculer l’indicateur de délai moyen de paiement client (DSO) et produire des rapports sur l’ancienneté des factures impayées, deux outils importants pour gérer la trésorerie et le recouvrement. Pourquoi est-ce important ? Il s’agit de la date de référence pour les calculs financiers : elle sert de point de départ au calcul du DSO, des échéances de paiement et de l’ancienneté des factures. Où trouver ces données Table SAP : VBRK, champ : FKDAT Exemples 2023-03-202023-04-012023-05-18
	Heure de fin EndTime	Horodatage précis indiquant la fin d’une activité ou d’un événement.
Description L’heure de fin marque l’achèvement d’une activité. En Process Mining, elle est souvent déduite de l’heure de début de l’activité suivante dans le cas, mais peut aussi provenir directement du système si celui-ci enregistre les événements de début et de fin. Cet attribut est essentiel au calcul de la durée de traitement de chaque activité. La différence entre l’heure de début et l’heure de fin donne la durée de chaque étape, ce qui est nécessaire à l’analyse des goulots d’étranglement, par exemple pour repérer les retards lors de l’approbation des factures. Pourquoi est-ce important ? Il permet de calculer la durée exacte de traitement de chaque activité, une mesure fondamentale pour analyser les goulots d’étranglement. Où trouver ces données Cet attribut est calculé pour le Process Mining. Il correspond généralement à l’heure de début de l’événement suivant dans la séquence du cas. Dans certains scénarios, 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	Montant net total de la facture.
Description Cet attribut représente la valeur monétaire totale des biens ou des services facturés, hors taxes. Il s’agit d’une donnée financière fondamentale pour chaque cas de facture. Le montant de la facture sert à 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 du montant total des créances impayées. Pourquoi est-ce important ? Il quantifie la valeur financière de chaque facture et permet d’analyser le processus selon les montants, de prioriser le recouvrement et d’évaluer les incidences financières. Où trouver ces données Table SAP : VBRK, champ : NETWR Exemples 1500.0025000.50125.75
	Nom d’utilisateur UserName	Identifiant de l’employé qui a exécuté l’activité.
Description Cet attribut enregistre l’identifiant de l’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 relie les étapes du processus aux personnes ou aux équipes qui les exécutent. L’analyse par nom d’utilisateur aide à repérer les personnes les plus performantes, les besoins de formation ou les déséquilibres dans la répartition de la charge de travail. Elle est également essentielle à l’analyse de la conformité : elle indique qui a exécuté les activités importantes et permet de comprendre pourquoi différents utilisateurs réalisent différemment une même activité. Pourquoi est-ce 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ù trouver ces données Pour les événements de création, cette information figure dans VBRK-ERNAM. Pour les modifications ultérieures, elle se trouve dans les tables d’historique des modifications, comme CDHDR-USERNAME, ou dans les journaux de 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 base des clients dans SAP. L’analyse du processus par client permet de repérer les tendances propres à certains comptes. Elle peut, par exemple, révéler quels clients paient régulièrement en retard, contestent le plus souvent leurs factures ou sont associés aux processus de facturation les moins efficaces. Ces informations permettent d’adapter la gestion de la relation client et les stratégies de recouvrement. Pourquoi est-ce important ? Il permet d’analyser le processus du point de vue du client et de repérer, pour chaque compte, les habitudes de paiement, la fréquence des litiges et les inefficacités du processus. Où trouver ces données Récupéré dans la table des données de base des clients KNA1 (champ : NAME1), à partir de l’identifiant du payeur dans l’en-tête de la facture (VBRK-KUNRG). Exemples Centrale électrique de SpringfieldSupérette Kwik-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. Cette information figure généralement dans la fiche de données de base du client. Cet attribut est essentiel au Dashboard des performances de facturation par région. Il permet de comparer des indicateurs clés, comme les temps de cycle, les taux d’erreur et le DSO, entre différentes régions. Cette comparaison peut révéler 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 généralisation des bonnes pratiques. Pourquoi est-ce important ? Il permet de comparer les performances de facturation entre différentes zones géographiques, de repérer les écarts régionaux et d’harmoniser les processus. Où trouver ces données Récupéré dans la table des données de base des clients KNA1 (champ : REGIO), à partir de l’identifiant du payeur dans l’en-tête de la facture (VBRK-KUNRG). Exemples CANYTXBA
	Code société CompanyCode	Unité organisationnelle pour laquelle l’opération financière est enregistrée.
Description Le code société est une entité organisationnelle fondamentale dans SAP Financials. Il représente une société juridiquement indépendante pour laquelle des états financiers sont établis. Chaque document de facturation est associé à un code société précis. Dans les organisations qui regroupent plusieurs sociétés, l’analyse par code société permet de comparer les performances des processus, les indicateurs financiers comme le DSO et la conformité entre différentes entités juridiques. Elle fournit un filtre organisationnel de haut niveau pour tous les Dashboards de processus. Pourquoi est-ce important ? Il permet de segmenter l’analyse des processus par entité juridique, afin de comparer les performances et de consolider les données financières de l’organisation. Où trouver ces données Table SAP : VBRK, champ : BUKRS Exemples 10002000US01
	Conditions de paiement PaymentTerms	Code qui définit les conditions de paiement, notamment le délai accordé pour régler une facture.
Description Les conditions de paiement sont des modalités convenues à l’avance avec un client qui déterminent la date à laquelle une facture doit être réglée. Exemples : « 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 des conditions de paiement permet d’en évaluer l’efficacité. En comparant les différentes modalités au délai réel de règlement, une entreprise peut déterminer lesquelles incitent le mieux les clients à payer rapidement et les ajuster afin d’améliorer sa trésorerie. Pourquoi est-ce important ? Il définit l’échéancier de paiement convenu et permet d’analyser les modalités qui incitent le mieux les clients à payer dans les délais. Où trouver ces données 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 de 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. Ce champ de métadonnées est essentiel pour connaître l’ancienneté des données analysées. Ces informations permettent de vérifier la date de l’analyse et de gérer les calendriers d’actualisation des données. Elles indiquent aux parties prenantes si les données sont à jour lorsqu’elles prennent des décisions à partir des Dashboards et des analyses de Process Mining. Pourquoi est-ce important ? Il indique si les données sont à jour, un élément essentiel pour se fier à l’analyse et évaluer sa pertinence au regard de la situation actuelle des opérations. Où trouver ces données 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 de devise du montant de la facture.
Description Cet attribut indique la devise dans laquelle les montants des factures 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 à la fiabilité des analyses et du reporting financier. Elle permet de convertir les montants dans une devise de reporting commune et de comparer les performances de facturation entre des régions qui utilisent des devises locales différentes. Pourquoi est-ce important ? Il fournit le contexte nécessaire à l’interprétation des valeurs monétaires et garantit la fiabilité des analyses et du reporting financier, notamment dans les activités internationales. Où trouver ces données Table SAP : VBRK, champ : WAERK Exemples USDEURGBP
	Motif de l’avoir CreditMemoReason	Code indiquant le motif d’émission d’un avoir.
Description Lorsqu’une facture comporte une erreur et doit faire l’objet d’un avoir, un motif est généralement attribué au document correspondant. Cela permet de classer les sources d’erreurs de facturation de manière structurée. Cet attribut contribue directement au KPI du taux d’erreur de facturation. En regroupant et en analysant les motifs des avoirs, une entreprise peut repérer 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 est-ce important ? Il classe les motifs d’émission des avoirs, ce qui aide à repérer les sources d’erreurs de facturation les plus fréquentes et à améliorer la qualité. Où trouver ces données Table SAP : VBRK, champ : AUGRU (motif de commande). Ce champ est utilisé pour les demandes d’avoir ou de débit qui sont ensuite facturées. Exemples 001 - Écart de prix002 - Qualité insuffisante005 - Retour client
	Motif du litige CustomerDisputeReason	Motif invoqué par un client pour contester une facture.
Description Lorsqu’un client conteste une facture, le motif du litige est souvent consigné. Il peut s’agir d’une erreur de prix, d’une quantité incorrecte ou de marchandises endommagées. Ces informations peuvent être enregistrées dans le module SAP Dispute Management ou sous forme de notes textuelles. L’analyse des motifs de litige est essentielle pour calculer le KPI du taux d’erreur de facturation et étudier les erreurs associées. Elle aide à repérer les causes profondes des inexactitudes de facturation, afin de corriger les problèmes récurrents dans les processus en amont, d’améliorer la qualité des factures et de renforcer la satisfaction client. Pourquoi est-ce important ? Il explique pourquoi les factures sont contestées et met directement en évidence les causes des erreurs de facturation et de l’insatisfaction des clients. Où trouver ces données Si SAP Dispute Management est utilisé, ces informations peuvent se trouver dans des tables telles que UDM_DISPUTE. Sinon, elles peuvent être déduites des codes de motif associés aux documents ou de champs textuels. Exemples Prix incorrectÉcart de quantitéMarchandises reçues endommagées
	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 qui l’ont précédé. Une même commande peut donner lieu à une ou plusieurs factures ; ce lien permet de reconstituer l’ensemble du flux documentaire. Cet attribut est essentiel pour analyser le processus Order-to-Cash de bout en bout. Il permet d’étendre l’analyse en amont et de relier les problèmes de facturation à leurs causes possibles lors de la création ou de l’exécution de la commande. Il permet, par exemple, de calculer le temps de cycle global de génération de la facture à partir de l’exécution de la commande. Pourquoi est-ce important ? Il relie la facture à la commande client d’origine et permet d’analyser le processus Order-to-Cash dans son ensemble, au-delà de la seule facturation. Où trouver ces données Table SAP : VBRP (données des postes du document de facturation), champ : AUBEL Exemples 100001231000045610000789
	Paiement effectué à temps IsPaidOnTime	Indicateur booléen précisant si la facture a été réglée à la date d’échéance ou avant celle-ci.
Description Cet attribut calculé compare la date réelle du paiement à la date d’échéance prévue. Il prend la valeur « true » si le paiement a été effectué à temps et « false » s’il est en retard. Cet indicateur simplifie le calcul et la visualisation du KPI du taux de paiement à temps. Il facilite le filtrage et la segmentation des factures réglées en retard ou à temps. L’analyse peut ainsi révéler des tendances liées à certains clients, régions ou conditions de paiement qui entraînent des retards. Pourquoi est-ce important ? Il simplifie la mesure des performances en indiquant clairement si chaque facture a été réglée à temps ou en retard, et contribue directement au KPI du taux de paiement à temps. Où trouver ces données Ce champ est calculé. La logique compare l’horodatage de l’activité « Paiement reçu du client » à la valeur de l’attribut « PaymentDueDate ». Exemples truefalse
	Statut du paiement PaymentStatus	État actuel du paiement de la facture, par exemple ouverte, réglée ou en retard.
Description Le statut du paiement indique où en est une facture dans le processus de recouvrement. Il ne correspond pas à un champ unique dans SAP : il est déterminé à partir du statut de lettrage du document comptable associé. Cet attribut est essentiel au Dashboard de suivi de l’ancienneté des factures impayées. Il permet de répartir les factures ouvertes selon leur statut et leur ancienneté, afin d’aider l’équipe de recouvrement à établir ses priorités. Le suivi des changements de statut permet également d’observer le processus de recouvrement lui-même. Pourquoi est-ce important ? Il donne une vue immédiate du statut de recouvrement d’une facture, indispensable pour gérer les créances et hiérarchiser les efforts de recouvrement. Où trouver ces données Déterminé à partir 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 OuverteRégléeEn retardPartiellement réglée
	Système source SourceSystem	Identifie le système source précis dont les données ont été extraites.
Description Cet attribut indique l’origine des données. Il est particulièrement utile dans les environnements qui comprennent 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. Lors de l’analyse, il permet de comparer les processus et les performances entre différents systèmes ou entités organisationnelles. Il assure la traçabilité des données et apporte le contexte nécessaire, notamment lorsque des données provenant de plusieurs sources sont réunies pour obtenir une vue globale du processus. Pourquoi est-ce important ? Il précise l’origine des données, ce qui clarifie leur provenance dans les environnements multi-systèmes et contribue à leur gouvernance. Où trouver ces données 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 classe le document de facturation, par exemple comme facture, avoir ou annulation.
Description Le type de document de facturation est un champ clé qui classe les opérations du processus de facturation. Il détermine le traitement du document, notamment sa plage de numérotation et les règles de comptabilisation. Cet attribut permet de filtrer le processus pour analyser des types d’opérations précis. Vous pouvez, par exemple, créer une vue distincte du processus pour les avoirs afin d’en comprendre les motifs et le flux de traitement, ou analyser séparément les factures standard et les annulations pour mieux cerner le processus de facturation principal. Pourquoi est-ce important ? Il classe les opérations et permet de cibler l’analyse de flux documentaires précis, comme les factures standard, les avoirs ou les annulations. Où trouver ces données Table SAP : VBRK, champ : FKART Exemples F2G2S1L2

Obligatoire Recommandé Facultatif

Activités Order-to-Cash : facturation et émission des factures

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir le processus avec précision.

5 Recommandé 8 Facultatif

	Activité	Description
	Facture clôturée	Cette activité indique l’état final d’une facture payée. Elle correspond fonctionnellement à « Paiement affecté et rapproché » et signifie que le processus lié à cette facture est terminé.
Pourquoi est-ce important ? Il s’agit de l’événement de fin du parcours nominal. Mesurer le temps de cycle total jusqu’à cette étape donne une vue complète du cycle de vie de la facturation, de bout en bout. Où trouver ces données 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. Données à recueillir 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 en comptabilité	Correspond à la comptabilisation réussie du document de facturation dans le module de comptabilité financière. Cette étape importante transforme la facture en créance officielle et génère des écritures dans le grand livre.
Pourquoi est-ce important ? Cette activité confirme que la facture constitue un document financier officiel. Le délai entre sa génération et sa comptabilisation est un indicateur clé de l’efficacité du traitement interne. Où trouver ces données Cet événement est enregistré lors de la création du document comptable correspondant. Le document de facturation (VBRK-VBELN) est associé au document comptable (BKPF-BELNR) via VBRK-BELNR, et la date de comptabilisation correspond à BKPF-BUDAT. Données à recueillir Extrait de la date de comptabilisation (BUDAT) du document comptable dans la table BKPF associé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 qu’un traitement en arrière-plan crée la facture, ce qui ajoute une nouvelle entrée dans la table d’en-tête des documents de facturation.
Pourquoi est-ce 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 temps de cycle de génération des factures et repérer les retards en début de processus. Où trouver ces données Enregistré dans la table VBRK de SAP S/4HANA (document de facturation : données d’en-tête) lors de la création. La date de création (VBRK-ERDAT) et l’heure (VBRK-ERZET) servent d’horodatage. Données à recueillir L’événement est extrait de l’horodatage de création de l’enregistrement du document de facturation dans la table VBRK. Type d’événement explicit
	Paiement affecté et rapproché	Correspond au moment où le paiement reçu du client est rapproché et affecté au lettrage du poste de facture ouvert dans le sous-livre des comptes clients. Cette activité marque la fin de la transaction du point de vue financier.
Pourquoi est-ce important ? Mesure l’efficacité du processus d’affectation des paiements. Les retards à cette étape peuvent donner une image inexacte de la situation des comptes clients et créer du travail inutile pour les équipes de recouvrement. Où trouver ces données Cet événement est extrait de la date de lettrage (BSEG-AUGDT) du poste du document comptable de la facture d’origine. Cette date est renseignée lorsqu’un document de lettrage solde le poste. Données à recueillir Extrait du champ de date de lettrage (AUGDT) dans la table BSEG/ACDOCA pour le poste de facture. Type d’événement explicit
	Paiement du client reçu	Cette activité indique l’enregistrement d’un paiement reçu d’un client dans le système financier. À ce stade, le paiement n’est pas nécessairement affecté à une facture précise, mais les fonds ont bien été comptabilisés.
Pourquoi est-ce important ? Cette étape est importante pour calculer le délai moyen de paiement client (DSO). Elle indique que les fonds ont été reçus, même si le rapprochement reste à effectuer. Où trouver ces données Extrait de la date de comptabilisation (BKPF-BUDAT) du document de paiement client, généralement de type « DZ » dans la table BKPF. Données à recueillir L’événement repose sur la création du document de paiement dans BKPF/BSEG. Type d’événement explicit
	Avoir créé	Cette activité correspond à la création d’un avoir destiné à corriger une surfacturation ou à créditer un client pour des marchandises retournées. L’avoir est souvent associé à une facture d’origine.
Pourquoi est-ce important ? Cet événement met en évidence les ajustements financiers effectués 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 de pertes de revenus. Où trouver ces données Créé explicitement sous la forme d’un nouveau document de facturation dans VBRK, avec un type de facturation spécifique aux avoirs, par exemple « G2 ». Il référence souvent la commande client ou la facture d’origine. Données à recueillir Extrait de la création, dans VBRK, d’un document de facturation de type 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 sa comptabilisation en comptabilité financière, pour diverses raisons, comme un contrôle de crédit ou des incohérences dans les données. Ce statut est déduit du champ de statut de comptabilisation du document de facturation.
Pourquoi est-ce important ? Cet événement met en évidence les goulots d’étranglement : les factures sont créées, mais ne sont pas immédiatement transmises à la comptabilité, ce qui retarde l’ensemble du cycle d’encaissement. Il peut révéler des problèmes de qualité des données ou de gestion du crédit. Où trouver ces données Déduit du champ de statut de comptabilisation dans la table d’en-tête des documents de facturation (VBRK-RFBSK). Un statut tel que « A » (document de facturation bloqué pour transfert vers FI) indique un blocage. Données à recueillir Déduit en vérifiant la valeur du champ de statut de comptabilisation (VBRK-RFBSK) juste après la génération de la facture. Type d’événement inferred
	Date d’échéance du paiement atteinte	Événement calculé correspondant à la date à laquelle le paiement de la facture est officiellement dû, selon les conditions de paiement convenues. Il ne s’agit pas d’un événement transactionnel, mais d’une date calculée à partir des données de la facture.
Pourquoi est-ce important ? Cette date sert de référence pour mesurer le respect des échéances de paiement et analyser le comportement de paiement des clients. Elle permet de distinguer les paiements effectués à temps des paiements en retard. Où trouver ces données Calculée à 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. Données à recueillir Calculée en ajoutant le nombre de jours prévu par les conditions de paiement à la date de référence figurant dans le poste du document comptable (BSEG). Type d’événement calculated
	Facture annulée	Cet événement se produit lorsqu’une facture déjà créée est annulée, généralement par la création d’un document d’annulation correspondant. L’opération contre-passe la facture d’origine et son incidence comptable.
Pourquoi est-ce important ? Cet événement signale des reprises, des corrections ou des erreurs de facturation. Des annulations fréquentes indiquent souvent des problèmes importants en amont, lors de la saisie des commandes client ou de la configuration de la facturation. Où trouver ces données Enregistré lors de la création d’un document de facturation d’annulation, par exemple de type « S1 ». Ce nouveau document dans VBRK référence le numéro de la facture d’origine dans le champ VBRK-SFAKN. Données à recueillir L’événement est extrait de la date de création dans VBRK du document d’annulation qui 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 courrier, e-mail ou EDI. Le mode d’enregistrement dépend de la configuration de la gestion des sorties dans SAP.
Pourquoi est-ce important ? C’est à ce moment que commence officiellement le délai de paiement du point de vue du client. Tout retard d’envoi de la facture a une incidence directe sur le délai moyen de paiement client (DSO) et sur la trésorerie. Où trouver ces données 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 considéré comme ayant lieu en même temps que « Facture comptabilisée en comptabilité ». Données à recueillir Vérifiez dans les journaux de traitement des tables de gestion des sorties s’il existe un 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 officiellement enregistré dans le système. Elle nécessite l’utilisation du module SAP Dispute Management.
Pourquoi est-ce important ? Cet événement met en évidence les problèmes de précision de la facturation, de qualité des produits ou de prestation de services susceptibles de retarder les paiements. L’analyse des motifs de litige peut aider à traiter les causes profondes et à améliorer la satisfaction client. Où trouver ces données Enregistré lors de la création d’un dossier de litige dans les tables Dispute Management (par exemple, UDM_CASE), associé au poste du document comptable. Données à recueillir Extrait de l’horodatage de création du dossier de litige associé à la facture. Type d’événement explicit
	Relance de paiement envoyée	Correspond à l’envoi à un client d’une relance ou d’un avis de retard pour une facture impayée. Il s’agit d’un événement explicite généré par la procédure automatisée de relance.
Pourquoi est-ce important ? Permet d’analyser l’efficacité du processus de relance. Vous pouvez déterminer si les relances accélèrent les paiements et quels niveaux de relance ont le plus d’effet. Où trouver ces données Enregistré dans les tables d’historique des relances (MAHNV, MHND) lors de l’exécution du traitement de relance (transaction F150) pour le poste ouvert de la facture. Données à recueillir Extrait de la date d’exécution de la relance enregistrée dans les tables d’historique des relances. Type d’événement explicit
	Reprise de facturation détectée	Événement calculé qui repère une boucle de reprise : une facture est annulée, puis une nouvelle facture est 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 est-ce important ? Contribue directement au calcul de l’indicateur de taux de reprise de facturation en quantifiant les corrections. Il aide à repérer les inefficacités et à mesurer le coût d’une qualité insuffisante dans le processus de facturation. Où trouver ces données Cette séquence est calculée en repérant un événement « Facture annulée » suivi d’un nouvel événement « Facture générée », les deux étant associés au même document source, par exemple un numéro de commande client. Données à recueillir Déduit de la détection d’une séquence « Facture annulée » puis « Facture générée » pour une même référence de commande client. Type d’événement calculated

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de SAP S/4HANA

Étapes

Prérequis : Vérifiez que vous disposez d’un compte utilisateur SAP S/4HANA et des autorisations nécessaires pour interroger les vues Core Data Services (CDS). Vous devez notamment avoir 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. Plusieurs outils permettent d’exécuter des requêtes SQL sur les vues CDS, notamment SAP HANA Studio, DBeaver connecté via le client SAP HANA ou le module d’extension SAP Analysis for Microsoft Excel. Pour ce guide, nous partons du principe que vous utilisez un client SQL standard.
Définir les paramètres du système : Avant d’exécuter la requête, déterminez les codes société concernés et la période à analyser. Pour commencer, il est recommandé de limiter le périmètre, par exemple aux données des 3 à 6 derniers mois, afin de maîtriser la durée d’exécution.
Préparer la requête SQL : Copiez la requête SQL complète fournie dans la section « query » de ce document et collez-la dans le client SQL de votre choix.
Personnaliser les espaces réservés : Modifiez les valeurs de remplacement dans la requête. Remplacez 'YYYY-MM-DD' par les dates de début et de fin souhaitées. Remplacez 'XXXX' par le ou les codes société concernés. Selon la configuration de votre système, vous devrez peut-être aussi modifier la valeur de remplacement des types de documents d’avoir, par exemple 'G2'.
Exécuter la requête : Lancez la requête SQL modifiée sur la base de données SAP S/4HANA. La durée d’exécution dépend du volume de données correspondant à la période sélectionnée.
Vérifier les résultats : Une fois la requête terminée, examinez les résultats. Le jeu de résultats doit prendre la forme d’un tableau plat où chaque ligne correspond à une activité du processus de facturation. Il s’agit de votre journal d’événements.
Transformer les données, si nécessaire : La requête est conçue pour produire un journal d’événements dans un format normalisé. Vérifiez toutefois que le format des horodatages est compatible avec votre outil de Process Mining. La requête utilise ABAP_SYSTEM_UTCL_TO_TIMESTAMP pour convertir les horodatages au format UTC standard, généralement compatible avec les outils du marché.
Exporter le journal d’événements : Exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Vérifiez que le fichier est encodé en UTF-8 pour éviter les problèmes de caractères.
Importer les données dans ProcessMind : Importez le fichier CSV généré dans la plateforme ProcessMind et associez 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 WHERE de l’expression de table commune (CTE) initiale. Pour une première analyse, une période de 3 à 6 mois est recommandée afin de trouver un équilibre entre le volume de données et les performances. Le filtre porte sur BillingDocumentDate.
Code société : Filtrez sur une ou plusieurs valeurs de CompanyCode pour 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. Configurez l’espace réservé, par exemple ('G2', 'CR'), avec les types de documents d’avoir utilisés 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 l’équipe de sécurité SAP. De plus, pour les activités telles que « Litige client ouvert » ou « Rappel de paiement envoyé », les modules SAP Dispute Management et SAP Financials Dunning correspondants doivent être utilisés dans votre système.
Performances : La requête utilise plusieurs jointures et unions. Pour les très grands jeux de données, 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 l’extraction initiale.

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 filtres éventuels sur les clients ou les régions. Remplacez uniquement les espaces réservés de connexion et de filtre dans la requête.
Vérifiez les sources de données SAP S/4HANA concernées et leurs associations de 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 vérifiés dans le dictionnaire de données du système.
Définissez la période d’extraction à l’aide d’un horodatage de début inclus et d’un horodatage de fin exclu. Pour la première exécution, une période de trois à six mois est recommandée. 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 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 des événements. Les activités calculées, notamment « Échéance de paiement atteinte » et « Reprise de facturation identifiée », sont générées par la logique SQL et renvoyées sous forme de lignes.
Vérifiez le schéma renvoyé. Le journal d’événements 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.
Vérifiez la signification des événements et leurs relations. Comparez les lignes « Facture générée » aux données de création des en-têtes de facturation, les lignes « Facture comptabilisée » au statut de comptabilisation, les lignes « Facture envoyée au client » aux enregistrements de sortie, les lignes de paiement aux documents comptables et les lignes de lettrage aux postes de facture lettrés. Examinez toutes les sections dépendant d’espaces réservés avant toute utilisation en production.
Normalisez les résultats pour ProcessMind. Conservez une ligne par événement, utilisez un type d’horodatage et un fuseau horaire cohérents, préservez InvoiceNumber au format texte pour conserver les zéros initiaux et vérifiez que les valeurs de ActivityName correspondent exactement aux noms d’activité requis. Triez les données par InvoiceNumber et EventTime, puis ajoutez un critère de tri secondaire déterministe si plusieurs événements ont le même horodatage.
Exportez les résultats au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Associez InvoiceNumber à l’identifiant du cas, ActivityName à la colonne d’activité et EventTime à l’horodatage de l’événement. Ajoutez les attributs recommandés lorsqu’ils sont disponibles, puis importez le fichier selon le processus d’importation ProcessMind configuré et vérifiez une dernière fois le nombre de lignes et d’activités.

Configuration

Période : Commencez par trois à six mois. Utilisez un horodatage de début inclus et un horodatage de fin exclu pour éviter les doublons entre les extractions incrémentielles.
Identifiant du 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 document SAP peuvent commencer par des zéros.
Activités requises : L’extraction doit renvoyer des lignes explicites pour les activités suivantes : Facture générée, Blocage de comptabilisation de la facture, Facture comptabilisée, Facture envoyée au client, Échéance de paiement atteinte, Litige client ouvert, Rappel de paiement envoyé, Paiement client reçu, Encaissement affecté/rapproché, Facture clôturée, Facture annulée, Avoir créé et Reprise de facturation identifiée.
Filtres : N’appliquez des filtres sur Company Code, le type de document de facturation, l’organisation commerciale, le client, la région et les dates qu’après avoir vérifié 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 en fonction de la version SAP S/4HANA déployée et des modules activés. Remplacez les références de sources entre crochets par des objets et des champs vérifiés.
Événements calculés : L’activité « Échéance de paiement atteinte » est déduite des conditions de paiement et des données d’échéance. L’activité « Reprise de facturation identifiée » est déduite des annulations et des créations de factures ultérieures. Ces événements sont générés par SQL et ne correspondent pas à des enregistrements transactionnels natifs.
Performances : Appliquez les filtres sur les dates, le code société, le type de facturation et le numéro de document dans chaque requête source. Ne sélectionnez que les colonnes nécessaires, évitez les jointures sans restriction avec de grandes tables comptables, traitez la période par lots mensuels ou hebdomadaires et consultez les plans d’exécution de la base de données pour repérer les jointures coûteuses.
Extraction incrémentielle : Utilisez un point de reprise stable fondé sur les horodatages de création ou de comptabilisation des sources. Réexécutez l’extraction sur une courte période de chevauchement pour récupérer les enregistrements tardifs de sortie, de paiement, de litige et de lettrage, puis éliminez les doublons à l’aide d’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 sélectionnés du schéma HANA. 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 des données 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. Si des modules ou des enregistrements sources sont absents, les activités correspondantes ne seront pas présentes et ne seront pas déduites.
Fuseau horaire : Normalisez les horodatages selon le fuseau horaire requis par ProcessMind. Indiquez si les horodatages sources sont enregistrés en UTC, en heure locale du système ou dans un autre fuseau horaire configuré.

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 à démarrer ?

Utilisez ce modèle pour préparer vos données plus rapidement et commencer à optimiser votre processus de facturation Order to Cash. Transformez dès aujourd’hui vos données SAP S/4HANA en analyses concrètes.

Retour au guide d’amélioration

Télécharger le modèle

Optimisez la facturation Order to Cash et accélérez de 30 % vos encaissements

Éliminez les inefficacités et réduisez de 30 % le temps de cycle de facturation dès aujourd’hui.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Commencez en quelques minutes.

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 Order-to-Cash : facturation et émission des factures

Activités Order-to-Cash : facturation et émission des factures

Guides d’extraction

Extraction des données de facturation à partir des vues CDS de SAP S/4HANA

Étapes

Configuration

Exemple de requête sql

Requête directe sur les tables de documents de facturation de la base de données HANA

Étapes

Configuration

Exemple de requête sql

Prêt à démarrer ?

Optimisez la facturation Order to Cash et accélérez de 30 % vos encaissements

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 Order-to-Cash : facturation et émission des factures

Activités Order-to-Cash : facturation et émission des factures

Guides d’extraction

Extraction des données de facturation à partir des vues CDS de SAP S/4HANA

Étapes

Configuration

Exemple de requête sql

Requête directe sur les tables de documents de facturation de la base de données HANA

Étapes

Configuration

Exemple de requête sql

Prêt à démarrer ?

Optimisez la facturation Order to Cash et accélérez de 30 % vos encaissements

Attributs Order-to-Cash : facturation et émission des factures

Activités Order-to-Cash : facturation et émission des factures

Prêt à démarrer ?