Votre template de données Order-to-Cash - Facturation
Votre template de données Order-to-Cash - Facturation
- Attributs recommandés pour une analyse approfondie
- Étapes clés du processus et jalons à suivre
- Guide pratique d'extraction de données pour SAP ECC
Attributs Commande au paiement - Facturation
| Nom | Description | ||
|---|---|---|---|
| Activité ActivityName | Le nom de l'événement commercial ou de l'étape qui s'est produit au sein du cycle de vie de la facture. | ||
| Description Cet attribut décrit une action ou un changement de statut spécifique dans le processus de facturation, tel que « Facture générée », « Facture enregistrée » ou « Paiement client reçu ». Ces activités sont dérivées conceptuellement de divers événements système, de changements de statut dans les documents ou de codes de transaction spécifiques exécutés par les utilisateurs. La séquence de ces activités forme le flux de processus, qui est la base de l'analyse du Process Mining. En examinant les activités, les organisations peuvent comprendre quelles étapes sont prises, dans quel ordre et à quelle fréquence, révélant l'exécution réelle du processus par rapport au processus conçu. Pourquoi c'est important Il définit les étapes de la cartographie des processus, permettant la visualisation et l'analyse des flux de processus, des écarts et des goulots d'étranglement. Où obtenir Ceci est un attribut conceptuel dérivé de multiples sources, telles que les codes de transaction (CDHDR-TCODE), les changements de statut de document (VBUK-FKSTK) et les enregistrements de documents comptables. Exemples Facture généréeFacture comptabiliséeRelance de paiement émiseFacture apurée | |||
| Heure de début EventTime | L'horodatage indiquant quand une activité ou un événement spécifique s'est produit. | ||
| Description L'horodatage de l'événement (Event Time) capture la date et l'heure précises de chaque activité dans le cycle de vie de la facture. Cet horodatage est fondamental pour toutes les analyses basées sur le temps en Process Mining, y compris le calcul des temps de cycle, l'identification des goulets d'étranglement et le suivi des performances des 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), avec un champ d'heure (UZEIT) provenant de diverses tables SAP qui enregistrent les modifications ou la création de documents. Des horodatages précis sont essentiels pour construire un journal d'événements (event log) fiable et garantir la validité de toute analyse de performance. Pourquoi c'est important Cet attribut est le fondement de toute analyse de performance, permettant le calcul des temps de cycle, des durées et des temps d'attente entre les étapes du processus. Où obtenir Construit à partir de divers champs de date et d'heure dans plusieurs tables, tels que BKPF (BUDAT, CPUTM), VBRK (ERDAT, ERZET) et les tables de journaux de modifications comme CDHDR (UDATE, UTIME). Exemples 2023-04-15T10:30:00Z2023-04-16T11:00:00Z2023-05-20T09:00:00Z | |||
| Numéro de facture InvoiceNumber | L'identifiant unique du document de facturation, servant de Case ID principal pour le processus de facturation. | ||
| Description Le numéro de facture, connu sous le nom de numéro de document de facturation dans SAP, identifie de manière unique chaque facture. En Process Mining, il agit comme le CaseId, regroupant toutes les activités connexes telles que la création, l'enregistrement, l'envoi, le paiement et le lettrage en une seule instance de processus de bout en bout. L'analyse des processus par numéro de facture permet une vue complète du cycle de vie de chaque transaction de facturation, de sa création à son règlement final. Ceci est crucial pour le calcul d'indicateurs clés de performance tels que les jours de créances clients (DSO) et le temps de cycle global des factures, fournissant une base claire pour la mesure et l'amélioration des performances. Pourquoi c'est important C'est la clé essentielle pour suivre l'intégralité du parcours d'une facture, permettant l'analyse des temps de cycle, des goulots d'étranglement et des variations pour chaque transaction de facturation individuelle. Où obtenir Table SAP ECC : VBRK, Champ : VBELN Exemples 90001234900012359000123690001237 | |||
| Code société CompanyCode | L'identifiant de l'entité juridique qui a émis la facture. | ||
| Description Le code société représente une unité juridique et comptable indépendante dans SAP. Toutes les transactions financières, y compris les factures, sont enregistrées dans un code société spécifique. C'est un élément de données organisationnel fondamental. Dans un contexte de Process Mining, le code société est utilisé pour analyser et comparer la performance du processus de facturation entre différentes entités juridiques au sein d'une entreprise. Cela aide à identifier les meilleures pratiques dans une entité qui pourraient être appliquées à d'autres et garantit que l'analyse respecte la structure organisationnelle de l'entreprise. Pourquoi c'est important Permet de filtrer et de comparer les processus entre différentes entités juridiques, ce qui est fondamental pour l'analyse financière et l'évaluation comparative organisationnelle. Où obtenir Table SAP ECC : VBRK, Champ : BUKRS Exemples 10002000US01DE01 | |||
| Montant total de la facture TotalInvoiceAmount | La valeur nette totale du document de facturation. | ||
| Description Cet attribut représente le montant net total de la facture, hors taxes. Le montant de la facture est une donnée financière critique associée au processus de facturation. Il est utilisé dans diverses analyses, telles que la segmentation des factures en catégories de grande et faible valeur pour voir si leurs flux de processus diffèrent. Il peut également être utilisé pour prioriser les efforts de recouvrement ou pour enquêter sur les raisons pour lesquelles les factures de grande valeur prennent plus de temps à être approuvées ou payées. Ce contexte financier ajoute une couche de profondeur significative à l'analyse des processus. Pourquoi c'est important Fournit un contexte financier essentiel, permettant une analyse basée sur la valeur des factures, comme l'identification si les factures de grande valeur suivent un processus différent ou mettent plus de temps à être lettrées. Où obtenir Table SAP ECC : VBRK, Champ : NETWR Exemples 1500.7525000.00500.0012345.67 | |||
| Nom d'utilisateur UserName | L'ID de l'utilisateur qui a exécuté l'activité ou créé le document. | ||
| Description Cet attribut capture l'ID utilisateur SAP responsable d'un événement donné, comme la création d'une facture ou l'enregistrement d'un paiement. Il est essentiel pour analyser l'élément humain du processus. Avec ces données, il est possible d'étudier les variations de performance entre les utilisateurs ou les équipes, d'identifier les besoins en formation et de détecter les problèmes de conformité potentiels. Il est également utilisé pour différencier les activités manuelles effectuées par les utilisateurs humains et les étapes automatisées exécutées par les utilisateurs système ou de traitement par lots, ce qui est clé pour le calcul des taux d'automatisation. Pourquoi c'est important Permet l'analyse des performances des utilisateurs, la répartition de la charge de travail et aide à distinguer les activités manuelles des activités automatisées, soutenant les initiatives d'automatisation et d'efficacité. Où obtenir 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 | Un numéro unique qui identifie le client à qui la facture est émise. | ||
| Description Le numéro client relie une facture à un client ou partenaire commercial spécifique. Cet attribut est essentiel pour segmenter et analyser le processus de facturation en fonction des caractéristiques du client. Les analystes peuvent utiliser ce champ pour comparer les jours de créances clients (DSO) entre différents clients, identifier quels clients paient fréquemment en retard, ou analyser la conformité aux conditions de paiement. Comprendre ces schémas est crucial pour gérer les relations client et améliorer les stratégies de recouvrement adaptées aux différents segments de clientèle. Pourquoi c'est important Permet une analyse centrée sur le client, aidant à identifier les comportements de paiement, à évaluer le DSO par client et à adapter les stratégies de recouvrement. Où obtenir Table SAP ECC : VBRK, Champ : KUNRG (Payeur) ou KUNAG (Client donneur d'ordre). Exemples 100023200541CUST-A487910345 | |||
| Type de Document de Facturation BillingDocumentType | Un code qui catégorise le type de document de facturation, tel qu'une facture, un avoir ou une note de débit. | ||
| Description Le type de document de facturation classe les transactions en catégories distinctes basées sur leur objectif commercial. Par exemple, 'F2' est une facture client standard, tandis que 'G2' représente une note de crédit. Cette classification est configurée dans SAP pour contrôler la manière dont les différents documents de facturation sont traités. Pour le Process Mining, cet attribut est essentiel pour filtrer et comparer différents scénarios de facturation. Les analystes peuvent examiner le processus pour les factures standard séparément des notes de crédit afin de comprendre leurs flux uniques, leurs temps de cycle et leurs défis, conduisant à des améliorations de processus plus ciblées. Pourquoi c'est important Permet la segmentation et l'analyse de différents processus de facturation, tels que les factures standard par rapport aux avoirs, qui ont souvent des flux de processus très différents. Où obtenir Table SAP ECC : VBRK, Champ : FKART Exemples F2G2L2IV | |||
| Code de transaction TransactionCode | Le code de transaction SAP utilisé pour exécuter une activité. | ||
| Description Le code de transaction, ou T-Code, est un identifiant unique pour une fonction ou un programme spécifique dans SAP, tel que 'VF01' pour la création d'un document de facturation. La capture du T-Code pour chaque événement fournit une vue technique, au niveau du système, de la façon dont un processus a été exécuté. Cette information est très précieuse pour l'analyse des causes profondes. Par exemple, si les erreurs sont courantes, les analystes peuvent vérifier si un code de transaction non standard est utilisé. Cela aide également à dériver le nom de l'activité et à comprendre quelles fonctionnalités du système sont utilisées dans le processus. Pourquoi c'est important Fournit le contexte technique de la façon dont une activité a été réalisée, permettant une analyse des causes profondes des écarts de processus et aidant à identifier les actions utilisateur non standard. Où obtenir Table SAP ECC : CDHDR, Champ : TCODE Exemples VF01VF02FB01F-28 | |||
| Conditions de paiement PaymentTerms | Les conditions selon lesquelles un vendeur conclura une vente, y compris le calendrier de paiement. | ||
| Description Les conditions de paiement définissent les règles relatives à l'échéance d'un paiement, telles que 'Net 30' ou 'Net 60'. Ces conditions sont convenues avec le client et constituent un facteur clé dans la détermination de la trésorerie. L'analyse du processus par conditions de paiement peut révéler si certaines conditions sont associées à des cycles de paiement plus longs ou à des taux plus élevés de paiements tardifs. Cette information peut aider l'entreprise à négocier de meilleures conditions avec les clients ou à ajuster sa planification financière. C'est également un intrant clé pour le calcul de la date d'échéance de la facture. Pourquoi c'est important Permet d'analyser le comportement de paiement des clients et l'impact sur la trésorerie en fonction des conditions négociées, offrant des perspectives pour optimiser les accords commerciaux. Où obtenir Table SAP ECC : VBRK, Champ : ZTERM Exemples Z030Z060Z001 | |||
| Date d'échéance de la facture InvoiceDueDate | La date à laquelle le client est censé effectuer le paiement. | ||
| Description La date d'échéance de la facture est la date limite de paiement telle que spécifiée par les conditions de paiement. Cette date est fondamentale pour la gestion des comptes clients et l'initiation des activités de recouvrement. Cet attribut est utilisé pour calculer le KPI du taux de paiement à temps en le comparant à la date de paiement réelle. L'analyse des factures par leur date d'échéance aide à la prévision de la trésorerie et à la priorisation des efforts de recouvrement pour les paiements à venir ou en retard. Elle est généralement dérivée de la date de référence et des conditions de paiement. Pourquoi c'est important C'est la référence pour mesurer la performance des paiements à temps et est essentielle pour la gestion des comptes clients et la prévision de la trésorerie. Où obtenir Calculé en fonction de la date de référence (BSEG-ZFBDT) et des conditions de paiement (BSEG-ZTERM). Il n'est pas toujours stocké dans un champ direct. Exemples 2023-05-152023-05-302023-06-20 | |||
| Date d'encaissement ClearingDate | La date à laquelle le paiement a été reçu et la facture a été lettrée des comptes clients. | ||
| Description La date de lettrage est la date à laquelle un poste non soldé, comme une facture, est marqué comme payé ou 'lettré' dans le système financier. Cette date représente effectivement le moment où les espèces sont considérées comme collectées et rapprochées. C'est l'une des dates les plus importantes du cycle Commande au paiement. Elle sert de point final pour le calcul des jours de créances clients (DSO) et du temps de cycle global de la facture à l'encaissement. L'analyse de la date de lettrage permet de mesurer l'efficacité du processus de recouvrement. Pourquoi c'est important Marque l'étape finale du cycle de vie de la facture, servant de date de fin pour le calcul du DSO et des temps de cycle globaux, et reflétant l'efficacité du recouvrement de trésorerie. Où obtenir Table SAP ECC : BSAD, Champ : AUGDT Exemples 2023-05-142023-06-012023-06-25 | |||
| Date de comptabilisation PostingDate | La date à laquelle le document est enregistré dans les livres comptables. | ||
| Description La date de comptabilisation détermine la période fiscale au cours de laquelle la transaction est enregistrée dans le Grand Livre Général. C'est une date critique pour la comptabilité et les rapports financiers. Les retards entre la date de création du document et la date de comptabilisation peuvent indiquer des inefficacités dans le traitement interne des documents de facturation. Du point de vue du Process Mining, la date de comptabilisation marque un jalon clé dans le cycle de vie de la facture. Le décalage entre la génération et la comptabilisation de la facture peut être un indicateur clé de performance pour l'efficacité du service de facturation. Pourquoi c'est important Marque un jalon financier clé et est crucial pour la comptabilité. Le décalage entre la création et l'enregistrement de la facture est une mesure clé de l'efficacité du traitement interne. Où obtenir Table SAP ECC : BKPF, Champ : BUDAT Exemples 2023-04-152023-04-172023-05-21 | |||
| Date du document DocumentDate | La date sur le document original, fournie par le vendeur ou le créateur. | ||
| Description La date du document est la date d'émission du document original. Pour la facturation, c'est généralement la date de création de la facture et elle est souvent utilisée comme base pour calculer la date d'échéance du paiement. Cette date est cruciale pour les rapports financiers et pour le calcul de métriques clés comme les jours de créances clients (DSO). Elle représente le point de départ de la période de recouvrement du point de vue du client. 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 c'est important Sert de référence pour le calcul de l'ancienneté des factures et du DSO, offrant un point de référence critique pour l'analyse financière et des conditions de paiement. Où obtenir 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 | Le timestamp de la dernière actualisation des données ou de l'extraction du système source. | ||
| Description Cet attribut indique la dernière fois que le jeu de données a été mis à jour à partir du système source. Il fournit un contexte crucial pour toute analyse, garantissant que les utilisateurs comprennent l'actualité des données qu'ils consultent. Dans les tableaux de bord et les rapports, cet horodatage informe les parties prenantes sur l'actualité des données et aide à gérer les attentes concernant la visibilité des transactions très récentes. Il est généralement généré à la fin du processus d'extraction des données. Pourquoi c'est important Informe les utilisateurs sur l'actualité des données, ce qui est essentiel pour prendre des décisions opérationnelles basées sur l'analyse. Où obtenir Généré et stocké pendant le processus d'extraction, transformation et chargement (ETL) des données. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Devise Currency | Le code de devise pour les montants spécifiés dans la facture. | ||
| Description Cet attribut indique la devise de la transaction, telle que USD, EUR ou JPY. Il fournit le contexte nécessaire pour toutes les valeurs monétaires, comme le montant total de la facture. Lors de l'analyse de données d'une organisation multinationale, le champ de devise est essentiel pour interpréter et convertir correctement les chiffres financiers. Il permet une génération de rapports cohérente et garantit que les montants ne sont pas agrégés sans conversion de devise appropriée, ce qui conduirait à une analyse financière incorrecte. Pourquoi c'est important Fournit le contexte nécessaire pour toutes les valeurs monétaires, assurant une analyse financière précise, en particulier dans un environnement multidevises. Où obtenir Table SAP ECC : VBRK, Champ : WAERK Exemples USDEURGBPJPY | |||
| Est Automatisé IsAutomated | Un indicateur signalant si une activité a été réalisée par un utilisateur système ou par 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érivé en comparant l'attribut Nom d'utilisateur à une liste d'ID utilisateur système ou de traitement par lots connus, comme 'BATCHUSER' ou 'SAPSYSTEM'. Cet indicateur est essentiel pour mesurer le niveau d'automatisation dans le processus de facturation, ce qui est un objectif clé pour de nombreuses organisations cherchant à améliorer l'efficacité et à réduire les coûts. Le KPI du taux de facturation automatisée est directement calculé à partir de cet attribut, aidant à suivre les progrès des initiatives d'automatisation. Pourquoi c'est important Soutient directement le calcul du taux de facturation automatisé, aidant à mesurer l'efficacité des processus et à suivre l'impact des projets d'automatisation. Où obtenir Dérivé de l'attribut Nom d'utilisateur. La logique serait quelque chose comme : SI UserName EST DANS ('BATCH', 'SYSTEM', 'RFCUSER') ALORS vrai SINON faux. Exemples truefaux | |||
| Est un retravail IsRework | Un indicateur signalant si une activité est une étape de retravail ou de correction. | ||
| Description Cet attribut calculé identifie les activités qui représentent du retravail, telles que « Facture corrigée » ou les annulations de documents. C'est typiquement un indicateur booléen dérivé du nom de l'activité ou des codes de transaction associés aux corrections et annulations, comme 'VF11' pour annuler un document de facturation. En Process Mining, cet indicateur est inestimable pour quantifier la quantité de retravail dans le processus de facturation. Il soutient directement les KPI comme le taux de correction des factures et aide à visualiser les boucles de retravail dans la cartographie des processus, mettant en évidence les inefficacités et les problèmes de qualité qui augmentent les coûts opérationnels et retardent les paiements. Pourquoi c'est important Aide à quantifier les inefficacités des processus et les problèmes de qualité en soulignant les efforts consacrés à la correction des erreurs, soutenant directement les KPI de retravail. Où obtenir Dérivé du nom de l'activité ou du code de transaction. Par exemple, SI ActivityName = 'Facture Corrigée' OU TransactionCode = 'VF11' ALORS vrai SINON faux. Exemples truefaux | |||
| Numéro de document de vente SalesDocumentNumber | L'identifiant de la commande client originale qui a conduit à la facture. | ||
| Description Cet attribut fournit un lien direct de la facture vers la commande client qui a initié la transaction. Cette traçabilité est cruciale pour une analyse de bout en bout complète du processus Commande au paiement. En connectant le processus de facturation au processus de commande client précédent, les organisations peuvent analyser le temps de cycle total de la commande client à l'encaissement. Cela aide à identifier si les retards de facturation sont causés par des problèmes de vente, d'exécution ou du département de facturation lui-même, offrant une vue plus holistique du processus. Pourquoi c'est important Relie le processus de facturation à la commande client, permettant une véritable analyse de bout en bout du processus Commande au paiement et aidant à identifier les retards inter-départementaux. Où obtenir Table SAP ECC : VBRP, Champ : VGBEL Exemples 100000451000004610000047 | |||
| Organisation commerciale SalesOrganization | L'unité organisationnelle responsable de la vente de produits ou de services. | ||
| Description L'organisation commerciale est une unité organisationnelle dans SAP responsable de la distribution de biens et de services et de la négociation des conditions de vente. C'est un champ clé pour structurer les opérations de vente et de distribution. En Process Mining, cet attribut permet l'analyse du processus de facturation du point de vue de la structure des ventes. Il permet la comparaison des performances entre différentes organisations commerciales, aidant à identifier quelles régions ou lignes d'affaires sont plus efficaces dans leurs processus de facturation et soutenant les initiatives de standardisation des meilleures pratiques. Pourquoi c'est important Permet l'analyse comparative des performances entre différentes divisions de vente ou régions, aidant à identifier les meilleures pratiques et les domaines d'amélioration. Où obtenir Table SAP ECC : VBRK, Champ : VKORG Exemples 1000NA01EU01AP01 | |||
| Système source SourceSystem | Identifie le système source d'où les `données` ont été extraites. | ||
| Description Cet attribut spécifie le système d'enregistrement d'où proviennent les données. Dans un environnement d'entreprise avec plusieurs instances ERP ou systèmes intégrés, ce champ aide à distinguer les données provenant de différentes sources. Pour le Process Mining, il est essentiel pour la validation des données et pour les analyses qui comparent les processus entre différents systèmes ou unités organisationnelles. Il est généralement renseigné comme une valeur statique pendant le processus d'extraction de données pour étiqueter le jeu de données. Pourquoi c'est important Fournit le contexte de l'origine des données, ce qui est crucial dans les environnements multi-systèmes pour garantir l'intégrité des données et permettre une analyse spécifique au système. Où obtenir Ceci est généralement une valeur statique ajoutée pendant le processus d'extraction, de transformation et de chargement (ETL) des données, identifiant l'instance SAP ECC spécifique (par exemple, 'ECC_PROD_NA'). Exemples SAP_ECC_PRODECC_EU_100SAP_US_FIN | |||
Activités Commande au paiement - Facturation
| Activité | Description | ||
|---|---|---|---|
| Facture apurée | Le statut final d'une facture payée avec succès, indiquant que le poste non soldé a été clôturé par un paiement ou une note de crédit correspondante. La facture est considérée comme entièrement réglée. | ||
| Pourquoi c'est important Marque l'achèvement réussi du cycle Commande au paiement pour une facture. C'est l'événement de fin principal pour mesurer le temps de cycle moyen global des factures. Où obtenir Se produit lorsque les champs document de lettrage (AUGBL) et date de lettrage (AUGDT) sont renseignés pour le poste de facture dans la table BSEG. Capture L'événement se produit à la date de compensation (AUGDT) enregistrée dans la table BSEG pour le poste de facture. Type d'événement explicit | |||
| Facture comptabilisée | La facture est formellement enregistrée dans le sous-grand livre des comptes clients et le grand livre général. Cet événement rend la facture juridiquement contraignante et reflète la dette due par le client. | ||
| Pourquoi c'est important C'est un jalon critique qui lance officiellement le décompte du recouvrement. Le temps entre la génération et l'enregistrement peut mettre en évidence des retards de traitement internes affectant la trésorerie. Où obtenir Enregistré dans la table BKPF. La date de comptabilisation (BUDAT) pour le numéro de document (BELNR) marque cet événement. Pour les documents comptables temporaires, c'est à ce moment qu'il est converti en document enregistré. Capture À partir de la date de comptabilisation (BUDAT) dans la table BKPF pour le document de facture. Type d'événement explicit | |||
| Facture envoyée au client | Indique que la facture a été expédiée au client via un canal de sortie défini comme l'impression, l'e-mail ou l'EDI. Ceci est généralement capturé à partir des journaux du système de gestion des sorties. | ||
| Pourquoi c'est important Cet événement est un jalon clé qui déclenche le décompte des conditions de paiement du client. Les retards ici impactent directement le moment où un paiement peut être attendu et affectent l'efficacité du recouvrement des paiements. Où obtenir Peut être déduit de la date et de l'heure de traitement dans la table de statut des messages (NAST) pour le type de sortie correspondant à la facture. Capture Déduit de l'entrée de table NAST avec le statut de traitement '1' (traité avec succès). Type d'événement inferred | |||
| Facture générée | Marque la création du document de facturation dans le système. Cet événement est capturé lorsqu'une nouvelle entrée est créée dans la table d'en-tête de document comptable (BKPF) avec un type de document spécifique pour les factures. | ||
| Pourquoi c'est important C'est le point de départ de l'ensemble du processus de facturation. L'analyse du temps à partir de cet événement aide à mesurer le temps de cycle de création de facture et constitue la base du calcul des jours de créances clients (DSO). Où obtenir Enregistré dans la table BKPF. La date de création (CPUDT) et l'heure (CPUTM) pour un numéro de document spécifique (BELNR) marquent cet événement. Le type de document (BLART) l'identifie comme une facture. Capture À partir de l'horodatage de création (CPUDT) dans la table BKPF pour le document de facture. Type d'événement explicit | |||
| Paiement client reçu | Un paiement a été reçu du client et comptabilisé dans le système comme encaissement ou dépôt bancaire. Cela crée un document de paiement distinct qui n'est pas encore appliqué à la facture spécifique. | ||
| Pourquoi c'est important C'est un jalon majeur dans le cycle de conversion de trésorerie. Le temps entre l'envoi de la facture et la réception du paiement est une composante principale des jours de créances clients (DSO). Où obtenir Enregistré comme 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. Capture À partir de la date de comptabilisation du document de paiement client dans BKPF. Type d'événement explicit | |||
| Cas de litige créé | Un litige formel a été enregistré contre la facture, généralement en raison de plaintes de clients. Ceci est enregistré dans le système de gestion des litiges SAP. | ||
| Pourquoi c'est important Identifie les factures à risque de paiement tardif et met en évidence les problèmes sous-jacents entraînant l'insatisfaction client. Cela marque le début d'un processus important de gestion des exceptions. Où obtenir Capturé à partir de la création d'un cas dans la table des cas de litige (UDM_CASE) lié au document comptable de la facture. Capture Enregistré lorsqu'un utilisateur crée un cas de litige via la transaction UDM_DISPUTE. Type d'événement explicit | |||
| Date d'échéance de la facture atteinte | Un événement calculé marquant le jour où le paiement de la facture est officiellement dû selon les conditions de paiement. Ce n'est pas une activité réalisée par un utilisateur ou un système, mais un point temporel critique. | ||
| Pourquoi c'est important Essentiel pour analyser le comportement de paiement et la conformité. C'est la base pour déterminer les paiements à temps ou en retard et calculer l'indicateur clé de performance (KPI) du taux de paiement à temps. Où obtenir Dérivé en comparant la date actuelle à la date d'échéance nette. La date d'échéance se trouve dans le champ BSEG-ZFBDT ou est calculée à partir de la date de référence et des conditions de paiement. Capture Comparer la date système avec le champ de la date d'échéance nette dans le poste de facture (BSEG). Type d'événement calculated | |||
| Facture approuvée | Représente l'approbation formelle de la facture, lui permettant d'être enregistrée ou envoyée au client. Ceci est souvent déduit lorsqu'un document comptable temporaire est converti en document enregistré. | ||
| Pourquoi c'est important Suit le workflow d'approbation interne, qui est une source courante de goulots d'étranglement. L'analyse de cette activité aide à soutenir le tableau de bord d'analyse des flux d'approbation des factures en identifiant les approbateurs lents. Où obtenir Peut être déduit de la transition d'un document du statut stationné (dans VBKPF) au statut comptabilisé (dans BKPF). Alternativement, si un système de workflow est utilisé, il peut s'agir d'un événement explicite dans les journaux de workflow. Capture Comparer la date de création du document stationné (VBKPF) à la date de comptabilisation du document final (BKPF). Type d'événement inferred | |||
| Facture corrigée | Représente une activité de retravail où une facture initiale s'est avérée incorrecte et a ensuite été annulée. Ceci est capturé en identifiant les documents d'annulation liés à la facture originale. | ||
| Pourquoi c'est important Met en évidence les inefficacités des processus et les problèmes de qualité. Une fréquence élevée de corrections signale des problèmes dans les données de vente ou de facturation en amont, soutenant le tableau de bord des taux de retravail et d'erreurs de facturation. Où obtenir Identifié en trouvant un document d'annulation où BKPF-STBLG pointe vers le document original. La création de ce document d'annulation est l'événement. Capture Enregistré lorsqu'un document d'annulation est créé (par exemple, via FB08). Type d'événement explicit | |||
| Facture passée en perte | Un statut final alternatif où la facture est considérée comme irrécouvrable et le montant dû est compensé par un compte de créances douteuses. Cela clôture la facture sans paiement client. | ||
| Pourquoi c'est important Représente un résultat de processus négatif et une perte de revenus. Le suivi de ces événements aide à analyser les raisons des créances irrécouvrables et à améliorer les politiques de gestion du crédit. Où obtenir Déduit en analysant la transaction de lettrage de la facture. Si le document de lettrage est imputé à un compte de grand livre spécifique pour créances douteuses, la facture est considérée comme passée en pertes. Capture Déduit lorsque la transaction de lettrage implique un enregistrement sur un compte de grand livre désigné pour créances douteuses. Type d'événement inferred | |||
| Facture pré-enregistrée | Le document de facture a été sauvegardé dans un état préliminaire sans être enregistré dans le grand livre général. Ceci est souvent utilisé lorsque les informations sont incomplètes ou nécessitent une révision avant l'enregistrement final. | ||
| Pourquoi c'est important Suit les étapes de pré-enregistrement et les retards potentiels. Une longue durée à l'état de document comptable temporaire peut indiquer des problèmes de qualité des données ou des goulots d'étranglement dans le processus de pré-approbation. Où obtenir Les documents comptables temporaires sont stockés dans la table VBKPF. La création d'un document ici, qui est ensuite enregistré, signifie cette activité. Capture Enregistré lors de la sauvegarde d'un document comptable temporaire à l'aide d'une transaction comme FV70. Type d'événement explicit | |||
| Paiement appliqué à la facture | Le paiement client reçu a été apparié et appliqué à la facture non soldée spécifique, marquant le poste pour lettrage. C'est l'étape de rapprochement qui lie le paiement à la dette. | ||
| Pourquoi c'est important Cette activité est cruciale pour mesurer le temps de cycle de l'application d'espèces. Des retards dans l'application des espèces peuvent déformer le véritable statut des comptes clients et masquer la trésorerie disponible. Où obtenir Déduit de la transaction de lettrage, par exemple, F-32, qui renseigne les champs de lettrage dans le poste de facture. Le horodatage de l'événement est la date de lettrage. Capture Déduit de la date de lettrage (AUGDT) renseignée dans la table des postes de facture (BSEG). Type d'événement inferred | |||
| Relance de paiement émise | Le système a généré et envoyé un avis de relance ou un rappel de paiement au client pour une facture en retard. Ceci est capturé à partir des journaux d'historique de relance. | ||
| Pourquoi c'est important Permet d'évaluer l'efficacité de la stratégie de recouvrement. L'analyse du délai entre l'envoi du rappel et la réception du paiement est essentielle pour l'indicateur clé de performance (KPI) de l'efficacité des relances de paiement. Où obtenir Enregistré dans les tables de données de relance, spécifiquement MHNK (En-tête des données de relance) et MHND (Postes des données de relance), qui sont générées par l'exécution de la relance (Transaction F150). Capture Enregistré lors de l'exécution d'une relance (F150) pour l'élément en retard. Type d'événement explicit | |||
Guides d'extraction
Étapes
- Accéder à l'éditeur ABAP: Connectez-vous à votre système SAP ECC. Accédez à l'éditeur ABAP à l'aide du code de transaction
SE38. - Créer un programme: Entrez un nom pour votre nouveau programme dans le champ Programme, par exemple,
Z_PM_O2C_INVOICE_EXTRACT, et cliquez sur le bouton Créer. Fournissez un titre descriptif et définissez le type de programme sur 'Programme exécutable'. - Définir l'écran de sélection: Dans le code source du programme, définissez les paramètres de l'écran de sélection. Cela permet aux utilisateurs de filtrer les données à extraire. Les paramètres clés incluent la plage de dates de création du document (
S_ERDAT), le code de société (S_BUKRS) et le type de document de facturation (S_VBTYP). - Définir les structures de données: Déclarez une structure de table interne qui contiendra les données finales du journal d'événements (event log). Cette structure doit inclure les champs
InvoiceNumber,ActivityName,EventTimeet les attributs recommandés tels queUserName,BillingDocumentType,CustomerNumber,CompanyCodeetTotalInvoiceAmount. - Implémenter la logique de sélection des données: Écrivez la logique ABAP principale pour sélectionner les données. Tout d'abord, sélectionnez les documents de facturation principaux des tables
VBRKetBKPFen fonction des saisies de l'utilisateur sur l'écran de sélection. Stockez-les dans une table interne temporaire. - Extraire les activités: Parcourez la liste initiale des documents de facturation. Pour chaque document, effectuez des sélections ultérieures à partir de diverses tables pour identifier les 13 activités requises. Par exemple, interrogez la table
NASTpour les événements 'Facture envoyée au client',BSEGpour les informations de compensation ('Facture compensée', 'Paiement appliqué') etMHNKpour les données de relance ('Rappel de paiement émis'). - Construire la table du journal d'événements: Pour chaque activité trouvée à l'étape précédente, renseignez un nouvel enregistrement dans votre table interne finale du journal d'événements. Assurez-vous que
InvoiceNumber,ActivityName,EventTimeet les autres attributs sont correctement mappés à partir des tables sources. - Écrire sur le serveur d'applications: Une fois la boucle terminée et la table finale du journal d'événements entièrement remplie, utilisez les instructions
OPEN DATASET,LOOP AT... TRANSFERetCLOSE DATASETpour écrire le contenu de la table interne dans un fichier plat sur le serveur d'applications SAP. Spécifiez un chemin de fichier logique accessible. - Récupérer le fichier: Utilisez le code de transaction
AL11pour naviguer dans les répertoires du serveur d'applications et localiser le fichier généré. Coordonnez-vous avec votre équipe SAP Basis pour télécharger le fichier du serveur vers votre machine locale ou un emplacement réseau partagé. - Formatage final: Ouvrez le fichier téléchargé et confirmez qu'il s'agit d'un fichier de valeurs séparées par des virgules (CSV) avec une ligne d'en-tête. Assurez-vous que le fichier est enregistré avec l'encodage UTF-8 pour être compatible avec ProcessMind lors du téléchargement.
Configuration
- Prérequis: Accès pour créer et exécuter des programmes ABAP (transaction SE38). Autorisation de lecture des tables FI et SD, y compris
VBRK,VBRP,BKPF,BSEG,NAST,MHNKetUDM_CASE_ATTR00(pour la gestion des litiges). - Sélection de la plage de dates: Le programme doit inclure un paramètre de plage de dates obligatoire, généralement basé sur la date de création du document (
ERDATdans VBRK/BKPF). Pour une extraction initiale, une période de 3 à 6 mois est recommandée afin de maintenir l'ensemble de données gérable. - Filtres clés: Toujours filtrer par
CompanyCode(BUKRS) pour limiter la portée de l'extraction. Il est également fortement recommandé de filtrer par type de document de facturation (VBTYPde VBRK) ou type de document comptable (BLARTde BKPF) pour inclure uniquement les types de factures pertinents, par exemple, 'RV' pour les factures comptables standard, et exclure les avoirs ou autres documents. - Considérations relatives aux performances: Pour les grands ensembles de données couvrant plus de quelques mois, le programme doit être exécuté en tâche de fond pour éviter les délais d'attente de session. La logique ABAP doit être optimisée pour utiliser des lectures de tables indexées et éviter les boucles imbriquées avec des sélections de base de données à l'intérieur. La sélection des données dans des tables internes avant de les traiter est l'approche privilégiée.
- Configuration du fichier de sortie: Le code ABAP doit spécifier le chemin du fichier de sortie sur le serveur d'applications et le délimiteur pour le fichier CSV, généralement une virgule ou un point-virgule. Assurez-vous que le chemin est un répertoire configuré globalement et accessible.
a 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: Assurez-vous de disposer d'un utilisateur de base de données avec un accès en lecture seule aux tables SAP ECC nécessaires, y compris VBRK, BKPF, BSAD, NAST, CDHDR, CDPOS, SCASE, et d'autres spécifiées dans la requête. Ce niveau d'accès est généralement accordé uniquement aux administrateurs système ou à des équipes d'analyse de données spécifiques.
- Connectez-vous à la base de données: Utilisez un outil client SQL standard, tel que DBeaver, Oracle SQL Developer ou Microsoft SQL Server Management Studio, pour établir une connexion à la base de données SAP ECC.
- Préparez la requête SQL: Copiez la requête SQL complète fournie dans la section 'requête' dans l'éditeur de votre client SQL.
- Personnalisez les marqueurs: La requête contient plusieurs marqueurs que vous devez remplacer par des valeurs spécifiques à votre environnement. Ceux-ci incluent :
'YYYYMMDD': Remplacez toutes les instances par les dates de début et de fin de la période d'analyse souhaitée. Il est crucial de filtrer les données pour une période gérable.'XXXX': Remplacez par le(s) code(s) de société spécifique(s) que vous souhaitez analyser.[Your Invoice Output Type]: Spécifiez le code de type de sortie utilisé pour envoyer les factures aux clients, par exemple, 'RD00'.[Your Bad Debt G/L Account]: Entrez le numéro de compte général utilisé pour radier les factures irrécouvrables.[Your Dispute Case Invoice Attribute]: Spécifiez le nom de l'attribut utilisé pour stocker le numéro de facture dans votre configuration de gestion des litiges, par exemple, 'INVOICE_ID'.
- Revoir les fonctions de timestamp: La requête utilise une syntaxe générique
CAST(CONCAT(date_field, time_field) AS TIMESTAMP). Vous devrez peut-être l'ajuster pour correspondre à votre système de base de données spécifique, par exemple, en utilisantTO_TIMESTAMPpour Oracle ouDATETIMEFROMPARTSpour SQL Server. - Exécutez la requête: Exécutez la requête modifiée. L'exécution peut prendre un temps significatif en fonction de la taille de vos tables SAP et de la plage de dates sélectionnée.
- Inspectez les résultats: Une fois la requête terminée, examinez la sortie pour vous assurer qu'elle contient les colonnes attendues : InvoiceNumber, ActivityName, EventTime et les attributs recommandés. Vérifiez s'il y a des erreurs ou des résultats vides.
- Exportez au format CSV: Exportez l'ensemble complet des résultats de votre client SQL vers un fichier CSV. Assurez-vous que le fichier utilise l'encodage UTF-8 pour éviter les problèmes avec les caractères spéciaux.
- Préparez pour le téléchargement: Avant de télécharger vers un outil de Process Mining, confirmez que les en-têtes de colonne CSV correspondent exactement aux noms d'attributs requis, par exemple,
InvoiceNumber,ActivityName,EventTime,UserName.
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.
- Autorisation: L'utilisateur de la base de données doit disposer des autorisations
SELECTsur toutes les tables utilisées dans la requête, couvrant les modules FI, SD et potentiellement FSCM. - Plage de dates: Il est crucial de filtrer la requête par une plage de dates spécifique pour garantir des performances et un volume de données raisonnables. Nous recommandons de commencer par une période de 3 à 6 mois. Les marqueurs de filtre de date
'YYYYMMDD'doivent être définis dans plusieurs parties de la requête. - Filtre par code de société: La requête est conçue pour être filtrée par code de société (
BUKRS). L'analyse d'un ou de quelques codes de société à la fois est une pratique courante. - Configuration du type de document: La logique d'identification des événements tels que les corrections de facture, les radiations ou les documents envoyés dépend des configurations SAP standard. Vous devrez peut-être ajuster la requête si votre organisation utilise des types de documents personnalisés (
BLART), des types de sortie (KSCHL) ou des comptes généraux pour ces processus. - Considérations relatives aux performances: L'exécution de cette requête sur un système SAP de production en direct peut consommer des ressources importantes et impacter les performances opérationnelles. Il est fortement recommandé d'effectuer des extractions volumineuses pendant les heures creuses ou sur une réplique dédiée de la base de données pour le reporting.
a 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: Assurez-vous de disposer d'un outil ETL sous licence avec un connecteur SAP certifié (par exemple, Informatica PowerCenter avec SAP Connector, Talend avec SAP Connector, etc.). Vérifiez que vous avez des identifiants utilisateur SAP avec les autorisations nécessaires pour lire les tables financières, de vente et système requises (BKPF, BSEG, VBRK, NAST, MHNK, UDM_CASE_ATTR00, CDHDR, CDPOS).
- Établir la connexion SAP: Dans votre outil ETL, créez une nouvelle connexion à votre système SAP ECC. Configurez les détails de connexion, y compris le serveur d'applications, le numéro de système, le client, l'utilisateur et le mot de passe. Testez la connexion pour vous assurer qu'elle est réussie.
- Définir les sources de données: Pour chaque activité à extraire, définissez la ou les tables SAP correspondantes comme source de données dans votre tâche ETL. Par exemple, ajoutez VBRK pour la génération de factures, BKPF pour les événements de comptabilisation et NAST pour la communication client.
- Construire la logique d'extraction pour chaque activité: Créez un flux de données ou une transformation séparé pour chacune des 13 activités requises. Dans chaque flux, appliquez des filtres pour sélectionner les enregistrements pertinents. Par exemple, filtrez par code de société (BUKRS), type de document (BLART) et une plage de dates spécifique (par exemple, date de création ERDAT).
- Mapper les champs et transformer les données: Dans chaque flux de données, mappez les champs de la table SAP source à la structure du journal d'événements cible : InvoiceNumber, ActivityName, EventTime, UserName, et d'autres attributs recommandés. Utilisez une logique de transformation pour coder en dur le 'ActivityName' pour chaque flux et pour formater correctement les dates et les horodatages.
- Gérer les activités complexes: Pour les événements calculés comme 'Date d'échéance de la facture atteinte', utilisez la date de paiement de référence (ZFBDT) et la logique des conditions de paiement pour calculer la date d'échéance, ou simplement extrayez la date d'échéance nette (NETDT) de BSEG. Pour les événements dérivés des journaux de modifications comme 'Facture approuvée', vous devrez peut-être joindre des tables comme BKPF et CDHDR/CDPOS en fonction du numéro de document et de la date.
- Combiner les données d'activité: Utilisez une transformation 'Union' ou 'Fusion' dans votre outil ETL pour combiner les sorties des 13 flux de données individuels en un seul ensemble de données. Assurez-vous que les noms de colonnes et les types de données sont cohérents dans tous les flux avant l'union.
- Configurer la destination cible: Définissez la destination de sortie finale pour votre journal d'événements. Cela peut être un fichier plat (CSV), une table de base de données ou une connexion directe à une zone de transit.
- Définir le calendrier d'extraction: Configurez les paramètres de plage de dates pour l'extraction. Pour le chargement initial, vous pouvez extraire 6 à 12 mois de données. Pour les chargements delta ultérieurs, configurez la tâche pour extraire les données depuis la dernière date d'exécution.
- Exécuter et exporter: Exécutez la tâche ETL. Une fois terminée, inspectez le fichier de sortie pour vous assurer qu'il respecte le format requis. La sortie finale doit être un seul fichier CSV avec chaque ligne représentant un événement unique, prêt à être téléchargé dans ProcessMind.
Configuration
- Connexion SAP: Une connexion au serveur d'applications au système SAP ECC cible est requise. L'utilisateur SAP a besoin d'un accès RFC et d'autorisations pour des tables comme VBRK, BKPF, BSEG, NAST, et d'autres spécifiées dans la requête.
- Licence d'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 les données pour une période de 3 à 6 mois afin d'assurer un échantillon représentatif pour l'analyse sans surcharger le système. Utilisez un paramètre configurable pour les dates de début et de fin.
- Filtres clés: Filtrez toujours par code de société (BUKRS) pour limiter la portée de l'extraction. Il est également essentiel de filtrer sur les types de documents de facturation pertinents (VBRK-FKART) et les types de documents comptables (BKPF-BLART) pour inclure uniquement les factures standard et exclure d'autres types de documents comme 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 des champs inutiles et planifiez l'extraction pendant les heures creuses pour minimiser l'impact sur les performances du système source SAP.
a 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