Votre modèle de données pour la gestion des paiements fournisseurs
Votre modèle de données pour la gestion des paiements fournisseurs
- Attributs essentiels pour l'analyse des fournisseurs et des paiements
- Jalons de processus essentiels pour le cycle de paiement
- Logique d'extraction spécialisée pour les systèmes SAP S/4HANA
Attributs de traitement des paiements des comptes fournisseurs
| Nom | Description | ||
|---|---|---|---|
| Activité Activity | La tâche spécifique ou le changement de statut d'événement enregistré pour la facture. | ||
| Description Cet attribut représente les différentes étapes du processus se produisant pendant le cycle de vie de la facture. Il capture des événements tels que la création de la facture, 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 de journaux de modifications (change logs) ou des mises à jour de statut de workflow trouvées dans le système source. Pour l'analyse, ce champ est essentiel pour cartographier la variante de flux de processus. Il permet au moteur de process mining de visualiser la séquence des étapes, d'identifier les boucles de retravail et de déterminer où le processus dévie du parcours standard ("happy path"). C'est le composant central du journal d'événements (event log). Pourquoi c'est important Il définit les nœuds de la carte de processus, permettant la visualisation du workflow et des goulots d'étranglement. Où obtenir Dérivé des codes de transaction (TCODE) ou de l'en-tête (CDHDR) et du poste (CDPOS) du document de modification Exemples Facture comptabiliséeBlocage de paiement appliquéExécution de la série de paiementsFacture apurée | |||
| Heure de l'événement EventTime | L'horodatage exact au moment de l'activité. | ||
| Description L'horodatage d'événement enregistre la date et l'heure spécifiques auxquelles une activité a été enregistrée dans la base de données SAP. Il fournit la dimension temporelle nécessaire pour ordonner les événements séquentiellement au sein d'un cas. Cet horodatage est généralement construit en combinant les champs Date CPU et Heure CPU des journaux système ou des en-têtes de document. En analyse, cet attribut est essentiel pour calculer les temps de cycle, la durée et le débit. Il permet la mesure des écarts de temps entre les étapes, tels que le temps écoulé entre la réception de la facture et l'approbation finale, ce qui est crucial pour identifier les goulots d'étranglement et évaluer les performances des KPI comme le temps moyen d'approbation des factures. Pourquoi c'est important Il fournit l'ordre chronologique des événements et constitue la base de tous les calculs de performance basés sur le temps. Où obtenir Champ CPUDT (Date de saisie) et CPUTM (Heure de saisie) de la table SAP BKPF, ou champs UDATE et UTIME de la table CDHDR Exemples 2023-10-12T08:30:00.000Z2023-10-12T14:15:22.000Z2023-10-15T09:00:00.000Z | |||
| Numéro de facture InvoiceNumber | L'identifiant unique de la facture fournisseur en cours de traitement. | ||
| Description Le numéro de facture est la clé primaire pour le suivi du cycle de vie d'un poste à payer au sein du système SAP S/4HANA. Il se réfère spécifiquement au numéro de document comptable généré lors de la comptabilisation de la facture au grand livre général. Dans la terminologie SAP standard, cela correspond au numéro de document (BELNR) trouvé dans un code société et un exercice fiscal spécifiques. En analyse de processus, cet attribut sert d'ID de cas. Il relie toutes les activités disparates – de la réception initiale et de la mise en attente de la facture, en passant par divers blocages d'approbation et modifications, jusqu'au lettrage final du paiement. Le regroupement des événements par cet identifiant permet aux analystes de reconstituer l'historique complet de bout en bout de chaque obligation de paiement. Pourquoi c'est important Il sert d'identifiant de cas définitif, permettant la reconstitution de bout en bout du flux de processus de paiement. Où obtenir Champ BELNR de la table SAP BKPF (en-tête de document comptable) ou champ BELNR de la table ACDOCA Exemples 1900000523510000289119000006015100003002 | |||
| Dernière mise à jour des données LastDataUpdate | L'horodatage indiquant quand l'enregistrement a été extrait ou actualisé pour la dernière fois. | ||
| Description La Dernière mise à jour des données marque le moment où les données ont été chargées avec succès dans la plateforme de Process Mining. Elle ne reflète pas le moment de l'événement commercial, mais plutôt la fraîcheur de l'ensemble de données lui-même. Ceci est crucial pour maintenir la confiance dans les tableaux de bord analytiques. Dans l'analyse, cet attribut aide les utilisateurs à comprendre l'actualité des informations qu'ils consultent. Il est particulièrement important lors de la surveillance de tableaux de bord quasi en temps réel comme l'Analyse des blocages de paiement, garantissant que les décisions sont prises sur la base de 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, ce qui est essentiel pour les tableaux de bord opérationnels. Où 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 | L'identifiant de l'instance SAP S/4HANA d'où proviennent les données. | ||
| Description Cet attribut identifie l'installation ERP ou le client spécifique d'où les données de processus ont été extraites. Dans les environnements avec plusieurs instances SAP ou des systèmes hérités fonctionnant en parallèle, ce champ garantit la traçabilité des données et permet des comparaisons entre systèmes. Pour l'analyse, ce champ agit comme un filtre de haut niveau. Il aide les analystes à séparer les données lors de l'évaluation comparative des performances entre différentes installations système régionales ou lors de la validation de la cohérence des données pendant les projets de migration de système. Il garantit que toute variation de processus attribuée à la configuration du système est correctement contextualisée. Pourquoi c'est important Il distingue les sources de données dans les environnements multi-systèmes, assurant une segmentation précise. Où obtenir ID système (SY-SYSID) issu du contexte d'installation SAP Exemples SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Code société CompanyCode | L'unité d'organisation pour laquelle le bilan et le compte de résultat sont créés. | ||
| Description Le code société représente l'entité comptable indépendante au sein de l'entreprise. C'est l'unité organisationnelle centrale de la comptabilité externe et elle est utilisée pour structurer les données financières. Chaque facture est affectée à un seul code société. En analyse, cet attribut permet la segmentation des KPI par entité juridique ou région. Il est utilisé dans les tableaux de bord pour comparer l'efficacité des équipes de comptabilité fournisseurs entre les différentes filiales. Par exemple, il aide à identifier si une succursale spécifique a un taux plus élevé de blocages manuels de paiement par rapport à la norme de l'entreprise. Pourquoi c'est important Il segmente le processus par entité juridique, facilitant l'analyse comparative interne. Où obtenir Champ BUKRS de la table SAP BKPF Exemples US01DE1010002000 | |||
| Conditions de paiement PaymentTerms | La clé représentant les conditions convenues pour le paiement et les escomptes. | ||
| Description Les conditions de paiement définissent l'échéance d'une facture et si des escomptes sont applicables pour un paiement anticipé. Ce code (par exemple, 'Z001') correspond à des règles telles que 'Net 30' ou '2% 10, Net 30'. Il est copié du Fichier Fournisseur vers la Facture mais peut être modifié manuellement. En analyse, cet attribut est essentiel pour les tableaux de bord "Optimiseur d'escomptes" et "Conformité aux conditions de paiement fournisseur". Il permet au système de calculer la date d'échéance de référence et d'identifier si le paiement a été effectué dans la fenêtre optimale pour réaliser des économies. Pourquoi c'est important Il dicte le calendrier prévu et les incitations financières, essentiels pour l'analyse des escomptes. Où obtenir Champ ZTERM de la table SAP BSEG Exemples Z001NT300001 | |||
| Date d'échéance nette NetDueDate | La date calculée à 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 pour le paiement. Elle est calculée en ajoutant le nombre maximal de jours de conditions de paiement à la date de base. Bien que parfois stockée explicitement, il s'agit souvent d'un champ calculé dans les vues d'analyse. En analyse, c'est le principal point de référence pour le "Suivi des paiements en retard et des pénalités". La comparaison de la date de lettrage réelle à la date d'échéance nette génère la métrique 'Jours de retard de paiement', ce qui aide à quantifier l'efficacité de l'équipe des comptes fournisseurs et le risque de friction avec les fournisseurs. Pourquoi c'est important C'est la date limite cible du processus ; la manquer a un impact sur la cote de crédit et entraîne des coûts. Où obtenir Calculé: Date de base + Jours de délai de paiement maximum (ZBD1T/ZBD2T/ZBD3T) Exemples 2023-11-302023-12-01 | |||
| Date d'encaissement ClearingDate | La date à laquelle la facture a été lettrée par paiement. | ||
| Description La date de lettrage enregistre quand le poste ouvert dans le grand livre des comptes fournisseurs a été soldé, généralement par un cycle de paiement ou une comptabilisation manuelle de paiement. Ceci marque efficacement la fin de l'obligation. En analyse, cet attribut est utilisé pour calculer le temps de cycle final du processus. C'est l'horodatage utilisé pour l'activité 'Paiement lettré' et est comparé à la date d'échéance nette pour déterminer la performance de paiement ponctuel. Il alimente directement le tableau de bord d'efficacité du lettrage des paiements. Pourquoi c'est important Il marque l'achèvement du processus de paiement et est utilisé pour déterminer la ponctualité des paiements. Où obtenir Champ AUGDT de la table SAP BSEG ou AUGDT Exemples 2023-11-012023-11-15 | |||
| Est sans contact IsTouchless | Un indicateur booléen signalant si la facture a été traitée sans intervention manuelle. | ||
| Description Cet attribut est calculé en analysant le flux d'événements pour un cas. Si le cas contient uniquement des activités automatisées (par exemple, utilisateur 'système', TCODES d'arrière-plan spécifiques) et aucune modification ou blocage manuel, il est marqué comme "sans intervention humaine" (touchless). En analyse, c'est la métrique centrale du KPI Taux de Factures "Touchless". Il permet à l'organisation de suivre le succès des initiatives d'automatisation et d'identifier quels types de cas (par exemple, par fournisseur ou région) transitent avec succès dans le système sans interventions humaines. Pourquoi c'est important C'est la mesure principale de l'automatisation et de l'efficacité des processus. Où obtenir Calculé en fonction de la séquence des activités et des types d'utilisateurs Exemples truefaux | |||
| Est un paiement en retard IsLatePayment | Un indicateur booléen signalant si le paiement a été effectué après la date d'échéance nette. | ||
| Description Cet attribut calculé évalue à vrai si la date de lettrage est strictement supérieure à la date d'échéance nette. Il sert de classificateur binaire pour la performance du processus. En analyse, ce drapeau est utilisé pour compter le nombre de cas non conformes pour le KPI "Fréquence des pénalités de paiement tardif". Il simplifie la création de tableaux de bord en permettant un simple décompte des valeurs 'Vrai' plutôt que de nécessiter des calculs de date complexes dans la couche de visualisation. Pourquoi c'est important Il simplifie le calcul des KPI de performance à temps. Où obtenir Calculé: Date de compensation > Date d'échéance nette Exemples truefaux | |||
| Montant de la facture InvoiceAmount | Le 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'enregistrée dans le document source. Il représente la dette qui doit être réglée avec le fournisseur. Dans SAP S/4HANA, cela est typiquement stocké dans le champ Montant en devise du document. En analyse, le montant de la facture est utilisé pour prioriser le travail. Les tableaux de bord comme la distribution des points de contact manuels utilisent ce champ pour mettre en évidence si des activités manuelles à fort effort sont gaspillées sur des factures de faible valeur. Il permet à l'organisation de concentrer les efforts d'optimisation sur les transactions de grande valeur où les défaillances de processus comportent un risque financier plus important. Pourquoi c'est important Il fournit le poids financier du cas, essentiel pour prioriser les inefficacités de processus à forte valeur. Où obtenir Champ WRBTR de la table SAP BKPF ou BSEG Exemples 1500.00250.5010000.00 | |||
| Motif de blocage de paiement PaymentBlockReason | Le code indiquant la raison pour laquelle une facture est bloquée pour paiement. | ||
| Description Cet attribut contient le code de motif spécifique appliqué à une facture qui empêche le cycle de paiement automatique de la prendre en compte. Des exemples incluent 'A' pour "Bloqué pour paiement", 'R' pour "Vérification facture", ou des blocages manuels définis par les utilisateurs. En analyse, ce champ est le principal moteur du tableau de bord d'analyse des blocages manuels de paiement. En agrégeant la fréquence des différentes raisons 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 bloquent le processus de paiement. Pourquoi c'est important Il identifie la cause spécifique des arrêts de processus, permettant une analyse ciblée des causes profondes. Où obtenir Champ ZLSPR de la table SAP BSEG Exemples ABRComment ça marche ? | |||
| Nom d'utilisateur UserName | L'ID de l'utilisateur qui a effectué l'activité spécifique. | ||
| Description Le nom d'utilisateur capture l'ID de connexion de la personne ou de l'agent système responsable de l'exécution d'une étape de processus. Il peut s'agir d'un utilisateur manuel saisissant des données ou d'un ID de job en arrière-plan (par exemple, 'BATCH_USER') effectuant des tâches automatisées. En analyse, cet attribut permet le calcul du 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 tableau de bord de distribution des points de contact manuels pour évaluer la charge de travail entre les équipes. Pourquoi c'est important Il distingue le travail manuel du travail automatisé, permettant le calcul des taux d'automatisation. Où obtenir Champ USNAM de la table SAP BKPF ou champ USERNAME de la table CDHDR Exemples BSMITHWF-BATCHRJONES | |||
| Numéro de fournisseur VendorNumber | L'identifiant unique du fournisseur associé à la facture. | ||
| Description Le numéro de fournisseur correspond au compte créditeur spécifique 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, cela est souvent lié au concept de Business Partner mais conserve l'ancien nom de champ LIFNR dans de nombreuses tables. En analyse, cet attribut est fondamental pour le tableau de bord de conformité des conditions de paiement des fournisseurs. Il permet aux analystes d'agréger la performance des processus par fournisseur, identifiant les fournisseurs spécifiques qui causent constamment des blocages, des écarts de prix ou des retards. Il soutient les décisions d'approvisionnement stratégique et la gestion des relations avec les fournisseurs. Pourquoi c'est important Il permet l'agrégation des performances par fournisseur, essentielle pour identifier les causes profondes des retards. Où obtenir Champ LIFNR de la table SAP BKPF ou champ LIFNR de la table ACDOCA Exemples 100050VEND-US-99200400 | |||
| Type de document DocumentType | Classifie le document comptable (par exemple, facture fournisseur, paiement, note de crédit). | ||
| Description Le type de document est un code à deux caractères dans SAP qui classifie la transaction comptable. Les types courants incluent 'KR' pour les factures fournisseurs, 'KZ' pour les paiements fournisseurs et 'RE' pour les réceptions de facture brutes. Il dicte la plage de numéros et le statut des champs du document. En analyse, cet attribut est utilisé pour filtrer le périmètre du processus. Par exemple, un analyste pourrait vouloir exclure les avoirs pour se concentrer uniquement sur l'efficacité des paiements sortants. Il aide également à identifier la combinaison de types de transactions traitées et prend en charge le tableau de bord de complexité des variantes de processus. Pourquoi c'est important Il catégorise le cas (facture vs. note de crédit), permettant une analyse filtrée. Où obtenir Champ BLART de la table SAP BKPF Exemples KRREKZKG | |||
| Date de base BaselineDate | La date à partir de laquelle les conditions de paiement s'appliquent et les dates d'échéance sont calculées. | ||
| Description La date de base est le point de départ pour le 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. En analyse, cette date est un prérequis technique pour le calcul du statut 'En retard'. Les erreurs dans la date de base entraînent souvent des paiements prématurés (impact sur la trésorerie) ou des paiements tardifs (impact sur les pénalités). Vérifier l'exactitude de cette date fait partie de l'analyse de conformité des conditions de paiement des fournisseurs. Pourquoi c'est important C'est le point d'ancrage pour tous les calculs de dates d'échéance. Où obtenir Champ ZFBDT de la table SAP BSEG Exemples 2023-10-012023-10-15 | |||
| Devise Currency | Le code devise associé au montant de la facture. | ||
| Description L'attribut devise spécifie la devise du montant de la facture, telle que USD, EUR ou GBP. Il permet l'interprétation correcte des valeurs financières et est essentiel lors de l'agrégation de données provenant de codes société internationaux. En analyse, ce champ garantit que les KPI financiers sont calculés correctement. Il est souvent utilisé pour normaliser les valeurs dans une devise de reporting pour les tableaux de bord mondiaux. Sans cet attribut, les métriques agrégées comme les dépenses totales ou la valeur moyenne des factures seraient dénuées de sens dans un environnement multidevises. Pourquoi c'est important Il fournit le contexte des montants financiers, essentiel pour un reporting mondial précis. Où obtenir Champ WAERS de la table SAP BKPF Exemples USDEURGBPJPY | |||
| Document d'Achat PurchasingDocument | Le numéro de commande d'achat associé à la facture. | ||
| Description Cet attribut lie la facture au processus d'approvisionnement en amont. Il contient le numéro de commande d'achat (PO) par rapport auquel la facture est rapprochée. Toutes les factures (par exemple, les frais divers) n'auront pas de référence de commande d'achat. En analyse, ce champ est vital pour l'analyse du taux de rapprochement en trois points. Il permet aux analystes de séparer les factures adossées à un PO des factures sans PO, qui ont généralement des workflows 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 d'approvisionnement. Pourquoi c'est important Il relie la comptabilité fournisseurs aux achats, permettant l'analyse du rapprochement à trois voies et l'extension des processus. Où obtenir Champ EBELN de la table SAP BSEG Exemples 45000012344500009876 | |||
| Exercice fiscal FiscalYear | L'exercice financier auquel la facture appartient. | ||
| 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. En analyse, c'est une nécessité technique pour l'identification unique des cas, mais cela prend également en charge le reporting annuel. Il garantit que l'ID de cas 'Numéro de facture' reste unique sur des décennies d'historique de données. Pourquoi c'est important Exigence technique pour l'identification unique des cas dans SAP FI. Où obtenir Champ GJAHR de la table SAP BKPF Exemples 20232024 | |||
| Jours d'escompte 1 CashDiscountDays1 | Le nombre de jours à partir de la date de base pendant lesquels le premier escompte est disponible. | ||
| Description Cet attribut définit la fenêtre temporelle pour les conditions de paiement les plus favorables (par exemple, '10' dans '2% 10, Net 30'). Il provient des conditions stockées dans le poste de facture. En analyse, cela aide à déterminer la 'Date cible' pour l'optimiseur d'escomptes. Si la facture est lettrée dans cette fenêtre, l'escompte est réalisé. Ce champ aide à mesurer le coût d'opportunité des cycles de traitement lents. Pourquoi c'est important Il définit la fenêtre d'opportunité pour les économies financières. Où obtenir Champ ZBD1T de la table SAP BSEG Exemples 10140 | |||
| Montant de l'escompte perdu DiscountLostAmount | La valeur monétaire des escomptes qui étaient disponibles mais non saisis. | ||
| Description Cet attribut calculé représente les "économies manquées". Il est dérivé 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 du pourcentage d'escompte manqué appliqué au montant de la facture. En analyse, c'est une métrique financière critique pour l'optimiseur d'escomptes. Il quantifie le coût de l'inefficacité en monnaie sonnante et trébuchante, fournissant un argumentaire solide pour l'amélioration des processus. Pourquoi c'est important Il quantifie la perte financière directe due aux retards de processus. Où obtenir Calculé: Si Date de compensation > Date d'escompte, alors Montant de la facture * % d'escompte Exemples 30,000.00150.00 | |||
| Pourcentage d'escompte 1 CashDiscountPercentage1 | Le pourcentage d'escompte disponible si payé pendant la première période d'escompte. | ||
| Description Cet attribut représente le taux d'incitatif financier offert par le fournisseur pour paiement anticipé (par exemple, '2' dans '2% 10'). En analyse, ceci est utilisé pour calculer la valeur de l''Escompte potentiel'. En multipliant ce pourcentage par le montant de la facture, les tableaux de bord peuvent visualiser le montant total des économies manquées en raison des inefficacités du processus, soutenant le cas d'affaires pour l'automatisation. Pourquoi c'est important Il quantifie le taux d'économies potentielles, essentiel pour les calculs de ROI. Où obtenir Champ ZBD1P de la table SAP BSEG Exemples 2.03,00,0 | |||
Activités de traitement des paiements des comptes fournisseurs
| Activité | Description | ||
|---|---|---|---|
| Blocage de paiement appliqué | Indique qu'un blocage de paiement a été défini sur le poste de facture, l'empêchant d'être inclus dans le cycle de paiement. Ceci est capturé en surveillant les modifications du champ ZLSPR dans la table BSEG via les documents de modification (change documents). | ||
| Pourquoi c'est important Les blocages sont la cause principale des retards de paiement et des frictions de processus, impactant directement le tableau de bord d'analyse des blocages de paiement manuels. Où obtenir Tables CDPOS et CDHDR (Documents de modification), recherchant les mises à jour du champ BSEG-ZLSPR. Capture Enregistré lorsque les enregistrements CDPOS modifient ZLSPR Type d'événement explicit | |||
| Blocage de paiement levé | Indique qu'un blocage de paiement précédemment appliqué a été levé, libérant ainsi la facture pour paiement. Ceci est identifié lorsque le champ ZLSPR dans BSEG passe d'une valeur à nul ou vide. | ||
| Pourquoi c'est important Souvent utilisé comme substitut de 'Facture approuvée' dans les systèmes sans journaux de workflow explicites, marquant la fin de la période de goulot d'étranglement. Où obtenir Tables CDPOS et CDHDR, recherchant BSEG-ZLSPR passant à vide. Capture Enregistré lors de la suppression de ZLSPR dans les enregistrements CDPOS Type d'événement explicit | |||
| Document de paiement créé | La génération du document comptable qui crédite la banque et débite le fournisseur. Ceci se trouve dans BKPF avec un type de document de paiement (par exemple, ZP, KZ). | ||
| Pourquoi c'est important La réalisation financière du paiement, utilisée pour calculer les Jours Fournisseurs (DPO). Où obtenir Table BKPF, filtrée par Type de Document (BLART) spécifique aux paiements. Capture Enregistré lors de la création du document de paiement BKPF Type d'événement explicit | |||
| Exécution de la série de paiements | Représente l'exécution du cycle de paiement où les instructions de virement sont générées. Ceci est suivi via la mise à jour du statut dans les tables REGUH ou REGUP. | ||
| Pourquoi c'est important L'engagement opérationnel de payer, essentiel pour analyser l'efficacité du processus de traitement par lots des paiements. Où obtenir Table REGUH, généralement corrélée avec la date et l'identification du cycle d'exécution. Capture Enregistré lorsque le statut du cycle de paiement est mis à jour Type d'événement explicit | |||
| Facture comptabilisée | Représente l'enregistrement officiel de la dette dans le Grand Livre Général. Cette activité est dérivée de l'horodatage de création dans la table BKPF ou de la date de saisie dans la table ACDOCA. | ||
| Pourquoi c'est important C'est le point de départ principal de la chronologie financière, établissant la base pour les dates d'échéance et l'analyse du vieillissement. Où obtenir Table BKPF, utilisant CPUDT (Date de saisie) et CPUTM (Heure de saisie). Capture Enregistré lors de la création de l'enregistrement BKPF Type d'événement explicit | |||
| Paiement compensé | Marque la réconciliation finale où le poste non soldé du compte fournisseur est compensé par le paiement. Capturé à partir du champ AUGDT (Date de compensation) dans la table BSEG. | ||
| Pourquoi c'est important L'état final du processus, indiquant que le cycle de vie est terminé et que les comptes sont équilibrés. Des taux de lettrage manuel élevés indiquent des inefficacités de rapprochement. Où obtenir Table BSEG, champ AUGDT (Date de compensation). Capture Enregistré lorsque le champ AUGDT est renseigné Type d'événement explicit | |||
| Conditions de paiement modifiées | Enregistre une mise à jour des conditions de paiement sur une facture ouverte, ce qui modifie la date d'échéance ou l'éligibilité à un escompte. Ceci est suivi via les journaux de modifications (change logs) sur le champ ZTERM de la table BSEG. | ||
| Pourquoi c'est important Des changements fréquents suggèrent des erreurs dans les données de base ou des remplacements manuels qui ont un impact sur la prévision de trésorerie et la conformité aux conditions de paiement des fournisseurs. Où obtenir Tables CDPOS et CDHDR, recherchant les mises à jour du champ BSEG-ZTERM. Capture Enregistré lorsque les enregistrements CDPOS modifient ZTERM Type d'événement explicit | |||
| Écart de prix détecté | Activité inférée indiquant une inadéquation entre le prix de la facture et le prix du bon de commande. Ceci est dérivé en observant une clé de blocage de paiement spécifique (généralement 'R' pour Vérification de facture) appliquée automatiquement lors de la comptabilisation. | ||
| Pourquoi c'est important Identifie les causes profondes du travail manuel de reprise et soutient l'analyse du taux de rapprochement à trois voies. Où obtenir Déduit de la valeur BSEG-ZLSPR 'R' (ou de la configuration spécifique au système pour les blocages de prix) au moment de la comptabilisation. Capture Comparer la valeur ZLSPR à 'R' Type d'événement inferred | |||
| Écart de quantité détecté | Activité inférée indiquant une divergence entre la quantité facturée et la quantité de marchandises reçues. Ceci est dérivé en observant une clé de blocage de paiement spécifique (généralement 'M' pour Écart de Quantité) appliquée au poste. | ||
| Pourquoi c'est important Crucial pour analyser l'efficacité du rapprochement et la qualité des données de la chaîne d'approvisionnement. Où obtenir Déduit de la valeur BSEG-ZLSPR 'M' (ou de la configuration spécifique au système pour les blocages de quantité). Capture Comparer la valeur ZLSPR à 'M' Type d'événement inferred | |||
| Escompte de caisse perdu | Un événement calculé marquant la date d'expiration de l'admissibilité à un escompte de caisse. Dérivé en comparant la date d'échéance de l'escompte à la date actuelle ou à la date de paiement. | ||
| Pourquoi c'est important Essentiel pour l'optimiseur de rabais pour paiement anticipé afin de visualiser les opportunités financières manquées. Où obtenir Calculé: BSEG-ZFBDT + BSEG-ZBD1T (Jours d'escompte 1). Capture Déduire en comparant la date à la date d'échéance de l'escompte Type d'événement calculated | |||
| Facture contre-passée | Indique que le document de facture a été inversé ou annulé. Capturé en vérifiant le champ STBLG (Document d'annulation) dans la table BKPF. | ||
| Pourquoi c'est important Représente le retravail et l'échec du processus, identifiant le gaspillage et les efforts potentiellement redondants. Où obtenir Table BKPF, le champ STBLG n'est pas vide. Capture Enregistré lorsque le champ STBLG est renseigné Type d'événement explicit | |||
| Facture échue | Un horodatage calculé représentant le moment où la facture a atteint sa date d'échéance nette. Ceci est dérivé en ajoutant les jours des conditions de paiement à la date de base trouvée dans la table BSEG. | ||
| Pourquoi c'est important Sert de point de référence pour la performance des paiements à temps et le suivi des pénalités de retard de paiement. Où obtenir Calculé: BSEG-ZFBDT (Date de base) + BSEG-ZBD1T/ZBD2T/ZBD3T (Jours). Capture Déduire en comparant la date actuelle à la date d'échéance nette Type d'événement calculated | |||
| Facture pré-enregistrée | Indique qu'une facture a été saisie dans SAP mais n'a pas encore été comptabilisée dans le grand livre, souvent utilisée pour une saisie de données préliminaire. Ceci est capturé explicitement de la table VBKPF ou en identifiant les documents dans BKPF avec un code de statut de stationnement avant qu'ils ne passent à l'état comptabilisé. | ||
| Pourquoi c'est important La mise en attente (parking) indique le début de la phase de saisie des données et aide à mesurer le délai entre la réception et l'obligation financière. Où obtenir Table VBKPF pour les données d'en-tête des documents mis en attente ou BKPF avec un statut de document spécifique (BSTAT = V). Capture 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 un cycle de proposition de paiement (F110), la première étape du programme de paiement automatisé. Capturé à partir de la table REGUH qui stocke 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ù obtenir Horodatage de création de la table REGUH (clés LAUFD et LAUFI). Capture Enregistré lors de la création de l'enregistrement REGUH Type d'événement explicit | |||
Guides d'extraction
Étapes
Identifier les vues CDS requises: Confirmez la disponibilité des vues CDS standard de SAP S/4HANA. Les vues principales nécessaires sont I_JournalEntry (En-tête), I_OperationalAcctgDocItem (Postes/équivalent BSEG), I_SupplierInvoice (Logistique), I_PaymentProposalItem (F110) et I_ChangeDocument (pour les journaux).
Configurer les autorisations utilisateur: Assurez-vous que l'utilisateur de la base de données ou l'utilisateur du service technique dispose des privilèges SELECT sur les vues DDL SQL associées aux entités CDS. Cela est généralement géré via SAP HANA Studio ou les outils de développement ABAP 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 qui accepte SQL). Cette méthode suppose un accès SQL direct à la couche HANA où les vues CDS sont exposées en tant que vues.
Définir le périmètre: Déterminez le code société (CompanyCode) et la plage d'années fiscales pour limiter le volume de données. Ceci est crucial pour les performances lors de l'interrogation de la vue des postes de document comptable opérationnel.
Implémenter la logique d'activité: Copiez la requête SQL fournie ci-dessous. Cette requête utilise UNION ALL pour combiner 14 blocs logiques distincts en une seule structure de journal d'événements. Chaque bloc cible une activité spécifique (par exemple, Facture enregistrée, Paiement compensé).
Gérer les documents de modification: La requête inclut des sections pour les modifications des conditions de paiement et la manipulation des blocages. Celles-ci reposent sur la vue I_ChangeDocument. Si cette vue n'est pas active dans votre version S/4 spécifique, vous devrez peut-être encapsuler les tables sous-jacentes (CDHDR/CDPOS) dans une vue CDS personnalisée.
Gérer les événements calculés: Passez en revue la logique pour les événements Facture Échue et Escompte de Caisse Perdu. Ces événements calculés sont générés en ajoutant des jours à la date de base trouvée dans la vue des postes opérationnels.
Exécuter l'extraction: Exécutez la requête. Pour les grands ensembles de données, il est fortement recommandé de partitionner l'extraction par année fiscale ou par code société afin d'éviter les débordements de mémoire.
Vérifier les formats de date: Assurez-vous que la colonne EventTime est formatée comme AAAA-MM-JJ HH:MM:SS. SAP HANA SQL renvoie des horodatages qui peuvent nécessiter un transtypage en fonction de votre application cible.
Exporter les données: Enregistrez le jeu de résultats sous forme de fichier CSV ou Parquet. Assurez-vous que les en-têtes correspondent aux colonnes définies dans l'instruction SELECT finale.
Transformer pour le téléchargement: Si votre outil de Process Mining nécessite un format CSV spécifique (par exemple, un masquage de date spécifique), appliquez ces transformations dans un script de post-traitement ou dans la requête SQL à l'aide des fonctions TO_VARCHAR.
Validation finale: Chargez un échantillon dans ProcessMind et vérifiez que l'ID de cas (numéro de facture) regroupe correctement toutes les activités, de l'enregistrement à la compensation.
Configuration
- Filtre par code société: Restreignez la requête à des unités organisationnelles spécifiques (CompanyCode = '1000') pour maintenir le contexte et les performances.
- Période: Appliquez un filtre sur la date de comptabilisation (PostingDate) ou la date de création (CreationDate) (par exemple, les 12 derniers mois) pour gérer le volume de données.
- Type de compte: Filtrez I_OperationalAcctgDocItem pour FinancialAccountType = 'K' (Fournisseur) afin d'exclure les lignes de grand livre et de client.
- Activation des vues CDS: Assurez-vous que les vues I_JournalEntry, I_OperationalAcctgDocItem et I_PaymentProposalItem sont actives et autorisées pour l'accès SQL.
- Performance du journal des modifications: L'interrogation de I_ChangeDocument peut être gourmande en ressources. Limitez ces sous-requêtes par ObjectClass 'BELEG' et des noms de champs spécifiques comme 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
Identifier les vues CDS requises: Confirmez la disponibilité des vues CDS standard de SAP S/4HANA. Les vues principales nécessaires sont I_JournalEntry (En-tête), I_OperationalAcctgDocItem (Postes/équivalent BSEG), I_SupplierInvoice (Logistique), I_PaymentProposalItem (F110) et I_ChangeDocument (pour les journaux).
Configurer les autorisations utilisateur: Assurez-vous que l'utilisateur de la base de données ou l'utilisateur du service technique dispose des privilèges SELECT sur les vues DDL SQL associées aux entités CDS. Cela est généralement géré via SAP HANA Studio ou les outils de développement ABAP 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 qui accepte SQL). Cette méthode suppose un accès SQL direct à la couche HANA où les vues CDS sont exposées en tant que vues.
Définir le périmètre: Déterminez le code société (CompanyCode) et la plage d'années fiscales pour limiter le volume de données. Ceci est crucial pour les performances lors de l'interrogation de la vue des postes de document comptable opérationnel.
Implémenter la logique d'activité: Copiez la requête SQL fournie ci-dessous. Cette requête utilise UNION ALL pour combiner 14 blocs logiques distincts en une seule structure de journal d'événements. Chaque bloc cible une activité spécifique (par exemple, Facture enregistrée, Paiement compensé).
Gérer les documents de modification: La requête inclut des sections pour les modifications des conditions de paiement et la manipulation des blocages. Celles-ci reposent sur la vue I_ChangeDocument. Si cette vue n'est pas active dans votre version S/4 spécifique, vous devrez peut-être encapsuler les tables sous-jacentes (CDHDR/CDPOS) dans une vue CDS personnalisée.
Gérer les événements calculés: Passez en revue la logique pour les événements Facture Échue et Escompte de Caisse Perdu. Ces événements calculés sont générés en ajoutant des jours à la date de base trouvée dans la vue des postes opérationnels.
Exécuter l'extraction: Exécutez la requête. Pour les grands ensembles de données, il est fortement recommandé de partitionner l'extraction par année fiscale ou par code société afin d'éviter les débordements de mémoire.
Vérifier les formats de date: Assurez-vous que la colonne EventTime est formatée comme AAAA-MM-JJ HH:MM:SS. SAP HANA SQL renvoie des horodatages qui peuvent nécessiter un transtypage en fonction de votre application cible.
Exporter les données: Enregistrez le jeu de résultats sous forme de fichier CSV ou Parquet. Assurez-vous que les en-têtes correspondent aux colonnes définies dans l'instruction SELECT finale.
Transformer pour le téléchargement: Si votre outil de Process Mining nécessite un format CSV spécifique (par exemple, un masquage de date spécifique), appliquez ces transformations dans un script de post-traitement ou dans la requête SQL à l'aide des fonctions TO_VARCHAR.
Validation finale: Chargez un échantillon dans ProcessMind et vérifiez que l'ID de cas (numéro de facture) regroupe correctement toutes les activités, de l'enregistrement à la compensation.
Configuration
- Filtre par code société: Restreignez la requête à des unités organisationnelles spécifiques (CompanyCode = '1000') pour maintenir le contexte et les performances.
- Période: Appliquez un filtre sur la date de comptabilisation (PostingDate) ou la date de création (CreationDate) (par exemple, les 12 derniers mois) pour gérer le volume de données.
- Type de compte: Filtrez I_OperationalAcctgDocItem pour FinancialAccountType = 'K' (Fournisseur) afin d'exclure les lignes de grand livre et de client.
- Activation des vues CDS: Assurez-vous que les vues I_JournalEntry, I_OperationalAcctgDocItem et I_PaymentProposalItem sont actives et autorisées pour l'accès SQL.
- Performance du journal des modifications: L'interrogation de I_ChangeDocument peut être gourmande en ressources. Limitez ces sous-requêtes par ObjectClass 'BELEG' et des noms de champs spécifiques comme 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