> Amélioration continue des processus > Traitement des paiements fournisseurs > SAP ECC > Modèle de données

Votre modèle de données pour le traitement des paiements fournisseurs

SAP ECC

Attributs du traitement des paiements fournisseurs (21) Activités du traitement des paiements fournisseurs (13) Guides d'extraction (3)

Votre modèle de données pour le traitement des paiements fournisseurs

Ce modèle propose une méthode structurée pour cartographier vos flux de travail de paiement dans SAP ECC en identifiant les points de données et les jalons essentiels. Il fournit une liste complète des attributs et des activités, accompagnée de conseils pratiques d’extraction pour vous aider à constituer un journal d’événements fiable. En suivant ce guide, vous pouvez repérer les retards de paiement et optimiser efficacement vos opérations financières.

Champs de données essentiels pour l'analyse des paiements
Principaux jalons du processus pour suivre les flux de travail
Guide d'extraction SAP ECC étape par étape

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du traitement des paiements fournisseurs

Ce tableau présente les champs de données recommandés à recueillir depuis votre système SAP ECC pour permettre une analyse détaillée du cycle de vie de vos paiements.

5 Obligatoire 10 Recommandé 6 Facultatif

	Nom	Description
	Dernière mise à jour des données LastDataUpdate	Horodatage de l’extraction de données la plus récente.
Description Cet attribut indique la date de la dernière actualisation de l’enregistrement depuis le système source. Il sert à évaluer la fraîcheur de l’analyse et à gérer les chargements incrémentiels. Dans les Dashboards, il aide les utilisateurs à déterminer s’ils consultent des données en temps réel ou un instantané d’une période précédente, ce qui est essentiel au suivi opérationnel des factures ouvertes. Pourquoi c’est important Fournit le contexte nécessaire sur la latence et la fiabilité des données. Où les obtenir Métadonnées du processus ETL Exemples 2023-11-01T00:00:00Z2023-11-01T12:00:00Z
	Horodatage de l’événement EventTimestamp	Date et heure exactes auxquelles l’activité a eu lieu.
Description Cet attribut enregistre le moment précis où une action a été effectuée dans le système SAP. Il combine généralement la date et l’heure système issues des tables concernées, par exemple CPUDT et CPUTM. Il est essentiel au calcul de tous les KPI temporels, notamment le temps de cycle, le délai d’approbation et le débit du processus. Sans horodatages précis, il est impossible de déterminer l’ordre des événements ou de mesurer l’efficacité. Pourquoi c’est important Essentiel pour ordonner les événements et calculer les indicateurs de durée. Où les obtenir Tables SAP ECC BKPF (CPUDT/CPUTM) ou CDHDR (UDATE/UTIME) Exemples 2023-10-15T09:30:00Z2023-10-15T14:45:12Z2023-10-16T08:15:00Z
	Nom de l’activité ActivityName	Étape ou action précise exécutée dans le processus.
Description Cet attribut décrit l’événement survenu dans le processus des comptes fournisseurs, comme « Invoice Posted », « Payment Block Applied » ou « Payment Run Executed ». Il définit les nœuds de la carte du processus. Dans l’analyse, la séquence de ces activités permet de visualiser les variantes du processus, d’identifier les boucles de reprise, par exemple la suppression d’un blocage suivie de sa réapplication, et de vérifier la conformité au flux de travail d’approbation standard. Pourquoi c’est important Il détermine le flux du processus et est nécessaire pour visualiser le parcours de la facture. Où les obtenir Dérivé des Transaction Codes (TCODE), des Change Document Object Classes (CDHDR) ou des journaux de flux de travail Exemples Facture comptabiliséeBlocage du paiement suppriméModification de prix
	Numéro de facture InvoiceNumber	Identifiant unique du document de facture fournisseur.
Description Cet attribut sert d’identifiant central du cas pour le processus de gestion des dettes fournisseurs. Dans SAP ECC, il s’agit techniquement de la concaténation du mandant, du code société, de l’exercice fiscal et du numéro de document comptable (BELNR), afin de garantir une unicité globale dans le système. Il regroupe toutes les activités liées à une dette fournisseur donnée. L’analyse utilise ce champ pour suivre le cycle de vie complet d’une obligation de paiement. Il permet aux outils de Process Mining de reconstituer l’historique d’une facture, depuis sa réception ou sa numérisation jusqu’à la comptabilisation de l’écriture finale de lettrage dans le grand livre. Pourquoi c’est important Il constitue la clé fondamentale pour relier les événements, les changements de statut et les écritures financières au sein d’une même instance de processus. Où les obtenir Table SAP ECC BKPF, champ BELNR (combiné à BUKRS et GJAHR) Exemples 1000-2023-1900001234US01-2023-51000008922000-2024-1500004455
	Système source SourceSystem	Identifiant de l’instance SAP ERP.
Description Cet attribut identifie le système SAP ECC ou le mandant précis à partir duquel les données ont été extraites. Dans les environnements multisystèmes, il est indispensable pour séparer les données et analyser les performances selon les régions ou les unités opérationnelles. Il permet aux utilisateurs de filtrer la vue du processus selon des environnements précis et garantit l’unicité des cas lorsque plusieurs instances SAP sont intégrées au même modèle de données de Process Mining. Pourquoi c’est important Garantit l’unicité et le contexte des données dans les environnements multi-ERP. Où les obtenir Paramètre de configuration ou d’extraction du système Exemples SAP_ECC_PRODERP_NASAP_P01
	Code de blocage du paiement PaymentBlockCode	Indique si une facture est bloquée pour paiement et en précise la raison.
Description Cet attribut (ZLSPR) contient le code qui empêche la prise en compte d’une facture dans la proposition de paiement automatique, par exemple « R » pour la vérification de facture ou « A » pour une facture verrouillée. Le suivi de cet attribut constitue le fondement du Dashboard « Résolution des blocages et mises en attente de paiement ». Il permet d’identifier les causes les plus fréquentes des retards de paiement et de mesurer la durée pendant laquelle les factures restent bloquées. Pourquoi c’est important Indicateur principal des difficultés du processus et des besoins d’intervention manuelle. Où les obtenir Table SAP ECC BSEG, champ ZLSPR Exemples ARnull
	Code société CompanyCode	Unité organisationnelle pour laquelle les états financiers sont établis.
Description Le code société (BUKRS) est l’unité organisationnelle centrale de la comptabilité financière SAP. Il représente une entité juridique ou une filiale précise au sein de la structure de l’entreprise. Cet attribut permet d’analyser les performances du processus par filiale ou par région. Les parties prenantes peuvent ainsi comparer les taux de paiements en retard ou les taux d’automatisation entre différentes unités opérationnelles afin d’identifier les plus performantes et celles qui doivent progresser. Pourquoi c’est important Dimension principale pour comparer les performances organisationnelles. Où les obtenir Table SAP ECC BKPF, champ BUKRS Exemples 1000US01DE10
	Conditions de paiement PaymentTerms	Code définissant les conditions de paiement et les remises.
Description Cet attribut contient la clé des conditions de paiement (ZTERM), qui détermine la date d’échéance de la facture et l’application éventuelle de remises pour paiement comptant, par exemple 2 % à 10 jours nets. Il sert de référence au calcul du « taux de capture des remises pour paiement anticipé ». L’analyse utilise ce code pour calculer la date de paiement cible et identifier les écarts à l’origine de remises perdues ou de pénalités. Pourquoi c’est important Définit l’échéance financière et les possibilités de remise. Où les obtenir Table SAP ECC BSEG, champ ZTERM Exemples Z001NT300002
	Date de lettrage ClearingDate	Date à laquelle la facture a été lettrée ou payée dans le système.
Description Cet attribut (AUGDT) enregistre la date à laquelle le poste ouvert a été lettré dans le grand livre, ce qui marque l’achèvement du processus de paiement. Il constitue l’horodatage de fin du KPI « temps de cycle moyen d’une facture ». La comparaison de cette date avec la date d’échéance permet de déterminer si le paiement a été effectué à temps ou en retard. Pourquoi c’est important Marque l’achèvement du processus financier. Où les obtenir Table SAP ECC BSEG, champ AUGDT Exemples 2023-11-202023-12-05
	Mode de paiement PaymentMethod	Mode utilisé pour payer la facture, par exemple chèque, virement ou ACH.
Description Cet attribut (ZLSCH) précise le mode de paiement prévu ou utilisé. Il distingue les chèques manuels, les virements bancaires et les paiements électroniques. Ce champ alimente le Dashboard « Répartition de l’automatisation des modes de paiement » ainsi que le KPI « taux d’adoption des paiements électroniques ». Il aide les organisations à suivre le remplacement progressif des chèques manuels, coûteux, par des virements électroniques moins coûteux. Pourquoi c’est important Suit l’efficacité et le coût de la phase d’exécution du paiement. Où les obtenir Table SAP ECC BSEG ou BKPF, champ ZLSCH Exemples CTU
	Montant de la facture InvoiceAmount	Valeur monétaire totale de la facture dans la devise locale.
Description Cet attribut représente le montant à payer au fournisseur (DMBTR ou WRBTR). Il est essentiel pour évaluer l’impact financier des inefficacités du processus. Utilisé dans la mise en correspondance « Montant de l’activité », ce champ permet de calculer des KPI pondérés par la valeur. Par exemple, un paiement en retard sur une facture d’un montant élevé est plus préoccupant que sur une facture de faible montant. Il aide à prioriser les tâches selon leur impact sur le fonds de roulement. Pourquoi c’est important Quantifie l’importance financière de l’instance de processus. Où les obtenir Table SAP ECC BSEG, champ DMBTR (devise locale) ou WRBTR (devise du document) Exemples 1500.00230.5010500.00
	Nom d’utilisateur UserName	Identifiant de l’utilisateur ayant effectué l’activité.
Description Cet attribut identifie l’identifiant utilisateur SAP (USNAM) responsable de l’événement. Il est enregistré dans l’en-tête de la transaction ou dans le journal des modifications. Il est associé à l’attribut générique « Utilisateur » afin d’analyser le « taux d’intervention manuelle » et l’utilisation des ressources. Il permet de distinguer les utilisateurs système automatisés, tels que les traitements par lots, des utilisateurs humains effectuant des ajustements manuels. Pourquoi c’est important Permet d’analyser les ressources et de calculer le taux d’automatisation. Où les obtenir Table SAP ECC BKPF, champ USNAM, ou CDHDR, champ USERNAME Exemples BSMITHWF-BATCHSAP_WORKER
	Numéro de commande d’achat PurchaseOrderNumber	Référence du document d’achat associé à la facture.
Description Cet attribut contient le numéro de commande d’achat (EBELN) lorsque la facture est associée à une commande. Il relie le processus de gestion des dettes fournisseurs au processus d’approvisionnement. Il est essentiel au Dashboard « Rapprochement des commandes et audit des écarts ». Son analyse permet de calculer le « taux de factures associées à une commande » et de comparer l’efficacité du traitement des factures avec et sans commande d’achat. Pourquoi c’est important Relie les comptes fournisseurs aux achats et identifie les flux de travail correspondants. Où les obtenir Table SAP ECC BSEG, champ EBELN Exemples 45000123894500099221null
	Numéro fournisseur VendorNumber	Identifiant unique du fournisseur ou du créancier.
Description Cet attribut identifie de manière unique le fournisseur externe associé à la facture (LIFNR). Il est lié aux données de base du fournisseur, qui contiennent notamment son nom, son adresse et ses conditions de paiement. L’analyse des fournisseurs est essentielle pour négocier de meilleures conditions, regrouper les dépenses et résoudre les problèmes récurrents. Ce champ alimente le Dashboard « Volume des demandes et du support fournisseurs » en aidant à mettre en relation les inefficacités du processus avec des fournisseurs précis. Pourquoi c’est important Permet d’analyser les performances du point de vue des fournisseurs. Où les obtenir Table SAP ECC BSEG, champ LIFNR, ou LFA1 Exemples 0000100234VEND-5592102938
	Type de document DocumentType	Classe le document comptable, par exemple facture ou avoir.
Description Le type de document (BLART) catégorise l’écriture comptable et distingue les factures fournisseurs standard, par exemple KR, les avoirs, KG, ou les paiements, KZ. Le filtrage par type de document est essentiel pour analyser correctement les temps de cycle, car les avoirs suivent un flux de processus différent de celui des factures standard. Il garantit la comparaison de processus de même nature. Pourquoi c’est important Distingue les différents flux de travail financiers, comme ceux des factures et des avoirs. Où les obtenir Table SAP ECC BKPF, champ BLART Exemples KRREKG
	Associée à une commande d’achat IsPOBased	Indicateur précisant si la facture est liée à une commande d’achat.
Description Cet attribut booléen est dérivé de la vérification du renseignement du champ Numéro de commande d’achat. Il segmente les données entre les flux associés à une commande, MM-LIV, et les flux sans commande, FI-AP. Cette segmentation est essentielle à l’analyse de l’efficacité du traitement des factures sans commande, car celles-ci nécessitent généralement davantage d’étapes d’approbation manuelle et présentent des temps de cycle plus longs. Pourquoi c’est important Segmentation fondamentale pour analyser l’efficacité du processus. Où les obtenir Dérivé : vrai si EBELN n’est ni nul ni vide Exemples truefalse
	Code devise CurrencyCode	Code de la devise du montant de la facture.
Description Cet attribut (WAERS) identifie la devise dans laquelle la facture a été émise, par exemple USD ou EUR. Il permet de gérer les processus multidevises. Dans l’analyse, il sert à regrouper les dépenses par devise ou à faciliter la conversion pour les rapports consolidés du Dashboard « Visibilité des flux de trésorerie et des paiements ». Pourquoi c’est important Nécessaire pour interpréter correctement les montants financiers. Où les obtenir Table SAP ECC BKPF, champ WAERS Exemples USDEURGBP
	Date d’échéance nette NetDueDate	Date calculée à laquelle la facture doit être payée au plus tard.
Description Cet attribut représente la date limite finale de paiement. Il est calculé en ajoutant le nombre maximal de jours de paiement défini dans les conditions de paiement à la date de référence du paiement. Il sert de référence au « suivi des paiements en retard et des pénalités ». Sans ce champ calculé, il est impossible de signaler les factures ayant dépassé leurs SLA. Pourquoi c’est important Échéance cible de l’ensemble du processus. Où les obtenir Calculé : BaselinePaymentDate + PaymentTerms(Days) Exemples 2023-11-302023-12-15
	Date de référence du paiement BaselinePaymentDate	Date à partir de laquelle les conditions de paiement sont calculées.
Description Cet attribut (ZFBDT) constitue le point de départ du calcul de la date d’échéance nette et des dates limites de remise. Il correspond généralement à la date de réception de la facture ou à la date du document, selon la configuration. L’analyse précise du « taux de paiements en retard » repose sur ce champ. Si la date de référence est incorrecte, tous les calculs d’échéance ultérieurs et les indicateurs de retard seront faussés. Pourquoi c’est important Date de référence pour tous les calculs d’ancienneté et d’échéance. Où les obtenir Table SAP ECC BSEG, champ ZFBDT Exemples 2023-10-012023-11-15
	Numéro de référence ReferenceNumber	Numéro de facture du fournisseur, tel qu’il figure sur le document papier.
Description Le numéro de référence (XBLNR) est l’identifiant externe fourni par le fournisseur. Il est saisi manuellement ou capturé par OCR lors de la création de la facture. Cet attribut constitue la clé principale de l’analyse « Prévention des paiements en double ». Les algorithmes recherchent plusieurs occurrences du même numéro de référence pour un même fournisseur et un même montant afin de signaler les paiements potentiellement dupliqués. Pourquoi c’est important Essentiel pour identifier les doublons et auditer les factures de fournisseurs précises. Où les obtenir Table SAP ECC BKPF, champ XBLNR Exemples INV-2023-00199887766OCT-BILLING
	Paiement en retard IsLatePayment	Indicateur précisant si le paiement a été effectué après la date d’échéance.
Description Cet attribut booléen est calculé en comparant la date de lettrage à la date d’échéance nette. Si la date de lettrage est postérieure, l’indicateur prend la valeur vrai. Il alimente directement le KPI « taux de paiements en retard ». Cet indicateur précalculé simplifie la création des Dashboards, car les utilisateurs peuvent compter les valeurs « vrai » sans écrire de logique complexe dans la couche de visualisation. Pourquoi c’est important Simplifie le suivi des KPI relatifs au respect des délais. Où les obtenir Calculé : ClearingDate > NetDueDate Exemples truefalse

Obligatoire Recommandé Facultatif

Activités du traitement des paiements fournisseurs

Voici les principales étapes du processus et les changements de statut à suivre pour visualiser le parcours complet de vos paiements fournisseurs.

7 Recommandé 6 Facultatif

	Activité	Description
	Blocage du paiement appliqué	Enregistre l’application d’une clé de blocage du paiement à un poste de facture. Cela empêche la facture d’être sélectionnée par le programme de paiement automatique.
Pourquoi c’est important Il s’agit d’une cause principale des retards de paiement et des remises manquées. L’analyse du code motif du blocage permet de déterminer si les retards sont dus à des écarts de prix, à des réceptions de marchandises manquantes ou à des blocages manuels. Où les obtenir Documents de modification (CDHDR/CDPOS) pour l’objet BELEG, champ BSEG-ZLSPR (Payment Block Key). Collecte Comparer le champ de statut avant et après Type d’événement inferred
	Blocage du paiement supprimé	Enregistre la suppression d’un blocage de paiement, ce qui rend la facture éligible au prochain cycle de paiement. Dans de nombreuses configurations SAP, cet événement sert d’indicateur indirect de l’« approbation ».
Pourquoi c’est important Représente la résolution des problèmes qui empêchent le paiement. La durée entre Block Applied et Block Removed constitue le goulot d’étranglement du « temps de résolution ». Où les obtenir Documents de modification (CDHDR/CDPOS) lorsque la nouvelle valeur de BSEG-ZLSPR est vide. Collecte Comparer le champ de statut avant et après Type d’événement inferred
	Facture compensée	Écriture comptable qui associe le poste de facture au document de paiement et solde le poste ouvert à zéro. Elle clôt le cycle de vie de la facture.
Pourquoi c’est important Indicateur d’achèvement du processus. Il est essentiel pour calculer le « délai de traitement de bout en bout » et confirmer l’extinction de la dette. Où les obtenir La table BSEG est renseignée dans le champ AUGDT (Clearing Date). Collecte Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Facture comptabilisée	Signifie que la facture a été correctement comptabilisée dans le grand livre et les livres auxiliaires. Cette action crée la dette dans le système.
Pourquoi c’est important La facture est désormais officiellement reconnue comme une dette. Cela déclenche le calcul standard de l’ancienneté du paiement et de la date d’échéance. Où les obtenir Création dans la table BKPF lorsque BSTAT est vide (comptabilisation standard). Collecte Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Facture créée	Indique le moment où les données de la facture sont techniquement saisies dans SAP ECC. Cet horodatage marque le début du processus numérique dans l’ERP.
Pourquoi c’est important Essentiel pour calculer le temps de traitement interne par rapport au temps d’attente total du fournisseur. Une latence élevée entre Receipt et Creation indique des goulots d’étranglement en amont lors de la réception. Où les obtenir Table BKPF, champs CPUDT (Entry Date) et CPUTM (Entry Time). Collecte Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Paiement comptabilisé	Exécution du cycle de paiement au cours duquel le virement bancaire est initié ou le chèque imprimé. Un document de paiement est généré dans le système.
Pourquoi c’est important Le point de non-retour de la sortie de trésorerie. Cet horodatage sert à calculer le délai réel du cycle de paiement et à vérifier le respect des échéances de remise. Où les obtenir Table BKPF pour le document de paiement (type de document « ZP » ou équivalent). Collecte Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Réception de la facture enregistrée	Capture la date indiquée sur la facture du fournisseur comme date de référence. Elle provient du champ Document Date dans l’en-tête du document comptable.
Pourquoi c’est important Établit la base de l’analyse de l’ancienneté et du respect des conditions de paiement des fournisseurs. Les écarts entre cette date et la date de saisie révèlent les retards liés au courrier ou à la numérisation. Où les obtenir Table BKPF, champ BLDAT (Document Date). Collecte Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Conditions de paiement modifiées	Événement de reprise spécifique au cours duquel les conditions de paiement sont modifiées manuellement. Cette modification change la date d’échéance et les paramètres de remise en espèces.
Pourquoi c’est important Cette modification vise souvent à prolonger artificiellement les délais de paiement ou à corriger des erreurs dans les données de référence. Elle a un effet direct sur les prévisions de trésorerie et les indicateurs de saisie des remises. Où les obtenir Documents de modification (CDHDR/CDPOS) pour le champ BSEG-ZTERM. Collecte Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Date d’échéance dépassée	Événement calculé indiquant que la facture reste ouverte après sa date d’échéance nette. La facture est ainsi signalée comme échue.
Pourquoi c’est important Prend en charge l’analyse des « paiements en retard ». Son suivi contribue à prévenir les tensions avec les fournisseurs et les éventuels frais de retard. Où les obtenir Calculé en ajoutant BSEG-ZBD3T (jours nets) à la date de référence, puis en comparant le résultat à la date actuelle. Collecte Dérivé de la comparaison du champ X avec le champ Y Type d’événement calculated
	Date limite de remise dépassée	Événement calculé indiquant que la date actuelle a dépassé la période de validité de la remise pour paiement comptant 1 ou 2. Cela signale une occasion d’économies manquée.
Pourquoi c’est important Alimente directement le Dashboard « Performance de capture des remises ». Permet de quantifier la perte financière due aux retards du processus. Où les obtenir Calculé en ajoutant BSEG-ZBD1T (jours) à BKPF-BLDAT (date du document), puis en comparant le résultat à la date actuelle ou à la date de paiement. Collecte Dérivé de la comparaison du champ X avec le champ Y Type d’événement calculated
	Données de facture modifiées	Capture les modifications manuelles apportées aux données d’en-tête ou de poste de la facture après la comptabilisation initiale. Les changements courants concernent les numéros de référence, les champs de texte ou les codes de taxe.
Pourquoi c’est important Indique une reprise et une intervention manuelle dans le processus. Des modifications fréquentes révèlent des problèmes de qualité des données à la source ou une validation insuffisante lors de la saisie initiale. Où les obtenir Documents de modification (CDHDR/CDPOS) pour l’objet BELEG, à l’exclusion des modifications de la clé de blocage. Collecte Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Facture mise en attente	Indique qu’une facture a été enregistrée comme brouillon sans générer d’écritures comptables. Ce statut permet d’interrompre la saisie ou de procéder à une vérification avant la comptabilisation finale.
Pourquoi c’est important Identifie les factures qui restent dans un état préliminaire et retardent le délai de paiement. Un volume élevé à ce stade suggère une saisie inefficace ou des exigences d’approbation peu claires. Où les obtenir Table VBKPF ou BKPF lorsque BSTAT est égal à « V ». Collecte Comparer le champ de statut avant et après Type d’événement inferred
	Proposition de paiement créée	Indique que la facture a été sélectionnée par le programme de paiement automatique (F110) pour un paiement potentiel. Elle figure désormais sur une liste préliminaire de paiements.
Pourquoi c’est important Signale le passage de l’état « À payer » à l’état « En cours de paiement ». Cette visibilité aide la trésorerie à gérer les besoins de liquidités avant la sortie effective des fonds. Où les obtenir Date de création dans la table REGUH (données de règlement du programme de paiement). Collecte Enregistré lors de l’exécution de la transaction X Type d’événement explicit

Recommandé Facultatif

Guides d'extraction

Comment extraire vos données de SAP ECC

Étapes

Accédez au code de transaction SQVI (QuickViewer) dans votre système SAP ECC.
Saisissez un nom pour votre vue, par exemple Z_AP_MINING, puis cliquez sur Create. Dans la fenêtre contextuelle Data Source, sélectionnez Table Join.
Dans l'écran de définition de la jointure, accédez à Edit, Insert Table. Ajoutez la table BKPF (Accounting Document Header) et la table BSAK (Accounting: Secondary Index for Vendors). Notez que BSAK contient les postes lettrés ; si vous avez besoin des postes ouverts, une extraction distincte ou une union avec la table BSIK est généralement nécessaire. Ce guide porte toutefois sur l'historique des postes lettrés de BSAK.
Vérifiez les conditions de liaison entre BKPF et BSAK. Assurez-vous que les tables sont jointes par le code société (BUKRS), le numéro de document comptable (BELNR) et l'exercice fiscal (GJAHR). Le système les propose généralement automatiquement.
Revenez à l'écran principal de définition pour sélectionner vos Output Fields (List fields) et Selection Fields (Filter fields).
Dans la liste Available Fields à gauche, sélectionnez les colonnes essentielles suivantes pour les List fields : BKPF-BELNR (Invoice Number), BKPF-BUKRS (Company Code), BKPF-GJAHR (Fiscal Year), BKPF-BLDAT (Document Date), BKPF-BUDAT (Posting Date), BKPF-CPUDT (Entry Date), BKPF-CPUTM (Entry Time), BKPF-USNAM (User Name), BKPF-XBLNR (Reference/Invoice ID), BKPF-AWKEY (Object Key), BSAK-LIFNR (Vendor), BSAK-AUGDT (Clearing Date), BSAK-AUGBL (Clearing Doc), BSAK-DMBTR (Amount), BSAK-WAERS (Currency), BSAK-ZFBDT (Baseline Date), BSAK-ZBD1T (Terms 1), BSAK-ZLSPR (Payment Block), BSAK-ZLSCH (Payment Method).
Enregistrez la QuickView et cliquez sur Execute (F8).
Dans l'écran de sélection, saisissez votre code société et un exercice fiscal ou une plage de dates de comptabilisation pertinents, par exemple les 12 derniers mois.
Exécutez le rapport pour générer la liste. Une fois celle-ci affichée, accédez à List, Export, Spreadsheet pour enregistrer les données brutes dans un fichier Excel ou CSV.
SQVI produisant une liste à plat, avec une ligne par facture, vous devez transformer ces données au format Event Log, avec une ligne par activité, afin de respecter les exigences de ProcessMind. Utilisez la logique SQL fournie dans la section Query ci-dessous pour transformer votre feuille de calcul exportée.

Configuration

Configuration de la jointure : Inner Join entre BKPF (Header) et BSAK (Vendor Cleared Items) sur BUKRS, BELNR et GJAHR.
Plage de dates : il est recommandé de filtrer sur la date de comptabilisation (BUDAT) des 6 à 12 derniers mois afin de maîtriser la taille de la liste.
Périmètre : cette extraction porte sur BSAK. Seules les factures ayant terminé le cycle, c'est-à-dire lettrées ou payées, apparaîtront. Les factures ouvertes (BSIK) sont exclues de cette configuration.
Sélection des champs : vérifiez que la date du document, la date de comptabilisation, la date de saisie et la date de lettrage sont toutes sélectionnées pour alimenter les horodatages des événements.
Autorisations : l'accès à la transaction SQVI et les autorisations d'affichage des tables financières sont nécessaires.

a Exemple de requête sql

/* 
  POST-EXTRACTION TRANSFORMATION SCRIPT
  Apply this SQL logic to the raw Excel export from SQVI to generate the Event Log.
  Input Table Name: [Raw_SQVI_Export]
*/

/* 1. Invoice Receipt Recorded */
SELECT
  "Invoice Number" AS InvoiceNumber,
  'Invoice Receipt Recorded' AS ActivityName,
  CAST("Document Date" AS DATETIME) AS EventTimestamp,
  'SAP ECC' AS SourceSystem,
  GETDATE() AS LastDataUpdate,
  "Company Code" AS CompanyCode,
  "Vendor" AS VendorNumber,
  "Amount" AS InvoiceAmount,
  "Currency" AS Currency
FROM [Raw_SQVI_Export]
WHERE "Document Date" IS NOT NULL

UNION ALL

/* 2. Invoice Created */
SELECT
  "Invoice Number",
  'Invoice Created',
  CAST(CONCAT("Entry Date", ' ', "Entry Time") AS DATETIME),
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE "Entry Date" IS NOT NULL

UNION ALL

/* 3. Invoice Parked */
/* Limitation: Historical park status is not preserved in BSAK. Utilizing Entry Date as proxy if distinct from Posting. */
SELECT
  "Invoice Number",
  'Invoice Parked',
  CAST(CONCAT("Entry Date", ' ', "Entry Time") AS DATETIME),
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE "Entry Date" < "Posting Date"

UNION ALL

/* 4. Invoice Posted */
SELECT
  "Invoice Number",
  'Invoice Posted',
  CAST("Posting Date" AS DATETIME),
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE "Posting Date" IS NOT NULL

UNION ALL

/* 5. Payment Block Applied */
/* Limitation: Only shows current block status (ZLSPR) on the cleared item. */
SELECT
  "Invoice Number",
  'Payment Block Applied',
  CAST("Posting Date" AS DATETIME),
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE "Payment Block" IS NOT NULL AND "Payment Block" <> ''

UNION ALL

/* 6. Invoice Data Changed */
/* Limitation: Cannot be extracted via SQVI BKPF/BSAK join. Requires CDHDR table. Row excluded or placeholder. */
SELECT
  "Invoice Number",
  'Invoice Data Changed',
  NULL,
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE 1=0

UNION ALL

/* 7. Payment Term Changed */
/* Limitation: Requires Change Log extraction. */
SELECT
  "Invoice Number",
  'Payment Term Changed',
  NULL,
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE 1=0

UNION ALL

/* 8. Payment Block Removed */
/* Limitation: Requires Change Log extraction. */
SELECT
  "Invoice Number",
  'Payment Block Removed',
  NULL,
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE 1=0

UNION ALL

/* 9. Payment Proposal Created */
/* Proxy: Uses Clearing Date minus 1 day as estimation since REGUH table is not in join. */
SELECT
  "Invoice Number",
  'Payment Proposal Created',
  DATEADD(day, -1, CAST("Clearing Date" AS DATETIME)),
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE "Clearing Date" IS NOT NULL

UNION ALL

/* 10. Payment Posted */
/* Logic: Uses Clearing Date as the effective payment date. */
SELECT
  "Invoice Number",
  'Payment Posted',
  CAST("Clearing Date" AS DATETIME),
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE "Clearing Date" IS NOT NULL AND "Clearing Doc" IS NOT NULL

UNION ALL

/* 11. Invoice Cleared */
SELECT
  "Invoice Number",
  'Invoice Cleared',
  CAST("Clearing Date" AS DATETIME),
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE "Clearing Date" IS NOT NULL

UNION ALL

/* 12. Discount Due Date Passed */
/* Logic: Checks if Clearing Date > (Baseline Date + Term 1 Days). */
SELECT
  "Invoice Number",
  'Discount Due Date Passed',
  DATEADD(day, CAST("Terms 1" AS INT), CAST("Baseline Date" AS DATETIME)),
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE "Clearing Date" > DATEADD(day, CAST("Terms 1" AS INT), CAST("Baseline Date" AS DATETIME))

UNION ALL

/* 13. Due Date Passed */
/* Logic: Checks if Clearing Date > Net Due Date. */
SELECT
  "Invoice Number",
  'Due Date Passed',
  DATEADD(day, CAST("Terms 1" AS INT) + CAST("Terms 2" AS INT), CAST("Baseline Date" AS DATETIME)),
  'SAP ECC',
  GETDATE(),
  "Company Code",
  "Vendor",
  "Amount",
  "Currency"
FROM [Raw_SQVI_Export]
WHERE "Clearing Date" > DATEADD(day, CAST("Terms 1" AS INT) + CAST("Terms 2" AS INT), CAST("Baseline Date" AS DATETIME))

Étapes

Mise en place des prérequis : vérifiez que Python est installé avec les bibliothèques pyrfc et pandas. Le SAP NetWeaver RFC SDK doit être installé sur la machine qui exécute le script. Le compte utilisateur SAP doit disposer des autorisations nécessaires pour le module de fonction RFC_READ_TABLE ainsi que d'un accès en lecture aux tables BKPF, BSAK, BSIK, REGUH, CDHDR, CDPOS et VBKPF.
Configuration de la connexion : mettez à jour les paramètres de connexion du script, aux lignes 15 à 22, avec l'hôte SAP ECC, le numéro de système, le client, l'utilisateur et le mot de passe correspondants. Définissez les variables TargetCompanyCode et DateFrom/DateTo pour préciser le périmètre de l'extraction.
Vue d'ensemble de la logique du script : le script effectue une extraction séquentielle. Il récupère d'abord les en-têtes de facture (BKPF) et les postes (BSAK/BSIK) afin de constituer la population de base. Il interroge ensuite les données de paiement (REGUH) et les journaux de modifications (CDHDR/CDPOS), en les limitant aux documents trouvés lors de la première étape afin de réduire les transferts de données.
Gestion des limites de largeur des tables : la fonction RFC_READ_TABLE standard impose souvent une limite de 512 octets par ligne. Le script comprend une fonction auxiliaire qui demande des colonnes précises afin que la réponse respecte cette limite. Il crée un DataFrame pandas pour chaque table.
Transformation des données : le script fusionne les données d'en-tête et de postes pour créer un « Process Object ». Il parcourt ensuite cet objet afin de générer les horodatages standard des activités Created, Posted et Receipt. Il calcule les dates d'échéance et les dates limites d'escompte à partir des conditions de paiement.
Analyse du journal des modifications : le script traite les données CDHDR et CDPOS afin d'identifier les modifications de champs. Il associe les modifications de « ZLSPR » aux activités Payment Block Applied/Removed et les modifications de « ZTERM » aux activités Payment Term Changed.
Construction de l'Event Log : toutes les activités dérivées sont ajoutées à une liste principale d'événements. Cette liste est convertie en DataFrame pandas final contenant les colonnes requises : InvoiceNumber, ActivityName, EventTimestamp, SourceSystem, etc.
Exportation : la dernière étape du script exporte le DataFrame dans un fichier CSV nommé sap_ap_event_log.csv. Ce fichier est formaté et prêt à être importé dans ProcessMind.
Exécution du script : exécutez le script en ligne de commande : python sap_ap_extraction.py. Surveillez la console pour suivre les journaux de progression indiquant le nombre d'enregistrements récupérés dans chaque table.
Validation : ouvrez le fichier CSV généré. Vérifiez que les dates sont au format ISO et que « Invoice Amount » est correctement formaté comme un nombre flottant. Vérifiez que la colonne « ActivityName » contient un ensemble des 13 types d'activité définis.

Configuration

RFC_READ_TABLE : ce module de fonction standard doit être actif et accessible. Si votre système utilise une copie personnalisée, par exemple /SAPDS/RFC_READ_TABLE, pour prendre en charge des lignes plus larges, mettez à jour le nom de la fonction dans le script.
Plage de dates : une fenêtre d'extraction de 3 à 6 mois est recommandée. L'extraction de CDHDR/CDPOS sur une période supérieure à 6 mois via RFC peut être extrêmement lente et entraîner un dépassement du délai d'attente.
Filtre sur le code société : filtrez toujours sur le code société (BUKRS) afin de limiter le jeu de données aux entités financières concernées.
Traitement par lots : dans les systèmes à fort volume, modifiez le script pour parcourir les dates jour par jour plutôt que d'interroger une longue période en une seule fois, afin d'éviter les problèmes de mémoire.
Objets du journal des modifications : le script filtre CDHDR sur la classe d'objet « BELEG ». Vérifiez que les modifications de vos documents financiers sont enregistrées sous cette classe d'objet standard.

a Exemple de requête python

import sys
from datetime import datetime, timedelta
import pandas as pd
from pyrfc import Connection

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
SAP_CONN_PARAMS = {
    class="hl-string">'user': class="hl-string">'YOUR_USER',
    class="hl-string">'passwd': class="hl-string">'YOUR_PASSWORD',
    class="hl-string">'ashost': class="hl-string">'YOUR_SAP_HOST',
    class="hl-string">'sysnr': class="hl-string">'00',
    class="hl-string">'client': class="hl-string">'100',
    class="hl-string">'lang': class="hl-string">'EN'
}

TARGET_COMPANY_CODE = class="hl-string">'1000'
DATE_FROM = class="hl-string">'20230101'
DATE_TO = class="hl-string">'20230131'
SOURCE_SYSTEM_ID = class="hl-string">'SAP_ECC_01'

class=class="hl-string">"hl-comment"># === RFC HELPER ===
def read_table(conn, table_name, fields, options, row_limit=0):
    class="hl-string">"""Reads SAP table via RFC_READ_TABLE and returns a DataFrame."""
    print(fclass="hl-string">"Reading {table_name}...")
    
    class=class="hl-string">"hl-comment"># Format fields for RFC
    rfc_fields = [{class="hl-string">'FIELDNAME': f} for f in fields]
    
    class=class="hl-string">"hl-comment"># Call RFC
    try:
        result = conn.call(class="hl-string">'RFC_READ_TABLE',
                           QUERY_TABLE=table_name,
                           DELIMITER=class="hl-string">';',
                           FIELDS=rfc_fields,
                           OPTIONS=[{class="hl-string">'TEXT': o} for o in options],
                           ROWCOUNT=row_limit)
    except Exception as e:
        print(fclass="hl-string">"Error reading {table_name}: {e}")
        return pd.DataFrame()

    class=class="hl-string">"hl-comment"># Parse output
    data = []
    headers = [f[class="hl-string">'FIELDNAME'] for f in result[class="hl-string">'FIELDS']]
    
    for line in result[class="hl-string">'DATA']:
        class=class="hl-string">"hl-comment"># Simple split by delimiter; robust parsing handles fixed width if delimiter fails, 
        class=class="hl-string">"hl-comment"># but semicolon is standard for this approach.
        values = line[class="hl-string">'WA'].split(class="hl-string">';')
        class=class="hl-string">"hl-comment"># Handle cases where split might be shorter if trailing fields are empty
        if len(values) < len(headers):
            values += [class="hl-string">''] * (len(headers) - len(values))
        data.append(dict(zip(headers, values)))
        
    return pd.DataFrame(data)

def main():
    class=class="hl-string">"hl-comment"># 1. Connect to SAP
    try:
        conn = Connection(**SAP_CONN_PARAMS)
    except Exception as e:
        print(fclass="hl-string">"Connection failed: {e}")
        return

    class=class="hl-string">"hl-comment"># 2. Extract BKPF (Header)
    class=class="hl-string">"hl-comment"># Filters: Company Code and Entry Date (CPUDT)
    bkpf_fields = [class="hl-string">'BUKRS', class="hl-string">'BELNR', class="hl-string">'GJAHR', class="hl-string">'BLART', class="hl-string">'BLDAT', class="hl-string">'BUDAT', class="hl-string">'CPUDT', class="hl-string">'CPUTM', class="hl-string">'USNAM']
    bkpf_opts = [
        fclass="hl-string">"BUKRS = '{TARGET_COMPANY_CODE}' AND CPUDT >= '{DATE_FROM}' AND CPUDT <= '{DATE_TO}'"
    ]
    df_bkpf = read_table(conn, class="hl-string">'BKPF', bkpf_fields, bkpf_opts)
    
    if df_bkpf.empty:
        print(class="hl-string">"No documents found.")
        return

    class=class="hl-string">"hl-comment"># 3. Extract Vendor Line Items (BSAK - Cleared, BSIK - Open)
    class=class="hl-string">"hl-comment"># To avoid huge queries, we filter BSIK/BSAK by the same date range or join later.
    class=class="hl-string">"hl-comment"># For robustness in RFC, we filter by BUKRS and Date range on CPU date or BUDAT similar to BKPF
    item_fields = [class="hl-string">'BUKRS', class="hl-string">'BELNR', class="hl-string">'GJAHR', class="hl-string">'BUZEI', class="hl-string">'LIFNR', class="hl-string">'DMBTR', class="hl-string">'WAERS', class="hl-string">'ZFBDT', class="hl-string">'ZTERM', class="hl-string">'ZBD1T', class="hl-string">'ZBD2T', class="hl-string">'ZLSPR', class="hl-string">'AUGDT', class="hl-string">'AUGBL']
    
    class=class="hl-string">"hl-comment"># Note: BSIK/BSAK are huge. In production, chunk by BELNR list derived from BKPF or Date.
    class=class="hl-string">"hl-comment"># Here we use the date range on BUDAT for simplicity of the example.
    item_opts = [
        fclass="hl-string">"BUKRS = '{TARGET_COMPANY_CODE}' AND BUDAT >= '{DATE_FROM}' AND BUDAT <= '{DATE_TO}'"
    ]
    
    df_bsik = read_table(conn, class="hl-string">'BSIK', item_fields, item_opts)
    df_bsak = read_table(conn, class="hl-string">'BSAK', item_fields, item_opts)
    
    class=class="hl-string">"hl-comment"># Combine Open and Cleared items
    df_items = pd.concat([df_bsik, df_bsak], ignore_index=True)
    
    class=class="hl-string">"hl-comment"># Filter items to only those present in our BKPF fetch (Inner Join logic)
    df_items = df_items[df_items[class="hl-string">'BELNR'].isin(df_bkpf[class="hl-string">'BELNR'])]

    class=class="hl-string">"hl-comment"># 4. Extract Payment Data (REGUH)
    class=class="hl-string">"hl-comment"># Filter by Date range roughly matching the process
    reguh_fields = [class="hl-string">'LAUFD', class="hl-string">'LAUFI', class="hl-string">'XVORL', class="hl-string">'VBLNR', class="hl-string">'LIFNR']
    reguh_opts = [
        fclass="hl-string">"LAUFD >= '{DATE_FROM}'"
    ]
    df_reguh = read_table(conn, class="hl-string">'REGUH', reguh_fields, reguh_opts)

    class=class="hl-string">"hl-comment"># 5. Extract Change History (CDHDR/CDPOS)
    class=class="hl-string">"hl-comment"># This is expensive. Filter by OBJECTCLAS class="hl-string">'BELEG' and Date.
    cdhdr_fields = [class="hl-string">'OBJECTCLAS', class="hl-string">'OBJECTID', class="hl-string">'CHANGENR', class="hl-string">'UDATE', class="hl-string">'UTIME', class="hl-string">'USERNAME']
    cdhdr_opts = [
        fclass="hl-string">"OBJECTCLAS = 'BELEG' AND UDATE >= '{DATE_FROM}'"
    ]
    df_cdhdr = read_table(conn, class="hl-string">'CDHDR', cdhdr_fields, cdhdr_opts)
    
    class=class="hl-string">"hl-comment"># Filter CDHDR to only relevant Invoice Numbers (OBJECTID usually contains BELNR + GJAHR)
    class=class="hl-string">"hl-comment"># Construct OBJECTID list from BKPF
    valid_object_ids = set(df_bkpf[class="hl-string">'BELNR'] + df_bkpf[class="hl-string">'GJAHR'])
    df_cdhdr = df_cdhdr[df_cdhdr[class="hl-string">'OBJECTID'].isin(valid_object_ids)]
    
    if not df_cdhdr.empty:
        class=class="hl-string">"hl-comment"># Get CDPOS for these changes
        class=class="hl-string">"hl-comment"># Cannot pass thousands of CHANGENR. Split if needed. 
        class=class="hl-string">"hl-comment"># Here assuming volume allows single fetch or loop.
        change_nums = df_cdhdr[class="hl-string">'CHANGENR'].unique().tolist()
        class=class="hl-string">"hl-comment"># Chunking needed for production
        cdpos_fields = [class="hl-string">'OBJECTCLAS', class="hl-string">'OBJECTID', class="hl-string">'CHANGENR', class="hl-string">'TABNAME', class="hl-string">'FNAME', class="hl-string">'VALUE_NEW', class="hl-string">'VALUE_OLD']
        df_cdpos = pd.DataFrame()
        
        class=class="hl-string">"hl-comment"># Simple chunk loop
        chunk_size = 100
        for i in range(0, len(change_nums), chunk_size):
            chunk = change_nums[i:i + chunk_size]
            chunk_str = class="hl-string">"'".join(chunk)
            opts = [fclass="hl-string">"OBJECTCLAS = 'BELEG' AND CHANGENR IN ('{chunk_str}')"]
            df_chunk = read_table(conn, class="hl-string">'CDPOS', cdpos_fields, opts)
            df_cdpos = pd.concat([df_cdpos, df_chunk])
            
        class=class="hl-string">"hl-comment"># Merge CDHDR and CDPOS
        df_changes = pd.merge(df_cdpos, df_cdhdr, on=[class="hl-string">'OBJECTCLAS', class="hl-string">'OBJECTID', class="hl-string">'CHANGENR'])
    else:
        df_changes = pd.DataFrame(columns=[class="hl-string">'OBJECTID', class="hl-string">'FNAME', class="hl-string">'VALUE_NEW', class="hl-string">'VALUE_OLD', class="hl-string">'UDATE', class="hl-string">'UTIME', class="hl-string">'USERNAME'])

    class=class="hl-string">"hl-comment"># === PROCESS EVENTS ===
    events = []

    class=class="hl-string">"hl-comment"># Join Headers and Items
    class=class="hl-string">"hl-comment"># Ensure key columns are strings for merging
    df_full = pd.merge(df_bkpf, df_items, on=[class="hl-string">'BUKRS', class="hl-string">'BELNR', class="hl-string">'GJAHR'])

    for _, row in df_full.iterrows():
        invoice_num = row[class="hl-string">'BELNR']
        vendor = row[class="hl-string">'LIFNR']
        amount = row[class="hl-string">'DMBTR']
        
        class=class="hl-string">"hl-comment"># Common attributes
        base_attrs = {
            class="hl-string">'InvoiceNumber': invoice_num,
            class="hl-string">'SourceSystem': SOURCE_SYSTEM_ID,
            class="hl-string">'CompanyCode': row[class="hl-string">'BUKRS'],
            class="hl-string">'VendorNumber': vendor,
            class="hl-string">'InvoiceAmount': amount,
            class="hl-string">'DocumentType': row[class="hl-string">'BLART'],
            class="hl-string">'LastDataUpdate': datetime.now().isoformat()
        }

        class=class="hl-string">"hl-comment"># 1. Invoice Created
        events.append({
            **base_attrs,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Created',
            class="hl-string">'EventTimestamp': fclass="hl-string">"{row['CPUDT']}T{row['CPUTM']}",
            class="hl-string">'UserName': row[class="hl-string">'USNAM']
        })

        class=class="hl-string">"hl-comment"># 2. Invoice Receipt Recorded
        if row[class="hl-string">'BLDAT']:
            events.append({
                **base_attrs,
                class="hl-string">'ActivityName': class="hl-string">'Invoice Receipt Recorded',
                class="hl-string">'EventTimestamp': fclass="hl-string">"{row['BLDAT']}T00:00:00",
                class="hl-string">'UserName': row[class="hl-string">'USNAM']
            })

        class=class="hl-string">"hl-comment"># 3. Invoice Posted
        if row[class="hl-string">'BUDAT']:
            events.append({
                **base_attrs,
                class="hl-string">'ActivityName': class="hl-string">'Invoice Posted',
                class="hl-string">'EventTimestamp': fclass="hl-string">"{row['BUDAT']}T00:00:00",
                class="hl-string">'UserName': row[class="hl-string">'USNAM']
            })

        class=class="hl-string">"hl-comment"># 4. Invoice Cleared
        if row[class="hl-string">'AUGDT'] and row[class="hl-string">'AUGDT'] != class="hl-string">'00000000':
            events.append({
                **base_attrs,
                class="hl-string">'ActivityName': class="hl-string">'Invoice Cleared',
                class="hl-string">'EventTimestamp': fclass="hl-string">"{row['AUGDT']}T00:00:00",
                class="hl-string">'ClearingDate': row[class="hl-string">'AUGDT']
            })
            
            class=class="hl-string">"hl-comment"># 5. Payment Posted (Proxy via Clearing)
            class=class="hl-string">"hl-comment"># If cleared by payment document, assume Payment Posted same day
            events.append({
                **base_attrs,
                class="hl-string">'ActivityName': class="hl-string">'Payment Posted',
                class="hl-string">'EventTimestamp': fclass="hl-string">"{row['AUGDT']}T23:59:59"
            })

        class=class="hl-string">"hl-comment"># 6. Payment Proposal Created
        class=class="hl-string">"hl-comment"># Check REGUH
        class=class="hl-string">"hl-comment"># Logic: REGUH contains payment proposals. We link via VBLNR (Payment Doc) or LIFNR matches
        class=class="hl-string">"hl-comment"># Simplified: if we find a proposal for this vendor in the range
        class=class="hl-string">"hl-comment"># In practice, need tighter link via BSAK-AUGBL = REGUH-VBLNR
        if row[class="hl-string">'AUGBL']:
            prop = df_reguh[df_reguh[class="hl-string">'VBLNR'] == row[class="hl-string">'AUGBL']]
            if not prop.empty:
                 for _, p_row in prop.iterrows():
                    events.append({
                        **base_attrs,
                        class="hl-string">'ActivityName': class="hl-string">'Payment Proposal Created',
                        class="hl-string">'EventTimestamp': fclass="hl-string">"{p_row['LAUFD']}T00:00:00"
                    })

        class=class="hl-string">"hl-comment"># 7. Parked (Check if originally parked - simplified logic)
        class=class="hl-string">"hl-comment"># Requires VBKPF check or document status history. Omitted for brevity in this block, 
        class=class="hl-string">"hl-comment"># usually involves checking if document ID exists in VBKPF list.

        class=class="hl-string">"hl-comment"># 8-11. Change Log Activities
        class=class="hl-string">"hl-comment"># Filter changes for this document
        obj_id = row[class="hl-string">'BELNR'] + row[class="hl-string">'GJAHR']
        doc_changes = df_changes[df_changes[class="hl-string">'OBJECTID'] == obj_id]
        
        for _, chg in doc_changes.iterrows():
            ts = fclass="hl-string">"{chg['UDATE']}T{chg['UTIME']}"
            fname = chg[class="hl-string">'FNAME']
            
            if fname == class="hl-string">'ZLSPR':
                if chg[class="hl-string">'VALUE_OLD'] == class="hl-string">'' and chg[class="hl-string">'VALUE_NEW'] != class="hl-string">'':
                    events.append({**base_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Block Applied', class="hl-string">'EventTimestamp': ts, class="hl-string">'PaymentBlockCode': chg[class="hl-string">'VALUE_NEW']})
                elif chg[class="hl-string">'VALUE_OLD'] != class="hl-string">'' and chg[class="hl-string">'VALUE_NEW'] == class="hl-string">'':
                    events.append({**base_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Block Removed', class="hl-string">'EventTimestamp': ts})
            elif fname == class="hl-string">'ZTERM':
                events.append({**base_attrs, class="hl-string">'ActivityName': class="hl-string">'Payment Term Changed', class="hl-string">'EventTimestamp': ts})
            else:
                events.append({**base_attrs, class="hl-string">'ActivityName': class="hl-string">'Invoice Data Changed', class="hl-string">'EventTimestamp': ts})

        class=class="hl-string">"hl-comment"># 12. Due Date Passed (Calculated)
        class=class="hl-string">"hl-comment"># Calculate Net Due Date = Baseline Date (ZFBDT) + Max Days (ZBD1T or ZBD2T or ZBD3T)
        try:
            zfbdt = datetime.strptime(row[class="hl-string">'ZFBDT'], class="hl-string">'%Y%m%d')
            days = float(row[class="hl-string">'ZBD1T']) if row[class="hl-string">'ZBD1T'] else 0
            due_date = zfbdt + timedelta(days=days)
            
            class=class="hl-string">"hl-comment"># If today > due_date and not cleared (or cleared after due date)
            clearing_date = datetime.strptime(row[class="hl-string">'AUGDT'], class="hl-string">'%Y%m%d') if (row[class="hl-string">'AUGDT'] and row[class="hl-string">'AUGDT'] != class="hl-string">'00000000') else None
            check_date = clearing_date if clearing_date else datetime.now()
            
            if check_date > due_date:
                 events.append({
                    **base_attrs,
                    class="hl-string">'ActivityName': class="hl-string">'Due Date Passed',
                    class="hl-string">'EventTimestamp': due_date.isoformat()
                })
        except ValueError:
            pass class=class="hl-string">"hl-comment"># Handle date parsing errors

        class=class="hl-string">"hl-comment"># 13. Discount Due Date Passed
        class=class="hl-string">"hl-comment"># Logic similar to Due Date using discount terms

    class=class="hl-string">"hl-comment"># Finalize
    df_events = pd.DataFrame(events)
    print(fclass="hl-string">"Generated {len(df_events)} events.")
    df_events.to_csv(class="hl-string">'sap_ap_event_log.csv', index=False)

if __name__ == class="hl-string">'__main__':
    main()

Étapes

Vérifiez que Theobald Xtract Universal est installé, sous licence et autorisé à se connecter au système SAP ECC cible. Confirmez que l'utilisateur SAP peut lire les données configurées relatives aux documents comptables, aux fournisseurs, aux achats, aux paiements, au lettrage et à l'historique des modifications. Les autorisations exactes dépendent de la conception de votre sécurité SAP.
Dans Xtract Universal, créez ou sélectionnez une connexion SAP pour le client SAP ECC requis et définissez les identifiants de connexion selon la méthode approuvée par votre organisation. Ne placez pas les identifiants dans le SQL d'extraction. Notez l'identifiant du système SAP qui alimentera SourceSystem.
Créez un objet d'extraction Table dans Xtract Universal. Sélectionnez la ou les tables SAP contenant les données requises sur l'en-tête du document comptable, les postes fournisseurs, les paiements, le lettrage, les conditions de paiement, le blocage des paiements, l'historique des modifications et les propositions de paiement. Remplacez [Your table name] et chaque référence de champ entre crochets par les objets disponibles dans votre système SAP ECC. Les objets exacts varient selon la version, la solution sectorielle, le modèle documentaire et la configuration.
Configurez l'extraction incrémentielle à l'aide de l'horodatage de modification ou de la séquence de modification la plus fiable disponible dans les données sources sélectionnées. Stockez le dernier watermark d'extraction réussi en dehors de l'Event Log et utilisez-le dans [Last successful extraction timestamp]. Lorsque cela est possible, prévoyez une petite fenêtre de chevauchement, puis dédupliquez selon InvoiceNumber, ActivityName, EventTimestamp et l'identifiant de l'événement source afin d'éviter les mises à jour manquées en cas d'horodatages identiques ou de validations tardives.
Configurez les filtres d'extraction. Limitez le chargement initial à [Start date] et [End date], puis appliquez [Company Code filter] et [Document Type filter] lorsque cela est nécessaire. Utilisez une plage de dates source suffisamment large pour couvrir les activités historiques, car les dates de comptabilisation, de lettrage, de paiement et de modification peuvent différer de la date du document de facture.
Associez chaque enregistrement source aux colonnes d'événement normalisées InvoiceNumber, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName et ClearingDate. Préservez la précision d'origine des horodatages. Si une source ne fournit qu'une date, appliquez la convention horaire métier convenue et documentez-la, plutôt que de laisser entendre une heure exacte que SAP ne stocke pas.
Implémentez les 13 branches d'activité explicites dans la requête. Invoice Receipt Recorded utilise la date du document comptable comme date de référence. Invoice Created, Invoice Parked, Invoice Posted, Payment Block Applied, Invoice Data Changed, Payment Term Changed, Payment Block Removed, Payment Proposal Created, Payment Posted et Invoice Cleared doivent chacune être émises sous forme de lignes distinctes à partir des éléments probants correspondants. Discount Due Date Passed et Due Date Passed sont des lignes dérivées qui doivent être générées explicitement en comparant la date d'exécution de l'extraction aux dates d'échéance de l'escompte et du montant net.
Appliquez la conversion des types de données dans Xtract Universal ou dans la couche SQL en aval. Convertissez les dates et heures SAP en un type d'horodatage cohérent, normalisez les valeurs vides en NULL, préservez les zéros initiaux des identifiants et convertissez les montants avec les règles correctes de devise et de décimales. Ne concaténez pas plusieurs activités dans une seule ligne.
Configurez la planification du job Xtract Universal et sa destination. À chaque exécution, écrivez les lignes extraites dans la destination de staging approuvée, ne mettez à jour le watermark qu'après un chargement réussi et conservez l'horodatage d'exécution de l'extraction dans LastDataUpdate. Traitez les doublons créés par les fenêtres de chevauchement avant de publier l'Event Log.
Validez le résultat à l'aide des contrôles ci-dessous. Vérifiez que chaque activité requise est représentée comme valeur ActivityName, que InvoiceNumber est renseigné pour chaque événement et que les horodatages sont chronologiquement plausibles pour chaque facture.
Exportez ou publiez le résultat final sous forme de table à plat ou de fichier délimité, avec une ligne par événement et les noms de colonnes exactement requis. Préservez l'encodage UTF-8, la stabilité des types de colonnes et un format d'horodatage compatible ISO. Importez l'Event Log obtenu dans ProcessMind en utilisant InvoiceNumber comme identifiant de dossier, ActivityName comme activité et EventTimestamp comme horodatage de l'événement. ProcessMind lit ces lignes telles quelles et ne déduit pas les événements manquants.

Configuration

Objet d'extraction : utilisez un objet d'extraction Table de Theobald Xtract Universal. Les tables et les champs sources SAP exacts doivent être sélectionnés selon la version et la configuration de votre SAP ECC. Utilisez [Your table name] et [Configure based on your system] jusqu'à validation de la correspondance avec la source.
Mode incrémentiel : utilisez un horodatage de modification source, une séquence de modification ou un watermark fiable équivalent. Si seules des dates sont disponibles, utilisez une fenêtre de chevauchement et une déduplication déterministe. Ne faites pas progresser le watermark avant confirmation de la réussite du chargement dans la destination.
Plage de dates : pour le chargement initial, utilisez une période maîtrisée d'environ 3 à 6 mois. Étendez-la lorsque les conditions de paiement, le lettrage, les propositions de paiement ou l'historique des modifications peuvent intervenir longtemps après la création de la facture. Pour les chargements récurrents, utilisez le dernier watermark réussi, augmenté d'une période de chevauchement.
Code société : appliquez [Company Code filter] lorsque le périmètre du processus est limité à certains codes société. Conservez CompanyCode dans la sortie, même lorsqu'un seul code société est extrait.
Type de document : appliquez [Document Type filter] uniquement après avoir confirmé quels types de document correspondent aux factures et aux avoirs dans le système cible. Conservez DocumentType dans la sortie.
Périmètre des factures : utilisez, lorsque cela est nécessaire, le numéro du document comptable, le code société et l'exercice fiscal comme clé du document source, tout en publiant la valeur InvoiceNumber configurée comme identifiant de dossier ProcessMind. Si les numéros de facture ne sont pas uniques à l'échelle globale, vérifiez si InvoiceNumber doit être préfixé ou normalisé d'une autre manière.
Correspondance des activités : configurez des correspondances distinctes pour les 13 activités. Un statut source ou une modification de champ doit produire une ligne d'événement distincte. Ne comptez pas sur ProcessMind pour déduire Invoice Posted, Invoice Cleared, les approbations, les dépassements d'échéance ou d'autres événements.
Événements calculés : générez explicitement Discount Due Date Passed et Due Date Passed. Définissez si l'événement doit être émis une fois par facture, une fois par jalon d'échéance pertinent ou à chaque exécution de l'extraction. La conception recommandée émet chaque événement une seule fois, au premier franchissement du seuil, et conserve une clé d'événement pour la déduplication.
Gestion des horodatages : préservez la précision des dates et heures sources. Documentez toute heure métier par défaut utilisée lorsque SAP ne stocke qu'une date. Utilisez un fuseau horaire unique et conservez le fuseau horaire du système SAP ou la règle de conversion dans la documentation de l'extraction.
Conversion des données : préservez les zéros initiaux des identifiants SAP, convertissez les valeurs textuelles vides en NULL, validez l'échelle des devises et standardisez les dates et horodatages avant l'importation dans ProcessMind.
Performances : limitez les colonnes sources, appliquez les filtres de date et d'organisation dans SAP, effectuez des extractions incrémentielles, répartissez les chargements historiques volumineux et évitez les analyses complètes non filtrées des tables. Planifiez les chargements initiaux intensifs en dehors des périodes de pointe de traitement SAP.
Historique des modifications : Invoice Data Changed et Payment Term Changed nécessitent un historique des modifications source ou un élément d'audit équivalent. Si les documents de modification ne sont pas conservés ou accessibles, ces activités ne peuvent pas être reconstituées de manière fiable.
Proposition de paiement : Payment Proposal Created nécessite l'accès aux données de proposition du Automatic Payment Program. Un paiement comptabilisé ne suffit pas à prouver qu'une proposition a été créée.
Prérequis : confirmez la connectivité SAP ECC, les autorisations de lecture SAP nécessaires, l'accès aux données comptables et de paiement pertinentes, la licence Theobald Xtract Universal, une destination configurée, un espace de stockage du watermark ainsi que les autorisations nécessaires pour planifier et exécuter le job d'extraction.

a Exemple de requête sql

WITH source_documents AS (
    SELECT
        [Invoice Number] AS InvoiceNumber,
        [Company Code] AS CompanyCode,
        [Vendor Number] AS VendorNumber,
        [Document Type] AS DocumentType,
        [Invoice Amount] AS InvoiceAmount,
        [Purchase Order Number] AS PurchaseOrderNumber,
        [Payment Terms] AS PaymentTerms,
        [Payment Block Code] AS PaymentBlockCode,
        [Payment Method] AS PaymentMethod,
        [User Name] AS UserName,
        [Clearing Date] AS ClearingDate,
        [Document Date] AS DocumentDate,
        [Invoice Created Timestamp] AS InvoiceCreatedTimestamp,
        [Invoice Parked Timestamp] AS InvoiceParkedTimestamp,
        [Invoice Posted Timestamp] AS InvoicePostedTimestamp,
        [Payment Block Applied Timestamp] AS PaymentBlockAppliedTimestamp,
        [Invoice Data Changed Timestamp] AS InvoiceDataChangedTimestamp,
        [Payment Term Changed Timestamp] AS PaymentTermChangedTimestamp,
        [Payment Block Removed Timestamp] AS PaymentBlockRemovedTimestamp,
        [Payment Proposal Created Timestamp] AS PaymentProposalCreatedTimestamp,
        [Payment Posted Timestamp] AS PaymentPostedTimestamp,
        [Invoice Cleared Timestamp] AS InvoiceClearedTimestamp,
        [Discount Due Date 1] AS DiscountDueDate1,
        [Discount Due Date 2] AS DiscountDueDate2,
        [Net Due Date] AS NetDueDate,
        [Source Change Timestamp] AS SourceChangeTimestamp,
        [Source System] AS SourceSystem
    FROM [Your table name]
    WHERE [Source Change Timestamp] >= CAST('[Last successful extraction timestamp]' AS TIMESTAMP)
      AND [Source Change Timestamp] < CAST('[End timestamp]' AS TIMESTAMP)
      AND [Document Date] >= CAST('[Start date]' AS DATE)
      AND [Document Date] < CAST('[End date]' AS DATE)
      AND ([Company Code] IN ([Company Code filter]) OR [Company Code filter] IS NULL)
      AND ([Document Type] IN ([Document Type filter]) OR [Document Type filter] IS NULL)
),
base_events AS (
    SELECT InvoiceNumber, 'Invoice Receipt Recorded' AS ActivityName, CAST(DocumentDate AS TIMESTAMP) AS EventTimestamp, SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE DocumentDate IS NOT NULL
    UNION ALL
    SELECT InvoiceNumber, 'Invoice Created', InvoiceCreatedTimestamp, SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE InvoiceCreatedTimestamp IS NOT NULL
    UNION ALL
    SELECT InvoiceNumber, 'Invoice Parked', InvoiceParkedTimestamp, SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE InvoiceParkedTimestamp IS NOT NULL
    UNION ALL
    SELECT InvoiceNumber, 'Invoice Posted', InvoicePostedTimestamp, SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE InvoicePostedTimestamp IS NOT NULL
    UNION ALL
    SELECT InvoiceNumber, 'Payment Block Applied', PaymentBlockAppliedTimestamp, SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE PaymentBlockAppliedTimestamp IS NOT NULL
    UNION ALL
    SELECT InvoiceNumber, 'Invoice Data Changed', InvoiceDataChangedTimestamp, SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE InvoiceDataChangedTimestamp IS NOT NULL
    UNION ALL
    SELECT InvoiceNumber, 'Payment Term Changed', PaymentTermChangedTimestamp, SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE PaymentTermChangedTimestamp IS NOT NULL
    UNION ALL
    SELECT InvoiceNumber, 'Payment Block Removed', PaymentBlockRemovedTimestamp, SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE PaymentBlockRemovedTimestamp IS NOT NULL
    UNION ALL
    SELECT InvoiceNumber, 'Payment Proposal Created', PaymentProposalCreatedTimestamp, SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE PaymentProposalCreatedTimestamp IS NOT NULL
    UNION ALL
    SELECT InvoiceNumber, 'Payment Posted', PaymentPostedTimestamp, SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE PaymentPostedTimestamp IS NOT NULL
    UNION ALL
    SELECT InvoiceNumber, 'Invoice Cleared', InvoiceClearedTimestamp, SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE InvoiceClearedTimestamp IS NOT NULL
    UNION ALL
    SELECT InvoiceNumber, 'Discount Due Date Passed', CAST(CURRENT_DATE AS TIMESTAMP), SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE ClearingDate IS NULL AND ((DiscountDueDate1 IS NOT NULL AND CURRENT_DATE > DiscountDueDate1) OR (DiscountDueDate2 IS NOT NULL AND CURRENT_DATE > DiscountDueDate2))
    UNION ALL
    SELECT InvoiceNumber, 'Due Date Passed', CAST(CURRENT_DATE AS TIMESTAMP), SourceSystem, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName, ClearingDate FROM source_documents WHERE ClearingDate IS NULL AND NetDueDate IS NOT NULL AND CURRENT_DATE > NetDueDate
),
final_events AS (
    SELECT
        InvoiceNumber,
        ActivityName,
        EventTimestamp,
        SourceSystem,
        CAST(CURRENT_TIMESTAMP AS TIMESTAMP) AS LastDataUpdate,
        CompanyCode,
        VendorNumber,
        DocumentType,
        InvoiceAmount,
        PurchaseOrderNumber,
        PaymentTerms,
        PaymentBlockCode,
        PaymentMethod,
        UserName,
        ClearingDate,
        ROW_NUMBER() OVER (PARTITION BY InvoiceNumber, ActivityName, EventTimestamp ORDER BY EventTimestamp) AS DuplicateRank
    FROM base_events
    WHERE InvoiceNumber IS NOT NULL
      AND EventTimestamp IS NOT NULL
)
SELECT
    InvoiceNumber,
    ActivityName,
    EventTimestamp,
    SourceSystem,
    LastDataUpdate,
    CompanyCode,
    VendorNumber,
    DocumentType,
    InvoiceAmount,
    PurchaseOrderNumber,
    PaymentTerms,
    PaymentBlockCode,
    PaymentMethod,
    UserName,
    ClearingDate
FROM final_events
WHERE DuplicateRank = 1
ORDER BY InvoiceNumber, EventTimestamp, ActivityName;

Prêt à commencer ?

Téléchargez dès maintenant le modèle complet pour commencer à transformer vos données de comptes fournisseurs en analyses concrètes. Notre équipe vous accompagne à chaque étape de votre démarche de Process Mining.

Retour au guide d’amélioration Télécharger le modèle

Optimisez dès maintenant le traitement de vos paiements fournisseurs

Réduisez de 30 % la durée du cycle de paiement et éliminez les goulots d'étranglement dans SAP ECC.

Démarrer l'essai gratuit

Aucune carte bancaire requise. La configuration ne prend que quelques minutes.

Votre modèle de données pour le traitement des paiements fournisseurs

Votre modèle de données pour le traitement des paiements fournisseurs

Attributs du traitement des paiements fournisseurs

Activités du traitement des paiements fournisseurs

Guides d'extraction

Extraction de jointure de tables SAP QuickViewer SQVI

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant le protocole RFC_READ_TABLE

Étapes

Configuration

a Exemple de requête python

Extraction delta Theobald Xtract Universal

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Optimisez dès maintenant le traitement de vos paiements fournisseurs

Votre modèle de données pour le traitement des paiements fournisseurs

Votre modèle de données pour le traitement des paiements fournisseurs

Attributs du traitement des paiements fournisseurs

Activités du traitement des paiements fournisseurs

Guides d'extraction

Extraction de jointure de tables SAP QuickViewer SQVI

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant le protocole RFC_READ_TABLE

Étapes

Configuration

a Exemple de requête python

Extraction delta Theobald Xtract Universal

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Optimisez dès maintenant le traitement de vos paiements fournisseurs

Nous attachons de l’importance à votre confidentialité