Votre modèle de données pour le traitement des paiements fournisseurs
Votre modèle de données pour le traitement des paiements fournisseurs
- Attributs essentiels pour l’analyse des fournisseurs et des paiements
- Étapes clés essentielles du cycle de paiement
- Logique d’extraction spécialisée pour les systèmes SAP S/4HANA
Attributs du traitement des paiements fournisseurs
| Nom | Description | ||
|---|---|---|---|
| Activité Activity | Tâche précise ou changement de statut d’un événement enregistré pour la facture. | ||
| Description Cet attribut représente les différentes étapes du processus qui se déroulent pendant le cycle de vie de la facture. Il capture des événements tels que la création, la comptabilisation, le blocage, l’approbation et le lettrage du paiement. Les noms des activités sont dérivés des codes de transaction, des entrées des journaux de modifications ou des mises à jour de statut du flux de travail présentes dans le système source. Pour l’analyse, ce champ est essentiel à la cartographie de la variante du flux de processus. Il permet au moteur de Process Mining de visualiser la séquence des étapes, d’identifier les boucles de reprise et de déterminer où le processus s’écarte du parcours nominal standard. Il constitue le composant central du journal d’événements. Pourquoi c’est important Il définit les nœuds de la carte du processus et permet de visualiser le flux de travail ainsi que les goulots d’étranglement. Où les obtenir Dérivé des codes de transaction (TCODE) ou de l’en-tête des documents de modification (CDHDR) et de leurs postes (CDPOS) Exemples Facture comptabiliséeBlocage du paiement appliquéExécution de la campagne de paiementsFacture compensée | |||
| Heure de l’événement EventTime | Horodatage exact auquel l’activité s’est produite. | ||
| Description Event Time enregistre la date et l’heure précises auxquelles une activité a été validée dans la base de données SAP. Il fournit la dimension temporelle nécessaire pour ordonner séquentiellement les événements au sein d’un cas. Cet horodatage est généralement construit en combinant les champs CPU Date et CPU Time issus des journaux système ou des en-têtes de documents. Dans l’analyse, cet attribut est essentiel au calcul des temps de cycle, de la durée et du débit. Il permet de mesurer les écarts de temps entre les étapes, comme le délai entre la réception de la facture et son approbation finale, ce qui est essentiel pour identifier les goulots d’étranglement et évaluer des indicateurs tels que le temps moyen d’approbation d’une facture. Pourquoi c’est important Il fournit l’ordre chronologique des événements et sert de base à tous les calculs de performance fondés sur le temps. Où les obtenir Table SAP BKPF, champs CPUDT (date de saisie) et CPUTM (heure de saisie), ou champs UDATE et UTIME de CDHDR Exemples 2023-10-12T08:30:00.000Z2023-10-12T14:15:22.000Z2023-10-15T09:00:00.000Z | |||
| Numéro de facture InvoiceNumber | Identifiant unique de la facture fournisseur traitée. | ||
| Description L’Invoice Number est la clé primaire utilisée pour suivre le cycle de vie d’un poste fournisseur dans le système SAP S/4HANA. Il désigne précisément le numéro du document comptable généré lors de la comptabilisation de la facture dans le grand livre. Dans la terminologie SAP standard, il correspond au Document Number (BELNR) associé à un Company Code et à un exercice fiscal précis. Dans l’analyse des processus, cet attribut sert de Case ID. Il relie toutes les activités distinctes, depuis la réception et la mise en attente initiales de la facture jusqu’aux différents blocages et modifications d’approbation, puis au paiement final par lettrage. Le regroupement des événements selon cet identifiant permet aux analystes de reconstituer l’historique complet de chaque obligation de paiement, de bout en bout. Pourquoi c’est important Il constitue le Case ID de référence et permet de reconstituer le flux du processus de paiement de bout en bout. Où les obtenir Table SAP BKPF (en-tête du document comptable), champ BELNR, ou champ BELNR de la table ACDOCA Exemples 1900000523510000289119000006015100003002 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière extraction ou actualisation de l’enregistrement. | ||
| Description Last Data Update indique le moment où les données ont été chargées avec succès dans la plateforme de Process Mining. Il ne correspond pas à l’heure de l’événement métier, mais à l’actualité du jeu de données. Cette distinction est essentielle pour préserver la fiabilité des Dashboards analytiques. Dans l’analyse, cet attribut aide les utilisateurs à comprendre l’actualité des informations affichées. Il est particulièrement important pour la surveillance de Dashboards quasi temps réel, comme Payment Block Analysis, afin de garantir que les décisions reposent sur l’état le plus récent du système SAP S/4HANA. Pourquoi c’est important Il informe les utilisateurs de l’actualité des données, un élément essentiel pour les Dashboards opérationnels. Où les obtenir Généré par le processus ETL / d’extraction Exemples 2023-10-27T23:59:59.000Z2023-11-01T06:00:00.000Z | |||
| Système source SourceSystem | Identifiant de l’instance SAP S/4HANA dont les données sont issues. | ||
| Description Cet attribut identifie l’installation ERP ou le client SAP précis à partir duquel les données du processus ont été extraites. Dans les environnements comprenant plusieurs instances SAP ou des systèmes historiques fonctionnant en parallèle, ce champ garantit la traçabilité des données et permet les comparaisons entre systèmes. Pour l’analyse, ce champ sert de filtre de haut niveau. Il aide les analystes à segmenter les données lorsqu’ils comparent les performances de différentes installations régionales ou vérifient la cohérence des données lors de projets de migration. Il garantit que les variations du processus attribuées à la configuration du système sont correctement contextualisées. Pourquoi c’est important Il distingue les sources de données dans les environnements multisystèmes et garantit une segmentation précise. Où les obtenir ID système (SY-SYSID) issu du contexte d’installation SAP Exemples SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Code société CompanyCode | Unité organisationnelle pour laquelle le bilan et le compte de résultat sont établis. | ||
| Description Le Company Code représente l’entité comptable indépendante au sein de l’entreprise. Il constitue l’unité organisationnelle centrale de la comptabilité externe et sert à structurer les données financières. Chaque facture est affectée à un seul Company Code. Dans l’analyse, cet attribut permet de segmenter les KPI par entité juridique ou par région. Il est utilisé dans les Dashboards pour comparer l’efficacité des équipes de comptabilité fournisseurs de différentes filiales. Il permet notamment de déterminer si une agence présente un taux de blocages manuels des paiements supérieur à la norme de l’entreprise. Pourquoi c’est important Il segmente le processus par entité juridique et facilite les comparaisons internes. Où les obtenir Table SAP BKPF, champ BUKRS Exemples US01DE1010002000 | |||
| Conditions de paiement PaymentTerms | Clé représentant les conditions convenues pour le paiement et les escomptes. | ||
| Description Les Payment Terms définissent la date d’échéance d’une facture et précisent si un escompte pour paiement comptant s’applique en cas de règlement anticipé. Ce code, par exemple « Z001 », correspond à des règles telles que « Net 30 » ou « 2 % à 10 jours, net à 30 jours ». Il est copié depuis les données de base du fournisseur vers la facture, mais peut être modifié manuellement. Dans l’analyse, cet attribut est au cœur de l’optimiseur des escomptes pour paiement anticipé et des Dashboards Vendor Payment Term Compliance. Il permet au système de calculer la date d’échéance de référence et de déterminer si le paiement a été effectué dans la fenêtre optimale pour bénéficier des économies. Pourquoi c’est important Il définit le calendrier attendu et les incitations financières, éléments essentiels à l’analyse des escomptes. Où les obtenir Table SAP BSEG, champ ZTERM Exemples Z001NT300001 | |||
| Date d’échéance nette NetDueDate | Date calculée à laquelle la facture doit être payée pour éviter les pénalités. | ||
| Description La date d’échéance nette constitue la date limite finale de paiement. Elle est calculée en ajoutant le nombre maximal de jours prévu par les conditions de paiement à la date de référence. Bien qu’elle soit parfois stockée explicitement, elle est souvent calculée dans les vues d’analyse. Dans l’analyse, elle sert de référence principale au suivi des paiements tardifs et des pénalités. La comparaison entre la date de lettrage réelle et la date d’échéance nette produit l’indicateur « Nombre de jours de retard », qui aide à mesurer l’efficacité de l’équipe de comptabilité fournisseurs et le risque de tensions avec les fournisseurs. Pourquoi c’est important Elle constitue l’échéance cible du processus ; son non-respect peut dégrader la notation de crédit et entraîner des coûts. Où les obtenir Calculée : date de référence + nombre maximal de jours de paiement (ZBD1T/ZBD2T/ZBD3T) Exemples 2023-11-302023-12-01 | |||
| Date de lettrage ClearingDate | Date à laquelle la facture a été lettrée par le paiement. | ||
| Description La date de lettrage indique le moment où le poste ouvert du grand livre fournisseurs a été soldé, généralement lors d’une exécution de paiement ou d’une comptabilisation manuelle. Elle marque ainsi la fin de la dette. Dans l’analyse, cet attribut sert à calculer le temps de cycle final du processus. Il correspond à l’horodatage de l’activité « Paiement lettré » et est comparé à la date d’échéance nette afin de déterminer la performance des paiements à temps. Il alimente directement le Dashboard d’efficacité du lettrage des paiements. Pourquoi c’est important Elle marque l’achèvement du processus de paiement et permet d’évaluer le respect des délais. Où les obtenir Table SAP BSEG ou champ AUGDT de la table AUGDT Exemples 2023-11-012023-11-15 | |||
| Montant de la facture InvoiceAmount | Montant brut total de la facture dans la devise du document. | ||
| Description Cet attribut reflète la valeur financière de la facture telle qu’elle est enregistrée dans le document source. Il représente la dette à régler auprès du fournisseur. Dans SAP S/4HANA, cette valeur est généralement stockée dans le champ Amount in Document Currency. Dans l’analyse, l’Invoice Amount sert à hiérarchiser les travaux. Des Dashboards tels que Manual Touch Point Distribution utilisent ce champ pour déterminer si des activités manuelles exigeant beaucoup d’efforts sont consacrées à des factures de faible valeur. L’organisation peut ainsi concentrer ses efforts d’optimisation sur les transactions de valeur élevée, pour lesquelles les défaillances du processus présentent un risque financier plus important. Pourquoi c’est important Il donne une indication du poids financier du cas, essentielle pour hiérarchiser les inefficacités des processus à forte valeur. Où les obtenir Table SAP BKPF ou BSEG, champ WRBTR Exemples 1500.00250.5010000.00 | |||
| Motif du blocage du paiement PaymentBlockReason | Code indiquant pourquoi une facture est bloquée pour paiement. | ||
| Description Cet attribut contient le code de motif précis appliqué à une facture et empêchant son intégration automatique dans l’exécution des paiements. Les exemples comprennent « A » pour un blocage de paiement, « R » pour la vérification de facture ou des blocages manuels définis par les utilisateurs. Dans l’analyse, ce champ est le principal facteur du Dashboard Manual Payment Block Analysis. En agrégeant la fréquence des différents motifs de blocage, l’organisation peut diagnostiquer les problèmes systémiques, tels que les écarts de prix fréquents ou les réceptions de marchandises manquantes, qui ralentissent le processus de paiement. Pourquoi c’est important Il identifie la cause précise des arrêts du processus et permet une analyse ciblée des causes profondes. Où les obtenir Table SAP BSEG, champ ZLSPR Exemples ABR* | |||
| Nom d’utilisateur UserName | Identifiant de l’utilisateur ayant effectué l’activité concernée. | ||
| Description Le User Name enregistre l’identifiant de connexion de la personne ou de l’agent système responsable de l’exécution d’une étape du processus. Il peut s’agir d’un utilisateur saisissant manuellement des données ou de l’identifiant d’un traitement en arrière-plan, par exemple « BATCH_USER », exécutant des tâches automatisées. Dans l’analyse, cet attribut permet de calculer le taux d’automatisation des activités. En distinguant les utilisateurs humains des comptes système, les analystes peuvent mesurer le niveau d’automatisation du processus. Il est également utilisé dans le Dashboard Manual Touch Point Distribution pour évaluer la charge de travail des équipes. Pourquoi c’est important Il distingue le travail manuel du travail automatisé et permet de calculer le taux d’automatisation. Où les obtenir Table SAP BKPF, champ USNAM, ou table CDHDR, champ USERNAME Exemples BSMITHWF-BATCHRJONES | |||
| Numéro de fournisseur VendorNumber | Identifiant unique du fournisseur associé à la facture. | ||
| Description Le Vendor Number correspond au compte fournisseur concerné dans le sous-grand livre SAP. Il relie la facture aux données de base contenant les conditions de paiement, les coordonnées bancaires et les informations de contact. Dans S/4HANA, il est souvent associé au concept de Business Partner, tout en conservant le nom de champ historique LIFNR dans de nombreuses tables. Dans l’analyse, cet attribut est fondamental pour le Dashboard Vendor Payment Term Compliance. Il permet aux analystes d’agréger les performances du processus par fournisseur et d’identifier ceux qui provoquent régulièrement des blocages, des écarts de prix ou des retards. Il contribue aux décisions d’achats stratégiques et à la gestion des relations fournisseurs. Pourquoi c’est important Il permet d’agréger les performances par fournisseur, ce qui est essentiel pour identifier les causes profondes des retards. Où les obtenir Table SAP BKPF, champ LIFNR, ou table ACDOCA, champ LIFNR Exemples 100050VEND-US-99200400 | |||
| Paiement en retard IsLatePayment | Indicateur booléen précisant si le paiement a été effectué après la date d’échéance nette. | ||
| Description Cet attribut calculé prend la valeur true lorsque la date de lettrage est strictement postérieure à la date d’échéance nette. Il sert de classification binaire de la performance du processus. Dans l’analyse, cet indicateur permet de compter les cas non conformes pour le KPI de fréquence des pénalités liées aux paiements tardifs. Il simplifie la création des Dashboards en permettant de compter directement les valeurs « True », sans devoir effectuer des calculs de dates complexes dans la couche de visualisation. Pourquoi c’est important Il simplifie le calcul des KPI de performance des paiements à temps. Où les obtenir Calculé : date de lettrage > date d’échéance nette Exemples truefalse | |||
| Sans intervention manuelle IsTouchless | Indicateur booléen précisant si la facture a été traitée sans intervention manuelle. | ||
| Description Cet attribut est calculé en analysant le flux d’événements d’un cas. Si le cas ne contient que des activités automatisées, par exemple un utilisateur « system » ou certains TCODES d’arrière-plan, et aucune modification ni aucun blocage manuel, il est marqué comme traité sans intervention manuelle. Dans l’analyse, il constitue la mesure centrale du KPI de taux de factures traitées sans intervention manuelle. Il permet à l’organisation de suivre les résultats de ses initiatives d’automatisation et d’identifier les types de cas, par fournisseur ou par région par exemple, qui traversent le système sans intervention humaine. Pourquoi c’est important Il constitue la principale mesure de l’automatisation et de l’efficacité du processus. Où les obtenir Calculé à partir de la séquence des activités et des types d’utilisateurs Exemples truefalse | |||
| Type de document DocumentType | Classe le document comptable, par exemple Vendor Invoice, Payment ou Credit Memo. | ||
| Description Le Document Type est un code à deux caractères dans SAP qui classe la transaction comptable. Les types courants comprennent « KR » pour les factures fournisseurs, « KZ » pour les paiements fournisseurs et « RE » pour la réception brute d’une facture. Il détermine la plage de numéros et le statut des champs du document. Dans l’analyse, cet attribut sert à filtrer le périmètre du processus. Par exemple, un analyste peut vouloir exclure les Credit Memos afin de se concentrer uniquement sur l’efficacité des paiements sortants. Il aide également à identifier la répartition des types de transactions traités et contribue au Dashboard Process Variant Complexity. Pourquoi c’est important Il catégorise le cas, facture ou avoir, et permet une analyse filtrée. Où les obtenir Table SAP BKPF, champ BLART Exemples KRREKZKG | |||
| Date de référence BaselineDate | Date à partir de laquelle les conditions de paiement s’appliquent et les échéances sont calculées. | ||
| Description La date de référence constitue le point de départ du calcul de la date d’échéance nette et des périodes d’escompte. Il s’agit généralement de la date de facture ou de la date de comptabilisation, selon la configuration et les données de base du fournisseur. Dans l’analyse, cette date est une condition technique préalable au calcul du statut « En retard ». Les erreurs de date de référence entraînent souvent des paiements anticipés, avec un impact sur la trésorerie, ou des paiements tardifs, avec un risque de pénalités. La vérification de son exactitude fait partie de l’analyse de la conformité aux conditions de paiement des fournisseurs. Pourquoi c’est important Elle constitue le point de référence de tous les calculs d’échéance. Où les obtenir Champ ZFBDT de la table SAP BSEG Exemples 2023-10-012023-10-15 | |||
| Devise Currency | Code devise associé au montant de la facture. | ||
| Description L’attribut Currency précise la devise de l’Invoice Amount, par exemple USD, EUR ou GBP. Il permet d’interpréter correctement les valeurs financières et est indispensable pour agréger les données de plusieurs Company Codes internationaux. Dans l’analyse, ce champ garantit le calcul correct des KPI financiers. Il est souvent utilisé pour convertir les montants dans une devise de reporting destinée aux Dashboards internationaux. Sans cet attribut, des indicateurs agrégés tels que les dépenses totales ou la valeur moyenne des factures seraient dépourvus de sens dans un environnement multidevise. Pourquoi c’est important Il fournit le contexte des montants financiers, indispensable à un reporting international précis. Où les obtenir Table SAP BKPF, champ WAERS Exemples USDEURGBPJPY | |||
| Document d’achat PurchasingDocument | Numéro du bon de commande associé à la facture. | ||
| Description Cet attribut relie la facture au processus d’achat en amont. Il contient le numéro du bon de commande (PO) auquel la facture est rapprochée. Toutes les factures, notamment celles correspondant à des dépenses diverses, ne comportent pas nécessairement de référence à un bon de commande. Dans l’analyse, ce champ est essentiel à l’analyse du taux de rapprochement à trois niveaux. Il permet aux analystes de distinguer les factures associées à un bon de commande des factures sans bon de commande, qui suivent généralement des flux de travail d’approbation très différents. Il facilite également le Process Mining de bout en bout en reliant les données des comptes fournisseurs aux données des achats. Pourquoi c’est important Il relie la comptabilité fournisseurs aux achats, ce qui permet d’analyser le rapprochement à trois niveaux et d’étendre le processus. Où les obtenir Champ EBELN de la table SAP BSEG Exemples 45000012344500009876 | |||
| Exercice fiscal FiscalYear | Exercice financier auquel la facture est rattachée. | ||
| Description L’exercice fiscal est une période utilisée pour le reporting financier. Avec le code société et le numéro de document, il constitue la clé primaire composite d’un document financier dans SAP. Dans l’analyse, il est indispensable pour identifier chaque cas de manière unique, tout en permettant les comparaisons d’une année sur l’autre. Il garantit que l’identifiant de cas « Numéro de facture » reste unique sur plusieurs décennies d’historique. Pourquoi c’est important Exigence technique pour identifier chaque cas de manière unique dans SAP FI. Où les obtenir Champ GJAHR de la table SAP BKPF Exemples 20232024 | |||
| Montant d’escompte perdu DiscountLostAmount | Valeur monétaire des escomptes disponibles mais non obtenus. | ||
| Description Cet attribut calculé représente le « montant perdu ». Il est obtenu en vérifiant si le paiement a été effectué après la date limite d’escompte et, le cas échéant, en calculant la valeur de l’escompte non obtenu appliqué au montant de la facture. Dans l’analyse, il s’agit d’un indicateur financier important pour l’optimisation des escomptes pour paiement anticipé. Il quantifie le coût des inefficacités en valeur monétaire et fournit un argument économique solide en faveur de l’amélioration des processus. Pourquoi c’est important Il quantifie la perte financière directe due aux retards du processus. Où les obtenir Calculé : si date de lettrage > date d’escompte, alors montant de la facture * pourcentage d’escompte Exemples 30.000.00150.00 | |||
| Nombre de jours d’escompte 1 CashDiscountDays1 | Nombre de jours à compter de la date de référence pendant lesquels le premier escompte est disponible. | ||
| Description Cet attribut définit la période pendant laquelle les conditions de paiement sont les plus avantageuses, par exemple « 10 » dans « 2 % à 10 jours, net à 30 jours ». Il provient des conditions enregistrées sur le poste de facture. Dans l’analyse, il aide à déterminer la « date cible » de l’optimisation des escomptes pour paiement anticipé. Si la facture est lettrée pendant cette période, l’escompte est obtenu. Ce champ permet de mesurer le coût d’opportunité des cycles de traitement trop longs. Pourquoi c’est important Il définit la période pendant laquelle des économies financières peuvent être réalisées. Où les obtenir Champ ZBD1T de la table SAP BSEG Exemples 10140 | |||
| Pourcentage d’escompte 1 CashDiscountPercentage1 | Pourcentage d’escompte disponible en cas de paiement pendant la première période d’escompte. | ||
| Description Cet attribut représente le taux d’incitation financière proposé par le fournisseur en cas de paiement anticipé, par exemple « 2 » dans « 2 % à 10 jours ». Dans l’analyse, il sert à calculer la valeur de l’« escompte potentiel ». En multipliant ce pourcentage par le montant de la facture, les Dashboards peuvent visualiser le montant total perdu en raison des inefficacités du processus et étayer le bien-fondé d’une automatisation. Pourquoi c’est important Il quantifie le taux d’économies potentiel, essentiel au calcul du ROI. Où les obtenir Champ ZBD1P de la table SAP BSEG Exemples 2.03.00.0 | |||
Activités du traitement des paiements fournisseurs
| Activité | Description | ||
|---|---|---|---|
| Blocage du paiement appliqué | Indique qu’un blocage de paiement a été défini sur le poste de facture, empêchant sa prise en compte dans l’exécution des paiements. Cette étape est identifiée en surveillant, au moyen des documents de modification, les changements apportés au champ ZLSPR de la table BSEG. | ||
| Pourquoi c’est important Les blocages sont la principale cause des retards de paiement et des difficultés dans le processus. Ils ont un impact direct sur le Dashboard Manual Payment Block Analysis. Où les obtenir Tables CDPOS et CDHDR (documents de modification), en recherchant les mises à jour du champ BSEG-ZLSPR. Collecte Enregistré lors de la modification des enregistrements CDPOS dans ZLSPR Type d’événement explicit | |||
| Blocage du paiement supprimé | Indique qu’un blocage de paiement précédemment appliqué a été levé, libérant ainsi la facture pour paiement. Cette étape est identifiée lorsque le champ ZLSPR de BSEG passe d’une valeur à une valeur nulle ou vide. | ||
| Pourquoi c’est important Sert souvent d’équivalent à « Invoice Approved » dans les systèmes dépourvus de journaux de flux de travail explicites et marque la fin de la période de blocage. Où les obtenir Tables CDPOS et CDHDR, en recherchant le passage de BSEG-ZLSPR à une valeur vide. Collecte Enregistré lors de la suppression de ZLSPR dans les enregistrements CDPOS Type d’événement explicit | |||
| Document de paiement créé | Génération du document comptable qui crédite la banque et débite le fournisseur. Ce document se trouve dans BKPF et possède un type de document de paiement, par exemple ZP ou KZ. | ||
| Pourquoi c’est important Réalisation financière du paiement, utilisée pour calculer le délai moyen de règlement fournisseurs (DPO). Où les obtenir Table BKPF, filtrée selon le type de document (BLART) propre aux paiements. Collecte Enregistré lors de la création du document de paiement BKPF Type d’événement explicit | |||
| Exécution de la campagne de paiements | Représente l’exécution du paiement, au cours de laquelle les instructions de transfert de fonds sont générées. Cette étape est suivie au moyen de la mise à jour du statut dans les tables REGUH ou REGUP. | ||
| Pourquoi c’est important Il s’agit de l’engagement opérationnel à payer, essentiel pour analyser l’efficacité du traitement des paiements par lots. Où les obtenir Table REGUH, généralement associée à la date et à l’identifiant de l’exécution. Collecte Enregistré lors de la mise à jour du statut de Payment Run Type d’événement explicit | |||
| Facture comptabilisée | Représente l’enregistrement officiel de la dette dans le grand livre. Cette activité est déduite de l’horodatage de création dans la table BKPF ou de la date d’écriture dans la table ACDOCA. | ||
| Pourquoi c’est important Il s’agit du point de départ principal de la chronologie financière, qui sert de référence pour les dates d’échéance et l’analyse de l’ancienneté des dettes. Où les obtenir Table BKPF, avec CPUDT (date de saisie) et CPUTM (heure de saisie). Collecte Enregistré lors de la création de l’enregistrement BKPF Type d’événement explicit | |||
| Paiement compensé | Marque le rapprochement final, au cours duquel le poste ouvert du compte fournisseur est soldé par le paiement. Cette étape est extraite du champ AUGDT (date de lettrage) de la table BSEG. | ||
| Pourquoi c’est important État final du processus, indiquant que le cycle est terminé et que les comptes sont équilibrés. Un taux élevé de lettrage manuel révèle des inefficacités dans le rapprochement. Où les obtenir Table BSEG, champ AUGDT (date de lettrage). Collecte Enregistré lorsque le champ AUGDT est renseigné Type d’événement explicit | |||
| Conditions de paiement modifiées | Enregistre une modification des conditions de paiement d’une facture ouverte, qui change la date d’échéance ou l’éligibilité à un escompte. Cette modification est suivie dans les journaux de changements du champ ZTERM de la table BSEG. | ||
| Pourquoi c’est important Des changements fréquents peuvent révéler des erreurs dans les données de base ou des modifications manuelles qui ont un impact sur les prévisions de trésorerie et le respect des conditions de paiement fournisseurs. Où les obtenir Tables CDPOS et CDHDR, en recherchant les mises à jour du champ BSEG-ZTERM. Collecte Enregistré lors de la modification des enregistrements CDPOS dans ZTERM Type d’événement explicit | |||
| Écart de prix détecté | Activité déduite indiquant un écart entre le prix de la facture et celui du bon de commande. Elle est identifiée par l’observation d’une Payment Block Key spécifique, généralement « R » pour la vérification de facture, appliquée automatiquement lors de la comptabilisation. | ||
| Pourquoi c’est important Identifie les causes profondes des reprises manuelles et contribue à l’analyse Three Way Match Rate. Où les obtenir Déduit de la valeur « R » de BSEG-ZLSPR, ou de la configuration propre au système pour les blocages liés au prix, au moment de la comptabilisation. Collecte Comparer la valeur de ZLSPR à « R » Type d’événement inferred | |||
| Écart de quantité détecté | Activité déduite indiquant un écart entre la quantité facturée et la quantité réceptionnée. Elle est identifiée par l’observation d’une Payment Block Key spécifique, généralement « M » pour un écart de quantité, appliquée au poste de facture. | ||
| Pourquoi c’est important Essentiel pour analyser l’efficacité du rapprochement et la qualité des données de la chaîne d’approvisionnement. Où les obtenir Déduit de la valeur « M » de BSEG-ZLSPR, ou de la configuration propre au système pour les blocages liés à la quantité. Collecte Comparer la valeur de ZLSPR à « M » Type d’événement inferred | |||
| Escompte perdu | Événement calculé marquant la date d’expiration du droit à un escompte pour paiement comptant. Il est déduit en comparant la date limite de l’escompte à la date actuelle ou à la date de paiement. | ||
| Pourquoi c’est important Essentiel pour l’optimiseur des escomptes pour paiement anticipé, qui permet de visualiser les opportunités financières perdues. Où les obtenir Calcul : BSEG-ZFBDT + BSEG-ZBD1T (jours d’escompte 1). Collecte Déduire en comparant la date à la date limite de l’escompte Type d’événement calculated | |||
| Facture arrivée à échéance | Horodatage calculé représentant le moment où la facture atteint sa date d’échéance nette. Il est obtenu en ajoutant le nombre de jours prévu par les conditions de paiement à la date de référence figurant dans la table BSEG. | ||
| Pourquoi c’est important Sert de référence pour le suivi de la performance des paiements à temps et le suivi des pénalités de retard de paiement. Où les obtenir Calcul : BSEG-ZFBDT (date de référence) + BSEG-ZBD1T/ZBD2T/ZBD3T (jours). Collecte Déduire en comparant la date actuelle à la date d’échéance nette Type d’événement calculated | |||
| Facture contrepassée | Indique que le document de facture a été contrepassé ou annulé. Cette étape est identifiée en vérifiant le champ STBLG (document de contrepassation) dans la table BKPF. | ||
| Pourquoi c’est important Représente une reprise et un échec du processus, en mettant en évidence le gaspillage et les efforts potentiellement redondants. Où les obtenir Table BKPF, champ STBLG non vide. Collecte Enregistré lorsque le champ STBLG est renseigné Type d’événement explicit | |||
| Facture mise en attente | Indique qu’une facture a été saisie dans SAP, mais pas encore comptabilisée dans le grand livre, généralement lors de la saisie préliminaire des données. Cette étape est identifiée explicitement dans la table VBKPF ou par la détection, dans BKPF, de documents présentant un code de statut « parked » avant leur comptabilisation. | ||
| Pourquoi c’est important La mise en attente marque le début de la phase de saisie et permet de mesurer le délai entre la réception de la facture et la constatation de l’obligation financière. Où les obtenir Table VBKPF pour les données d’en-tête des documents mis en attente, ou table BKPF avec un statut de document spécifique (BSTAT = V). Collecte Enregistré lors de la création de l’entrée VBKPF Type d’événement explicit | |||
| Proposition de paiement créée | Indique que la facture a été incluse dans une exécution de proposition de paiement (F110), première étape du programme de paiement automatisé. Cette information est extraite de la table REGUH, qui contient les données de règlement. | ||
| Pourquoi c’est important Indique que la facture a été sélectionnée pour paiement et a passé les contrôles de validation du programme de paiement. Où les obtenir Horodatage de création dans la table REGUH, avec les clés LAUFD et LAUFI. Collecte Enregistré lors de la création de l’enregistrement REGUH Type d’événement explicit | |||
Guides d’extraction
Étapes
Identifier les vues CDS requises : vérifiez la disponibilité des vues CDS standard de SAP S/4HANA. Les principales vues nécessaires sont I_JournalEntry (en-tête), I_OperationalAcctgDocItem (postes, équivalent de BSEG), I_SupplierInvoice (logistique), I_PaymentProposalItem (F110) et I_ChangeDocument (journaux).
Configurer les autorisations utilisateur : assurez-vous que l’utilisateur de base de données ou l’utilisateur de service technique dispose des privilèges SELECT sur les vues SQL DDL associées aux entités CDS. Cette configuration est généralement gérée dans SAP HANA Studio ou dans les outils de développement ABAP pour Eclipse (ADT).
Préparer l’environnement SQL : ouvrez votre interface SQL, par exemple SAP HANA Studio, DBeaver connecté à HANA ou un connecteur de Process Mining acceptant SQL. Cette méthode suppose un accès SQL direct à la couche HANA où les vues CDS sont exposées sous forme de vues.
Définir le périmètre : déterminez le code société (CompanyCode) et la période d’exercice afin de limiter le volume de données. Cette étape est essentielle pour les performances lors de l’interrogation de la vue des postes de documents de comptabilité opérationnelle.
Implémenter la logique des activités : copiez la requête SQL fournie ci-dessous. Elle utilise UNION ALL pour combiner 14 blocs logiques distincts dans une structure unique de journal d’événements. Chaque bloc cible une activité précise, par exemple « Facture comptabilisée » ou « Paiement lettré ».
Gérer les documents de modification : la requête comprend des sections consacrées aux modifications des conditions de paiement et à la gestion des blocages. Elles reposent sur la vue I_ChangeDocument. Si cette vue n’est pas active dans votre version de S/4, vous devrez peut-être encapsuler les tables sous-jacentes (CDHDR/CDPOS) dans une vue CDS personnalisée.
Traiter les événements calculés : examinez la logique de « Facture arrivée à échéance » et de « Escompte perdu ». Ces événements sont calculés en ajoutant un nombre de jours à la date de référence présente dans la vue des postes opérationnels.
Exécuter l’extraction : lancez la requête. Pour les volumes importants, il est vivement recommandé de répartir l’extraction par exercice ou par code société afin d’éviter les dépassements de mémoire.
Vérifier les formats de date : assurez-vous que la colonne EventTime est au format YYYY-MM-DD HH:MM:SS. SAP HANA SQL renvoie des horodatages qui peuvent nécessiter une conversion selon l’application cible.
Exporter les données : enregistrez le résultat dans un fichier CSV ou Parquet. Vérifiez que les en-têtes correspondent aux colonnes définies dans l’instruction SELECT finale.
Transformer les données avant importation : si votre outil de Process Mining exige un format CSV spécifique, par exemple un formatage particulier des dates, appliquez ces transformations dans un script de post-traitement ou dans SQL à l’aide des fonctions TO_VARCHAR.
Effectuer la validation finale : chargez un échantillon dans ProcessMind et vérifiez que l’identifiant de cas (numéro de facture) regroupe correctement toutes les activités, de la comptabilisation au lettrage.
Configuration
- Filtre sur le code société : limitez la requête à certaines unités organisationnelles (CompanyCode = '1000') afin de préserver le contexte et les performances.
- Période : appliquez un filtre sur PostingDate ou CreationDate, par exemple les 12 derniers mois, afin de maîtriser le volume de données.
- Type de compte : filtrez I_OperationalAcctgDocItem sur FinancialAccountType = 'K' (fournisseur) afin d’exclure les postes du grand livre et des clients.
- Activation des vues CDS : vérifiez que les vues I_JournalEntry, I_OperationalAcctgDocItem et I_PaymentProposalItem sont actives et disponibles pour un accès SQL.
- Performances du journal des modifications : l’interrogation de I_ChangeDocument peut mobiliser beaucoup de ressources. Limitez ces sous-requêtes à ObjectClass « BELEG » et à des noms de champs précis tels que ZLSPR et ZTERM.
a Exemple de requête sql
/* SAP S/4HANA CDS View Extraction for Accounts Payable */
/* Combined Event Log Query */
/* 1. Invoice Parked */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Parked' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JE.CreationDateTime > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
'False' AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K' -- Vendor
AND JE.AccountingDocumentCategory = 'V' -- Parked Document
UNION ALL
/* 2. Invoice Posted */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Posted' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
'False' AS IsLatePayment,
CASE WHEN JE.CreatedByUser = 'BATCH_USER' THEN 'True' ELSE 'False' END AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.AccountingDocumentCategory <> 'V' -- Exclude Parked
UNION ALL
/* 3. Price Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Price Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'R' -- Standard SAP Price Variance Block Key
UNION ALL
/* 4. Quantity Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Quantity Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'M' -- Standard SAP Quantity Variance Block Key
UNION ALL
/* 5. Payment Block Applied (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Applied' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
CD.NewValue AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NULL AND CD.NewValue IS NOT NULL
UNION ALL
/* 6. Payment Block Removed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Removed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NOT NULL AND (CD.NewValue IS NULL OR CD.NewValue = '')
UNION ALL
/* 7. Payment Terms Changed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Terms Changed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
CD.NewValue AS PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZTERM'
UNION ALL
/* 8. Invoice Due (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Due' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) < CURRENT_DATE
UNION ALL
/* 9. Cash Discount Lost (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Cash Discount Lost' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.CashDiscount1Days > 0
AND (JEItem.ClearingDate IS NULL OR JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days)))
UNION ALL
/* 10. Payment Proposal Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Proposal Created' AS Activity,
PPI.ProposalRunDate AS EventTime, -- Often just a date, cast to timestamp if needed
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
AND PPI.FiscalYear = JE.FiscalYear
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JEItem.FinancialAccountType = 'K'
UNION ALL
/* 11. Payment Run Executed */
/* Derived from existence in payment tables with a run ID */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Run Executed' AS Activity,
PPI.PaymentRunDate AS EventTime,
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
WHERE PPI.PaymentRunID IS NOT NULL
UNION ALL
/* 12. Payment Document Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Document Created' AS Activity,
PayJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
PayJE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PayJE.CreatedByUser AS UserName,
PayJE.PostingDate AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS PayJE
ON JEItem.ClearingJournalEntry = PayJE.AccountingDocument
AND JEItem.ClearingJournalEntryFiscalYear = PayJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingJournalEntry IS NOT NULL
UNION ALL
/* 13. Payment Cleared */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Cleared' AS Activity,
TO_TIMESTAMP(JEItem.ClearingDate) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
JEItem.ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingDate IS NOT NULL
UNION ALL
/* 14. Invoice Reversed */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Reversed' AS Activity,
RevJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
RevJE.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS RevJE
ON JE.ReverseDocument = RevJE.AccountingDocument
AND JE.ReverseDocumentFiscalYear = RevJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.ReverseDocument IS NOT NULL Étapes
- Vérifiez que l’accès SQL direct au schéma SAP HANA contenant ACDOCA, BKPF, BSEG, VBKPF, REGUH, REGUP et les tables de documents de modification concernées est disponible. Remplacez [Your SAP HANA schema] et les informations de connexion par les valeurs approuvées pour votre système.
- Confirmez la population de factures et la période de reporting. Définissez [Start date] et [End date] au format YYYYMMDD, puis configurez [Company code filter] comme prédicat SQL valide, par exemple BUKRS IN ('1000','2000').
- Validez la version SAP et la configuration locale concernant les documents préenregistrés, les statuts du programme de paiement, les types de documents de paiement et le stockage des documents de modification. La requête utilise des objets sources documentés et des correspondances de champs prudentes, mais les extensions locales et les différences de version doivent être vérifiées avant toute utilisation en production.
- Exécutez la requête sur SAP HANA à l’aide d’un client SQL ou d’un service d’extraction approuvé. La requête crée une ligne d’événement pour chaque activité explicitement extraite. ProcessMind ne déduira pas les activités absentes du résultat.
- Examinez les données sources et ajustez les prédicats de configuration signalés pour le statut de préenregistrement, les types de documents de paiement, le statut des propositions et des exécutions de paiement, ainsi que les classes d’objets des documents de modification. N’élargissez pas ces prédicats sans vérifier les doublons et les documents comptables sans rapport.
- Validez les jointures à l’aide de InvoiceNumber, CompanyCode, de l’exercice, du numéro de document comptable, du numéro de fournisseur et du poste lorsque cela s’applique. Vérifiez que les numéros de document de facture sont représentés de manière cohérente dans BKPF, BSEG, ACDOCA, REGUH et REGUP du système cible.
- Rapprochez les événements calculés. « Facture arrivée à échéance » est généré à la date d’échéance nette calculée, tandis que « Escompte perdu » est généré à la première date limite d’escompte applicable lorsqu’aucun paiement n’a été effectué avant cette échéance. Ces lignes dérivées doivent être clairement distinguées des événements issus des enregistrements sources.
- Exportez le résultat dans un fichier CSV UTF-8 plat ou dans un autre format tabulaire pris en charge par ProcessMind. Conservez exactement les noms de colonnes InvoiceNumber, Activity, EventTime, SourceSystem et LastDataUpdate. Conservez une ligne par événement et n’agrégez pas les activités par facture.
- Importez le journal d’événements dans ProcessMind, mappez InvoiceNumber comme identifiant de cas, Activity comme nom de l’activité et EventTime comme horodatage de l’événement. Mappez les autres colonnes comme attributs d’événement ou de cas selon la configuration d’importation de ProcessMind.
Configuration
- Période : utilisez une période glissante de 3 à 6 mois pour la première extraction. Appliquez de manière cohérente les prédicats relatifs à la date de comptabilisation, à la date de modification et à la date du programme de paiement, puis élargissez la période lors de la validation de conditions de paiement longues.
- Schéma : remplacez [Your SAP HANA schema] par le schéma propriétaire des objets SAP. Vérifiez si l’environnement expose les objets dépendants du mandant via le schéma sélectionné ou exige un prédicat explicite sur le mandant.
- Filtrage par société : configurez [Company code filter] afin de limiter BUKRS aux codes société requis. Appliquez le même périmètre à BKPF, BSEG, ACDOCA, REGUH, REGUP et aux sources de documents de modification lorsque ces champs sont disponibles.
- Filtrage des documents : examinez le prédicat sur les types de documents de facture et celui sur les types de documents de paiement. La requête contient des exemples courants, mais les types de documents sont configurables et doivent correspondre au système cible.
- Factures préenregistrées : vérifiez la représentation du statut des documents préenregistrés dans VBKPF ou BKPF. La requête utilise un prédicat configurable, car le codage de ce statut peut varier selon la version et l’implémentation.
- Modifications des paiements : vérifiez la classe d’objet, le nom de table, les noms de champs et la représentation des valeurs pour BSEG-ZLSPR et BSEG-ZTERM dans les documents de modification. Le stockage des documents de modification et le nommage des champs doivent être vérifiés dans le système cible.
- Programme de paiement : vérifiez les champs REGUH et REGUP utilisés pour le statut de la proposition et de l’exécution, la date d’exécution, l’identifiant d’exécution et le lien avec le document comptable. La configuration locale du programme de paiement peut modifier les valeurs de statut disponibles.
- Performances : limitez la période et les codes société, ne sélectionnez que les colonnes nécessaires et appliquez les filtres propres aux sources avant les jointures. Pour les volumes importants, matérialisez des sous-ensembles filtrés ou utilisez une vue de calcul HANA ou un schéma d’extraction approuvé.
- Autorisations : l’accès requis comprend les autorisations de lecture sur les objets du schéma SAP HANA concernés et sur les vues exposant les données comptables, du programme de paiement et des documents de modification. Coordonnez cette configuration avec les équipes chargées de la sécurité SAP et de la gouvernance des données.
- Prérequis fonctionnels : les fonctionnalités de comptabilité financière, de comptabilité fournisseurs, de programme de paiement et de documents de modification concernées doivent être actives et alimentées. Si une table source n’est pas utilisée dans l’implémentation, configurez un remplacement approuvé conforme à l’architecture du système.
- Gestion des horodatages : BKPF et BSEG fournissent généralement les dates et les heures dans des champs distincts. La requête les combine pour former un horodatage. Vérifiez le fuseau horaire du système source et appliquez la conversion requise avant l’importation dans ProcessMind.
- Protection des données : limitez les données fournisseurs et comptables au périmètre approuvé et appliquez les politiques de conservation, de masquage et d’accès de l’organisation.
a Exemple de requête sql
WITH
params AS (
SELECT
TO_DATE('[Start date]', 'YYYYMMDD') AS start_date,
TO_DATE('[End date]', 'YYYYMMDD') AS end_date,
'[Source system identifier]' AS source_system
FROM DUMMY
),
base_bkpf AS (
SELECT
b.MANDT,
b.BUKRS,
b.BELNR,
b.GJAHR,
b.BLART,
b.BLDAT,
b.BUDAT,
b.CPUDT,
b.CPUTM,
b.USNAM,
b.STBLG,
b.STJAH,
b.XBLNR,
b.WAERS,
b.BKTXT,
p.source_system,
p.start_date,
p.end_date
FROM [Your SAP HANA schema].BKPF b
CROSS JOIN params p
WHERE b.BUDAT BETWEEN TO_VARCHAR(p.start_date, 'YYYYMMDD') AND TO_VARCHAR(p.end_date, 'YYYYMMDD')
AND [Company code filter]
),
invoice_bseg AS (
SELECT
k.MANDT,
k.BUKRS,
k.BELNR,
k.GJAHR,
k.BLART,
k.BLDAT,
k.BUDAT,
k.CPUDT,
k.CPUTM,
k.USNAM,
k.STBLG,
k.STJAH,
k.XBLNR,
k.WAERS,
k.BKTXT,
k.source_system,
s.BUZEI,
s.LIFNR,
s.WRBTR,
s.DMBTR,
s.ZTERM,
s.ZLSPR,
s.ZFBDT,
s.ZBD1T,
s.ZBD2T,
s.ZBD3T,
s.AUGDT,
s.AUGBL,
s.SHKZG,
s.SGTXT,
s.XREF1,
s.XREF2,
s.XREF3
FROM base_bkpf k
INNER JOIN [Your SAP HANA schema].BSEG s
ON s.MANDT = k.MANDT
AND s.BUKRS = k.BUKRS
AND s.BELNR = k.BELNR
AND s.GJAHR = k.GJAHR
WHERE s.LIFNR IS NOT NULL
AND s.LIFNR <> ''
),
acdoca_invoice AS (
SELECT
a.RCLNT AS MANDT,
a.RBUKRS AS BUKRS,
a.BELNR,
a.GJAHR,
a.BUZEI,
a.RACCT,
a.HSL,
a.WSL,
a.RWCUR,
a.BUDAT,
a.BLDAT,
a.AUGDT,
a.AUGBL
FROM [Your SAP HANA schema].ACDOCA a
WHERE a.BUDAT BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [ACDOCA company code filter]
),
invoice_cases AS (
SELECT DISTINCT
i.MANDT,
i.BUKRS,
i.BELNR,
i.GJAHR,
i.BUZEI,
i.LIFNR,
i.WRBTR,
i.ZTERM,
i.ZLSPR,
i.ZFBDT,
i.ZBD1T,
i.ZBD2T,
i.ZBD3T,
i.AUGDT,
i.AUGBL,
i.BLART,
i.BLDAT,
i.BUDAT,
i.CPUDT,
i.CPUTM,
i.USNAM,
i.STBLG,
i.STJAH,
i.XBLNR,
i.WAERS,
i.source_system,
COALESCE(NULLIF(i.XBLNR, ''), i.BELNR) AS InvoiceNumber,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD3T, '')), 0)) AS NetDueDate,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD1T, '')), 0)) AS DiscountDueDate1,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD2T, '')), 0)) AS DiscountDueDate2
FROM invoice_bseg i
LEFT JOIN acdoca_invoice a
ON a.MANDT = i.MANDT
AND a.BUKRS = i.BUKRS
AND a.BELNR = i.BELNR
AND a.GJAHR = i.GJAHR
AND a.BUZEI = i.BUZEI
),
change_events AS (
SELECT
c.MANDT,
c.OBJECTID,
c.TABKEY,
c.FNAME,
c.VALUE_OLD,
c.VALUE_NEW,
c.UDATE,
c.UTIME,
c.USERNAME
FROM [Your SAP HANA schema].[Your change document item table name] c
WHERE c.TABNAME = 'BSEG'
AND c.FNAME IN ('ZLSPR', 'ZTERM')
AND c.UDATE BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [Change document object class filter]
),
reguh_events AS (
SELECT
r.MANDT,
r.LAUFD,
r.LAUFI,
r.XVORL,
r.ZBUKR,
r.LIFNR,
r.VBLNR,
r.AUSFD,
r.AUSDT,
r.LAUFD AS RunDate,
r.ZALDT,
r.RZAWE,
r.XEINZ,
r.XPGRO,
r.XAVIS,
r.XVORL AS ProposalIndicator
FROM [Your SAP HANA schema].REGUH r
WHERE r.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
regup_events AS (
SELECT
u.MANDT,
u.LAUFD,
u.LAUFI,
u.ZBUKR,
u.LIFNR,
u.VBLNR,
u.BUKRS,
u.BELNR,
u.GJAHR,
u.BUZEI,
u.XVORL,
u.AUGBL,
u.AUGDT
FROM [Your SAP HANA schema].REGUP u
WHERE u.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Parked' AS Activity,
TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
i.source_system AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
i.LIFNR AS VendorNumber,
i.BUKRS AS CompanyCode,
i.WRBTR AS InvoiceAmount,
i.BLART AS DocumentType,
i.ZTERM AS PaymentTerms,
i.ZLSPR AS PaymentBlockReason,
i.USNAM AS UserName,
i.AUGDT AS ClearingDate,
i.NetDueDate,
CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END AS IsLatePayment,
FALSE AS IsTouchless
FROM invoice_cases i
INNER JOIN [Your SAP HANA schema].VBKPF v
ON v.MANDT = i.MANDT
AND v.BUKRS = i.BUKRS
AND v.BELNR = i.BELNR
AND v.GJAHR = i.GJAHR
WHERE [VBKPF parked status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Posted', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Applied', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_NEW, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') = '' AND COALESCE(c.VALUE_NEW, '') <> ''
UNION ALL
SELECT i.InvoiceNumber, 'Price Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'R'
UNION ALL
SELECT i.InvoiceNumber, 'Quantity Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'M'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Terms Changed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, c.VALUE_NEW, i.ZLSPR, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZTERM'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Removed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_OLD, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') <> '' AND COALESCE(c.VALUE_NEW, '') = ''
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Due', TO_TIMESTAMP(TO_VARCHAR(i.NetDueDate, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.NetDueDate IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Cash Discount Lost', TO_TIMESTAMP(TO_VARCHAR(CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NULL OR i.AUGDT > CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END
UNION ALL
SELECT i.InvoiceNumber, 'Payment Proposal Created', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment proposal status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Run Executed', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment run executed status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Document Created', TO_TIMESTAMP(p.CPUDT || LPAD(COALESCE(p.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, p.BLART, i.ZTERM, i.ZLSPR, p.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN [Your SAP HANA schema].BKPF p ON p.MANDT = i.MANDT AND p.BUKRS = i.BUKRS AND p.BELNR = i.AUGBL AND p.GJAHR = i.GJAHR WHERE p.BLART IN ('ZP', 'KZ')
UNION ALL
SELECT i.InvoiceNumber, 'Payment Cleared', TO_TIMESTAMP(i.AUGDT || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Reversed', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.STBLG IS NOT NULL AND i.STBLG <> ''
)
SELECT
InvoiceNumber,
Activity,
EventTime,
SourceSystem,
LastDataUpdate,
VendorNumber,
CompanyCode,
InvoiceAmount,
DocumentType,
PaymentTerms,
PaymentBlockReason,
UserName,
ClearingDate,
NetDueDate,
IsLatePayment,
IsTouchless
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, Activity; Prêt à commencer ?
Transformez vos données financières en analyses concrètes et commencez dès aujourd’hui à optimiser vos cycles de paiement. Notre équipe vous accompagne à chaque étape de votre parcours de Process Mining.
Optimisez le traitement des paiements fournisseurs dans SAP S/4HANA
Éliminez les goulots d’étranglement et réduisez votre temps de cycle de 30 %.
Aucune carte bancaire requise. Configuration en 5 minutes.