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
- Guide étape par étape pour extraire les données
Attributs du traitement des factures fournisseurs
| Nom | Description | ||
|---|---|---|---|
| Activité ActivityName | Nom d’un événement ou d’une étape métier précis survenu au cours du traitement de la facture. | ||
| Description L’activité désigne une étape ou une action distincte du processus de traitement des factures fournisseurs, comme « Facture reçue », « Facture comptabilisée » ou « Paiement exécuté ». Ces activités constituent les éléments de base de la carte du processus. L’analyse des activités est au cœur du Process Mining. Elle permet de visualiser le flux du processus, de repérer les parcours courants, 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 des activités d’une facture donnée retrace son parcours dans le processus. Pourquoi est-ce important ? Cet attribut définit les étapes du processus. Il permet de visualiser et d’analyser son déroulement, de repérer les goulots d’étranglement et de détecter les boucles de reprise. Où trouver ces données Dérivé de différentes sources, notamment des modifications de statut de document (par exemple, BKPF-BSTAT), des documents de modification (tables CDHDR/CDPOS) ou des journaux de flux de travail. Une logique d’extraction personnalisée est généralement nécessaire. Exemples Facture reçueFacture approuvéePaiement exécutéFacture bloquée pour paiement | |||
| Facture Invoice | Identifiant unique d’un document de facture, qui sert d’ID de cas principal pour le processus de traitement des factures 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 donne une vue complète de son cycle de vie, de bout en bout. Elle est indispensable pour calculer des indicateurs clés comme le temps de cycle total, repérer les goulots d’étranglement pour chaque facture et comprendre les différents parcours possibles dans le processus. Pourquoi est-ce important ? Cet identifiant unique permet de retracer le parcours complet de chaque facture et d’analyser les performances du processus au cas par cas. Où trouver ces données Clé composite issue 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é a eu lieu. | ||
| Description L’heure de l’événement est l’horodatage associé à chaque activité. Elle établit l’ordre chronologique des événements d’une facture. Ces données sont indispensables pour comprendre le déroulement du processus et effectuer des analyses temporelles. L’analyse s’appuie sur cet horodatage pour ordonner correctement les activités, calculer les temps de cycle entre les étapes, repérer les temps d’attente et étudier les performances du processus sur différentes périodes, par exemple d’un mois à l’autre. Il constitue la base de tous les indicateurs liés à la durée. Pourquoi est-ce important ? Cet horodatage est essentiel pour ordonner les événements chronologiquement et calculer toutes les mesures temporelles, comme les temps de cycle et les durées, qui sont fondamentales pour le Process Mining. Où trouver ces données Extrait de différents champs de date et d’heure dans les tables SAP, comme 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 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation de ces données depuis le système source. | ||
| Description Cet attribut indique la date et l’heure de la dernière extraction ou mise à jour des données depuis SAP S/4HANA. Ces métadonnées sont essentielles pour connaître l’actualité des données analysées. Cette information permet aux utilisateurs de savoir à quel point l’analyse du processus est à jour. Elle les aide à tenir compte du délai de mise à disposition des données et contribue à planifier les actualisations et à préserver leur intégrité. Pourquoi est-ce important ? Indique l’actualité des données afin que les utilisateurs sachent dans quelle mesure l’analyse du processus est à jour. Où trouver ces données Cette valeur est générée et inscrite dans chaque enregistrement au moment 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 dont les données ont été extraites. | ||
| Description Cet attribut indique l’origine des données du processus. Dans cette vue, sa valeur est généralement « SAP S/4HANA ». Dans les environnements qui comptent plusieurs ERP ou systèmes intégrés, ce champ est essentiel pour assurer la traçabilité des données et leur séparation. Il garantit que l’analyse porte sur le bon jeu de données et aide à diagnostiquer les problèmes de qualité en les reliant à leur source. Pourquoi est-ce important ? Indique l’origine des données, un élément essentiel à leur gouvernance, au dépannage et à l’analyse des environnements comportant plusieurs systèmes. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction des données pour en indiquer l’origine. Exemples SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
| Code société CompanyCode | Unité organisationnelle pour laquelle la facture est traitée. | ||
| Description Le code société est la plus petite unité organisationnelle pour laquelle il est possible d’établir un ensemble complet et autonome de comptes à des fins de reporting externe. Dans le contexte du traitement des factures fournisseurs, il représente l’entité juridique qui doit de l’argent au fournisseur. L’analyse par code société permet de comparer les performances du processus entre les différentes entités juridiques de l’organisation. Elle aide à repérer les parties de l’entreprise qui suivent les processus standard, ainsi que celles dont l’efficacité est moindre, les temps de cycle plus longs ou le taux de reprises plus élevé. Pourquoi est-ce important ? Permet de comparer les performances du processus entre les entités juridiques et de repérer les problèmes et les bonnes pratiques propres à une région ou à une unité opérationnelle. Où trouver ces données Présent 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 est la date limite de paiement au fournisseur, à respecter pour éviter les pénalités de retard et préserver de bonnes relations avec lui. 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 au Dashboard « Conformité des paiements et ancienneté des factures » et à l’indicateur « Taux de paiement à temps ». En comparant la date d’échéance à la date de paiement effective, l’analyse révèle si les paiements sont effectués à temps, en avance ou en retard, avec des conséquences financières et relationnelles directes. Pourquoi est-ce important ? C’est le principal repère pour analyser les paiements à temps, mesurer la performance des paiements et évaluer leurs effets sur les relations avec les fournisseurs et les pénalités de retard. Où trouver ces données Cette date est souvent calculée. La date d’échéance nette figure dans le champ BSEG-NETDT. Elle peut aussi être calculée à partir de la date de référence 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 | Montant brut total de la facture dans la devise d’origine du document. | ||
| Description Il s’agit du montant total de la facture soumise par le fournisseur. Il comprend le coût des biens ou des services, les taxes et les autres frais, avant déduction des remises éventuelles. Le montant de la facture est un attribut financier important pour de nombreux types d’analyses. Il permet de hiérarchiser les factures de montant élevé, de comprendre l’incidence financière des retards de traitement, comme 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 circuit d’approbation différent. Il est également essentiel pour repérer les éventuels paiements en double. Pourquoi est-ce important ? Apporte un contexte financier à l’analyse du processus et permet d’étudier les montants, de hiérarchiser les factures importantes et de quantifier les conséquences financières. Où trouver ces données Présent dans des tables comme RBKP-RMWWR (montant brut de la facture) pour les factures MM, ou calculé à partir des postes de BSEG (champ WRBTR) pour les factures FI. Exemples 1500.00250.7512345.50 | |||
| Nom d’utilisateur UserName | Identifiant de la personne qui a effectué l’activité. | ||
| Description Cet attribut enregistre l’identifiant SAP de l’utilisateur responsable d’une activité précise, comme 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, repérer les personnes les plus performantes et identifier celles qui pourraient avoir besoin d’une formation complémentaire. Elle est également utile pour analyser les goulots d’étranglement liés aux approbations dans les Dashboards, car elle permet de déterminer quels approbateurs précis sont à l’origine des retards. Pourquoi est-ce important ? Associe les activités à des personnes précises afin d’analyser les performances et la charge de travail des utilisateurs, ainsi que le respect des règles de séparation des tâches. Où trouver ces données Généralement présent dans les tables d’en-tête, comme BKPF-USNAM (saisi par) ou dans les tables de documents de modification, comme CDHDR-USERNAME (modifié par). Exemples ABROWNJSMITHAP_AUTOMATION | |||
| Nom du fournisseur VendorName | Nom du fournisseur qui a soumis la facture. | ||
| Description Cet attribut contient le nom officiel du fournisseur. Il est associé au numéro de fournisseur enregistré dans le document de facture. L’analyse des fournisseurs est essentielle pour gérer les relations avec eux et repérer les problèmes de processus qui leur sont propres. Elle permet notamment de répondre à des questions comme « Quels fournisseurs soumettent le plus de factures comportant des écarts ? » ou « Payons-nous toujours à temps certains fournisseurs stratégiques ? ». Associé au numéro et au montant de la facture, cet attribut aide également à détecter les éventuels paiements en double. Pourquoi est-ce important ? Permet d’analyser les performances du processus par fournisseur, de repérer ceux qui posent problème et de gérer efficacement les relations avec les fournisseurs stratégiques. Où trouver ces données Extrait de la table des données de base des fournisseurs LFA1 (champ NAME1), en reliant le numéro de fournisseur (LIFNR) figurant dans BKPF ou RBKP. Exemples Fournitures de bureau SA.Groupe Conseil InternationalMachine Parts GmbH | |||
| Numéro de commande d’achat PurchaseOrderNumber | Identifiant unique de la commande d’achat associée à la facture, le cas échéant. | ||
| Description Cet attribut relie une facture à une commande d’achat (PO) approuvée au préalable. La présence d’un numéro de commande d’achat constitue la base du rapprochement à trois voies (commande d’achat, facture et réception de marchandises). Cet attribut est essentiel à l’analyse de la conformité et de l’efficacité. Il sert à calculer l’indicateur « Pourcentage de factures sans commande d’achat », qui mesure le respect des règles d’approvisionnement. Il est également indispensable au Dashboard « Performance du rapprochement à trois voies », qui permet d’analyser le rapprochement des factures associées à une commande d’achat. Pourquoi est-ce important ? Essentiel à l’analyse de l’efficacité du rapprochement à trois voies et à la mesure du respect des règles d’approvisionnement, en repérant les factures traitées sans commande d’achat. Où trouver ces données Présent dans les tables de postes de facture, comme RSEG-EBELN pour les factures MM ou BSEG-EBELN pour les factures FI. Exemples 45000012344500005678 | |||
| Automatisée IsAutomated | Indique si l’activité a été effectuée automatiquement par le système plutôt que par une personne. | ||
| Description Cet attribut booléen distingue les activités lancées par une personne de celles exécutées par des traitements système, des flux de travail ou des robots. Par exemple, une exécution automatisée des paiements ou la comptabilisation d’une facture générée par le système sera signalée comme automatisée. L’analyse de cet attribut permet de mesurer le degré d’automatisation du processus de traitement des factures fournisseurs. Elle sert à évaluer les résultats des initiatives d’automatisation, à comparer l’efficacité des étapes automatisées et manuelles, et à repérer d’autres possibilités d’automatisation. Pourquoi est-ce important ? Permet de mesurer le degré d’automatisation du processus, d’en évaluer l’efficacité et de repérer d’autres possibilités d’amélioration. Où trouver ces données Déduit du nom d’utilisateur, par exemple des identifiants système comme 'SAP_SYSTEM' ou 'BATCHUSER', ou de codes de transaction associés aux traitements automatisés. Exemples truefalse | |||
| Conditions de paiement PaymentTerms | Conditions convenues avec le fournisseur pour le règlement d’une facture, qui prévoient souvent des possibilités d’escompte. | ||
| Description Les conditions de paiement définissent les échéances de règlement et les éventuels escomptes accordés en cas de paiement anticipé. Par exemple, le code « Z001 » peut correspondre à « payable sous 30 jours, avec un escompte de 2 % en cas de paiement sous 10 jours ». Cet attribut est à la base du Dashboard « Taux de récupération des escomptes pour paiement anticipé ». L’analyse des conditions de paiement permet de repérer toutes les factures ouvrant droit à un escompte. En comparant ces factures aux escomptes effectivement obtenus, vous pouvez identifier les économies manquées et mesurer l’efficacité du processus de paiement. Pourquoi est-ce important ? Cet attribut est essentiel pour analyser les possibilités d’escompte pour paiement anticipé, mesurer la performance financière du processus de paiement et repérer les économies manquées. Où trouver ces données Dans les postes fournisseurs, table BSEG-ZTERM, ou dans l’en-tête de facture, champ RBKP-ZTERM. Exemples Z0010001NT30 | |||
| Date de lettrage ClearingDate | 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. C’est la date de l’activité « Paiement lettré », qui marque la dernière étape de la plupart des parcours de facturation menés à bien. Cette date sert à calculer la date réelle de paiement et à la comparer à la date d’échéance de la facture. Elle est donc indispensable au calcul de l’indicateur de performance clé « Taux de paiement à temps » et à toute analyse de la performance des paiements. Elle marque également la fin du calcul du temps de cycle de bout en bout de la facture. Pourquoi est-ce important ? Elle marque le règlement définitif d’une facture, sert de point final au calcul du temps de cycle et permet d’analyser les paiements effectués à temps. Où trouver ces données Disponible 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 | Code de devise du montant de la facture (par exemple, USD ou EUR). | ||
| Description Cet attribut indique la devise dans laquelle le montant de la facture est exprimé. Il apporte le contexte nécessaire à l’interprétation des valeurs financières. Dans une organisation présente dans plusieurs pays, analyser les factures sans tenir compte de leur devise peut conduire à des conclusions trompeuses. Ce champ permet de traiter correctement les données financières, en convertissant les montants dans une devise de référence commune ou en segmentant l’analyse par devise pour étudier l’activité financière de chaque région. Pourquoi est-ce important ? Cet attribut précise le contexte du montant de la facture et permet d’effectuer des analyses et des rapports financiers exacts, notamment dans les organisations présentes dans plusieurs pays. Où trouver ces données Disponible principalement dans les tables d’en-tête des documents, notamment BKPF-WAERS ou RBKP-WAERS. Exemples USDEURGBPJPY | |||
| Escompte obtenu DiscountTaken | Indicateur booléen précisant si un escompte pour paiement anticipé a bien été appliqué. | ||
| Description Cet attribut indique si un escompte de caisse a effectivement été obtenu lors du paiement de la facture. Il joue un rôle essentiel dans la mesure de l’efficacité financière du processus de comptabilité fournisseurs. Cet indicateur est au cœur de l’indicateur de performance clé « Taux de récupération des escomptes pour paiement anticipé ». En filtrant les factures qui ouvraient droit à un escompte selon leurs conditions de paiement, puis en analysant cet indicateur, l’entreprise peut calculer précisément les économies réalisées et les possibilités manquées. Elle dispose ainsi d’une mesure claire et quantifiable de la performance de la comptabilité fournisseurs. Pourquoi est-ce important ? Cet attribut mesure directement la capacité à obtenir les escomptes disponibles pour paiement anticipé, ce qui a un effet direct sur le résultat financier de l’entreprise. Où trouver ces données Déduit de la vérification du montant de l’escompte (BSEG-SKNTO) dans la pièce de paiement : sa valeur doit être supérieure à zéro. Exemples truefalse | |||
| Motif de blocage BlockingReason | Motif pour lequel une facture est bloquée avant paiement, généralement en raison d’un écart. | ||
| Description Lorsqu’une facture ne passe pas un contrôle de validation lors du rapprochement à trois voies ou d’une autre étape de vérification, elle est bloquée avant paiement. Le motif de blocage précise la nature du problème : écart de quantité ou de prix, réception de marchandises manquante, par exemple. Cet attribut est essentiel au Dashboard « Analyse des reprises liées aux écarts de factures ». 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 les écarts de prix sont fréquents, cela peut révéler des problèmes dans les données de référence du système d’achat. Pourquoi est-ce important ? Cet attribut met directement en évidence les causes profondes des écarts de factures et des reprises, afin de cibler les améliorations du processus. Où trouver ces données Stocké dans les tables des postes de facture, comme RSEG, dans les champs commençant par SPGR* (par exemple, SPGRP, SPGRQ, SPGRT). Également disponible dans RBKP_BLOCKED. Exemples Écart de prixÉcart de quantitéRéception de marchandises manquante | |||
| Numéro de facture du fournisseur VendorInvoiceNumber | Numéro de facture indiqué par le fournisseur sur son document. | ||
| Description Il s’agit de la référence issue du système comptable du fournisseur, telle qu’elle figure sur la facture papier ou électronique. Elle est saisie manuellement ou extraite par OCR à la réception de la facture. Ce champ est essentiel aux opérations et à l’analyse, notamment pour le Dashboard « Paiements potentiellement en double ». Pour repérer les doublons, on recherche souvent plusieurs pièces comptables internes ayant le même nom de fournisseur, le même numéro de facture fournisseur et le même montant. Ce numéro constitue la principale référence externe de la facture. Pourquoi est-ce important ? Ce champ est essentiel pour repérer les paiements potentiellement en double et constitue la principale référence externe à utiliser dans les échanges avec les fournisseurs. Où trouver ces données Stocké dans le champ « Référence » 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 son échéance. | ||
| Description Cet attribut calculé indique simplement par vrai ou faux si le paiement de la 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 dans le Dashboard « Conformité des paiements et ancienneté » et le calcul de l’indicateur de performance clé « Taux de paiement à temps ». Il permet de filtrer et d’agréger facilement les données pour compter les paiements en retard, calculer la part des paiements effectués à temps et repérer les fournisseurs ou les codes société qui affichent un taux élevé de retards. Pourquoi est-ce important ? Cet indicateur mesure directement le respect des conditions de paiement, simplifie le calcul du taux de paiement à temps et aide à repérer les points faibles de la performance des paiements. Où trouver ces données Attribut calculé. Logique : 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 clé dans SAP, qui classe 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 circuits de traitement des différentes catégories de factures. Le processus d’approbation d’un avoir peut, par exemple, différer de celui d’une facture standard. Cette analyse est utile au Dashboard « Variantes du circuit d’approbation des factures ». Pourquoi est-ce important ? Permet de segmenter le processus selon le traitement des différents types de factures et de mettre en évidence les variations de parcours et de temps de cycle. Où trouver ces données Directement dans la table d’en-tête du document, champ BKPF-BLART. Exemples KRREKG | |||
Activités de traitement des factures fournisseurs
| Activité | Description | ||
|---|---|---|---|
| Facture annulée | Le document de facture a été contrepassé, ce qui annule son incidence financière. Il s’agit d’une autre issue possible du processus, souvent due à des erreurs de saisie ou à un litige avec le fournisseur. | ||
| Pourquoi est-ce important ? Le suivi des annulations permet d’identifier les causes d’échec du processus, comme les soumissions en double ou les erreurs dans les données de facture, et peut révéler des problèmes en amont. Où trouver ces données 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 correspondant. Données à recueillir Repérez la date de comptabilisation du document de contrepassation, dont le numéro figure 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 requises dans le système de flux de travail. Il s’agit souvent de la dernière étape avant sa comptabilisation ou la levée du blocage de paiement. | ||
| Pourquoi est-ce important ? Cette étape clé marque la fin du cycle d’approbation. Le délai entre la transmission de la facture et son approbation est un indicateur important de l’efficacité du processus. Où trouver ces données Cet événement est extrait des journaux SAP Business, où il apparaît comme une étape d’achèvement ou de validation finale. Il peut aussi être déduit de la levée d’un blocage de paiement après la transmission de la facture. Données à recueillir Extrayez les événements d’achèvement des flux de travail des journaux SAP ou repérez l’événement final de « validation ». Type d’événement explicit | |||
| Facture bloquée pour paiement | Le système a bloqué la facture, automatiquement ou manuellement, empêchant ainsi son paiement. Ce blocage est généralement dû à des écarts de prix ou de quantité, ou à des approbations manquantes. | ||
| Pourquoi est-ce 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ù trouver ces données Ce statut explicite est enregistré dans le champ de clé de blocage de paiement (ZLSPR) du poste fournisseur du document comptable (table BSEG). Données à recueillir L’événement est consigné dans 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 un passif financier. Un document mis en attente devient un document comptabilisé, ou la facture est comptabilisée directement. | ||
| Pourquoi est-ce important ? Cette étape financière importante confirme l’obligation de paiement de l’entreprise et constitue souvent un préalable à la planification du paiement. Où trouver ces données Cet événement est identifié à partir de la date de comptabilisation (BUDAT) dans l’en-tête du document (BKPF). Le statut d’un document comptabilisé (BKPF-BSTAT) est vide. Données à recueillir Utilisez la date de comptabilisation (BKPF-BUDAT) pour les documents qui ne sont pas 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 par l’intermédiaire d’une interface automatisée comme l’OCR/VIM. L’é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 est-ce important ? Point de départ du processus, cette activité est indispensable pour calculer le temps de cycle de bout en bout des factures et mesurer le débit de l’ensemble du processus de traitement des factures fournisseurs. Où trouver ces données 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). Données à recueillir Utilisez l’horodatage de création du document de facture (BKPF-CPUDT, BKPF-CPUTM). 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 grand livre auxiliaire. Le processus est alors terminé. | ||
| Pourquoi est-ce important ? Dernière étape du processus, cette activité est indispensable au calcul exact du temps de cycle de bout en bout. Elle confirme que le passif est réglé. Où trouver ces données Cet événement explicite est marqué par le renseignement du champ de date de compensation (AUGDT) sur le poste fournisseur du document de facture (table BSEG). Données à recueillir Utilisez la date de compensation (BSEG-AUGDT) du poste de facture. Type d’événement explicit | |||
| Paiement exécuté | La facture a été payée. Cet événement est enregistré lorsque l’exécution des paiements est terminée et qu’un document de paiement est créé et comptabilisé. | ||
| Pourquoi est-ce important ? Cette activité est essentielle à l’analyse de la trésorerie et au calcul de l’indicateur « Taux de paiement à temps », qui compare cette date à la date d’échéance de la facture. Où trouver ces données 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 indiqué dans le champ du document de compensation (AUGBL) du poste de facture (BSEG). Données à recueillir Repérez la date de comptabilisation (BUDAT) du document de paiement qui solde le poste de facture. Type d’événement explicit | |||
| Commande d’achat rapprochée | Cette activité indique que la facture a été rapprochée avec succès de la commande d’achat correspondante. Il s’agit d’une étape importante du rapprochement à trois voies pour les factures liées aux achats. | ||
| Pourquoi est-ce important ? L’analyse de cette activité permet d’évaluer l’efficacité du rapprochement et constitue un élément essentiel des indicateurs « Performance du rapprochement à trois voies » et « Pourcentage de factures sans commande d’achat ». Où trouver ces données Cet événement est déduit lorsqu’une ligne de facture dans la table BSEG ou ACDOCA contient un numéro de commande d’achat (EBELN) et un poste (EBELP) valides. Données à recueillir Déduit de la présence d’une référence à une commande d’achat (BSEG-EBELN) dans le document de facture lors de sa création. Type d’événement inferred | |||
| Date d’échéance de la facture dépassée | Cet événement calculé indique que la date d’échéance nette de la facture est passée sans que le paiement ait été compensé. Il signale un retard de paiement. | ||
| Pourquoi est-ce important ? Cette activité est essentielle au Dashboard « Conformité des paiements et ancienneté des factures ». Elle permet de repérer et de gérer les factures en retard de manière proactive, ainsi que d’analyser les causes profondes des retards de paiement. Où trouver ces données 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). Données à recueillir Événement calculé 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 détecté, probablement à l’origine d’un blocage de paiement, a été examiné et résolu. Elle est enregistrée lorsqu’un blocage de paiement est levé sur une facture. | ||
| Pourquoi est-ce important ? Le suivi de cette boucle de reprise est essentiel au 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ù trouver ces données Cet événement 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 en est la principale source. Données à recueillir Repérez les documents de modification de la table BSEG pour lesquels le champ ZLSPR passe d’une valeur à un champ vide. Type d’événement inferred | |||
| Facture mise en attente | La facture a été saisie dans le système, mais n’a pas encore été comptabilisée dans le grand livre. Cette étape permet souvent d’enregistrer un document incomplet pour le traiter ou le faire approuver ultérieurement. | ||
| Pourquoi est-ce important ? Le suivi des factures mises en attente permet de repérer 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 aux contrôles initiaux. Où trouver ces données Ce statut est déduit du champ de statut du document dans l’en-tête du document comptable (BKPF-BSTAT = 'V' pour une mise en attente). L’événement se produit lorsque le statut est défini. Données à recueillir Repérez les documents de modification de la table BKPF pour lesquels le champ BSTAT prend la valeur 'V' (Vor-erfasst/Pre-entered). Type d’événement inferred | |||
| Facture rejetée | Un approbateur a rejeté la facture au cours du flux de travail d’approbation. La facture est alors généralement renvoyée à la personne chargée de son traitement pour être corrigée ou clarifiée. | ||
| Pourquoi est-ce important ? Le suivi des rejets met en évidence les boucles de reprise dans le processus d’approbation et peut révéler des problèmes de conformité aux règles ou de codification des factures. Où trouver ces données Cet événement est enregistré comme un résultat spécifique dans les journaux SAP Business associés à la facture. Données à recueillir Extrayez des journaux SAP les événements de statut « rejeté » des flux de travail. Type d’événement explicit | |||
| Facture transmise pour approbation | La facture a été soumise à un flux de travail pour obtenir les approbations requises selon les règles métier. Cette étape marque le début du sous-processus d’approbation. | ||
| Pourquoi est-ce important ? Cette activité marque le point de départ du calcul de l’indicateur « Temps moyen d’approbation des factures » et de l’analyse des goulots d’étranglement liés aux approbations. Où trouver ces données Cet événement peut être extrait des journaux SAP Business, dans les tables SWW*, qui enregistrent le démarrage d’une instance de flux de travail liée à l’objet facture, par exemple BUS2081. Données à recueillir Extrayez des journaux SAP les événements de démarrage des flux de travail (par exemple, dans la 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 paiements (par exemple, F110). Son paiement est désormais prévu, sous réserve de l’exécution finale de cette opération. | ||
| Pourquoi est-ce important ? Cette activité marque le passage d’un passif ouvert à un poste en cours de préparation pour paiement. Elle permet d’analyser l’efficacité des opérations de paiement. Où trouver ces données Cet événement est explicitement consigné dans les tables de données d’exécution des paiements, notamment REGUP (postes traités par le programme de paiement) et REGUH (en-tête). Données à recueillir Repérez le moment où 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é indique que les quantités et les montants de la facture ont été rapprochés avec succès du document de réception de marchandises correspondant. Il s’agit du dernier contrôle dans un rapprochement à trois voies. | ||
| Pourquoi est-ce important ? Le suivi de cette activité permet de repérer les inefficacités du rapprochement à trois voies et les écarts entre les marchandises reçues et celles facturées par le fournisseur. Où trouver ces données Cet événement est déduit de la présence d’une référence au document article (réception de marchandises) sur la ligne de facture, souvent liée à l’historique du poste de commande d’achat. Données à recueillir Déduit de la présence d’une référence au 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 : vérifiez que vous disposez 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 nom similaire) où se trouvent les vues CDS. Vous aurez besoin d’un client SQL capable de se connecter à la base SAP HANA, comme SAP HANA Studio, DBeaver ou un outil de requête similaire.
- Repérer les principales vues CDS : cette extraction s’appuie principalement sur les vues CDS I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails et I_PaymentProposalItem. Familiarisez-vous avec leurs principaux champs.
- Définir le périmètre de la requête : ouvrez votre client SQL et connectez-vous à la base SAP HANA. Avant d’exécuter la requête complète, définissez le périmètre de l’extraction : indiquez l’identifiant du système source, la période des factures (CreationDateTime) et les codes société concernés.
- Préparer la requête principale : copiez dans votre client SQL la requête complète fournie dans la section correspondante. Elle utilise des expressions de table communes (CTE) pour sélectionner d’abord un ensemble de factures, puis constituer un journal d’événements réunissant les données de 15 activités différentes.
- Définir les paramètres de la requête : repérez les variables de remplacement dans la requête SQL copiée. Remplacez « [YYYY-MM-DD] » par les dates de début et de fin de la période d’analyse. Remplacez « [Your Company Code 1] » et « [Your Company Code 2] » par les codes société SAP à analyser.
- Exécuter la requête d’extraction : lancez la requête SQL complète. Selon le volume de données et la période choisie, l’exécution peut durer de quelques minutes à plusieurs heures.
- Vérifier les premiers résultats : une fois la requête terminée, examinez les premières centaines de lignes. Vérifiez la cohérence des données, la présence des valeurs attendues dans toutes les colonnes et la diversité des valeurs ActivityName.
- Exporter le journal d’événements : exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Choisissez l’encodage UTF-8 pour éviter les problèmes de caractères. Donnez au fichier un nom explicite, par exemple sap_s4hana_ap_event_log.csv.
- Préparer l’importation : avant d’importer le fichier dans un outil de Process Mining, vérifiez que les en-têtes de colonnes du CSV correspondent exactement aux noms d’attributs requis : Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc.
- Importer les données dans l’outil de Process Mining : importez le fichier CSV généré dans votre plateforme de Process Mining et associez les colonnes aux champs correspondants : identifiant de cas, activité et horodatage.
Configuration
- Principales vues CDS : l’extraction s’appuie sur plusieurs vues CDS standard de S/4HANA. Les principales sont :
- I_JournalEntry et I_JournalEntryItem : en-têtes et postes des documents financiers, détails de comptabilisation et informations de lettrage.
- I_SupplierInvoiceAPI01 : détails propres aux factures MM (logistique), notamment les références aux commandes d’achat et les blocages de paiement.
- I_ChangeDocument : horodatage précis des modifications, par exemple l’ajout ou la suppression d’un blocage de paiement.
- I_WorkflowStatusDetails : événements liés au flux de travail d’approbation des factures.
- I_PaymentProposalItem : identification des factures incluses dans une proposition de cycle de paiement.
- I_Supplier : enrichissement des données avec les informations de base sur les fournisseurs, comme VendorName.
- Filtrage par période : il est essentiel de limiter le volume de données à l’aide d’un filtre de dates. 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 satisfaisantes.
- Filtres obligatoires : filtrez toujours par CompanyCode. L’analyse simultanée de tous les codes société peut être très lente et ne pas répondre aux besoins métier. Filtrez également JournalEntryType pour ne retenir que les documents liés aux fournisseurs, par exemple « KR » ou « RE ».
- Prérequis : l’utilisateur qui exécute la requête doit disposer de l’autorisation SELECT sur toutes les vues CDS utilisées et sur le schéma HANA sous-jacent. Un accès à l’application via l’interface SAP GUI ne suffit pas.
- Performances : les requêtes directes sur I_ChangeDocument peuvent mobiliser beaucoup de ressources. La requête fournie tente de limiter cet impact en filtrant d’abord les factures. Pour les très grands volumes, envisagez d’exécuter l’extraction en dehors des heures de pointe ou par périodes plus courtes.
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
- Vérifiez que vous disposez d’un accès direct en lecture au schéma SAP HANA contenant les tables SAP S/4HANA concernées. Obtenez la chaîne de connexion, les identifiants, le nom du schéma et les autorisations nécessaires pour lire BKPF, ACDOCA et les éventuelles tables supplémentaires configurées pour les documents préenregistrés, le flux de travail, les achats, les réceptions de marchandises, les propositions de paiement, le lettrage et les extournes.
- Vérifiez le modèle de données technique du système cible avant l’exécution. Validez les noms physiques, les champs clés et d’horodatage, les liens entre extournes et documents d’origine, les relations de paiement ainsi que le stockage du flux de travail utilisé par le système. Remplacez chaque variable entre crochets dans la requête par l’objet ou le champ correspondant du système. Ne partez pas du principe que les données du flux de travail ou des documents préenregistrés se trouvent dans une table universelle unique.
- Configurez les paramètres d’extraction. Renseignez [Start date], [End date], [Company code filter], [Document type filter] et [Schema name]. Commencez par une période de trois à six mois, puis élargissez-la après avoir vérifié les performances et l’exhaustivité des données.
- Exécutez la requête SQL dans un client SQL SAP HANA approuvé, comme SAP HANA Database Explorer ou un autre outil d’exécution SQL autorisé. La requête produit une ligne pour chaque activité explicitement extraite ; ProcessMind ne déduit pas les événements.
- Validez les résultats. Vérifiez que Invoice sert d’identifiant de 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 liens entre extournes et documents d’origine, ainsi que les jointures entre documents avant de charger les données.
- Appliquez les associations propres au système, le cas échéant. Par exemple, associez la source configurée des documents préenregistrés à Invoice Parked, la source du flux de travail à Invoice Routed For Approval, Invoice Approved et Invoice Rejected, et la source de paiement à Payment Proposal Created et Payment Executed. Si la traçabilité est nécessaire, conservez les identifiants sources dans des colonnes supplémentaires.
- Exportez les résultats 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 et gardez les noms de colonnes exacts suivants : Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber et InvoiceDueDate. Ne regroupez pas les activités par facture.
- Importez le journal d’événements dans ProcessMind et définissez Invoice comme identifiant de cas, ActivityName comme colonne d’activité et EventTime comme colonne d’horodatage. Vérifiez que les attributs facultatifs sont associés aux champs correspondants. ProcessMind lit le journal d’événements tel quel : avant l’importation, assurez-vous que chaque activité à visualiser figure déjà sur une ligne.
Configuration
- Période : commencez par trois à six mois. Selon l’activité extraite, utilisez la date de comptabilisation, la date de création du document ou la date pertinente de l’événement source. N’élargissez la période qu’après avoir vérifié la durée d’exécution de la requête et la durée de conservation des données sources.
- Filtrage par société : configurez [Company code filter] pour limiter l’extraction aux codes société requis. Si aucune restriction n’est nécessaire, sélectionnez toutes les sociétés de manière contrôlée plutôt que d’exécuter une requête de production sans restriction.
- Filtrage par document : configurez [Document type filter] uniquement après avoir confirmé les types de documents utilisés dans le système cible pour les factures fournisseurs, les avoirs, les documents préenregistrés, les documents de paiement et les extournes.
- Association des schémas et des objets : remplacez [Schema name] et 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 : convertissez tous les horodatages sources dans un même fuseau horaire. Si seule une date 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 ne comptez pas sur ProcessMind pour déduire les événements de lettrage, d’approbation, d’échéance ou de compensation.
- É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 qui n’ont pas été lettrées à cette date. La requête utilise [Evaluation timestamp] pour ce calcul.
- Performances : limitez la période initiale et le périmètre des sociétés, filtrez les champs indexés ou pertinents pour le partitionnement, évitez les projections trop larges et exécutez la requête pendant une plage de traitement 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 pertinent de la source et prévoyez une période de reprise afin de prendre en compte les mises à jour tardives et les extournes.
- Prérequis : autorisations requises sur la base de données, accès approuvé à l’environnement de production, connaissance de la configuration Universal Journal du système, accès aux sources configurées pour les documents préenregistrés, les achats, les réceptions de marchandises, le flux de travail, les paiements, le lettrage et les extournes, ainsi que toute approbation applicable en matière de licence SAP ou de gouvernance.
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 pour confirmer les conditions de déclenchement exactes et les champs de données de chacune des 15 activités requises. Repérez les tables SAP concernées, les types de documents (par exemple, « KR » et « RE ») et les codes société à inclure dans le périmètre.
- Créer le programme ABAP : ouvrez l’éditeur ABAP avec le code de transaction SE38. Créez un programme exécutable, par exemple Z_PM_AP_INVOICE_EXTRACT. Donnez-lui un titre explicite et définissez l’application « Financial Accounting ».
- Définir l’écran de sélection : dans le programme, créez un écran de sélection (avec les mots-clés PARAMETERS et SELECT-OPTIONS) permettant de préciser la période d’extraction (date de création des factures), les codes société concernés (BUKRS) et les types de documents de facture (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 pour stocker les données extraites des différentes tables sources SAP, comme BKPF, BSEG, RBKP, RSEG, CDHDR, CDPOS et REGUH.
- Sélection principale des données : commencez l’extraction en sélectionnant les factures principales 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 dans une table interne pour effectuer les recherches suivantes.
- Extraire les activités dans l’ordre : pour chaque facture de l’ensemble principal, effectuez plusieurs sélections afin de récupérer les horodatages et les détails de chaque activité métier. Par exemple, interrogez CDHDR et CDPOS pour les modifications des blocages de paiement, REGUH et REGUP pour les données de cycle de paiement, et BKPF pour les détails des documents d’extourne. 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 enregistrées 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 le lettrage intervient après l’échéance, créez un événement dont l’horodatage correspond à la date d’échéance.
- Transformation et enrichissement des données : à mesure que vous récupérez les données de chaque activité, renseignez tous les attributs requis. Recherchez notamment les noms des fournisseurs dans LFA1, convertissez les dates et les heures en une seule chaîne d’horodatage (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 réunies dans la table interne finale, utilisez les instructions OPEN DATASET, LOOP AT ... TRANSFER et CLOSE DATASET pour écrire les données dans un fichier, sur le chemin du serveur d’applications défini dans l’écran de sélection.
- Télécharger le fichier et préparer son importation : utilisez le code de transaction CG3Y pour télécharger le fichier généré depuis le serveur d’applications vers votre ordinateur. Enregistrez-le au format CSV avec l’encodage UTF-8. Avant de l’importer dans l’outil de Process Mining, vérifiez que les en-têtes de colonnes correspondent aux attributs requis (Invoice, ActivityName, EventTime, etc.).
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 6 à 12 mois est recommandée.
- Code société (P_BUKRS) : paramètre SELECT-OPTIONS obligatoire pour filtrer les codes société concernés. Il est déconseillé de traiter tous les codes société à la fois, 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é en tâche de fond (SM36/SM37) afin d’éviter les délais d’expiration dans le dialogue interactif. Planifiez son exécution en dehors des heures de pointe.
- Chemin du fichier de sortie : paramètre permettant de préciser 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 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 de modification des documents (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’applications.
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 à vous lancer ?
Appuyez-vous sur ce modèle pour lancer votre initiative de Process Mining et améliorer sensiblement l’efficacité de votre comptabilité fournisseurs. Commencez dès aujourd’hui à optimiser et à simplifier vos processus.
É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.