Votre modèle de données Purchase to Pay - Traitement des factures
Votre modèle de données Purchase to Pay - Traitement des factures
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction pour SAP S/4HANA
Purchase to Pay - Attributs du traitement des factures
| Nom | Description | ||
|---|---|---|---|
| Numéro de facture InvoiceNumber | Identifiant unique du document de facture fournisseur, utilisé comme identifiant principal du dossier dans le processus. | ||
| Description Le numéro de facture est l’identifiant unique attribué à chaque facture fournisseur dans SAP S/4HANA. Il relie toutes les activités associées, telles que la création, le préenregistrement, l’approbation et le paiement, au sein d’une même instance de processus cohérente. Dans le Process Mining, cet attribut est fondamental pour suivre le parcours de bout en bout de chaque facture. Il permet de reconstituer l’ensemble du flux de processus, de la réception au paiement final, et d’analyser les temps de cycle, les goulots d’étranglement et les variantes du processus au niveau de chaque facture. Pourquoi c’est important Il s’agit de la clé essentielle qui relie tous les événements associés et permet de retracer intégralement le cycle de vie d’une facture dans le système. Où les obtenir Il s’agit du numéro du document comptable, présent dans la table BKPF, champ BELNR. Exemples 190000000119000000451900000132 | |||
| Heure de l’événement EventTime | Date et heure précises auxquelles l’activité s’est produite. | ||
| Description L’heure de l’événement est l’horodatage qui indique précisément quand une activité donnée a eu lieu. Ces données sont essentielles pour calculer les durées, les temps de cycle et les temps d’attente entre les différentes étapes du processus. Dans une analyse de Process Mining, des horodatages précis servent à mesurer des KPI de performance tels que « Temps de cycle moyen des factures » et « Temps de cycle d’approbation des factures ». En analysant le temps écoulé entre les activités, les organisations peuvent localiser les goulots d’étranglement qui retardent les factures et repérer les possibilités d’accélérer le processus. Pourquoi c’est important Cet horodatage constitue la base de toutes les analyses fondées sur le temps, notamment le suivi des performances, l’identification des goulots d’étranglement et le suivi des SLA. Où les obtenir Généralement issu des tables de documents de modification CDHDR (en-tête) et CDPOS (poste), à partir des champs UDATE et UTIME. Pour certains événements, il peut provenir des dates de création ou de saisie figurant dans des tables telles que BKPF (CPUDT, CPUTM). Exemples 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Nom de l’activité ActivityName | Nom de l’activité métier ou de l’événement survenu à un moment précis pour une facture. | ||
| Description Le nom de l’activité décrit une étape précise ou un changement de statut dans le cycle de traitement des factures. Exemples : « Document de facture créé », « Facture envoyée pour approbation », « Blocage du paiement défini » et « Paiement exécuté ». Cet attribut est essentiel pour construire la cartographie du processus, qui représente visuellement le déroulement des activités. L’analyse de leur séquence, de leur fréquence et du temps écoulé entre elles permet d’identifier les goulots d’étranglement, les boucles de reprise et les écarts par rapport au processus conforme. Il constitue la base de toute analyse de Process Mining. Pourquoi c’est important Il définit les étapes du processus et permet de visualiser les cartes de processus ainsi que d’analyser les flux et les variations du processus. Où les obtenir Dérivé d’une combinaison de codes de transaction SAP (SY-TCODE), de statuts d’objets de documents de modification (CDHDR/CDPOS) et de valeurs de champs spécifiques indiquant des changements de statut. Exemples Facture mise en attenteFacture approuvéePaiement exécuté | |||
| Code société CompanyCode | Unité organisationnelle représentant une société juridiquement indépendante pour laquelle des états financiers sont établis. | ||
| Description Le code société est une unité organisationnelle fondamentale dans SAP Finance. Chaque facture est affectée à un code société précis, qui détermine l’entité juridique responsable de la transaction. Dans le Process Mining, filtrer ou comparer les données par code société est essentiel pour analyser les performances du processus entre différentes unités opérationnelles, entités juridiques ou pays. Cela aide à identifier les écarts régionaux en matière d’efficacité, de conformité et de niveau d’automatisation, afin de soutenir des initiatives d’amélioration ciblées. Pourquoi c’est important Il permet de segmenter et de comparer les performances du traitement des factures entre différentes entités juridiques ou zones géographiques de l’organisation. Où les obtenir Il s’agit d’un champ standard de la table d’en-tête des documents BKPF, champ BUKRS. Exemples 1000US01DE01 | |||
| Commande d’achat PurchasingDocument | Numéro de la commande d’achat à laquelle la facture est associée. | ||
| Description Le numéro du document d’achat relie la facture fournisseur à la commande d’achat d’origine (PO). Ce lien est fondamental pour le rapprochement à trois niveaux, qui vérifie la concordance entre la facture, la commande d’achat et la réception des marchandises. L’analyse de cet attribut aide à comprendre les problèmes liés aux factures associées ou non à une commande d’achat. Il est essentiel pour étudier les écarts de rapprochement et comprendre l’efficacité de la partie approvisionnement du processus. Pourquoi c’est important Il relie la facture au processus d’approvisionnement, ce qui est essentiel pour analyser les écarts de rapprochement et la conformité aux commandes d’achat. Où les obtenir Ces informations se trouvent généralement dans la table des postes de documents BSEG, champ EBELN (numéro du document d’achat). Exemples 450000123445000056784500009012 | |||
| Date d’échéance du paiement PaymentDueDate | Date à laquelle la facture doit être payée pour éviter tout retard. | ||
| Description La date d’échéance du paiement est la date calculée à laquelle le paiement au fournisseur doit être effectué, en fonction de la date de facture et des conditions de paiement convenues. Elle constitue une échéance importante du processus. Cet attribut est essentiel au KPI « Taux de paiement dans les délais » et au Dashboard « Performance des paiements fournisseurs ». En comparant la date réelle du paiement à la date d’échéance, l’entreprise peut mesurer sa capacité à respecter ses obligations de paiement, ce qui influe sur ses relations avec les fournisseurs et sa réputation financière. Pourquoi c’est important Il s’agit de la référence principale pour mesurer le respect des délais de paiement, un indicateur important pour préserver de bonnes relations avec les fournisseurs et éviter les frais de retard. Où les obtenir Cette date est souvent disponible directement sur le poste fournisseur de la table BSEG, dans le champ ZFBDT (date de référence pour le calcul de l’échéance). La date d’échéance nette est calculée à partir de cette date de référence et des conditions de paiement. Exemples 2023-05-302023-06-152023-07-01 | |||
| Montant de la facture AmountInCompanyCodeCurrency | Montant brut total de la facture dans la devise locale du code société. | ||
| Description Cet attribut représente la valeur totale de la facture. Il s’agit d’un indicateur important pour comprendre l’impact financier et l’ampleur de l’activité de traitement des factures. L’analyse des montants permet de prioriser le traitement des factures de valeur élevée, d’identifier les tendances de dépenses et de mettre en relation les problèmes de processus avec leur valeur financière. Elle peut notamment servir à déterminer si les factures de valeur élevée sont plus souvent bloquées ou nécessitent des délais d’approbation plus longs. Pourquoi c’est important Il fournit un contexte financier au processus et permet d’analyser les opérations selon leur valeur monétaire, notamment pour déterminer si les factures de valeur élevée sont traitées différemment. Où les obtenir Cette valeur est généralement calculée à partir de la somme des postes concernés dans la table BSEG, champ WRBTR (montant dans la devise locale). Exemples 1500.75125000.00850.20 | |||
| Motif du blocage du paiement PaymentBlockReason | Code indiquant pourquoi une facture est bloquée pour paiement. | ||
| Description Lorsqu’une facture est bloquée pour paiement, cet attribut précise le motif du blocage, par exemple « écart de quantité » ou « différence de prix ». Ces motifs sont configurés dans SAP afin de standardiser la gestion des exceptions. Cet attribut est essentiel au Dashboard « Occurrence et durée des blocages de paiement ». L’analyse de la fréquence des différents motifs de blocage aide à identifier les causes profondes des retards de paiement, qu’elles soient liées à certains fournisseurs, à des articles ou à des processus internes, afin de mettre en place des mesures correctives ciblées. Pourquoi c’est important Il fournit la cause profonde précise des blocages de paiement, ce qui permet de cibler les analyses, de réduire les retards et d’améliorer le traitement correct dès la première fois. Où les obtenir Situé sur le poste fournisseur de la table BSEG, champ ZLSPR (clé de blocage du paiement). Exemples RIA | |||
| Nom d’utilisateur UserName | ID utilisateur SAP de la personne ou du système ayant effectué l’activité. | ||
| Description Cet attribut identifie l’utilisateur qui a exécuté une transaction donnée ou créé un document. Il peut s’agir de l’ID d’une personne ou de l’ID d’un système pour les traitements automatisés par lots. L’analyse par utilisateur aide à comprendre la répartition de la charge de travail, à identifier les besoins de formation et à repérer les comportements inhabituels. Elle peut notamment montrer quels utilisateurs traitent fréquemment les exceptions ou quelles factures sont traitées automatiquement, par exemple par l’utilisateur « BATCHUSER », ce qui est essentiel pour calculer le KPI « Taux d’automatisation des factures ». Pourquoi c’est important Il attribue les activités du processus à des utilisateurs ou à des comptes système précis, ce qui permet d’analyser la charge de travail, de comparer les performances et de détecter les automatisations. Où les obtenir Issu de champs tels que BKPF-USNAM (saisi par) ou CDHDR-USERNAME (modifié par). Exemples SMITHJMUELLERTWF-BATCH | |||
| Numéro de fournisseur VendorNumber | Identifiant unique du fournisseur ayant soumis la facture. | ||
| Description Le numéro de fournisseur identifie le fournisseur ou le créancier associé à la facture. Il relie la transaction de facturation aux données de référence du fournisseur. Cet attribut est essentiel pour les analyses centrées sur les fournisseurs, par exemple l’évaluation de la « performance des paiements fournisseurs » ou l’identification des fournisseurs qui soumettent fréquemment des factures problématiques entraînant des exceptions ou des blocages de paiement. Il contribue à la gestion des relations avec les fournisseurs et à l’évaluation de leur fiabilité. Pourquoi c’est important Il permet d’analyser les performances du processus par fournisseur, d’identifier des tendances, de gérer les relations et d’évaluer les problèmes liés aux fournisseurs. Où les obtenir Généralement présent dans la table des postes de documents comptables BSEG, champ LIFNR. Exemples 100345700012V9832 | |||
| Type de document DocumentType | Code qui classe les différents types de documents comptables, tels que les factures fournisseurs ou les avoirs. | ||
| Description Le type de document sert dans SAP à distinguer les différentes transactions métier. Par exemple, « KR » représente généralement une facture fournisseur standard, tandis que « KG » peut désigner un avoir fournisseur. L’analyse par type de document permet de segmenter le processus afin de comprendre comment sont traités les différents types de transactions. Le processus d’un avoir peut, par exemple, différer sensiblement de celui d’une facture standard. Cette segmentation fournit des analyses de processus plus précises et plus pertinentes. Pourquoi c’est important Il permet de distinguer les différents types de transactions financières, comme les factures standard et les avoirs, qui suivent souvent des parcours de processus différents. Où les obtenir Présent dans la table d’en-tête des documents BKPF, champ BLART. Exemples KRREKG | |||
| Conditions de paiement PaymentTerms | Code définissant les conditions de paiement convenues avec le fournisseur, notamment les dates d’échéance et les périodes d’escompte. | ||
| Description Les conditions de paiement définissent les règles de règlement d’une facture, y compris les éventuels escomptes pour paiement anticipé. Par exemple, « Z030 » peut signifier « payable sous 30 jours nets ». Cet attribut est essentiel à la planification financière et à l’optimisation du fonds de roulement. Dans le Process Mining, il sert à calculer la « date d’échéance du paiement » et à déterminer l’éligibilité aux escomptes pour paiement anticipé, ce qui contribue directement au KPI « Taux de capture des escomptes pour paiement anticipé ». Pourquoi c’est important Il définit les règles relatives aux dates d’échéance et aux escomptes, avec un impact direct sur les KPI de respect des délais de paiement et la gestion du fonds de roulement. Où les obtenir Présentes sur le poste fournisseur de la table BSEG, dans le champ ZTERM (clé des conditions de paiement). Exemples 0001Z030NT60 | |||
| Date de facture InvoiceDate | Date à laquelle le fournisseur a émis le document de facture. | ||
| Description La date de facture, également appelée date du document, est la date indiquée par le fournisseur sur la facture. Elle sert de point de départ pour calculer la date d’échéance du paiement selon les conditions de paiement convenues. Dans le cadre de l’analyse, cette date est fondamentale pour les calculs financiers, notamment la détermination de l’ancienneté des factures et de l’éligibilité aux escomptes pour paiement anticipé. Elle constitue une donnée d’entrée essentielle du KPI « Taux de capture des escomptes pour paiement anticipé ». Pourquoi c’est important Elle sert de référence pour calculer les conditions de paiement et les dates d’échéance, ce qui est essentiel à la gestion du fonds de roulement et à la capture des escomptes. Où les obtenir Présente dans la table d’en-tête des documents BKPF, champ BLDAT (date du document). Exemples 2023-04-122023-05-152023-06-20 | |||
| Est automatisé IsAutomated | Indicateur précisant si une activité a été effectuée par un utilisateur système automatisé. | ||
| Description Cet attribut booléen prend la valeur true lorsque l’utilisateur associé à une activité est un compte système ou un compte de traitement par lots connu, tel que « WF-BATCH » ou « SAP_SYSTEM ». Il aide à distinguer les étapes manuelles des étapes automatisées du processus. Cet attribut est essentiel au calcul du KPI « Taux d’automatisation des factures ». En analysant les parties automatisées du processus, les organisations peuvent mesurer les résultats de leurs initiatives d’automatisation, réduire davantage les tâches manuelles et améliorer l’efficacité. Pourquoi c’est important Il distingue les activités manuelles des activités pilotées par le système, ce qui est fondamental pour mesurer les taux d’automatisation et identifier de nouvelles possibilités d’automatisation. Où les obtenir Dérivé de l’attribut UserName. Une table de correspondance ou une règle permet de classer certains ID utilisateur comme « automatisés ». Exemples truefalse | |||
| Est payé dans les délais IsPaidOnTime | Indicateur prenant la valeur true si la facture a été payée à la date d’échéance ou avant celle-ci. | ||
| Description Cet attribut booléen résulte de la comparaison entre la date réelle du paiement, c’est-à-dire l’horodatage de l’activité « Paiement exécuté », et la « date d’échéance du paiement ». Il fournit un résultat binaire clair pour le statut de paiement de chaque facture. Il constitue le calcul central du KPI « Taux de paiement dans les délais ». Il permet de filtrer et d’analyser facilement les caractéristiques des paiements en retard, notamment les fournisseurs, les codes société ou les montants de facture fréquemment associés aux retards. Pourquoi c’est important Il mesure directement le respect des conditions de paiement, un KPI important pour la gestion des relations avec les fournisseurs et les opérations financières. Où les obtenir Calculé en comparant EventTime de l’activité « Paiement exécuté » à l’attribut PaymentDueDate. (Payment Date <= PaymentDueDate). Exemples truefalse | |||
| Est une reprise IsRework | Indicateur précisant si une facture a fait l’objet d’activités de reprise, telles qu’une approbation rejetée ou la suppression d’un blocage de paiement. | ||
| Description Cet attribut signale les factures qui ont connu une ou plusieurs boucles de reprise. Une reprise est identifiée par certaines séquences d’activités, par exemple « Facture approuvée » après « Facture rejetée », ou « Blocage du paiement supprimé » après « Blocage du paiement défini ». Cet attribut simplifie le calcul du KPI « Taux de reprise des factures ». Il permet aux analystes d’isoler et d’étudier facilement les dossiers ayant fait l’objet d’une reprise, afin de comprendre les causes profondes de l’inefficacité et des efforts manuels répétés. Pourquoi c’est important Il identifie les flux de processus inefficaces dans lesquels le travail doit être répété, ce qui aide à quantifier le gaspillage et à localiser les causes profondes des exceptions de processus. Où les obtenir Calculé à partir de la séquence des activités dans le journal d’événements. Par exemple, si « Facture rejetée » apparaît dans la trace d’une facture, cet indicateur prend la valeur true. Exemples truefalse | |||
| Horodatage de l’extraction ExtractionTimestamp | Date et heure auxquelles les données ont été extraites du système source. | ||
| Description Cet attribut enregistre l’horodatage de l’extraction des données. Il indique le degré d’actualité des données analysées dans l’outil de Process Mining. Dans le cadre de l’analyse, il permet d’évaluer la récence des résultats produits. Il est essentiel aux Dashboards de suivi opérationnel, afin de garantir que les décisions reposent sur des informations à jour et de gérer efficacement les cycles d’actualisation des données. Pourquoi c’est important Indique le degré d’actualité des données et garantit que l’analyse et les rapports reposent sur les informations les plus récentes disponibles. Où les obtenir Il ne s’agit pas d’un champ SAP. Il est généré et ajouté par l’outil d’extraction des données ou le processus ETL au moment de l’extraction. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| ID du système source SourceSystemId | Identifiant du système SAP S/4HANA source depuis lequel les données ont été extraites. | ||
| Description Cet attribut indique le système d’origine, par exemple « S4H_PROD » ou « ERP_EU ». Il est particulièrement important dans les environnements qui regroupent plusieurs instances ERP ou des systèmes historiques et modernes. Il permet de comparer les performances des processus entre différents systèmes ou régions. Il garantit la traçabilité des données et joue un rôle essentiel dans la gouvernance des données et le dépannage lorsque des données provenant de plusieurs sources sont regroupées dans une plateforme centrale de Process Mining. Pourquoi c’est important Il fournit le contexte relatif à l’origine des données, indispensable à la gouvernance des données et à la comparaison des processus entre différents systèmes ou sites de l’entreprise. Où les obtenir Cette valeur est généralement dérivée de l’identifiant du système SAP (sy-sysid) lors de l’extraction des données ou configurée comme valeur statique dans le pipeline ETL. Exemples S4PS4H_PROD_100ECC_EU | |||
| Motif de la contrepassation ReversalReason | Code indiquant pourquoi un document de facture a été contrepassé. | ||
| Description Lorsqu’une facture est comptabilisée incorrectement, elle est souvent contrepassée. Le code du motif de contrepassation explique pourquoi cette opération a été effectuée, par exemple « date de comptabilisation incorrecte » ou « erreur de saisie ». L’analyse des motifs de contrepassation aide à identifier les erreurs récurrentes dans le processus de comptabilisation des factures. Ces résultats peuvent servir à améliorer la formation, renforcer les contrôles du système ou traiter les problèmes récurrents qui entraînent des reprises financières et une charge administrative supplémentaire. Pourquoi c’est important Il explique pourquoi les factures ont été annulées et fournit une indication directe sur les sources d’erreurs et de reprises dans le processus de comptabilisation. Où les obtenir Présent dans l’en-tête du document d’origine, dans la table BKPF, champ STGRD (motif de la contrepassation). Exemples 010205 | |||
| N° du document de compensation. ClearingDocumentNumber | Numéro du document qui lettre la facture, généralement le document de paiement. | ||
| Description Le numéro du document de lettrage relie un poste de facture ouvert à la transaction qui le lettre, généralement le document de paiement. Il confirme que la facture a été payée. Cet attribut constitue le lien définitif entre une facture et son paiement. Il sert à identifier l’activité « Paiement exécuté » et son horodatage correspondant, indispensables au calcul du temps de cycle de bout en bout et du taux de paiement dans les délais. Pourquoi c’est important Il confirme qu’une facture a été payée et la relie à la transaction de paiement correspondante, ce qui est essentiel à l’analyse du temps de cycle et des performances de paiement. Où les obtenir Présent dans la table des postes de documents BSEG, champ AUGBL (numéro du document de lettrage). Exemples 150000000115000000231500000088 | |||
| Nombre de cycles d’approbation ApprovalCycleCount | Nombre de fois où une facture a été soumise pour approbation. | ||
| Description Cette mesure compte le nombre d’occurrences de l’activité « Facture envoyée pour approbation » pour une même facture. Un nombre supérieur à un indique que la facture a été rejetée ou renvoyée au moins une fois et qu’un nouveau cycle d’approbation a été nécessaire. Cet attribut contribue directement au KPI « Taux d’approbation dès la première soumission ». L’analyse des factures présentant un nombre élevé de cycles d’approbation permet d’identifier les causes des approbations échouées, comme des informations insuffisantes ou un codage incorrect, puis de prendre des mesures pour améliorer le processus. Pourquoi c’est important Il quantifie les reprises au sein du sous-processus d’approbation, ce qui aide à mesurer le taux de traitement correct dès la première fois et à identifier les motifs de rejet des approbations. Où les obtenir Calculé en comptant les occurrences de l’activité « Facture envoyée pour approbation » pour chaque InvoiceNumber unique. Exemples 123 | |||
Purchase to Pay - Activités de traitement des factures
| Activité | Description | ||
|---|---|---|---|
| Document de facture créé | Il s’agit du premier événement, qui marque la création d’un document de facture dans SAP. Il peut être enregistré lorsqu’un utilisateur sauvegarde un nouveau document de facture, qui peut être à l’état « parked » ou précomptabilisé. | ||
| Pourquoi c’est important Cette activité marque le début du cycle de vie du traitement de la facture. L’analyse du temps écoulé entre cet événement et les suivants est essentielle pour mesurer le délai global de traitement. Où les obtenir Cet événement est enregistré à partir de la date et de l’heure de création (CPUDT, CPUTM) figurant dans la table d’en-tête du document, généralement BKPF ou RBKP pour les factures logistiques. Le code de transaction (BKPF-TCODE), tel que FB60, MIRO ou MIR7, indique le mode de création. Collecte Utilisez l’horodatage de création BKPF-CPUDT et BKPF-CPUTM du document de facture. Type d’événement explicit | |||
| Facture approuvée | Cette activité indique que la facture a été approuvée par l’autorité désignée. Elle est enregistrée lorsque le flux de travail d’approbation se termine avec succès ou lorsqu’un indicateur de libération est défini. | ||
| Pourquoi c’est important Il s’agit d’une étape importante qui débloque la facture pour le paiement. Les retards d’approbation constituent un goulot d’étranglement fréquent, et le suivi de cette activité aide à repérer les approbateurs ou les étapes de processus trop lents. Où les obtenir Cette activité peut être déduite de l’étape finale de libération dans un flux de travail SAP ou du suivi des modifications apportées aux champs de statut de libération dans les tables associées à la facture ou à son document d’achat. Collecte Déduisez cette activité des événements de fin du flux de travail ou des modifications du champ de statut de libération d’un document. Type d’événement inferred | |||
| Facture comptabilisée | Il s’agit d’un événement financier important au cours duquel la facture mise en attente ou approuvée est officiellement comptabilisée dans le grand livre. Cette opération constate la dette envers le fournisseur. | ||
| Pourquoi c’est important La comptabilisation constitue une étape majeure qui sépare la saisie et l’approbation des données de la phase de règlement financier. Le délai entre la création de la facture et sa comptabilisation est un indicateur important de l’efficacité du traitement interne. Où les obtenir Cet événement est identifié par la date de comptabilisation (BKPF-BUDAT) figurant dans l’en-tête du document. Pour les documents d’abord mis en attente, le passage au statut comptabilisé fournit l’horodatage de l’événement. Collecte Utilisez la date de comptabilisation (BKPF-BUDAT) comme horodatage de l’événement. Type d’événement explicit | |||
| Facture contrepassée | Cette activité représente la contrepassation d’un document de facture précédemment comptabilisé. Il s’agit d’un événement terminal pour une facture incorrecte, qui est ensuite souvent saisie à nouveau correctement. | ||
| Pourquoi c’est important Les contrepassations révèlent des erreurs importantes qui n’ont pas été détectées plus tôt dans le processus. Le suivi de leur fréquence et de leurs causes profondes est essentiel pour améliorer le processus et réduire les erreurs financières. Où les obtenir Une contrepassation est identifiée lorsqu’un document de contrepassation est créé. L’en-tête du document d’origine (BKPF) contient le numéro du document de contrepassation (BKPF-STBLG), et inversement. La date de comptabilisation du document de contrepassation correspond à l’heure de l’événement. Collecte Identifiez les documents dont le champ BKPF-STBLG contient une valeur et utilisez la date de comptabilisation du document de contrepassation. Type d’événement explicit | |||
| Paiement exécuté | Il s’agit de la dernière activité du processus standard : le paiement est effectué et la facture est lettrée. Cela signifie que les fonds ont été versés au fournisseur. | ||
| Pourquoi c’est important Cette étape marque la fin du cycle de vie de la facture P2P. Elle est indispensable pour calculer le temps de cycle total de bout en bout et mesurer le respect des délais de paiement par rapport à la date d’échéance. Où les obtenir Cet événement est enregistré à partir des informations du document de lettrage figurant sur le poste fournisseur. La date de lettrage (BSEG-AUGDT) et le document de lettrage (BSEG-AUGBL) indiquent que le paiement a été effectué. Collecte Utilisez la date de lettrage (BSEG-AUGDT) du poste fournisseur lettré. Type d’événement explicit | |||
| Blocage de paiement défini | Activité consistant à appliquer volontairement un blocage à une facture afin d’empêcher son paiement. Cette situation est souvent due à des écarts de prix ou de quantité, ou à l’attente d’un avoir. | ||
| Pourquoi c’est important Les blocages de paiement sont une cause majeure des retards de règlement et des litiges avec les fournisseurs. L’analyse de leur fréquence, de leur durée et de leurs motifs est essentielle pour améliorer le taux de paiements effectués dans les délais. Où les obtenir Cet événement est enregistré en suivant les modifications du champ Payment Block Key (BSEG-ZLSPR) dans le poste de facture. Les journaux de modification CDHDR et CDPOS fournissent l’horodatage et l’utilisateur associés à l’application du blocage. Collecte Identifiez les cas où le champ BSEG-ZLSPR est renseigné au moyen des documents de modification CDHDR/CDPOS. Type d’événement explicit | |||
| Blocage de paiement supprimé | Représente la résolution d’un problème, lorsqu’un blocage de paiement précédemment défini est supprimé. La facture redevient alors éligible au paiement. | ||
| Pourquoi c’est important Le délai entre la mise en place et la suppression d’un bloc correspond au temps de résolution d’une exception de processus. Réduire cette durée est essentiel pour améliorer l’efficacité et les relations avec les fournisseurs. Où les obtenir Cet événement est enregistré lorsque le champ Payment Block Key (BSEG-ZLSPR) est effacé. Cette modification est consignée dans les tables CDHDR et CDPOS, qui fournissent un horodatage de la suppression. Collecte Identifiez le moment où le champ BSEG-ZLSPR est effacé à l’aide des documents de modification (CDHDR/CDPOS). Type d’événement explicit | |||
| Données de facture mises à jour | Cette activité reflète une modification apportée au document de facture après sa création initiale. Elle est fréquente lors des cycles de reprise qui suivent un rejet ou lorsqu’il faut corriger des erreurs. | ||
| Pourquoi c’est important Des mises à jour fréquentes signalent des reprises et d’éventuels problèmes de qualité des données au moment de la saisie. Le suivi de ces modifications permet de quantifier les efforts consacrés aux corrections et d’identifier les erreurs récurrentes. Où les obtenir Les modifications apportées aux champs clés sont enregistrées dans les tables de documents de modification SAP, CDHDR pour l’en-tête et CDPOS pour les postes. Les événements peuvent être générés en filtrant les modifications de l’objet de facture concerné. Collecte Extrayez les événements de modification des tables CDHDR et CDPOS pour l’objet de facture. Type d’événement explicit | |||
| Facture envoyée pour approbation | Cette activité marque le lancement d’un flux de travail d’approbation formel pour la facture. Elle est souvent déduite lorsque le statut de la facture passe à « en attente d’approbation » ou lorsqu’un élément de flux de travail est généré. | ||
| Pourquoi c’est important Il s’agit du point de départ pour mesurer le temps de cycle d’approbation. Comprendre à quel moment les approbations commencent est essentiel pour identifier les goulots d’étranglement du flux de travail d’approbation lui-même. Où les obtenir Cet événement est généralement déduit du démarrage d’un SAP Business Workflow, dans la table SWW_WI2OBJ, associé à l’objet de facture, par exemple BUS2081, ou d’une modification d’un champ de statut personnalisé dans l’en-tête du document. Collecte Déduisez cette activité de la création d’un élément de flux de travail associé au document de facture. Type d’événement inferred | |||
| Facture mise en attente | Représente une facture saisie dans le système, mais qui n’a pas encore été comptabilisée dans le grand livre. La mise en attente permet d’enregistrer les factures incomplètes ou de les soumettre à une vérification ultérieure avant comptabilisation. | ||
| Pourquoi c’est important La mise en attente indique une pause volontaire dans le processus. Le suivi de la durée et de la fréquence des factures mises en attente aide à identifier les causes des retards avant le début du cycle officiel de comptabilisation et d’approbation. Où les obtenir Cela peut être identifié à partir de documents créés au moyen de transactions de mise en attente, par exemple MIR7 ou FV60, ou en vérifiant certains champs de statut dans la table BKPF ou dans des tables dédiées aux documents mis en attente, telles que VBKPF. Collecte Identifiez les documents créés au moyen de transactions de mise en attente ou vérifiez la présence d’un statut de document mis en attente. Type d’événement explicit | |||
| Facture rejetée | Représente le rejet d’une facture au cours du processus d’approbation. Cet événement déclenche une reprise, qui nécessite une correction et une nouvelle soumission. | ||
| Pourquoi c’est important Les rejets de factures sont un indicateur important d’inefficacité du processus et de problèmes de qualité des données. L’analyse de leur fréquence et de leurs motifs aide à identifier les possibilités d’amélioration et les besoins de formation. Où les obtenir Cette activité est déduite de mises à jour précises du statut dans un flux de travail SAP, par exemple lorsque le statut devient « rejeté », ou d’événements qui annulent le flux de travail d’approbation en cours et renvoient la facture au gestionnaire. Collecte Déduisez cette activité des modifications du statut du flux de travail indiquant un rejet. Type d’événement inferred | |||
| Paiement exécuté en retard | Il s’agit d’un événement calculé qui se produit lorsque le paiement d’une facture est exécuté après sa date d’échéance calculée. Il est déterminé en comparant deux champs de date. | ||
| Pourquoi c’est important Cette activité contribue directement aux KPI relatifs au respect des délais de paiement et aide à identifier les fournisseurs ou les unités opérationnelles qui accusent fréquemment des retards de paiement, ce qui peut nuire aux relations avec les fournisseurs et entraîner des pénalités. Où les obtenir Cet événement est calculé en comparant la date de lettrage (BSEG-AUGDT) à la date d’échéance nette. La date d’échéance est elle-même calculée à partir de la date de référence (BSEG-ZFBDT) et des conditions de paiement (BSEG-ZTERM). Collecte Déduisez cet événement en comparant BSEG-AUGDT > (BSEG-ZFBDT + nombre de jours prévu par les conditions de paiement). Type d’événement calculated | |||
| Proposition de paiement créée | La facture est sélectionnée et incluse dans une proposition de paiement dans le cadre d’une exécution de paiements. Il s’agit de la première étape du processus de paiement automatisé. | ||
| Pourquoi c’est important Cette activité indique l’intention de payer. Les délais entre cette étape et l’exécution finale du paiement peuvent révéler des problèmes liés au processus d’exécution des paiements, aux approbations ou aux échanges avec la banque. Où les obtenir Cette information se trouve dans les tables d’exécution des paiements, notamment REGUP, qui contient les éléments inclus dans une proposition de paiement. La date d’exécution figurant dans la table REGUH correspondante fournit l’horodatage. Collecte Identifiez le moment où une facture apparaît dans la table REGUP à la suite d’une exécution de proposition de paiement. Type d’événement explicit | |||
Guides d'extraction
Étapes
- Prérequis et autorisations : vérifiez que l’utilisateur qui exécute l’extraction dispose des autorisations nécessaires dans SAP S/4HANA pour accéder aux vues Core Data Services (CDS) requises. Les principales vues sont
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemetI_PaymentProposalItem. L’utilisateur doit également être autorisé à exécuter des requêtes via l’interface choisie, par exemple un service OData ou une connexion SQL directe. - Identifiez votre méthode de connexion : déterminez comment vous vous connecterez au système SAP S/4HANA pour exécuter la requête SQL. Les méthodes courantes comprennent SAP Data Services, SAP Data Intelligence, un outil ETL tiers doté d’un connecteur SAP ou une connexion SQL directe à la base de données SAP HANA, si les règles de sécurité de votre organisation l’autorisent.
- Définissez les paramètres d’extraction : avant d’exécuter la requête, définissez les principaux paramètres. Indiquez la période à extraire, par exemple
CreationDateentre'YYYY-MM-DD'et'YYYY-MM-DD'. Identifiez également les valeurs deCompanyCodeà inclure afin de limiter le périmètre de l’extraction. - Personnalisez la requête SQL : copiez la requête SQL fournie dans le client SQL ou l’outil d’extraction de votre choix. Vérifiez attentivement les espaces réservés, tels que
'{StartDate}','{EndDate}'et('{CompanyCode1}', '{CompanyCode2}'). Remplacez-les par les valeurs définies à l’étape précédente. Vous devrez peut-être aussi adapter les noms de champs liés au statut du flux de travail à votre configuration SAP. - Exécutez la requête : lancez la requête SQL complète sur la base de données SAP S/4HANA ou via la couche de services appropriée. Cette requête est conçue pour couvrir un périmètre étendu et peut nécessiter un temps d’exécution important selon le volume de données et la période sélectionnée. Surveillez les éventuelles erreurs ou expirations de délai.
- Examinez les premiers résultats : une fois la requête terminée, effectuez une vérification rapide du résultat. Assurez-vous que les colonnes
InvoiceNumber,ActivityNameetEventTimesont renseignées. Vérifiez que la colonneActivityNamecontient plusieurs activités différentes, et pas uniquement « Document de facture créé ». - Traitez la transformation des données : la requête est structurée pour produire un journal d’événements propre. Vérifiez toutefois que la colonne
EventTimeutilise un format d’horodatage cohérent, tel queYYYY-MM-DDTHH:MM:SS. Lorsque cela est nécessaire, la requête fournie regroupe les champs de date et d’heure dans un horodatage unique. - Exportez les données : exportez le résultat final depuis votre outil dans un fichier CSV (valeurs séparées par des virgules). Ce format est compatible avec les outils de Process Mining, notamment ProcessMind.
- Préparez l’importation : avant l’importation, vérifiez que le fichier CSV utilise l’encodage UTF-8 afin d’éviter les problèmes de caractères. Assurez-vous que les en-têtes correspondent exactement aux attributs requis :
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, etc. - Importez dans ProcessMind : importez le fichier CSV préparé dans votre projet de Process Mining. Associez les colonnes du fichier aux champs correspondants de l’identifiant du cas, du nom de l’activité et de l’horodatage dans la configuration du modèle de données.
Configuration
- Vues CDS utilisées : les principales sources de données sont les vues CDS standard de SAP. Les vues essentielles sont
I_InvoiceDocumentpour les données d’en-tête,I_OperationalAcctgDocItempour les informations financières et de compensation, ainsi queI_ChangeDocumentetI_ChangeDocumentItempour suivre les modifications historiques des attributs de facture, comme les blocages de paiement et le statut du flux de travail. - Filtrage par période : il est essentiel de filtrer les données sur une période précise afin de maîtriser les performances. La requête fournie utilise un espace réservé pour
CreationDatedans la vueI_InvoiceDocument. Il est recommandé de commencer par une période de trois à six mois. - Filtre par code société : pour que l’extraction reste pertinente et gérable, filtrez toujours sur un ou plusieurs
CompanyCode. La requête contient à cet effet l’espace réservéWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}'). - Filtre par type de document : vous pouvez affiner davantage l’extraction en filtrant sur
InvoiceDocumentType. Vous pouvez, par exemple, inclure les factures fournisseurs standard (RE) tout en excluant les avoirs. Ce filtre peut être ajouté à la clauseWHEREde la CTE initiale. - Prérequis : l’utilisateur qui exécute la requête doit disposer des autorisations d’affichage appropriées pour les documents financiers et d’achat des codes société concernés. L’accès à la base de données HANA sous-jacente via un client SQL n’est pas standard et nécessite des autorisations particulières.
- Considérations de performance : l’extraction des données des tables de documents de modification (
I_ChangeDocument,I_ChangeDocumentItem) peut être coûteuse. Il est essentiel d’appliquer des filtres stricts sur la date, le code société et la classe d’objet (INCOMINGINVOICE) afin d’éviter des temps d’exécution trop longs.
a Exemple de requête sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Étapes
- Confirmez que l’accès direct en lecture au tenant SAP HANA ou au schéma de base de données est approuvé, puis obtenez un utilisateur de base de données en lecture seule autorisé à accéder aux tables SAP requises ainsi qu’aux tables approuvées d’historique des modifications ou du flux de travail. Utilisez SAP HANA Database Explorer, SAP HANA Studio ou un client SQL approuvé. N’utilisez pas d’accès en écriture à la production.
- Confirmez les noms physiques des tables et des colonnes dans le système S/4HANA cible. ACDOCA, BKPF et RBKP constituent des points de départ standard, mais le flux de travail, la mise en attente, la proposition de paiement, l’exécution du paiement, l’historique des modifications et l’historique des blocages de paiement peuvent utiliser des objets propres à la version ou au client. Remplacez chaque espace réservé entre crochets dans la requête par des objets vérifiés dans le catalogue du système et correspondant aux règles métier concernées.
- Définissez la période d’extraction à l’aide de [Start timestamp] et [End timestamp]. Extrayez une période suffisamment large pour les documents et les événements, généralement de trois à six mois, et étendez-la lorsque les dates d’échéance ou les paiements tardifs peuvent se situer après la période de création des factures.
- Identifiez les cas de facture à l’aide de la clé de facture configurée. La requête utilise InvoiceNumber comme identifiant du cas et le combine en interne avec le code société et l’exercice lorsque cela est nécessaire pour éviter les collisions. Vérifiez si la définition métier exige d’ajouter l’exercice ou le code société à l’identifiant du cas dans ProcessMind.
- Associez les données des factures comptabilisées provenant de RBKP, BKPF et ACDOCA. Utilisez RBKP pour les informations d’en-tête de facture, BKPF pour les horodatages et les utilisateurs des pièces comptables, et ACDOCA pour le fournisseur, le montant, le document d’achat, la compensation et les informations comptables liées au paiement, lorsqu’elles sont disponibles. Ne supposez pas que chaque champ est renseigné dans tous les scénarios de comptabilisation.
- Associez les événements de mise en attente, d’approbation, de rejet, de mise à jour, de blocage de paiement, d’annulation, de proposition et d’exécution du paiement à partir des sources vérifiées propres au système. Remplacez les vues sources génériques par des vues ou des tables approuvées qui exposent les horodatages des événements, les références de facture, les utilisateurs, les statuts ainsi que les anciennes et nouvelles valeurs. Chaque activité doit être produite sous la forme d’une ligne d’événement explicite, car ProcessMind ne déduit pas les événements.
- Exécutez la requête SQL complète dans une session hors production ou en lecture seule. Examinez les plans d’exécution et limitez la requête par code société, type de document, exercice et horodatage de l’événement lorsque cela est pertinent. Évitez les jointures non limitées entre de grandes tables de journaux et d’historique.
- Validez le résultat à l’aide des contrôles décrits ci-dessous. Vérifiez que toutes les colonnes requises sont présentes, que EventTime est renseigné pour chaque événement, qu’InvoiceNumber est renseigné pour chaque cas et que les 13 noms d’activité apparaissent lorsque les données sources correspondantes existent.
- Exportez le résultat dans un fichier délimité pris en charge par ProcessMind, de préférence au format CSV UTF-8, avec une ligne par événement et les colonnes InvoiceNumber, ActivityName, EventTime, UserName, CompanyCode, VendorNumber, AmountInCompanyCodeCurrency, PaymentDueDate, DocumentType, PaymentBlockReason et PurchasingDocument. Conservez les horodatages dans un fuseau cohérent et préservez les zéros initiaux des identifiants.
- Importez le journal d’événements dans ProcessMind et configurez InvoiceNumber comme identifiant du cas, ActivityName comme colonne d’activité et EventTime comme colonne d’horodatage. Si la configuration de ProcessMind prend en charge des clés de cas supplémentaires, utilisez la même règle de clé composite que lors de l’extraction.
Configuration
- Période : utilisez initialement une période glissante de trois à six mois. Ajoutez un historique supplémentaire lorsque des événements d’approbation, de paiement, de compensation, d’annulation ou de paiement tardif peuvent survenir après la période de création des factures.
- Périmètre des sociétés : filtrez sur [Company code filter] et vérifiez que les codes société sélectionnés sont autorisés pour l’extraction.
- Périmètre des documents : filtrez sur [Document type filter] et incluez les types de documents correspondant aux factures fournisseurs, aux avoirs, aux factures mises en attente et aux annulations du processus cible.
- Identifiant du cas : utilisez InvoiceNumber, conformément à la définition du processus. Lorsque les numéros de facture ne sont pas uniques à l’échelle globale, conservez le code société et l’exercice dans le résultat source ou configurez une clé de cas composite selon le modèle ProcessMind.
- Sources des événements : vérifiez les sources physiques des changements de statut du flux de travail, des décisions d’approbation, de la mise en attente, de l’historique des modifications, des blocages de paiement, des propositions de paiement et de l’exécution des paiements. Ces sources varient selon la version de S/4HANA, le périmètre activé, la conception du flux de travail et les extensions propres au client.
- Règle d’horodatage : sélectionnez l’horodatage de l’événement métier, et non celui de l’extraction. Documentez le fuseau horaire et convertissez tous les horodatages de manière cohérente avant l’importation.
- Règle relative aux montants : utilisez le montant dans la devise du code société et vérifiez que la source sélectionnée gère les signes débit et crédit de manière cohérente. N’additionnez pas les lignes du journal sans avoir validé la règle d’agrégation pour le cas de facture.
- Règle relative aux paiements : définissez si « Paiement exécuté » correspond à la compensation, à la comptabilisation de la pièce de paiement, à l’exécution bancaire ou à une autre étape métier. Utilisez la source correspondant à la définition approuvée du processus.
- Paiement tardif : produisez « Paiement tardif exécuté » uniquement lorsque « Paiement exécuté » intervient après PaymentDueDate. La requête calcule explicitement cet événement et ne s’appuie pas sur une déduction de ProcessMind.
- Performances : limitez les lectures des sources par date, code société, type de document et exercice concerné. Sélectionnez uniquement les colonnes nécessaires, examinez les plans de requête et matérialisez les vues intermédiaires approuvées si l’historique source est volumineux.
- Prérequis : connectivité directe à SAP HANA, autorisations de lecture sur tous les objets sélectionnés, droit d’inspecter les métadonnées et accès aux données pertinentes des comptes fournisseurs, du grand livre, des achats, du flux de travail et des paiements. Vérifiez que les licences SAP requises, les règles d’accès à la base de données et les approbations relatives à la protection des données sont en place.
- Sécurité : utilisez un compte technique en lecture seule, protégez les données relatives aux fournisseurs et aux paiements, et respectez les règles de l’organisation en matière de transport, d’audit, de masquage et de gestion des identifiants.
a Exemple de requête sql
WITH
invoice_base AS (
SELECT
r.INV_DOC_NO AS InvoiceNumber,
r.COMPANY_CODE AS CompanyCode,
r.FISCAL_YEAR AS FiscalYear,
r.DOCUMENT_TYPE AS DocumentType,
r.VENDOR_NO AS VendorNumber,
r.GROSS_AMOUNT_CC AS AmountInCompanyCodeCurrency,
r.PAYMENT_DUE_DATE AS PaymentDueDate,
r.PURCHASING_DOCUMENT AS PurchasingDocument,
r.CREATED_AT AS InvoiceCreatedAt,
r.CREATED_BY AS InvoiceCreatedBy
FROM [Your RBKP invoice header source] r
WHERE r.CREATED_AT >= '[Start timestamp]'
AND r.CREATED_AT < '[End timestamp]'
AND r.COMPANY_CODE IN ([Company code filter])
AND r.DOCUMENT_TYPE IN ([Document type filter])
),
posted_accounting AS (
SELECT
b.INV_DOC_NO AS InvoiceNumber,
b.COMPANY_CODE AS CompanyCode,
b.FISCAL_YEAR AS FiscalYear,
b.ACCOUNTING_DOCUMENT AS AccountingDocument,
b.POSTING_DATE AS PostingDate,
b.CREATED_AT AS PostedAt,
b.CREATED_BY AS PostedBy,
b.REVERSAL_DOCUMENT AS ReversalDocument,
b.REVERSED_DOCUMENT AS ReversedDocument
FROM [Your BKPF accounting document source] b
WHERE b.CREATED_AT >= '[Start timestamp]'
AND b.CREATED_AT < '[End timestamp]'
AND b.COMPANY_CODE IN ([Company code filter])
),
journal_attributes AS (
SELECT
a.COMPANY_CODE AS CompanyCode,
a.FISCAL_YEAR AS FiscalYear,
a.ACCOUNTING_DOCUMENT AS AccountingDocument,
MAX(a.VENDOR_NO) AS VendorNumber,
SUM(a.AMOUNT_IN_COMPANY_CODE_CURRENCY) AS AmountInCompanyCodeCurrency,
MAX(a.PURCHASING_DOCUMENT) AS PurchasingDocument,
MAX(a.CLEARING_DATE) AS ClearingDate,
MAX(a.CLEARING_DOCUMENT) AS ClearingDocument
FROM [Your ACDOCA universal journal source] a
WHERE a.COMPANY_CODE IN ([Company code filter])
AND a.POSTING_DATE >= '[Start date]'
AND a.POSTING_DATE < '[End date]'
GROUP BY
a.COMPANY_CODE,
a.FISCAL_YEAR,
a.ACCOUNTING_DOCUMENT
),
source_events AS (
SELECT
e.INV_DOC_NO AS InvoiceNumber,
e.COMPANY_CODE AS CompanyCode,
e.FISCAL_YEAR AS FiscalYear,
e.EVENT_TIMESTAMP AS EventTime,
e.EVENT_USER AS UserName,
e.PAYMENT_BLOCK_REASON AS PaymentBlockReason,
e.PURCHASING_DOCUMENT AS PurchasingDocument,
e.VENDOR_NO AS VendorNumber,
e.AMOUNT_IN_COMPANY_CODE_CURRENCY AS AmountInCompanyCodeCurrency,
e.PAYMENT_DUE_DATE AS PaymentDueDate,
e.DOCUMENT_TYPE AS DocumentType,
e.EVENT_TYPE AS SourceEventType
FROM [Your verified invoice event and workflow source] e
WHERE e.EVENT_TIMESTAMP >= '[Start timestamp]'
AND e.EVENT_TIMESTAMP < '[End timestamp]'
AND e.COMPANY_CODE IN ([Company code filter])
),
base_events AS (
SELECT
i.InvoiceNumber,
'Invoice Document Created' AS ActivityName,
i.InvoiceCreatedAt AS EventTime,
i.InvoiceCreatedBy AS UserName,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber) AS VendorNumber,
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)) AS PaymentBlockReason,
COALESCE(i.PurchasingDocument, j.PurchasingDocument) AS PurchasingDocument
FROM invoice_base i
LEFT JOIN posted_accounting p
ON p.InvoiceNumber = i.InvoiceNumber
AND p.CompanyCode = i.CompanyCode
AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j
ON j.CompanyCode = p.CompanyCode
AND j.FiscalYear = p.FiscalYear
AND j.AccountingDocument = p.AccountingDocument
WHERE i.InvoiceCreatedAt IS NOT NULL
UNION ALL
SELECT
s.InvoiceNumber,
'Invoice Parked' AS ActivityName,
s.EventTime,
s.UserName,
s.CompanyCode,
COALESCE(s.VendorNumber, i.VendorNumber) AS VendorNumber,
COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS PaymentDueDate,
COALESCE(s.DocumentType, i.DocumentType) AS DocumentType,
s.PaymentBlockReason,
COALESCE(s.PurchasingDocument, i.PurchasingDocument) AS PurchasingDocument
FROM source_events s
LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PARKED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Sent For Approval', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'SENT_FOR_APPROVAL'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Approved', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'APPROVED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Rejected', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'REJECTED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Data Updated', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'DATA_UPDATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Set', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_SET'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Removed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_REMOVED'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted',
p.PostedAt,
p.PostedBy,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN posted_accounting p ON p.InvoiceNumber = i.InvoiceNumber AND p.CompanyCode = i.CompanyCode AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.CompanyCode AND j.FiscalYear = p.FiscalYear AND j.AccountingDocument = p.AccountingDocument
WHERE p.PostedAt IS NOT NULL
UNION ALL
SELECT s.InvoiceNumber, 'Payment Proposal Created', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_PROPOSAL_CREATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
UNION ALL
SELECT s.InvoiceNumber, 'Late Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
AND s.EventTime > CAST(COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS TIMESTAMP)
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Reversed',
p.ReversalEventAt,
p.ReversalUser,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN [Your verified reversal event source] p ON p.INV_DOC_NO = i.InvoiceNumber AND p.COMPANY_CODE = i.CompanyCode AND p.FISCAL_YEAR = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.COMPANY_CODE AND j.FiscalYear = p.FISCAL_YEAR AND j.AccountingDocument = p.ACCOUNTING_DOCUMENT
WHERE p.ReversalEventAt IS NOT NULL
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
CompanyCode,
VendorNumber,
AmountInCompanyCodeCurrency,
PaymentDueDate,
DocumentType,
PaymentBlockReason,
PurchasingDocument
FROM base_events
WHERE InvoiceNumber IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Étapes
- Accédez à l'éditeur ABAP : connectez-vous à votre système SAP S/4HANA. Ouvrez la transaction
SE38(éditeur ABAP). - Créez le programme : saisissez le nom du nouveau programme dans le champ Program, par exemple
Z_PM_INVOICE_EXTRACT, puis cliquez sur le bouton « Create ». Indiquez un titre, définissez le type sur « Executable Program » et enregistrez le programme dans un package approprié. - Définissez la structure du programme et l'écran de sélection : dans l'éditeur, définissez les structures de données destinées à la sortie de l'Event Log final. Créez ensuite un écran de sélection permettant de saisir des paramètres tels que la période de la date de saisie de la facture, les codes société et les types de document. Le programme sera ainsi réutilisable et adaptable.
- Implémentez la logique de sélection des données : écrivez les instructions SQL ABAP principales pour sélectionner les données dans les différentes tables SAP. Le programme interrogera successivement les données correspondant aux 13 activités requises.
- Extrayez les données d'en-tête et de poste : pour les événements fondamentaux tels que « Invoice Document Created » et « Invoice Posted », sélectionnez les données dans des tables principales comme
RBKP(en-tête de facture logistique) etBKPF(en-tête du document comptable). - Extrayez les données des documents de modification : pour des activités telles que « Payment Block Set » et « Payment Block Removed », interrogez les tables de documents de modification
CDHDR(en-tête du document de modification) etCDPOS(postes du document de modification). Vous devrez identifier les modifications apportées à certains champs, par exempleZLSPRdans la tableBSEG. - Extrayez les données de paiement : pour enregistrer les activités liées aux paiements, interrogez notamment
REGUP(postes traités par le programme de paiement) pour les propositions de paiement etBSAK(postes fournisseurs compensés) pour les paiements exécutés. Distinguez « Late Payment Executed » en comparant la date de compensation (AUGDT) à la date d'échéance nette (ZFBDT). - Extrayez les données du Workflow : pour les activités d'approbation, interrogez les tables SAP Business Workflow telles que
SWW_WI2OBJafin de relier les éléments de Workflow aux objets de facture. Cette partie dépend fortement de votre configuration de Workflow et peut nécessiter une adaptation importante. - Unifiez les données au format Event Log : pour chaque activité sélectionnée, formatez les données dans une structure de table interne commune. Chaque ligne de cette table représente un événement unique et doit contenir l'identifiant de cas (
InvoiceNumber),ActivityNameetEventTime, ainsi que les autres Attributs recommandés. - Générez le fichier de sortie : utilisez les instructions ABAP
OPEN DATASET,TRANSFERetCLOSE DATASETpour écrire le contenu de la table interne finale dans un fichier plat sur le serveur d'applications SAP. Le format CSV est recommandé. - Planifiez et exécutez : exécutez le programme au premier plan pour les tests avec
F8. Pour les exécutions de production, planifiez-le comme tâche en arrière-plan à l'aide de la transactionSM36, pendant les heures creuses, afin de ne pas affecter les performances du système. - Récupérez et chargez le fichier : utilisez la transaction
AL11pour accéder au répertoire du serveur d'applications où le fichier a été enregistré. Téléchargez-le sur votre système local. Vérifiez que le fichier est encodé en UTF-8 et correctement formaté avant de le charger dans l'outil de Process Mining.
Configuration
- Période : définissez une période précise pour l’extraction en fonction de la date de saisie de la facture (
RBKP-CPUDT) ou de la date de comptabilisation (BKPF-BUDAT). Pour une première analyse, une période de trois à six mois est recommandée afin de conserver un volume de données gérable. - Code société (BUKRS) : il est essentiel de filtrer sur un ou plusieurs codes société. Extraire les données de tous les codes société d’une grande organisation peut entraîner des temps d’exécution très longs et produire des fichiers volumineux.
- Type de document (BLART) : filtrez sur les types de documents pertinents afin d’isoler les factures fournisseurs. Les types courants comprennent « RE » (facture, brut) et « KR » (facture fournisseur). Ce filtre permet d’exclure les documents sans rapport avec l’analyse.
- Compte fournisseur (LIFNR) : le programme peut inclure un filtre facultatif sur certains numéros de fournisseur, ce qui est utile pour une analyse ciblée ou pour les tests.
- Configuration du fichier de sortie : le programme doit proposer des paramètres permettant de définir le chemin du fichier de sortie sur le serveur d’applications ainsi que le séparateur de champs, par exemple une virgule ou un point-virgule.
- Prérequis : l’utilisateur ou le compte système qui exécute ce programme doit disposer d’un accès développeur pour créer et exécuter des programmes ABAP via
SE38, ainsi que d’autorisations de lecture étendues sur les tables FI, MM et Basis, notammentBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSet les tables du flux de travail.
a Exemple de requête abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path. Prêt à commencer ?
Commencez dès aujourd’hui à optimiser le traitement de vos factures. Ce modèle constitue votre première étape vers des améliorations opérationnelles significatives et une efficacité accrue.
Optimisez dès maintenant le traitement des factures P2P dans SAP S/4HANA
Localisez les goulots d'étranglement et réduisez d'au moins 30 % le délai de traitement des factures.
Aucune carte bancaire requise. Configuration en quelques minutes.