Votre modèle de données pour la facturation Order to Cash
Votre modèle de données pour la facturation Order to Cash
- Attributs recommandés pour une analyse complète
- Étapes et jalons clés du processus à suivre
- Conseils pratiques pour extraire les données de SAP ECC
Attributs de facturation Order to Cash
| Nom | Description | ||
|---|---|---|---|
| Activité ActivityName | Nom de l’événement métier ou de l’étape qui s’est produite au cours du cycle de vie de la facture. | ||
| Description Cet attribut décrit une action précise ou un changement de statut dans le processus de facturation, par exemple « Facture générée », « Facture comptabilisée » ou « Paiement client reçu ». Ces activités sont déduites de différents événements système, des changements de statut des pièces ou des codes de transaction utilisés par les utilisateurs. La séquence de ces activités forme le flux du processus, qui constitue la base de l’analyse en Process Mining. En examinant les activités, les organisations peuvent comprendre quelles étapes sont réalisées, dans quel ordre et à quelle fréquence. Elles peuvent ainsi comparer l’exécution réelle du processus au processus prévu. Pourquoi est-ce important ? Il définit les étapes de la cartographie des processus et permet de visualiser et d’analyser les flux, les écarts et les goulots d’étranglement. Où trouver ces données Il s’agit d’un attribut conceptuel déduit de plusieurs sources, notamment les codes de transaction (CDHDR-TCODE), les changements de statut des pièces (VBUK-FKSTK) et les écritures comptables. Exemples Facture crééeFacture comptabiliséeRelance de paiement envoyéeFacture lettrée | |||
| Heure de début EventTime | Horodatage indiquant quand une activité ou un événement précis s’est produit. | ||
| Description L’heure de l’événement indique la date et l’heure exactes de chaque activité du cycle de vie de la facture. Cet horodatage est indispensable à toutes les analyses temporelles en Process Mining, notamment au calcul des temps de cycle, à l’identification des goulots d’étranglement et au suivi des performances du processus par rapport aux accords de niveau de service. Cet attribut est généralement construit en combinant un champ de date, comme la date de comptabilisation (BUDAT), et un champ horaire (UZEIT) provenant de différentes tables SAP qui enregistrent les modifications ou la création de pièces. Des horodatages exacts sont essentiels pour constituer un journal d’événements fiable et garantir la validité des analyses de performance. Pourquoi est-ce important ? Cet attribut est à la base de toute analyse de performance. Il permet de calculer les temps de cycle, les durées et les temps d’attente entre les étapes du processus. Où trouver ces données Construit à partir de différents champs de date et d’heure répartis dans plusieurs tables, comme BKPF (BUDAT, CPUTM), VBRK (ERDAT, ERZET) et les tables de journal des modifications, telles que CDHDR (UDATE, UTIME). Exemples 2023-04-15T10:30:00Z2023-04-16T11:00:00Z2023-05-20T09:00:00Z | |||
| Numéro de facture InvoiceNumber | Identifiant unique de la pièce de facturation, utilisé comme ID de cas principal pour le processus de facturation. | ||
| Description Le numéro de facture, appelé numéro de pièce de facturation dans SAP, identifie chaque facture de manière unique. En Process Mining, il sert de CaseId et regroupe dans une même instance de processus toutes les activités associées, comme la création, la comptabilisation, l’envoi, le paiement et le lettrage. L’analyse par numéro de facture donne une vue complète du cycle de vie de chaque opération de facturation, de sa création à son règlement final. Elle est essentielle au calcul d’indicateurs clés tels que le délai moyen de paiement client (DSO) et le temps de cycle global de la facture, et fournit une base claire pour mesurer et améliorer les performances. Pourquoi est-ce important ? C’est la clé qui permet de suivre l’ensemble du parcours d’une facture et d’analyser les temps de cycle, les goulots d’étranglement et les variations pour chaque opération de facturation. Où trouver ces données Table SAP ECC : VBRK, champ : VBELN Exemples 90001234900012359000123690001237 | |||
| Code société CompanyCode | Identifiant de l’entité juridique qui a émis la facture. | ||
| Description Le code société représente dans SAP une unité juridique et comptable indépendante. Toutes les opérations financières, y compris les factures, sont comptabilisées dans un code société précis. Il s’agit d’un élément fondamental des données organisationnelles. En Process Mining, le code société sert à analyser et à comparer les performances du processus de facturation entre les différentes entités juridiques d’une entreprise. Cette comparaison permet de repérer les pratiques efficaces d’une entité qui pourraient être reprises par d’autres, tout en tenant compte de la structure organisationnelle de l’entreprise. Pourquoi est-ce important ? Il permet de filtrer et de comparer les processus entre différentes entités juridiques, une fonction essentielle à l’analyse financière et à la comparaison des performances organisationnelles. Où trouver ces données Table SAP ECC : VBRK, champ : BUKRS Exemples 10002000US01DE01 | |||
| Montant total de la facture TotalInvoiceAmount | Valeur nette totale de la pièce de facturation. | ||
| Description Cet attribut correspond au montant net total de la facture, hors taxes. Le montant de la facture est une donnée financière importante associée au processus de facturation. Il sert à différentes analyses, par exemple pour répartir les factures entre montants élevés et faibles et vérifier si leurs flux diffèrent. Il peut également aider à prioriser les efforts de recouvrement ou à comprendre pourquoi l’approbation ou le paiement des factures de montant élevé prend plus de temps. Ce contexte financier enrichit considérablement l’analyse du processus. Pourquoi est-ce important ? Il apporte un contexte financier essentiel et permet d’analyser les factures selon leur montant, par exemple pour déterminer si les factures de montant élevé suivent un processus différent ou sont plus longues à lettrer. Où trouver ces données Table SAP ECC : VBRK, champ : NETWR Exemples 1500.7525000.00500.0012345.67 | |||
| Nom d’utilisateur UserName | ID de l’utilisateur qui a réalisé l’activité ou créé la pièce. | ||
| Description Cet attribut enregistre l’ID de l’utilisateur SAP responsable d’un événement donné, par exemple la création d’une facture ou la comptabilisation d’un paiement. Il est essentiel pour analyser la part humaine du processus. Ces données permettent d’étudier les écarts de performance entre utilisateurs ou équipes, de repérer les besoins de formation et de détecter d’éventuels problèmes de conformité. Elles servent également à distinguer les activités manuelles réalisées par des utilisateurs des étapes automatisées exécutées par des utilisateurs système ou des utilisateurs de traitement par lots, ce qui est essentiel au calcul du taux d’automatisation. Pourquoi est-ce important ? Il permet d’analyser les performances des utilisateurs et la répartition de la charge de travail, ainsi que de distinguer les activités manuelles des activités automatisées, pour soutenir les initiatives d’automatisation et d’efficacité. Où trouver ces données Table SAP ECC : VBRK, champ : ERNAM (créé par), ou BKPF, champ : USNAM (nom d’utilisateur), ou CDHDR, champ : USERNAME (utilisateur). Exemples JSMITHBW_BATCHLROSSIMKUMAR | |||
| Numéro de client CustomerNumber | Numéro unique identifiant le client auquel la facture est adressée. | ||
| Description Le numéro de client associe une facture à un client ou à un partenaire commercial précis. Cet attribut est essentiel pour segmenter et analyser le processus de facturation selon les caractéristiques des clients. Les analystes peuvent comparer le délai moyen de paiement client (DSO) entre les clients, repérer ceux qui paient souvent en retard ou étudier le respect des conditions de paiement. Comprendre ces tendances est essentiel pour gérer les relations clients et adapter les stratégies de recouvrement aux différents segments. Pourquoi est-ce important ? Il permet d’analyser le processus du point de vue du client, notamment les comportements de paiement, le DSO par client et l’adaptation des stratégies de recouvrement. Où trouver ces données Table SAP ECC : VBRK, champ : KUNRG (payeur) ou KUNAG (donneur d’ordre). Exemples 100023200541CUST-A487910345 | |||
| Type de pièce de facturation BillingDocumentType | Code qui classe la pièce de facturation, par exemple comme facture, avoir ou note de débit. | ||
| Description Le type de pièce de facturation classe les opérations selon leur finalité métier. Par exemple, « F2 » désigne une facture client standard, tandis que « G2 » correspond à un avoir. Dans SAP, cette classification détermine le traitement des différents types de pièces de facturation. En Process Mining, cet attribut est essentiel pour filtrer et comparer les différents scénarios de facturation. Les analystes peuvent étudier séparément le processus des factures standard et celui des avoirs afin de comprendre leurs flux, leurs temps de cycle et leurs difficultés propres, puis de définir des améliorations ciblées. Pourquoi est-ce important ? Il permet de segmenter et d’analyser différents processus de facturation, par exemple les factures standard et les avoirs, dont les flux sont souvent très différents. Où trouver ces données Table SAP ECC : VBRK, champ : FKART Exemples F2G2L2IV | |||
| Code de transaction TransactionCode | Code de transaction SAP utilisé pour réaliser une activité. | ||
| Description Le code de transaction, ou T-Code, est un identifiant unique associé à une fonction ou à un programme SAP précis, comme « VF01 » pour créer une pièce de facturation. Enregistrer le T-Code de chaque événement permet de comprendre, au niveau technique, comment le processus a été exécuté. Cette information est très utile pour rechercher les causes d’un problème. Par exemple, si des erreurs sont fréquentes, les analystes peuvent vérifier si un code de transaction non standard est utilisé. Elle aide également à déduire le nom de l’activité et à comprendre quelles fonctionnalités du système sont utilisées dans le processus. Pourquoi est-ce important ? Il précise le contexte technique dans lequel une activité a été réalisée, ce qui permet de rechercher les causes des écarts du processus et de repérer les actions non standard des utilisateurs. Où trouver ces données Table SAP ECC : CDHDR, champ : TCODE Exemples VF01VF02FB01F-28 | |||
| Conditions de paiement PaymentTerms | Conditions auxquelles le vendeur réalise une vente, notamment l’échéancier de paiement. | ||
| Description Les conditions de paiement définissent les délais de règlement, par exemple « Net 30 » ou « Net 60 ». Elles sont convenues avec le client et influent directement sur la trésorerie. L’analyse du processus selon les conditions de paiement peut révéler si certaines d’entre elles sont associées à des délais de paiement plus longs ou à davantage de retards. Ces constats peuvent aider l’entreprise à négocier de meilleures conditions avec ses clients ou à adapter sa planification financière. Les conditions de paiement servent également au calcul de la date d’échéance de la facture. Pourquoi est-ce important ? Il aide à analyser les comportements de paiement des clients et les effets sur la trésorerie selon les conditions négociées, afin d’éclairer l’optimisation des accords commerciaux. Où trouver ces données Table SAP ECC : VBRK, champ : ZTERM Exemples Z030Z060Z001 | |||
| Correspond à une reprise IsRework | Indicateur précisant si une activité correspond à une reprise ou à une étape de correction. | ||
| Description Cet attribut calculé repère les activités qui correspondent à des reprises, comme « Facture corrigée » ou les contrepassations de pièces. Il s’agit généralement d’un indicateur booléen déduit du nom de l’activité ou des codes de transaction associés aux corrections et aux annulations, comme « VF11 » pour annuler une pièce de facturation. En Process Mining, cet indicateur permet de quantifier les reprises dans le processus de facturation. Il contribue directement au calcul d’indicateurs clés comme le taux de correction des factures et aide à visualiser les boucles de reprise dans la cartographie des processus. Celles-ci mettent en évidence les inefficacités et les problèmes de qualité qui augmentent les coûts opérationnels et retardent les paiements. Pourquoi est-ce important ? Il aide à quantifier les inefficacités du processus et les problèmes de qualité en montrant les efforts consacrés à la correction des erreurs. Il contribue directement au suivi des indicateurs clés liés aux reprises. Où trouver ces données Déduit du nom de l’activité ou du code de transaction. Par exemple : IF ActivityName = 'Invoice Corrected' OR TransactionCode = 'VF11' THEN true ELSE false. Exemples truefalse | |||
| Date d’échéance de la facture InvoiceDueDate | Date à laquelle le client est censé effectuer le paiement. | ||
| Description La date d’échéance de la facture correspond à la date limite de paiement définie par les conditions de paiement. Elle est essentielle à la gestion des comptes clients et au lancement des activités de recouvrement. Cet attribut sert à calculer l’indicateur clé du taux de paiement à temps, en le comparant à la date réelle du paiement. L’analyse des factures par date d’échéance aide à prévoir la trésorerie et à prioriser le recouvrement des paiements à venir ou en retard. Cette date est généralement calculée à partir de la date de référence et des conditions de paiement. Pourquoi est-ce important ? Elle sert de référence pour mesurer le respect des délais de paiement et est essentielle à la gestion des comptes clients et aux prévisions de trésorerie. Où trouver ces données Calculée à partir de la date de référence (BSEG-ZFBDT) et des conditions de paiement (BSEG-ZTERM). Elle n’est pas toujours enregistrée dans un champ dédié. Exemples 2023-05-152023-05-302023-06-20 | |||
| Date de comptabilisation PostingDate | Date à laquelle la pièce est comptabilisée dans les livres comptables. | ||
| Description La date de comptabilisation détermine la période fiscale dans laquelle l’opération est enregistrée dans le grand livre. Elle est essentielle à la comptabilité et aux rapports financiers. Un délai entre la création du document et sa comptabilisation peut signaler des inefficacités dans le traitement interne des pièces de facturation. En Process Mining, la date de comptabilisation marque une étape clé du cycle de vie de la facture. Le délai entre la génération de la facture et sa comptabilisation peut servir d’indicateur de performance pour mesurer l’efficacité du service de facturation. Pourquoi est-ce important ? Elle marque une étape financière importante et joue un rôle essentiel en comptabilité. Le délai entre la création et la comptabilisation de la facture mesure l’efficacité du traitement interne. Où trouver ces données Table SAP ECC : BKPF, champ : BUDAT Exemples 2023-04-152023-04-172023-05-21 | |||
| Date de lettrage ClearingDate | Date à laquelle le paiement a été reçu et la facture lettrée dans les comptes clients. | ||
| Description La date de lettrage est celle à laquelle un poste ouvert, comme une facture, est marqué comme payé ou « lettré » dans le système financier. Elle indique que le paiement est considéré comme encaissé et rapproché. C’est l’une des dates les plus importantes du cycle Order to Cash. Elle marque la fin du calcul du délai moyen de paiement client (DSO) et du temps de cycle global entre la facture et l’encaissement. Son analyse permet de mesurer l’efficacité du processus de recouvrement. Pourquoi est-ce important ? Elle marque la dernière étape du cycle de vie de la facture et sert de date de fin au calcul du DSO et du temps de cycle global. Elle reflète également l’efficacité du recouvrement. Où trouver ces données Table SAP ECC : BSAD, champ : AUGDT Exemples 2023-05-142023-06-012023-06-25 | |||
| Date du document DocumentDate | Date figurant sur le document d’origine, fournie par le fournisseur ou son créateur. | ||
| Description La date du document est celle à laquelle le document d’origine a été émis. Pour la facturation, il s’agit généralement de la date de création de la facture, souvent utilisée comme point de départ pour calculer la date d’échéance du paiement. Cette date est essentielle aux rapports financiers et au calcul d’indicateurs clés comme le délai moyen de paiement client (DSO). Du point de vue du client, elle marque le début de la période de recouvrement. L’analyse des écarts entre la date du document et la date de comptabilisation peut révéler des retards internes dans le traitement des factures entrantes. Pourquoi est-ce important ? Elle sert de référence pour calculer l’ancienneté des factures et le DSO, et constitue un repère essentiel pour l’analyse financière et celle des conditions de paiement. Où trouver ces données Table SAP ECC : VBRK, champ : FKDAT (date de facturation) Exemples 2023-04-152023-04-162023-05-20 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage de la dernière actualisation ou extraction des données depuis le système source. | ||
| Description Cet attribut indique la date de la dernière mise à jour du jeu de données depuis le système source. Il fournit un contexte essentiel à l’analyse et permet aux utilisateurs de savoir si les données consultées sont à jour. Dans les Dashboards et les rapports, cet horodatage informe les parties prenantes de l’actualité des données et les aide à comprendre pourquoi les opérations les plus récentes ne sont pas encore visibles. Il est généralement généré à la fin du processus d’extraction des données. Pourquoi est-ce important ? Il informe les utilisateurs de l’actualité des données, un élément essentiel pour prendre des décisions opérationnelles à partir de l’analyse. Où trouver ces données Généré et enregistré lors du processus d’extraction, de transformation et de chargement (ETL) des données. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Devise Currency | Code de devise des montants indiqués sur la facture. | ||
| Description Cet attribut indique la devise de l’opération, par exemple USD, EUR ou JPY. Il fournit le contexte nécessaire à l’interprétation de toutes les valeurs monétaires, comme le montant total de la facture. Lorsqu’une organisation multinationale analyse ses données, le champ de devise est indispensable pour interpréter et convertir correctement les montants financiers. Il permet d’établir des rapports cohérents et évite d’agréger des montants sans conversion appropriée, ce qui fausserait l’analyse financière. Pourquoi est-ce important ? Il fournit le contexte nécessaire à l’interprétation des valeurs monétaires et garantit la justesse de l’analyse financière, en particulier dans un environnement multidevise. Où trouver ces données Table SAP ECC : VBRK, champ : WAERK Exemples USDEURGBPJPY | |||
| Est automatisée IsAutomated | Indicateur précisant si une activité a été réalisée par un utilisateur système ou au moyen d’une automatisation. | ||
| Description Cet attribut calculé est un indicateur booléen qui distingue les activités manuelles des activités automatisées. Il est généralement déterminé en comparant l’attribut « Nom d’utilisateur » à une liste d’ID connus d’utilisateurs système ou de traitement par lots, comme « BATCHUSER » ou « SAPSYSTEM ». Cet indicateur est essentiel pour mesurer le niveau d’automatisation du processus de facturation, un objectif important pour de nombreuses organisations qui cherchent à améliorer leur efficacité et à réduire leurs coûts. L’indicateur clé du taux de facturation automatisée est calculé directement à partir de cet attribut, ce qui permet de suivre l’avancement des initiatives d’automatisation. Pourquoi est-ce important ? Il sert directement au calcul du taux de facturation automatisée, ce qui permet de mesurer l’efficacité du processus et de suivre les effets des projets d’automatisation. Où trouver ces données Déduit de l’attribut « Nom d’utilisateur ». La logique pourrait être la suivante : IF UserName IN ('BATCH', 'SYSTEM', 'RFCUSER') THEN true ELSE false. Exemples truefalse | |||
| Numéro de commande client SalesDocumentNumber | Identifiant de la commande client d’origine à l’origine de la facture. | ||
| Description Cet attribut relie directement la facture à la commande client à l’origine de l’opération. Cette traçabilité est essentielle à une analyse complète du cycle Order to Cash. En reliant le processus de facturation au processus de commande client qui le précède, les organisations peuvent analyser le temps de cycle total entre la commande du client et l’encaissement. Elles peuvent ainsi déterminer si les retards de facturation sont dus à des problèmes liés aux ventes, à l’exécution de la commande ou au service de facturation, et obtenir une vue d’ensemble du processus. Pourquoi est-ce important ? Il relie le processus de facturation à la commande client et permet une analyse complète du cycle Order to Cash, tout en aidant à repérer les retards entre services. Où trouver ces données Table SAP ECC : VBRP, champ : VGBEL Exemples 100000451000004610000047 | |||
| Organisation commerciale SalesOrganization | Unité organisationnelle responsable de la vente de produits ou de services. | ||
| Description Dans SAP, l’organisation commerciale est l’unité organisationnelle responsable de la distribution des biens et des services ainsi que de la négociation des conditions de vente. Elle joue un rôle clé dans la structuration des activités commerciales et de distribution. En Process Mining, cet attribut permet d’analyser le processus de facturation selon la structure commerciale. Il facilite la comparaison des performances entre organisations commerciales et aide à repérer les régions ou les lignes d’activité dont le processus de facturation est le plus efficace, ainsi qu’à diffuser les bonnes pratiques. Pourquoi est-ce important ? Il permet de comparer les performances entre différentes divisions commerciales ou régions, afin de repérer les bonnes pratiques et les points à améliorer. Où trouver ces données Table SAP ECC : VBRK, champ : VKORG Exemples 1000NA01EU01AP01 | |||
| Système source SourceSystem | Identifie le système source dont proviennent les données extraites. | ||
| Description Cet attribut indique le système de référence d’où proviennent les données. Dans une entreprise qui utilise plusieurs instances ERP ou des systèmes intégrés, il permet de distinguer les données selon leur source. En Process Mining, il est essentiel à la validation des données et aux analyses comparant les processus de différents systèmes ou unités organisationnelles. Il est généralement renseigné avec une valeur statique lors de l’extraction des données afin d’identifier le jeu de données. Pourquoi est-ce important ? Il précise l’origine des données, un élément essentiel pour garantir leur intégrité et permettre des analyses propres à chaque système dans les environnements qui en comptent plusieurs. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL), qui identifie l’instance SAP ECC concernée (par exemple, « ECC_PROD_NA »). Exemples SAP_ECC_PRODECC_EU_100SAP_US_FIN | |||
Activités de facturation Order to Cash
| Activité | Description | ||
|---|---|---|---|
| Facture comptabilisée | La facture est officiellement enregistrée dans le sous-livre des créances clients et dans le grand livre. Cet événement rend la facture juridiquement contraignante et reflète la dette du client. | ||
| Pourquoi est-ce important ? Cette étape importante marque officiellement le début du délai de recouvrement. Le temps écoulé entre la création et la comptabilisation peut révéler des retards de traitement internes qui affectent la trésorerie. Où trouver ces données Enregistré dans la table BKPF. La date de comptabilisation (BUDAT) du numéro de document (BELNR) marque cet événement. Pour un document mis en attente, il s’agit du moment où il est converti en document comptabilisé. Données à recueillir À partir de la date de comptabilisation (BUDAT) du document de facture dans la table BKPF. Type d’événement explicit | |||
| Facture créée | Indique la création du document de facturation dans le système. Cet événement est enregistré lorsqu’une nouvelle entrée correspondant à un type de document de facture donné est créée dans la table d’en-tête des documents comptables (BKPF). | ||
| Pourquoi est-ce important ? Il s’agit du point de départ de l’ensemble du processus de facturation. L’analyse du délai écoulé depuis cet événement permet de mesurer le temps de cycle de création des factures et sert de base au calcul du délai moyen de paiement client. Où trouver ces données Enregistré dans la table BKPF. La date de création (CPUDT) et l’heure (CPUTM) d’un numéro de document donné (BELNR) marquent cet événement. Le type de document (BLART) permet de l’identifier comme une facture. Données à recueillir À partir de l’horodatage de création (CPUDT) du document de facture dans la table BKPF. Type d’événement explicit | |||
| Facture envoyée au client | Indique que la facture a été envoyée au client par un canal défini, comme l’impression, le courriel ou l’EDI. Cet événement est généralement enregistré dans les journaux du système de gestion des sorties. | ||
| Pourquoi est-ce important ? Cette étape importante déclenche le délai de paiement du client. Tout retard à ce stade repousse la date à laquelle le paiement peut être attendu et nuit à l’efficacité du recouvrement. Où trouver ces données Peut être déduit de la date et de l’heure de traitement figurant dans la table des statuts de message (NAST), pour le type de sortie correspondant à la facture. Données à recueillir Déduit d’une entrée dans la table NAST dont le statut de traitement est « 1 » (traitement réussi). Type d’événement inferred | |||
| Facture lettrée | Statut final d’une facture payée : le poste ouvert a été soldé par un paiement correspondant ou un avoir. La facture est considérée comme entièrement réglée. | ||
| Pourquoi est-ce important ? Marque la fin du cycle de commande à encaissement pour une facture. Il s’agit de l’événement de fin principal pour mesurer le temps de cycle moyen global des factures. Où trouver ces données Se produit lorsque les champs du document de lettrage (AUGBL) et de la date de lettrage (AUGDT) sont renseignés pour le poste de facture dans la table BSEG. Données à recueillir L’événement se produit à la date de lettrage (AUGDT) enregistrée dans la table BSEG pour le poste de facture. Type d’événement explicit | |||
| Paiement client reçu | Le paiement du client a été reçu et enregistré dans le système sous forme d’encaissement ou de dépôt bancaire. Un document de paiement distinct est créé, mais il n’est pas encore affecté à la facture concernée. | ||
| Pourquoi est-ce important ? Cette étape marque un moment important du cycle de conversion de trésorerie. Le délai entre l’envoi de la facture et la réception du paiement constitue une composante majeure du délai moyen de paiement client. Où trouver ces données Enregistré sous la forme d’un nouveau document dans BKPF et BSEG, généralement avec un type de document indiquant un paiement client, tel que « DZ ». La date de comptabilisation (BUDAT) marque l’événement. Données à recueillir À partir de la date de comptabilisation du document de paiement client dans BKPF. Type d’événement explicit | |||
| Date d’échéance de la facture atteinte | Événement calculé qui marque la date à laquelle le paiement de la facture est officiellement dû selon les conditions de paiement. Il ne correspond pas à une activité effectuée par un utilisateur ou un système, mais à une date clé. | ||
| Pourquoi est-ce important ? Cet événement est essentiel pour analyser les habitudes de paiement et le respect des conditions convenues. Il sert de référence pour distinguer les paiements à l’heure des paiements en retard et calculer le KPI du taux de paiement dans les délais. Où trouver ces données Déduit en comparant la date du jour à la date d’échéance nette. La date d’échéance figure dans le champ BSEG-ZFBDT ou est calculée à partir de la date de référence et des conditions de paiement. Données à recueillir Comparez la date système au champ de date d’échéance nette du poste de facture (BSEG). Type d’événement calculated | |||
| Facture approuvée | Correspond à l’approbation officielle de la facture, qui permet de la comptabiliser ou de l’envoyer au client. Cette étape est souvent déduite de la conversion d’un document mis en attente en document comptabilisé. | ||
| Pourquoi est-ce important ? Suit le flux de travail d’approbation interne, souvent à l’origine de goulots d’étranglement. L’analyse de cette activité aide à alimenter le Dashboard d’analyse du circuit d’approbation des factures en repérant les approbateurs qui ralentissent le processus. Où trouver ces données Peut être déduit du passage d’un document du statut « mis en attente » (dans VBKPF) au statut « comptabilisé » (dans BKPF). Si un système de flux de travail est utilisé, cet événement peut aussi figurer explicitement dans les journaux du flux de travail. Données à recueillir Comparez la date de création du document mis en attente (VBKPF) à la date de comptabilisation du document définitif (BKPF). Type d’événement inferred | |||
| Facture corrigée | Correspond à une reprise : la facture initiale a été jugée incorrecte, puis annulée. Cet événement est repéré à partir des documents d’annulation associés à la facture d’origine. | ||
| Pourquoi est-ce important ? Met en évidence les inefficacités du processus et les problèmes de qualité. Des corrections fréquentes signalent des problèmes dans les données commerciales ou de facturation en amont et alimentent le Dashboard sur les reprises et les erreurs de facturation. Où trouver ces données Repéré à partir d’un document d’annulation dont le champ BKPF-STBLG pointe vers le document d’origine. La création de ce document d’annulation constitue l’événement. Données à recueillir Enregistré lors de la création d’un document d’annulation, par exemple avec FB08. Type d’événement explicit | |||
| Facture mise en attente | Le document de facture a été enregistré à titre provisoire, sans être comptabilisé dans le grand livre. Cette étape est souvent utilisée lorsque des informations sont manquantes ou doivent être vérifiées avant la comptabilisation définitive. | ||
| Pourquoi est-ce important ? Suit les étapes précédant la comptabilisation et les retards éventuels. Une longue période de mise en attente peut révéler des problèmes de qualité des données ou des goulots d’étranglement dans le processus de préapprobation. Où trouver ces données Les documents mis en attente sont stockés dans la table VBKPF. La création d’un document dans cette table, puis sa comptabilisation ultérieure, correspond à cette activité. Données à recueillir Enregistré lors de la sauvegarde d’un document mis en attente à l’aide d’une transaction telle que FV70. Type d’événement explicit | |||
| Facture passée en perte | Statut final alternatif : la facture est considérée comme irrécouvrable et le montant restant dû est imputé à un compte de créances irrécouvrables. La facture est ainsi clôturée sans paiement du client. | ||
| Pourquoi est-ce important ? Correspond à une issue défavorable du processus et à une perte de revenus. Le suivi de ces événements aide à analyser les causes des créances irrécouvrables et à améliorer les politiques de gestion du crédit. Où trouver ces données Déduit de l’analyse de l’opération de lettrage de la facture. Si la pièce de lettrage est imputée à un compte général de charges pour créances douteuses, la facture est considérée comme passée en perte. Données à recueillir Déduit lorsque l’opération de lettrage comporte une imputation sur un compte général dédié aux créances douteuses. Type d’événement inferred | |||
| Litige créé | Un litige officiel a été enregistré au sujet de la facture, généralement à la suite d’une réclamation du client. Il est consigné dans le système SAP de gestion des litiges. | ||
| Pourquoi est-ce important ? Permet de repérer les factures pour lesquelles le paiement risque d’être retardé et de mettre en évidence les problèmes à l’origine de l’insatisfaction du client. Cet événement marque le début d’un processus important de gestion des exceptions. Où trouver ces données Enregistré lors de la création d’un dossier dans la table des litiges (UDM_CASE), associé au document comptable de la facture. Données à recueillir Enregistré lorsqu’un utilisateur crée un dossier de litige au moyen de la transaction UDM_DISPUTE. Type d’événement explicit | |||
| Paiement affecté à la facture | Le paiement reçu du client a été rapproché et affecté à la facture ouverte concernée, qui peut alors être lettrée. Cette étape de rapprochement associe le paiement à la créance. | ||
| Pourquoi est-ce important ? Cette activité est essentielle pour mesurer le temps de cycle de traitement des encaissements. Un retard d’affectation peut fausser l’état réel des créances et masquer les liquidités disponibles. Où trouver ces données Déduit de la transaction de lettrage, par exemple F-32, qui renseigne les champs de lettrage du poste de facture. L’horodatage de l’événement correspond à la date de lettrage. Données à recueillir Déduit du renseignement de la date de lettrage (AUGDT) dans le poste de facture de la table BSEG. Type d’événement inferred | |||
| Relance de paiement envoyée | Le système a généré et envoyé au client un avis de relance ou une demande de paiement pour une facture en retard. Cet événement est enregistré dans l’historique des relances. | ||
| Pourquoi est-ce important ? Permet d’évaluer l’efficacité de la stratégie de recouvrement. L’analyse du délai entre l’envoi d’une relance et la réception du paiement est essentielle au KPI d’efficacité des relances de paiement. Où trouver ces données Enregistré dans les tables de données de relance, notamment MHNK (en-tête des données de relance) et MHND (postes des données de relance), générées lors de l’exécution du programme de relance (transaction F150). Données à recueillir Enregistré lors de l’exécution d’un programme de relance (F150) pour le poste en retard. Type d’événement explicit | |||
Guides d’extraction
Étapes
- Accédez à l’éditeur ABAP : Connectez-vous à votre système SAP ECC. Ouvrez l’éditeur ABAP à l’aide du code de transaction
SE38. - Créez un programme : Saisissez un nom pour votre nouveau programme dans le champ Program, par exemple
Z_PM_O2C_INVOICE_EXTRACT, puis cliquez sur le bouton Create. Donnez-lui un titre explicite et définissez son type sur « Executable Program ». - Définissez l’écran de sélection : Dans le code source du programme, définissez les paramètres de l’écran de sélection. Ils permettent de filtrer les données à extraire. Les principaux paramètres sont la plage de dates de création du document (
S_ERDAT), le code société (S_BUKRS) et le type de document de facturation (S_VBTYP). - Définissez les structures de données : Déclarez une table interne destinée à contenir les données finales du journal d’événements. Elle doit inclure les champs
InvoiceNumber,ActivityName,EventTimeet les attributs recommandés, tels queUserName,BillingDocumentType,CustomerNumber,CompanyCodeetTotalInvoiceAmount. - Mettez en place la logique de sélection des données : Écrivez le code ABAP principal pour sélectionner les données. Commencez par sélectionner les documents de facturation principaux dans les tables
VBRKetBKPF, selon les critères saisis dans l’écran de sélection. Stockez-les dans une table interne temporaire. - Extrayez les activités : Parcourez la liste initiale des documents de facturation. Pour chaque document, effectuez des sélections dans différentes tables afin d’identifier les 13 activités requises. Par exemple, interrogez la table
NASTpour les événements « Facture envoyée au client »,BSEGpour les informations de lettrage (« Facture lettrée », « Paiement imputé ») etMHNKpour les données de relance (« Relance de paiement envoyée »). - Alimentez la table du journal d’événements : Pour chaque activité trouvée à l’étape précédente, ajoutez un enregistrement à la table interne finale du journal d’événements. Vérifiez que
InvoiceNumber,ActivityName,EventTimeet les autres attributs sont correctement associés aux champs des tables sources. - Écrivez le fichier sur le serveur d’applications : Une fois la boucle terminée et la table finale du journal d’événements remplie, utilisez les instructions
OPEN DATASET,LOOP AT... TRANSFERetCLOSE DATASETpour écrire son contenu dans un fichier plat sur le serveur d’applications SAP. Indiquez un chemin logique accessible. - Récupérez le fichier : Utilisez le code de transaction
AL11pour parcourir les répertoires du serveur d’applications et repérer le fichier généré. Demandez à votre équipe SAP Basis de le télécharger sur votre poste ou dans un emplacement réseau partagé. - Vérifiez le format final : Ouvrez le fichier téléchargé et vérifiez qu’il s’agit d’un fichier CSV avec une ligne d’en-tête. Enregistrez-le en UTF-8 pour qu’il soit compatible avec l’importation dans ProcessMind.
Configuration
- Prérequis : Vous devez pouvoir créer et exécuter des programmes ABAP (transaction SE38) et être autorisé à lire les tables FI et SD, notamment
VBRK,VBRP,BKPF,BSEG,NAST,MHNKetUDM_CASE_ATTR00(pour Dispute Management). - Sélection de la plage de dates : Le programme doit comporter un paramètre obligatoire de plage de dates, généralement basé sur la date de création du document (
ERDATdans VBRK/BKPF). Pour une première extraction, une période de 3 à 6 mois est recommandée afin de conserver un volume de données raisonnable. - Filtres principaux : Filtrez toujours par code société (
CompanyCode,BUKRS) pour limiter le périmètre de l’extraction. Il est également vivement recommandé de filtrer par type de document de facturation (VBTYPdans VBRK) ou type de pièce comptable (BLARTdans BKPF), afin de ne conserver que les types de facture pertinents, par exemple « RV » pour les factures comptables standard, et d’exclure les avoirs et autres documents. - Performances : Pour les volumes importants couvrant plus de quelques mois, exécutez le programme en tâche de fond afin d’éviter les expirations de session. Optimisez le code ABAP en utilisant des lectures de tables indexées et en évitant les boucles imbriquées qui déclenchent des sélections dans la base de données. Il est préférable de sélectionner d’abord les données dans des tables internes, puis de les traiter.
- Configuration du fichier de sortie : Le code ABAP doit préciser le chemin du fichier de sortie sur le serveur d’applications ainsi que le séparateur du fichier CSV, généralement une virgule ou un point-virgule. Vérifiez que le répertoire est configuré à l’échelle du système et accessible.
Exemple de requête abap
REPORT Z_PM_O2C_INVOICE_EXTRACT.
*&---------------------------------------------------------------------*
*& Tables
*&---------------------------------------------------------------------*
TABLES: VBRK, BKPF.
*&---------------------------------------------------------------------*
*& Type Definitions for Event Log Output
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoicenumber TYPE vbrk-vbeln,
activityname TYPE string,
eventtime TYPE timestamp,
username TYPE xubname,
billingdocumenttype TYPE vbrk-vbtyp,
customernumber TYPE vbrk-kunnr,
companycode TYPE vbrk-bukrs,
totalinvoiceamount TYPE vbrk-netwr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log,
gs_event_log TYPE ty_event_log.
DATA: BEGIN OF gs_invoice,
vbeln TYPE vbrk-vbeln, " SD Doc (Invoice)
awkey TYPE bkpf-awkey, " Accounting Doc Reference Key
bukrs TYPE vbrk-bukrs, " Company Code
kunnr TYPE vbrk-kunnr, " Customer
vbtyp TYPE vbrk-vbtyp, " SD Doc Type
netwr TYPE vbrk-netwr, " Net Value
waerk TYPE vbrk-waerk, " Currency
fkdat TYPE vbrk-fkdat, " Billing Date
erdat TYPE vbrk-erdat, " Creation Date
erzet TYPE vbrk-erzet, " Creation Time
ernam TYPE vbrk-ernam, " Creator
belnr TYPE bkpf-belnr, " Acct Doc
gjahr TYPE bkpf-gjahr, " Fiscal Year
cpudt TYPE bkpf-cpudt, " Acct Doc Entry Date
cputm TYPE bkpf-cputm, " Acct Doc Entry Time
usnam TYPE bkpf-usnam, " Acct Doc User
stblg TYPE bkpf-stblg, " Reversal Doc
END OF gs_invoice.
DATA: gt_invoices LIKE TABLE OF gs_invoice.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbrk-erdat OBLIGATORY,
s_bukrs FOR vbrk-bukrs OBLIGATORY,
s_vbtyp FOR vbrk-vbtyp.
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/trans/tmp/invoice_extract.csv' OBLIGATORY.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" 1. Select base set of invoices
SELECT vbrk~vbeln, vbrk~bukrs, vbrk~kunnr, vbrk~vbtyp, vbrk~netwr, vbrk~waerk,
vbrk~fkdat, vbrk~erdat, vbrk~erzet, vbrk~ernam,
bkpf~belnr, bkpf~gjahr, bkpf~cpudt, bkpf~cputm, bkpf~usnam, bkpf~stblg, bkpf~awkey
INTO CORRESPONDING FIELDS OF TABLE gt_invoices
FROM vbrk
INNER JOIN bkpf ON bkpf~awkey = vbrk~vbeln AND bkpf~awtyp = 'VBRK'
WHERE vbrk~erdat IN s_erdat
AND vbrk~bukrs IN s_bukrs
AND vbrk~vbtyp IN s_vbtyp.
IF gt_invoices IS INITIAL.
MESSAGE 'No invoices found for the selected criteria.' TYPE 'I'.
RETURN.
ENDIF.
LOOP AT gt_invoices INTO gs_invoice.
CLEAR gs_event_log.
gs_event_log-invoicenumber = gs_invoice-vbeln.
gs_event_log-billingdocumenttype = gs_invoice-vbtyp.
gs_event_log-customernumber = gs_invoice-kunnr.
gs_event_log-companycode = gs_invoice-bukrs.
gs_event_log-totalinvoiceamount = gs_invoice-netwr.
" Activity: Invoice Generated (using accounting doc creation)
gs_event_log-activityname = 'Invoice Generated'.
gs_event_log-username = gs_invoice-usnam.
CONCATENATE gs_invoice-cpudt gs_invoice-cputm INTO DATA(lv_ts_gen).
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Posted (same as generated for non-parked docs)
gs_event_log-activityname = 'Invoice Posted'.
gs_event_log-username = gs_invoice-usnam.
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Approved (inferred by posting)
gs_event_log-activityname = 'Invoice Approved'.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Sent To Customer
SELECT SINGLE addat, aduhr FROM nast
INTO (DATA(lv_nast_date), DATA(lv_nast_time))
WHERE kappl = 'V3' AND objky = gs_invoice-vbeln AND vszst > '0'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Sent To Customer'.
gs_event_log-username = sy-uname.
CONVERT DATE lv_nast_date TIME lv_nast_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Corrected / Reversed
IF gs_invoice-stblg IS NOT INITIAL.
SELECT SINGLE cpudt, cputm, usnam FROM bkpf
INTO (DATA(lv_rev_date), DATA(lv_rev_time), DATA(lv_rev_user))
WHERE belnr = gs_invoice-stblg AND gjahr = gs_invoice-gjahr.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Corrected'.
gs_event_log-username = lv_rev_user.
CONVERT DATE lv_rev_date TIME lv_rev_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
" Activity: Payment Applied, Cleared, Due Date, Written Off (from BSEG)
SELECT SINGLE augdt, augbl, zfBDT, hkont FROM bseg
INTO (DATA(lv_augdt), DATA(lv_augbl), DATA(lv_zfbdt), DATA(lv_hkont))
WHERE bukrs = gs_invoice-bukrs
AND belnr = gs_invoice-belnr
AND gjahr = gs_invoice-gjahr
AND koart = 'D'. " Customer line
IF sy-subrc = 0.
" Due Date Reached (Calculated event)
IF lv_zfbdt IS NOT INITIAL.
gs_event_log-activityname = 'Invoice Due Date Reached'.
gs_event_log-username = 'System'.
CONVERT DATE lv_zfbdt INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Cleared, Applied, Write-Off
IF lv_augdt IS NOT INITIAL.
SELECT SINGLE usnam, cpudt, cputm, blart FROM bkpf
INTO (DATA(lv_clear_user), DATA(lv_clear_date), DATA(lv_clear_time), DATA(lv_clear_type))
WHERE belnr = lv_augbl AND bukrs = gs_invoice-bukrs.
IF sy-subrc = 0.
gs_event_log-username = lv_clear_user.
CONVERT DATE lv_clear_date TIME lv_clear_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
IF lv_clear_type = 'DZ'. " Standard Customer Payment
gs_event_log-activityname = 'Customer Payment Received'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Payment Applied To Invoice'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Invoice Cleared'. APPEND gs_event_log TO gt_event_log.
ELSE. " Assuming other clearing doc types could be write-offs
gs_event_log-activityname = 'Invoice Written Off'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDIF.
" Activity: Payment Reminder Issued (Dunning)
SELECT COUNT(*) FROM mhnk WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
IF sy-subrc = 0 AND sy-dbcnt > 0.
SELECT SINGLE lafdn FROM mhnk
INTO DATA(lv_dunning_date)
WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
gs_event_log-activityname = 'Payment Reminder Issued'.
gs_event_log-username = 'System'.
CONVERT DATE lv_dunning_date INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Parked (Example from VBKPF, may require system specific logic)
SELECT SINGLE cpudt, cputm, usnam FROM vbkpf
INTO (DATA(lv_park_date), DATA(lv_park_time), DATA(lv_park_user))
WHERE awkey = gs_invoice-vbeln AND awsys = 'LOG' AND bstat = 'V'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Parked'.
gs_event_log-username = lv_park_user.
CONVERT DATE lv_park_date TIME lv_park_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Dispute Case Created (Requires Dispute Management module)
SELECT SINGLE create_date, create_time, create_user FROM udm_case_attr00
INTO (DATA(lv_disp_date), DATA(lv_disp_time), DATA(lv_disp_user))
WHERE [Your logic to link invoice to dispute case, e.g., via a custom field or object link].
IF sy-subrc = 0.
gs_event_log-activityname = 'Dispute Case Created'.
gs_event_log-username = lv_disp_user.
CONVERT DATE lv_disp_date TIME lv_disp_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
*&---------------------------------------------------------------------*
*& Write data to file
*&---------------------------------------------------------------------*
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
" Header
DATA(lv_header) = 'InvoiceNumber,ActivityName,EventTime,UserName,BillingDocumentType,CustomerNumber,CompanyCode,TotalInvoiceAmount'.
TRANSFER lv_header TO p_path.
LOOP AT gt_event_log INTO gs_event_log.
DATA(lv_line) = |
{ gs_event_log-invoicenumber }|
,{ gs_event_log-activityname }|
,{ gs_event_log-eventtime }|
,{ gs_event_log-username }|
,{ gs_event_log-billingdocumenttype }|
,{ gs_event_log-customernumber }|
,{ gs_event_log-companycode }|
,{ gs_event_log-totalinvoiceamount }|.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: 'Extraction complete. File created at:', p_path. Étapes
- Prérequis et accès : Vérifiez que vous disposez d’un utilisateur de base de données avec un accès en lecture seule aux tables SAP ECC nécessaires, notamment VBRK, BKPF, BSAD, NAST, CDHDR, CDPOS, SCASE et les autres tables indiquées dans la requête. Cet accès est généralement réservé aux administrateurs système ou à certaines équipes d’analyse des données.
- Connectez-vous à la base de données : Utilisez un client SQL standard, tel que DBeaver, Oracle SQL Developer ou Microsoft SQL Server Management Studio, pour vous connecter à la base de données SAP ECC.
- Préparez la requête SQL : Copiez la requête SQL complète fournie dans la section « query » dans l’éditeur de votre client SQL.
- Remplacez les espaces réservés : La requête contient plusieurs espaces réservés à remplacer par des valeurs propres à votre environnement :
'YYYYMMDD': remplacez chaque occurrence par les dates de début et de fin de la période à analyser. Il est essentiel de limiter la période pour conserver un volume de données raisonnable.'XXXX': remplacez cette valeur par le ou les codes société à analyser.[Your Invoice Output Type]: indiquez le code de type de sortie utilisé pour envoyer les factures aux clients, par exemple « RD00 ».[Your Bad Debt G/L Account]: saisissez le numéro du compte général utilisé pour passer en perte les factures irrécouvrables.[Your Dispute Case Invoice Attribute]: indiquez le nom de l’attribut qui stocke le numéro de facture dans votre configuration Dispute Management, par exemple « INVOICE_ID ».
- Vérifiez les fonctions d’horodatage : La requête utilise la syntaxe générique
CAST(CONCAT(date_field, time_field) AS TIMESTAMP). Vous devrez peut-être l’adapter à votre système de base de données, par exemple en utilisantTO_TIMESTAMPpour Oracle ouDATETIMEFROMPARTSpour SQL Server. - Exécutez la requête : Lancez la requête modifiée. Selon le volume des tables SAP et la période sélectionnée, son exécution peut prendre un certain temps.
- Vérifiez les résultats : Une fois la requête terminée, vérifiez que les colonnes attendues sont présentes : InvoiceNumber, ActivityName, EventTime et les attributs recommandés. Repérez les éventuelles erreurs ou l’absence de résultats.
- Exportez au format CSV : Exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Enregistrez-le en UTF-8 afin d’éviter les problèmes liés aux caractères spéciaux.
- Préparez l’importation : Avant d’importer le fichier dans un outil de Process Mining, vérifiez que les en-têtes des colonnes CSV correspondent exactement aux noms d’attributs requis, par exemple
InvoiceNumber,ActivityName,EventTimeetUserName.
Configuration
- Connexion à la base de données : Une connexion SQL directe en lecture seule à la base de données SAP ECC sous-jacente est nécessaire. Cette méthode contourne entièrement la couche applicative SAP.
- Autorisations : L’utilisateur de la base de données doit disposer des autorisations
SELECTsur toutes les tables utilisées dans la requête, qui relèvent des modules FI, SD et éventuellement FSCM. - Plage de dates : Il est essentiel de limiter la requête à une période précise pour garantir des performances satisfaisantes et maîtriser le volume de données. Nous recommandons de commencer par une période de 3 à 6 mois. Les espaces réservés de filtre de date
'YYYYMMDD'doivent être renseignés à plusieurs endroits dans la requête. - Filtre par code société : La requête doit être filtrée par code société (
BUKRS). Il est courant d’analyser un ou quelques codes société à la fois. - Configuration des types de document : La logique d’identification des événements, tels que les corrections de facture, les passages en perte ou l’envoi de documents, dépend de la configuration SAP standard. Vous devrez peut-être adapter la requête si votre organisation utilise des types de document personnalisés (
BLART), des types de sortie (KSCHL) ou des comptes généraux spécifiques à ces processus. - Performances : L’exécution de cette requête sur un système SAP de production en service peut mobiliser des ressources importantes et affecter les performances opérationnelles. Il est vivement recommandé d’effectuer les extractions volumineuses en dehors des heures de pointe ou sur une réplique de la base dédiée aux rapports.
Exemple de requête sql
WITH InvoiceBase AS (
SELECT
VBRK.VBELN AS InvoiceNumber,
VBRK.FKART AS BillingDocumentType,
VBRK.KUNRG AS CustomerNumber,
VBRK.BUKRS AS CompanyCode,
VBRK.NETWR AS TotalInvoiceAmount,
VBRK.ERNAM AS CreatorName,
VBRK.ERDAT AS CreationDate,
VBRK.ERZET AS CreationTime
FROM VBRK
WHERE VBRK.ERDAT BETWEEN '20230101' AND '20231231' -- Filter by Invoice Creation Date
AND VBRK.BUKRS IN ('1000') -- Filter by Company Code
AND VBRK.FKART NOT IN ('S1', 'S2') -- Exclude cancelled invoices
)
-- 1. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS ActivityName,
CAST(CONCAT(ib.CreationDate, ib.CreationTime) AS TIMESTAMP) AS EventTime,
ib.CreatorName AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM InvoiceBase ib
UNION ALL
-- 2. Invoice Parked
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Parked' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = 'V' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 3. Invoice Posted
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Posted' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = '' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 4. Invoice Approved (from Parked to Posted)
SELECT
SUBSTRING(h.OBJECTID, 4, 10) AS InvoiceNumber,
'Invoice Approved' as ActivityName,
CAST(CONCAT(h.UDATE, h.UTIME) AS TIMESTAMP) AS EventTime,
h.USERNAME AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM CDHDR h
JOIN CDPOS p ON h.MANDANT = p.MANDANT AND h.OBJECTCLAS = p.OBJECTCLAS AND h.OBJECTID = p.OBJECTID AND h.CHANGENR = p.CHANGENR
JOIN InvoiceBase ib ON SUBSTRING(h.OBJECTID, 4, 10) = ib.InvoiceNumber
WHERE h.OBJECTCLAS = 'BELEGV'
AND p.TABNAME = 'BKPF'
AND p.FNAME = 'BSTAT'
AND p.VALUE_OLD = 'V'
AND p.VALUE_NEW = ' '
AND h.UDATE BETWEEN '20230101' AND '20231231'
UNION ALL
-- 5. Invoice Sent To Customer
SELECT
n.OBJKY AS InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
CAST(CONCAT(n.DATVR, n.UHRVR) AS TIMESTAMP) AS EventTime,
n.VSTAT AS UserName, -- User who processed is not directly available, using processing status as a proxy
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM NAST n
JOIN InvoiceBase ib ON n.OBJKY = ib.InvoiceNumber
WHERE n.KSCHL = '[Your Invoice Output Type]' -- E.g., 'RD00'
AND n.VSTAT = '1' -- Processed successfully
AND n.DATVR BETWEEN '20230101' AND '20231231'
UNION ALL
-- 6. Invoice Corrected (Reversed)
SELECT
SUBSTRING(orig_doc.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Corrected' AS ActivityName,
CAST(CONCAT(rev_doc.CPUDT, rev_doc.CPUTM) AS TIMESTAMP) AS EventTime,
rev_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
rev_doc.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF orig_doc
JOIN BKPF rev_doc ON orig_doc.STBLG = rev_doc.BELNR AND orig_doc.BUKRS = rev_doc.BUKRS AND orig_doc.GJAHR = rev_doc.STJAH
JOIN InvoiceBase ib ON SUBSTRING(orig_doc.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE orig_doc.AWTYP = 'VBRK' AND orig_doc.STBLG IS NOT NULL AND rev_doc.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 7. Invoice Due Date Reached
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Due Date Reached' AS ActivityName,
CAST(CONCAT(bs.ZFBDT, '000000') AS TIMESTAMP) AS EventTime,
'System' AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSEG bs
JOIN BKPF b ON bs.MANDT = b.MANDT AND bs.BUKRS = b.BUKRS AND bs.BELNR = b.BELNR AND bs.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND bs.KOART = 'D' AND bs.ZFBDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 8. Payment Reminder Issued
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(CONCAT(h.LAUFD, '000000') AS TIMESTAMP) AS EventTime,
h.LAUFI AS UserName, -- Dunning Run ID
ib.BillingDocumentType,
ib.CustomerNumber,
d.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM MHND d
JOIN MHNK h ON d.MANDT = h.MANDT AND d.LAUFD = h.LAUFD AND d.LAUFI = h.LAUFI
JOIN BKPF b ON d.MANDT = b.MANDT AND d.BUKRS = b.BUKRS AND d.BELNR = b.BELNR AND d.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE h.LAUFD BETWEEN '20230101' AND '20231231'
UNION ALL
-- 9. Dispute Case Created
SELECT
attr.ATTR_VALUE AS InvoiceNumber,
'Dispute Case Created' AS ActivityName,
sc.CREATE_TIME AS EventTime,
sc.CREATED_BY AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM SCMG_T_CASE_ATTR attr
JOIN SCASE sc ON attr.CASE_GUID = sc.CASE_GUID
JOIN InvoiceBase ib ON attr.ATTR_VALUE = ib.InvoiceNumber
WHERE attr.ATTR_NAME = '[Your Dispute Case Invoice Attribute]' -- e.g., 'INVOICE_ID'
AND CAST(sc.CREATE_TIME AS DATE) BETWEEN '20230101' AND '20231231'
UNION ALL
-- 10, 11, 12. Clearing Events (Payment, Clearing, Write-Off)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
BillingDocumentType,
CustomerNumber,
CompanyCode,
TotalInvoiceAmount
FROM (
SELECT
bsad.XBLNR AS InvoiceNumber,
CASE
WHEN clearing_item.HKONT = '[Your Bad Debt G/L Account]' THEN 'Invoice Written Off'
ELSE 'Customer Payment Received'
END AS ActivityName,
CAST(CONCAT(clearing_doc.CPUDT, clearing_doc.CPUTM) AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
LEFT JOIN BSEG clearing_item ON clearing_doc.MANDT = clearing_item.MANDT AND clearing_doc.BUKRS = clearing_item.BUKRS AND clearing_doc.BELNR = clearing_item.BELNR AND clearing_doc.GJAHR = clearing_item.GJAHR AND clearing_item.HKONT = '[Your Bad Debt G/L Account]' -- e.g. '148000'
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Payment Applied To Invoice' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '000000') AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Invoice Cleared' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '235959') AS TIMESTAMP) AS EventTime, -- Add time to separate from 'Payment Applied'
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
) AS ClearingEvents Étapes
- Prérequis : Vérifiez que vous disposez d’une licence pour un outil ETL doté d’un connecteur SAP certifié, par exemple Informatica PowerCenter avec SAP Connector ou Talend avec SAP Connector. Assurez-vous que vos identifiants SAP disposent des autorisations nécessaires pour lire les tables financières, commerciales et système requises (BKPF, BSEG, VBRK, NAST, MHNK, UDM_CASE_ATTR00, CDHDR, CDPOS).
- Établissez la connexion SAP : Dans votre outil ETL, créez une connexion à votre système SAP ECC. Renseignez les informations de connexion : serveur d’applications, numéro de système, client, utilisateur et mot de passe. Testez la connexion.
- Définissez les sources de données : Pour chaque activité à extraire, définissez les tables SAP correspondantes comme sources de données dans votre tâche ETL. Par exemple, ajoutez VBRK pour la création des factures, BKPF pour les événements de comptabilisation et NAST pour les communications avec les clients.
- Créez la logique d’extraction pour chaque activité : Créez un flux de données ou une transformation distincte pour chacune des 13 activités requises. Dans chaque flux, appliquez des filtres pour sélectionner les enregistrements pertinents, par exemple le code société (BUKRS), le type de document (BLART) et une plage de dates précise (comme la date de création ERDAT).
- Associez les champs et transformez les données : Dans chaque flux, associez les champs des tables SAP sources à la structure cible du journal d’événements : InvoiceNumber, ActivityName, EventTime, UserName et les autres attributs recommandés. Utilisez des transformations pour définir la valeur d’« ActivityName » propre à chaque flux et mettre les dates et horodatages au bon format.
- Traitez les activités complexes : Pour les événements calculés, comme « Date d’échéance de la facture atteinte », calculez la date d’échéance à partir de la date de paiement de référence (ZFBDT) et des conditions de paiement, ou récupérez directement la date d’échéance nette (NETDT) dans BSEG. Pour les événements issus des journaux de modifications, comme « Facture approuvée », vous devrez peut-être joindre des tables telles que BKPF et CDHDR/CDPOS à partir du numéro et de la date du document.
- Regroupez les données des activités : Utilisez une transformation « Union » ou « Merge » dans votre outil ETL pour réunir les résultats des 13 flux dans un seul jeu de données. Avant cette opération, vérifiez que les noms de colonnes et les types de données sont cohérents dans tous les flux.
- Configurez la destination : Définissez la destination finale du journal d’événements. Il peut s’agir d’un fichier plat (CSV), d’une table de base de données ou d’une connexion directe à une zone de préparation.
- Planifiez l’extraction : Configurez les paramètres de plage de dates. Pour le chargement initial, vous pouvez extraire 6 à 12 mois de données. Pour les chargements différentiels suivants, configurez la tâche afin qu’elle récupère les données depuis la date de la dernière exécution.
- Exécutez et exportez : Lancez la tâche ETL. Une fois l’exécution terminée, vérifiez que le fichier de sortie respecte le format requis. Le résultat doit être un fichier CSV unique, chaque ligne correspondant à un événement distinct, prêt à être importé dans ProcessMind.
Configuration
- Connexion SAP : Une connexion au serveur d’applications du système SAP ECC cible est nécessaire. L’utilisateur SAP doit disposer d’un accès RFC et des autorisations requises pour les tables telles que VBRK, BKPF, BSEG, NAST et les autres tables indiquées dans la requête.
- Licence de l’outil ETL : Une licence valide pour l’outil ETL commercial et son connecteur SAP spécifique est obligatoire.
- Plage de dates : Il est recommandé d’extraire 3 à 6 mois de données pour obtenir un échantillon représentatif sans imposer une charge excessive au système. Utilisez un paramètre configurable pour les dates de début et de fin.
- Filtres principaux : Filtrez toujours par code société (BUKRS) pour limiter le périmètre de l’extraction. Il est également essentiel de filtrer par types de document de facturation pertinents (VBRK-FKART) et types de pièces comptables (BKPF-BLART), afin de conserver les factures standard et d’exclure les autres types de documents, tels que les avoirs ou les documents internes.
- Performances : L’extraction de grandes tables comme BSEG peut être lente. Utilisez des filtres sélectifs, évitez d’extraire les champs inutiles et planifiez l’extraction en dehors des heures de pointe pour limiter son impact sur les performances du système SAP source.
Exemple de requête config
// ETL Data Extraction Logic for SAP Order-to-Cash Invoicing
// This represents the configuration logic within a graphical ETL tool.
// == Global Parameters ==
// $StartDate: '[Start Date]' (e.g., '2023-01-01')
// $EndDate: '[End Date]' (e.g., '2023-06-30')
// $CompanyCodes: '[Company Code(s)]' (e.g., '1000', '2000')
// $BillingDocTypes: '[Billing Document Type(s)]' (e.g., 'F1', 'F2')
// == Source 1: Invoice Generated ==
// Tables: VBRK
DATA_SOURCE generated_invoices FROM VBRK WHERE
ERDAT >= $StartDate AND ERDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND FKART IN ($BillingDocTypes)
MAP {
InvoiceNumber: VBELN,
ActivityName: 'Invoice Generated',
EventTime: ERDAT + ERZET, // Combine date and time
UserName: ERNAM,
BillingDocumentType: FKART,
CustomerNumber: KUNAG,
CompanyCode: BUKRS,
TotalInvoiceAmount: NETWR
}
// == Source 2: Invoice Posted ==
// Tables: BKPF joined with VBRK
DATA_SOURCE posted_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Posted',
EventTime: A.BUDAT + A.CPUTM, // Posting date and entry time
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 3: Invoice Parked ==
// Tables: BKPF joined with VBRK
DATA_SOURCE parked_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.CPUDT >= $StartDate AND A.CPUDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = 'V'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Parked',
EventTime: A.CPUDT + A.CPUTM,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 4: Invoice Approved (Transition from Parked to Posted) ==
// Tables: BKPF joined with VBRK
DATA_SOURCE approved_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
AND EXISTS (SELECT 1 FROM VBELEGV C WHERE C.BELNR = A.BELNR) // Check if it was ever parked
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Approved',
EventTime: A.BUDAT + A.CPUTM, // Use posting date as approval date
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 5: Invoice Sent To Customer ==
// Tables: NAST joined with VBRK
DATA_SOURCE sent_invoices FROM NAST as A
INNER JOIN VBRK as B ON (A.OBJKY = B.VBELN)
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND B.BUKRS IN ($CompanyCodes)
AND A.VSTAT = '1' // Successfully processed
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Sent To Customer',
EventTime: A.ERDAT + A.ERUHR,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: B.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 6: Invoice Corrected (Reversed) ==
// Tables: VBRK (for the reversal document)
DATA_SOURCE corrected_invoices FROM VBRK as A
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.SFAKN <> '' // SFAKN is the original cancelled invoice
MAP {
InvoiceNumber: A.SFAKN, // Case ID is the original invoice
ActivityName: 'Invoice Corrected',
EventTime: A.ERDAT + A.ERZET,
UserName: A.ERNAM,
BillingDocumentType: A.FKART,
CustomerNumber: A.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: NULL // Amount belongs to the reversal doc, not original
}
// == Source 7: Invoice Due Date Reached ==
// Tables: BSEG joined with VBRK
DATA_SOURCE due_invoices FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.NETDT >= $StartDate AND A.NETDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.KOART = 'D' // Customer line item
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Due Date Reached',
EventTime: A.NETDT, // Net due date
UserName: 'System',
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 8: Payment Reminder Issued ==
// Tables: MHNK, MHND, VBRK
DATA_SOURCE reminders FROM MHNK as A
INNER JOIN MHND as D ON (A.LAUFD = D.LAUFD AND A.LAUFI = D.LAUFI)
INNER JOIN VBRK as B ON (SUBSTRING(D.XBLNR, 1, 10) = B.VBELN) // XBLNR may need parsing
WHERE A.LAUFD >= $StartDate AND A.LAUFD <= $EndDate
AND D.BUKRS IN ($CompanyCodes)
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Reminder Issued',
EventTime: A.LAUFD, // Dunning date
UserName: A.IDAPS,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: D.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 9: Dispute Case Created ==
// Tables: UDM_CASE_ATTR00
DATA_SOURCE disputes FROM UDM_CASE_ATTR00 as A
WHERE A.CREATE_TIMESTAMP >= $StartDate // Timestamp format may vary
AND A.FIN_COMP_CODE IN ($CompanyCodes)
AND A.PROCESS = 'FIN_FSCM_DIS'
MAP {
InvoiceNumber: A.BILL_DOC_ID,
ActivityName: 'Dispute Case Created',
EventTime: A.CREATE_TIMESTAMP,
UserName: A.CREATE_USER,
BillingDocumentType: NULL,
CustomerNumber: A.BP_NUMBER,
CompanyCode: A.FIN_COMP_CODE,
TotalInvoiceAmount: A.DISPUTED_AMOUNT
}
// == Source 10: Customer Payment Received ==
// Tables: BKPF
DATA_SOURCE payments FROM BKPF
WHERE BUDAT >= $StartDate AND BUDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND BLART = 'DZ' // Example for Customer Payment
MAP {
InvoiceNumber: NULL, // Invoice not yet known
ActivityName: 'Customer Payment Received',
EventTime: BUDAT + CPUTM,
UserName: USNAM,
BillingDocumentType: NULL,
CustomerNumber: NULL, // Requires join to BSEG to get customer
CompanyCode: BUKRS,
TotalInvoiceAmount: NULL
}
// == Source 11 & 12: Payment Applied To Invoice & Invoice Cleared ==
// Tables: BSEG joined with VBRK
DATA_SOURCE cleared_items FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.AUGBL <> ''
// Generate two records from this source
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Applied To Invoice',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM, // User from header of original invoice doc
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
UNION WITH {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Cleared',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 13: Invoice Written Off ==
// Tables: BSEG (for the invoice line) and BKPF (for clearing doc type)
DATA_SOURCE written_off FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
INNER JOIN BKPF as C ON (A.AUGBL = C.BELNR AND A.BUKRS = C.BUKRS AND A.AUGGJ = C.GJAHR)
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND C.BLART = '[Your Write-Off Document Type]' // e.g., 'AB'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Written Off',
EventTime: A.AUGDT,
UserName: C.USNAM, // User who posted the write-off
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Final Union of all sources ==
OUTPUT generated_invoices
UNION ALL posted_invoices
UNION ALL parked_invoices
UNION ALL approved_invoices
UNION ALL sent_invoices
UNION ALL corrected_invoices
UNION ALL due_invoices
UNION ALL reminders
UNION ALL disputes
UNION ALL payments
UNION ALL cleared_items
UNION ALL written_off Prêt à commencer ?
Utilisez ce modèle pour préparer vos données plus simplement et mieux comprendre votre processus de facturation. Commencez dès aujourd’hui à accélérer vos encaissements.
Accélérez vos encaissements : optimisez votre facturation dès aujourd’hui !
Réduisez les inefficacités, diminuez le temps de cycle de 30 % et améliorez votre trésorerie.
Aucune carte bancaire requise. Commencez à optimiser vos processus en quelques minutes.