Votre Modèle de Données Du Bon de De la commande au paiement - Traitement des facturess factures fournisseurs factures fournisseurs Factures
Votre Modèle de Données Du Bon de De la commande au paiement - Traitement des facturess factures fournisseurs factures fournisseurs Factures
- Attributs recommandés à collecter
- Activités clés à suivre
- Conseils d'extraction pour `SAP S/4HANA`
Du Bon de De la commande au paiement - Attributs de Traitement des facturess factures fournisseurs factures fournisseurs Factures
| Nom | Descriptionn | ||
|---|---|---|---|
| Numéro de facture InvoiceNumber | L'identifiant unique du document de facture fournisseur, servant d'identifiant de dossier principal pour le processus. | ||
| Descriptionn 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 indispensable pour suivre le parcours complet de chaque facture. Il permet la reconstruction de l'intégralité du flux de processus, de la réception au paiement final, permettant l'analyse des temps de cycle, des points de blocage et des variations de processus au niveau de chaque facture. Pourquoi est-ce 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. Source des données : 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. | ||
| Descriptionn 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 indispensables 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 points de blocage où les factures sont retardées et repérer les opportunités d'accélération des processus. Pourquoi est-ce important ? : Cet horodatage est la base de toutes les analyses temporelles, y compris le suivi des performances, l'identification des points de blocage et le suivi des SLA. Source des données : 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. | ||
| Descriptionn Le nom de l'activité décrit une étape spécifique ou un changement de statut dans le 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 impératif pour la construction de la cartographie 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 points de blocage, les boucles de reprise et les variations de processus non conformes. Il constitue l'pilier central de toute analyse de Process Mining. Pourquoi est-ce important ? : Il définit les étapes du processus, pour visualiser des cartes de processus et l'analyse des flux de processus et des variations. Source des données : 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. | ||
| Descriptionn Le numéro de document d'achat lie la facture fournisseur à la commande d'achat (PO) d'origine. Ce lien est indispensable 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 indispensable pour enquêter sur les divergences de rapprochement et comprendre l'efficacité de la partie approvisionnement du processus. Pourquoi est-ce important ? : Lie la facture au processus d'approvisionnement, ce qui est indispensable pour analyser les écarts de rapprochement et la conformité des bons de commande. Source des données : Ces informationsns se trouvent généralement dans la table de segment de document BSEG, champ EBELN (Numéro de documentment 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. | ||
| Descriptionn Le code société est une unité organisationnelle clée 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 indispensable pour analyser la performance des processus dans 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 est-ce important ? : Il permet de segmenter et de comparer la performance du traitement des factures entre différentes entités juridiques ou emplacements géographiques dans l'organisation. Source des données : 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. | ||
| Descriptionn 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 indispensable pour le KPI 'Taux de paiement ponctuel' et le tableau de bord '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 est-ce important ? : C'est le principal repère pour mesurer la performance des paiements ponctuels, ce qui est impératif pour maintenir de bonnes relations avec les fournisseurs et éviter les frais de retard. Source des données : 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é. | ||
| Descriptionn 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 est-ce 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. Source des données : 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. | ||
| Descriptionn 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 impératif pour le tableau de bord '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 est-ce 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. Source des données : 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é. | ||
| Descriptionn 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 indispensable pour le calcul du KPI 'Taux d'automatisation des factures'. Pourquoi est-ce 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. Source des données : 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. | ||
| Descriptionn 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 indispensable 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 est-ce 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. Source des données : Généralement disponible 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. | ||
| Descriptionn 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 analyses de vos processus plus précises et pertinentes. Pourquoi est-ce 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. Source des données : 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. | ||
| Descriptionn 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 indispensable 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 est-ce 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. Source des données : 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. | ||
| Descriptionn 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 clée 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 est-ce important ? : Sert de base pour le calcul des conditions et des dates d'échéance de paiement, ce qui est indispensable pour gérer le fonds de roulement et capturer les escomptes. Source des données : 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 Automatisé IsAutomated | Un indicateur signalant si une activité a été réalisée par un utilisateur système automatisé. | ||
| Descriptionn 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 indispensable 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 est-ce important ? : Distingue les activités manuelles des activités pilotées par le système, ce qui est indispensable pour mesurer les taux d'automatisation et identifier les opportunités d'automatisation supplémentaire. Source des données : 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 reprises 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é. | ||
| Descriptionn Cet attribut signale les factures ayant subi une ou plusieurs boucles de reprise. 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 est-ce 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. Source des données : 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. | ||
| Descriptionn Cet attribut enregistre l'horodatage de l'événement d'extraction de données. Il reflète la la réactualisation 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 indispensable 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 est-ce important ? : Indique la la réactualisation des données, garantissant que l'analyse et le reporting sont basés sur les informations les plus actuelles disponibles. Source des données : 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. | ||
| Descriptionn 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 impératif 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 est-ce 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. Source des données : 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. | ||
| Descriptionn 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 indispensable pour calculer le temps de cycle complet et le taux de paiement à temps. Pourquoi est-ce important ? : Confirme qu'une facture a été payée et la lie à la transaction de paiement spécifique, ce qui est indispensable pour l'analyse du temps de cycle et de la performance de paiement. Source des données : Trouvé dans la table de segment de document BSEG, champ AUGBL (Numéro de documentment 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. | ||
| Descriptionn 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 contribue directement au 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 est-ce 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. Source des données : Calculé en comptant les occurrences de l'activité 'Facture envoyée pour approbation' pour chaque InvoiceNumber unique. Exemples 123 | |||
| Paiement à temps IsPaidOnTime | Un indicateur qui est vrai si la facture a été payée à ou avant sa date d'échéance de paiement. | ||
| Descriptionn 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 ponctuel'. 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 est-ce 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. Source des données : Calculé en comparant l'(EventTime) de l'activité 'Paiement exécuté' avec l'attribut PaymentDueDate. (Date de paiement <= PaymentDueDate). Exemples truefaux | |||
| Raison de l'annulation ReversalReason | Un code indiquant la raison pour laquelle un document de facture a été annulé. | ||
| Descriptionn 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 est-ce 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. Source des données : Trouvé dans l'en-tête du document original dans la table BKPF, champ STGRD (Raison d'annulation). Exemples 010205 | |||
Du Bon de De la commande au paiement - Activités de Traitement des facturess factures fournisseurs factures fournisseurs Factures
| Activité | Descriptionn | ||
|---|---|---|---|
| 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 est-ce 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. Source des données : 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 est-ce 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. Source des données : 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 est-ce 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 indispensable pour l'amélioration des processus et la réduction des inexactitudes financières. Source des données : 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 est-ce 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 indispensablele pour mesurer le délai de traitement global. Source des données : 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 est-ce important ? : Ceci marque la fin du cycle de vie de la facture P2P. Il est indispensable pour calculer le temps de cycle total complet et pour mesurer la performance de paiement à temps par rapport à la date d'échéance. Source des données : 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 est-ce 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 indispensablele pour améliorer les taux de paiement à temps. Source des données : 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 est-ce 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 indispensable pour améliorer l'efficacité et les relations avec les fournisseurs. Source des données : 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 est-ce 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. Source des données : 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 est-ce important ? : C'est le point de départ pour mesurer le temps de cycle d'approbation. Comprendre quand les approbations commencent est indispensable pour identifier les points de blocage dans le workflow d'approbation lui-même. Source des données : 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 est-ce 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. Source des données : 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 est-ce 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. Source des données : 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 est-ce important ? : Cette activité contribue directement au 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. Source des données : 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 est-ce 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. Source des données : 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,(ActivityName)et(EventTime)sont renseignées. Vérifiez que vous voyez une variété d'activités différentes dans la colonne(ActivityName), 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
(EventTime)est 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 indispensable 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 danss 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 indispensablele 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,(ActivityName)et(EventTime)sont renseignées. Vérifiez que vous voyez une variété d'activités différentes dans la colonne(ActivityName), 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
(EventTime)est 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 indispensable 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 danss 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 indispensablele 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 indispensable 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.