Votre Template de données pour le processus Purchase to Pay - Traitement des factures
Votre Template de données pour le processus Purchase to Pay - Traitement des factures
- Attributs recommandés à collecter
- Activités clés à suivre
- Conseils d'extraction pour `SAP S/4HANA`
Attributs du processus Achats-Comptes Fournisseurs – Traitement des factures
| Nom | Description | ||
|---|---|---|---|
| Numéro de facture InvoiceNumber | L'identifiant unique du document de facture fournisseur, servant d'identifiant de cas principal pour le processus. | ||
| Description Le numéro de facture est l'identifiant unique attribué à chaque facture fournisseur dans SAP S/4HANA. Il relie toutes les activités associées, telles que la création, la mise en attente, l'approbation et le paiement, en une seule instance de processus cohérente. En Process Mining, cet attribut est fondamental pour suivre le parcours de bout en bout de chaque facture. Il permet la reconstruction de l'intégralité du flux de processus, de la réception au paiement final, autorisant l'analyse des temps de cycle, des goulots d'étranglement et des variations de processus au niveau de chaque facture. Pourquoi c'est important C'est la clé essentielle pour connecter tous les événements liés, permettant une traçabilité complète du cycle de vie d'une facture à travers le système. Où obtenir C'est le numéro du document comptable, trouvé dans la table BKPF, champ BELNR. Exemples 190000000119000000451900000132 | |||
| Heure de l'événement EventTime | La date et l'heure précises auxquelles l'activité s'est produite. | ||
| Description L'heure de l'événement est l'horodatage qui enregistre précisément quand une activité spécifique s'est produite. Ces données sont essentielles pour calculer les durées, les temps de cycle et les temps d'attente entre les différentes étapes du processus. Dans l'analyse Process Mining, les horodatages précis sont utilisés pour mesurer les KPI de performance comme le 'Temps de cycle moyen des factures' et le 'Temps de cycle d'approbation des factures'. En analysant le temps écoulé entre les activités, les organisations peuvent identifier les goulots d'étranglement où les factures sont retardées et repérer les opportunités d'accélération des processus. Pourquoi c'est important Cet horodatage est la base de toutes les analyses basées sur le temps, y compris le suivi des performances, l'identification des goulots d'étranglement et le suivi des SLA. Où obtenir Généralement issu des tables de documents de modification CDHDR (En-tête) et CDPOS (Poste), en utilisant les champs UDATE et UTIME. Pour certains événements, il peut provenir des dates de création ou de saisie dans des tables comme BKPF (CPUDT, CPUTM). Exemples 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Nom de l'activité ActivityName | Le nom de l'activité commerciale ou de l'événement survenu à un moment précis pour une facture. | ||
| Description Le nom de l'activité décrit une étape spécifique ou un changement de statut au sein du cycle de vie du traitement des factures. Les exemples incluent 'Document de facture créé', 'Facture envoyée pour approbation', 'Blocage de paiement défini' et 'Paiement exécuté'. Cet attribut est crucial pour la construction de la carte des processus, qui représente visuellement le flux des activités. L'analyse de la séquence, de la fréquence et de la durée entre ces activités aide à identifier les goulots d'étranglement, les boucles de retrabail et les variations de processus non conformes. Il constitue l'épine dorsale de toute analyse de Process Mining. Pourquoi c'est important Il définit les étapes du processus, permettant la visualisation des cartes de processus et l'analyse des flux de processus et des variations. Où obtenir Dérivé d'une combinaison de codes de transaction SAP (SY-TCODE), des statuts d'objets de document de modification (CDHDR/CDPOS) et de valeurs de champs spécifiques indiquant des changements de statut. Exemples Facture pré-enregistréeFacture approuvéePaiement effectué | |||
| Bon de commande PurchasingDocument | Le numéro de la commande d'achat à laquelle la facture est liée. | ||
| Description Le numéro de document d'achat lie la facture fournisseur à la commande d'achat (PO) d'origine. Ce lien est fondamental pour le processus de rapprochement en trois points, qui vérifie la facture par rapport à la commande d'achat et à la réception des marchandises. L'analyse par cet attribut aide à comprendre les problèmes liés aux factures avec commande d'achat par rapport aux factures sans commande d'achat. Il est essentiel pour enquêter sur les divergences de rapprochement et comprendre l'efficacité de la partie approvisionnement du processus. Pourquoi c'est important Lie la facture au processus d'approvisionnement, ce qui est essentiel pour analyser les écarts de rapprochement et la conformité des bons de commande. Où obtenir Ces informations se trouvent généralement dans la table de segment de document BSEG, champ EBELN (Numéro de document d'achat). Exemples 450000123445000056784500009012 | |||
| Code société CompanyCode | L'unité organisationnelle représentant une entreprise juridiquement indépendante pour laquelle des états financiers sont créés. | ||
| Description Le code société est une unité organisationnelle fondamentale dans SAP Finance. Chaque facture est affectée à un code société spécifique, qui détermine l'entité juridique responsable de la transaction. En Process Mining, le filtrage ou la comparaison par code société est essentiel pour analyser la performance des processus au sein de différentes unités commerciales, entités juridiques ou pays. Il aide à identifier les différences régionales en termes d'efficacité, de conformité et de niveaux d'automatisation, soutenant ainsi des initiatives d'amélioration ciblées. Pourquoi c'est important Il permet de segmenter et de comparer la performance du traitement des factures entre différentes entités juridiques ou emplacements géographiques au sein de l'organisation. Où obtenir C'est un champ standard dans la table d'en-tête du document BKPF, champ BUKRS. Exemples 1000US01DE01 | |||
| Date d'échéance du paiement PaymentDueDate | La date à laquelle la facture doit être payée pour éviter d'être en retard. | ||
| Description La date d'échéance du paiement est la date calculée à laquelle le paiement au fournisseur est dû, basée sur la date de facture et les conditions de paiement convenues. Elle sert de date limite critique dans le processus. Cet attribut est essentiel pour le KPI 'Taux de paiement à temps' et le dashboard 'Performance de paiement fournisseur'. En comparant la date de paiement réelle avec la date d'échéance, une entreprise peut mesurer sa capacité à respecter ses obligations de paiement, ce qui affecte les relations avec les fournisseurs et la réputation financière. Pourquoi c'est important C'est le principal repère pour mesurer la performance des paiements ponctuels, ce qui est crucial pour maintenir de bonnes relations avec les fournisseurs et éviter les frais de retard. Où obtenir Cette date est souvent directement disponible dans le poste fournisseur de la table BSEG, champ ZFBDT (Date de base pour le calcul de l'échéance). La date d'échéance nette est calculée à partir de cette date de base et des conditions de paiement. Exemples 2023-05-302023-06-152023-07-01 | |||
| Montant de la facture AmountInCompanyCodeCurrency | Le montant brut total de la facture dans la devise locale du code société. | ||
| Description Cet attribut représente la valeur totale de la facture. C'est une métrique clé pour comprendre l'impact financier et l'ampleur de l'opération de traitement des factures. L'analyse des montants de facture aide à prioriser les factures de grande valeur pour un traitement plus rapide, à identifier les tendances de dépenses et à corréler les problèmes de processus avec la valeur financière. Par exemple, il peut être utilisé pour déterminer si les factures de grande valeur sont plus susceptibles d'être bloquées ou d'avoir des délais d'approbation plus longs. Pourquoi c'est important Fournit un contexte financier au processus, permettant une analyse basée sur la valeur monétaire, par exemple pour identifier si les factures de grande valeur sont traitées différemment. Où obtenir Cette valeur est généralement dérivée de la somme des postes pertinents dans la table BSEG, champ WRBTR (Montant en devise locale). Exemples 1500.75125000.00850.20 | |||
| Motif de blocage de paiement PaymentBlockReason | Un code indiquant pourquoi une facture est bloquée pour paiement. | ||
| Description Lorsqu'une facture est bloquée pour paiement, cet attribut fournit la raison spécifique du blocage, telle que 'Écart de quantité' ou 'Divergence de prix'. Ces raisons sont configurées dans SAP pour standardiser la gestion des exceptions. Cet attribut est crucial pour le dashboard 'Occurrence et durée du blocage de paiement'. L'analyse de la fréquence des différentes raisons de blocage aide à identifier les causes profondes des retards de paiement, telles que des problèmes avec des fournisseurs spécifiques, des matériaux ou des processus internes, permettant des actions correctives ciblées. Pourquoi c'est important Fournit la cause racine spécifique des blocages de paiement, permettant une analyse ciblée pour réduire les retards et améliorer le traitement dès la première fois. Où obtenir Situé dans le poste de ligne fournisseur de la table BSEG, champ ZLSPR (Clé de blocage de paiement). Exemples RIA | |||
| Nom d'utilisateur UserName | L'ID utilisateur SAP de la personne ou du système qui a effectué l'activité. | ||
| Description Cet attribut identifie l'utilisateur qui a exécuté une transaction spécifique ou créé un document. Il peut s'agir de l'ID utilisateur d'un individu ou d'un ID système pour les jobs batch automatisés. L'analyse par utilisateur aide à comprendre la répartition de la charge de travail, à identifier les besoins en formation et à repérer les comportements d'utilisateur inhabituels. Par exemple, il peut mettre en évidence les utilisateurs qui gèrent fréquemment des exceptions ou les factures qui sont traitées automatiquement (par exemple, l'utilisateur 'BATCHUSER'), ce qui est essentiel pour le calcul du KPI 'Taux d'automatisation des factures'. Pourquoi c'est important Il attribue les activités de processus à des utilisateurs ou comptes système spécifiques, permettant l'analyse de la charge de travail, la comparaison des performances et la détection de l'automatisation. Où obtenir Provient de champs tels que BKPF-USNAM (Saisi par) ou CDHDR-USERNAME (Modifié par). Exemples SMITHJMUELLERTWF-BATCH | |||
| Numéro de fournisseur VendorNumber | L'identifiant unique du fournisseur qui a soumis la facture. | ||
| Description Le numéro de fournisseur identifie le fournisseur ou le créancier associé à la facture. Il relie la transaction de facture aux données de base du fournisseur. Cet attribut est essentiel pour l'analyse axée sur les fournisseurs, telle que l'évaluation de la 'Performance de paiement des fournisseurs' ou l'identification des fournisseurs qui soumettent fréquemment des factures problématiques entraînant des exceptions ou des blocages de paiement. Il aide à gérer les relations avec les fournisseurs et à évaluer la fiabilité des fournisseurs. Pourquoi c'est important Permet l'analyse de la performance du processus par fournisseur, aidant à identifier les schémas, à gérer les relations et à évaluer les problèmes liés aux fournisseurs. Où obtenir Généralement trouvé dans la table de segment de document comptable BSEG, champ LIFNR. Exemples 100345700012V9832 | |||
| Type de document DocumentType | Un code qui classe différents types de documents comptables, tels que les factures fournisseurs ou les avoirs. | ||
| Description Le type de document est utilisé dans SAP pour distinguer différentes transactions commerciales. Par exemple, 'KR' représente généralement une facture fournisseur standard, tandis que 'KG' pourrait être un avoir fournisseur. L'analyse par type de document permet de segmenter le processus pour comprendre comment différents types de transactions sont gérés. Par exemple, le processus pour un avoir peut être significativement différent de celui d'une facture standard. Cette segmentation fournit des informations de processus plus précises et pertinentes. Pourquoi c'est important Il aide à différencier les différents types de transactions financières, tels que les factures standard et les avoirs, qui suivent souvent des chemins de processus différents. Où obtenir Trouvé dans la table d'en-tête de document BKPF, champ BLART. Exemples KRREKG | |||
| Conditions de paiement PaymentTerms | Le code définissant les conditions de paiement convenues avec le fournisseur, telles que les dates d'échéance et les périodes de remise. | ||
| Description Les conditions de paiement définissent les règles de paiement d'une facture, y compris les remises éventuelles pour paiement anticipé. Par exemple, 'Z030' pourrait signifier 'Payable à 30 jours net'. Cet attribut est essentiel pour la planification financière et l'optimisation du fonds de roulement. En Process Mining, il est utilisé pour calculer la 'Date d'échéance du paiement' et pour déterminer l'éligibilité aux escomptes pour paiement anticipé, soutenant directement le KPI 'Taux de capture des escomptes pour paiement anticipé'. Pourquoi c'est important Définit les règles pour les dates d'échéance de paiement et les escomptes, impactant directement les KPI de paiement ponctuel et la gestion du fonds de roulement. Où obtenir Trouvé dans le poste de ligne fournisseur dans la table BSEG, champ ZTERM (Clé des conditions de paiement). Exemples 0001Z030NT60 | |||
| Date de la facture InvoiceDate | La date à laquelle le fournisseur a émis le document de facture. | ||
| Description La date de facture, également connue sous le nom de date du document, est la date fournie par le fournisseur sur la facture. Elle est utilisée comme point de départ pour le calcul de la date d'échéance du paiement sur la base des conditions de paiement convenues. En analyse, cette date est fondamentale pour les calculs financiers, tels que la détermination du vieillissement des factures et l'éligibilité aux escomptes pour paiement anticipé. Elle est un intrant clé pour le KPI 'Taux de capture des escomptes pour paiement anticipé'. Pourquoi c'est important Sert de base pour le calcul des conditions et des dates d'échéance de paiement, ce qui est essentiel pour gérer le fonds de roulement et capturer les escomptes. Où obtenir Trouvé dans la table d'en-tête de document BKPF, champ BLDAT (Date du document). Exemples 2023-04-122023-05-152023-06-20 | |||
| Est `payé à temps` IsPaidOnTime | Un indicateur qui est vrai si la facture a été payée à ou avant sa date d'échéance de paiement. | ||
| Description Cet attribut booléen est le résultat de la comparaison de la date de paiement réelle (l'horodatage de l'activité 'Paiement exécuté') avec la 'Date d'échéance du paiement'. Il fournit un résultat binaire clair pour le statut de paiement de chaque facture. Ceci est le calcul principal du KPI 'Taux de paiement à temps'. Il permet un filtrage et une analyse faciles pour comprendre les caractéristiques des paiements en retard, telles que les fournisseurs courants, les codes société ou les montants de facture associés aux retards. Pourquoi c'est important Mesure directement le respect des conditions de paiement, ce qui est un KPI essentiel pour la gestion des relations fournisseurs et les opérations financières. Où obtenir Calculé en comparant l'EventTime de l'activité 'Paiement exécuté' avec l'attribut PaymentDueDate. (Date de paiement <= PaymentDueDate). Exemples truefaux | |||
| Est Automatisé IsAutomated | Un indicateur signalant si une activité a été réalisée par un utilisateur système automatisé. | ||
| Description Cet attribut booléen est vrai si l'utilisateur associé à une activité est un compte système ou batch connu, tel que 'WF-BATCH' ou 'SAP_SYSTEM'. Il aide à distinguer les étapes de processus manuelles et automatisées. Cet attribut est essentiel pour le calcul du KPI 'Taux d'automatisation des factures'. En analysant quelles parties du processus sont automatisées, les organisations peuvent mesurer le succès de leurs initiatives d'automatisation et identifier de nouvelles opportunités pour réduire l'effort manuel et améliorer l'efficacité. Pourquoi c'est important Distingue les activités manuelles des activités pilotées par le système, ce qui est fondamental pour mesurer les taux d'automatisation et identifier les opportunités d'automatisation supplémentaire. Où obtenir Dérivé de l'attribut UserName. Un mappage ou une règle est créé pour classer des ID d'utilisateur spécifiques comme 'automatisés'. Exemples truefaux | |||
| Est un retravail IsRework | Un indicateur signalant si une facture a fait l'objet d'activités de reprise, telles qu'une approbation rejetée ou un blocage de paiement levé. | ||
| Description Cet attribut signale les factures ayant subi une ou plusieurs boucles de retrabail. Le retrabail est identifié par des séquences d'activités spécifiques, par exemple, 'Facture approuvée' après 'Facture rejetée', ou 'Blocage de paiement levé' après 'Blocage de paiement défini'. Cet attribut simplifie le calcul du KPI 'Taux de retrabail des factures'. Il permet aux analystes d'isoler et d'examiner facilement les cas de retrabail pour comprendre les causes profondes de l'inefficacité et de l'effort manuel répété. Pourquoi c'est important Identifie les flux de processus inefficaces où le travail doit être répété, aidant à quantifier le gaspillage et à identifier les causes profondes des exceptions de processus. Où obtenir Calculé sur la base de la séquence d'activités dans le journal d'événements. Par exemple, si 'Facture rejetée' apparaît dans la trace d'une facture, cet indicateur serait défini sur vrai. Exemples truefaux | |||
| Horodatage d'extraction ExtractionTimestamp | La date et l'heure auxquelles les données ont été extraites du système source. | ||
| Description Cet attribut enregistre l'horodatage de l'événement d'extraction de données. Il reflète la fraîcheur des données analysées dans l'outil de Process Mining. En analyse, ceci est utilisé pour comprendre la récence des informations générées. Il est essentiel pour les dashboards de surveillance opérationnelle de s'assurer que les décisions sont basées sur des informations à jour et de gérer efficacement les cycles d'actualisation des données. Pourquoi c'est important Indique la fraîcheur des données, garantissant que l'analyse et le reporting sont basés sur les informations les plus actuelles disponibles. Où obtenir Ceci n'est pas un champ SAP. Il est généré et ajouté par l'outil d'extraction de données ou le processus ETL au moment de l'extraction des données. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| ID du système source SourceSystemId | L'identifiant du système source SAP S/4HANA à partir duquel les données ont été extraites. | ||
| Description Cet attribut spécifie le système d'origine, par exemple, 'S4H_PROD' ou 'ERP_EU'. Il est particulièrement important dans les environnements avec plusieurs instances ERP ou un mélange de systèmes hérités et modernes. Pour l'analyse, il permet de comparer la performance des processus entre différents systèmes ou régions. Il assure la provenance des données et est crucial pour la gouvernance des données et le dépannage lorsque les données de plusieurs sources sont combinées dans une plateforme centrale de Process Mining. Pourquoi c'est important Cela apporte du contexte sur l'origine des données, un point essentiel pour la gouvernance des données et pour comparer les processus entre les différents systèmes ou sites de l'entreprise. Où obtenir Cette valeur est généralement dérivée de l'ID système SAP (sy-sysid) lors de l'extraction des données ou configurée comme une valeur statique dans le pipeline ETL. Exemples S4PS4H_PROD_100ECC_EU | |||
| N° de document de compensation ClearingDocumentNumber | Le numéro du document qui compense la facture, représentant généralement le document de paiement. | ||
| Description Le numéro de document de compensation lie un poste de facture ouvert à la transaction qui le compense, qui est presque toujours le document de paiement. Cela confirme que la facture a été payée. Cet attribut est le lien définitif entre une facture et son paiement. Il est utilisé pour identifier l'activité 'Paiement exécuté' et son horodatage correspondant, ce qui est essentiel pour calculer le temps de cycle de bout en bout et le taux de paiement à temps. Pourquoi c'est important Confirme qu'une facture a été payée et la lie à la transaction de paiement spécifique, ce qui est essentiel pour l'analyse du temps de cycle et de la performance de paiement. Où obtenir Trouvé dans la table de segment de document BSEG, champ AUGBL (Numéro de document de compensation). Exemples 150000000115000000231500000088 | |||
| Nombre de cycles d'approbation ApprovalCycleCount | Un compte du nombre de fois qu'une facture a été envoyée pour approbation. | ||
| Description Cette métrique compte le nombre de fois où l'activité 'Facture envoyée pour approbation' se produit pour une seule facture. Un compte supérieur à un indique que la facture a été rejetée ou renvoyée au moins une fois, nécessitant un nouveau cycle d'approbation. Cet attribut soutient directement le KPI 'Taux d'approbation au premier passage'. En analysant les factures avec des nombres élevés de cycles d'approbation, les organisations peuvent identifier les raisons des échecs d'approbation, telles que des informations insuffisantes ou un codage incorrect, et prendre des mesures pour améliorer le processus. Pourquoi c'est important Quantifie le retrabail au sein du sous-processus d'approbation, aidant à mesurer le taux de succès dès la première fois et à identifier les raisons des rejets d'approbation. Où obtenir Calculé en comptant les occurrences de l'activité 'Facture envoyée pour approbation' pour chaque InvoiceNumber unique. Exemples 123 | |||
| Raison de l'annulation ReversalReason | Un code indiquant la raison pour laquelle un document de facture a été annulé. | ||
| Description Si une facture est comptabilisée incorrectement, elle est souvent annulée. Le code de motif d'annulation explique pourquoi cette action a été entreprise, par exemple, 'Date de comptabilisation incorrecte' ou 'Erreur de saisie de données'. L'analyse des motifs d'annulation aide à identifier les schémas d'erreurs dans le processus de comptabilisation des factures. Cette information peut être utilisée pour améliorer la formation, renforcer les contrôles système ou aborder les problèmes récurrents qui entraînent des reprises financières et des frais administratifs. Pourquoi c'est important Explique pourquoi les factures ont été annulées, offrant un aperçu direct des sources d'erreur et de reprise dans le processus de comptabilisation. Où obtenir Trouvé dans l'en-tête du document original dans la table BKPF, champ STGRD (Raison d'annulation). Exemples 010205 | |||
| Temps de traitement des factures InvoiceProcessingTime | Le temps total écoulé de la première activité à la dernière activité pour une facture. | ||
| Description Cette métrique calcule la durée totale de traitement d'une seule facture, généralement de la création ou réception de la facture au paiement final. Elle fournit un résumé au niveau du cas du temps de cycle de bout en bout. Cet attribut calculé est la base du KPI 'Temps de cycle moyen des factures' et du dashboard 'Temps de cycle de bout en bout des factures'. Il permet l'identification rapide des cas les plus longs et l'analyse des facteurs qui contribuent à des temps de traitement prolongés. Pourquoi c'est important Mesure l'efficacité de bout en bout du processus pour chaque facture, mettant en évidence les cas avec des durées exceptionnellement longues qui nécessitent une investigation. Où obtenir Calculé en prenant la différence entre l'horodatage du dernier événement et du premier événement pour chaque InvoiceNumber unique. Exemples 10 jours 4 heures25 jours 1 heure5 jours 8 heures | |||
Activités du processus Achats-Comptes Fournisseurs – Traitement des factures
| Activité | Description | ||
|---|---|---|---|
| Facture approuvée | Cette activité signifie que la facture a été approuvée par l'autorité désignée. Cela est enregistré lorsque le workflow d'approbation se termine avec succès ou qu'un indicateur de libération est défini. | ||
| Pourquoi c'est important C'est une étape critique qui débloque la facture pour paiement. Les retards d'approbation sont un goulot d'étranglement courant, et le suivi de cette activité aide à identifier les approbateurs ou les étapes de processus lents. Où obtenir Ceci peut être déduit de l'étape de libération finale dans un workflow SAP ou en suivant les modifications apportées aux champs de statut de libération dans les tables associées à la facture ou à son document d'achat. Capture Déduire des événements de complétion de Workflow ou des modifications dans le champ de statut de libération d'un document. Type d'événement inferred | |||
| Facture comptabilisée | C'est un événement financier clé où la facture "parquée" (mise en attente) ou approuvée est officiellement comptabilisée dans le Grand Livre. Cette action reconnaît la dette envers le fournisseur. | ||
| Pourquoi c'est important La comptabilisation est une étape majeure qui sépare la saisie des données et l'approbation de la phase de règlement financier. Le temps écoulé entre la création de la facture et sa comptabilisation est une mesure clé de l'efficacité du traitement interne. Où obtenir Cet événement est identifié par la Date de comptabilisation (BKPF-BUDAT) sur l'en-tête du document. Pour les documents qui sont d'abord "parqués" (mis en attente), la transition vers un statut comptabilisé fournit l'horodatage de l'événement. Capture Utilisez la date de comptabilisation (BKPF-BUDAT) comme horodatage de l'événement. Type d'événement explicit | |||
| Facture contre-passée | Une activité représentant l'annulation d'un document de facture précédemment comptabilisé. Il s'agit d'un événement terminal pour une facture incorrecte, qui est ensuite souvent saisie à nouveau correctement. | ||
| Pourquoi c'est important Les annulations indiquent des erreurs critiques qui n'ont pas été détectées plus tôt dans le processus. Le suivi de leur fréquence et de leurs causes profondes est essentiel pour l'amélioration des processus et la réduction des inexactitudes financières. Où obtenir Une annulation est identifiée lorsqu'un document d'annulation est créé. L'en-tête du document original (BKPF) contiendra le numéro du document d'annulation (BKPF-STBLG) et vice versa. La date de comptabilisation du document d'annulation est l'heure de l'événement. Capture Identifiez les documents ayant une valeur dans le champ BKPF-STBLG et utilisez la date de comptabilisation du document d'annulation. Type d'événement explicit | |||
| Facture créée | C'est le premier événement, marquant la création d'un document de facture dans SAP. Il peut être capturé lorsqu'un utilisateur enregistre un nouveau document de facture, qui pourrait être dans un état "parqué" (mis en attente) ou pré-comptabilisé. | ||
| Pourquoi c'est important Cette activité marque le début du cycle de vie du traitement des factures. L'analyse du temps écoulé entre cet événement et les autres est cruciale pour mesurer le délai de traitement global. Où obtenir Cet événement est capturé à partir de la date et de l'heure de création (CPUDT, CPUTM) dans la table d'en-tête du document, généralement BKPF ou RBKP pour les factures logistiques. Le code de transaction (BKPF-TCODE) comme FB60, MIRO ou MIR7 indique la méthode de création. Capture Utilisez l'horodatage de création de BKPF-CPUDT et BKPF-CPUTM pour le document de facture. Type d'événement explicit | |||
| Paiement effectué | C'est l'activité finale du processus standard, où le paiement est effectué et la facture est compensée. Cela signifie que les fonds ont été déboursés au fournisseur. | ||
| Pourquoi c'est important Ceci marque la fin du cycle de vie de la facture P2P. Il est essentiel pour calculer le temps de cycle total de bout en bout et pour mesurer la performance de paiement à temps par rapport à la date d'échéance. Où obtenir Cet événement est capturé à partir des informations du document de compensation sur le poste fournisseur. La date de compensation (BSEG-AUGDT) et le document de compensation (BSEG-AUGBL) indiquent que le paiement a été effectué. Capture Utilisez la date de compensation (BSEG-AUGDT) du poste fournisseur compensé. Type d'événement explicit | |||
| Blocage de paiement activé | Une activité où un blocage est intentionnellement placé sur une facture pour empêcher son paiement. Cela est souvent dû à des écarts de prix ou de quantité, ou à un avoir en attente. | ||
| Pourquoi c'est important Les blocages de paiement sont une cause principale de retards de paiement et de litiges avec les fournisseurs. L'analyse de la fréquence, de la durée et des raisons de ces blocages est essentielle pour améliorer les taux de paiement à temps. Où obtenir Cet événement est capturé en suivant les modifications du champ Clé de blocage de paiement (BSEG-ZLSPR) dans le poste de facture. Les journaux de modifications dans CDHDR et CDPOS fournissent l'horodatage et l'utilisateur lorsque le blocage a été défini. Capture Identifiez quand le champ BSEG-ZLSPR est renseigné via des documents de modification (CDHDR/CDPOS). Type d'événement explicit | |||
| Blocage de paiement levé | Représente la résolution d'un problème, où un blocage de paiement précédemment défini est levé. Cela rend la facture à nouveau éligible au paiement. | ||
| Pourquoi c'est important Le temps entre la mise en place et la levée d'un blocage représente le temps de résolution d'une exception de processus. Réduire cette durée est essentiel pour améliorer l'efficacité et les relations avec les fournisseurs. Où obtenir Cet événement est capturé lorsque le champ Clé de blocage de paiement (BSEG-ZLSPR) est effacé. Cette modification est enregistrée dans les tables CDHDR et CDPOS, fournissant un horodatage pour la levée du blocage. Capture Identifiez quand le champ BSEG-ZLSPR est compensé via des documents de modification (CDHDR/CDPOS). Type d'événement explicit | |||
| Données de facture mises à jour | Cette activité reflète une modification apportée au document de facture après sa création initiale. C'est courant lors des cycles de retrabail suite à un rejet ou pour corriger des erreurs. | ||
| Pourquoi c'est important Les mises à jour fréquentes signalent des reprises et des problèmes potentiels de qualité des données au point d'entrée. Le suivi de ces modifications aide à quantifier l'effort consacré aux corrections et à identifier les erreurs courantes. Où obtenir Les modifications des champs clés sont enregistrées dans les tables de documents de modification de SAP, CDHDR (en-tête) et CDPOS (poste). Des événements peuvent être générés en filtrant les modifications apportées à l'objet de facture pertinent. Capture Extrayez les événements de modification des tables CDHDR et CDPOS pour l'objet facture. Type d'événement explicit | |||
| Facture envoyée pour approbation | Cette activité marque le début d'un workflow d'approbation formel pour la facture. Ceci est souvent déduit lorsque le statut de la facture passe à 'en attente d'approbation' ou qu'un élément de workflow est généré. | ||
| Pourquoi c'est important C'est le point de départ pour mesurer le temps de cycle d'approbation. Comprendre quand les approbations commencent est essentiel pour identifier les goulots d'étranglement dans le workflow d'approbation lui-même. Où obtenir Ceci est généralement déduit du début d'un workflow métier SAP (table SWW_WI2OBJ) lié à l'objet facture (par exemple, BUS2081) ou d'une modification d'un champ de statut personnalisé sur l'en-tête du document. Capture Déduire de la création d'un poste de Workflow lié au document de facture. Type d'événement inferred | |||
| Facture pré-enregistrée | Représente une facture qui a été saisie dans le système mais n'est pas encore comptabilisée dans le grand livre. Le « parking » (mise en attente) est utilisé pour enregistrer les factures incomplètes ou pour un examen ultérieur avant la comptabilisation. | ||
| Pourquoi c'est important Le « parking » (mise en attente) indique une pause délibérée dans le processus. Le suivi de la durée et de la fréquence des factures mises en attente aide à identifier les raisons des retards avant le début du cycle formel de comptabilisation et d'approbation. Où obtenir Ceci peut être identifié par les documents créés via des transactions de "parking" (par exemple, MIR7, FV60) ou en vérifiant des champs de statut spécifiques dans la table BKPF ou des tables de documents "parqués" dédiées comme VBKPF. Capture Identifiez les documents créés via des transactions de stationnement ou vérifiez le statut d'un document stationné. Type d'événement explicit | |||
| Facture rejetée | Représente le rejet d'une facture pendant le processus d'approbation. Cet événement déclenche un retrabail, nécessitant une correction et une nouvelle soumission. | ||
| Pourquoi c'est important Les rejets de factures sont un indicateur clé d'inefficacité des processus et de problèmes de qualité des données. L'analyse de la fréquence et des raisons des rejets aide à identifier les opportunités d'amélioration et de formation. Où obtenir Ceci est déduit des mises à jour de statut spécifiques dans un workflow SAP, telles qu'un statut 'rejeté', ou d'événements qui annulent le workflow d'approbation actuel, le renvoyant au processeur. Capture Déduire des changements de statut de Workflow indiquant un rejet. Type d'événement inferred | |||
| Paiement en retard exécuté | Ceci est un événement calculé qui se produit lorsqu'un paiement de facture est exécuté après sa date d'échéance calculée. Il est dérivé en comparant deux champs de date. | ||
| Pourquoi c'est important Cette activité soutient directement les KPI de paiement à temps et aide à identifier les fournisseurs ou unités commerciales ayant des retards de paiement fréquents, ce qui peut nuire aux relations avec les fournisseurs et entraîner des pénalités. Où obtenir Ceci est calculé en comparant la date de compensation (BSEG-AUGDT) avec la date d'échéance nette. La date d'échéance est elle-même calculée à partir de la date de base (BSEG-ZFBDT) et des conditions de paiement (BSEG-ZTERM). Capture Déduire en comparant BSEG-AUGDT > (BSEG-ZFBDT + jours de conditions de paiement). Type d'événement calculated | |||
| Proposition de paiement créée | La facture est sélectionnée et incluse dans une proposition de paiement dans le cadre d'une exécution de paiement. C'est la première étape du processus de paiement automatisé. | ||
| Pourquoi c'est important Cette activité indique l'intention de payer. Les retards entre cette étape et l'exécution finale du paiement peuvent révéler des problèmes liés au processus d'exécution des paiements, aux approbations ou à la communication bancaire. Où obtenir Ceci se trouve dans les tables d'exécution de paiement, spécifiquement REGUP, qui contient les postes inclus dans une proposition de paiement. La date d'exécution dans la table REGUH correspondante fournit l'horodatage. Capture Identifiez quand une facture apparaît dans la table REGUP à partir d'une exécution de proposition de paiement. Type d'événement explicit | |||
Guides d'extraction
Étapes
- Prérequis et Autorisation : Assurez-vous que l'utilisateur exécutant l'extraction dispose des autorisations nécessaires dans SAP S/4HANA pour accéder aux vues Core Data Services (CDS) requises. Les vues clés incluent
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemetI_PaymentProposalItem. L'utilisateur aura également besoin des permissions pour exécuter des requêtes via l'interface choisie, telle qu'un service OData ou une connexion SQL directe. - Identifier votre méthode de connexion : Déterminez comment vous vous connecterez au système SAP S/4HANA pour exécuter la requête SQL. Les méthodes courantes incluent l'utilisation de SAP Data Services, SAP Data Intelligence, un outil ETL tiers avec un connecteur SAP, ou une connexion SQL directe à la base de données SAP HANA si les politiques de sécurité de votre organisation le permettent.
- Définir les paramètres d'extraction : Avant d'exécuter la requête, définissez les paramètres clés. Spécifiez la plage de dates pour l'extraction, par exemple,
CreationDateentre'AAAA-MM-JJ'et'AAAA-MM-JJ'. Identifiez également les valeursCompanyCodespécifiques que vous souhaitez inclure pour limiter la portée de l'extraction des données. - Personnaliser la requête SQL : Copiez la requête SQL fournie dans le client SQL ou l'outil d'extraction de données de votre choix. Examinez attentivement les paramètres de substitution, tels que
'{StartDate}','{EndDate}'et('{CompanyCode1}', '{CompanyCode2}'). Remplacez ces paramètres de substitution par les valeurs réelles que vous avez définies à l'étape précédente. Vous devrez peut-être également ajuster les noms de champs pour l'état du Workflow en fonction de votre configuration SAP spécifique. - Exécuter la requête : Exécutez la requête SQL complète sur la base de données SAP S/4HANA ou via la couche de service appropriée. La requête est conçue pour être complète et peut prendre un temps d'exécution considérable en fonction du volume de données et de la plage de dates sélectionnée. Surveillez l'exécution pour détecter d'éventuelles erreurs ou dépassements de délai.
- Examiner les résultats initiaux : Une fois la requête terminée, effectuez un examen rapide de la sortie. Vérifiez que les colonnes
InvoiceNumber,ActivityNameetEventTimesont renseignées. Vérifiez que vous voyez une variété d'activités différentes dans la colonneActivityName, et pas seulement 'Document de facture créé'. - Traiter la transformation des données : La requête est structurée pour produire un format de journal d'événements propre. Cependant, assurez-vous que la colonne
EventTimeest dans un format d'horodatage cohérent, tel queAAAA-MM-JJTHH:MM:SS. La requête fournie combine les champs de date et d'heure en un seul horodatage si nécessaire. - Exporter les données : Exportez le jeu de résultats final de votre outil vers un fichier CSV (Comma-Separated Values). Ce format est universellement compatible avec les outils de Process Mining, y compris ProcessMind.
- Préparer le téléchargement : Avant le téléchargement, confirmez que le fichier CSV utilise l'encodage UTF-8 pour éviter les problèmes de caractères. Assurez-vous que les en-têtes de colonne du fichier correspondent exactement aux attributs requis :
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, etc. - Télécharger vers ProcessMind : Téléchargez le fichier CSV préparé dans votre projet de Process Mining. Mappez les colonnes de votre fichier aux champs correspondants d'ID de cas, de nom d'activité et d'horodatage dans la configuration du modèle de données de l'outil.
Configuration
- Vues CDS utilisées : Les sources de données primaires sont des vues CDS SAP standard. Les vues clés sont
I_InvoiceDocumentpour les données d'en-tête,I_OperationalAcctgDocItempour les détails de comptabilisation et de compensation financière, etI_ChangeDocumentavecI_ChangeDocumentItempour le suivi des modifications historiques des attributs de facture comme les blocages de paiement et l'état du Workflow. - Filtrage par plage de dates : Il est essentiel de filtrer les données par une plage de dates spécifique pour gérer les performances. La requête fournie utilise un paramètre de substitution pour la
CreationDatedans la vueI_InvoiceDocument. Un point de départ recommandé est une période de données de 3 à 6 mois. - Filtre par code société : Pour garantir que l'extraction est pertinente et gérable, filtrez toujours par un ou plusieurs
CompanyCode. La requête inclut un paramètre de substitutionWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')à cette fin. - Filtre par type de document : Vous pouvez affiner davantage l'extraction en filtrant sur
InvoiceDocumentType. Par exemple, vous pouvez vouloir inclure les factures fournisseurs standard (RE) mais exclure les avoirs. Cela peut être ajouté à la clauseWHEREdu CTE initial. - Prérequis : L'utilisateur exécutant la requête a besoin des autorisations d'affichage appropriées pour les documents financiers et d'achat au sein des codes société spécifiés. L'accès à la base de données HANA sous-jacente via un client SQL n'est pas standard et requiert des permissions spéciales.
- Considérations relatives aux performances : L'extraction de données à partir des tables de documents de modification (
I_ChangeDocument,I_ChangeDocumentItem) peut être gourmande en performances. L'application de filtres stricts sur la date, le code société et la classe d'objet (INCOMINGINVOICE) est essentielle pour éviter des temps d'exécution longs.
a Exemple de requête sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Étapes
- Prérequis et Autorisation : Assurez-vous que l'utilisateur exécutant l'extraction dispose des autorisations nécessaires dans SAP S/4HANA pour accéder aux vues Core Data Services (CDS) requises. Les vues clés incluent
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemetI_PaymentProposalItem. L'utilisateur aura également besoin des permissions pour exécuter des requêtes via l'interface choisie, telle qu'un service OData ou une connexion SQL directe. - Identifier votre méthode de connexion : Déterminez comment vous vous connecterez au système SAP S/4HANA pour exécuter la requête SQL. Les méthodes courantes incluent l'utilisation de SAP Data Services, SAP Data Intelligence, un outil ETL tiers avec un connecteur SAP, ou une connexion SQL directe à la base de données SAP HANA si les politiques de sécurité de votre organisation le permettent.
- Définir les paramètres d'extraction : Avant d'exécuter la requête, définissez les paramètres clés. Spécifiez la plage de dates pour l'extraction, par exemple,
CreationDateentre'AAAA-MM-JJ'et'AAAA-MM-JJ'. Identifiez également les valeursCompanyCodespécifiques que vous souhaitez inclure pour limiter la portée de l'extraction des données. - Personnaliser la requête SQL : Copiez la requête SQL fournie dans le client SQL ou l'outil d'extraction de données de votre choix. Examinez attentivement les paramètres de substitution, tels que
'{StartDate}','{EndDate}'et('{CompanyCode1}', '{CompanyCode2}'). Remplacez ces paramètres de substitution par les valeurs réelles que vous avez définies à l'étape précédente. Vous devrez peut-être également ajuster les noms de champs pour l'état du Workflow en fonction de votre configuration SAP spécifique. - Exécuter la requête : Exécutez la requête SQL complète sur la base de données SAP S/4HANA ou via la couche de service appropriée. La requête est conçue pour être complète et peut prendre un temps d'exécution considérable en fonction du volume de données et de la plage de dates sélectionnée. Surveillez l'exécution pour détecter d'éventuelles erreurs ou dépassements de délai.
- Examiner les résultats initiaux : Une fois la requête terminée, effectuez un examen rapide de la sortie. Vérifiez que les colonnes
InvoiceNumber,ActivityNameetEventTimesont renseignées. Vérifiez que vous voyez une variété d'activités différentes dans la colonneActivityName, et pas seulement 'Document de facture créé'. - Traiter la transformation des données : La requête est structurée pour produire un format de journal d'événements propre. Cependant, assurez-vous que la colonne
EventTimeest dans un format d'horodatage cohérent, tel queAAAA-MM-JJTHH:MM:SS. La requête fournie combine les champs de date et d'heure en un seul horodatage si nécessaire. - Exporter les données : Exportez le jeu de résultats final de votre outil vers un fichier CSV (Comma-Separated Values). Ce format est universellement compatible avec les outils de Process Mining, y compris ProcessMind.
- Préparer le téléchargement : Avant le téléchargement, confirmez que le fichier CSV utilise l'encodage UTF-8 pour éviter les problèmes de caractères. Assurez-vous que les en-têtes de colonne du fichier correspondent exactement aux attributs requis :
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, etc. - Télécharger vers ProcessMind : Téléchargez le fichier CSV préparé dans votre projet de Process Mining. Mappez les colonnes de votre fichier aux champs correspondants d'ID de cas, de nom d'activité et d'horodatage dans la configuration du modèle de données de l'outil.
Configuration
- Vues CDS utilisées : Les sources de données primaires sont des vues CDS SAP standard. Les vues clés sont
I_InvoiceDocumentpour les données d'en-tête,I_OperationalAcctgDocItempour les détails de comptabilisation et de compensation financière, etI_ChangeDocumentavecI_ChangeDocumentItempour le suivi des modifications historiques des attributs de facture comme les blocages de paiement et l'état du Workflow. - Filtrage par plage de dates : Il est essentiel de filtrer les données par une plage de dates spécifique pour gérer les performances. La requête fournie utilise un paramètre de substitution pour la
CreationDatedans la vueI_InvoiceDocument. Un point de départ recommandé est une période de données de 3 à 6 mois. - Filtre par code société : Pour garantir que l'extraction est pertinente et gérable, filtrez toujours par un ou plusieurs
CompanyCode. La requête inclut un paramètre de substitutionWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')à cette fin. - Filtre par type de document : Vous pouvez affiner davantage l'extraction en filtrant sur
InvoiceDocumentType. Par exemple, vous pouvez vouloir inclure les factures fournisseurs standard (RE) mais exclure les avoirs. Cela peut être ajouté à la clauseWHEREdu CTE initial. - Prérequis : L'utilisateur exécutant la requête a besoin des autorisations d'affichage appropriées pour les documents financiers et d'achat au sein des codes société spécifiés. L'accès à la base de données HANA sous-jacente via un client SQL n'est pas standard et requiert des permissions spéciales.
- Considérations relatives aux performances : L'extraction de données à partir des tables de documents de modification (
I_ChangeDocument,I_ChangeDocumentItem) peut être gourmande en performances. L'application de filtres stricts sur la date, le code société et la classe d'objet (INCOMINGINVOICE) est essentielle pour éviter des temps d'exécution longs.
a Exemple de requête sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Étapes
- Accéder à l'éditeur ABAP : Connectez-vous à votre système SAP S/4HANA. Ouvrez la transaction
SE38(Éditeur ABAP). - Créer le programme : Saisissez un nom pour votre nouveau programme dans le champ Programme, par exemple,
Z_PM_INVOICE_EXTRACT, et cliquez sur le bouton 'Créer'. Donnez un titre, définissez le Type sur 'Programme exécutable' et enregistrez-le dans un package approprié. - Définir la structure du programme et l'écran de sélection : Dans l'éditeur, définissez les structures de données pour la sortie du journal d'événements final. Ensuite, créez un écran de sélection pour permettre aux utilisateurs de saisir des paramètres comme une plage de dates pour la date de saisie de la facture, les codes société et les types de documents. Cela rend le programme réutilisable et flexible.
- Implémenter la logique de sélection des données : Écrivez les instructions SQL ABAP principales pour sélectionner les données des différentes tables SAP. Le programme interrogera séquentiellement chacune des 13 activités requises.
- Extraire les données d'en-tête et de poste : Pour les événements fondamentaux comme 'Document de facture créé' et 'Facture comptabilisée', sélectionnez les données des tables primaires telles que
RBKP(En-tête de facture logistique) etBKPF(En-tête de document comptable). - Extraire les données de document de modification : Pour des activités comme 'Blocage de paiement défini' et 'Blocage de paiement levé', interrogez les tables de documents de modification
CDHDR(En-tête de document de modification) etCDPOS(Postes de document de modification). Vous devrez identifier les modifications de champs spécifiques, par exemple,ZLSPRdans la tableBSEG. - Extraire les données de paiement : Pour capturer les activités liées au paiement, interrogez les tables comme
REGUP(Postes traités du programme de paiement) pour les propositions de paiement etBSAK(Postes fournisseurs compensés) pour les paiements exécutés. Différenciez 'Paiement en retard exécuté' en comparant la date de compensation (AUGDT) avec la date d'échéance nette (ZFBDT). - Extraire les données de Workflow : Pour les activités d'approbation, interrogez les tables de Workflow SAP Business telles que
SWW_WI2OBJpour lier les postes de Workflow aux objets de facture. Cette partie dépend fortement de votre configuration de Workflow spécifique et peut nécessiter une adaptation significative. - Unifier les données au format journal d'événements : Pour chaque activité sélectionnée, formatez les données dans une structure de table interne commune. Chaque ligne de cette table représente un événement unique et doit contenir l'identifiant de cas (
InvoiceNumber), le nom de l'activité (ActivityName) et l'heure de l'événement (EventTime), ainsi que d'autres attributs recommandés. - Générer le fichier de sortie : Utilisez les instructions ABAP
OPEN DATASET,TRANSFERetCLOSE DATASETpour écrire le contenu de la table interne finale dans un fichier plat sur le serveur d'applications SAP. Un format de valeurs séparées par des virgules (CSV) est recommandé. - Planifier et exécuter : Exécutez le programme en avant-plan pour les tests (en utilisant
F8). Pour les exécutions en production, planifiez-le comme une tâche d'arrière-plan à l'aide de la transactionSM36pour qu'il s'exécute en dehors des heures de pointe afin d'éviter d'impacter les performances du système. - Récupérer et télécharger : Utilisez la transaction
AL11pour naviguer vers le répertoire du serveur d'applications où le fichier a été enregistré. Téléchargez le fichier sur votre système local. Assurez-vous que le fichier est encodé en UTF-8 et formaté correctement avant de le télécharger dans l'outil de Process Mining.
Configuration
- Plage de dates : Définissez une plage de dates spécifique pour l'extraction basée sur la date de saisie de la facture (
RBKP-CPUDT) ou la date de comptabilisation (BKPF-BUDAT). Pour une analyse initiale, une période de 3 à 6 mois est recommandée pour garantir un volume de données gérable. - Code société (BUKRS) : Il est essentiel de filtrer par un ou plusieurs codes société. L'extraction de données pour tous les codes société d'une grande organisation peut entraîner des temps d'exécution extrêmement longs et des fichiers volumineux.
- Type de document (BLART) : Filtrez sur les types de documents pertinents pour isoler les factures fournisseurs. Les types courants incluent 'RE' (Facture - Brut) et 'KR' (Facture fournisseur). Cela permet d'exclure les documents non pertinents de l'analyse.
- Compte fournisseur (LIFNR) : Le programme peut inclure un filtre optionnel pour des numéros de fournisseurs spécifiques, ce qui est utile pour une analyse ciblée ou des tests.
- Configuration du fichier de sortie : Le programme doit avoir des paramètres pour définir le chemin du fichier de sortie sur le serveur d'applications et le délimiteur de champ, par exemple, une virgule ou un point-virgule.
- Prérequis : L'utilisateur ou le compte système exécutant ce programme nécessite un accès développeur pour créer et exécuter des programmes ABAP (via
SE38) et des autorisations de lecture étendues pour les tables FI, MM et Basis, y comprisBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOS, et les tables de Workflow.
a Exemple de requête abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path.