> 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 paiement dans SAP ECC, en recensant les données et les jalons essentiels. Il présente une liste complète d’attributs et d’activités, ainsi que des conseils pratiques pour extraire les données et constituer un journal d’événements fiable. Suivez ce guide pour repérer les retards de paiement et optimiser vos opérations financières.

Champs de données essentiels à l’analyse des paiements
Jalons clés du processus pour suivre les flux de travail
Guide détaillé pour extraire les données de SAP ECC

Vous découvrez les journaux d’événements ? Découvrez comment créer 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 à extraire de votre système SAP ECC pour analyser en détail le cycle de paiement.

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 à partir du système source. Il permet d’évaluer la fraîcheur de l’analyse et de gérer les chargements incrémentiels. Dans les Dashboards, il aide à déterminer si les données affichées sont en temps réel ou correspondent à un instantané antérieur. Cette information est essentielle au suivi opérationnel des factures ouvertes. Pourquoi est-ce important ? Précise le contexte des délais et de la fiabilité des données. Où trouver ces données 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 eu lieu dans le système SAP. Il combine généralement les champs de date et d’heure système des tables concernées (par exemple, CPUDT et CPUTM). Il est essentiel au calcul de tous les indicateurs temporels, notamment le temps de cycle, le délai d’approbation et le débit du processus. Sans horodatages exacts, il est impossible de déterminer l’ordre des événements ou de mesurer l’efficacité. Pourquoi est-ce important ? Essentiel pour ordonner les événements et calculer les durées. Où trouver ces données 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 réalisée dans le processus.
Description Cet attribut décrit l’événement survenu dans le processus des comptes fournisseurs, par exemple « Facture comptabilisée », « Blocage du paiement appliqué » ou « Cycle de paiement exécuté ». Il définit les nœuds de la cartographie du processus. Lors de l’analyse, la séquence de ces activités permet de visualiser les variantes du processus, de repérer les boucles de reprise (par exemple, suppression d’un blocage suivie de sa réapplication) et de vérifier la conformité au flux de travail d’approbation standard. Pourquoi est-ce important ? Il détermine le flux du processus et permet de visualiser le parcours de la facture. Où trouver ces données Dérivé des codes de transaction (TCODE), des classes d’objets des documents de modification (CDHDR) ou des journaux de flux de travail Exemples Facture comptabiliséeBlocage du paiement suppriméModification du prix
	Numéro de facture InvoiceNumber	Identifiant unique du document de facture du fournisseur.
Description Cet attribut sert d’identifiant central de cas pour le processus des comptes fournisseurs. Dans SAP ECC, il s’agit techniquement d’une concaténation du mandant, du code société, de l’exercice fiscal et du numéro de document comptable (BELNR), afin de garantir son unicité dans tout le système. Il regroupe toutes les activités liées à une dette envers un fournisseur. L’analyse utilise ce champ pour suivre le cycle de vie complet d’une obligation de paiement. Les outils de Process Mining peuvent ainsi reconstituer l’historique d’une facture, depuis sa réception ou sa numérisation jusqu’à la comptabilisation de l’écriture de lettrage finale dans le grand livre. Pourquoi est-ce important ? Cette clé fondamentale permet de relier les événements, les changements de statut et les écritures comptables au sein d’une même instance de processus. Où trouver ces données Table BKPF de SAP ECC, 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 ou le mandant SAP ECC dont proviennent les données extraites. Dans les environnements comportant plusieurs systèmes, il est essentiel pour séparer les données et analyser les performances par région ou unité opérationnelle. Il permet de filtrer la vue du processus selon l’environnement concerné et garantit l’identification unique des cas lorsque plusieurs instances SAP sont intégrées au même modèle de données de Process Mining. Pourquoi est-ce important ? Garantit l’unicité des données et leur mise en contexte dans les environnements comportant plusieurs ERP. Où trouver ces données 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, le cas échéant, pour quelle raison.
Description Cet attribut (ZLSPR) contient le code qui empêche la sélection d’une facture par le cycle de paiement automatique (par exemple, « R » pour la vérification de facture, « A » pour un blocage). Le suivi de cet attribut est au cœur du Dashboard « Blocage des paiements et résolution des mises en attente ». Il permet aux analystes de repérer les causes les plus fréquentes de retard de paiement et de mesurer le temps passé par les factures en état de blocage. Pourquoi est-ce important ? Indicateur principal des difficultés du processus et des besoins d’intervention manuelle. Où trouver ces données Table BSEG de SAP ECC, 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 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 comparer les taux de retard de paiement ou d’automatisation entre différentes unités opérationnelles afin de repérer les meilleures performances et les points à améliorer. Pourquoi est-ce important ? Dimension principale pour comparer les performances des unités organisationnelles. Où trouver ces données Table BKPF de SAP ECC, champ BUKRS Exemples 1000US01DE10
	Conditions de paiement PaymentTerms	Code qui définit les conditions de paiement et les remises.
Description Cet attribut stocke 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 anticipé (par exemple, 2 % si le paiement intervient sous 10 jours). Il sert de référence au calcul du taux de remises obtenues pour paiement anticipé. L’analyse utilise ce code pour calculer la date de paiement cible et repérer les écarts qui entraînent des remises perdues ou des pénalités. Pourquoi est-ce important ? Définit l’échéance financière et les possibilités de remise. Où trouver ces données Table BSEG de SAP ECC, 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) indique la date à laquelle le poste ouvert a été lettré dans le grand livre, marquant ainsi la fin du processus de paiement. Il correspond à l’horodatage de fin de l’indicateur « Durée moyenne du cycle de facturation ». 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 est-ce important ? Marque la fin du processus financier. Où trouver ces données 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 bancaire 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 par mode de paiement » et l’indicateur du taux d’adoption des paiements électroniques. Il permet aux organisations de suivre le passage des chèques manuels, coûteux, aux virements électroniques, moins coûteux. Pourquoi est-ce important ? Suit l’efficacité et le coût de la phase d’exécution du paiement. Où trouver ces données Table BSEG ou BKPF de SAP ECC, champ ZLSCH Exemples CTU
	Montant de la facture InvoiceAmount	Montant total 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’incidence financière des inefficacités du processus. Utilisé dans l’association « Montant de l’activité », ce champ permet de calculer des indicateurs pondérés par la valeur. Par exemple, un retard de paiement sur une facture d’un montant élevé est plus important que sur une facture de faible montant. Il aide à prioriser les tâches en fonction de leur incidence sur le fonds de roulement. Pourquoi est-ce important ? Quantifie l’incidence financière de l’instance de processus. Où trouver ces données Table BSEG de SAP ECC, champ DMBTR (devise locale) ou WRBTR (devise du document) Exemples 1500.00230.5010500.00
	Nom d’utilisateur UserName	Identifiant de l’utilisateur qui a effectué l’activité.
Description Cet attribut identifie l’ID 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 » pour analyser le taux d’interventions manuelles et l’utilisation des ressources. Il permet de distinguer les utilisateurs système automatisés (traitements par lots) des personnes qui effectuent des ajustements manuels. Pourquoi est-ce important ? Permet d’analyser les ressources et de calculer le taux d’automatisation. Où trouver ces données Table BKPF de SAP ECC, champ USNAM, ou table CDHDR, champ USERNAME Exemples BSMITHWF-BATCHSAP_WORKER
	Numéro de commande d’achat PurchaseOrderNumber	Référence au 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 des comptes fournisseurs au processus d’approvisionnement. Il est essentiel au Dashboard « Rapprochement des commandes d’achat et audit des écarts ». Son analyse permet de calculer la part des factures associées à une commande d’achat et de comparer l’efficacité du traitement des factures avec et sans commande. Pourquoi est-ce important ? Relie les comptes fournisseurs à l’approvisionnement et permet de repérer les flux de travail associés au rapprochement. Où trouver ces données Table BSEG de SAP ECC, champ EBELN Exemples 45000123894500099221null
	Numéro de 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 référence du fournisseur, qui comprennent 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 de l’assistance aux fournisseurs » en permettant de relier les inefficacités du processus à des fournisseurs précis. Pourquoi est-ce important ? Permet d’analyser les performances du point de vue des fournisseurs. Où trouver ces données Table BSEG de SAP ECC, champ LIFNR, ou table 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) et les paiements (KZ). Il est essentiel de filtrer par type de document pour analyser correctement le temps de cycle, car les avoirs suivent un flux de processus différent de celui des factures standard. Ce filtre garantit la comparaison de processus similaires. Pourquoi est-ce important ? Permet de distinguer les flux financiers associés aux factures et aux avoirs. Où trouver ces données Table BKPF de SAP ECC, champ BLART Exemples KRREKG
	Avec commande d’achat IsPOBased	Indique si la facture est associée à une commande d’achat.
Description Cet attribut booléen est calculé en vérifiant si le champ du numéro de commande d’achat est renseigné. Il permet de distinguer les flux associés à une commande d’achat (MM-LIV) des flux sans commande d’achat (FI-AP). Cette distinction est essentielle pour l’analyse de l’efficacité du traitement des factures sans commande d’achat, car celles-ci nécessitent généralement davantage d’étapes d’approbation manuelles et présentent des temps de cycle plus longs. Pourquoi est-ce important ? Une distinction fondamentale pour analyser l’efficacité des processus. Où trouver ces données Calculé : vrai si EBELN n’est ni nul ni vide Exemples truefalse
	Code de devise CurrencyCode	Code de devise associé au montant de la facture.
Description Cet attribut (WAERS) indique la devise dans laquelle la facture a été émise (par exemple, USD ou EUR). Il permet de gérer les processus impliquant plusieurs devises. L’analyse peut s’en servir pour regrouper les dépenses par devise ou convertir les montants afin de consolider les rapports dans le Dashboard de suivi des flux de trésorerie et des paiements. Pourquoi est-ce important ? Nécessaire pour interpréter correctement les montants financiers. Où trouver ces données Table SAP ECC BKPF, champ WAERS Exemples USDEURGBP
	Date d’échéance nette NetDueDate	Date calculée à laquelle la facture doit être payée.
Description Cet attribut correspond à la date limite de paiement. Il est calculé en ajoutant le nombre maximal de jours de paiement prévu par les conditions de paiement à la date de base du paiement. Il sert de référence pour le suivi des retards de paiement et des pénalités. Sans ce champ calculé, il est impossible de repérer les factures dont le délai de service convenu n’a pas été respecté. Pourquoi est-ce important ? L’échéance à respecter pour l’ensemble du processus. Où trouver ces données 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) sert de point de départ au calcul de la date d’échéance nette et des dates limites de remise. Selon la configuration, il correspond généralement à la date de réception de la facture ou à la date du document. L’analyse du taux de retard de paiement repose sur ce champ. Si la date de référence est incorrecte, tous les calculs d’échéance qui en découlent ainsi que les indicateurs de retard seront faussés. Pourquoi est-ce important ? Date de référence pour tous les calculs d’ancienneté et d’échéance. Où trouver ces données Table BSEG de SAP ECC, 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 extrait par reconnaissance optique de caractères (OCR) lors de la création de la facture. Cet attribut est la clé principale de l’analyse de prévention des paiements en double. Des algorithmes recherchent plusieurs occurrences d’un même numéro de référence pour un même fournisseur et un même montant afin de signaler les paiements potentiellement en double. Pourquoi est-ce important ? Essentiel pour repérer les doublons et vérifier les factures de fournisseurs. Où trouver ces données Table BKPF de SAP ECC, champ XBLNR Exemples INV-2023-00199887766OCT-BILLING
	Paiement en retard IsLatePayment	Indique 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’attribut prend la valeur vrai. Il sert directement au calcul de l’indicateur de taux de retard de paiement. Ce champ pré-calculé simplifie la création des Dashboards : il suffit de compter les valeurs « vrai », sans écrire de logique complexe dans la couche de visualisation. Pourquoi est-ce important ? Simplifie le suivi des indicateurs de respect des délais. Où trouver ces données 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 déroulement complet des paiements fournisseurs.

7 Recommandé 6 Facultatif

	Activité	Description
	Blocage du paiement appliqué	Enregistre l’application d’un code de blocage du paiement à une ligne de facture. La facture ne peut alors pas être sélectionnée par le programme de paiement automatique.
Pourquoi est-ce important ? C’est l’une des principales causes de retard de paiement et de remises manquées. L’analyse du code de 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ù trouver ces données Documents de modification (CDHDR/CDPOS) pour l’objet BELEG, champ BSEG-ZLSPR (Payment Block Key). Données à recueillir 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, qui rend la facture admissible au prochain cycle de paiement. Dans de nombreuses configurations SAP, cette étape sert d’indicateur d’approbation.
Pourquoi est-ce important ? Cette étape marque la résolution des problèmes qui empêchaient le paiement. Le délai entre l’application et la suppression du blocage correspond au temps de résolution du goulot d’étranglement. Où trouver ces données Documents de modification (CDHDR/CDPOS) où la nouvelle valeur de BSEG-ZLSPR est vide. Données à recueillir Comparer le champ de statut avant et après Type d’événement inferred
	Facture comptabilisée	Indique que la facture a été comptabilisée dans le grand livre et les livres auxiliaires. Cette opération crée la dette dans le système.
Pourquoi est-ce important ? La facture est désormais officiellement reconnue comme une dette. Cette étape déclenche le calcul standard de l’ancienneté du paiement et de la date d’échéance. Où trouver ces données Création dans la table BKPF lorsque BSTAT est vide (comptabilisation standard). Données à recueillir 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 saisies dans SAP ECC. Cet horodatage marque le début du traitement numérique dans l’ERP.
Pourquoi est-ce important ? Cet horodatage est essentiel pour calculer le temps de traitement interne par rapport au temps d’attente total du fournisseur. Un délai important entre la réception et la création révèle des goulots d’étranglement en amont. Où trouver ces données Table BKPF, champs CPUDT (Entry Date) et CPUTM (Entry Time). Données à recueillir Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Facture lettrée	Écriture comptable qui associe le poste de facture au document de paiement et solde le poste ouvert. Cette étape clôt le cycle de vie de la facture.
Pourquoi est-ce important ? Marqueur de fin du processus. Il est essentiel pour calculer le temps de cycle de bout en bout et confirmer que la dette est éteinte. Où trouver ces données Le champ AUGDT (Clearing Date) de la table BSEG est renseigné. Données à recueillir Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Paiement comptabilisé	Exécution du cycle de paiement, qui déclenche le virement bancaire ou l’impression du chèque. Un document de paiement est alors généré dans le système.
Pourquoi est-ce important ? C’est le point de non-retour pour la sortie de trésorerie. Cet horodatage sert à calculer le temps de cycle réel du paiement et à vérifier le respect des échéances de remise. Où trouver ces données Table BKPF pour le document de paiement (type de document « ZP » ou équivalent). Données à recueillir Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Réception de la facture enregistrée	Enregistre comme date de référence la date indiquée sur la facture du fournisseur. Cette information provient du champ Document Date de l’en-tête du document comptable.
Pourquoi est-ce important ? Cette date sert de référence pour l’analyse de l’ancienneté et le contrôle du respect des délais de paiement des fournisseurs. L’écart entre cette date et la date de saisie révèle les retards liés au courrier ou à la numérisation. Où trouver ces données Table BKPF, champ BLDAT (Document Date). Données à recueillir Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Conditions de paiement modifiées	Événement de reprise précis 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 pour paiement anticipé.
Pourquoi est-ce important ? Cette modification sert souvent à prolonger artificiellement les délais de paiement ou à corriger des erreurs dans les données de référence. Elle a une incidence directe sur les prévisions de trésorerie et les indicateurs de remises obtenues. Où trouver ces données Documents de modification (CDHDR/CDPOS) pour le champ BSEG-ZTERM. Données à recueillir 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é qui indique que la facture reste ouverte après sa date d’échéance nette. La facture est alors signalée comme échue.
Pourquoi est-ce important ? Cet événement alimente l’analyse des retards de paiement. Son suivi permet de prévenir les tensions avec les fournisseurs et les éventuels frais de retard. Où trouver ces données Calculé en ajoutant BSEG-ZBD3T (jours nets) à la date de référence, puis en comparant le résultat à la date actuelle. Données à recueillir Déduire en comparant le champ X au champ Y Type d’événement calculated
	Données de facture modifiées	Enregistre les modifications manuelles apportées à l’en-tête ou aux postes de la facture après sa comptabilisation initiale. Les changements portent souvent sur les références, les champs de texte ou les codes de taxe.
Pourquoi est-ce important ? Ces modifications signalent des reprises et des interventions manuelles dans le processus. Leur fréquence peut révéler des problèmes de qualité des données à la source ou des contrôles insuffisants lors de la saisie initiale. Où trouver ces données Documents de modification (CDHDR/CDPOS) pour l’objet BELEG, à l’exclusion des modifications du code de blocage. Données à recueillir Enregistré lors de l’exécution de la transaction X Type d’événement explicit
	Échéance de remise dépassée	Événement calculé qui indique que la date actuelle dépasse la période de validité de la remise pour paiement anticipé 1 ou 2. Il signale une possibilité d’économie manquée.
Pourquoi est-ce important ? Cet événement alimente directement le Dashboard « Performance des remises obtenues ». Il permet de quantifier les pertes financières dues aux retards du processus. Où trouver ces données Calculé en ajoutant BSEG-ZBD1T (jours) à BKPF-BLDAT (Document Date), puis en comparant le résultat à la date actuelle ou à la date de paiement. Données à recueillir Déduire en comparant le champ X au champ Y Type d’événement calculated
	Facture mise en attente	Indique qu’une facture a été enregistrée en 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 définitive.
Pourquoi est-ce important ? Permet de repérer les factures à l’état préliminaire, qui retardent le début du délai de paiement. Un volume élevé peut signaler une saisie inefficace ou des exigences d’approbation peu claires. Où trouver ces données Table VBKPF ou BKPF lorsque BSTAT est égal à « V ». Données à recueillir Comparer le champ de statut avant et après Type d’événement inferred
	Proposition de paiement créée	Indique que le programme de paiement automatique (F110) a sélectionné la facture pour un paiement éventuel. Elle figure désormais sur une liste préliminaire de paiements.
Pourquoi est-ce important ? Cette étape marque le passage de « À payer » à « En cours de paiement ». Cette visibilité aide la trésorerie à anticiper ses besoins avant que les fonds ne quittent le compte. Où trouver ces données Date de création dans la table REGUH (données de règlement du programme de paiement). Données à recueillir 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 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, vous devrez généralement effectuer une extraction distincte ou combiner les données avec celles de la table BSIK. Ce guide porte toutefois sur l’historique des postes lettrés dans BSAK.
Vérifiez les conditions de liaison entre BKPF et BSAK. Assurez-vous que les tables sont jointes par société (BUKRS), numéro de pièce comptable (BELNR) et exercice (GJAHR). Le système propose généralement ces conditions automatiquement.
Revenez à l’écran principal de définition pour sélectionner les champs de sortie (Output Fields) et les champs de sélection (Selection Fields).
Dans la liste Available Fields à gauche, sélectionnez les colonnes suivantes pour les champs de sortie : BKPF-BELNR (numéro de facture), BKPF-BUKRS (société), BKPF-GJAHR (exercice), BKPF-BLDAT (date de pièce), BKPF-BUDAT (date comptable), BKPF-CPUDT (date de saisie), BKPF-CPUTM (heure de saisie), BKPF-USNAM (nom d’utilisateur), BKPF-XBLNR (référence/ID de facture), BKPF-AWKEY (clé d’objet), BSAK-LIFNR (fournisseur), BSAK-AUGDT (date de lettrage), BSAK-AUGBL (pièce de lettrage), BSAK-DMBTR (montant), BSAK-WAERS (devise), BSAK-ZFBDT (date de base), BSAK-ZBD1T (conditions 1), BSAK-ZLSPR (blocage de paiement), BSAK-ZLSCH (mode de paiement).
Enregistrez la QuickView, puis cliquez sur Execute (F8).
Dans l’écran de sélection, saisissez votre société et un exercice ou une plage de dates comptables pertinente (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 (une ligne par facture), vous devez transformer ces données en journal d’événements (une ligne par activité) pour répondre aux exigences de ProcessMind. Utilisez la requête SQL fournie dans la section Query ci-dessous pour transformer le fichier exporté.

Configuration

Configuration de la jointure : jointure interne entre BKPF (en-tête) et BSAK (postes fournisseurs lettrés) sur BUKRS, BELNR et GJAHR.
Plage de dates : il est recommandé de filtrer sur la date comptable (BUDAT) des 6 à 12 derniers mois afin de limiter la taille de la liste.
Périmètre : cette extraction porte sur BSAK. Elle ne comprend donc que les factures dont le cycle est terminé (lettrées/payées). Les factures ouvertes (BSIK) sont exclues de cette configuration.
Sélection des champs : veillez à sélectionner les dates de pièce, comptable, de saisie et de lettrage afin de déterminer les horodatages des événements.
Autorisations : l’accès à la transaction SQVI et l’autorisation d’afficher les tables financières sont nécessaires.

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

Installer les prérequis : vérifiez que Python est installé avec les bibliothèques pyrfc et pandas. Le SDK SAP NetWeaver RFC doit être installé sur la machine qui exécutera le script. Le compte utilisateur SAP doit disposer des autorisations nécessaires pour le module de fonction RFC_READ_TABLE et d’un accès en lecture aux tables BKPF, BSAK, BSIK, REGUH, CDHDR, CDPOS et VBKPF.
Configurer la connexion : mettez à jour les paramètres de connexion du script (lignes 15 à 22) avec l’hôte SAP ECC, le numéro de système, le client, le nom d’utilisateur et le mot de passe correspondant à votre environnement. Définissez les variables TargetCompanyCode et DateFrom/DateTo pour préciser le périmètre de l’extraction.
Comprendre le fonctionnement 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) pour constituer la population de base. Il interroge ensuite les données de paiement (REGUH) et les journaux de modifications (CDHDR/CDPOS), en filtrant les pièces trouvées à la première étape afin de limiter le transfert de données.
Gérer les limites de largeur des tables : la fonction standard RFC_READ_TABLE limite souvent les lignes à 512 octets. 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.
Transformer les données : le script fusionne les données d’en-tête et de poste pour créer un « objet de processus ». 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 de remise en fonction des conditions de paiement.
Analyser les journaux de modifications : le script traite les données CDHDR et CDPOS pour repérer les modifications de champs. Il associe les modifications de « ZLSPR » aux activités Payment Block Applied/Removed et celles de « ZTERM » à l’activité Payment Term Changed.
Construire le journal d’événements : toutes les activités dérivées sont ajoutées à une liste principale d’événements. Cette liste est convertie en DataFrame pandas final, qui contient les colonnes requises : InvoiceNumber, ActivityName, EventTimestamp, SourceSystem, etc.
Exporter les données : à la dernière étape, le 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écuter le script : lancez le script en ligne de commande avec python sap_ap_extraction.py. Suivez dans la console les journaux de progression indiquant le nombre d’enregistrements récupérés dans chaque table.
Valider les résultats : ouvrez le fichier CSV généré. Vérifiez que les dates sont au format ISO et que « Invoice Amount » est correctement formaté comme nombre à virgule flottante. Assurez-vous que la colonne « ActivityName » contient plusieurs 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 période d’extraction de 3 à 6 mois est recommandée. La récupération des données CDHDR/CDPOS via RFC sur une période de plus de 6 mois peut être extrêmement lente et entraîner un dépassement du délai d’attente.
Filtre par société : filtrez toujours par société (BUKRS) pour limiter le jeu de données aux entités financières concernées.
Extraction par lots : dans les systèmes à fort volume, modifiez le script pour traiter les dates une par une plutôt que d’interroger une longue période d’un seul coup, afin d’éviter les problèmes de mémoire.
Objets des journaux de modifications : le script filtre CDHDR selon la classe d’objet 'BELEG'. Vérifiez que les modifications de vos pièces financières sont enregistrées sous cette classe d’objet standard.

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. Assurez-vous que l’utilisateur SAP peut lire les données configurées relatives à la comptabilité, aux fournisseurs, aux achats, aux paiements, au lettrage et à l’historique des modifications. Les autorisations exactes dépendent de la configuration de sécurité de votre environnement SAP.
Dans Xtract Universal, créez ou sélectionnez une connexion SAP pour le client SAP ECC requis et configurez les identifiants de connexion selon la méthode approuvée. N’insérez pas d’identifiants dans la requête SQL d’extraction. Notez l’identifiant du système SAP qui alimentera SourceSystem.
Créez un objet d’extraction de table dans Xtract Universal. Sélectionnez la ou les tables SAP contenant les données requises sur les en-têtes de pièces comptables, les postes fournisseurs, les paiements, le lettrage, les conditions de paiement, les blocages de paiement, l’historique des modifications et les propositions de paiement. Remplacez [Your table name] et chaque référence de champ entre crochets dans la requête par les objets disponibles dans votre système SAP ECC. Ceux-ci varient selon la version, la solution sectorielle, le modèle de pièces et la configuration.
Configurez l’extraction incrémentielle à partir de l’horodatage de modification ou de la séquence de modifications la plus fiable disponible dans les données source sélectionnées. Stockez le dernier point de reprise d’extraction réussi en dehors du journal d’événements et utilisez-le dans [Last successful extraction timestamp]. Si possible, prévoyez une courte période de chevauchement, puis éliminez les doublons à partir de InvoiceNumber, ActivityName, EventTimestamp et de l’identifiant de l’événement source afin de ne pas manquer les mises à jour dues à des horodatages identiques ou à des 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] si nécessaire. Utilisez une plage de dates source suffisamment large pour les activités historiques, car les dates de comptabilisation, de lettrage, de paiement et de modification peuvent différer de la date de la pièce de facture.
Associez chaque enregistrement source aux colonnes d’événement normalisées suivantes : InvoiceNumber, ActivityName, EventTimestamp, SourceSystem, LastDataUpdate, CompanyCode, VendorNumber, DocumentType, InvoiceAmount, PurchaseOrderNumber, PaymentTerms, PaymentBlockCode, PaymentMethod, UserName et ClearingDate. Préservez la précision des horodatages source. Si la source ne fournit qu’une date, appliquez la convention horaire définie par l’entreprise et consignez-la, sans laisser entendre que SAP stocke une heure exacte.
Implémentez les 13 branches d’activité explicites de la requête. Invoice Receipt Recorded utilise la date de pièce 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 chacun être émis sur une ligne distincte, à partir des données source correspondantes. Discount Due Date Passed et Due Date Passed sont des événements calculés : générez-les explicitement en comparant la date d’exécution de l’extraction aux dates d’échéance applicables, pour la remise et le paiement net.
Convertissez les 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, remplacez les valeurs vides par NULL, préservez les zéros initiaux des identifiants et convertissez les montants selon les règles de devise et de décimales appropriées. Ne regroupez pas plusieurs activités sur une même ligne.
Configurez la planification et la destination de la tâche Xtract Universal. À chaque exécution, écrivez les lignes extraites dans la zone de préparation approuvée, ne mettez à jour le point de reprise qu’après le succès du chargement et conservez l’horodatage d’exécution de l’extraction dans LastDataUpdate. Éliminez les doublons créés par les périodes de chevauchement avant de publier le journal d’événements.
Validez les résultats à l’aide des contrôles ci-dessous. Vérifiez que chaque activité requise apparaît comme valeur de ActivityName, que InvoiceNumber est renseigné pour chaque événement et que les horodatages suivent un ordre chronologique plausible 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 exacts requis. Préservez l’encodage UTF-8, la stabilité des types de colonnes et un format d’horodatage compatible avec ISO. Importez le journal d’événements obtenu dans ProcessMind en associant InvoiceNumber à l’identifiant du cas, ActivityName à l’activité et EventTimestamp à l’horodatage de l’événement. ProcessMind lit les lignes telles qu’elles sont fournies et ne déduit pas les événements manquants.

Configuration

Objet d’extraction : utilisez un objet d’extraction de table Theobald Xtract Universal. Sélectionnez les tables et champs SAP source en fonction de la version et de la configuration de votre système SAP ECC. Tant que l’association avec les sources n’est pas confirmée, utilisez [Your table name] et [Configure based on your system].
Mode incrémentiel : utilisez un horodatage de modification source, une séquence de modifications ou un point de reprise équivalent et fiable. Si seules des dates sont disponibles, prévoyez une période de chevauchement et une déduplication déterministe. Ne mettez pas à jour le point de reprise avant d’avoir confirmé la réussite du chargement dans la destination.
Plage de dates : pour le chargement initial, choisissez une période maîtrisée d’environ 3 à 6 mois. Étendez-la si les conditions de paiement, le lettrage, les propositions de paiement ou l’historique des modifications peuvent intervenir bien après la création de la facture. Pour les chargements récurrents, reprenez au dernier point de reprise réussi en ajoutant une période de chevauchement.
Société : appliquez [Company Code filter] si le périmètre du processus se limite à certaines sociétés. Conservez CompanyCode dans les données de sortie, même si une seule société est extraite.
Type de pièce : appliquez [Document Type filter] uniquement après avoir confirmé quels types de pièces correspondent aux factures et aux avoirs dans le système cible. Conservez DocumentType dans les données de sortie.
Périmètre des factures : utilisez le numéro de pièce comptable, la société et l’exercice comme clé de pièce source, si nécessaire, tout en publiant la valeur InvoiceNumber configurée comme identifiant de cas dans ProcessMind. Si les numéros de facture ne sont pas uniques à l’échelle du système, vérifiez s’il faut ajouter un préfixe à InvoiceNumber ou le normaliser autrement.
Association des activités : configurez une association distincte pour chacune des 13 activités. Tout changement de statut ou de champ dans la source doit produire une ligne d’événement distincte. Ne comptez pas sur ProcessMind pour déduire les événements Invoice Posted, Invoice Cleared, d’approbation, de dépassement d’échéance ou autres.
É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 échéance pertinente ou à chaque exécution de l’extraction. La méthode recommandée consiste à émettre chaque événement une seule fois, au premier dépassement du seuil, et à stocker une clé d’événement pour éliminer les doublons.
Gestion des horodatages : préservez la précision des dates et heures source. Consignez toute heure par défaut définie par l’entreprise lorsque SAP ne stocke qu’une date. Utilisez un seul fuseau horaire et documentez le fuseau horaire du système SAP ou la règle de conversion appliquée.
Conversion des données : préservez les zéros initiaux des identifiants SAP, convertissez les champs de texte vides en NULL, vérifiez l’échelle des devises et normalisez les dates et horodatages avant l’importation dans ProcessMind.
Performances : limitez les colonnes source, appliquez les filtres de date et d’organisation dans SAP, procédez par extraction incrémentielle, répartissez les chargements historiques volumineux et évitez les analyses complètes de tables sans filtre. Planifiez les chargements initiaux les plus lourds 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 une piste d’audit équivalente. Si les pièces de modification ne sont pas conservées ou accessibles, ces activités ne peuvent pas être reconstituées de manière fiable.
Proposition de paiement : l’activité Payment Proposal Created nécessite l’accès aux données de proposition du programme de paiements automatiques. La comptabilisation d’un paiement ne suffit pas à prouver qu’une proposition a été créée.
Prérequis : vérifiez la connectivité SAP ECC, les autorisations de lecture SAP requises, l’accès aux données comptables et de paiement concernées, la licence Theobald Xtract Universal, la configuration d’une destination, le stockage du point de reprise et les autorisations nécessaires pour planifier et exécuter la tâche d’extraction.

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 le modèle complet pour commencer à transformer vos données de comptabilité 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 des paiements fournisseurs

Réduisez de 30 % le temps de cycle des paiements et éliminez les goulots d’étranglement dans SAP ECC.

Démarrez votre 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 par jointure de tables avec SAP QuickViewer SQVI

Étapes

Configuration

Exemple de requête sql

Script Python utilisant le protocole RFC_READ_TABLE

Étapes

Configuration

Exemple de requête python

Extraction incrémentielle avec Theobald Xtract Universal

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Optimisez dès maintenant le traitement des 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 par jointure de tables avec SAP QuickViewer SQVI

Étapes

Configuration

Exemple de requête sql

Script Python utilisant le protocole RFC_READ_TABLE

Étapes

Configuration

Exemple de requête python

Extraction incrémentielle avec Theobald Xtract Universal

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Optimisez dès maintenant le traitement des paiements fournisseurs

Prêt à commencer ?