Votre modèle de données pour le traitement des factures fournisseurs
Votre modèle de données pour le traitement des factures fournisseurs
- Attributs recommandés pour une analyse complète
- 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 | Nom d’un événement ou d’une étape métier spécifique survenu au cours du cycle de traitement de la facture. | ||
| Description L’activité représente une étape ou une action distincte du processus fournisseurs, telle que « Facture reçue », « Facture comptabilisée » ou « Paiement exécuté ». Ces activités constituent les éléments de base de la cartographie du processus. L’analyse des activités est au cœur du Process Mining. Elle permet de visualiser le flux du processus, d’identifier les parcours fréquents, de détecter les écarts par rapport au processus standard et de mesurer la fréquence et la durée de chaque étape. La séquence de ces activités pour une facture donnée forme son parcours dans le processus. Pourquoi c’est important Il définit les étapes du processus et permet de visualiser et d’analyser le flux, d’identifier les goulots d’étranglement et de détecter les boucles de reprise. Où les obtenir Dérivé de différentes sources, notamment des changements de statut des documents, par exemple BKPF-BSTAT, des documents de modification, tables CDHDR/CDPOS, ou des journaux du flux de travail. Cela nécessite généralement une logique d’extraction personnalisée. Exemples Facture reçueFacture approuvéePaiement exécutéFacture bloquée pour paiement | |||
| Facture Invoice | Identifiant unique d’un document de facture, utilisé comme identifiant principal du dossier dans le processus fournisseurs. | ||
| Description La facture est l’objet central qui relie toutes les activités associées, de sa réception à son paiement. Dans SAP S/4HANA, il s’agit généralement d’une clé composite formée du code société (BUKRS), d’un numéro de document unique (BELNR) et de l’exercice fiscal (GJAHR). L’analyse par facture offre une vue complète du cycle de vie de la facture, de bout en bout. Elle est fondamentale pour calculer des indicateurs tels que le délai total de traitement, identifier les goulots d’étranglement propres à certaines factures et comprendre les différents parcours possibles dans le processus. Pourquoi c’est important Il identifie de manière unique le parcours de chaque facture, ce qui permet d’en retracer le cycle de vie complet et d’analyser la performance du processus au cas par cas. Où les 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), à partir des champs BUKRS, BELNR et GJAHR. Exemples 1000-1900000001-20231710-1900000002-20232000-5100000003-2024 | |||
| Heure de l’événement EventTime | Date et heure exactes auxquelles l’activité s’est produite. | ||
| Description L’heure de l’événement est l’horodatage associé à chaque activité. Elle fournit la séquence chronologique des événements d’une facture. Ces données sont essentielles pour comprendre le flux du processus et effectuer toute analyse fondée sur le temps. Dans les analyses, l’heure de l’événement sert à ordonner correctement les activités, à calculer les délais entre les différentes étapes, à identifier les temps d’attente et à analyser la performance du processus sur différentes périodes, par exemple d’un mois à l’autre. Elle constitue le fondement de tous les KPI liés à la durée. Pourquoi c’est important Cet horodatage est essentiel pour ordonner les événements chronologiquement et calculer tous les indicateurs temporels, tels que les délais et les durées, qui sont fondamentaux pour le Process Mining. Où les obtenir Provient de différents champs de date et d’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 des journaux de modifications (CDHDR-UDATE/UTIME). Exemples 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la date à laquelle les données de cet enregistrement ont été actualisées pour la dernière fois 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. Il s’agit d’un champ de métadonnées essentiel pour évaluer l’actualité des données analysées. Cette information permet aux utilisateurs de connaître la fraîcheur de l’analyse du processus. Elle aide à gérer les attentes concernant la latence des données, à planifier les actualisations et à préserver l’intégrité des données. Pourquoi c’est important Indique l’actualité des données et permet aux utilisateurs de savoir dans quelle mesure leur analyse du processus est à jour. Où les obtenir Cette valeur est générée et apposée sur chaque enregistrement lors de l’extraction des données depuis le système source. Exemples 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
| Système source SourceSystem | Système à partir duquel les données ont été extraites. | ||
| Description Cet attribut identifie l’origine des données du processus. Dans cette vue, sa valeur sera généralement « SAP S/4HANA ». Dans les environnements comprenant plusieurs ERP ou systèmes intégrés, ce champ est essentiel pour assurer la traçabilité et la séparation des données. Il garantit que l’analyse porte sur le jeu de données approprié et facilite le diagnostic des problèmes de qualité en permettant de remonter jusqu’à la source. Pourquoi c’est important Identifie l’origine des données, ce qui est essentiel pour la gouvernance des données, le dépannage et les environnements multisystèmes. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction afin d’indiquer l’origine du jeu de données. Exemples SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
| Code société CompanyCode | Unité organisationnelle pour laquelle la facture est traitée. | ||
| Description Un code société est la plus petite unité organisationnelle pour laquelle un ensemble complet et autonome de comptes peut être établi à des fins de reporting externe. Dans le contexte des processus fournisseurs, il représente l’entité juridique qui doit régler la facture au fournisseur. L’analyse par code société permet de comparer la performance du processus entre les différentes entités juridiques de l’organisation. Elle aide à identifier les entités qui appliquent les processus standard et celles qui présentent une meilleure efficacité, des délais plus longs ou davantage de reprises. Pourquoi c’est important Permet de comparer la performance du processus entre différentes entités juridiques et d’identifier les problèmes et les bonnes pratiques propres à une région ou à une unité opérationnelle. Où les obtenir Se trouve dans les tables d’en-tête des documents, principalement BKPF-BUKRS pour les factures FI et RBKP-BUKRS pour les factures MM. Exemples 10001710US01DE01 | |||
| Date d’échéance de la facture InvoiceDueDate | Date à laquelle le paiement de la facture doit être effectué au fournisseur. | ||
| Description La date d’échéance de la facture correspond à la date limite de paiement du fournisseur pour éviter les pénalités de retard et préserver une bonne relation commerciale. Elle est calculée à partir 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é des paiements et ancienneté » et le KPI « Taux de paiement dans les délais ». La comparaison entre la date d’échéance et la date réelle de paiement permet de déterminer si les paiements sont effectués à temps, en avance ou en retard, avec des conséquences financières et commerciales directes. Pourquoi c’est important Il s’agit du principal indicateur de l’analyse des paiements dans les délais. Il permet de mesurer la performance des paiements et leur impact sur les relations fournisseurs et les pénalités de retard. Où les 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éduite de la date de référence du paiement (BSEG-ZFBDT) et des conditions de paiement (BSEG-ZTERM). Exemples 2023-10-312023-11-152024-01-10 | |||
| Montant de la facture InvoiceAmount | Montant brut total de la facture dans la devise d’origine du document. | ||
| Description Il s’agit de la valeur totale de la facture soumise par le fournisseur. Elle comprend le coût des biens ou services, les taxes et les autres frais, avant toute déduction ou remise. Le montant de la facture est un attribut financier essentiel pour de nombreuses analyses. Il permet de prioriser les factures de montant élevé, de comprendre l’impact financier des retards de traitement, par exemple les pénalités appliquées aux factures importantes, et de segmenter le processus, par exemple pour déterminer si les factures de montant élevé suivent un parcours d’approbation différent. Il est également indispensable pour identifier d’éventuels paiements en double. Pourquoi c’est important Fournit le contexte financier du processus et permet une analyse fondée sur la valeur, la priorisation des factures importantes et la quantification des impacts financiers. Où les obtenir Se trouve dans des tables telles que RBKP-RMWWR (montant brut de la facture) pour les factures MM, ou est calculé à partir des postes de BSEG, champ WRBTR, pour les factures FI. Exemples 1500.00250.7512345.50 | |||
| Nom d’utilisateur UserName | Identifiant de l’utilisateur ayant effectué l’activité. | ||
| Description Cet attribut enregistre l’identifiant de l’utilisateur SAP responsable de l’exécution d’une activité donnée, telle que la comptabilisation, l’approbation ou la compensation d’une facture. Il relie les étapes du processus aux utilisateurs concernés. L’analyse par nom d’utilisateur est essentielle pour comprendre la répartition de la charge de travail, identifier les utilisateurs les plus performants et repérer ceux qui pourraient avoir besoin d’une formation complémentaire. Elle est également importante pour analyser les goulots d’étranglement liés aux approbations dans les Dashboards, car elle permet d’identifier les approbateurs responsables des retards. Pourquoi c’est important Associe les activités à des personnes précises et permet d’analyser la performance des utilisateurs, leur charge de travail et le respect des politiques de séparation des tâches. Où les obtenir Se trouve généralement dans des tables d’en-tête telles que BKPF-USNAM (saisi par) ou dans les tables de documents de modification, CDHDR-USERNAME (modifié par). Exemples ABROWNJSMITHAP_AUTOMATION | |||
| Nom du fournisseur VendorName | Nom du fournisseur ayant soumis la facture. | ||
| Description Cet attribut contient le nom officiel du fournisseur. Il est associé au numéro de fournisseur enregistré sur le document de facture. L’analyse des fournisseurs est essentielle pour gérer les relations fournisseurs et identifier les problèmes propres à certains d’entre eux. Elle permet de répondre à des questions telles que « Quels fournisseurs soumettent le plus de factures présentant des écarts ? » ou « Réglons-nous systématiquement à temps les factures de certains fournisseurs stratégiques ? ». Avec le numéro et le montant de la facture, il s’agit également d’un champ important pour détecter d’éventuels paiements en double. Pourquoi c’est important Permet d’analyser la performance du processus par fournisseur, d’identifier les fournisseurs problématiques et de gérer efficacement les relations avec les fournisseurs stratégiques. Où les obtenir Extrait de la table des données de base des fournisseurs LFA1, champ NAME1, en établissant le lien avec le numéro de fournisseur (LIFNR) présent dans BKPF ou RBKP. Exemples Office Supplies Inc.Global Consulting GroupMachine Parts GmbH | |||
| Numéro du bon de commande PurchaseOrderNumber | Identifiant unique du bon de commande associé à la facture, le cas échéant. | ||
| Description Cet attribut relie une facture à un bon de commande préalablement approuvé. La présence d’un numéro de bon de commande constitue la base du rapprochement à trois niveaux, entre le bon de commande, la facture et la réception de marchandises. Il s’agit d’un attribut essentiel pour les analyses de conformité et d’efficacité. Il sert à calculer le KPI « Pourcentage de factures sans bon de commande », qui mesure le respect des politiques d’achat. Il est également fondamental pour le Dashboard « Performance du rapprochement à trois niveaux », qui permet d’analyser le rapprochement des factures associées à un bon de commande. Pourquoi c’est important Essentiel pour analyser l’efficacité du rapprochement à trois niveaux et mesurer le respect des politiques d’achat en identifiant les factures traitées sans bon de commande. Où les obtenir Se trouve 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 | Conditions convenues avec le fournisseur pour régler une facture, comprenant souvent des possibilités de remise. | ||
| Description Les conditions de paiement définissent les dates d’échéance et les éventuelles remises pour paiement anticipé. Par exemple, une condition telle que « Z001 » peut correspondre à « payable sous 30 jours, remise de 2 % en cas de paiement sous 10 jours ». Cet attribut constitue le fondement du Dashboard « Taux de capture des remises pour paiement anticipé ». L’analyse des conditions de paiement permet d’identifier toutes les factures éligibles à une remise. La comparaison avec les remises effectivement obtenues révèle les économies manquées et mesure l’efficacité du processus de paiement. Pourquoi c’est important Il est essentiel pour analyser les possibilités de remise pour paiement anticipé, mesurer la performance financière du processus de paiement et identifier les économies manquées. Où les obtenir Se trouve dans les postes fournisseurs, table BSEG-ZTERM, ou dans l’en-tête de la facture, RBKP-ZTERM. Exemples Z0010001NT30 | |||
| Date de lettrage ClearingDate | La date à laquelle le paiement a été effectué et la facture lettrée parmi les postes ouverts. | ||
| Description La date de lettrage correspond au règlement financier de la facture. Il s’agit de la date à laquelle l’activité « Paiement lettré » est exécutée, ce qui marque la dernière étape de la plupart des parcours de facture aboutis. Cette date sert à calculer la date effective de paiement et à la comparer à la date d’échéance de la facture. Elle est donc indispensable au calcul du KPI « Taux de paiement à temps » et à toute analyse de la performance des paiements. Elle marque également le point final du calcul du délai de traitement de la facture de bout en bout. Pourquoi c’est important Marque le règlement final d’une facture, sert de point final au calcul du délai de traitement et de base à l’analyse des paiements effectués à temps. Où les obtenir Présente dans les tables des postes lettrés, par exemple BSAK-AUGDT pour les fournisseurs. Exemples 2023-10-282023-11-142024-01-09 | |||
| Devise de la facture InvoiceCurrency | Le code devise du montant de la facture (par exemple, USD, EUR). | ||
| Description Cet attribut indique la devise dans laquelle le montant de la facture est exprimé. Il fournit le contexte nécessaire à l’interprétation des valeurs financières. Dans une organisation internationale, analyser les factures sans tenir compte de leur devise peut être trompeur. Ce champ permet de traiter correctement les données financières, soit en convertissant tous les montants dans une devise de reporting unique, soit en segmentant l’analyse par devise afin de comprendre les activités financières régionales. Pourquoi c’est important Fournit le contexte nécessaire au montant de la facture et permet une analyse et un reporting financiers précis, notamment dans les organisations internationales. Où les obtenir Présente dans les tables d’en-tête des documents, principalement BKPF-WAERS ou RBKP-WAERS. Exemples USDEURGBPJPY | |||
| Escompte obtenu DiscountTaken | Indicateur booléen précisant si un escompte pour paiement anticipé a été effectivement appliqué. | ||
| Description Cet attribut indique si un escompte de règlement a effectivement été obtenu lors du paiement de la facture. Il constitue un élément essentiel pour mesurer l’efficacité financière du processus de comptabilité fournisseurs. Cet indicateur est au cœur du KPI « Taux de récupération des escomptes pour paiement anticipé ». En filtrant les factures pour lesquelles un escompte était possible, selon les conditions de paiement, puis en analysant cet indicateur, l’entreprise peut calculer précisément les économies réalisées et les occasions manquées. Elle dispose ainsi d’une mesure claire et quantifiable de la performance de la comptabilité fournisseurs. Pourquoi c’est important Mesure directement la capacité à obtenir les escomptes disponibles pour paiement anticipé, avec un impact direct sur le résultat de l’entreprise. Où les obtenir Obtenu en vérifiant que le champ du montant de l’escompte (BSEG-SKNTO) est supérieur à zéro dans le document de paiement. Exemples truefalse | |||
| Est automatisée IsAutomated | Indicateur précisant si l’activité a été exécutée automatiquement par le système plutôt que par un utilisateur humain. | ||
| Description Cet attribut booléen distingue les activités lancées par un utilisateur de celles exécutées par des tâches système, des flux de travail ou des robots. Par exemple, une exécution automatisée de paiements ou l’enregistrement d’une facture généré par le système serait identifié comme automatisé. L’analyse de cet attribut aide à comprendre le niveau d’automatisation du processus des comptes fournisseurs. Elle permet de mesurer le succès des initiatives d’automatisation, de comparer l’efficacité des étapes automatisées et manuelles et d’identifier de nouvelles possibilités d’automatisation. Pourquoi c’est important Aide à mesurer le degré d’automatisation du processus, à analyser l’efficacité de l’automatisation et à identifier de nouvelles possibilités d’amélioration. Où les obtenir Dérivé du nom d’utilisateur, par exemple des identifiants système tels que 'SAP_SYSTEM' ou 'BATCHUSER', ou de codes de transaction spécifiques associés aux tâches automatisées. Exemples truefalse | |||
| Motif de blocage BlockingReason | Motif pour lequel une facture est bloquée pour paiement, indiquant la présence d’un écart. | ||
| Description Lorsqu’une facture échoue à un contrôle de validation pendant le rapprochement à trois niveaux ou une autre étape de vérification, elle est bloquée pour paiement. Le motif de blocage précise la nature du problème, par exemple un écart de quantité, une variation de prix ou une réception de marchandises manquante. Cet attribut est essentiel pour le Dashboard « Analyse des reprises liées aux écarts de facturation ». L’analyse de la fréquence des différents motifs de blocage permet d’identifier les causes profondes des inefficacités du processus. Par exemple, si la variation de prix est un motif fréquent, elle peut révéler des problèmes dans les données de base du système d’achat. Pourquoi c’est important Fournit une visibilité directe sur les causes profondes des écarts de facturation et des reprises, afin de cibler les actions d’amélioration du processus. Où les obtenir Stocké dans des tables de postes de facture telles que RSEG, dans des champs commençant par SPGR* (par exemple, SPGRP, SPGRQ, SPGRT). Peut également se trouver dans RBKP_BLOCKED. Exemples Écart de prixÉcart de quantitéRéception des marchandises manquante | |||
| Numéro de facture fournisseur VendorInvoiceNumber | Le numéro de facture indiqué par le fournisseur sur son document. | ||
| Description Il s’agit du numéro de référence issu du propre système comptable du fournisseur, tel qu’il figure sur la facture papier ou électronique. Il est saisi manuellement ou capturé par OCR lors de la réception de la facture. Ce champ est particulièrement important pour les opérations et l’analyse, notamment pour le Dashboard « Paiements potentiellement en double ». Une méthode courante de détection des doublons consiste à rechercher plusieurs documents de facture internes partageant le même nom de fournisseur, le même numéro de facture fournisseur et le même montant de facture. Il s’agit de la principale référence externe d’une facture. Pourquoi c’est important Il s’agit d’un champ essentiel pour détecter les paiements potentiellement en double et de la principale référence externe utilisée pour communiquer avec les fournisseurs. Où les obtenir Stocké dans le champ « Reference » de l’en-tête du document, généralement BKPF-XBLNR. Exemples INV-2023-9876733401120231015-001 | |||
| Paiement en retard IsLatePayment | Indicateur booléen précisant si la facture a été payée après sa date d’échéance. | ||
| Description Cet attribut calculé est un indicateur simple, vrai ou faux, qui précise si le paiement d’une facture a été effectué après sa date d’échéance officielle. Il est obtenu en comparant la date de lettrage à la date d’échéance de la facture. Cet indicateur simplifie l’analyse du Dashboard « Conformité et ancienneté des paiements » et du KPI « Taux de paiement à temps ». Il permet de filtrer et d’agréger facilement les données pour compter les paiements en retard, calculer le pourcentage de paiements effectués à temps et identifier les fournisseurs ou codes société présentant un taux élevé de paiements en retard. Pourquoi c’est important Mesure directement le respect des conditions de paiement, simplifie le calcul du KPI de paiement à temps et aide à identifier les domaines où la performance des paiements est insuffisante. Où les obtenir Attribut calculé. La logique est la suivante : IF ClearingDate > InvoiceDueDate THEN true ELSE false. Exemples truefalse | |||
| Type de document de facture InvoiceDocumentType | Classification du document de facture, qui détermine son traitement dans SAP. | ||
| Description Le type de document est un élément de configuration essentiel 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 notamment la plage de numéros et les champs obligatoires. Dans l’analyse des processus, le filtrage par type de document permet de comparer les flux de traitement de différents types de factures. Par exemple, le processus d’approbation d’un avoir peut différer de celui d’une facture standard. Cette analyse est utile pour le Dashboard « Variantes d’acheminement des approbations de factures ». Pourquoi c’est important Permet de segmenter le processus selon le traitement des différents types de factures et de révéler les variations de parcours et de délais. Où les obtenir Directement depuis la table d’en-tête du document, champ BKPF-BLART. Exemples KRREKG | |||
Activités du traitement des factures fournisseurs
| Activité | Description | ||
|---|---|---|---|
| Facture annulée | Le document de facture a été contrepassé, annulant ainsi son impact financier. Il s’agit d’un état final alternatif du processus, souvent dû à des erreurs de saisie ou à un litige avec le fournisseur. | ||
| Pourquoi c’est important Le suivi des annulations permet d’identifier les causes des échecs du processus, telles que les soumissions en double ou les données de facture incorrectes, et peut révéler des problèmes en amont. Où les obtenir Cet événement est explicitement enregistré lors de la création d’un document de contrepassation. L’en-tête du document d’origine (BKPF) contient alors le numéro du document de contrepassation (STBLG) et le motif de contrepassation. Collecte Identifiez la date de comptabilisation du document de contrepassation, lié dans l’en-tête du document d’origine (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 flux de travail. Il s’agit souvent de la dernière étape avant l’enregistrement de la facture ou la suppression de son blocage de paiement. | ||
| Pourquoi c’est important Cette étape importante marque la fin du cycle d’approbation. Le délai entre l’envoi pour approbation et l’approbation constitue un indicateur essentiel de l’efficacité du processus. Où les obtenir Capturé dans les journaux SAP Business Workflow comme une étape d’achèvement ou de libération finale. Il peut également être déduit de la suppression d’un blocage de paiement après l’envoi pour approbation. Collecte Extraire les événements d’achèvement du flux de travail à partir des journaux du flux de travail SAP ou identifier l’événement final de « libération ». Type d’événement explicit | |||
| Facture bloquée pour paiement | Le système a bloqué la facture automatiquement ou manuellement, empêchant son paiement. Ce blocage est généralement dû à un écart de prix ou de quantité, ou à des approbations manquantes. | ||
| Pourquoi c’est important Il s’agit d’un indicateur important de problèmes et de reprises. L’analyse des motifs et de la durée des blocages permet d’identifier les causes profondes des retards de paiement et des inefficacités du processus. Où les obtenir Il s’agit d’un statut explicite enregistré dans le champ Payment Block Key (ZLSPR) du poste fournisseur du document comptable, dans la table BSEG. Collecte Enregistré via les documents de modification lorsque le champ BSEG-ZLSPR contient un motif de blocage. Type d’événement explicit | |||
| Facture comptabilisée | La facture est officiellement enregistrée dans le grand livre, ce qui crée une dette financière. Un document mis en attente devient un document comptabilisé, ou une comptabilisation directe est effectuée. | ||
| Pourquoi c’est important Il s’agit d’une étape financière importante. Elle confirme l’obligation de paiement de l’entreprise et constitue souvent une condition préalable à la planification du paiement. Où les obtenir Cet événement est identifié par la date de comptabilisation (BUDAT) dans l’en-tête du document (BKPF). Le statut d’un document comptabilisé (BKPF-BSTAT) est vide. Collecte Utilisez l’horodatage de comptabilisation (BKPF-BUDAT) pour les documents qui ne sont pas mis en attente (BKPF-BSTAT est vide). Type d’événement explicit | |||
| Facture reçue | Cette activité correspond à la création d’un document de facture dans SAP, manuellement ou via une interface automatisée telle que l’OCR ou VIM. Cet événement est généralement enregistré à 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 essentielle pour calculer le délai de traitement de la facture de bout en bout et mesurer le débit global du processus fournisseurs. Où les obtenir Cet événement est extrait de la table d’en-tête des documents comptables (BKPF), à partir de la date de création du document (CPUDT) et de l’heure de création (CPUTM). Collecte Utilisez l’horodatage de création (BKPF-CPUDT, BKPF-CPUTM) du document de facture. Type d’événement explicit | |||
| Paiement compensé | Cette activité marque la clôture définitive de la facture : le paiement et la facture sont rapprochés dans le livre auxiliaire. Elle indique que le processus est terminé. | ||
| Pourquoi c’est important En tant que dernière étape du processus, cette activité est essentielle pour calculer précisément le délai de traitement de bout en bout. Elle confirme que la dette est réglée. Où les obtenir Il s’agit d’un événement explicite, marqué par le renseignement du champ de date de compensation (AUGDT) sur le poste fournisseur du document de facture, dans la table BSEG. Collecte Utilisez la date de compensation (BSEG-AUGDT) du poste de facture. Type d’événement explicit | |||
| Paiement exécuté | Un paiement a été effectué pour la facture. Cet événement est enregistré lorsque la campagne de paiement est terminée et qu’un document de paiement est créé et comptabilisé. | ||
| Pourquoi c’est important Cette activité est essentielle pour l’analyse des flux de trésorerie et le calcul du KPI « Taux de paiement dans les délais », en comparant cette date à la date d’échéance de la facture. Où les obtenir Cet événement est extrait de la date de comptabilisation du document de paiement qui solde la facture. Le numéro du document de paiement est lié dans le champ du document de compensation (AUGBL) du poste de facture (BSEG). Collecte Identifiez la date de comptabilisation (BUDAT) du document de paiement qui solde le poste de facture. Type d’événement explicit | |||
| Bon de commande rapproché | Cette activité indique que la facture a été rapprochée avec succès avec le bon de commande correspondant. Il s’agit d’une étape essentielle du rapprochement à trois niveaux pour les factures liées aux achats. | ||
| Pourquoi c’est important L’analyse de cette activité permet de mesurer l’efficacité du rapprochement. Elle est fondamentale pour les KPI « Performance du rapprochement à trois niveaux » et « Pourcentage de factures sans bon de commande ». Où les obtenir Cet événement est déduit lorsqu’une ligne de facture dans la table BSEG ou ACDOCA contient un numéro de bon de commande (EBELN) et un poste (EBELP) valides. Collecte Déduit de la présence d’une référence de bon de commande (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 | Événement calculé indiquant que la date d’échéance nette de la facture est dépassée sans qu’un paiement ait été compensé. Il signale une situation de paiement tardif ou en retard. | ||
| Pourquoi c’est important Essentielle pour le Dashboard « Conformité des paiements et ancienneté », cette activité permet d’identifier et de gérer en amont les factures en retard, ainsi que d’analyser les causes profondes des retards de paiement. Où les obtenir Il ne s’agit pas d’un événement explicite dans SAP. Il est calculé en comparant la date actuelle du système à la date d’échéance nette, calculée à partir de BSEG-ZFBDT, ou de la date de référence, et des conditions de paiement. Collecte Événement calculé déclenché lorsque l’horodatage de l’événement est posté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é, probablement à l’origine d’un blocage de paiement, a été examiné et résolu. Elle est enregistrée lorsqu’un blocage de paiement est supprimé d’une facture. | ||
| Pourquoi c’est important Le suivi de cette boucle de reprise est essentiel pour le Dashboard « Analyse des reprises liées aux écarts de facturation ». Il permet de quantifier le temps et les efforts consacrés à la correction des erreurs. Où les obtenir Cet événement est déduit des documents de modification indiquant la suppression d’un blocage de paiement. Le journal des modifications du champ BSEG-ZLSPR constitue la source principale. Collecte Identifiez les documents de modification de la table BSEG pour lesquels le champ ZLSPR passe d’une valeur à une valeur vide. Type d’événement inferred | |||
| Facture envoyée pour approbation | La facture a été soumise à un flux de travail pour les approbations requises, conformément aux règles métier. Cette étape marque le début du sous-processus d’approbation. | ||
| Pourquoi c’est important Cette activité constitue le point de départ du calcul du KPI « Délai moyen d’approbation des factures » et de l’analyse des goulots d’étranglement liés aux approbations. Où les obtenir Peut être extraite des journaux SAP Business Workflow, notamment des tables SWW*, qui enregistrent le démarrage d’une instance de Workflow liée à l’objet facture, par exemple BUS2081. Collecte Extraire les événements de démarrage du flux de travail à partir des journaux du flux de travail SAP, par exemple la table SWW_WIHEAD, associés au document de facture. Type d’événement explicit | |||
| Facture mise en attente | Représente une facture saisie dans le système, mais pas encore comptabilisée dans le grand livre. Il s’agit souvent d’une étape volontaire permettant d’enregistrer un document incomplet en vue de son traitement ou de son approbation ultérieure. | ||
| Pourquoi c’est important Le suivi des factures mises en attente permet d’identifier les retards avant le début de la comptabilisation officielle et de mettre en évidence les problèmes liés à l’exhaustivité des données ou à la validation initiale. Où les obtenir Ce statut est déduit du champ de statut du document dans l’en-tête comptable (BKPF-BSTAT = 'V' pour une facture mise en attente). L’événement se produit lorsque le statut est défini. Collecte Identifiez les documents de modification de la table BKPF pour lesquels le champ BSTAT est défini sur 'V' (Vor-erfasst/Préenregistré). Type d’événement inferred | |||
| Facture rejetée | Un approbateur a rejeté la facture pendant le flux de travail d’approbation. Cette action renvoie généralement la facture au collaborateur chargé du traitement pour correction ou clarification. | ||
| Pourquoi c’est important Le suivi des rejets met en évidence les boucles de reprise du processus d’approbation et peut révéler des problèmes de conformité aux politiques ou de codification des factures. Où les obtenir Cet événement est enregistré comme un résultat spécifique dans les journaux SAP Business Workflow associés à la facture. Collecte Extraire les événements de statut « rejeté » du flux de travail à partir des journaux du flux de travail SAP. 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 campagne de paiement, par exemple F110. Elle est désormais prévue pour paiement, sous réserve de l’exécution finale de la campagne. | ||
| Pourquoi c’est important Cette activité montre le passage d’une dette ouverte à un poste activement préparé pour paiement. Elle contribue à analyser l’efficacité des opérations de paiement. Où les obtenir Cet événement est explicitement enregistré dans les tables de données des campagnes de paiement, notamment REGUP (postes traités par le programme de paiement) et REGUH (en-tête). Collecte Identifiez le moment où une facture apparaît dans la table REGUP pour une campagne de paiement identifiée dans REGUH. Type d’événement explicit | |||
| Réception de marchandises rapprochée | Cette activité indique que les quantités et les montants de la facture ont été rapprochés avec succès avec le document de réception de marchandises correspondant. Il s’agit de la validation finale dans un scénario de rapprochement à trois niveaux. | ||
| Pourquoi c’est important Son suivi permet de localiser les inefficacités du rapprochement à trois niveaux et d’identifier les écarts entre les marchandises reçues et celles facturées par le fournisseur. Où les obtenir Cet événement est déduit de la présence d’une référence à un document article, correspondant à une réception de marchandises, sur la ligne de facture, souvent liée à l’historique du poste de bon de commande. Collecte Déduit de la présence d’une référence à un document de réception de marchandises sur la ligne 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 ayant un accès en lecture au schéma de la base de données SAP S/4HANA, généralement SAPABAP1 ou un schéma similaire, où se trouvent 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 un outil de requête de base de données similaire.
- Identifier les vues CDS principales : les principales vues CDS nécessaires à 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 le périmètre 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 le périmètre de l’extraction. Vous devez notamment renseigner l’identifiant correct du système source, la période des factures (CreationDateTime) et les codes société concernés.
- Préparer la requête principale : copiez la requête SQL complète fournie dans la section consacrée aux requêtes dans votre client SQL. Elle utilise des Common Table Expressions (CTE) pour sélectionner d’abord une population de référence de factures, puis construire un Event Log en réunissant 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, repérez les variables de substitution. Remplacez « [YYYY-MM-DD] » par les dates de début et de fin de votre période d’analyse. Remplacez « [Your Company Code 1] » et « [Your Company Code 2] » par la liste des codes 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 période sélectionnée, l’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 renseignées comme prévu et confirmez que différentes valeurs ActivityName sont présentes.
- Exporter l’Event Log : exportez l’ensemble des résultats depuis votre client SQL vers un fichier CSV. Vérifiez que le fichier est encodé en UTF-8 afin d’éviter les problèmes de caractères. Donnez-lui un nom explicite, par exemple sap_s4hana_ap_event_log.csv.
- Préparer le chargement : avant de charger le fichier dans un outil de Process Mining, vérifiez que les en-têtes de colonnes du fichier CSV correspondent exactement aux noms d’attributs requis : Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc.
- Charger les données dans l’outil de Process Mining : chargez le fichier CSV généré dans votre plateforme de Process Mining et associez les colonnes aux champs correspondants pour l’ID de dossier, l’activité et l’horodatage.
Configuration
- Vues CDS clés : l’extraction repose sur une combinaison de vues CDS standard de S/4HANA. Les principales vues sont :
- I_JournalEntry et I_JournalEntryItem : pour les en-têtes et postes des documents financiers, les détails de comptabilisation et les informations d’apurement.
- I_SupplierInvoiceAPI01 : pour les détails propres aux factures MM (logistique), notamment les références aux bons de commande et les blocages de paiement.
- I_ChangeDocument : pour suivre l’horodatage exact des changements, comme l’application ou la suppression d’un blocage de paiement.
- I_WorkflowStatusDetails : pour extraire les événements liés au flux de travail d’approbation des factures.
- I_PaymentProposalItem : pour identifier le moment où une facture est incluse dans une proposition d’exécution de paiements.
- I_Supplier : pour enrichir les données avec les informations de base du fournisseur, comme VendorName.
- Filtrage par période : il est essentiel d’appliquer un filtre de dates pour limiter le volume de données. La requête fournie filtre CreationDateTime dans la CTE Invoices_Base. Pour une première analyse, une période de trois à six mois est recommandée afin de conserver des performances maîtrisables.
- Filtres obligatoires : filtrez toujours par CompanyCode. L’analyse simultanée de tous les codes société peut être extrêmement lente et ne pas être pertinente pour l’activité. Filtrez également JournalEntryType afin de sélectionner uniquement les documents liés aux fournisseurs, par exemple « KR » et « RE ».
- Prérequis : l’utilisateur de base de données qui exécute la requête doit disposer de l’autorisation SELECT sur toutes les vues CDS utilisées ainsi que sur le schéma HANA sous-jacent. Un accès au niveau applicatif dans l’interface SAP GUI ne suffit pas.
- Considérations de performance : les requêtes directes sur I_ChangeDocument peuvent consommer beaucoup de ressources. La requête fournie tente de limiter cet impact en filtrant d’abord les factures. Pour les volumes très importants, envisagez d’exécuter l’extraction en dehors des heures de pointe ou par lots couvrant des périodes plus courtes.
a Exemple de requête 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
- Confirmez qu’un accès direct en lecture au schéma SAP HANA contenant les tables SAP S/4HANA concernées est disponible. Obtenez la chaîne de connexion, les identifiants, le nom du schéma et les autorisations nécessaires pour lire BKPF, ACDOCA ainsi que les tables supplémentaires configurées pour les documents enregistrés, le flux de travail, les achats, la réception des marchandises, les propositions de paiement, l’apurement et les données d’annulation.
- Confirmez le modèle de données technique du système cible avant l’exécution. Validez les noms physiques, les champs clés, les champs d’horodatage, les relations d’annulation, les relations de paiement et la persistance du flux de travail utilisée par le système. Remplacez chaque paramètre entre crochets dans la requête par l’objet ou le champ correspondant du système. Ne supposez pas que les données du flux de travail ou des documents enregistrés sont stockées dans une table universelle unique.
- Configurez les paramètres d’extraction. Définissez [Date de début], [Date de fin], [Filtre de code société], [Filtre de type de document] et [Nom du schéma]. Utilisez d’abord une période de trois à six mois, puis élargissez-la après validation des performances et de l’exhaustivité.
- Exécutez la requête SQL dans un client SQL SAP HANA approuvé, tel que SAP HANA Database Explorer, ou dans un autre outil d’exécution SQL autorisé. La requête produit une ligne pour chaque activité explicitement extraite et ne demande pas à ProcessMind de déduire les événements.
- Validez le jeu de résultats. Vérifiez que Invoice est l’identifiant du cas, que ActivityName contient les 15 noms d’activité requis, que EventTime est renseigné et cohérent sur le plan chronologique, que SourceSystem identifie SAP S/4HANA et que LastDataUpdate contient l’horodatage d’actualisation de l’extraction. Examinez les événements en double, les relations d’annulation et les jointures de documents avant de charger les données.
- Appliquez les associations propres au système qui sont nécessaires. Par exemple, associez la source configurée des documents enregistrés à Invoice Parked, la source configurée du flux de travail à Invoice Routed For Approval, Invoice Approved et Invoice Rejected, et la source configurée des paiements à Payment Proposal Created et Payment Executed. Conservez les identifiants sources dans des colonnes supplémentaires si la traçabilité est requise.
- Exportez le résultat dans un fichier délimité ou un jeu de résultats de base de données, avec un événement par ligne. Utilisez l’encodage UTF-8, conservez les horodatages dans un fuseau horaire cohérent, gardez les noms de colonnes exacts Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber et InvoiceDueDate, et n’agrégez pas les activités par facture.
- Importez le journal d’événements dans ProcessMind et configurez Invoice comme identifiant du cas, ActivityName comme colonne d’activité et EventTime comme colonne d’heure de l’événement. Vérifiez que les attributs facultatifs sont associés aux champs correspondants. Comme ProcessMind lit le journal d’événements tel quel, assurez-vous que chaque activité à visualiser est déjà présente sur une ligne avant l’importation.
Configuration
- Période : commencez par trois à six mois. Utilisez la date de comptabilisation, la date de création du document ou la date de l’événement source pertinente selon l’activité extraite. N’élargissez la période qu’après avoir validé le temps d’exécution de la requête et la durée de conservation de la source.
- Filtrage par société : configurez [Filtre de code société] pour limiter l’extraction aux codes société requis. Si aucune restriction n’est nécessaire, utilisez une sélection contrôlée de toutes les sociétés plutôt qu’une requête de production sans restriction.
- Filtrage des documents : configurez [Filtre de type de document] uniquement après avoir confirmé les types de documents utilisés pour les factures fournisseurs, les avoirs, les documents enregistrés, les documents de paiement et les annulations dans le système cible.
- Association du schéma et des objets : remplacez [Nom du schéma] ainsi que chaque objet ou champ source entre crochets par des valeurs vérifiées dans le système SAP S/4HANA cible. Une requête HANA directe doit être adaptée aux applications activées, aux extensions, à la conception du flux de travail et au modèle de données du système.
- Gestion des horodatages : normalisez tous les horodatages sources dans un même fuseau horaire. Lorsqu’une date seule est disponible, utilisez une heure par défaut documentée et consignez cette limite dans le dictionnaire de données.
- Sémantique des événements : extrayez chaque activité sur une ligne distincte. Ne regroupez pas plusieurs activités dans un seul enregistrement de facture et n’attendez pas de ProcessMind qu’il déduise les événements de rapprochement, d’approbation, d’échéance ou d’apurement.
- Événement d’échéance : générez Invoice Due Date Passed uniquement pour les factures dont la date d’échéance est antérieure à l’horodatage d’évaluation configuré et pour lesquelles aucun événement d’apurement n’existe à cet horodatage. La requête utilise [Horodatage d’évaluation] pour ce calcul.
- Performances : limitez la période et le périmètre des sociétés au départ, filtrez les champs indexés ou pertinents pour le partitionnement, évitez les projections inutilement larges et exécutez la requête pendant une plage de reporting approuvée. Envisagez de préparer des sous-ensembles de données sources si la requête de production dépasse la durée d’exécution convenue.
- Stratégie d’actualisation : définissez LastDataUpdate sur l’horodatage d’exécution de l’extraction. Pour les chargements incrémentiels, conservez un point de reprise fondé sur l’horodatage de modification source pertinent et incluez une période de reprise afin de prendre en compte les mises à jour tardives et les annulations.
- Prérequis : autorisations de base de données nécessaires, accès à la production approuvé, connaissance de la configuration du Universal Journal du système, accès aux sources configurées pour les documents enregistrés, les achats, la réception des marchandises, le flux de travail, les paiements, l’apurement et les annulations, ainsi que les approbations SAP en matière de licences ou de gouvernance applicables.
a Exemple de requête sql
WITH
params AS (
SELECT
TO_DATE('[Start date]') AS start_date,
TO_DATE('[End date]') AS end_date,
TO_TIMESTAMP('[Evaluation timestamp]') AS evaluation_ts,
TO_TIMESTAMP('[Extraction timestamp]') AS extraction_ts
FROM DUMMY
),
base_invoice AS (
SELECT
b.mandt,
b.bukrs,
b.belnr,
b.gjahr,
b.bldat,
b.budat,
b.cpudt,
b.cputm,
b.usnam,
b.blart,
b.xblnr,
b.stblg,
b.stjah,
a.lifnr,
a.wrbtr,
a.waers,
a.zfbdt,
a.zbd1t,
a.zbd2t,
a.zbd3t,
a.ebeln,
a.ebelp,
a.augbl,
a.augdt,
a.buzei,
v.name1 AS vendor_name,
CASE
WHEN a.zfbdt IS NOT NULL THEN ADD_DAYS(a.zfbdt, COALESCE(a.zbd1t, 0))
ELSE NULL
END AS invoice_due_date
FROM [Schema name].BKPF b
INNER JOIN [Schema name].ACDOCA a
ON a.mandt = b.mandt
AND a.rbukrs = b.bukrs
AND a.belnr = b.belnr
AND a.gjahr = b.gjahr
LEFT JOIN [Schema name].[Vendor master table] v
ON v.[Vendor key field] = a.lifnr
CROSS JOIN params p
WHERE b.bukrs IN ([Company code filter])
AND b.blart IN ([Document type filter])
AND b.cpudt BETWEEN p.start_date AND p.end_date
),
invoice_received AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Received' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(cputm), '00:00:00')) AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
),
invoice_parked AS (
SELECT
CAST([Parked invoice key field] AS NVARCHAR(40)) AS invoice,
'Invoice Parked' AS activity_name,
[Parked event timestamp field] AS event_time,
CAST([Parked user field] AS NVARCHAR(80)) AS user_name,
[Parked company code field] AS company_code,
[Parked vendor name field] AS vendor_name,
[Parked amount field] AS invoice_amount,
[Parked currency field] AS document_currency,
CAST([Parked purchase order field] AS NVARCHAR(40)) AS purchase_order_number,
[Parked due date field] AS invoice_due_date
FROM [Schema name].[Parked document source]
WHERE [Parked event date field] BETWEEN (SELECT start_date FROM params) AND (SELECT end_date FROM params)
AND [Parked company code field] IN ([Company code filter])
),
purchase_order_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Purchase Order Matched' AS activity_name,
COALESCE([Purchase order match timestamp field], TO_TIMESTAMP(TO_VARCHAR(i.cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(i.cputm), '00:00:00'))) AS event_time,
CAST(COALESCE([Purchase order match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrBtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Purchase order match source] m
ON m.[Invoice document key field] = i.belnr
AND m.[Invoice company code field] = i.bukrs
AND m.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
goods_receipt_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Goods Receipt Matched' AS activity_name,
[Goods receipt match timestamp field] AS event_time,
CAST(COALESCE([Goods receipt match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Goods receipt match source] g
ON g.[Invoice document key field] = i.belnr
AND g.[Invoice company code field] = i.bukrs
AND g.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
invoice_blocked AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Blocked For Payment' AS activity_name,
[Payment block timestamp field] AS event_time,
CAST(COALESCE([Payment block user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block source] b
ON b.[Invoice document key field] = i.belnr
AND b.[Invoice company code field] = i.bukrs
AND b.[Invoice fiscal year field] = i.gjahr
WHERE [Payment block value field] IS NOT NULL
),
discrepancy_resolved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Discrepancy Resolved' AS activity_name,
[Payment block removal timestamp field] AS event_time,
CAST(COALESCE([Payment block removal user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block history source] h
ON h.[Invoice document key field] = i.belnr
AND h.[Invoice company code field] = i.bukrs
AND h.[Invoice fiscal year field] = i.gjahr
WHERE [Previous payment block value field] IS NOT NULL
AND [New payment block value field] IS NULL
),
invoice_routed_for_approval AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Routed For Approval' AS activity_name,
[Workflow routed timestamp field] AS event_time,
CAST([Workflow initiator field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow routed event value]'
),
invoice_approved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Approved' AS activity_name,
[Workflow approval timestamp field] AS event_time,
CAST([Workflow approver field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow approved event value]'
),
invoice_rejected AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Rejected' AS activity_name,
[Workflow rejection timestamp field] AS event_time,
CAST([Workflow rejector field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow rejected event value]'
),
invoice_posted AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Posted' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(budat, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NULL
),
payment_proposal_created AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Proposal Created' AS activity_name,
[Payment proposal timestamp field] AS event_time,
CAST([Payment proposal user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment proposal source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
payment_executed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Executed' AS activity_name,
[Payment execution timestamp field] AS event_time,
CAST([Payment execution user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment execution source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
invoice_due_date_passed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Due Date Passed' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.invoice_due_date IS NOT NULL
AND TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') < (SELECT evaluation_ts FROM params)
AND i.augbl IS NULL
),
payment_cleared AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Cleared' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.augdt, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.augbl IS NOT NULL
AND i.augdt IS NOT NULL
),
invoice_cancelled AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Cancelled' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR([Reversal posting date field], 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(COALESCE([Reversal user field], usnam) AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NOT NULL
),
all_events AS (
SELECT * FROM invoice_received
UNION ALL SELECT * FROM invoice_parked
UNION ALL SELECT * FROM purchase_order_matched
UNION ALL SELECT * FROM goods_receipt_matched
UNION ALL SELECT * FROM invoice_blocked
UNION ALL SELECT * FROM discrepancy_resolved
UNION ALL SELECT * FROM invoice_routed_for_approval
UNION ALL SELECT * FROM invoice_approved
UNION ALL SELECT * FROM invoice_rejected
UNION ALL SELECT * FROM invoice_posted
UNION ALL SELECT * FROM payment_proposal_created
UNION ALL SELECT * FROM payment_executed
UNION ALL SELECT * FROM invoice_due_date_passed
UNION ALL SELECT * FROM payment_cleared
UNION ALL SELECT * FROM invoice_cancelled
)
SELECT
invoice AS "Invoice",
activity_name AS "ActivityName",
event_time AS "EventTime",
'SAP S/4HANA' AS "SourceSystem",
(SELECT extraction_ts FROM params) AS "LastDataUpdate",
user_name AS "UserName",
company_code AS "CompanyCode",
vendor_name AS "VendorName",
invoice_amount AS "InvoiceAmount",
purchase_order_number AS "PurchaseOrderNumber",
invoice_due_date AS "InvoiceDueDate"
FROM all_events
WHERE invoice IS NOT NULL
AND event_time IS NOT NULL
ORDER BY "Invoice", "EventTime", "ActivityName"; Étapes
- Spécification et conception : Avant de coder, collaborez avec les analystes métier afin de confirmer les conditions exactes de déclenchement et les champs de données pour chacune des 15 activités requises. Identifiez les tables SAP concernées, les types de documents, par exemple « KR » et « RE », ainsi que les codes société à inclure dans le périmètre.
- Créer le programme ABAP : Lancez l’éditeur ABAP à l’aide de la transaction SE38. Créez un nouveau programme exécutable, par exemple Z_PM_AP_INVOICE_EXTRACT. Attribuez-lui un titre explicite et définissez l’application sur « Financial Accounting ».
- Définir l’écran de sélection : Dans le programme, définissez un écran de sélection, à l’aide des mots-clés PARAMETERS et SELECT-OPTIONS, afin de permettre aux utilisateurs de préciser la période d’extraction, fondée sur la date de création de la facture, les codes société cibles (BUKRS) et les types de documents de facture concernés (BLART). Ajoutez é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 correspondant au format final du journal d’événements, par exemple TY_EVENT_LOG, avec tous les attributs requis et recommandés. Déclarez des tables internes destinées à contenir les données sélectionnées dans différentes 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 de factures dans RBKP (factures logistiques) et BKPF (factures financières), selon les critères de l’écran de sélection. Stockez les clés de ces factures principales dans une table interne afin de piloter les recherches de données suivantes.
- Extraire les activités successivement : Pour chaque facture de l’ensemble principal, effectuez une série de sélections afin de trouver les horodatages et les détails de chaque activité métier. Par exemple, interrogez CDHDR et CDPOS pour les changements de blocage de paiement, REGUH et REGUP pour les données du cycle de paiement, et BKPF pour les détails des documents 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 stockées directement dans un champ de table. Pour l’événement « Invoice Due Date Passed », utilisez la date d’échéance de la facture (BSEG-ZFBDT + conditions de paiement) et la date de lettrage (BSEG-AUGDT). Si la date de lettrage est postérieure à la date d’échéance, créez un nouvel enregistrement d’événement dont l’horodatage correspond à la date d’échéance.
- Transformation et enrichissement des données : À mesure que vous recueillez les données de chaque activité, renseignez tous les attributs requis. Recherchez notamment les noms des fournisseurs dans LFA1, convertissez les dates et heures en une chaîne d’horodatage unique (CONCATENATE...INTO...) et définissez la valeur SourceSystem.
- Générer le fichier de sortie : Une fois toutes les factures et les 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 situé sur le serveur d’applications, à l’emplacement indiqué sur l’écran de sélection.
- Télécharger et préparer l’importation : Utilisez la transaction CG3Y pour télécharger le fichier généré depuis le serveur d’applications vers votre machine locale. Vérifiez que le fichier est enregistré au format CSV encodé en UTF-8. Contrôlez que les en-têtes de colonnes correspondent aux attributs requis, notamment Invoice, ActivityName, EventTime, avant d’importer le fichier dans l’outil de Process Mining.
Configuration
- Période : définissez l’option de sélection P_CPUDT pour la date de création de la facture (BKPF-CPUDT ou RBKP-CPUDT). Pour une première analyse, une période de six à douze mois est recommandée.
- Code société (P_BUKRS) : paramètre SELECT-OPTIONS obligatoire pour filtrer des codes société précis. Le traitement simultané de tous les codes société n’est pas recommandé, sauf nécessité absolue.
- Type de document de facture (P_BLART) : paramètre SELECT-OPTIONS permettant de filtrer les types de documents de facture pertinents. Les types courants comprennent « KR » (facture fournisseur), « KG » (avoir fournisseur) et « RE » (vérification des factures logistiques).
- Mode d’exécution : pour les volumes importants, le programme doit être exécuté comme tâche en arrière-plan (SM36/SM37) afin d’éviter les délais d’expiration du traitement en dialogue. Planifiez son exécution en dehors des heures de pointe.
- Chemin du fichier de sortie : PARAMETER permettant de définir le chemin et le nom du fichier sur le serveur d’application SAP, par exemple dans le répertoire /tmp/. Le fichier y est écrit avant son téléchargement.
- Prérequis : l’utilisateur qui exécute le rapport doit être autorisé à lire les tables FI, CO et MM (BKPF, BSEG, RBKP, RSEG, LFA1), les tables des documents de modification (CDHDR, CDPOS) et les tables du flux de travail. L’objet d’autorisation S_DATASET est également requis pour écrire des fichiers sur le serveur d’application.
a Exemple de requête 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. Prêt à commencer ?
Utilisez ce modèle pour lancer votre initiative de Process Mining et réaliser des gains d’efficacité importants dans vos opérations de comptes fournisseurs. Commencez dès aujourd’hui votre démarche vers un processus plus optimisé et mieux maîtrisé.
Évitez les pénalités de retard : optimisez dès aujourd’hui le traitement de vos factures fournisseurs
Réduisez de 60 % les coûts de traitement et éliminez facilement les paiements en double.
Aucune carte bancaire requise, commencez en quelques minutes.