Votre modèle de données pour le traitement des paiements de factures fournisseurs
Votre modèle de données pour le traitement des paiements de factures fournisseurs
- Attributs clés pour l’analyse des fournisseurs et des paiements
- Principales étapes du cycle de paiement
- Logique d’extraction spécifique aux systèmes SAP S/4HANA
Attributs du traitement des paiements de factures fournisseurs
| Nom | Description | ||
|---|---|---|---|
| Activité Activity | Tâche précise ou changement de statut de l’événement enregistré pour la facture. | ||
| Description Cet attribut représente les différentes étapes du processus au cours du cycle de vie de la facture. Il recense des événements tels que la création, la comptabilisation et le blocage de la facture, son approbation et la compensation du paiement. Les noms des activités sont issus des codes de transaction, des entrées du journal des modifications ou des mises à jour de statut du flux de travail dans le système source. Pour l’analyse, ce champ est essentiel à la représentation des variantes du processus. Le moteur de Process Mining s’en sert pour visualiser l’ordre des étapes, repérer les boucles de reprise et déterminer les écarts par rapport au parcours nominal. Il constitue l’élément central du journal d’événements. Pourquoi est-ce important ? Il définit les nœuds de la cartographie du processus et permet de visualiser le flux de travail et les goulots d’étranglement. Où trouver ces données Dérivé des codes de transaction (TCODE) ou de l’en-tête (CDHDR) et des postes (CDPOS) du document de modification Exemples Facture comptabiliséeBlocage de paiement appliquéExécution du cycle de paiementFacture compensée | |||
| Heure de l’événement EventTime | Horodatage exact de l’activité. | ||
| Description L’heure de l’événement indique la date et l’heure précises auxquelles l’activité a été enregistrée dans la base de données SAP. Elle fournit la dimension temporelle nécessaire pour ordonner les événements d’un cas. Cet horodatage est généralement constitué à partir des champs de date et d’heure CPU des journaux système ou des en-têtes de document. Dans l’analyse, cet attribut est indispensable au calcul des temps de cycle, des durées et du débit. Il permet de mesurer le temps écoulé entre les étapes, par exemple entre la réception d’une facture et son approbation finale. Ces mesures aident à repérer les goulots d’étranglement et à évaluer les KPI, comme le temps moyen d’approbation des factures. Pourquoi est-ce important ? Il établit l’ordre chronologique des événements et sert de base à tous les calculs de performance liés au temps. Où trouver ces données Table SAP BKPF, champs CPUDT (date de saisie) et CPUTM (heure de saisie), ou table CDHDR, champs UDATE et UTIME 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 Le numéro de facture est la clé principale qui permet de suivre le cycle de vie d’un poste fournisseur dans SAP S/4HANA. Il s’agit précisément du numéro de document comptable généré lors de la comptabilisation de la facture dans le grand livre. Dans la terminologie SAP standard, il correspond au numéro de document (BELNR), associé à un code société et à un exercice fiscal donnés. Dans l’analyse des processus, cet attribut sert d’ID de cas. Il relie toutes les activités, depuis la réception et la mise en attente initiales de la facture jusqu’au paiement final et à sa compensation, en passant par les différents blocages et modifications liés à l’approbation. Le regroupement des événements selon cet identifiant permet de reconstituer l’historique complet de chaque obligation de paiement. Pourquoi est-ce important ? Il sert d’ID de cas de référence et permet de reconstituer le flux de paiement de bout en bout. Où trouver ces données Table SAP BKPF (en-tête du document comptable), champ BELNR, ou table ACDOCA, champ BELNR Exemples 1900000523510000289119000006015100003002 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage de la dernière extraction ou actualisation de l’enregistrement. | ||
| Description La dernière mise à jour des données indique à quel moment celles-ci ont été chargées avec succès dans la plateforme de Process Mining. Elle ne correspond pas à l’heure de l’événement métier, mais à la fraîcheur du jeu de données. Cette information est essentielle pour que les utilisateurs puissent se fier aux analyses des Dashboards. Dans l’analyse, cet attribut permet de connaître l’actualité des informations affichées. Il est particulièrement important pour le suivi de Dashboards quasi en temps réel, comme l’analyse des blocages de paiement, afin que les décisions reposent sur l’état le plus récent du système SAP S/4HANA. Pourquoi est-ce important ? Il renseigne les utilisateurs sur l’actualité des données, un point essentiel pour les Dashboards opérationnels. Où trouver ces données Généré par le processus ETL ou 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 proviennent les données. | ||
| Description Cet attribut identifie l’installation ERP ou le client dont les données de processus ont été extraites. Lorsque plusieurs instances SAP ou systèmes hérités fonctionnent en parallèle, ce champ assure la traçabilité des données et permet de comparer les systèmes. Dans l’analyse, ce champ sert de filtre général. Il aide à isoler les données pour comparer les performances de différentes installations régionales ou vérifier leur cohérence lors d’une migration. Il permet aussi de tenir compte de la configuration système lorsqu’on analyse les variations du processus. Pourquoi est-ce important ? Il distingue les sources de données dans les environnements multisystèmes et permet une segmentation précise. Où trouver ces données ID système (SY-SYSID) de l’installation SAP Exemples SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Code société CompanyCode | Unité organisationnelle pour laquelle sont établis le bilan et le compte de résultat. | ||
| Description Le code société représente l’entité comptable indépendante au sein de l’entreprise. Unité centrale de la comptabilité externe, il sert à structurer les données financières. Chaque facture est rattachée à un seul code société. Dans l’analyse, cet attribut permet de segmenter les KPI par entité juridique ou par région. Les Dashboards s’en servent pour comparer l’efficacité des équipes fournisseurs des différentes filiales. Il peut, par exemple, aider à repérer une succursale où les blocages manuels de paiement sont plus fréquents que dans l’ensemble de l’entreprise. Pourquoi est-ce important ? Il segmente le processus par entité juridique et facilite les comparaisons internes. Où trouver ces données Table SAP BKPF, champ BUKRS Exemples US01DE1010002000 | |||
| Conditions de paiement PaymentTerms | Code correspondant aux conditions de paiement et d’escompte convenues. | ||
| Description Les conditions de paiement définissent la date d’échéance d’une facture et les éventuels escomptes accordés en cas de paiement anticipé. Ce code (par exemple, « Z001 ») correspond à des règles telles que « net à 30 jours » ou « 2 % à 10 jours, net à 30 jours ». Il est repris des données de référence du fournisseur dans la facture, mais peut être modifié manuellement. Dans l’analyse, cet attribut est au cœur des Dashboards d’optimisation des escomptes pour paiement anticipé et de conformité des conditions de paiement fournisseurs. Il permet de calculer la date d’échéance de référence et de vérifier si le paiement a été effectué dans le délai optimal pour bénéficier des économies. Pourquoi est-ce important ? Il détermine les délais prévus et les avantages financiers, essentiels à l’analyse des escomptes. Où trouver ces données Table SAP BSEG, champ ZTERM Exemples Z001NT300001 | |||
| Date d’échéance nette NetDueDate | Date limite à laquelle la facture doit être payée pour éviter les pénalités. | ||
| Description La date d’échéance nette est la date limite finale de paiement. Elle est calculée en ajoutant le nombre maximal de jours de paiement à la date de référence. Elle est parfois enregistrée explicitement, mais figure souvent dans les vues d’analyse sous forme de champ calculé. Dans l’analyse, elle sert de référence principale au suivi des retards de paiement et des pénalités. La comparaison entre la date de compensation réelle et la date d’échéance nette permet de calculer le nombre de jours de retard. Cet indicateur aide à évaluer l’efficacité de l’équipe des comptes fournisseurs et le risque de tensions avec les fournisseurs. Pourquoi est-ce important ? Elle fixe la date limite du processus. La dépasser peut nuire à la cote de crédit et entraîner des coûts. Où trouver ces données Calcul : date de référence + nombre maximal de jours de paiement (ZBD1T/ZBD2T/ZBD3T) Exemples 2023-11-302023-12-01 | |||
| Date de compensation ClearingDate | Date à laquelle le paiement a compensé la facture. | ||
| Description La date de compensation indique à quel moment le poste ouvert du grand livre auxiliaire des fournisseurs a été soldé, généralement lors d’un cycle de paiement ou de la comptabilisation manuelle d’un paiement. Elle marque ainsi la fin de la dette. Dans l’analyse, cet attribut sert à calculer le temps de cycle total du processus. Il fournit l’horodatage de l’activité « Paiement compensé » et est comparé à la date d’échéance nette pour évaluer le respect des délais de paiement. Il alimente directement le Dashboard d’efficacité de la compensation des paiements. Pourquoi est-ce important ? Il marque la fin du processus de paiement et permet d’évaluer le respect des délais. Où trouver ces données Table SAP BSEG, champ 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 indique la valeur financière de la facture telle qu’elle figure dans le document source. Il représente la dette à régler au fournisseur. Dans SAP S/4HANA, cette valeur est généralement enregistrée dans le champ du montant en devise du document. Dans l’analyse, le montant de la facture sert à hiérarchiser les tâches. Des Dashboards comme la répartition des interventions manuelles utilisent ce champ pour repérer les efforts manuels importants consacrés à des factures de faible valeur. L’entreprise peut ainsi concentrer ses efforts d’optimisation sur les transactions de montant élevé, pour lesquelles les défaillances du processus présentent un risque financier plus important. Pourquoi est-ce important ? Il indique le poids financier du cas et aide à prioriser les inefficacités des processus portant sur des montants élevés. Où trouver ces données Table SAP BKPF ou BSEG, champ WRBTR Exemples 1500.00250.5010000.00 | |||
| Motif du blocage de paiement PaymentBlockReason | Code indiquant pourquoi une facture est bloquée pour paiement. | ||
| Description Cet attribut contient le code du motif de blocage appliqué à une facture, qui empêche le cycle de paiement automatique de la sélectionner. Il peut s’agir, par exemple, du code « A » pour un blocage de paiement, de « R » pour la vérification de facture ou d’un blocage manuel défini par un utilisateur. Dans l’analyse, ce champ est le principal indicateur du Dashboard d’analyse des blocages manuels de paiement. En regroupant les différents motifs de blocage, l’entreprise peut diagnostiquer les problèmes récurrents, comme les écarts de prix fréquents ou les réceptions de marchandises manquantes, qui retardent le processus de paiement. Pourquoi est-ce important ? Il identifie la cause précise des arrêts du processus et permet d’en analyser les causes profondes de manière ciblée. Où trouver ces données Table SAP BSEG, champ ZLSPR Exemples ABR* | |||
| Nom d’utilisateur UserName | ID de l’utilisateur ayant effectué l’activité. | ||
| Description Le nom d’utilisateur indique l’identifiant de connexion de la personne ou du compte système responsable d’une étape du processus. Il peut s’agir d’un utilisateur qui saisit des données manuellement ou d’un identifiant de traitement en arrière-plan (par exemple, « BATCH_USER ») qui exécute 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 degré d’automatisation du processus. Le Dashboard de répartition des interventions manuelles s’en sert également pour évaluer la charge de travail des équipes. Pourquoi est-ce important ? Il distingue les tâches manuelles des tâches automatisées et permet de calculer le taux d’automatisation. Où trouver ces données 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 numéro de fournisseur correspond au compte créditeur dans le grand livre auxiliaire SAP. Il relie la facture aux données de référence contenant les conditions de paiement, les coordonnées bancaires et les informations de contact. Dans S/4HANA, il est souvent associé au concept de partenaire commercial, mais conserve dans de nombreuses tables le nom de champ historique LIFNR. Dans l’analyse, cet attribut est fondamental pour le Dashboard de conformité des conditions de paiement fournisseurs. Il permet d’agréger les performances du processus par fournisseur et de repérer ceux qui provoquent régulièrement des blocages, des écarts de prix ou des retards. Il contribue aux décisions d’approvisionnement stratégique et à la gestion des relations fournisseurs. Pourquoi est-ce important ? Il permet d’agréger les performances par fournisseur et d’identifier les causes profondes des retards. Où trouver ces données 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é renvoie « vrai » si la date de compensation est postérieure à la date d’échéance nette. Il permet de classer les performances du processus en deux catégories. Lors de l’analyse, cet indicateur sert à compter les cas non conformes pour le KPI de fréquence des pénalités de retard de paiement. Il simplifie la création de Dashboards : il suffit de compter les valeurs « Vrai », sans effectuer de calculs complexes sur les dates dans la couche de visualisation. Pourquoi est-ce important ? Il simplifie le calcul des KPI de respect des délais de paiement. Où trouver ces données Calcul : date de compensation > 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é à partir du flux d’événements d’un cas. Si celui-ci ne contient que des activités automatisées (par exemple, un utilisateur « system » ou certains TCODES d’arrière-plan) et aucune modification ou aucun blocage manuel, il est considéré comme traité sans intervention manuelle. Lors de l’analyse, cet attribut constitue la mesure principale 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 de repérer les types de cas (par exemple, par fournisseur ou par région) qui suivent le processus sans intervention humaine. Pourquoi est-ce important ? C’est la principale mesure de l’automatisation et de l’efficacité du processus. Où trouver ces données 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, facture fournisseur, paiement ou avoir). | ||
| Description Dans SAP, le type de document est un code à deux caractères qui classe la transaction comptable. Parmi les types courants, on trouve « KR » pour les factures fournisseurs, « KZ » pour les paiements fournisseurs et « RE » pour la réception brute de facture. Il détermine la plage de numéros et le statut des champs du document. Dans l’analyse, cet attribut sert à définir le périmètre du processus. Un analyste peut, par exemple, exclure les avoirs pour se concentrer uniquement sur l’efficacité des paiements sortants. Il permet également de connaître la répartition des types de transactions traités et alimente le Dashboard de complexité des variantes de processus. Pourquoi est-ce important ? Il classe le cas, par exemple comme facture ou avoir, et permet de filtrer l’analyse. Où trouver ces données 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 sert de point de départ au calcul de la date d’échéance nette et des périodes d’escompte. Selon la configuration et les données de référence du fournisseur, il s’agit généralement de la date de facture ou de la date de comptabilisation. Dans l’analyse, cette date est nécessaire au calcul du statut « En retard ». Une date de référence erronée peut entraîner des paiements anticipés (avec un effet sur la trésorerie) ou tardifs (avec un risque de pénalités). La vérification de son exactitude fait partie de l’analyse de conformité des conditions de paiement fournisseurs. Pourquoi est-ce important ? Elle sert de point de départ à tous les calculs de dates d’échéance. Où trouver ces données Table SAP BSEG, champ ZFBDT Exemples 2023-10-012023-10-15 | |||
| Devise Currency | Code de la devise associée au montant de la facture. | ||
| Description L’attribut Devise précise l’unité monétaire du montant de la facture, par exemple USD, EUR ou GBP. Il permet d’interpréter correctement les valeurs financières et est indispensable pour agréger des données provenant de codes société de différents pays. Dans l’analyse, ce champ garantit l’exactitude des KPI financiers. Il sert souvent à convertir les valeurs dans une devise de reporting commune pour les Dashboards internationaux. Sans cet attribut, des indicateurs agrégés comme les dépenses totales ou le montant moyen des factures n’auraient pas de sens dans un environnement multidevise. Pourquoi est-ce important ? Il précise la devise des montants et permet d’établir des rapports internationaux exacts. Où trouver ces données Table SAP BKPF, champ WAERS Exemples USDEURGBPJPY | |||
| Document d’achat PurchasingDocument | Numéro de commande d’achat associé à la facture. | ||
| Description Cet attribut relie la facture au processus d’approvisionnement en amont. Il contient le numéro de commande d’achat (PO) auquel la facture est rapprochée. Certaines factures, par exemple celles de dépenses diverses, ne comportent pas de référence à une commande. Dans l’analyse, ce champ est essentiel à l’analyse du taux de rapprochement à trois voies. Il permet de distinguer les factures associées à une commande de celles qui ne le sont pas, car leurs flux d’approbation sont généralement très différents. Il facilite également l’analyse de bout en bout en reliant les données des comptes fournisseurs à celles des achats. Pourquoi est-ce important ? Il relie les comptes fournisseurs aux achats, ce qui permet d’analyser le rapprochement à trois voies et d’étendre l’analyse du processus. Où trouver ces données Table SAP BSEG, champ EBELN Exemples 45000012344500009876 | |||
| Exercice fiscal FiscalYear | Exercice 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 forme la clé primaire composite d’un document financier dans SAP. Dans l’analyse, il est nécessaire pour identifier les cas de manière unique et permet également de comparer les résultats d’une année sur l’autre. Il garantit que l’ID de cas « Numéro de facture » reste unique, même sur plusieurs décennies de données. Pourquoi est-ce important ? Exigence technique pour identifier de manière unique les cas dans SAP FI. Où trouver ces données Table SAP BKPF, champ GJAHR Exemples 20232024 | |||
| Montant des remises perdues DiscountLostAmount | Valeur des escomptes disponibles qui n’ont pas été obtenus. | ||
| Description Cet attribut calculé représente les économies auxquelles l’organisation a renoncé. Il est déterminé en vérifiant si le paiement a été effectué après la date limite de l’escompte et, le cas échéant, en calculant le montant de l’escompte perdu à partir du pourcentage applicable au montant de la facture. Lors de l’analyse, il s’agit d’un indicateur financier important pour l’optimisation des escomptes pour paiement anticipé. Il chiffre directement le coût des inefficacités et permet d’étayer l’analyse de rentabilité des améliorations du processus. Pourquoi est-ce important ? Il chiffre les pertes financières directement liées aux retards du processus. Où trouver ces données Calcul : si la date de compensation > date limite de l’escompte, alors montant de la facture × pourcentage de l’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 dans le poste de facture. Dans l’analyse, il permet de déterminer la date cible de l’optimisation des escomptes pour paiement anticipé. Si la facture est compensée pendant cette période, l’escompte est obtenu. Ce champ permet de mesurer le coût d’opportunité des délais de traitement. Pourquoi est-ce important ? Il définit la période pendant laquelle des économies peuvent être réalisées. Où trouver ces données Table SAP BSEG, champ ZBD1T Exemples 10140 | |||
| Pourcentage du premier escompte CashDiscountPercentage1 | Pourcentage de l’escompte accordé si le paiement est effectué pendant la première période d’escompte. | ||
| Description Cet attribut indique le taux de l’avantage financier accordé par le fournisseur en cas de paiement anticipé (par exemple, « 2 » dans « 2 % à 10 jours »). Dans l’analyse, il sert à calculer le montant de l’escompte potentiel. En multipliant ce pourcentage par le montant de la facture, les Dashboards montrent les sommes qui n’ont pas été économisées en raison des inefficacités du processus. Ces éléments étayent l’analyse de rentabilité de l’automatisation. Pourquoi est-ce important ? Il quantifie les économies potentielles et contribue au calcul du retour sur investissement. Où trouver ces données Table SAP BSEG, champ ZBD1P Exemples 2.03.00.0 | |||
Activités du traitement des paiements de factures fournisseurs
| Activité | Description | ||
|---|---|---|---|
| Blocage de paiement appliqué | Indique qu’un blocage de paiement a été appliqué au poste de facture, empêchant sa sélection lors de la campagne de paiement. Cette activité est identifiée en suivant les modifications du champ ZLSPR dans la table BSEG au moyen des documents de modification. | ||
| Pourquoi est-ce important ? Les blocages sont la principale cause des retards de paiement et des difficultés de traitement. Ils ont un effet direct sur le Dashboard d’analyse des blocages manuels de paiement. Où trouver ces données Tables CDPOS et CDHDR (documents de modification), pour repérer les mises à jour du champ BSEG-ZLSPR. Données à recueillir Enregistré lorsque les enregistrements CDPOS indiquent une modification de ZLSPR Type d’événement explicit | |||
| Blocage de paiement levé | Indique qu’un blocage de paiement précédemment appliqué a été levé, rendant ainsi la facture payable. Cette activité est identifiée lorsque le champ ZLSPR de la table BSEG passe d’une valeur à une valeur nulle ou vide. | ||
| Pourquoi est-ce important ? Dans les systèmes sans journaux de flux de travail explicites, cette activité sert souvent d’indicateur indirect de l’approbation de la facture et marque la fin de la période de blocage. Où trouver ces données Tables CDPOS et CDHDR, pour repérer le passage à vide du champ BSEG-ZLSPR. Données à recueillir Enregistré lorsque les enregistrements CDPOS indiquent la suppression de ZLSPR Type d’événement explicit | |||
| Création du document de paiement | Génération du document comptable qui crédite la banque et débite le fournisseur. Ce document figure dans BKPF et porte un type de document de paiement (par exemple, ZP, KZ). | ||
| Pourquoi est-ce important ? Réalisation financière du paiement, utilisée pour calculer le délai moyen de paiement des fournisseurs (DPO). Où trouver ces données Table BKPF, filtrée selon le type de document (BLART) propre aux paiements. Données à recueillir Enregistré lors de la création du document de paiement BKPF Type d’événement explicit | |||
| Exécution du cycle de paiement | Correspond à l’exécution du cycle de paiement, au cours duquel les instructions de virement sont générées. Cette étape est suivie au moyen de la mise à jour du statut dans les tables REGUH ou REGUP. | ||
| Pourquoi est-ce important ? Engagement opérationnel de paiement, essentiel pour analyser l’efficacité du regroupement des paiements. Où trouver ces données Table REGUH, généralement associée à la date et à l’identifiant du cycle. Données à recueillir Enregistré lors de la mise à jour du statut du cycle de paiement Type d’événement explicit | |||
| Facture comptabilisée | Correspond à l’enregistrement officiel de la dette dans le grand livre général. Cette activité est déterminée à partir de l’horodatage de création dans la table BKPF ou de la date d’écriture dans la table ACDOCA. | ||
| Pourquoi est-ce important ? Il s’agit du point de départ de la chronologie financière, qui sert de référence pour les échéances et l’analyse de l’ancienneté. Où trouver ces données Table BKPF, à partir de CPUDT (date de saisie) et CPUTM (heure de saisie). Données à recueillir Enregistré à la création de l’enregistrement dans BKPF Type d’événement explicit | |||
| Paiement compensé | Marque la compensation finale, lorsque le poste ouvert du compte fournisseur est soldé par le paiement. Cette étape est enregistrée dans le champ AUGDT (Clearing Date) de la table BSEG. | ||
| Pourquoi est-ce important ? État final du processus, qui indique que le cycle est terminé et que les comptes sont équilibrés. Un taux élevé de compensations manuelles révèle des inefficacités dans le rapprochement. Où trouver ces données Table BSEG, champ AUGDT (Clearing Date). Données à recueillir Enregistré lorsque le champ AUGDT est renseigné Type d’événement explicit | |||
| Conditions de paiement modifiées | Enregistre la modification des conditions de paiement d’une facture ouverte, qui change son échéance ou son admissibilité à une remise. Cette activité est suivie au moyen des journaux de modification du champ ZTERM dans la table BSEG. | ||
| Pourquoi est-ce important ? Des modifications fréquentes peuvent révéler des erreurs dans les données de référence ou des dérogations manuelles qui affectent les prévisions de trésorerie et le respect des conditions de paiement des fournisseurs. Où trouver ces données Tables CDPOS et CDHDR, pour repérer les mises à jour du champ BSEG-ZTERM. Données à recueillir Enregistré lorsque les enregistrements CDPOS indiquent une modification de ZTERM Type d’événement explicit | |||
| Écart de prix détecté | Activité déduite qui signale un écart entre le prix de la facture et celui de la commande d’achat. Elle est déterminée par la présence d’une clé de blocage de paiement spécifique, généralement « R » pour la vérification de facture, appliquée automatiquement lors de la comptabilisation. | ||
| Pourquoi est-ce important ? Permet d’identifier les causes des reprises manuelles et contribue à l’analyse du taux de rapprochement à trois voies. Où trouver ces données Déduit de la valeur « R » du champ BSEG-ZLSPR (ou de la configuration propre au système pour les blocages liés aux prix) au moment de la comptabilisation. Données à recueillir Comparer la valeur de ZLSPR à « R » Type d’événement inferred | |||
| Écart de quantité détecté | Activité déduite qui signale un écart entre la quantité facturée et la quantité réceptionnée. Elle est déterminée par la présence d’une clé de blocage de paiement spécifique, généralement « M » pour un écart de quantité, sur le poste de facture. | ||
| Pourquoi est-ce important ? Essentiel pour analyser l’efficacité du rapprochement et la qualité des données de la chaîne d’approvisionnement. Où trouver ces données Déduit de la valeur « M » du champ BSEG-ZLSPR (ou de la configuration propre au système pour les blocages liés aux quantités). Données à recueillir Comparer la valeur de ZLSPR à « M » Type d’événement inferred | |||
| Échéance de la facture | Horodatage calculé correspondant à la date d’échéance nette de la facture. Il est déterminé 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 est-ce important ? Sert de référence pour le suivi des paiements à temps et le suivi des pénalités de retard. Où trouver ces données Calcul : BSEG-ZFBDT (date de référence) + BSEG-ZBD1T/ZBD2T/ZBD3T (nombre de jours). Données à recueillir 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 détectée en vérifiant que le champ STBLG (Reversal Document) de la table BKPF est renseigné. | ||
| Pourquoi est-ce important ? Correspond à des reprises et à un échec du processus, révélant des tâches inutiles et un risque de doublons. Où trouver ces données Table BKPF, champ STBLG non vide. Données à recueillir 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éral. Cette étape sert souvent à effectuer une saisie préliminaire. Elle est identifiée directement dans la table VBKPF ou par la présence, dans BKPF, d’un code d’état de mise en attente avant la comptabilisation. | ||
| Pourquoi est-ce important ? La mise en attente marque le début de la saisie des données et permet de mesurer le délai entre la réception de la facture et la constatation de l’obligation financière. Où trouver ces données 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). Données à recueillir Enregistré à la création de l’entrée dans VBKPF Type d’événement explicit | |||
| Proposition de paiement créée | Indique que la facture a été incluse dans une campagne de proposition de paiement (F110), première étape du programme de paiement automatisé. L’activité est identifiée dans la table REGUH, qui contient les données de règlement. | ||
| Pourquoi est-ce 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ù trouver ces données Horodatage de création de la table REGUH (clés LAUFD et LAUFI). Données à recueillir Enregistré lors de la création de l’enregistrement REGUH Type d’événement explicit | |||
| Remise pour paiement anticipé perdue | Événement calculé qui marque la date d’expiration du droit à une remise pour paiement anticipé. Il est déterminé en comparant la date limite de remise à la date actuelle ou à la date de paiement. | ||
| Pourquoi est-ce important ? Indispensable à l’optimiseur des remises pour paiement anticipé, qui permet de visualiser les occasions d’économies perdues. Où trouver ces données Calcul : BSEG-ZFBDT + BSEG-ZBD1T (premier délai de remise, en jours). Données à recueillir Déduire en comparant la date à la date limite de remise Type d’événement calculated | |||
Guides d’extraction
Étapes
Repérer les vues CDS nécessaires : vérifiez que les vues CDS standard de SAP S/4HANA sont disponibles. Les principales vues requises 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 la base de données ou le compte de service technique dispose des autorisations SELECT sur les vues SQL DDL associées aux entités CDS. Cette configuration se fait généralement 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 à inclure afin de limiter le volume de données. Cette étape est importante pour les performances des requêtes sur la vue des postes de documents comptables opérationnels.
Définir la logique des activités : copiez la requête SQL fournie ci-dessous. Elle utilise UNION ALL pour regrouper 14 blocs de logique distincts dans une seule structure de journal d’événements. Chaque bloc correspond à une activité précise (par exemple, facture comptabilisée ou paiement compensé).
Traiter les documents de modification : la requête comprend des sections consacrées aux modifications des conditions de paiement et aux manipulations de blocage. Elles s’appuient 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 des événements « Facture arrivée à échéance » et « Escompte perdu ». Ces événements sont calculés en ajoutant un nombre de jours à la date de référence figurant dans la vue des postes opérationnels.
Lancer l’extraction : exécutez la requête. Pour les grands jeux de données, 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 le format des dates : assurez-vous que la colonne EventTime est au format YYYY-MM-DD HH:MM:SS. Selon l’application cible, les horodatages renvoyés par SAP HANA SQL peuvent nécessiter une conversion de type.
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.
Préparer les données pour l’importation : si votre outil de Process Mining exige un format CSV particulier (par exemple, un format de date spécifique), effectuez ces transformations dans un script de post-traitement ou dans SQL à l’aide des fonctions TO_VARCHAR.
Effectuer la validation finale : importez un échantillon dans ProcessMind et vérifiez que l’ID de cas (numéro de facture) regroupe correctement toutes les activités, de la comptabilisation à la compensation.
Configuration
- Filtre sur le code société : limitez la requête à des unités organisationnelles précises (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) pour 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 comptes clients.
- Activation des vues CDS : vérifiez que les vues I_JournalEntry, I_OperationalAcctgDocItem et I_PaymentProposalItem sont actives et autorisées pour l’accès SQL.
- Performances des journaux de modifications : les requêtes sur I_ChangeDocument peuvent mobiliser beaucoup de ressources. Limitez les sous-requêtes à la classe d’objet 'BELEG' et à des noms de champs précis, tels que ZLSPR et ZTERM.
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 vous disposez d’un accès SQL direct au schéma SAP HANA contenant ACDOCA, BKPF, BSEG, VBKPF, REGUH, REGUP et les tables de documents de modification applicables. Remplacez [Your SAP HANA schema] et les informations de connexion par les valeurs autorisé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] sous la forme d’un prédicat SQL valide, par exemple BUKRS IN ('1000','2000').
- Vérifiez la version de SAP et la configuration locale des documents préenregistrés, des champs de statut du programme de paiement, des types de documents de paiement et du stockage des documents de modification. La requête utilise des objets sources documentés et des associations de champs prudentes, mais vous devez vérifier les extensions locales et les différences entre versions 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é. Elle 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 indiqué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 qu’aucun document comptable en double ou sans rapport n’est inclus.
- Vérifiez les jointures à l’aide des champs InvoiceNumber, CompanyCode, exercice, numéro de document comptable, numéro de fournisseur et poste, le cas échéant. Confirmez que les numéros de document de facture sont représentés de façon cohérente dans BKPF, BSEG, ACDOCA, REGUH et REGUP dans le système cible.
- Vérifiez les événements calculés. L’événement « Facture arrivée à échéance » est généré à la date d’échéance nette calculée. L’événement « Escompte perdu » est généré à la première date limite d’escompte applicable lorsqu’aucun paiement n’a été effectué avant cette date. Ces lignes sont dérivées et doivent être clairement distinguées des événements issus des enregistrements sources.
- Exportez le résultat dans un fichier CSV plat encodé en UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Conservez exactement les noms de colonnes InvoiceNumber, Activity, EventTime, SourceSystem et LastDataUpdate. Gardez une ligne par événement et ne regroupez pas les activités par facture.
- Importez le journal d’événements dans ProcessMind et associez InvoiceNumber à l’identifiant du cas, Activity au nom de l’activité et EventTime à l’horodatage de l’événement. Associez les autres colonnes à des attributs d’événement ou de cas selon la configuration d’importation de ProcessMind.
Configuration
- Période : pour la première extraction, utilisez une période glissante de 3 à 6 mois. Appliquez de manière cohérente les prédicats portant sur la date de comptabilisation, la date de modification et la date du programme de paiement. Étendez la période pour vérifier les conditions de paiement à long terme.
- Schéma : remplacez [Your SAP HANA schema] par le schéma auquel appartiennent les objets SAP. Vérifiez si l’environnement expose les objets dépendant du mandant par le schéma sélectionné ou s’il faut ajouter un prédicat de mandant explicite.
- Filtrage par société : configurez [Company code filter] pour 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 les champs correspondants sont disponibles.
- Filtrage des documents : vérifiez les prédicats portant sur les types de documents de facture et de paiement. La requête comprend des exemples courants, mais les types de documents sont configurables et doivent correspondre au système cible.
- Factures préenregistrées : vérifiez comment le statut de préenregistrement est représenté 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 la table, les noms de champs et la représentation des valeurs pour BSEG-ZLSPR et BSEG-ZTERM dans les documents de modification. Le stockage de ces documents et le nommage des champs doivent être vérifiés dans le système cible.
- Programme de paiement : vérifiez les champs de REGUH et REGUP utilisés pour le statut des propositions et des exécutions, la date d’exécution, l’identification de l’exécution et le lien vers le document comptable. La configuration locale du programme de paiement peut influer sur les valeurs de statut disponibles.
- Performances : limitez la période et les codes société, sélectionnez uniquement les colonnes nécessaires et appliquez les filtres propres à chaque source avant les jointures. Pour les grands jeux de données, matérialisez des sous-ensembles filtrés des sources ou utilisez une vue de calcul HANA ou un schéma d’extraction approuvé.
- Autorisations : l’accès en lecture aux objets du schéma SAP HANA concerné et à toute vue exposant les données comptables, les données du programme de paiement et les documents de modification est nécessaire. Coordonnez-vous avec les équipes chargées de la sécurité SAP et de la gouvernance des données.
- Prérequis fonctionnels : les fonctions de comptabilité financière, de comptabilité fournisseurs, de programme de paiement et de gestion des documents de modification concernées doivent être actives et alimentées. Si une table source n’est pas utilisée dans votre implémentation, configurez une solution de remplacement approuvée, conforme à la conception 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 en un horodatage. Vérifiez le fuseau horaire du système source et appliquez la conversion nécessaire avant l’importation dans ProcessMind.
- Protection des données : limitez les données fournisseurs et comptables au périmètre approuvé et appliquez les règles de conservation, de masquage et d’accès de votre organisation.
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 démarche 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.