Votre modèle de données Order to Cash - Facturation et émission des factures
Votre modèle de données Order to Cash - Facturation et émission des factures
- Attributs recommandés pour une analyse complète
- Étapes clés du processus et jalons à suivre
- Conseils pratiques pour extraire les données de SAP ECC
Attributs du processus Order to Cash - Facturation et émission des factures
| Nom | Description | ||
|---|---|---|---|
| Activité ActivityName | Nom de l’événement métier ou de l’étape qui s’est produite au cours du cycle de vie de la facture. | ||
| Description Cet attribut décrit une action précise ou un changement de statut dans le processus de facturation, comme « Facture générée », « Facture comptabilisée » ou « Paiement client reçu ». Ces activités sont dérivées conceptuellement de différents événements système, des changements de statut des documents ou des codes de transaction exécutés par les utilisateurs. La séquence de ces activités forme le flux du processus, qui constitue le fondement de l’analyse par process mining. En examinant les activités, les entreprises peuvent comprendre quelles étapes sont réalisées, dans quel ordre et à quelle fréquence, et comparer l’exécution réelle au processus défini. Pourquoi c’est important Il définit les étapes de la cartographie du processus et permet de visualiser et d’analyser les flux de processus, les écarts et les goulots d’étranglement. Où les obtenir Il s’agit d’un attribut conceptuel dérivé de plusieurs sources, telles que les codes de transaction (CDHDR-TCODE), les changements de statut des documents (VBUK-FKSTK) et les comptabilisations des documents comptables. Exemples Facture généréeFacture comptabiliséeRelance de paiement envoyéeFacture lettrée | |||
| Heure de début EventTime | Horodatage indiquant le moment où une activité ou un événement donné s’est produit. | ||
| Description Event Time enregistre la date et l’heure précises de chaque activité du cycle de vie d’une facture. Cet horodatage est fondamental pour toutes les analyses temporelles du Process Mining, notamment le calcul des temps de cycle, l’identification des goulots d’étranglement et le suivi des performances du processus par rapport aux accords de niveau de service. Cet attribut est généralement construit en combinant un champ de date, tel que Posting Date (BUDAT), avec un champ horaire (UZEIT) provenant de différentes tables SAP qui enregistrent les modifications ou la création des documents. Des horodatages précis sont essentiels pour constituer un journal d’événements fiable et garantir la validité des analyses de performance. Pourquoi c’est important Cet attribut constitue la base de toutes les analyses de performance et permet de calculer les délais de cycle, les durées et les temps d’attente entre les étapes du processus. Où les obtenir Construit à partir de différents champs de date et d’heure répartis dans plusieurs tables, comme BKPF (BUDAT, CPUTM), VBRK (ERDAT, ERZET) et les tables de journaux des modifications telles que CDHDR (UDATE, UTIME). Exemples 2023-04-15T10:30:00Z2023-04-16T11:00:00Z2023-05-20T09:00:00Z | |||
| Numéro de facture InvoiceNumber | Identifiant unique du document de facturation, qui sert d’identifiant de dossier principal pour le processus de facturation. | ||
| Description Le numéro de facture, appelé numéro de document de facturation dans SAP, identifie chaque facture de manière unique. Dans le process mining, il sert de CaseId et regroupe toutes les activités associées, comme la création, la comptabilisation, l’envoi, le paiement et le lettrage, au sein d’une même instance de processus de bout en bout. L’analyse des processus par numéro de facture offre une vision complète du cycle de vie de chaque opération de facturation, de sa création à son règlement définitif. Elle est essentielle pour calculer des indicateurs clés tels que le délai moyen de paiement (DSO) et le cycle global de facturation, et fournit une base claire pour mesurer et améliorer la performance. Pourquoi c’est important Il s’agit de la clé essentielle pour suivre l’intégralité du parcours d’une facture et analyser les temps de cycle, les goulots d’étranglement et les variations de chaque transaction de facturation. Où les obtenir Table SAP ECC : VBRK, champ : VBELN Exemples 90001234900012359000123690001237 | |||
| Code société CompanyCode | Identifiant de l’entité juridique qui a émis la facture. | ||
| Description Le code société représente dans SAP une unité juridique et comptable indépendante. Toutes les opérations financières, y compris les factures, sont comptabilisées dans un code société donné. Il s’agit d’un élément fondamental des données organisationnelles. Dans le contexte du process mining, le code société sert à analyser et à comparer la performance du processus de facturation entre les différentes entités juridiques d’un groupe. Cette approche permet d’identifier les bonnes pratiques d’une entité qui pourraient être appliquées à d’autres, tout en veillant à ce que l’analyse respecte la structure organisationnelle de l’entreprise. Pourquoi c’est important Permet de filtrer et de comparer les processus entre différentes entités juridiques, ce qui est essentiel pour l’analyse financière et la comparaison des performances organisationnelles. Où les obtenir Table SAP ECC : VBRK, champ : BUKRS Exemples 10002000US01DE01 | |||
| Montant total de la facture TotalInvoiceAmount | La valeur nette totale du document de facturation. | ||
| Description Cet attribut représente le montant net total de la facture, hors taxes. Le montant de la facture constitue une donnée financière essentielle associée au processus de facturation. Il est utilisé dans différentes analyses, par exemple pour répartir les factures entre catégories de montants élevés et faibles afin de déterminer si leurs flux de processus diffèrent. Il peut également servir à hiérarchiser les actions de recouvrement ou à rechercher pourquoi les factures de montant élevé mettent plus de temps à être approuvées ou réglées. Ce contexte financier apporte une dimension importante à l’analyse des processus. Pourquoi c’est important Fournit le contexte financier nécessaire pour analyser les factures selon leur montant, notamment pour déterminer si les factures de montant élevé suivent un processus différent ou mettent plus de temps à être réglées. Où les obtenir Table SAP ECC : VBRK, champ : NETWR Exemples 1500.7525000.00500.0012345.67 | |||
| Nom d’utilisateur UserName | Identifiant de l’utilisateur qui a exécuté l’activité ou créé le document. | ||
| Description Cet attribut enregistre l’identifiant de l’utilisateur SAP responsable d’un événement donné, comme la création d’une facture ou la comptabilisation d’un paiement. Il est essentiel pour analyser la dimension humaine du processus. Ces données permettent d’étudier les écarts de performance entre utilisateurs ou équipes, d’identifier les besoins de formation et de détecter d’éventuels problèmes de conformité. Elles servent également à distinguer les activités manuelles réalisées par des utilisateurs des étapes automatisées exécutées par le système ou des utilisateurs de traitement par lots, ce qui est essentiel pour calculer les taux d’automatisation. Pourquoi c’est important Permet d’analyser la performance des utilisateurs et la répartition de la charge de travail, et de distinguer les activités manuelles des activités automatisées afin de soutenir les initiatives d’automatisation et d’efficacité. Où les obtenir Table SAP ECC : VBRK, champ : ERNAM (créé par), ou BKPF, champ : USNAM (nom d’utilisateur), ou CDHDR, champ : USERNAME (utilisateur). Exemples JSMITHBW_BATCHLROSSIMKUMAR | |||
| Numéro de client CustomerNumber | Numéro unique qui identifie le client auquel la facture est adressée. | ||
| Description Le numéro de client relie une facture à un client ou à un partenaire commercial donné. Cet attribut est essentiel pour segmenter et analyser le processus de facturation selon les caractéristiques des clients. Les analystes peuvent utiliser ce champ pour comparer le délai moyen de paiement (DSO) entre différents clients, identifier ceux qui paient fréquemment en retard ou analyser le respect des conditions de paiement. La compréhension de ces tendances est essentielle pour gérer la relation client et améliorer les stratégies de recouvrement adaptées à chaque segment. Pourquoi c’est important Permet une analyse centrée sur le client, en aidant à identifier les comportements de paiement, à évaluer le DSO par client et à adapter les stratégies de recouvrement. Où les obtenir Table SAP ECC : VBRK, champ : KUNRG (payeur) ou KUNAG (donneur d’ordre). Exemples 100023200541CUST-A487910345 | |||
| Type de document de facturation BillingDocumentType | Code qui catégorise le type de document de facturation, comme une facture, un avoir ou une note de débit. | ||
| Description Le type de document de facturation classe les opérations en catégories distinctes selon leur finalité métier. Par exemple, « F2 » correspond à une facture client standard, tandis que « G2 » désigne un avoir. Cette classification est configurée dans SAP afin de contrôler le traitement des différents documents de facturation. Pour le process mining, cet attribut est essentiel pour filtrer et comparer les différents scénarios de facturation. Les analystes peuvent examiner séparément le processus des factures standard et celui des avoirs afin d’en comprendre les flux, les délais de cycle et les difficultés propres, puis de définir des améliorations plus ciblées. Pourquoi c’est important Permet de segmenter et d’analyser différents processus de facturation, comme les factures standard et les avoirs, dont les flux sont souvent très différents. Où les obtenir Table SAP ECC : VBRK, champ : FKART Exemples F2G2L2IV | |||
| Code de transaction TransactionCode | Code de transaction SAP utilisé pour exécuter une activité. | ||
| Description Le code de transaction, ou T-Code, est l’identifiant unique d’une fonction ou d’un programme SAP donné, comme « VF01 » pour créer un document de facturation. L’enregistrement du T-Code pour chaque événement fournit une vision technique, au niveau du système, de l’exécution du processus. Ces informations sont très utiles pour l’analyse des causes profondes. Par exemple, lorsque les erreurs sont fréquentes, les analystes peuvent vérifier si un code de transaction non standard est utilisé. Elles contribuent également à déduire le nom de l’activité et à comprendre les fonctionnalités du système utilisées dans le processus. Pourquoi c’est important Fournit le contexte technique de l’exécution d’une activité, permet d’analyser les causes profondes des écarts du processus et aide à identifier les actions utilisateur non standard. Où les obtenir Table SAP ECC : CDHDR, champ : TCODE Exemples VF01VF02FB01F-28 | |||
| Conditions de paiement PaymentTerms | Les conditions selon lesquelles un vendeur réalise une vente, notamment l’échéancier de paiement. | ||
| Description Les conditions de paiement définissent les règles applicables à l’échéance d’un paiement, par exemple « Net 30 » ou « Net 60 ». Elles sont convenues avec le client et constituent un facteur déterminant pour les flux de trésorerie. L’analyse du processus selon les conditions de paiement peut révéler si certaines conditions sont associées à des cycles de paiement plus longs ou à davantage de retards. Ces résultats peuvent aider l’entreprise à négocier de meilleures conditions avec ses clients ou à ajuster sa planification financière. Ils constituent également une donnée essentielle pour calculer la date d’échéance de la facture. Pourquoi c’est important Aide à analyser le comportement de paiement des clients et l’incidence sur les flux de trésorerie selon les conditions négociées, afin d’améliorer les accords commerciaux. Où les obtenir Table SAP ECC : VBRK, champ : ZTERM Exemples Z030Z060Z001 | |||
| Date d’échéance de la facture InvoiceDueDate | La date à laquelle le client est censé effectuer le paiement. | ||
| Description La date d’échéance de la facture correspond à la date limite de paiement définie par les conditions de paiement. Cette date est fondamentale pour gérer les créances clients et lancer les actions de recouvrement. Cet attribut sert à calculer le KPI du taux de paiement à temps, en le comparant à la date réelle de paiement. L’analyse des factures selon leur date d’échéance aide à prévoir les flux de trésorerie et à hiérarchiser les actions de recouvrement pour les paiements à venir ou en retard. Elle est généralement calculée à partir de la date de référence et des conditions de paiement. Pourquoi c’est important Sert de référence pour mesurer la ponctualité des paiements et est indispensable à la gestion des créances clients ainsi qu’à la prévision des flux de trésorerie. Où les obtenir Calculée à partir de la date de référence (BSEG-ZFBDT) et des conditions de paiement (BSEG-ZTERM). Elle n’est pas toujours enregistrée dans un champ dédié. Exemples 2023-05-152023-05-302023-06-20 | |||
| Date de comptabilisation PostingDate | La date à laquelle le document est comptabilisé dans les livres de comptabilité financière. | ||
| Description La date de comptabilisation détermine la période fiscale au cours de laquelle la transaction est enregistrée dans le grand livre. Il s’agit d’une date essentielle pour la comptabilité et le reporting financier. Les retards entre la création du document et sa comptabilisation peuvent révéler des inefficacités dans le traitement interne des documents de facturation. Du point de vue du Process Mining, la date de comptabilisation marque une étape importante du cycle de vie de la facture. Le délai entre la création de la facture et sa comptabilisation peut constituer un indicateur clé de l’efficacité du service de facturation. Pourquoi c’est important Marque une étape financière importante et joue un rôle essentiel en comptabilité. Le délai entre la création et la comptabilisation de la facture mesure l’efficacité du traitement interne. Où les obtenir Table SAP ECC : BKPF, champ : BUDAT Exemples 2023-04-152023-04-172023-05-21 | |||
| Date de lettrage ClearingDate | La date à laquelle le paiement a été reçu et la facture lettrée dans les comptes clients. | ||
| Description La date de lettrage correspond à la date à laquelle un poste ouvert, comme une facture, est marqué comme payé ou « lettré » dans le système financier. Elle indique donc le moment où l’encaissement est considéré comme reçu et rapproché. Il s’agit de l’une des dates les plus importantes du cycle Order to Cash. Elle sert de point final au calcul du délai moyen de recouvrement (DSO) et de la durée globale du cycle facture-encaissement. L’analyse de la date de lettrage permet de mesurer l’efficacité du processus de recouvrement. Pourquoi c’est important Marque la dernière étape du cycle de vie de la facture. Elle sert de date de fin pour calculer le DSO et la durée globale du cycle, tout en reflétant l’efficacité de l’encaissement. Où les obtenir Table SAP ECC : BSAD, champ : AUGDT Exemples 2023-05-142023-06-012023-06-25 | |||
| Date du document DocumentDate | La date figurant sur le document d’origine, fournie par le fournisseur ou le créateur. | ||
| Description La date du document correspond à la date d’émission du document d’origine. Dans le processus de facturation, il s’agit généralement de la date de création de la facture et elle sert souvent de base au calcul de la date d’échéance du paiement. Cette date est essentielle pour le reporting financier et le calcul d’indicateurs tels que le délai moyen de recouvrement (DSO). Elle marque le début de la période de recouvrement du point de vue du client. L’analyse des écarts entre la date du document et la date de comptabilisation peut révéler des retards internes dans le traitement des factures reçues. Pourquoi c’est important Sert de référence pour calculer l’ancienneté des factures et le DSO, et fournit un point de comparaison important pour l’analyse financière et celle des conditions de paiement. Où les obtenir Table SAP ECC : VBRK, champ : FKDAT (date de facturation) Exemples 2023-04-152023-04-162023-05-20 | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage de l’actualisation ou de l’extraction la plus récente des données depuis le système source. | ||
| Description Cet attribut indique la dernière mise à jour du jeu de données depuis le système source. Il fournit un contexte essentiel à toute analyse, afin que les utilisateurs connaissent l’actualité des données consultées. Dans les Dashboards et les rapports, cet horodatage informe les parties prenantes de la fraîcheur des données et les aide à comprendre dans quelle mesure les transactions les plus récentes sont visibles. Il est généralement généré à la fin du processus d’extraction des données. Pourquoi c’est important Informe les utilisateurs de l’actualité des données, un élément essentiel pour prendre des décisions opérationnelles fondées sur l’analyse. Où les obtenir Généré et enregistré lors du processus d’extraction, de transformation et de chargement (ETL) des données. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Devise Currency | Le code devise des montants indiqués sur la facture. | ||
| Description Cet attribut indique la devise de la transaction, par exemple USD, EUR ou JPY. Il fournit le contexte nécessaire à l’interprétation des valeurs monétaires, comme le montant total de la facture. Lors de l’analyse des données d’une organisation multinationale, le champ de devise est indispensable pour interpréter et convertir correctement les montants financiers. Il garantit la cohérence des rapports et évite d’agréger des montants sans conversion préalable, ce qui fausserait l’analyse financière. Pourquoi c’est important Fournit le contexte nécessaire à toutes les valeurs monétaires et garantit une analyse financière fiable, notamment dans un environnement multidevise. Où les obtenir Table SAP ECC : VBRK, champ : WAERK Exemples USDEURGBPJPY | |||
| Est automatisé IsAutomated | Un indicateur précisant si une activité a été réalisée par un utilisateur système ou au moyen d’une automatisation. | ||
| Description Cet attribut calculé est un indicateur booléen qui distingue les activités manuelles des activités automatisées. Il est généralement obtenu en comparant l’attribut Nom d’utilisateur à une liste d’identifiants connus d’utilisateurs système ou de traitement par lots, tels que « BATCHUSER » ou « SAPSYSTEM ». Cet indicateur est essentiel pour mesurer le niveau d’automatisation du processus de facturation, un objectif important pour de nombreuses organisations qui cherchent à améliorer leur efficacité et à réduire leurs coûts. Le KPI du taux de facturation automatisée est calculé directement à partir de cet attribut, ce qui permet de suivre les progrès des initiatives d’automatisation. Pourquoi c’est important Contribue directement au calcul du taux de facturation automatisée, afin de mesurer l’efficacité du processus et de suivre les effets des projets d’automatisation. Où les obtenir Dérivé de l’attribut Nom d’utilisateur. La logique pourrait être la suivante : IF UserName IN ('BATCH', 'SYSTEM', 'RFCUSER') THEN true ELSE false. Exemples truefalse | |||
| Est une reprise IsRework | Un indicateur précisant si une activité correspond à une étape de reprise ou de correction. | ||
| Description Cet attribut calculé identifie les activités correspondant à des reprises, comme « Facture corrigée » ou les extournes de documents. Il s’agit généralement d’un indicateur booléen dérivé du nom de l’activité ou des codes de transaction associés aux corrections et aux annulations, comme « VF11 » pour annuler un document de facturation. Dans le cadre du Process Mining, cet indicateur est très utile pour quantifier les reprises dans le processus de facturation. Il contribue directement à des KPI tels que le taux de correction des factures et permet de visualiser les boucles de reprise dans la cartographie du processus, en mettant en évidence les inefficacités et les problèmes de qualité qui augmentent les coûts opérationnels et retardent les paiements. Pourquoi c’est important Aide à quantifier les inefficacités et les problèmes de qualité du processus en montrant l’effort consacré à la correction des erreurs, et contribue directement aux KPI de reprise. Où les obtenir Dérivé du nom de l’activité ou du code de transaction. Par exemple : IF ActivityName = 'Invoice Corrected' OR TransactionCode = 'VF11' THEN true ELSE false. Exemples truefalse | |||
| Numéro du document commercial SalesDocumentNumber | L’identifiant de la commande client d’origine à l’origine de la facture. | ||
| Description Cet attribut établit un lien direct entre la facture et la commande client à l’origine de la transaction. Cette traçabilité est essentielle pour analyser l’ensemble du cycle Order to Cash, de bout en bout. En reliant le processus de facturation au processus de commande client qui le précède, les organisations peuvent analyser la durée totale du cycle, de la commande du client à l’encaissement. Cela permet de déterminer si les retards de facturation sont dus à des problèmes liés aux ventes, à l’exécution de la commande ou au service de facturation, et d’obtenir une vision complète du processus. Pourquoi c’est important Relie le processus de facturation à la commande client, permettant une véritable analyse Order to Cash de bout en bout et facilitant l’identification des retards entre services. Où les obtenir Table SAP ECC : VBRP, champ : VGBEL Exemples 100000451000004610000047 | |||
| Organisation commerciale SalesOrganization | L’unité organisationnelle responsable de la vente de produits ou de services. | ||
| Description L’organisation commerciale est une unité organisationnelle de SAP chargée de distribuer des biens et des services et de négocier les conditions de vente. Il s’agit d’un champ essentiel pour structurer les opérations commerciales et de distribution. Dans le cadre du Process Mining, cet attribut permet d’analyser le processus de facturation selon la structure commerciale. Il facilite la comparaison des performances entre différentes organisations commerciales, aide à déterminer quelles régions ou lignes d’activité sont les plus efficaces dans leur facturation et soutient les initiatives de standardisation des bonnes pratiques. Pourquoi c’est important Permet de comparer et d’analyser les performances entre différentes divisions commerciales ou régions, afin d’identifier les bonnes pratiques et les axes d’amélioration. Où les obtenir Table SAP ECC : VBRK, champ : VKORG Exemples 1000NA01EU01AP01 | |||
| Système source SourceSystem | Identifie le système source à partir duquel les données ont été extraites. | ||
| Description Cet attribut indique le système de référence dans lequel les données ont été créées. Dans un environnement d’entreprise comprenant plusieurs instances ERP ou systèmes intégrés, ce champ permet de distinguer les données provenant de sources différentes. Pour le process mining, il est essentiel à la validation des données et aux analyses comparant les processus entre différents systèmes ou unités organisationnelles. Il est généralement renseigné avec une valeur statique lors de l’extraction afin d’identifier le jeu de données. Pourquoi c’est important Fournit le contexte sur l’origine des données, ce qui est essentiel dans les environnements multisystèmes pour garantir leur intégrité et permettre une analyse propre à chaque système. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL), qui identifie l’instance SAP ECC concernée, par exemple « ECC_PROD_NA ». Exemples SAP_ECC_PRODECC_EU_100SAP_US_FIN | |||
Activités du processus Order to Cash - Facturation et émission des factures
| Activité | Description | ||
|---|---|---|---|
| Facture comptabilisée | La facture est officiellement enregistrée dans le sous-grand livre des comptes clients et dans le grand livre général. Cet événement rend la facture juridiquement opposable et matérialise la dette du client. | ||
| Pourquoi c’est important Il s’agit d’une étape importante qui déclenche officiellement le délai de recouvrement. Le temps écoulé entre la génération et la comptabilisation peut révéler des retards de traitement internes qui affectent la trésorerie. Où les obtenir Enregistré dans la table BKPF. La date de comptabilisation (BUDAT) du numéro de document (BELNR) marque cet événement. Pour les documents mis en attente, il s’agit du moment où le document est converti en document comptabilisé. Collecte À partir de la date de comptabilisation (BUDAT) du document de facture dans la table BKPF. Type d’événement explicit | |||
| Facture envoyée au client | Indique que la facture a été envoyée au client par un canal de sortie défini, tel que l’impression, l’e-mail ou l’EDI. Cet événement est généralement enregistré dans les journaux du système de gestion des sorties. | ||
| Pourquoi c’est important Cet événement constitue une étape importante, car il déclenche le délai de paiement prévu pour le client. Tout retard à ce stade repousse directement la date à laquelle le paiement peut être attendu et affecte l’efficacité du recouvrement. Où les obtenir Peut être déduit de la date et de l’heure de traitement figurant dans la table des statuts de messages (NAST), pour le type de sortie correspondant à la facture. Collecte Déduit d’une entrée de la table NAST présentant le statut de traitement « 1 » (traitement réussi). Type d’événement inferred | |||
| Facture générée | Indique la création du document de facturation dans le système. Cet événement est enregistré lorsqu’une nouvelle entrée est créée dans la table d’en-tête des documents comptables (BKPF), avec un type de document spécifique aux factures. | ||
| Pourquoi c’est important Il s’agit du point de départ de l’ensemble du processus de facturation. L’analyse du délai écoulé depuis cet événement permet de mesurer le cycle de création de la facture et constitue la base du calcul du délai moyen de paiement (DSO). Où les obtenir Enregistré dans la table BKPF. La date (CPUDT) et l’heure (CPUTM) de création d’un numéro de document donné (BELNR) marquent cet événement. Le type de document (BLART) permet d’identifier une facture. Collecte À partir de l’horodatage de création (CPUDT) du document de facture dans la table BKPF. Type d’événement explicit | |||
| Facture lettrée | Statut final d’une facture payée avec succès, indiquant que le poste ouvert a été clôturé par un paiement correspondant ou un avoir. La facture est considérée comme entièrement réglée. | ||
| Pourquoi c’est important Marque l’achèvement réussi du cycle Order to Cash pour une facture. Il s’agit de l’événement final principal pour mesurer le cycle moyen global de facturation. Où les obtenir Se produit lorsque les champs du document de lettrage (AUGBL) et de la date de lettrage (AUGDT) sont renseignés pour la ligne de facture dans la table BSEG. Collecte L’événement se produit à la date de lettrage (AUGDT) enregistrée dans la table BSEG pour la ligne de facture. Type d’événement explicit | |||
| Paiement client reçu | Un paiement a été reçu du client et comptabilisé dans le système sous la forme d’un encaissement ou d’un dépôt bancaire. Cette opération crée un document de paiement distinct, qui n’est pas encore imputé à la facture concernée. | ||
| Pourquoi c’est important Il s’agit d’une étape importante du cycle de conversion de trésorerie. Le délai entre l’envoi de la facture et la réception du paiement constitue une composante essentielle du délai moyen de paiement (DSO). Où les obtenir Enregistré comme un nouveau document dans BKPF et BSEG, généralement avec un type de document indiquant un paiement client, tel que « DZ ». La date de comptabilisation (BUDAT) marque l’événement. Collecte À partir de la date de comptabilisation du document de paiement client dans BKPF. Type d’événement explicit | |||
| Date d’échéance de la facture atteinte | Événement calculé qui marque le jour où le paiement de la facture devient officiellement exigible selon les conditions de paiement. Il ne s’agit pas d’une activité réalisée par un utilisateur ou un système, mais d’un moment important du processus. | ||
| Pourquoi c’est important Essentiel pour analyser le comportement de paiement et la conformité. Il sert de référence pour distinguer les paiements à temps des paiements en retard et calculer le KPI du taux de paiement à échéance. Où les obtenir Déduit par comparaison entre la date actuelle et la date d’échéance nette. La date d’échéance figure dans le champ BSEG-ZFBDT ou est calculée à partir de la date de référence et des conditions de paiement. Collecte Comparer la date système au champ de date d’échéance nette de la ligne de facture (BSEG). Type d’événement calculated | |||
| Dossier de litige créé | Un litige officiel a été enregistré à l’encontre de la facture, généralement à la suite d’une réclamation client. Il est enregistré dans le système SAP de gestion des litiges. | ||
| Pourquoi c’est important Identifie les factures présentant un risque de retard de paiement et met en évidence les problèmes à l’origine de l’insatisfaction du client. Il marque le début d’un processus important de traitement des exceptions. Où les obtenir Capturé lors de la création d’un dossier dans la table des dossiers de litige (UDM_CASE), associé au document comptable de la facture. Collecte Enregistré lorsqu’un utilisateur crée un dossier de litige via la transaction UDM_DISPUTE. Type d’événement explicit | |||
| Facture approuvée | Représente l’approbation officielle de la facture, qui peut alors être comptabilisée ou envoyée au client. Cette étape est souvent déduite de la conversion d’un document mis en attente en document comptabilisé. | ||
| Pourquoi c’est important Suit le flux de travail d’approbation interne, qui constitue une source fréquente de goulots d’étranglement. L’analyse de cette activité contribue au Dashboard Invoice Approval Flow Analysis en identifiant les approbateurs les plus lents. Où les obtenir Peut être déduit de la transition d’un document de l’état « parked » dans VBKPF à l’état « posted » dans BKPF. Si un système de flux de travail est utilisé, il peut également s’agir d’un événement explicite dans les journaux du flux de travail. Collecte Comparer la date de création du document mis en attente (VBKPF) à la date de comptabilisation du document définitif (BKPF). Type d’événement inferred | |||
| Facture corrigée | Représente une activité de reprise au cours de laquelle une facture initiale a été déclarée incorrecte, puis contrepassée. Cet événement est identifié à partir des documents de contrepassation liés à la facture d’origine. | ||
| Pourquoi c’est important Met en évidence les inefficacités du processus et les problèmes de qualité. Une fréquence élevée de corrections signale des problèmes dans les données commerciales ou de facturation en amont et alimente le Dashboard des reprises et des taux d’erreur de facturation. Où les obtenir Identifié lorsqu’un document de contrepassation est trouvé et que BKPF-STBLG pointe vers le document d’origine. La création de ce document de contrepassation constitue l’événement. Collecte Enregistré lors de la création d’un document de contrepassation, par exemple via FB08. Type d’événement explicit | |||
| Facture mise en attente | Le document de facture a été enregistré dans un état préliminaire sans être comptabilisé dans le grand livre. Cette étape est souvent utilisée lorsque certaines informations sont incomplètes ou doivent être vérifiées avant la comptabilisation définitive. | ||
| Pourquoi c’est important Suit les étapes précédant la comptabilisation et les retards éventuels. Une durée prolongée dans l’état « parked » peut signaler des problèmes de qualité des données ou des goulots d’étranglement dans le processus précédant l’approbation. Où les obtenir Les documents mis en attente sont stockés dans la table VBKPF. La création d’un document dans cette table, qui sera ensuite comptabilisé, correspond à cette activité. Collecte Enregistré lors de la sauvegarde d’un document mis en attente au moyen d’une transaction telle que FV70. Type d’événement explicit | |||
| Facture passée en perte | Statut final alternatif dans lequel la facture est considérée comme irrécouvrable et le montant restant est soldé sur un compte de créances douteuses. La facture est ainsi clôturée sans paiement du client. | ||
| Pourquoi c’est important Représente une issue défavorable du processus et une perte de revenus. Le suivi de ces événements aide à analyser les causes des créances irrécouvrables et à améliorer les politiques de gestion du crédit. Où les obtenir Déduit de l’analyse de la transaction de lettrage de la facture. Si le document de lettrage est comptabilisé sur un compte général de charges dédié aux créances douteuses, la facture est considérée comme passée en perte. Collecte Déduit lorsque la transaction de lettrage comprend une comptabilisation sur un compte général dédié aux créances douteuses. Type d’événement inferred | |||
| Paiement imputé à la facture | Le paiement reçu du client a été rapproché et imputé à la facture ouverte concernée, ce qui marque le poste comme soldé. Il s’agit de l’étape de rapprochement qui relie le paiement à la dette. | ||
| Pourquoi c’est important Cette activité est essentielle pour mesurer le cycle d’imputation des paiements. Les retards d’imputation peuvent fausser la situation réelle des comptes clients et masquer les liquidités disponibles. Où les obtenir Déduit de la transaction de lettrage, par exemple F-32, qui renseigne les champs de lettrage de la ligne de facture. L’horodatage de l’événement correspond à la date de lettrage. Collecte Déduit du renseignement de la date de lettrage (AUGDT) dans la table des lignes de facture (BSEG). Type d’événement inferred | |||
| Relance de paiement envoyée | Le système a généré et envoyé au client une relance ou une notification de recouvrement pour une facture échue. Cet événement est enregistré dans les journaux de l’historique des relances. | ||
| Pourquoi c’est important Permet d’évaluer l’efficacité de la stratégie de recouvrement. L’analyse du délai entre la relance et la réception du paiement est essentielle pour le KPI d’efficacité des relances de paiement. Où les obtenir Enregistré dans les tables de données de relance, notamment MHNK (en-tête des données de relance) et MHND (lignes de données de relance), générées par l’exécution des relances (transaction F150). Collecte Enregistré lors de l’exécution d’une relance (F150) pour le poste arrivé à échéance. Type d’événement explicit | |||
Guides d’extraction
Étapes
- Accéder à l’éditeur ABAP : Connectez-vous à votre système SAP ECC. Accédez à l’éditeur ABAP à l’aide du code de transaction
SE38. - Créer le programme : Saisissez le nom de votre nouveau programme dans le champ Program, par exemple
Z_PM_O2C_INVOICE_EXTRACT, puis cliquez sur le bouton Create. Indiquez un titre explicite et définissez le type du programme sur « Executable Program ». - Définir l’écran de sélection : Dans le code source du programme, définissez les paramètres de l’écran de sélection. Les utilisateurs pourront ainsi filtrer les données à extraire. Les principaux paramètres comprennent la plage de dates de création des documents (
S_ERDAT), le code société (S_BUKRS) et le type de document de facturation (S_VBTYP). - Définir les structures de données : Déclarez une structure de table interne destinée à contenir les données finales du journal d’événements. Elle doit inclure les champs
InvoiceNumber,ActivityName,EventTime, ainsi que des attributs recommandés tels queUserName,BillingDocumentType,CustomerNumber,CompanyCodeetTotalInvoiceAmount. - Implémenter la logique de sélection des données : Écrivez la logique ABAP principale pour sélectionner les données. Commencez par sélectionner les documents de facturation principaux dans les tables
VBRKetBKPF, en fonction des valeurs saisies sur l’écran de sélection. Stockez-les dans une table interne temporaire. - Extraire les activités : Parcourez la liste initiale des documents de facturation. Pour chaque document, effectuez des sélections complémentaires dans différentes tables afin d’identifier les 13 activités requises. Interrogez par exemple la table
NASTpour les événements « Invoice Sent To Customer »,BSEGpour les informations de lettrage (« Invoice Cleared », « Payment Applied ») etMHNKpour les données de relance (« Payment Reminder Issued »). - Construire la table du journal d’événements : Pour chaque activité trouvée à l’étape précédente, ajoutez un nouvel enregistrement dans la table interne finale du journal d’événements. Vérifiez que
InvoiceNumber,ActivityName,EventTimeet les autres attributs sont correctement associés aux champs des tables sources. - Écrire sur le serveur d’applications : Une fois la boucle terminée et la table finale entièrement renseignée, utilisez les instructions
OPEN DATASET,LOOP AT... TRANSFERetCLOSE DATASETpour écrire le contenu de la table interne dans un fichier plat sur le serveur d’applications SAP. Indiquez un chemin logique accessible. - Récupérer le fichier : Utilisez le code de transaction
AL11pour accéder aux répertoires du serveur d’applications et localiser le fichier généré. Coordonnez-vous avec votre équipe SAP Basis afin de télécharger le fichier du serveur vers votre poste local ou un emplacement réseau partagé. - Mise en forme finale : Ouvrez le fichier téléchargé et vérifiez qu’il s’agit d’un fichier CSV séparé par des virgules, avec une ligne d’en-tête. Enregistrez-le au format UTF-8 afin d’assurer sa compatibilité avec ProcessMind lors du chargement.
Configuration
- Prérequis : Accès permettant de créer et d’exécuter des programmes ABAP (transaction SE38). Autorisation de lecture sur les tables FI et SD, notamment
VBRK,VBRP,BKPF,BSEG,NAST,MHNKetUDM_CASE_ATTR00(pour la Gestion des litiges). - Sélection de la plage de dates : Le programme doit comporter un paramètre obligatoire de plage de dates, généralement fondé sur la date de création du document (
ERDATdans VBRK/BKPF). Pour une première extraction, une période de 3 à 6 mois est recommandée afin de conserver un volume de données maîtrisable. - Filtres principaux : Filtrez toujours par
CompanyCode(BUKRS) afin de limiter le périmètre de l’extraction. Il est également vivement recommandé de filtrer par type de document de facturation (VBTYPdans VBRK) ou par type de document comptable (BLARTdans BKPF), afin de ne conserver que les types de factures pertinents, par exemple « RV » pour les factures comptables standard, et d’exclure les avoirs ou autres documents. - Considérations relatives aux performances : Pour les volumes importants couvrant plus de quelques mois, exécutez le programme en tâche de fond afin d’éviter les expirations de session. La logique ABAP doit être optimisée en utilisant des lectures de tables indexées et en évitant les boucles imbriquées contenant des sélections en base de données. Il est préférable de sélectionner d’abord les données dans des tables internes, puis de les traiter.
- Configuration du fichier de sortie : Le code ABAP doit préciser le chemin du fichier de sortie sur le serveur d’applications ainsi que le séparateur du fichier CSV, généralement une virgule ou un point-virgule. Vérifiez que le chemin correspond à un répertoire configuré au niveau global et accessible.
a Exemple de requête abap
REPORT Z_PM_O2C_INVOICE_EXTRACT.
*&---------------------------------------------------------------------*
*& Tables
*&---------------------------------------------------------------------*
TABLES: VBRK, BKPF.
*&---------------------------------------------------------------------*
*& Type Definitions for Event Log Output
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoicenumber TYPE vbrk-vbeln,
activityname TYPE string,
eventtime TYPE timestamp,
username TYPE xubname,
billingdocumenttype TYPE vbrk-vbtyp,
customernumber TYPE vbrk-kunnr,
companycode TYPE vbrk-bukrs,
totalinvoiceamount TYPE vbrk-netwr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log,
gs_event_log TYPE ty_event_log.
DATA: BEGIN OF gs_invoice,
vbeln TYPE vbrk-vbeln, " SD Doc (Invoice)
awkey TYPE bkpf-awkey, " Accounting Doc Reference Key
bukrs TYPE vbrk-bukrs, " Company Code
kunnr TYPE vbrk-kunnr, " Customer
vbtyp TYPE vbrk-vbtyp, " SD Doc Type
netwr TYPE vbrk-netwr, " Net Value
waerk TYPE vbrk-waerk, " Currency
fkdat TYPE vbrk-fkdat, " Billing Date
erdat TYPE vbrk-erdat, " Creation Date
erzet TYPE vbrk-erzet, " Creation Time
ernam TYPE vbrk-ernam, " Creator
belnr TYPE bkpf-belnr, " Acct Doc
gjahr TYPE bkpf-gjahr, " Fiscal Year
cpudt TYPE bkpf-cpudt, " Acct Doc Entry Date
cputm TYPE bkpf-cputm, " Acct Doc Entry Time
usnam TYPE bkpf-usnam, " Acct Doc User
stblg TYPE bkpf-stblg, " Reversal Doc
END OF gs_invoice.
DATA: gt_invoices LIKE TABLE OF gs_invoice.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbrk-erdat OBLIGATORY,
s_bukrs FOR vbrk-bukrs OBLIGATORY,
s_vbtyp FOR vbrk-vbtyp.
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/trans/tmp/invoice_extract.csv' OBLIGATORY.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" 1. Select base set of invoices
SELECT vbrk~vbeln, vbrk~bukrs, vbrk~kunnr, vbrk~vbtyp, vbrk~netwr, vbrk~waerk,
vbrk~fkdat, vbrk~erdat, vbrk~erzet, vbrk~ernam,
bkpf~belnr, bkpf~gjahr, bkpf~cpudt, bkpf~cputm, bkpf~usnam, bkpf~stblg, bkpf~awkey
INTO CORRESPONDING FIELDS OF TABLE gt_invoices
FROM vbrk
INNER JOIN bkpf ON bkpf~awkey = vbrk~vbeln AND bkpf~awtyp = 'VBRK'
WHERE vbrk~erdat IN s_erdat
AND vbrk~bukrs IN s_bukrs
AND vbrk~vbtyp IN s_vbtyp.
IF gt_invoices IS INITIAL.
MESSAGE 'No invoices found for the selected criteria.' TYPE 'I'.
RETURN.
ENDIF.
LOOP AT gt_invoices INTO gs_invoice.
CLEAR gs_event_log.
gs_event_log-invoicenumber = gs_invoice-vbeln.
gs_event_log-billingdocumenttype = gs_invoice-vbtyp.
gs_event_log-customernumber = gs_invoice-kunnr.
gs_event_log-companycode = gs_invoice-bukrs.
gs_event_log-totalinvoiceamount = gs_invoice-netwr.
" Activity: Invoice Generated (using accounting doc creation)
gs_event_log-activityname = 'Invoice Generated'.
gs_event_log-username = gs_invoice-usnam.
CONCATENATE gs_invoice-cpudt gs_invoice-cputm INTO DATA(lv_ts_gen).
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Posted (same as generated for non-parked docs)
gs_event_log-activityname = 'Invoice Posted'.
gs_event_log-username = gs_invoice-usnam.
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Approved (inferred by posting)
gs_event_log-activityname = 'Invoice Approved'.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Sent To Customer
SELECT SINGLE addat, aduhr FROM nast
INTO (DATA(lv_nast_date), DATA(lv_nast_time))
WHERE kappl = 'V3' AND objky = gs_invoice-vbeln AND vszst > '0'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Sent To Customer'.
gs_event_log-username = sy-uname.
CONVERT DATE lv_nast_date TIME lv_nast_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Corrected / Reversed
IF gs_invoice-stblg IS NOT INITIAL.
SELECT SINGLE cpudt, cputm, usnam FROM bkpf
INTO (DATA(lv_rev_date), DATA(lv_rev_time), DATA(lv_rev_user))
WHERE belnr = gs_invoice-stblg AND gjahr = gs_invoice-gjahr.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Corrected'.
gs_event_log-username = lv_rev_user.
CONVERT DATE lv_rev_date TIME lv_rev_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
" Activity: Payment Applied, Cleared, Due Date, Written Off (from BSEG)
SELECT SINGLE augdt, augbl, zfBDT, hkont FROM bseg
INTO (DATA(lv_augdt), DATA(lv_augbl), DATA(lv_zfbdt), DATA(lv_hkont))
WHERE bukrs = gs_invoice-bukrs
AND belnr = gs_invoice-belnr
AND gjahr = gs_invoice-gjahr
AND koart = 'D'. " Customer line
IF sy-subrc = 0.
" Due Date Reached (Calculated event)
IF lv_zfbdt IS NOT INITIAL.
gs_event_log-activityname = 'Invoice Due Date Reached'.
gs_event_log-username = 'System'.
CONVERT DATE lv_zfbdt INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Cleared, Applied, Write-Off
IF lv_augdt IS NOT INITIAL.
SELECT SINGLE usnam, cpudt, cputm, blart FROM bkpf
INTO (DATA(lv_clear_user), DATA(lv_clear_date), DATA(lv_clear_time), DATA(lv_clear_type))
WHERE belnr = lv_augbl AND bukrs = gs_invoice-bukrs.
IF sy-subrc = 0.
gs_event_log-username = lv_clear_user.
CONVERT DATE lv_clear_date TIME lv_clear_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
IF lv_clear_type = 'DZ'. " Standard Customer Payment
gs_event_log-activityname = 'Customer Payment Received'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Payment Applied To Invoice'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Invoice Cleared'. APPEND gs_event_log TO gt_event_log.
ELSE. " Assuming other clearing doc types could be write-offs
gs_event_log-activityname = 'Invoice Written Off'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDIF.
" Activity: Payment Reminder Issued (Dunning)
SELECT COUNT(*) FROM mhnk WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
IF sy-subrc = 0 AND sy-dbcnt > 0.
SELECT SINGLE lafdn FROM mhnk
INTO DATA(lv_dunning_date)
WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
gs_event_log-activityname = 'Payment Reminder Issued'.
gs_event_log-username = 'System'.
CONVERT DATE lv_dunning_date INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Parked (Example from VBKPF, may require system specific logic)
SELECT SINGLE cpudt, cputm, usnam FROM vbkpf
INTO (DATA(lv_park_date), DATA(lv_park_time), DATA(lv_park_user))
WHERE awkey = gs_invoice-vbeln AND awsys = 'LOG' AND bstat = 'V'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Parked'.
gs_event_log-username = lv_park_user.
CONVERT DATE lv_park_date TIME lv_park_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Dispute Case Created (Requires Dispute Management module)
SELECT SINGLE create_date, create_time, create_user FROM udm_case_attr00
INTO (DATA(lv_disp_date), DATA(lv_disp_time), DATA(lv_disp_user))
WHERE [Your logic to link invoice to dispute case, e.g., via a custom field or object link].
IF sy-subrc = 0.
gs_event_log-activityname = 'Dispute Case Created'.
gs_event_log-username = lv_disp_user.
CONVERT DATE lv_disp_date TIME lv_disp_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
*&---------------------------------------------------------------------*
*& Write data to file
*&---------------------------------------------------------------------*
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
" Header
DATA(lv_header) = 'InvoiceNumber,ActivityName,EventTime,UserName,BillingDocumentType,CustomerNumber,CompanyCode,TotalInvoiceAmount'.
TRANSFER lv_header TO p_path.
LOOP AT gt_event_log INTO gs_event_log.
DATA(lv_line) = |
{ gs_event_log-invoicenumber }|
,{ gs_event_log-activityname }|
,{ gs_event_log-eventtime }|
,{ gs_event_log-username }|
,{ gs_event_log-billingdocumenttype }|
,{ gs_event_log-customernumber }|
,{ gs_event_log-companycode }|
,{ gs_event_log-totalinvoiceamount }|.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: 'Extraction complete. File created at:', p_path. Étapes
- Prérequis et accès : Vérifiez que vous disposez d’un utilisateur de base de données avec un accès en lecture seule aux tables SAP ECC nécessaires, notamment VBRK, BKPF, BSAD, NAST, CDHDR, CDPOS, SCASE et les autres tables indiquées dans la requête. Ce niveau d’accès est généralement réservé aux administrateurs système ou à certaines équipes d’analyse des données.
- Se connecter à la base de données : Utilisez un outil client SQL standard, tel que DBeaver, Oracle SQL Developer ou Microsoft SQL Server Management Studio, pour établir une connexion à la base de données SAP ECC.
- Préparer la requête SQL : Copiez la requête SQL complète fournie dans la section « query » dans l’éditeur de votre client SQL.
- Personnaliser les paramètres : La requête contient plusieurs paramètres que vous devez remplacer par les valeurs propres à votre environnement. Il s’agit notamment des éléments suivants :
'YYYYMMDD': Remplacez toutes les occurrences par les dates de début et de fin de la période d’analyse souhaitée. Il est essentiel de limiter les données à une période maîtrisable.'XXXX': Remplacez cette valeur par le ou les codes société à analyser.[Your Invoice Output Type]: Indiquez le code du type de sortie utilisé pour envoyer les factures aux clients, par exemple « RD00 ».[Your Bad Debt G/L Account]: Saisissez le numéro du compte du grand livre utilisé pour passer en perte les factures irrécouvrables.[Your Dispute Case Invoice Attribute]: Indiquez le nom de l’attribut utilisé pour stocker le numéro de facture dans votre configuration de Gestion des litiges, par exemple « INVOICE_ID ».
- Vérifier les fonctions d’horodatage : La requête utilise une syntaxe générique
CAST(CONCAT(date_field, time_field) AS TIMESTAMP). Vous devrez peut-être l’adapter à votre système de base de données, par exemple en utilisantTO_TIMESTAMPavec Oracle ouDATETIMEFROMPARTSavec SQL Server. - Exécuter la requête : Lancez la requête modifiée. Selon le volume de vos tables SAP et la plage de dates sélectionnée, son exécution peut prendre un certain temps.
- Examiner les résultats : Une fois la requête terminée, vérifiez que la sortie contient les colonnes attendues : InvoiceNumber, ActivityName, EventTime et les attributs recommandés. Recherchez également les erreurs ou les résultats vides.
- Exporter au format CSV : Exportez l’ensemble des résultats depuis votre client SQL vers un fichier CSV. Vérifiez que le fichier utilise l’encodage UTF-8 afin d’éviter les problèmes liés aux caractères spéciaux.
- Préparer le chargement : Avant de charger le fichier dans un outil de Process Mining, vérifiez que les en-têtes de colonnes CSV correspondent exactement aux noms d’attributs requis, par exemple
InvoiceNumber,ActivityName,EventTime,UserName.
Configuration
- Connexion à la base de données : Une connexion SQL directe en lecture seule à la base de données SAP ECC sous-jacente est requise. Cette méthode contourne entièrement la couche applicative SAP.
- Autorisations : L’utilisateur de base de données doit disposer des autorisations
SELECTsur toutes les tables utilisées dans la requête, qui couvrent les modules FI, SD et potentiellement FSCM. - Plage de dates : Il est essentiel de filtrer la requête sur une plage de dates précise afin de maintenir des performances et un volume de données raisonnables. Nous recommandons de commencer par une période de 3 à 6 mois. Les paramètres de filtre de date
'YYYYMMDD'doivent être définis à plusieurs endroits de la requête. - Filtre par code société : La requête est conçue pour être filtrée par code société (
BUKRS). Il est courant d’analyser un seul code société, ou un nombre limité de codes, à la fois. - Configuration des types de documents : L’identification d’événements tels que les corrections de factures, les passages en perte ou l’envoi de documents dépend des configurations SAP standard. Vous devrez peut-être adapter la requête si votre organisation utilise des types de documents personnalisés (
BLART), des types de sortie (KSCHL) ou des comptes du grand livre spécifiques à ces processus. - Considérations relatives aux performances : L’exécution de cette requête sur un système SAP de production actif peut mobiliser des ressources importantes et affecter les performances opérationnelles. Il est vivement recommandé d’effectuer les extractions volumineuses en dehors des heures de pointe ou sur une réplique de reporting dédiée de la base de données.
a Exemple de requête sql
WITH InvoiceBase AS (
SELECT
VBRK.VBELN AS InvoiceNumber,
VBRK.FKART AS BillingDocumentType,
VBRK.KUNRG AS CustomerNumber,
VBRK.BUKRS AS CompanyCode,
VBRK.NETWR AS TotalInvoiceAmount,
VBRK.ERNAM AS CreatorName,
VBRK.ERDAT AS CreationDate,
VBRK.ERZET AS CreationTime
FROM VBRK
WHERE VBRK.ERDAT BETWEEN '20230101' AND '20231231' -- Filter by Invoice Creation Date
AND VBRK.BUKRS IN ('1000') -- Filter by Company Code
AND VBRK.FKART NOT IN ('S1', 'S2') -- Exclude cancelled invoices
)
-- 1. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS ActivityName,
CAST(CONCAT(ib.CreationDate, ib.CreationTime) AS TIMESTAMP) AS EventTime,
ib.CreatorName AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM InvoiceBase ib
UNION ALL
-- 2. Invoice Parked
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Parked' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = 'V' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 3. Invoice Posted
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Posted' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = '' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 4. Invoice Approved (from Parked to Posted)
SELECT
SUBSTRING(h.OBJECTID, 4, 10) AS InvoiceNumber,
'Invoice Approved' as ActivityName,
CAST(CONCAT(h.UDATE, h.UTIME) AS TIMESTAMP) AS EventTime,
h.USERNAME AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM CDHDR h
JOIN CDPOS p ON h.MANDANT = p.MANDANT AND h.OBJECTCLAS = p.OBJECTCLAS AND h.OBJECTID = p.OBJECTID AND h.CHANGENR = p.CHANGENR
JOIN InvoiceBase ib ON SUBSTRING(h.OBJECTID, 4, 10) = ib.InvoiceNumber
WHERE h.OBJECTCLAS = 'BELEGV'
AND p.TABNAME = 'BKPF'
AND p.FNAME = 'BSTAT'
AND p.VALUE_OLD = 'V'
AND p.VALUE_NEW = ' '
AND h.UDATE BETWEEN '20230101' AND '20231231'
UNION ALL
-- 5. Invoice Sent To Customer
SELECT
n.OBJKY AS InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
CAST(CONCAT(n.DATVR, n.UHRVR) AS TIMESTAMP) AS EventTime,
n.VSTAT AS UserName, -- User who processed is not directly available, using processing status as a proxy
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM NAST n
JOIN InvoiceBase ib ON n.OBJKY = ib.InvoiceNumber
WHERE n.KSCHL = '[Your Invoice Output Type]' -- E.g., 'RD00'
AND n.VSTAT = '1' -- Processed successfully
AND n.DATVR BETWEEN '20230101' AND '20231231'
UNION ALL
-- 6. Invoice Corrected (Reversed)
SELECT
SUBSTRING(orig_doc.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Corrected' AS ActivityName,
CAST(CONCAT(rev_doc.CPUDT, rev_doc.CPUTM) AS TIMESTAMP) AS EventTime,
rev_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
rev_doc.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF orig_doc
JOIN BKPF rev_doc ON orig_doc.STBLG = rev_doc.BELNR AND orig_doc.BUKRS = rev_doc.BUKRS AND orig_doc.GJAHR = rev_doc.STJAH
JOIN InvoiceBase ib ON SUBSTRING(orig_doc.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE orig_doc.AWTYP = 'VBRK' AND orig_doc.STBLG IS NOT NULL AND rev_doc.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 7. Invoice Due Date Reached
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Due Date Reached' AS ActivityName,
CAST(CONCAT(bs.ZFBDT, '000000') AS TIMESTAMP) AS EventTime,
'System' AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSEG bs
JOIN BKPF b ON bs.MANDT = b.MANDT AND bs.BUKRS = b.BUKRS AND bs.BELNR = b.BELNR AND bs.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND bs.KOART = 'D' AND bs.ZFBDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 8. Payment Reminder Issued
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(CONCAT(h.LAUFD, '000000') AS TIMESTAMP) AS EventTime,
h.LAUFI AS UserName, -- Dunning Run ID
ib.BillingDocumentType,
ib.CustomerNumber,
d.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM MHND d
JOIN MHNK h ON d.MANDT = h.MANDT AND d.LAUFD = h.LAUFD AND d.LAUFI = h.LAUFI
JOIN BKPF b ON d.MANDT = b.MANDT AND d.BUKRS = b.BUKRS AND d.BELNR = b.BELNR AND d.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE h.LAUFD BETWEEN '20230101' AND '20231231'
UNION ALL
-- 9. Dispute Case Created
SELECT
attr.ATTR_VALUE AS InvoiceNumber,
'Dispute Case Created' AS ActivityName,
sc.CREATE_TIME AS EventTime,
sc.CREATED_BY AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM SCMG_T_CASE_ATTR attr
JOIN SCASE sc ON attr.CASE_GUID = sc.CASE_GUID
JOIN InvoiceBase ib ON attr.ATTR_VALUE = ib.InvoiceNumber
WHERE attr.ATTR_NAME = '[Your Dispute Case Invoice Attribute]' -- e.g., 'INVOICE_ID'
AND CAST(sc.CREATE_TIME AS DATE) BETWEEN '20230101' AND '20231231'
UNION ALL
-- 10, 11, 12. Clearing Events (Payment, Clearing, Write-Off)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
BillingDocumentType,
CustomerNumber,
CompanyCode,
TotalInvoiceAmount
FROM (
SELECT
bsad.XBLNR AS InvoiceNumber,
CASE
WHEN clearing_item.HKONT = '[Your Bad Debt G/L Account]' THEN 'Invoice Written Off'
ELSE 'Customer Payment Received'
END AS ActivityName,
CAST(CONCAT(clearing_doc.CPUDT, clearing_doc.CPUTM) AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
LEFT JOIN BSEG clearing_item ON clearing_doc.MANDT = clearing_item.MANDT AND clearing_doc.BUKRS = clearing_item.BUKRS AND clearing_doc.BELNR = clearing_item.BELNR AND clearing_doc.GJAHR = clearing_item.GJAHR AND clearing_item.HKONT = '[Your Bad Debt G/L Account]' -- e.g. '148000'
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Payment Applied To Invoice' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '000000') AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Invoice Cleared' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '235959') AS TIMESTAMP) AS EventTime, -- Add time to separate from 'Payment Applied'
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
) AS ClearingEvents Étapes
- Prérequis : Vérifiez que vous disposez d’un outil ETL sous licence avec un connecteur SAP certifié, par exemple Informatica PowerCenter avec SAP Connector ou Talend avec SAP Connector. Vérifiez également que vous disposez d’identifiants utilisateur SAP avec les autorisations nécessaires pour lire les tables financières, commerciales et système requises (BKPF, BSEG, VBRK, NAST, MHNK, UDM_CASE_ATTR00, CDHDR, CDPOS).
- Établir la connexion SAP : Dans votre outil ETL, créez une nouvelle connexion à votre système SAP ECC. Configurez les informations de connexion, notamment le serveur d’applications, le numéro de système, le client, l’utilisateur et le mot de passe. Testez la connexion pour vérifier qu’elle fonctionne.
- Définir les sources de données : Pour chaque activité à extraire, définissez la ou les tables SAP correspondantes comme sources de données dans votre tâche ETL. Ajoutez par exemple VBRK pour la génération des factures, BKPF pour les événements de comptabilisation et NAST pour les communications avec les clients.
- Construire la logique d’extraction de chaque activité : Créez un flux de données ou une transformation distincte pour chacune des 13 activités requises. Dans chaque flux, appliquez des filtres afin de sélectionner les enregistrements pertinents. Filtrez par exemple par code société (BUKRS), type de document (BLART) et plage de dates précise, comme la date de création ERDAT.
- Mapper les champs et transformer les données : Dans chaque flux de données, associez les champs des tables SAP sources à la structure cible du journal d’événements : InvoiceNumber, ActivityName, EventTime, UserName et les autres attributs recommandés. Utilisez une logique de transformation pour renseigner en dur l’« ActivityName » de chaque flux et formater correctement les dates et les horodatages.
- Gérer les activités complexes : Pour les événements calculés tels que « Invoice Due Date Reached », utilisez la date de paiement de référence (ZFBDT) et la logique des conditions de paiement pour calculer la date d’échéance, ou récupérez directement la date d’échéance nette (NETDT) depuis BSEG. Pour les événements issus des journaux de modifications, tels que « Invoice Approved », vous devrez peut-être joindre les tables BKPF et CDHDR/CDPOS à partir du numéro et de la date du document.
- Combiner les données d’activité : Utilisez une transformation « Union » ou « Merge » dans votre outil ETL afin de regrouper les sorties des 13 flux de données individuels dans un jeu de données unique. Vérifiez que les noms et les types de colonnes sont cohérents dans tous les flux avant l’union.
- Configurer la destination cible : Définissez la destination finale du journal d’événements. Il peut s’agir d’un fichier plat (CSV), d’une table de base de données ou d’une connexion directe à une zone de préparation.
- Planifier l’extraction : Configurez les paramètres de la plage de dates pour l’extraction. Pour le chargement initial, vous pouvez extraire 6 à 12 mois de données. Pour les chargements différentiels suivants, configurez la tâche afin qu’elle extraie les données depuis la date de la dernière exécution.
- Exécuter et exporter : Exécutez la tâche ETL. Une fois l’exécution terminée, examinez le fichier de sortie afin de vérifier qu’il respecte le format requis. Le résultat final doit être un fichier CSV unique, chaque ligne représentant un événement distinct, prêt à être chargé dans ProcessMind.
Configuration
- Connexion SAP : Une connexion au serveur d’applications du système SAP ECC cible est requise. L’utilisateur SAP doit disposer d’un accès RFC et des autorisations nécessaires sur des tables telles que VBRK, BKPF, BSEG, NAST et les autres tables indiquées dans la requête.
- Licence de l’outil ETL : Une licence valide pour l’outil ETL commercial et son connecteur SAP spécifique est obligatoire.
- Plage de dates : Il est recommandé d’extraire les données sur une période de 3 à 6 mois afin d’obtenir un échantillon représentatif pour l’analyse sans imposer une charge excessive au système. Utilisez un paramètre configurable pour les dates de début et de fin.
- Filtres principaux : Filtrez toujours par code société (BUKRS) afin de limiter le périmètre de l’extraction. Il est également essentiel de filtrer par types de documents de facturation pertinents (VBRK-FKART) et types de documents comptables (BKPF-BLART), afin de ne conserver que les factures standard et d’exclure les autres types de documents, tels que les avoirs ou les documents internes.
- Performances : L’extraction de grandes tables telles que BSEG peut être lente. Utilisez des filtres sélectifs, évitez d’extraire les champs inutiles et planifiez l’extraction en dehors des heures de pointe afin de limiter son impact sur les performances du système SAP source.
a Exemple de requête config
// ETL Data Extraction Logic for SAP Order-to-Cash Invoicing
// This represents the configuration logic within a graphical ETL tool.
// == Global Parameters ==
// $StartDate: '[Start Date]' (e.g., '2023-01-01')
// $EndDate: '[End Date]' (e.g., '2023-06-30')
// $CompanyCodes: '[Company Code(s)]' (e.g., '1000', '2000')
// $BillingDocTypes: '[Billing Document Type(s)]' (e.g., 'F1', 'F2')
// == Source 1: Invoice Generated ==
// Tables: VBRK
DATA_SOURCE generated_invoices FROM VBRK WHERE
ERDAT >= $StartDate AND ERDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND FKART IN ($BillingDocTypes)
MAP {
InvoiceNumber: VBELN,
ActivityName: 'Invoice Generated',
EventTime: ERDAT + ERZET, // Combine date and time
UserName: ERNAM,
BillingDocumentType: FKART,
CustomerNumber: KUNAG,
CompanyCode: BUKRS,
TotalInvoiceAmount: NETWR
}
// == Source 2: Invoice Posted ==
// Tables: BKPF joined with VBRK
DATA_SOURCE posted_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Posted',
EventTime: A.BUDAT + A.CPUTM, // Posting date and entry time
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 3: Invoice Parked ==
// Tables: BKPF joined with VBRK
DATA_SOURCE parked_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.CPUDT >= $StartDate AND A.CPUDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = 'V'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Parked',
EventTime: A.CPUDT + A.CPUTM,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 4: Invoice Approved (Transition from Parked to Posted) ==
// Tables: BKPF joined with VBRK
DATA_SOURCE approved_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
AND EXISTS (SELECT 1 FROM VBELEGV C WHERE C.BELNR = A.BELNR) // Check if it was ever parked
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Approved',
EventTime: A.BUDAT + A.CPUTM, // Use posting date as approval date
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 5: Invoice Sent To Customer ==
// Tables: NAST joined with VBRK
DATA_SOURCE sent_invoices FROM NAST as A
INNER JOIN VBRK as B ON (A.OBJKY = B.VBELN)
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND B.BUKRS IN ($CompanyCodes)
AND A.VSTAT = '1' // Successfully processed
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Sent To Customer',
EventTime: A.ERDAT + A.ERUHR,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: B.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 6: Invoice Corrected (Reversed) ==
// Tables: VBRK (for the reversal document)
DATA_SOURCE corrected_invoices FROM VBRK as A
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.SFAKN <> '' // SFAKN is the original cancelled invoice
MAP {
InvoiceNumber: A.SFAKN, // Case ID is the original invoice
ActivityName: 'Invoice Corrected',
EventTime: A.ERDAT + A.ERZET,
UserName: A.ERNAM,
BillingDocumentType: A.FKART,
CustomerNumber: A.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: NULL // Amount belongs to the reversal doc, not original
}
// == Source 7: Invoice Due Date Reached ==
// Tables: BSEG joined with VBRK
DATA_SOURCE due_invoices FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.NETDT >= $StartDate AND A.NETDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.KOART = 'D' // Customer line item
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Due Date Reached',
EventTime: A.NETDT, // Net due date
UserName: 'System',
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 8: Payment Reminder Issued ==
// Tables: MHNK, MHND, VBRK
DATA_SOURCE reminders FROM MHNK as A
INNER JOIN MHND as D ON (A.LAUFD = D.LAUFD AND A.LAUFI = D.LAUFI)
INNER JOIN VBRK as B ON (SUBSTRING(D.XBLNR, 1, 10) = B.VBELN) // XBLNR may need parsing
WHERE A.LAUFD >= $StartDate AND A.LAUFD <= $EndDate
AND D.BUKRS IN ($CompanyCodes)
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Reminder Issued',
EventTime: A.LAUFD, // Dunning date
UserName: A.IDAPS,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: D.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 9: Dispute Case Created ==
// Tables: UDM_CASE_ATTR00
DATA_SOURCE disputes FROM UDM_CASE_ATTR00 as A
WHERE A.CREATE_TIMESTAMP >= $StartDate // Timestamp format may vary
AND A.FIN_COMP_CODE IN ($CompanyCodes)
AND A.PROCESS = 'FIN_FSCM_DIS'
MAP {
InvoiceNumber: A.BILL_DOC_ID,
ActivityName: 'Dispute Case Created',
EventTime: A.CREATE_TIMESTAMP,
UserName: A.CREATE_USER,
BillingDocumentType: NULL,
CustomerNumber: A.BP_NUMBER,
CompanyCode: A.FIN_COMP_CODE,
TotalInvoiceAmount: A.DISPUTED_AMOUNT
}
// == Source 10: Customer Payment Received ==
// Tables: BKPF
DATA_SOURCE payments FROM BKPF
WHERE BUDAT >= $StartDate AND BUDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND BLART = 'DZ' // Example for Customer Payment
MAP {
InvoiceNumber: NULL, // Invoice not yet known
ActivityName: 'Customer Payment Received',
EventTime: BUDAT + CPUTM,
UserName: USNAM,
BillingDocumentType: NULL,
CustomerNumber: NULL, // Requires join to BSEG to get customer
CompanyCode: BUKRS,
TotalInvoiceAmount: NULL
}
// == Source 11 & 12: Payment Applied To Invoice & Invoice Cleared ==
// Tables: BSEG joined with VBRK
DATA_SOURCE cleared_items FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.AUGBL <> ''
// Generate two records from this source
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Applied To Invoice',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM, // User from header of original invoice doc
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
UNION WITH {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Cleared',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 13: Invoice Written Off ==
// Tables: BSEG (for the invoice line) and BKPF (for clearing doc type)
DATA_SOURCE written_off FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
INNER JOIN BKPF as C ON (A.AUGBL = C.BELNR AND A.BUKRS = C.BUKRS AND A.AUGGJ = C.GJAHR)
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND C.BLART = '[Your Write-Off Document Type]' // e.g., 'AB'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Written Off',
EventTime: A.AUGDT,
UserName: C.USNAM, // User who posted the write-off
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Final Union of all sources ==
OUTPUT generated_invoices
UNION ALL posted_invoices
UNION ALL parked_invoices
UNION ALL approved_invoices
UNION ALL sent_invoices
UNION ALL corrected_invoices
UNION ALL due_invoices
UNION ALL reminders
UNION ALL disputes
UNION ALL payments
UNION ALL cleared_items
UNION ALL written_off Prêt à commencer ?
Utilisez ce modèle pour simplifier la préparation de vos données et obtenir des analyses utiles sur votre processus de facturation et d’émission des factures. Commencez dès aujourd’hui votre démarche vers une trésorerie plus rapidement disponible.
Accélérez vos flux de trésorerie : optimisez dès aujourd’hui votre facturation et l’émission de vos factures !
Éliminez les inefficacités, réduisez la durée du cycle de 30 % et améliorez vos flux de trésorerie.
Aucune carte bancaire requise. Commencez à optimiser en quelques minutes.