Votre modèle de données pour le traitement des factures Purchase to Pay
Votre modèle de données pour le traitement des factures Purchase to Pay
- Attributs recommandés à recueillir
- Activités clés à suivre
- Guide d’extraction pour SAP S/4HANA
Attributs du traitement des factures Purchase to Pay
| Nom | Description | ||
|---|---|---|---|
| Numéro de facture InvoiceNumber | Identifiant unique du document de facture fournisseur, utilisé comme identifiant principal du cas 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, comme la création, la mise en attente, l’approbation et le paiement, au sein d’une même instance de processus. En Process Mining, cet attribut est essentiel pour suivre le parcours de chaque facture de bout en bout. 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 variations du processus pour chaque facture. Pourquoi est-ce important ? Il s’agit de la clé qui relie tous les événements associés et permet de retracer l’ensemble du cycle de vie d’une facture dans le système. Où trouver ces données Il s’agit du numéro de 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é a eu lieu. | ||
| 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 indispensables 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 exacts servent à mesurer des indicateurs de performance tels que le « temps de cycle moyen des factures » et le « temps de cycle d’approbation des factures ». L’analyse du temps écoulé entre les activités permet aux organisations de repérer les goulots d’étranglement qui retardent les factures et de déterminer où accélérer le processus. Pourquoi est-ce important ? Cet horodatage est à la base de toutes les analyses temporelles, notamment le suivi des performances, le repérage des goulots d’étranglement et le suivi des SLA. Où trouver ces données Ces données proviennent généralement des tables de documents de modification CDHDR (en-tête) et CDPOS (poste), à partir des champs UDATE et UTIME. Pour certains événements, elles peuvent être extraites des dates de création ou de saisie 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 au cours du traitement d’une facture. Exemples : « Document de facture créé », « Facture transmise pour approbation », « Blocage de paiement défini » et « Paiement exécuté ». Cet attribut est essentiel à la création de la carte du processus, qui représente visuellement le déroulement des activités. L’analyse de leur séquence, de leur fréquence et de leur durée permet de repérer les goulots d’étranglement, les boucles de reprise et les écarts par rapport au processus prévu. Il constitue la base de toute analyse de Process Mining. Pourquoi est-ce important ? Il définit les étapes du processus et permet de visualiser les cartes de processus ainsi que d’analyser les flux et leurs variations. Où trouver ces données Déduit à partir d’une combinaison de codes de transaction SAP (SY-TCODE), de statuts des documents de modification (CDHDR/CDPOS) et de valeurs de champs précises 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. En Process Mining, il est essentiel de filtrer ou de comparer les données par code société pour analyser les performances du processus entre différentes unités opérationnelles, entités juridiques ou pays. Cette analyse permet de repérer les écarts régionaux en matière d’efficacité, de conformité et d’automatisation, et de cibler les initiatives d’amélioration. Pourquoi est-ce important ? Il permet de segmenter et de comparer les performances du traitement des factures entre les différentes entités juridiques ou zones géographiques de l’organisation. Où trouver ces données Il s’agit d’un champ standard de la table d’en-tête de document BKPF, champ BUKRS. Exemples 1000US01DE01 | |||
| Commande d’achat PurchasingDocument | Numéro de la commande d’achat associée à la facture. | ||
| 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 voies, qui vérifie la facture par rapport à la commande 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 examiner les écarts de rapprochement et évaluer l’efficacité de la partie approvisionnement du processus. Pourquoi est-ce important ? Relie la facture au processus d’approvisionnement, ce qui est essentiel pour analyser les écarts de rapprochement et le respect des commandes d’achat. Où trouver ces données Cette information se trouve généralement dans la table des postes de document BSEG, champ EBELN (numéro du document d’achat). Exemples 450000123445000056784500009012 | |||
| Date d’échéance du paiement PaymentDueDate | Date limite à 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 fournisseur doit être payé, 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 pour l’indicateur « taux de paiement à temps » et le Dashboard « performances de paiement des fournisseurs ». En comparant la date de paiement effective à la date d’échéance, une 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 est-ce important ? Il s’agit du principal repère pour mesurer le respect des échéances de paiement, essentiel au maintien de bonnes relations avec les fournisseurs et à la prévention des frais de retard. Où trouver ces données Cette date est souvent disponible directement dans le poste fournisseur de la table BSEG, champ ZFBDT (date de base pour le calcul de l’échéance). La date d’échéance nette est calculée à partir de cette date de base et des conditions de paiement. Exemples 2023-05-302023-06-152023-07-01 | |||
| Montant de la facture AmountInCompanyCodeCurrency | 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’une métrique clé pour comprendre l’incidence financière et l’ampleur du traitement des factures. L’analyse des montants permet de traiter en priorité les factures de valeur élevée, de repérer les tendances de dépenses et de mettre en relation les problèmes de processus avec leur incidence financière. Elle peut, par exemple, aider à déterminer si les factures de montant élevé sont plus souvent bloquées ou nécessitent des délais d’approbation plus longs. Pourquoi est-ce important ? Il apporte un contexte financier au processus et permet d’analyser les données selon leur valeur monétaire, par exemple pour déterminer si les factures de montant élevé suivent un traitement différent. Où trouver ces données Cette valeur est généralement calculée en additionnant les postes concernés de la table BSEG, champ WRBTR (montant en devise locale). Exemples 1500.75125000.00850.20 | |||
| Motif du blocage de 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 normaliser le traitement des exceptions. Cet attribut est essentiel au Dashboard « fréquence et durée des blocages de paiement ». L’analyse de la fréquence des différents motifs permet de repérer les causes profondes des retards de paiement, qu’elles soient liées à certains fournisseurs, à des articles ou à des processus internes, et de prendre des mesures correctives ciblées. Pourquoi est-ce important ? Il précise la cause des blocages de paiement et permet de cibler l’analyse afin de réduire les retards et d’améliorer le traitement correct dès la première fois. Où trouver ces données Situé dans le poste fournisseur de la table BSEG, champ ZLSPR (clé de blocage de paiement). Exemples RIA | |||
| Nom d’utilisateur UserName | ID utilisateur SAP de la personne ou du système à l’origine de l’activité. | ||
| Description Cet attribut identifie l’utilisateur qui a exécuté une transaction ou créé un document. Il peut s’agir de l’ID d’une personne ou d’un ID système utilisé pour les traitements par lots automatisés. L’analyse par utilisateur permet de comprendre la répartition de la charge de travail, de repérer les besoins de formation et de détecter les comportements inhabituels. Elle peut, par exemple, montrer quels utilisateurs traitent souvent des exceptions ou quelles factures sont traitées automatiquement, comme celles associées à l’utilisateur « BATCHUSER ». Ces informations sont essentielles au calcul de l’indicateur « taux d’automatisation des factures ». Pourquoi est-ce important ? Il associe les activités du processus à des utilisateurs ou à des comptes système précis, ce qui permet d’analyser la charge de travail et les performances, ainsi que de repérer les activités automatisées. Où trouver ces données Extrait 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 qui a 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 base du fournisseur. Cet attribut est utile pour les analyses centrées sur les fournisseurs, par exemple pour évaluer leurs performances de paiement ou repérer ceux qui soumettent souvent des factures problématiques entraînant des exceptions ou des blocages de paiement. Il aide à gérer les relations avec les fournisseurs et à évaluer leur fiabilité. Pourquoi est-ce important ? Il permet d’analyser les performances du processus par fournisseur, de repérer des tendances, de gérer les relations et d’évaluer les problèmes liés aux fournisseurs. Où trouver ces données Se trouve généralement dans la table des postes du document comptable BSEG, champ LIFNR. Exemples 100345700012V9832 | |||
| Type de document DocumentType | Code qui distingue les différents types de documents comptables, comme les factures fournisseurs ou les avoirs. | ||
| Description Dans SAP, le type de document sert à distinguer les différentes transactions métier. Par exemple, « KR » désigne 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 pour comprendre comment sont traitées les différentes transactions. Le traitement d’un avoir peut, par exemple, différer sensiblement de celui d’une facture standard. Cette segmentation fournit des résultats d’analyse plus précis et pertinents. Pourquoi est-ce important ? Il permet de distinguer les différents types de transactions financières, comme les factures standard et les avoirs, qui suivent souvent des processus différents. Où trouver ces données Présent dans la table d’en-tête de document BKPF, champ BLART. Exemples KRREKG | |||
| Comporte des reprises IsRework | Indicateur précisant si la facture a fait l’objet de reprises, par exemple après le rejet d’une approbation ou la levée d’un blocage de paiement. | ||
| Description Cet attribut signale les factures qui ont connu une ou plusieurs boucles de reprise. Les reprises sont repérées à partir de séquences d’activités précises, par exemple « Facture approuvée » après « Facture rejetée », ou « Blocage de paiement supprimé » après « Blocage de paiement défini ». Cet attribut simplifie le calcul de l’indicateur « taux de reprise des factures ». Il permet aux analystes d’isoler et d’examiner facilement les cas concernés afin d’en comprendre les causes profondes et de réduire les inefficacités et les tâches manuelles répétées. Pourquoi est-ce important ? Repère les flux de processus inefficaces qui nécessitent de refaire certaines tâches, ce qui aide à quantifier les pertes et à déterminer les causes profondes des exceptions. Où trouver ces données Calculé à partir de la séquence d’activités du journal d’événements. Par exemple, si « Facture rejetée » apparaît dans la trace d’une facture, cet indicateur prend la valeur vraie. Exemples truefalse | |||
| Conditions de paiement PaymentTerms | Code qui définit les conditions de paiement convenues avec le fournisseur, notamment les échéances 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 « paiement net à 30 jours ». Cet attribut est essentiel à la planification financière et à l’optimisation du fonds de roulement. En Process Mining, il sert à calculer la date d’échéance du paiement et à déterminer si la facture peut bénéficier d’un escompte pour paiement anticipé. Il contribue directement à l’indicateur « taux d’obtention des escomptes pour paiement anticipé ». Pourquoi est-ce important ? Il définit les règles relatives aux échéances et aux escomptes, et influe directement sur les indicateurs de paiement à temps et la gestion du fonds de roulement. Où trouver ces données Présentes dans le poste fournisseur de la table BSEG, champ ZTERM (clé des conditions de paiement). Exemples 0001Z030NT60 | |||
| Date de facture InvoiceDate | Date à laquelle le fournisseur a émis la facture. | ||
| Description La date de facture, également appelée date du document, est celle qui figure sur la facture émise par le fournisseur. Elle sert de point de départ au calcul de la date d’échéance du paiement, selon les conditions convenues. Cette date est fondamentale pour les calculs financiers, notamment pour déterminer l’ancienneté des factures et leur admissibilité aux escomptes pour paiement anticipé. Elle constitue une donnée clé pour l’indicateur « taux d’obtention des escomptes pour paiement anticipé ». Pourquoi est-ce important ? Elle sert de base au calcul des conditions et des échéances de paiement, essentiel à la gestion du fonds de roulement et à l’obtention des escomptes. Où trouver ces données Présente dans la table d’en-tête de document BKPF, champ BLDAT (date du document). Exemples 2023-04-122023-05-152023-06-20 | |||
| Est automatisé IsAutomated | Indicateur précisant si l’activité a été effectuée par un utilisateur système automatisé. | ||
| Description Cet attribut booléen prend la valeur vraie si l’utilisateur associé à une activité est un compte système ou de traitement par lots connu, tel que « WF-BATCH » ou « SAP_SYSTEM ». Il permet de distinguer les étapes manuelles des étapes automatisées du processus. Cet attribut est essentiel au calcul de l’indicateur « taux d’automatisation des factures ». L’analyse des étapes automatisées permet aux organisations de mesurer les résultats de leurs initiatives d’automatisation, de repérer d’autres possibilités de réduire les tâches manuelles et d’améliorer l’efficacité. Pourquoi est-ce important ? Il distingue les activités manuelles de celles exécutées par le système, une distinction fondamentale pour mesurer le taux d’automatisation et repérer les possibilités d’automatisation supplémentaires. Où trouver ces données Déduit de l’attribut UserName. Une association ou une règle permet de classer certains ID utilisateur comme « automatisés ». 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 leur degré d’actualité dans l’outil de Process Mining. L’analyse de cet attribut permet de savoir à quand remontent les résultats obtenus. Il est essentiel aux Dashboards de suivi opérationnel : il permet de vérifier que les décisions reposent sur des informations à jour et de gérer efficacement les cycles d’actualisation des données. Pourquoi est-ce important ? Indique l’actualité des données et permet de s’assurer que les analyses et les rapports reposent sur les informations les plus récentes disponibles. Où trouver ces données Il ne s’agit pas d’un champ SAP. L’outil d’extraction des données ou le processus ETL le génère et l’ajoute 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 dont 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 comprennent plusieurs instances ERP ou associent des systèmes anciens et récents. Il permet de comparer les performances des processus entre différents systèmes ou régions. Il garantit la traçabilité de l’origine des données et joue un rôle essentiel dans leur gouvernance et dans le diagnostic des problèmes lorsque des données issues de plusieurs sources sont réunies sur une plateforme centrale de Process Mining. Pourquoi est-ce important ? Il précise l’origine des données, une information essentielle pour leur gouvernance et pour comparer les processus entre différents systèmes ou sites de l’entreprise. Où trouver ces données Cette valeur est généralement extraite de l’identifiant du système SAP (sy-sysid) lors de l’extraction des données, ou définie comme valeur statique dans le pipeline ETL. Exemples S4PS4H_PROD_100ECC_EU | |||
| Motif de contrepassation ReversalReason | Code indiquant pourquoi un document de facture a été contrepassé. | ||
| Description Lorsqu’une facture est comptabilisée par erreur, elle est souvent contrepassée. Le code du motif de contrepassation en précise la raison, par exemple « date de comptabilisation incorrecte » ou « erreur de saisie ». L’analyse des motifs de contrepassation permet de repérer 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 à corriger les problèmes récurrents qui entraînent des reprises financières et une charge administrative supplémentaire. Pourquoi est-ce important ? Explique pourquoi des factures ont été annulées et met directement en évidence les sources d’erreurs et de reprises dans le processus de comptabilisation. Où trouver ces données Présent dans l’en-tête du document d’origine de la table BKPF, champ STGRD (motif de contrepassation). Exemples 010205 | |||
| N° de document de lettrage. 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 ainsi que la facture a été payée. Cet attribut établit le lien définitif entre une facture et son paiement. Il sert à identifier l’activité « Paiement exécuté » et l’horodatage correspondant, indispensables au calcul du temps de cycle de bout en bout et du taux de paiement à temps. Pourquoi est-ce important ? Confirme qu’une facture a été payée et la relie à la transaction de paiement correspondante, une information essentielle pour analyser le temps de cycle et les performances de paiement. Où trouver ces données Présent dans la table des postes de document 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 métrique compte le nombre d’occurrences de l’activité « Facture transmise 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, ce qui a nécessité un nouveau cycle d’approbation. Cet attribut contribue directement à l’indicateur « taux d’approbation dès la première soumission ». L’analyse des factures ayant connu plusieurs cycles d’approbation permet aux organisations de repérer les causes des refus, comme des informations insuffisantes ou un codage incorrect, et de prendre des mesures pour améliorer le processus. Pourquoi est-ce important ? Quantifie les reprises dans le sous-processus d’approbation, ce qui aide à mesurer le taux de traitement correct dès la première fois et à repérer les motifs de rejet des approbations. Où trouver ces données Calculé en comptant les occurrences de l’activité « Facture transmise pour approbation » pour chaque valeur unique de InvoiceNumber. Exemples 123 | |||
| Payée à temps IsPaidOnTime | Indicateur vrai si la facture a été payée au plus tard à la date d’échéance. | ||
| Description Cet attribut booléen résulte de la comparaison entre la date de paiement effective, c’est-à-dire l’horodatage de l’activité « Paiement exécuté », et la « date d’échéance du paiement ». Il indique clairement, pour chaque facture, si le paiement a été effectué à temps. Il s’agit du calcul central de l’indicateur « taux de paiement à temps ». Il permet de filtrer et d’analyser facilement les caractéristiques des retards de paiement, par exemple les fournisseurs, les codes société ou les montants de facture qui leur sont associés. Pourquoi est-ce important ? Mesure directement le respect des conditions de paiement, un indicateur clé pour la gestion des relations avec les fournisseurs et des opérations financières. Où trouver ces données Calculé en comparant l’heure de l’événement de l’activité « Paiement exécuté » à l’attribut PaymentDueDate. (Payment Date <= PaymentDueDate). Exemples truefalse | |||
Activités du traitement des factures Purchase to Pay
| Activité | Description | ||
|---|---|---|---|
| Document de facture créé | Il s’agit du premier événement : il 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 en attente ou non encore comptabilisé. | ||
| Pourquoi est-ce important ? Cette activité marque le début du cycle de traitement de la facture. Le temps écoulé entre cet événement et les suivants est essentiel pour mesurer le délai total de traitement. Où trouver ces données 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 la méthode de création. Données à recueillir Utilisez l’horodatage de création BKPF-CPUDT et BKPF-CPUTM pour le document de facture. Type d’événement explicit | |||
| Facture approuvée | Cette activité indique que l’autorité compétente a approuvé la facture. Elle est enregistrée lorsque le flux de travail d’approbation aboutit ou qu’un indicateur de libération est défini. | ||
| Pourquoi est-ce important ? Cette étape clé débloque la facture pour son paiement. Les retards d’approbation constituent un goulot d’étranglement fréquent. Le suivi de cette activité permet de repérer les approbateurs ou les étapes du processus qui ralentissent le traitement. Où trouver ces données Cet événement peut être déduit de l’étape finale de libération dans un flux de travail SAP ou du suivi des changements de statut de libération dans les tables associées à la facture ou à son document d’achat. Données à recueillir Déduisez cet événement des événements de fin du flux de travail ou des changements du champ de statut de libération du document. Type d’événement inferred | |||
| Facture comptabilisée | Il s’agit d’une étape financière clé : 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 est-ce important ? La comptabilisation marque une étape importante entre la saisie et l’approbation des données, d’une part, et le règlement financier, d’autre part. Le délai entre la création et la comptabilisation de la facture est un indicateur clé de l’efficacité du traitement interne. Où trouver ces données Cet événement est identifié à partir de 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. Données à recueillir Utilisez la date de comptabilisation (BKPF-BUDAT) comme horodatage de l’événement. Type d’événement explicit | |||
| Facture contrepassée | Activité correspondant à la contrepassation d’une facture précédemment comptabilisée. Pour une facture erronée, il s’agit d’un événement final, après lequel la facture est souvent saisie à nouveau correctement. | ||
| Pourquoi est-ce important ? Les contrepassations révèlent des erreurs importantes qui n’ont pas été détectées plus tôt dans le processus. Il est essentiel d’en suivre la fréquence et les causes profondes pour améliorer le processus et réduire les erreurs financières. Où trouver ces données 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. Données à recueillir Repérez les documents dont le champ BKPF-STBLG est renseigné 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 est-ce important ? Cette étape marque la fin du cycle de vie de la facture P2P. Elle est essentielle pour calculer le temps de cycle total de bout en bout et mesurer le respect des échéances de paiement. Où trouver ces données Cet événement est extrait des informations de lettrage du poste fournisseur. La date de lettrage (BSEG-AUGDT) et le document de lettrage (BSEG-AUGBL) indiquent que le paiement a été effectué. Données à recueillir Utilisez la date de lettrage (BSEG-AUGDT) du poste fournisseur lettré. Type d’événement explicit | |||
| Blocage de paiement défini | Un blocage est délibérément appliqué à une facture pour empêcher son paiement. Il est souvent dû à un écart de prix ou de quantité, ou à un avoir en attente. | ||
| Pourquoi est-ce important ? Les blocages de paiement sont une cause majeure de retards de paiement et de litiges avec les fournisseurs. Pour améliorer le taux de paiement dans les délais, il est essentiel d’analyser leur fréquence, leur durée et leurs motifs. Où trouver ces données Cet événement est enregistré en suivant les modifications du champ de clé de blocage de paiement (BSEG-ZLSPR) dans le poste de facture. Les journaux de modification CDHDR et CDPOS indiquent l’horodatage et l’utilisateur associés à la définition du blocage. Données à recueillir Repérez les cas où le champ BSEG-ZLSPR est renseigné à l’aide des documents de modification (CDHDR/CDPOS). Type d’événement explicit | |||
| Blocage de paiement supprimé | Cet événement marque la résolution d’un problème : un blocage de paiement précédemment défini est supprimé. La facture peut alors de nouveau être payée. | ||
| Pourquoi est-ce important ? Le délai entre la définition et la suppression d’un blocage correspond au temps de résolution d’une exception du processus. Réduire ce délai est essentiel pour améliorer l’efficacité et les relations avec les fournisseurs. Où trouver ces données Cet événement est enregistré lorsque le champ de clé de blocage de paiement (BSEG-ZLSPR) est effacé. Cette modification est consignée dans les tables CDHDR et CDPOS, qui fournissent l’horodatage de la suppression. Données à recueillir Repérez les cas 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é correspond à une modification du document de facture après sa création. Elle survient souvent lors d’une reprise après un rejet ou pour corriger des erreurs. | ||
| Pourquoi est-ce 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 mesurer le travail consacré aux corrections et de repérer les erreurs fréquentes. Où trouver ces données Les modifications des champs clés sont enregistrées dans les tables de documents de modification SAP CDHDR (en-tête) et CDPOS (poste). Vous pouvez générer des événements en filtrant les modifications apportées à l’objet de facture concerné. Données à recueillir Extrayez des tables CDHDR et CDPOS les événements de modification associés à l’objet de facture. Type d’événement explicit | |||
| Facture envoyée pour approbation | Cette activité marque le lancement du processus officiel d’approbation de la facture. Elle est souvent déduite du passage de son statut à « en attente d’approbation » ou de la création d’un élément de flux de travail. | ||
| Pourquoi est-ce important ? C’est le point de départ pour mesurer le temps de cycle d’approbation. Savoir quand les approbations commencent est essentiel pour repérer les goulots d’étranglement dans le circuit d’approbation. Où trouver ces données Cet événement est généralement déduit du démarrage d’un flux de travail SAP Business Workflow (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. Données à recueillir Déduisez cet événement de la création d’un élément de flux de travail lié au document de facture. 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. La mise en attente permet d’enregistrer une facture incomplète ou de la soumettre à un examen ultérieur avant comptabilisation. | ||
| Pourquoi est-ce important ? La mise en attente marque une pause délibérée dans le processus. Le suivi de la durée et de la fréquence des factures mises en attente aide à comprendre les retards qui surviennent avant le début du cycle officiel de comptabilisation et d’approbation. Où trouver ces données Vous pouvez repérer les documents créés à l’aide de transactions de mise en attente, par exemple MIR7 ou FV60, ou vérifier des champs de statut précis dans la table BKPF ou dans des tables dédiées aux documents en attente, comme VBKPF. Données à recueillir Repérez les documents créés à l’aide de transactions de mise en attente ou vérifiez leur statut. Type d’événement explicit | |||
| Facture rejetée | La facture est rejetée au cours du processus d’approbation. Cet événement entraîne une reprise : la facture doit être corrigée puis soumise à nouveau. | ||
| Pourquoi est-ce 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 permet de repérer les possibilités d’amélioration et de formation. Où trouver ces données Cet événement est déduit de mises à jour de statut précises dans un flux de travail SAP, comme le statut « rejeté », ou d’événements qui annulent le flux de travail d’approbation en cours et renvoient la facture à la personne chargée de son traitement. Données à recueillir Déduisez cet événement des changements de statut du flux de travail qui indiquent un rejet. Type d’événement inferred | |||
| Paiement en retard exécuté | Cet événement calculé 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 est-ce important ? Cette activité contribue directement au suivi des indicateurs de paiement à temps et aide à repérer les fournisseurs ou les unités opérationnelles qui connaissent fréquemment des retards de paiement, susceptibles de nuire aux relations fournisseurs et d’entraîner des pénalités. Où trouver ces données Cet événement est calculé en comparant la date de lettrage (BSEG-AUGDT) à la date d’échéance nette. Cette dernière est calculée à partir de la date de base (BSEG-ZFBDT) et des conditions de paiement (BSEG-ZTERM). Données à recueillir Déduisez-le en comparant BSEG-AUGDT > (BSEG-ZFBDT + nombre de jours des conditions de paiement). Type d’événement calculated | |||
| Proposition de paiement créée | La facture est sélectionnée et intégrée à une proposition de paiement dans le cadre d’une campagne de paiement. Il s’agit de la première étape du processus de paiement automatisé. | ||
| Pourquoi est-ce important ? Cette activité indique l’intention de procéder au paiement. Les délais entre cette étape et l’exécution effective du paiement peuvent révéler des problèmes liés à la campagne de paiement, aux approbations ou aux échanges avec la banque. Où trouver ces données Cette information figure dans les tables de campagne de paiement, notamment REGUP, qui contient les postes inclus dans une proposition de paiement. La date de campagne dans la table REGUH correspondante fournit l’horodatage. Données à recueillir Repérez le moment où une facture apparaît dans la table REGUP à la suite d’une campagne de proposition de paiement. Type d’événement explicit | |||
Guides d’extraction
Étapes
- Prérequis et autorisations : vérifiez que l’utilisateur chargé de l’extraction dispose des autorisations nécessaires dans SAP S/4HANA pour accéder aux vues Core Data Services (CDS) requises. Parmi les principales vues figurent
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemetI_PaymentProposalItem. L’utilisateur doit également pouvoir exécuter des requêtes via l’interface choisie, par exemple un service OData ou une connexion SQL directe. - Choisissez 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 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 paramètres clés. Indiquez la période d’extraction, par exemple
CreationDateentre'YYYY-MM-DD'et'YYYY-MM-DD'. Déterminez également les valeurs deCompanyCodeà inclure afin de limiter le périmètre des données extraites. - Adaptez 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 paramètres fictifs, tels que
'{StartDate}','{EndDate}'et('{CompanyCode1}', '{CompanyCode2}'). Remplacez-les par les valeurs définies à l’étape précédente. Selon votre configuration SAP, vous devrez peut-être aussi adapter les noms des champs liés au statut du flux de travail. - Exécutez la requête : lancez la requête SQL complète sur la base SAP S/4HANA ou via la couche de services appropriée. Cette requête couvre un périmètre étendu et son exécution peut prendre du temps, selon le volume de données et la période choisie. Surveillez son exécution afin de repérer d’éventuelles erreurs ou expirations de délai.
- Vérifiez les premiers résultats : une fois la requête terminée, examinez rapidement les résultats. Vérifiez que les colonnes
InvoiceNumber,ActivityNameetEventTimesont renseignées. Assurez-vous que la colonneActivityNamecontient plusieurs activités différentes et pas uniquement « Invoice Document Created ». - Vérifiez la transformation des données : la requête est conçue pour produire un journal d’événements dans un format cohérent. Vérifiez toutefois que la colonne
EventTimeutilise un format d’horodatage uniforme, par exempleYYYY-MM-DDTHH:MM:SS. Si nécessaire, la requête fournie combine les champs de date et d’heure en un seul horodatage. - Exportez les données : exportez le jeu de résultats 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 est encodé en UTF-8 afin d’éviter les problèmes de caractères. Les en-têtes de colonnes doivent correspondre exactement aux attributs requis :
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, etc. - Importez les données dans ProcessMind : importez le fichier CSV préparé dans votre projet de Process Mining. Dans la configuration du modèle de données, associez les colonnes du fichier aux champs correspondants pour l’identifiant de cas, le nom de l’activité et l’horodatage.
Configuration
- Vues CDS utilisées : les principales sources de données sont les vues CDS standard de SAP. Les vues clés sont
I_InvoiceDocumentpour les données d’en-tête,I_OperationalAcctgDocItempour les écritures financières et les détails de lettrage, ainsi queI_ChangeDocumentetI_ChangeDocumentItempour suivre l’historique des modifications d’attributs de facture, comme les blocages de paiement et le statut du flux de travail. - Filtrage par période : il est essentiel de limiter les données à une période précise pour maîtriser les performances. La requête fournie utilise un paramètre fictif pour
CreationDatedans la vueI_InvoiceDocument. Pour commencer, il est recommandé d’extraire trois à six mois de données. - Filtre par code société : pour que l’extraction reste pertinente et gérable, filtrez toujours les données par une ou plusieurs valeurs
CompanyCode. La requête comprend à cet effet le paramètre fictifWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}'). - Filtre par type de document : vous pouvez affiner l’extraction en filtrant sur
InvoiceDocumentType. Vous pouvez, par exemple, inclure les factures fournisseur standard (RE) et exclure les avoirs. Ajoutez ce filtre à la clauseWHEREdu CTE initial. - Prérequis : l’utilisateur qui exécute la requête doit disposer des autorisations d’affichage nécessaires pour les documents financiers et d’achat des codes société concernés. L’accès à la base HANA sous-jacente via un client SQL n’est pas accordé par défaut et nécessite des autorisations spécifiques.
- Performances : l’extraction des données des tables de modification (
I_ChangeDocument,I_ChangeDocumentItem) peut solliciter fortement le système. Appliquez 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.
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
- Vérifiez que l’accès direct en lecture au tenant SAP HANA ou au schéma de base de données est autorisé, puis obtenez un compte de base de données en lecture seule disposant des autorisations nécessaires sur les tables SAP requises et sur les tables d’historique des modifications ou de flux de travail approuvées. Utilisez SAP HANA Database Explorer, SAP HANA Studio ou un client SQL approuvé. N’utilisez pas d’accès en écriture à l’environnement de production.
- Vérifiez 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 courants, mais les objets liés au flux de travail, aux factures préenregistrées, aux propositions de paiement, à l’exécution des paiements, à l’historique des modifications et aux blocages de paiement peuvent varier selon la version et le client. Remplacez chaque paramètre entre crochets dans la requête par des objets vérifiés dans le catalogue système et correspondant à la sémantique métier concernée.
- Définissez la période d’extraction à l’aide de [Start timestamp] et [End timestamp]. Prévoyez une période suffisamment large pour les documents et les événements, généralement de trois à six mois, et prolongez-la si les échéances de paiement ou les retards de paiement peuvent dépasser 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 de cas et, si nécessaire, le combine en interne avec le code société et l’exercice afin d’éviter les doublons. Vérifiez si la définition métier exige d’ajouter l’exercice ou le code société à l’identifiant de cas 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 documents comptables, et ACDOCA pour les données disponibles sur les fournisseurs, les montants, les documents d’achat, le lettrage et les paiements. Ne supposez pas que tous les champs sont renseignés dans chaque scénario de comptabilisation.
- Associez les événements de préenregistrement, d’approbation, de rejet, de mise à jour, de blocage de paiement, d’annulation, de proposition et d’exécution du paiement aux sources vérifiées pour votre système. Remplacez les vues sources fictives 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 et les anciennes et nouvelles valeurs. Chaque activité doit être produite sous forme de 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, lorsque c’est pertinent, limitez la requête par code société, type de document, exercice et horodatage de l’événement. Évitez les jointures sans restriction entre des tables volumineuses de journaux et d’historique.
- Validez les résultats à l’aide des contrôles décrits ci-dessous. Vérifiez la présence de toutes les colonnes requises, le renseignement de EventTime pour chaque événement et de InvoiceNumber pour chaque cas, ainsi que la présence des 13 noms d’activité lorsque les données sources correspondantes existent.
- Exportez les résultats dans un fichier délimité compatible avec 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. Utilisez un fuseau horaire cohérent pour les horodatages et conservez les zéros initiaux des identifiants.
- Importez le journal d’événements dans ProcessMind et configurez InvoiceNumber comme identifiant de cas, ActivityName comme colonne d’activité et EventTime comme colonne d’horodatage. Si la configuration ProcessMind accepte des clés de cas supplémentaires, appliquez la même règle de clé composite que lors de l’extraction.
Configuration
- Période : pour la première extraction, utilisez une période glissante de trois à six mois. Incluez un historique plus long si des événements d’approbation, de paiement, de lettrage, d’annulation ou de retard de paiement peuvent survenir après la période de création de la facture.
- Périmètre des sociétés : filtrez par [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 par [Document type filter] et incluez les types de documents correspondant aux factures fournisseur, aux avoirs, aux factures préenregistrées et aux annulations du processus cible.
- Identifiant de cas : utilisez InvoiceNumber, conformément à la définition du processus. Si les numéros de facture ne sont pas uniques à l’échelle du système, conservez le code société et l’exercice dans les résultats sources ou configurez une clé de cas composite selon le modèle ProcessMind.
- Sources d’événements : vérifiez les sources physiques des changements de statut du flux de travail, des décisions d’approbation, du préenregistrement, 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 configuration 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 harmonisez tous les horodatages des événements avant l’importation.
- Règle de calcul des montants : utilisez le montant dans la devise du code société et vérifiez que la source choisie applique les signes débit et crédit de façon cohérente. Évitez de totaliser les lignes du journal sans avoir validé la règle d’agrégation pour le cas de facture.
- Règle de paiement : définissez ce que signifie Payment Executed : le lettrage, la comptabilisation du document de paiement, l’exécution bancaire ou un autre jalon métier. Utilisez la source correspondant à la définition de processus convenue.
- Retard de paiement : produisez l’événement Late Payment Executed uniquement si Payment Executed survient après PaymentDueDate. La requête calcule explicitement cet événement ; il n’est pas déduit par ProcessMind.
- Performances : limitez la lecture des sources par date, code société, type de document et exercice pertinent. Ne sélectionnez que les colonnes nécessaires, examinez les plans de requête et, si l’historique source est volumineux, matérialisez les vues intermédiaires approuvées.
- Prérequis : une connexion directe à SAP HANA, des autorisations de lecture sur tous les objets sélectionnés, le droit de consulter les métadonnées et l’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 aux bases de données et les autorisations de protection des données sont en place.
- Sécurité : utilisez un compte technique en lecture seule, protégez les données fournisseurs et de paiement, et respectez les règles de transport, d’audit, de masquage et de gestion des identifiants de votre organisation.
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 un nom pour votre nouveau programme dans le champ Program, par exemple
Z_PM_INVOICE_EXTRACT, puis cliquez sur le bouton « Create ». Attribuez un titre, sélectionnez « Executable Program » comme type 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 au journal d’événements final. Créez ensuite un écran de sélection permettant de saisir des paramètres tels qu’une période de dates de saisie des factures, les codes société et les types de documents. Le programme pourra ainsi être réutilisé et adapté à différents besoins.
- Mettez en place la logique de sélection des données : rédigez les instructions ABAP SQL nécessaires 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 de base comme « Invoice Document Created » et « Invoice Posted », sélectionnez les données dans des tables principales telles que
RBKP(en-tête de facture logistique) etBKPF(en-tête de document comptable). - Extrayez les données des documents de modification : pour des activités comme « Payment Block Set » et « Payment Block Removed », interrogez les tables de modification
CDHDR(en-tête du document de modification) etCDPOS(postes du document de modification). Vous devrez repérer les modifications apportées à des champs précis, par exempleZLSPRdans la tableBSEG. - Extrayez les données de paiement : pour recueillir les activités liées aux paiements, interrogez des tables comme
REGUP(postes traités par le programme de paiement) pour les propositions de paiement etBSAK(postes fournisseur lettrés) pour les paiements exécutés. Distinguez l’événement « Late Payment Executed » en comparant la date de lettrage (AUGDT) à la date d’échéance nette (ZFBDT). - Extrayez les données du flux de travail : pour les activités d’approbation, interrogez les tables SAP Business Workflow, comme
SWW_WI2OBJ, afin de relier les éléments du flux de travail aux objets de facture. Cette étape dépend fortement de la configuration de votre flux de travail et peut nécessiter des adaptations importantes. - Rassemblez les données au format du journal d’événements : pour chaque activité sélectionnée, mettez les données en forme dans une table interne commune. Chaque ligne 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 (valeurs séparées par des virgules) est recommandé. - Planifiez et exécutez le programme : pour les tests, exécutez le programme en mode interactif avec
F8. En production, planifiez son exécution comme tâche d’arrière-plan avec la transactionSM36, en dehors des heures de pointe, afin de limiter son impact sur les performances du système. - Récupérez et importez 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. Avant de l’importer dans l’outil de Process Mining, vérifiez qu’il est encodé en UTF-8 et correctement formaté.
Configuration
- Période : définissez une période précise pour l’extraction à partir 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 les données par un ou plusieurs codes société. Dans une grande organisation, extraire les données de tous les codes société peut entraîner des temps d’exécution très longs et produire des fichiers volumineux.
- Type de document (BLART) : filtrez les types de documents pertinents pour isoler les factures fournisseur. Les types courants comprennent « RE » (facture brute) et « KR » (facture fournisseur). Vous exclurez ainsi les documents qui ne sont pas utiles à l’analyse.
- Compte fournisseur (LIFNR) : le programme peut proposer un filtre facultatif sur certains numéros de fournisseur, utile pour une analyse ciblée ou des tests.
- Configuration du fichier de sortie : le programme doit permettre de définir le chemin du fichier de sortie sur le serveur d’applications et 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 le programme doit disposer des droits de développement nécessaires 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.
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 une première étape vers une amélioration notable de vos opérations et une meilleure efficacité.
Optimisez dès maintenant le traitement des factures P2P dans SAP S/4HANA
Repérez les goulots d’étranglement et réduisez le temps de cycle des factures de 30 % ou plus.
Aucune carte bancaire requise. Configuration en quelques minutes.