Modèle de données : Traitement des factures fournisseurs
Votre modèle de données pour le traitement des factures fournisseurs
- Attributs recommandés pour une analyse approfondie
- Activités clés du processus à suivre efficacement
- Guide d'extraction des données étape par étape
Attributs du traitement des factures fournisseurs
| Nom | Description | ||
|---|---|---|---|
Activité ActivityName | Le nom d'un événement ou d'une étape métier spécifique survenue dans le cycle de vie du traitement des factures. | ||
Description L'Activité représente une étape ou une action distincte dans le processus de comptabilité fournisseurs, telle que « Facture reçue », « Facture comptabilisée » ou « Paiement exécuté ». Ces activités sont les éléments constitutifs de la cartographie des processus. L'analyse des activités est au cœur du Process Mining. Elle aide à visualiser le flux de processus, à identifier les parcours courants, à détecter les écarts par rapport au processus standard et à mesurer la fréquence et la durée de chaque étape. La séquence de ces activités pour une facture donnée constitue son parcours de processus. Pourquoi c'est important Il définit les étapes du processus, permettant la visualisation et l'analyse du flux de processus, l'identification des goulots d'étranglement et la détection des boucles de retravail. Où obtenir Dérivé de diverses sources, notamment les changements de statut de document (ex: BKPF-BSTAT), les documents de modification (tables CDHDR/CDPOS) ou les logs de workflow. Cela requiert généralement une logique d'extraction personnalisée. Exemples Facture reçueFacture approuvéePaiement exécutéFacture bloquée pour paiement | |||
Event Time EventTime | La date et l'heure exactes de l'activité. | ||
Description L'Event Time est le timestamp associé à chaque activité, fournissant la séquence chronologique des événements pour une facture. Cette donnée est essentielle pour comprendre le flux de processus et réaliser toute analyse temporelle. En analyse, l'Event Time est utilisé pour ordonner correctement les activités, calculer les temps de cycle entre les différentes étapes, identifier les temps d'attente et analyser la performance du processus sur différentes périodes (par exemple, mois après mois). C'est le fondement de tous les KPIs basés sur la durée. Pourquoi c'est important Cet horodatage est essentiel pour ordonner les événements chronologiquement et calculer toutes les métriques temporelles, telles que les temps de cycle et les durées, qui sont fondamentales pour le Process Mining. Où obtenir Issue de divers champs de date/heure des tables SAP, tels que la Date de création (BKPF-CPUDT), la Date de comptabilisation (BKPF-BUDAT), la Date de compensation (BSAK-AUGDT) ou les horodatages du journal des modifications (CDHDR-UDATE/UTIME). Exemples 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
Facture Invoice | L'identifiant unique d'une facture, servant de référence principale (ID de cas) pour le processus de comptabilité fournisseurs. | ||
Description La Facture est l'objet central qui connecte toutes les activités connexes, de la réception au paiement. Dans SAP S/4HANA, il s'agit généralement d'une clé composite formée par le Code de société (BUKRS), un Numéro de document unique (BELNR) et l'Exercice (GJAHR). L'analyse par facture permet une vue complète de bout en bout du cycle de vie de la facture. Ceci est fondamental pour le calcul de métriques clés comme le temps de cycle total, l'identification des goulots d'étranglement pour les factures individuelles et la compréhension des différents chemins qu'une facture peut emprunter au cours du processus. Pourquoi c'est important Il identifie de manière unique le parcours de chaque facture, permettant ainsi de tracer son cycle de vie complet et d'analyser la performance du processus au cas par cas. Où obtenir Il s'agit d'une clé composite dérivée des tables BKPF (En-tête du document comptable) ou RBKP (En-tête du document : Réception de facture) en utilisant les champs BUKRS, BELNR et GJAHR. Exemples 1000-1900000001-20231710-1900000002-20232000-5100000003-2024 | |||
Dernière mise à jour des données LastDataUpdate | Le timestamp indiquant la dernière actualisation des données de cet enregistrement depuis le système source. | ||
Description Cet attribut fournit la date et l'heure de la dernière extraction ou mise à jour des données depuis SAP S/4HANA. C'est un champ de métadonnées crucial pour comprendre l'actualité des données analysées. Cette information est importante pour que les utilisateurs sachent à quel point l'analyse du processus est récente. Elle aide à gérer les attentes concernant la latence des données et est vitale pour la planification des actualisations de données et le maintien de leur intégrité. Pourquoi c'est important Indique la fraîcheur des données, garantissant aux utilisateurs de savoir à quel point leur analyse de processus est à jour. Où obtenir Cette valeur est générée et apposée sur chaque enregistrement au moment de l'extraction des données du système source. Exemples 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
Système source SourceSystem | Le système d'où les données ont été extraites. | ||
Description Cet attribut identifie l'origine des données du processus. Pour cette vue, la valeur sera généralement 'SAP S/4HANA'. Dans les environnements comportant plusieurs ERP ou systèmes intégrés, ce champ est essentiel pour la traçabilité et la séparation des données. Il garantit que l'analyse est effectuée sur le bon ensemble de données et aide à diagnostiquer les problèmes de qualité des données en les retraçant jusqu'à leur source. Pourquoi c'est important Identifie l'origine des données, ce qui est crucial pour la gouvernance des données, le dépannage et dans les environnements multi-systèmes. Où obtenir Il s'agit généralement d'une valeur statique ajoutée lors du processus d'extraction des données pour étiqueter l'origine de l'ensemble de données. Exemples SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
Code société CompanyCode | L'unité organisationnelle pour laquelle la facture est traitée. | ||
Description Un code de société est la plus petite unité organisationnelle pour laquelle un ensemble complet et autonome de comptes peut être établi pour les rapports externes. Dans le contexte des comptes fournisseurs, il représente l'entité juridique qui doit de l'argent au fournisseur. L'analyse par code de société permet de comparer la performance des processus entre les différentes entités juridiques au sein de l'organisation. Cela aide à identifier quelles parties de l'entreprise suivent les processus standards et lesquelles présentent une efficacité supérieure, des cycles plus longs ou des taux de reprise plus élevés. Pourquoi c'est important Permet de comparer la performance des processus entre différentes entités juridiques, ce qui aide à identifier les problèmes spécifiques à une région ou à une unité commerciale, ainsi que les meilleures pratiques. Où obtenir Trouvé dans les tables d'en-tête de document, principalement BKPF-BUKRS pour les factures FI et RBKP-BUKRS pour les factures MM. Exemples 10001710US01DE01 | |||
Date d'échéance de la facture InvoiceDueDate | La date à laquelle le paiement de la facture est dû au fournisseur. | ||
Description La Date d'échéance de la facture est la date limite pour payer le fournisseur afin d'éviter les pénalités de retard et de maintenir une bonne relation fournisseur. Cette date est calculée en fonction de la date de référence de la facture et des conditions de paiement convenues avec le fournisseur. Cette date est essentielle pour le dashboard « Conformité et ancienneté des paiements » et l'ICP « Taux de paiement dans les délais ». En comparant la date d'échéance avec la date de paiement réelle, l'analyse peut révéler si les paiements sont effectués à temps, en avance ou en retard, ce qui a des conséquences financières et relationnelles directes. Pourquoi c'est important Ceci est le principal moteur pour l'analyse des paiements à temps, permettant de mesurer la performance des règlements et leur impact sur les relations fournisseurs et les frais de retard. Où obtenir Cette date est souvent calculée. La date d'échéance nette se trouve dans le champ BSEG-NETDT. Elle peut également être dérivée de la date de base pour le paiement (BSEG-ZFBDT) et des conditions de paiement (BSEG-ZTERM). Exemples 2023-10-312023-11-152024-01-10 | |||
Montant de la facture InvoiceAmount | Le montant brut total de la facture, exprimé dans la devise d'origine du document. | ||
Description Il s'agit de la valeur totale de la facture telle que soumise par le fournisseur. Elle comprend le coût des biens ou services, les taxes et tout autre frais, avant toute déduction ou remise. Le montant de la facture est un attribut financier essentiel pour un large éventail d'analyses. Il aide à prioriser les factures de grande valeur, à comprendre l'impact financier des retards de processus (par exemple, les pénalités de retard sur les factures importantes) et à segmenter le processus (par exemple, « Les factures de grande valeur suivent-elles un circuit d'approbation différent ? »). Il est également crucial pour identifier les paiements potentiellement en double. Pourquoi c'est important Apporte un contexte financier au processus, permettant une analyse basée sur la valeur, la priorisation des factures de grande valeur et la quantification des impacts financiers. Où obtenir Trouvé dans des tables comme RBKP-RMWWR (Montant brut de la facture) pour les factures MM ou calculé à partir des postes dans BSEG (champ WRBTR) pour les factures FI. Exemples 1500.00250.7512345.50 | |||
Nom d'utilisateur UserName | L'identifiant de l'utilisateur ayant réalisé l'activité. | ||
Description Cet attribut enregistre l'ID utilisateur SAP responsable de l'exécution d'une activité spécifique, telle que la comptabilisation, l'approbation ou le lettrage d'une facture. Il relie les étapes du processus aux utilisateurs individuels. L'analyse par nom d'utilisateur est essentielle pour comprendre la répartition de la charge de travail, identifier les collaborateurs les plus performants et repérer les utilisateurs qui pourraient nécessiter une formation complémentaire. Elle est également clé pour analyser les goulets d'étranglement d'approbation dans les tableaux de bord, car elle aide à identifier les approbateurs spécifiques qui causent des retards dans le processus. Pourquoi c'est important Attribue les activités à des individus précis, ce qui permet d'analyser les performances des utilisateurs, leur charge de travail et la conformité aux politiques de ségrégation des tâches. Où obtenir Généralement trouvé dans les tables d'en-tête comme BKPF-USNAM (Saisi par) ou dans les tables de documents de modification CDHDR-USERNAME (Modifié par). Exemples ABROWNJSMITHAP_AUTOMATION | |||
Nom du fournisseur VendorName | Le nom du fournisseur qui a soumis la facture. | ||
Description Cet attribut contient le nom officiel du fournisseur. Il est lié via le numéro de fournisseur enregistré sur le document de facture. L'analyse des fournisseurs est cruciale pour gérer les relations avec eux et identifier les problèmes de processus spécifiques à certains d'entre eux. Elle peut aider à répondre à des questions telles que « Quels fournisseurs soumettent le plus de factures présentant des écarts ? » ou « Payons-nous systématiquement nos fournisseurs stratégiques à temps ? ». C'est également un champ clé, avec le numéro et le montant de la facture, pour la détection d'éventuels paiements en double. Pourquoi c'est important Analyse des performances par fournisseur pour identifier les problèmes et gérer efficacement les relations stratégiques. Où obtenir Extrait de la table des données de base fournisseurs LFA1 (champ NAME1), en effectuant un lien via le numéro de fournisseur (LIFNR) trouvé dans BKPF ou RBKP. Exemples Office Supplies Inc.Global Consulting GroupMachine Parts GmbH | |||
Numéro de bon de commande PurchaseOrderNumber | L'identifiant unique du bon de commande associé à la facture, le cas échéant. | ||
Description Cet attribut relie une facture à un bon de commande (BC) préapprouvé. La présence d'un numéro de BC est la base du processus de rapprochement triple (BC-Facture-Réception de marchandises). C'est un attribut essentiel pour l'analyse de la conformité et de l'efficacité. Il est utilisé pour calculer le KPI du « Pourcentage de factures sans bon de commande », qui mesure le respect des politiques d'approvisionnement. Il est également fondamental pour le tableau de bord de la « Performance du rapprochement triple », permettant l'analyse du processus de rapprochement pour les factures adossées à un BC. Pourquoi c'est important Crucial pour analyser l'efficacité du rapprochement à 3 voies et mesurer la conformité aux politiques d'approvisionnement en identifiant les factures traitées sans bon de commande. Où obtenir Trouvé dans les tables de postes de facture, telles que RSEG-EBELN (pour les factures MM) ou BSEG-EBELN (pour les factures FI). Exemples 45000012344500005678 | |||
Conditions de paiement PaymentTerms | Les conditions convenues avec le fournisseur pour le paiement d'une facture, incluant souvent des opportunités d'escompte. | ||
Description Les conditions de paiement définissent les règles pour les dates d'échéance des paiements et les escomptes potentiels pour paiement anticipé. Par exemple, une condition telle que 'Z001' pourrait correspondre à 'Payable sous 30 jours, 2 % d'escompte si payé en 10 jours'. Cet attribut est la base du tableau de bord 'Taux de capture des escomptes pour paiement anticipé'. En analysant les conditions de paiement, il est possible d'identifier toutes les factures éligibles à un escompte. La comparaison avec les escomptes réellement obtenus révèle les opportunités d'économies manquées et mesure l'efficacité du processus de paiement. Pourquoi c'est important Il est essentiel pour analyser les opportunités d'escompte pour paiement anticipé, mesurer la performance financière du processus de paiement et identifier les économies manquées. Où obtenir Trouvé dans les postes fournisseurs, table BSEG-ZTERM, ou dans l'en-tête de facture dans RBKP-ZTERM. Exemples Z0010001NT30 | |||
Date de compensation ClearingDate | La date à laquelle un paiement a été effectué et la facture a été compensée des postes ouverts. | ||
Description La Date de compensation indique le règlement financier de la facture. C'est la date à laquelle l'activité « Paiement compensé » a lieu, marquant l'étape finale pour la plupart des parcours de factures réussis. Cette date est utilisée pour calculer la date de paiement réelle afin de la comparer à la Date d'échéance de la facture. Elle est donc essentielle pour le calcul de l'ICP « Taux de paiement dans les délais » et pour toute analyse liée à la performance des paiements. Elle marque également le point final pour le calcul du temps de cycle de bout en bout de la facture. Pourquoi c'est important Marque le règlement final d'une facture, servant de point d'arrivée pour les calculs de temps de cycle et de base pour l'analyse des paiements dans les délais. Où obtenir Trouvé dans les tables des postes apurés, telles que BSAK-AUGDT pour les fournisseurs. Exemples 2023-10-282023-11-142024-01-09 | |||
Devise de la facture InvoiceCurrency | Le code de devise pour le montant de la facture (par ex. USD, EUR). | ||
Description Cet attribut spécifie la devise dans laquelle le montant de la facture est libellé. Il fournit un contexte essentiel pour toute valeur financière. Dans une organisation multinationale, analyser les factures sans tenir compte de leur devise peut être trompeur. Ce champ permet un traitement approprié des données financières, soit en convertissant tous les montants en une seule devise de reporting, soit en segmentant l'analyse par devise pour comprendre les activités financières régionales. Pourquoi c'est important Fournit le contexte nécessaire au Montant de la facture, permettant une analyse financière et un reporting précis, particulièrement dans des contextes multinationaux. Où obtenir Trouvé dans les tables d'en-tête de document, principalement BKPF-WAERS ou RBKP-WAERS. Exemples USDEURGBPJPY | |||
Escompte pris DiscountTaken | Un indicateur booléen spécifiant si un escompte pour paiement anticipé a été appliqué avec succès. | ||
Description Cet attribut indique si un escompte de caisse a réellement été appliqué lors du paiement de la facture. C'est un élément essentiel pour mesurer l'efficacité financière du processus de comptabilité fournisseurs. Cet indicateur est au cœur du KPI du « Taux de capture des escomptes pour paiement anticipé ». En filtrant les factures où un escompte était possible (selon les conditions de paiement) et en analysant ensuite cet indicateur, une entreprise peut calculer précisément le montant économisé et le nombre d'opportunités d'économies manquées. Cela fournit une mesure claire et quantifiable de la performance de la comptabilité fournisseurs. Pourquoi c'est important Mesure directement l'efficacité à bénéficier des escomptes pour paiement anticipé, ce qui a un impact direct sur le résultat net de l'entreprise. Où obtenir Dérivé en vérifiant si le champ du montant de l'escompte (BSEG-SKNTO) est supérieur à zéro dans le document de paiement. Exemples truefalse | |||
Est automatisé IsAutomated | Un indicateur signalant si l'activité a été effectuée automatiquement par le système plutôt que par un utilisateur humain. | ||
Description Cet attribut booléen distingue les activités initiées par l'homme des activités exécutées par des tâches système, des workflows ou des bots. Par exemple, une exécution de paiement automatisée ou une comptabilisation de facture générée par le système serait signalée comme automatisée. L'analyse de cet attribut aide à comprendre le niveau d'automatisation dans le processus de comptabilité fournisseurs. Il peut être utilisé pour mesurer le succès des initiatives d'automatisation, comparer l'efficacité des étapes automatisées par rapport aux étapes manuelles et identifier de nouvelles opportunités d'automatisation. Pourquoi c'est important Permet de mesurer le degré d'automatisation du processus, d'analyser son efficacité et d'identifier les opportunités d'amélioration continue. Où obtenir Dérivé à partir du nom d'utilisateur (par exemple, les ID utilisateur système comme 'SAP_SYSTEM' ou 'BATCHUSER') ou de codes de transaction spécifiques associés aux traitements automatisés. Exemples truefalse | |||
Est un paiement en retard IsLatePayment | Un indicateur booléen indiquant si la facture a été payée après sa date d'échéance. | ||
Description Cet attribut calculé est un simple indicateur vrai/faux qui signale si le paiement d'une facture a été effectué après sa date d'échéance officielle. Il est dérivé de la comparaison de la « Date de lettrage » avec la « Date d'échéance de la facture ». Cet indicateur simplifie l'analyse pour le tableau de bord « Conformité et Ancienneté des paiements » et le KPI du « Taux de paiement dans les délais ». Il permet un filtrage et une agrégation faciles pour compter le nombre de paiements en retard, calculer le pourcentage de paiements dans les délais et identifier les fournisseurs ou les sociétés ayant des taux élevés de paiements en retard. Pourquoi c'est important Mesure directement la conformité aux conditions de paiement, simplifie le calcul des KPI de paiement dans les délais et aide à identifier les domaines où la performance des paiements est insuffisante. Où obtenir Attribut calculé. La logique est la suivante : SI Date de compensation > Date d'échéance de la facture ALORS vrai SINON faux. Exemples truefalse | |||
Motif de blocage BlockingReason | La raison pour laquelle une facture est bloquée pour paiement, signalant une anomalie. | ||
Description Lorsqu'une facture échoue à un contrôle de validation durant le rapprochement à trois voies ou d'autres étapes de vérification, elle est bloquée pour paiement. Le motif de blocage précise la nature du problème, comme un écart de quantité, une variance de prix ou une réception de marchandises manquante. Cet attribut est essentiel pour le tableau de bord « Analyse du retravail des écarts de facture ». L'analyse de la fréquence des différents motifs de blocage aide à identifier les causes profondes des inefficacités du processus. Par exemple, si une « variance de prix » est une raison courante, cela peut pointer vers des problèmes de données de base dans le système d'achat. Pourquoi c'est important Fournit un aperçu direct des causes profondes des écarts de facturation et du retravail, permettant des efforts d'amélioration des processus ciblés. Où obtenir Stocké dans les tables de postes de facture comme RSEG, dans les champs commençant par SPGR* (par ex., SPGRP, SPGRQ, SPGRT). Peut également être trouvé dans RBKP_BLOCKED. Exemples Écart de prixÉcart de quantitéRéception de marchandises manquante | |||
Numéro de facture fournisseur VendorInvoiceNumber | Le numéro de facture fourni par le fournisseur sur son document. | ||
Description Il s'agit du numéro de référence provenant du système comptable du fournisseur, tel qu'il figure sur la facture physique ou électronique. Il est saisi manuellement ou capturé par OCR lors de la réception de la facture. Ce champ est d'une importance capitale pour les opérations et l'analyse, notamment pour le tableau de bord « Paiements de factures potentiellement en double ». Une méthode courante pour détecter les doublons consiste à rechercher plusieurs documents de facture internes qui partagent le même nom de fournisseur, le même numéro de facture fournisseur et le même montant de facture. C'est la référence externe principale pour une facture. Pourquoi c'est important C'est un champ clé pour la détection des paiements potentiellement en double et sert de référence externe principale pour la communication avec les fournisseurs. Où obtenir Stocké dans le champ 'Référence' de l'en-tête du document, généralement BKPF-XBLNR. Exemples INV-2023-9876733401120231015-001 | |||
Temps de traitement ProcessingTime | La durée d'une seule activité. | ||
Description Le Temps de traitement, ou durée d'activité, est le temps écoulé entre le début et la fin d'une activité. Cette métrique est calculée à partir des données de log d'événements. Cette mesure calculée est cruciale pour le tableau de bord 'Carte thermique des durées d'activité et des retouches'. Elle aide à identifier les étapes spécifiques du processus qui consomment le plus de temps. L'analyse des temps de traitement peut mettre en évidence des inefficacités, telles que de longues étapes d'approbation ou des activités prolongées de résolution des écarts, guidant ainsi les efforts d'amélioration ciblés. Pourquoi c'est important Quantifie le temps passé sur chaque activité, aidant à identifier les étapes les plus chronophages et les goulots d'étranglement du processus. Où obtenir Calculé en déterminant la différence entre l'EventTime de l'activité actuelle et l'EventTime de l'activité suivante pour la même facture. Exemples P2DT3H4MPT5HP7D | |||
Type de document de facture InvoiceDocumentType | Une classification du document de facture, qui détermine son traitement dans SAP. | ||
Description Le Type de document est un élément de configuration clé dans SAP qui catégorise les documents comptables. Par exemple, « KR » est généralement utilisé pour les factures fournisseurs, « RE » pour les factures MM et « KG » pour les avoirs fournisseurs. Ce type détermine des éléments tels que la plage de numéros et les champs obligatoires. En analyse de processus, le filtrage par Type de document permet de comparer les flux de processus pour différents types de factures. Par exemple, le processus d'approbation d'un avoir peut être différent de celui d'une facture standard. Ceci est utile pour le dashboard « Variantes de routage d'approbation des factures ». Pourquoi c'est important Segmente le processus selon le type de facture, révélant les variations dans les parcours et temps de traitement. Où obtenir Directement depuis la table d'en-tête de document, champ BKPF-BLART. Exemples KRREKG | |||
Activités de traitement des factures fournisseurs
| Activité | Description | ||
|---|---|---|---|
Facture annulée | Le document de facture a été annulé, annulant ainsi son impact financier. Il s'agit d'un état final alternatif pour le processus, souvent dû à des saisies incorrectes ou à des litiges avec les fournisseurs. | ||
Pourquoi c'est important Le suivi des annulations aide à identifier les causes des échecs de processus, tels que les soumissions en double ou les données de facture incorrectes, ce qui peut révéler des problèmes en amont. Où obtenir Cette donnée est explicitement enregistrée lors de la création d'un document d'annulation. L'en-tête du document original (BKPF) contiendra alors le numéro (STBLG) et le motif de l'annulation. Capture Identifiez la date de comptabilisation du document d'annulation, qui est lié dans l'en-tête du document original (BKPF-STBLG). Type d'événement explicit | |||
Facture approuvée | La facture a reçu toutes les approbations nécessaires dans le système de workflow. C'est souvent l'étape finale avant qu'une facture puisse être comptabilisée ou débloquée pour paiement. | ||
Pourquoi c'est important Cette étape clé marque la fin du cycle d'approbation. Le délai entre l'acheminement et l'approbation est une métrique d'efficacité cruciale. Où obtenir Capturé à partir des logs SAP Business Workflow comme une étape d'achèvement ou de libération finale. Alternativement, il peut être déduit de la levée d'un blocage de paiement post-acheminement. Capture Extraire les événements de complétion du workflow depuis les logs SAP workflow ou identifier l'événement final de 'libération'. Type d'événement explicit | |||
Facture bloquée pour paiement | Le système a automatiquement ou manuellement placé un blocage sur la facture, l'empêchant d'être payée. Ceci est généralement dû à des écarts de prix, de quantité ou à des approbations manquantes. | ||
Pourquoi c'est important C'est un indicateur clé de problèmes et de reprises. L'analyse des motifs et des durées de blocage aide à identifier les causes profondes des retards de paiement et des inefficacités de processus. Où obtenir Il s'agit d'un statut explicite enregistré dans le champ Clé de blocage de paiement (ZLSPR) de la ligne d'article fournisseur du document comptable (table BSEG). Capture Enregistré via des documents de modification lorsque le champ BSEG-ZLSPR est renseigné avec un motif de blocage. Type d'événement explicit | |||
Facture enregistrée | La facture est formellement enregistrée dans le Grand Livre, créant une dette financière. Un document de facture provisoire devient un document comptabilisé, ou une imputation directe est effectuée. | ||
Pourquoi c'est important C'est un jalon financier critique. Il confirme l'obligation de paiement de l'entreprise et est souvent une condition préalable à la planification du paiement. Où obtenir Cet événement est identifié par la Date de comptabilisation (BUDAT) dans l'en-tête du document (BKPF). Un document comptabilisé a un statut de document (BKPF-BSTAT) vide. Capture Utilisez l'horodatage de comptabilisation (BKPF-BUDAT) pour les documents qui ne sont pas mémorisés (BKPF-BSTAT est vide). Type d'événement explicit | |||
Facture reçue | Cette activité marque la création d'un document de facture dans SAP, soit manuellement, soit via une interface automatisée telle qu'OCR/VIM. Cet événement est généralement capturé à partir de la date et de l'heure de création de l'en-tête du document comptable. | ||
Pourquoi c'est important En tant que point de départ du processus, cette activité est fondamentale pour le calcul du temps de cycle de la facture de bout en bout et la mesure du débit global du processus des Comptes Fournisseurs. Où obtenir Cet événement est capturé à partir de la table d'en-tête du document comptable (BKPF), en utilisant la date (CPUDT) et l'heure (CPUTM) de création du document. Capture Utilisez l'horodatage de création (BKPF-CPUDT, BKPF-CPUTM) pour le document de facture. Type d'événement explicit | |||
Paiement exécuté | Paiement de la facture effectué et enregistré à la fin de l'exécution du paiement, avec création et comptabilisation du document. | ||
Pourquoi c'est important Cette activité est essentielle pour l'analyse des flux de trésorerie et pour mesurer le KPI du « Taux de paiement dans les délais » en comparant cette date à la date d'échéance de la facture. Où obtenir Cette information est tirée de la date de comptabilisation du document de paiement qui solde la facture. Le numéro de ce document de paiement est lié via le champ de compensation (AUGBL) du poste de facture (BSEG). Capture Identifiez la date de comptabilisation (BUDAT) du document de paiement qui apure le poste de facture. Type d'événement explicit | |||
Paiement réglé | Cette activité marque la clôture finale de la facture, où le paiement et la facture sont rapprochés dans le grand livre auxiliaire. Elle signifie que le processus est terminé. | ||
Pourquoi c'est important En tant qu'étape finale du processus, cette activité est essentielle pour calculer avec précision le temps de cycle de bout en bout. Elle confirme que l'obligation de paiement est réglée. Où obtenir Il s'agit d'un événement explicite marqué par le renseignement du champ Date de lettrage (AUGDT) dans la ligne d'article fournisseur du document de facture (table BSEG). Capture Utilisez la date de compensation (BSEG-AUGDT) du poste de facture. Type d'événement explicit | |||
Bon de commande rapproché | Cette activité signifie que la facture a été rapprochée avec succès d'un bon de commande correspondant. C'est une étape cruciale du processus de rapprochement triple pour les factures liées à l'approvisionnement. | ||
Pourquoi c'est important L'analyse de cette activité est cruciale pour mesurer l'efficacité du processus de rapprochement et constitue un pilier pour les KPI de 'Performance du rapprochement à 3 voies' et de 'Pourcentage de factures sans bon de commande'. Où obtenir Ceci est déduit lorsqu'un poste de facture dans la table BSEG ou ACDOCA contient un numéro de commande d'achat (EBELN) et un poste (EBELP) valides. Capture Déduit de la présence d'une référence de commande d'achat (BSEG-EBELN) sur le document de facture lors de sa création. Type d'événement inferred | |||
Date d'échéance de la facture dépassée | Un événement calculé signalant le dépassement de la date d'échéance nette d'une facture sans paiement, indiquant un retard. | ||
Pourquoi c'est important Essentielle pour le dashboard 'Conformité des paiements et ancienneté', cette activité aide à identifier et à gérer de manière proactive les factures en souffrance et à analyser les causes profondes des retards de paiement. Où obtenir Il ne s'agit pas d'un événement explicite dans SAP. Il est calculé en comparant la date actuelle du système avec la date d'échéance nette (calculée à partir de BSEG-ZFBDT ou de la date de base et des conditions de paiement). Capture Événement calculé déclenché lorsque le timestamp de l'événement est supérieur à la date d'échéance nette de la facture. Type d'événement calculated | |||
Écart résolu | Cette activité indique qu'un problème précédemment identifié, qui avait probablement entraîné un blocage de paiement, a été examiné et résolu. Elle est enregistrée lorsque le blocage de paiement est levé sur une facture. | ||
Pourquoi c'est important Le suivi de cette boucle de retravail est crucial pour le tableau de bord « Analyse du retravail des écarts de facture ». Il permet de quantifier le temps et les efforts consacrés à la correction des erreurs. Où obtenir Ceci est déduit des documents de modification qui indiquent la levée d'un blocage de paiement. Le journal des modifications du champ BSEG-ZLSPR constitue la source principale. Capture Identifiez les documents de modification pour la table BSEG où le champ ZLSPR passe d'une valeur à vide. Type d'événement inferred | |||
Facture pré-enregistrée | Représente une facture qui a été saisie dans le système mais pas encore comptabilisée dans le grand livre. Il s'agit souvent d'une étape intentionnelle pour sauvegarder un document incomplet en vue d'un traitement ou d'une approbation ultérieurs. | ||
Pourquoi c'est important Le suivi des factures mémorisées aide à identifier les retards avant le début du processus de comptabilisation formel et peut mettre en lumière des problèmes de complétude des données ou de validation initiale. Où obtenir Ce statut est déduit du champ de statut du document dans l'en-tête du document comptable (BKPF-BSTAT = 'V' pour Mémorisé). L'événement se produit lorsque ce statut est défini. Capture Identifiez les documents de modification pour la table BKPF où le champ BSTAT est défini sur 'V' (Vor-erfasst/Pré-saisie). Type d'événement inferred | |||
Facture rejetée | Un approbateur a rejeté la facture durant le workflow, la renvoyant au responsable pour correction ou clarification. | ||
Pourquoi c'est important Le suivi des rejets met en évidence les boucles de retravail au sein du processus d'approbation et peut indiquer des problèmes de conformité aux politiques ou une codification de facture incorrecte. Où obtenir Ceci est capturé comme un événement de résultat spécifique dans les journaux du workflow SAP Business associés à la facture. Capture Extraire les événements de statut 'rejeté' du workflow depuis les logs SAP workflow. Type d'événement explicit | |||
Facture routée pour approbation | La facture a été soumise à un workflow pour les approbations requises, conformément aux règles métier. Cela marque le début du sous-processus d'approbation. | ||
Pourquoi c'est important Cette activité constitue le point de départ pour mesurer le KPI du « Délai moyen d'approbation des factures » et analyser les goulets d'étranglement dans le processus d'approbation. Où obtenir Peut être capturé à partir des logs SAP Business Workflow (tables SWW*) qui enregistrent le début d'une instance de workflow liée à l'objet facture (ex: BUS2081). Capture Extraire les événements de début de workflow depuis les logs SAP workflow (ex: table SWW_WIHEAD) liés au document de facture. Type d'événement explicit | |||
Proposition de paiement créée | La facture a été incluse dans une proposition de paiement dans le cadre d'une exécution de paiement (par ex. F110). Elle est maintenant prévue pour paiement, en attente de l'exécution finale de la transaction. | ||
Pourquoi c'est important Cette activité montre la transition d'un engagement non soldé vers un poste activement préparé pour le paiement, ce qui aide à analyser l'efficacité des opérations de paiement. Où obtenir Cet événement est explicitement enregistré dans les tables de données des exécutions de paiement, spécifiquement REGUP (Postes traités par le programme de paiement) et REGUH (En-tête). Capture Identifiez quand une facture apparaît dans la table REGUP pour une exécution de paiement identifiée dans REGUH. Type d'événement explicit | |||
Réception de marchandises rapprochée | Cette activité signifie que les quantités et les valeurs de la facture ont été rapprochées avec succès d'un document de réception de marchandises correspondant. Il s'agit de la validation finale dans un scénario de rapprochement triple. | ||
Pourquoi c'est important Le suivi de ces éléments aide à identifier les inefficacités dans le processus de rapprochement à trois voies et à déceler les écarts entre les marchandises reçues et ce qui est facturé par le fournisseur. Où obtenir Ceci est déduit de la présence d'une référence de document article (réception de marchandises) sur le poste de facture, souvent liée via l'historique des postes de commande d'achat. Capture Déduit de la présence d'une référence de document de réception de marchandises sur le poste de facture (par exemple, dans RSEG pour les factures MIRO). Type d'événement inferred | |||
Guides d'extraction
Étapes
- Prérequis et accès : Assurez-vous de disposer d'un utilisateur avec un accès en lecture au schéma de la base de données SAP S/4HANA (généralement SAPABAP1 ou similaire) où résident les vues CDS. Vous aurez besoin d'un outil client SQL capable de se connecter à la base de données SAP HANA, tel que SAP HANA Studio, DBeaver ou des outils de requête de base de données similaires.
- Identifier les vues CDS principales : Les principales vues CDS pour cette extraction sont I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails et I_PaymentProposalItem. Familiarisez-vous avec leurs champs clés.
- Définir la portée de la requête : Ouvrez votre client SQL et connectez-vous à la base de données SAP HANA. Avant d'exécuter la requête complète, définissez la portée de votre extraction. Cela implique de configurer l'identifiant correct du système source, la plage de dates pour les factures (CreationDateTime) et les codes de société pertinents.
- Préparer la requête principale : Copiez la requête SQL complète fournie dans la section query dans votre client SQL. La requête utilise des expressions de table communes (CTE) pour d'abord sélectionner une population de base de factures, puis construire un journal d'événements en combinant les données de 15 activités différentes.
- Définir les paramètres de la requête : Dans la requête SQL copiée, localisez les variables de remplacement. Remplacez '[YYYY-MM-DD]' par les dates de début et de fin de votre période d'analyse. Remplacez '[Your Company Code 1]', '[Your Company Code 2]' par la liste des codes de société SAP que vous souhaitez analyser.
- Exécuter la requête d'extraction : Exécutez la requête SQL complète. Selon le volume de données et la plage de dates sélectionnée, cette opération peut prendre de quelques minutes à plusieurs heures.
- Examiner les résultats préliminaires : Une fois la requête terminée, examinez les premières centaines de lignes du résultat. Vérifiez la cohérence des données, assurez-vous que toutes les colonnes sont remplies comme prévu et que différentes valeurs ActivityName sont présentes.
- Exporter le journal d'événements : Exportez l'ensemble des résultats de votre client SQL vers un fichier CSV. Assurez-vous que le fichier est encodé en UTF-8 pour éviter les problèmes de caractères. Nommez le fichier de manière descriptive, par exemple, sap_s4hana_ap_event_log.csv.
- Préparer l'importation : Avant d'importer le fichier vers un outil de Process Mining, confirmez que les en-têtes de colonne du fichier CSV correspondent exactement aux noms d'attributs requis : Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc.
- Importer dans l'outil de Process Mining : Importez le fichier CSV généré sur votre plateforme de Process Mining, en mappant les colonnes aux champs correspondants d'ID de cas, d'activité et d'horodatage.
Configuration
- Principales Vues CDS : L'extraction s'appuie sur une combinaison de Vues CDS S/4HANA standard. Les vues principales sont :
- I_JournalEntry & I_JournalEntryItem : Pour les en-têtes de documents financiers, les postes, les détails de comptabilisation et les informations de lettrage.
- I_SupplierInvoiceAPI01 : Pour les détails spécifiques aux factures MM (Logistique), incluant les références de commandes et les blocages de paiement.
- I_ChangeDocument : Pour suivre l'horodatage exact des modifications, comme l'activation ou la suppression d'un blocage de paiement.
- I_WorkflowStatusDetails : Pour extraire les événements liés au workflow d'approbation des factures.
- I_PaymentProposalItem : Pour identifier quand une facture est incluse dans une proposition de lot de paiement.
- I_Supplier : Pour enrichir les données avec des informations de base fournisseur, comme VendorName.
- Filtrage par Plage de Dates : Il est crucial d'appliquer un filtre de plage de dates pour limiter le volume de données. La requête fournie filtre sur CreationDateTime dans le CTE Invoices_Base. Une plage de 3 à 6 mois est recommandée pour une analyse initiale afin d'assurer des performances gérables.
- Filtres Obligatoires : Toujours filtrer par CompanyCode. L'analyse des données de tous les codes société simultanément peut être extrêmement lente et ne pas être pertinente pour l'entreprise. De plus, filtrez sur JournalEntryType pour sélectionner uniquement les documents liés aux fournisseurs (par exemple, 'KR', 'RE').
- Prérequis : L'utilisateur de la base de données qui exécute la requête doit disposer de l'autorisation SELECT sur toutes les Vues CDS utilisées dans la requête et sur le schéma HANA sous-jacent. L'accès au niveau applicatif via l'interface SAP GUI n'est pas suffisant.
- Considérations de Performance : Les requêtes directes sur I_ChangeDocument peuvent être gourmandes en ressources. La requête fournie tente d'atténuer cela en pré-filtrant les factures. Pour les jeux de données très volumineux, envisagez d'exécuter l'extraction pendant les heures creuses ou par lots de plages de dates plus petites.
a Exemple de requête sql
`sql
-- Common Table Expression (CTE) to select the base set of AP Invoices
WITH Invoices_Base AS (
SELECT
I_JournalEntry.CompanyCode,
I_JournalEntry.AccountingDocument,
I_JournalEntry.FiscalYear,
CONCAT(I_JournalEntry.CompanyCode, CONCAT(I_JournalEntry.AccountingDocument, I_JournalEntry.FiscalYear)) AS InvoiceId,
I_JournalEntry.CreationDateTime,
I_JournalEntry.CreatedByUser,
I_JournalEntry.DocumentStatus,
I_JournalEntry.JournalEntryType,
I_JournalEntry.ReversalReferenceJournalEntry,
I_JournalEntry.IsReversed,
I_JournalEntry.ReversalDate,
IJE_ITEM.NetDueDate,
IJE_ITEM.Supplier,
SUP.SupplierName AS VendorName,
IJE_ITEM.AmountInCompanyCodeCurrency AS InvoiceAmount,
MM.PurchaseOrder AS PurchaseOrderNumber,
MM.PaymentBlockingReason
FROM I_JournalEntry
-- Join to get item details like due date and supplier
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON I_JournalEntry.CompanyCode = IJE_ITEM.CompanyCode
AND I_JournalEntry.AccountingDocument = IJE_ITEM.AccountingDocument
AND I_JournalEntry.FiscalYear = IJE_ITEM.FiscalYear
AND IJE_ITEM.IsSupplier = 'X'
-- Join to get vendor name from master data
LEFT JOIN I_Supplier AS SUP
ON IJE_ITEM.Supplier = SUP.Supplier
-- Join to get MM Invoice specific data like PO Number and Payment Block
LEFT JOIN I_SupplierInvoiceAPI01 AS MM
ON I_JournalEntry.AccountingDocument = MM.AccountingDocument
AND I_JournalEntry.CompanyCode = MM.CompanyCode
AND I_JournalEntry.FiscalYear = MM.FiscalYear
WHERE
I_JournalEntry.JournalEntryType IN ('KR', 'RE') -- Standard Vendor Invoice Types
AND I_JournalEntry.CompanyCode IN ('[Your Company Code 1]', '[Your Company Code 2]')
AND I_JournalEntry.CreationDateTime BETWEEN '[YYYY-MM-DD]T00:00:00Z' AND '[YYYY-MM-DD]T23:59:59Z'
)
-- Event: 1. Invoice Received
SELECT
B.InvoiceId AS "Invoice",
'Invoice Received' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
UNION ALL
-- Event: 2. Invoice Parked
SELECT
B.InvoiceId AS "Invoice",
'Invoice Parked' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.DocumentStatus = 'V' -- 'V' stands for Parked
UNION ALL
-- Event: 3. Purchase Order Matched
SELECT
B.InvoiceId AS "Invoice",
'Purchase Order Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PurchaseOrderNumber IS NOT NULL AND B.PurchaseOrderNumber <> ''
UNION ALL
-- Event: 4. Goods Receipt Matched
SELECT
B.InvoiceId AS "Invoice",
'Goods Receipt Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_SupplierInvoiceItemAPI01 AS MM_ITEM
ON B.AccountingDocument = MM_ITEM.AccountingDocument
AND B.FiscalYear = MM_ITEM.FiscalYear
WHERE MM_ITEM.GoodsReceipt IS NOT NULL AND MM_ITEM.GoodsReceipt <> ''
UNION ALL
-- Event: 5. Invoice Blocked For Payment
SELECT
B.InvoiceId AS "Invoice",
'Invoice Blocked For Payment' AS "ActivityName",
B.CreationDateTime AS "EventTime", -- Approximates block time as creation time if blocked on entry
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PaymentBlockingReason IS NOT NULL AND B.PaymentBlockingReason <> ''
UNION ALL
-- Event: 6. Discrepancy Resolved (Payment Block Removed)
SELECT
B.InvoiceId AS "Invoice",
'Discrepancy Resolved' AS "ActivityName",
CD.ChangeTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CD.UserName AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_ChangeDocument AS CD
ON CONCAT(B.CompanyCode, B.AccountingDocument, B.FiscalYear) = CD.ObjectValue
WHERE CD.ChangeDocumentObject = 'INVOICE'
AND CD.TableName = 'RBKP'
AND CD.FieldName = 'ZLSPR' -- Field for Payment Block
AND CD.NewFieldValue = '' -- Block was removed
UNION ALL
-- Event: 7, 8, 9. Workflow Events (Routed, Approved, Rejected)
SELECT
B.InvoiceId AS "Invoice",
CASE WF.WorkflowStatus
WHEN 'READY' THEN 'Invoice Routed For Approval'
WHEN 'APPROVED' THEN 'Invoice Approved'
WHEN 'REJECTED' THEN 'Invoice Rejected'
END AS "ActivityName",
WF.WorkflowStatusChangedDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
WF.WorkflowStatusChangedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_WorkflowStatusDetails AS WF
ON B.InvoiceId = WF.WorkflowScenarioInstance
WHERE WF.WorkflowStatus IN ('READY', 'APPROVED', 'REJECTED')
UNION ALL
-- Event: 10. Invoice Posted
SELECT
B.InvoiceId AS "Invoice",
'Invoice Posted' AS "ActivityName",
JE.PostingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntry AS JE
ON B.AccountingDocument = JE.AccountingDocument
AND B.CompanyCode = JE.CompanyCode
AND B.FiscalYear = JE.FiscalYear
WHERE B.DocumentStatus <> 'V' -- Any status other than Parked is considered Posted for AP
UNION ALL
-- Event: 11. Payment Proposal Created
SELECT
B.InvoiceId AS "Invoice",
'Payment Proposal Created' AS "ActivityName",
PPI.PaymentProposalRunDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
PPI.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_PaymentProposalItem AS PPI
ON B.CompanyCode = PPI.CompanyCode
AND B.AccountingDocument = PPI.AccountingDocument
AND B.FiscalYear = PPI.FiscalYear
UNION ALL
-- Event: 12. Payment Executed
-- This links the invoice to its clearing document, which is the payment document
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Executed' AS "ActivityName",
CLEAR_JE.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CLEAR_JE.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
INNER JOIN I_JournalEntry AS CLEAR_JE
ON IJE_ITEM.ClearingJournalEntry = CLEAR_JE.AccountingDocument
AND IJE_ITEM.CompanyCode = CLEAR_JE.CompanyCode
WHERE IJE_ITEM.ClearingJournalEntry IS NOT NULL AND IJE_ITEM.ClearingJournalEntry <> ''
AND CLEAR_JE.JournalEntryType = 'KZ' -- Vendor Payment Document Type
UNION ALL
-- Event: 13. Invoice Due Date Passed
SELECT
B.InvoiceId AS "Invoice",
'Invoice Due Date Passed' AS "ActivityName",
ADD_DAYS(B.NetDueDate, 1) AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
'SYSTEM' AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE B.NetDueDate < CURRENT_DATE
AND IJE_ITEM.ClearingDate IS NULL -- Invoice is not yet cleared
UNION ALL
-- Event: 14. Payment Cleared
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Cleared' AS "ActivityName",
IJE_ITEM.ClearingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
IJE_ITEM.ChangedByUser AS "UserName", -- User who cleared it
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE IJE_ITEM.ClearingDate IS NOT NULL
UNION ALL
-- Event: 15. Invoice Cancelled
SELECT
B.InvoiceId AS "Invoice",
'Invoice Cancelled' AS "ActivityName",
B.ReversalDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName", -- User who created the original document
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.IsReversed = 'X';
`Étapes
- Prérequis et accès : Assurez-vous de disposer d'un utilisateur avec un accès en lecture au schéma de la base de données SAP S/4HANA (généralement SAPABAP1 ou similaire) où résident les vues CDS. Vous aurez besoin d'un outil client SQL capable de se connecter à la base de données SAP HANA, tel que SAP HANA Studio, DBeaver ou des outils de requête de base de données similaires.
- Identifier les vues CDS principales : Les principales vues CDS pour cette extraction sont I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails et I_PaymentProposalItem. Familiarisez-vous avec leurs champs clés.
- Définir la portée de la requête : Ouvrez votre client SQL et connectez-vous à la base de données SAP HANA. Avant d'exécuter la requête complète, définissez la portée de votre extraction. Cela implique de configurer l'identifiant correct du système source, la plage de dates pour les factures (CreationDateTime) et les codes de société pertinents.
- Préparer la requête principale : Copiez la requête SQL complète fournie dans la section query dans votre client SQL. La requête utilise des expressions de table communes (CTE) pour d'abord sélectionner une population de base de factures, puis construire un journal d'événements en combinant les données de 15 activités différentes.
- Définir les paramètres de la requête : Dans la requête SQL copiée, localisez les variables de remplacement. Remplacez '[YYYY-MM-DD]' par les dates de début et de fin de votre période d'analyse. Remplacez '[Your Company Code 1]', '[Your Company Code 2]' par la liste des codes de société SAP que vous souhaitez analyser.
- Exécuter la requête d'extraction : Exécutez la requête SQL complète. Selon le volume de données et la plage de dates sélectionnée, cette opération peut prendre de quelques minutes à plusieurs heures.
- Examiner les résultats préliminaires : Une fois la requête terminée, examinez les premières centaines de lignes du résultat. Vérifiez la cohérence des données, assurez-vous que toutes les colonnes sont remplies comme prévu et que différentes valeurs ActivityName sont présentes.
- Exporter le journal d'événements : Exportez l'ensemble des résultats de votre client SQL vers un fichier CSV. Assurez-vous que le fichier est encodé en UTF-8 pour éviter les problèmes de caractères. Nommez le fichier de manière descriptive, par exemple, sap_s4hana_ap_event_log.csv.
- Préparer l'importation : Avant d'importer le fichier vers un outil de Process Mining, confirmez que les en-têtes de colonne du fichier CSV correspondent exactement aux noms d'attributs requis : Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc.
- Importer dans l'outil de Process Mining : Importez le fichier CSV généré sur votre plateforme de Process Mining, en mappant les colonnes aux champs correspondants d'ID de cas, d'activité et d'horodatage.
Configuration
- Principales Vues CDS : L'extraction s'appuie sur une combinaison de Vues CDS S/4HANA standard. Les vues principales sont :
- I_JournalEntry & I_JournalEntryItem : Pour les en-têtes de documents financiers, les postes, les détails de comptabilisation et les informations de lettrage.
- I_SupplierInvoiceAPI01 : Pour les détails spécifiques aux factures MM (Logistique), incluant les références de commandes et les blocages de paiement.
- I_ChangeDocument : Pour suivre l'horodatage exact des modifications, comme l'activation ou la suppression d'un blocage de paiement.
- I_WorkflowStatusDetails : Pour extraire les événements liés au workflow d'approbation des factures.
- I_PaymentProposalItem : Pour identifier quand une facture est incluse dans une proposition de lot de paiement.
- I_Supplier : Pour enrichir les données avec des informations de base fournisseur, comme VendorName.
- Filtrage par Plage de Dates : Il est crucial d'appliquer un filtre de plage de dates pour limiter le volume de données. La requête fournie filtre sur CreationDateTime dans le CTE Invoices_Base. Une plage de 3 à 6 mois est recommandée pour une analyse initiale afin d'assurer des performances gérables.
- Filtres Obligatoires : Toujours filtrer par CompanyCode. L'analyse des données de tous les codes société simultanément peut être extrêmement lente et ne pas être pertinente pour l'entreprise. De plus, filtrez sur JournalEntryType pour sélectionner uniquement les documents liés aux fournisseurs (par exemple, 'KR', 'RE').
- Prérequis : L'utilisateur de la base de données qui exécute la requête doit disposer de l'autorisation SELECT sur toutes les Vues CDS utilisées dans la requête et sur le schéma HANA sous-jacent. L'accès au niveau applicatif via l'interface SAP GUI n'est pas suffisant.
- Considérations de Performance : Les requêtes directes sur I_ChangeDocument peuvent être gourmandes en ressources. La requête fournie tente d'atténuer cela en pré-filtrant les factures. Pour les jeux de données très volumineux, envisagez d'exécuter l'extraction pendant les heures creuses ou par lots de plages de dates plus petites.
a Exemple de requête sql
`sql
-- Common Table Expression (CTE) to select the base set of AP Invoices
WITH Invoices_Base AS (
SELECT
I_JournalEntry.CompanyCode,
I_JournalEntry.AccountingDocument,
I_JournalEntry.FiscalYear,
CONCAT(I_JournalEntry.CompanyCode, CONCAT(I_JournalEntry.AccountingDocument, I_JournalEntry.FiscalYear)) AS InvoiceId,
I_JournalEntry.CreationDateTime,
I_JournalEntry.CreatedByUser,
I_JournalEntry.DocumentStatus,
I_JournalEntry.JournalEntryType,
I_JournalEntry.ReversalReferenceJournalEntry,
I_JournalEntry.IsReversed,
I_JournalEntry.ReversalDate,
IJE_ITEM.NetDueDate,
IJE_ITEM.Supplier,
SUP.SupplierName AS VendorName,
IJE_ITEM.AmountInCompanyCodeCurrency AS InvoiceAmount,
MM.PurchaseOrder AS PurchaseOrderNumber,
MM.PaymentBlockingReason
FROM I_JournalEntry
-- Join to get item details like due date and supplier
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON I_JournalEntry.CompanyCode = IJE_ITEM.CompanyCode
AND I_JournalEntry.AccountingDocument = IJE_ITEM.AccountingDocument
AND I_JournalEntry.FiscalYear = IJE_ITEM.FiscalYear
AND IJE_ITEM.IsSupplier = 'X'
-- Join to get vendor name from master data
LEFT JOIN I_Supplier AS SUP
ON IJE_ITEM.Supplier = SUP.Supplier
-- Join to get MM Invoice specific data like PO Number and Payment Block
LEFT JOIN I_SupplierInvoiceAPI01 AS MM
ON I_JournalEntry.AccountingDocument = MM.AccountingDocument
AND I_JournalEntry.CompanyCode = MM.CompanyCode
AND I_JournalEntry.FiscalYear = MM.FiscalYear
WHERE
I_JournalEntry.JournalEntryType IN ('KR', 'RE') -- Standard Vendor Invoice Types
AND I_JournalEntry.CompanyCode IN ('[Your Company Code 1]', '[Your Company Code 2]')
AND I_JournalEntry.CreationDateTime BETWEEN '[YYYY-MM-DD]T00:00:00Z' AND '[YYYY-MM-DD]T23:59:59Z'
)
-- Event: 1. Invoice Received
SELECT
B.InvoiceId AS "Invoice",
'Invoice Received' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
UNION ALL
-- Event: 2. Invoice Parked
SELECT
B.InvoiceId AS "Invoice",
'Invoice Parked' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.DocumentStatus = 'V' -- 'V' stands for Parked
UNION ALL
-- Event: 3. Purchase Order Matched
SELECT
B.InvoiceId AS "Invoice",
'Purchase Order Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PurchaseOrderNumber IS NOT NULL AND B.PurchaseOrderNumber <> ''
UNION ALL
-- Event: 4. Goods Receipt Matched
SELECT
B.InvoiceId AS "Invoice",
'Goods Receipt Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_SupplierInvoiceItemAPI01 AS MM_ITEM
ON B.AccountingDocument = MM_ITEM.AccountingDocument
AND B.FiscalYear = MM_ITEM.FiscalYear
WHERE MM_ITEM.GoodsReceipt IS NOT NULL AND MM_ITEM.GoodsReceipt <> ''
UNION ALL
-- Event: 5. Invoice Blocked For Payment
SELECT
B.InvoiceId AS "Invoice",
'Invoice Blocked For Payment' AS "ActivityName",
B.CreationDateTime AS "EventTime", -- Approximates block time as creation time if blocked on entry
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PaymentBlockingReason IS NOT NULL AND B.PaymentBlockingReason <> ''
UNION ALL
-- Event: 6. Discrepancy Resolved (Payment Block Removed)
SELECT
B.InvoiceId AS "Invoice",
'Discrepancy Resolved' AS "ActivityName",
CD.ChangeTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CD.UserName AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_ChangeDocument AS CD
ON CONCAT(B.CompanyCode, B.AccountingDocument, B.FiscalYear) = CD.ObjectValue
WHERE CD.ChangeDocumentObject = 'INVOICE'
AND CD.TableName = 'RBKP'
AND CD.FieldName = 'ZLSPR' -- Field for Payment Block
AND CD.NewFieldValue = '' -- Block was removed
UNION ALL
-- Event: 7, 8, 9. Workflow Events (Routed, Approved, Rejected)
SELECT
B.InvoiceId AS "Invoice",
CASE WF.WorkflowStatus
WHEN 'READY' THEN 'Invoice Routed For Approval'
WHEN 'APPROVED' THEN 'Invoice Approved'
WHEN 'REJECTED' THEN 'Invoice Rejected'
END AS "ActivityName",
WF.WorkflowStatusChangedDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
WF.WorkflowStatusChangedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_WorkflowStatusDetails AS WF
ON B.InvoiceId = WF.WorkflowScenarioInstance
WHERE WF.WorkflowStatus IN ('READY', 'APPROVED', 'REJECTED')
UNION ALL
-- Event: 10. Invoice Posted
SELECT
B.InvoiceId AS "Invoice",
'Invoice Posted' AS "ActivityName",
JE.PostingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntry AS JE
ON B.AccountingDocument = JE.AccountingDocument
AND B.CompanyCode = JE.CompanyCode
AND B.FiscalYear = JE.FiscalYear
WHERE B.DocumentStatus <> 'V' -- Any status other than Parked is considered Posted for AP
UNION ALL
-- Event: 11. Payment Proposal Created
SELECT
B.InvoiceId AS "Invoice",
'Payment Proposal Created' AS "ActivityName",
PPI.PaymentProposalRunDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
PPI.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_PaymentProposalItem AS PPI
ON B.CompanyCode = PPI.CompanyCode
AND B.AccountingDocument = PPI.AccountingDocument
AND B.FiscalYear = PPI.FiscalYear
UNION ALL
-- Event: 12. Payment Executed
-- This links the invoice to its clearing document, which is the payment document
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Executed' AS "ActivityName",
CLEAR_JE.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CLEAR_JE.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
INNER JOIN I_JournalEntry AS CLEAR_JE
ON IJE_ITEM.ClearingJournalEntry = CLEAR_JE.AccountingDocument
AND IJE_ITEM.CompanyCode = CLEAR_JE.CompanyCode
WHERE IJE_ITEM.ClearingJournalEntry IS NOT NULL AND IJE_ITEM.ClearingJournalEntry <> ''
AND CLEAR_JE.JournalEntryType = 'KZ' -- Vendor Payment Document Type
UNION ALL
-- Event: 13. Invoice Due Date Passed
SELECT
B.InvoiceId AS "Invoice",
'Invoice Due Date Passed' AS "ActivityName",
ADD_DAYS(B.NetDueDate, 1) AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
'SYSTEM' AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE B.NetDueDate < CURRENT_DATE
AND IJE_ITEM.ClearingDate IS NULL -- Invoice is not yet cleared
UNION ALL
-- Event: 14. Payment Cleared
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Cleared' AS "ActivityName",
IJE_ITEM.ClearingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
IJE_ITEM.ChangedByUser AS "UserName", -- User who cleared it
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE IJE_ITEM.ClearingDate IS NOT NULL
UNION ALL
-- Event: 15. Invoice Cancelled
SELECT
B.InvoiceId AS "Invoice",
'Invoice Cancelled' AS "ActivityName",
B.ReversalDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName", -- User who created the original document
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.IsReversed = 'X';
`Étapes
- Spécification et Conception : Avant le codage, collaborez avec les analystes métier pour confirmer les conditions de déclenchement exactes et les champs de données pour chacune des 15 activités requises. Identifiez les tables SAP pertinentes, les types de documents (par exemple, 'KR', 'RE') et les codes société à inclure dans le périmètre.
- Création du programme ABAP : Lancez l'éditeur ABAP à l'aide du code de transaction SE38. Créez un nouveau programme exécutable, par exemple, Z_PM_AP_INVOICE_EXTRACT. Donnez-lui un titre descriptif et définissez son application sur 'Comptabilité financière'.
- Définition de l'écran de sélection : Dans le programme, définissez un écran de sélection (en utilisant les mots-clés PARAMETERS et SELECT-OPTIONS) pour permettre aux utilisateurs de spécifier la plage de dates d'extraction (pour la date de création des factures), les codes société cibles (BUKRS) et les types de documents de facture pertinents (BLART). Incluez également un paramètre pour le chemin du fichier de sortie sur le serveur d'applications.
- Déclarations de données : Définissez une structure de table interne qui correspond au format final du journal d'événements (par exemple, TY_EVENT_LOG), incluant tous les attributs requis et recommandés. Déclarez des tables internes pour contenir les données sélectionnées à partir de diverses tables sources SAP telles que BKPF, BSEG, RBKP, RSEG, CDHDR, CDPOS et REGUH.
- Sélection principale des données : Commencez la logique d'extraction en sélectionnant l'ensemble principal des factures de RBKP (Factures logistiques) et BKPF (Factures financières) en fonction des critères de l'écran de sélection de l'utilisateur. Stockez ces clés de facture primaires dans une table interne pour piloter les recherches de données ultérieures.
- Extraction séquentielle des activités : Pour chaque facture de l'ensemble principal, effectuez une série de sélections afin de récupérer les horodatages et les détails de chaque activité commerciale. Par exemple, interrogez CDHDR et CDPOS pour les modifications de blocage de paiement, REGUH et REGUP pour les données d'exécution de paiement, et BKPF pour les détails du document d'annulation. Ajoutez un nouvel enregistrement à la table finale du journal d'événements pour chaque activité trouvée.
- Logique des événements calculés : Implémentez la logique ABAP pour les activités qui ne sont pas directement stockées dans un champ de table. Pour l'événement 'Date d'échéance de la facture dépassée', utilisez la date d'échéance de la facture (BSEG-ZFBDT + conditions de paiement) et la date de compensation (BSEG-AUGDT). Si la date de compensation est postérieure à la date d'échéance, créez un nouvel enregistrement d'événement avec l'horodatage défini sur cette date d'échéance.
- Transformation et enrichissement des données : Au fur et à mesure que vous collectez les données pour chaque activité, renseignez tous les attributs requis. Cela implique la recherche des noms de fournisseurs dans LFA1, la conversion des dates et heures en une seule chaîne d'horodatage (CONCATENATE...INTO...), et la définition de la valeur SourceSystem.
- Génération du fichier de sortie : Une fois toutes les factures et leurs activités correspondantes traitées et collectées dans la table interne finale, utilisez les instructions OPEN DATASET, LOOP AT ... TRANSFER et CLOSE DATASET pour écrire les données dans un fichier, à l'emplacement spécifié sur l'écran de sélection du serveur d'applications.
- Téléchargement et préparation à l'importation : Utilisez le code de transaction CG3Y pour télécharger le fichier généré du serveur d'applications vers votre machine locale. Assurez-vous que le fichier est enregistré au format CSV encodé en UTF-8. Vérifiez que les en-têtes de colonne correspondent aux attributs requis (Invoice, ActivityName, EventTime, etc.) avant de l'importer dans l'outil de Process Mining.
Configuration
- Plage de Dates: Définissez l'option de sélection P_CPUDT pour la date de création de la facture (BKPF-CPUDT ou RBKP-CPUDT). Une plage de 6 à 12 mois de données est recommandée pour une analyse initiale.
- Code Société (P_BUKRS): Un paramètre SELECT-OPTIONS obligatoire pour filtrer des codes société spécifiques. Le traitement simultané de tous les codes société n'est pas recommandé, sauf en cas d'absolue nécessité.
- Type de Document de Facture (P_BLART): Un paramètre SELECT-OPTIONS pour filtrer les types de documents de facture pertinents. Les types courants incluent 'KR' (Facture Fournisseur), 'KG' (Avoir Fournisseur), 'RE' (Vérification Facture Logistique).
- Mode d'Exécution: Le programme doit être exécuté en tâche de fond (SM36/SM37) pour les volumes importants de données afin d'éviter les délais d'attente dans le processus de dialogue au premier plan. Planifiez son exécution en dehors des heures de pointe.
- Chemin du Fichier de Sortie: Un PARAMETER pour spécifier le chemin et le nom du fichier sur le serveur d'applications SAP (par exemple, dans le répertoire /tmp/). Le fichier y est écrit avant d'être téléchargé.
- Prérequis: L'utilisateur exécutant le rapport doit disposer de l'autorisation de lecture des tables FI, CO et MM (BKPF, BSEG, RBKP, RSEG, LFA1), des tables de documents de modification (CDHDR, CDPOS) et des tables de workflow. De plus, l'objet d'autorisation S_DATASET est nécessaire pour écrire des fichiers sur le serveur d'applications.
a Exemple de requête abap
`abap
*&---------------------------------------------------------------------*
*& Report Z_PM_AP_INVOICE_EXTRACT
*&---------------------------------------------------------------------*
*& This report extracts Accounts Payable invoice lifecycle events for
*& process mining analysis.
*&---------------------------------------------------------------------*
REPORT z_pm_ap_invoice_extract.
*&---------------------------------------------------------------------*
*& Data Structures
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoice TYPE belnr_d,
activityname TYPE string,
eventtime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
username TYPE uname,
companycode TYPE bukrs,
vendorname TYPE name1_gp,
invoiceamount TYPE wrbtr,
purchaseordernumber TYPE ebeln,
invoiceduedate TYPE d,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gv_system_id TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_cpudt FOR bkpf-cpudt OBLIGATORY DEFAULT sy-datum,
s_blart FOR bkpf-blart.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/tmp/ap_extract.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" Get System ID and Update Timestamp
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_system_id
EXCEPTIONS
own_logical_system_not_defined = 1
OTHERS = 2.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
" Internal tables for SAP data
DATA: lt_bkpf TYPE TABLE OF bkpf,
lt_rbkp TYPE TABLE OF rbkp.
" Select base documents
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND ( blart = 'KR' OR blart = 'KG' ). " Example FI Invoice Types
SELECT * FROM rbkp INTO TABLE lt_rbkp
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND blart = 'RE'. " Example MM Invoice Type
" --- Process each invoice document ---
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
PERFORM process_invoice USING <fs_bkpf>.
ENDLOOP.
LOOP AT lt_rbkp ASSIGNING FIELD-SYMBOL(<fs_rbkp>).
PERFORM process_mm_invoice USING <fs_rbkp>.
ENDLOOP.
" Write output to file
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form PROCESS_INVOICE (Handles FI Invoices)
*&---------------------------------------------------------------------*
FORM process_invoice USING iv_bkpf TYPE bkpf.
DATA: ls_bseg TYPE bseg,
ls_lfa1 TYPE lfa1,
ld_due_date TYPE d.
DATA: ls_event TYPE ty_event_log.
" Get Vendor and other details from first line item
SELECT SINGLE * FROM bseg INTO ls_bseg
WHERE bukrs = iv_bkpf-bukrs
AND belnr = iv_bkpf-belnr
AND gjahr = iv_bkpf-gjahr
AND koart = 'K'.
IF sy-subrc = 0.
SELECT SINGLE name1 FROM lfa1 INTO ls_lfa1-name1 WHERE lifnr = ls_bseg-lifnr.
CALL FUNCTION 'DETERMINE_DUE_DATE'
EXPORTING
i_zfbdt = ls_bseg-zfbdt
i_zbd1t = ls_bseg-zbd1t
i_zbd2t = ls_bseg-zbd2t
i_zbd3t = ls_bseg-zbd3t
i_zbd1p = ls_bseg-zbd1p
i_zbd2p = ls_bseg-zbd2p
i_zterm = ls_bseg-zterm
IMPORTING
e_faedt = ld_due_date.
ENDIF.
" Helper function to populate common fields
MACRO set_common_fields.
ls_event-invoice = iv_bkpf-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_bkpf-bukrs.
ls_event-vendorname = ls_lfa1-name1.
ls_event-invoiceduedate = ld_due_date.
SELECT SINGLE wrbtr FROM bseg INTO ls_event-invoiceamount WHERE belnr = iv_bkpf-belnr AND gjahr = iv_bkpf-gjahr AND koart = 'K'.
ENDMACRO.
" 1. Invoice Received
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
" 2. Invoice Parked (if document was created as parked)
IF iv_bkpf-bstat = 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Parked'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 10. Invoice Posted (For non-parked, same as received. For parked, this needs CDHDR/CDPOS logic not shown for brevity)
IF iv_bkpf-bstat <> 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Posted'.
CONCATENATE iv_bkpf-budat iv_bkpf-cputm INTO ls_event-eventtime. " Using posting date
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 5. & 7. Invoice Blocked / Discrepancy Resolved from Change Docs
DATA: lt_cdhdr TYPE TABLE OF cdhdr, lt_cdpos TYPE TABLE OF cdpos.
DATA(ld_objectkey) = |{ iv_bkpf-bukrs }{ iv_bkpf-belnr }{ iv_bkpf-gjahr }|.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr WHERE objectclas = 'BELEG' AND objectid = ld_objectkey.
IF sy-subrc = 0.
SELECT * FROM cdpos INTO TABLE lt_cdpos FOR ALL ENTRIES IN lt_cdhdr
WHERE changenr = lt_cdhdr-changenr AND tabname = 'BSEG' AND fname = 'ZLSPR'.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>).
READ TABLE lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>) WITH KEY changenr = <fs_cdpos>-changenr.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
IF <fs_cdpos>-value_new IS NOT INITIAL AND <fs_cdpos>-value_old IS INITIAL.
ls_event-activityname = 'Invoice Blocked For Payment'.
ELSEIF <fs_cdpos>-value_new IS INITIAL AND <fs_cdpos>-value_old IS NOT INITIAL.
ls_event-activityname = 'Discrepancy Resolved'.
ELSE.
CONTINUE.
ENDIF.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO ls_event-eventtime.
ls_event-username = <fs_cdhdr>-username.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDIF.
" 6. 8. 9. Workflow Events (Routed, Approved, Rejected) - Simplified Example
" This requires knowledge of specific workflow templates. Placeholder logic:
" SELECT ... FROM SWW_WI2OBJ ... WHERE INSTID = [Invoice Object]
" SELECT ... FROM SWWWIHEAD ... to get status and times
" 11. & 12. & 14. Payment Proposal, Executed, Cleared
IF ls_bseg-augbl IS NOT INITIAL.
DATA: ls_regup TYPE regup.
SELECT SINGLE * FROM regup INTO ls_regup WHERE vblnr = ls_bseg-belnr.
IF sy-subrc = 0.
DATA(ld_rundate) = ls_regup-laufd.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Proposal Created'.
CONCATENATE ld_rundate '000000' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Executed'.
CONCATENATE ls_bseg-augdt '120000' INTO ls_event-eventtime. " Using clearing date as proxy
APPEND ls_event TO gt_event_log.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Cleared'.
CONCATENATE ls_bseg-augdt '120001' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
" 13. Invoice Due Date Passed (Calculated)
IF ls_bseg-augdt IS NOT INITIAL AND ld_due_date IS NOT INITIAL.
IF ls_bseg-augdt > ld_due_date.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Due Date Passed'.
CONCATENATE ld_due_date '235959' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
" 15. Invoice Cancelled
IF iv_bkpf-stblg IS NOT INITIAL.
DATA: ls_rev_bkpf TYPE bkpf.
SELECT SINGLE * FROM bkpf INTO ls_rev_bkpf WHERE belnr = iv_bkpf-stblg.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Cancelled'.
CONCATENATE ls_rev_bkpf-cpudt ls_rev_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = ls_rev_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form PROCESS_MM_INVOICE (Handles MM/Logistics Invoices)
*&---------------------------------------------------------------------*
FORM process_mm_invoice USING iv_rbkp TYPE rbkp.
" This form would be similar to PROCESS_INVOICE, but starts with RBKP.
" It needs to find the corresponding FI document in BKPF via AWKEY.
" The logic for PO/GR Matched would be included here.
" For demonstration, creating placeholder events for MM-specific activities.
DATA: ls_event TYPE ty_event_log.
ls_event-invoice = iv_rbkp-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_rbkp-bukrs.
" 1. Invoice Received (MM)
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 3. Purchase Order Matched (Implicit)
ls_event-activityname = 'Purchase Order Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 4. Goods Receipt Matched (Implicit)
ls_event-activityname = 'Goods Receipt Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" NOTE: The rest of the events (Block, Pay, etc.) would be found by linking
" RBKP to BKPF and then reusing the logic from PROCESS_INVOICE.
" Link: BKPF-AWKEY = CONCATENATE( RBKP-BELNR, RBKP-GJAHR ).
ENDFORM.
*&---------------------------------------------------------------------*
*& Form WRITE_OUTPUT_FILE
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lv_string TYPE string.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_string = 'Invoice,ActivityName,EventTime,SourceSystem,LastDataUpdate,UserName,CompanyCode,VendorName,InvoiceAmount,PurchaseOrderNumber,InvoiceDueDate'.
TRANSFER lv_string TO p_fpath.
" Write Data
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
" Create a comma-separated string, handling potential commas in data
CONCATENATE <fs_event>-invoice
<fs_event>-activityname
<fs_event>-eventtime
<fs_event>-sourcesystem
<fs_event>-lastdataupdate
<fs_event>-username
<fs_event>-companycode
<fs_event>-vendorname
<fs_event>-invoiceamount
<fs_event>-purchaseordernumber
<fs_event>-invoiceduedate
INTO lv_string SEPARATED BY ','.
TRANSFER lv_string TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'Extraction complete. File written to:', p_fpath.
ENDFORM.
`