Votre template de données Commande-Encaissement – Facturation et recouvrement
Votre template de données Commande-Encaissement – Facturation et recouvrement
- Attributs recommandés à collecter
- Activités clés à suivre
- Conseils d'extraction pour `SAP S/4HANA`
Attributs De la commande à l'encaissement - Facturation et Recouvrement
| Nom | Description | ||
|---|---|---|---|
| Numéro de facture InvoiceNumber | L'identifiant unique d'un document de facturation, servant d'identifiant principal du `case` pour le processus de facturation. | ||
| Description Le numéro de facture, connu sous le nom de numéro de document de facturation dans SAP, identifie de manière unique chaque transaction de facturation. Il agit comme la clé centrale qui lie toutes les En Pourquoi c'est important C'est l'identifiant fondamental qui relie toutes les activités de facturation connexes en un seul cas, rendant possible l'analyse de processus de bout en bout. Où obtenir Table SAP : VBRK, Champ : VBELN Exemples 900012349000567890009012 | |||
| Heure de l'événement EventTime | Le `timestamp` précis indiquant quand une `activité` ou un `event` s'est produit. | ||
| Description L'heure de l'événement fournit la date et l'heure pour chaque activité, formant l'épine dorsale chronologique du processus. Cet horodatage est crucial pour calculer les durées, les temps de cycle et les temps d'attente entre les différentes étapes du processus de facturation. En analyse, l'heure de l'événement est utilisée pour ordonner séquentiellement les activités, calculer des indicateurs clés de performance comme le délai moyen de recouvrement et le temps de cycle de génération de facture, et identifier les goulots d'étranglement basés sur le temps. Elle permet une vue dynamique du processus, montrant comment les performances évoluent au fil du temps et combien de temps prend chaque étape du cycle de facturation. Pourquoi c'est important Il fournit la séquence chronologique des événements, ce qui est essentiel pour calculer toutes les métriques basées sur le temps, telles que les temps de cycle et les durées. Où obtenir Extrait de divers champs de date et d'heure selon l'activité, tels que la date et l'heure de création (VBRK-ERDAT, VBRK-ERZET), les horodatages de modification (CDHDR-UDATE, CDHDR-UTIME) ou la date de comptabilisation (BKPF-BUDAT). Exemples 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Nom de l'activité ActivityName | Le nom de l'`activité` ou de l'`event` commercial qui s'est produit au sein du processus de facturation, tel que 'Facture générée' ou 'Paiement reçu'. | ||
| Description Le nom de l' L'analyse de la séquence et de la fréquence de ces Pourquoi c'est important Cet Où obtenir Dérivé de diverses sources, y compris les codes de transaction (SY-TCODE), les statuts de document de modification (tables CDHDR/CDPOS) ou les journaux de workflow métier (par exemple, SWW_WI2OBJ). Exemples Facture généréeFacture comptabiliséePaiement client reçuFacture annulée | |||
| Date d'échéance du paiement PaymentDueDate | La date à laquelle le client est censé payer la facture. | ||
| Description La date d'échéance de paiement est calculée en fonction de la date de la facture et des conditions de paiement convenues. Elle représente la date limite de réception du paiement sans que la facture ne devienne en retard. Cet Pourquoi c'est important Il fixe la date limite de paiement pour le client, ce qui est crucial pour calculer les taux de paiement à temps et gérer les comptes clients. Où obtenir Cette date n'est pas directement stockée mais est calculée en fonction de la date de facture (VBRK-FKDAT) et de la clé des conditions de paiement (VBRK-ZTERM) en utilisant les fonctions standard de détermination de date de SAP. Exemples 2023-04-192023-05-012023-06-17 | |||
| Date de la facture InvoiceDate | La date officielle à laquelle la facture a été émise au client. | ||
| Description La date de facture, également connue sous le nom de date de facturation dans SAP, sert de point de départ pour de nombreux calculs financiers. C'est la date à partir de laquelle les conditions de paiement, les dates d'échéance et l'ancienneté de la créance sont déterminées. Cette date est un Pourquoi c'est important C'est la date principale pour les calculs financiers, servant de point de départ pour le DSO, les dates d'échéance de paiement et l'analyse du vieillissement des factures. Où obtenir Table SAP : VBRK, Champ : FKDAT Exemples 2023-03-202023-04-012023-05-18 | |||
| Heure de fin EndTime | Le `timestamp` précis indiquant quand une `activité` ou un `event` a été achevé. | ||
| Description L'heure de fin marque l'achèvement d'une Cet Pourquoi c'est important Il permet le calcul de la durée exacte (temps de traitement) de chaque activité, ce qui est fondamental pour l'analyse des goulots d'étranglement. Où obtenir Ceci est un Exemples 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Montant de la facture InvoiceAmount | La valeur nette totale de la facture. | ||
| Description Cet Le montant de la facture est utilisé dans un large éventail d'analyses. Il permet la segmentation du processus par valeur, par exemple, pour voir si les factures de grande valeur sont traitées différemment ou subissent plus de retards. Il constitue également la base des rapports financiers et du calcul de la valeur totale des créances en suspens. Pourquoi c'est important Il quantifie la valeur financière de chaque facture, permettant une analyse basée sur la valeur, la priorisation des recouvrements et l'évaluation de l'impact financier. Où obtenir Table SAP : VBRK, Champ : NETWR Exemples 1500.0025000.50125.75 | |||
| Nom d'utilisateur UserName | L'ID utilisateur de l'employé qui a exécuté l'`activité`. | ||
| Description Cet L'analyse par nom d'utilisateur aide à identifier les individus très performants, les besoins en formation ou les déséquilibres dans la répartition de la charge de travail. Elle est également cruciale pour l'analyse de la Pourquoi c'est important Il lie les activités de processus à des utilisateurs spécifiques, permettant l'analyse de la charge de travail, des performances et de la conformité au niveau individuel ou d'équipe. Où obtenir Pour les événements de création, cela se trouve dans VBRK-ERNAM. Pour les modifications ultérieures, on le trouve dans les tables d'historique des modifications comme CDHDR-USERNAME ou dans les journaux de workflow. Exemples CBURNSHSIMPSONLLEONARD | |||
| Nom du client CustomerName | Le nom du client à qui la facture a été émise. | ||
| Description Cet L'analyse du processus par client permet d'identifier des schémas spécifiques à certains comptes. Par exemple, elle peut révéler quels clients paient constamment en retard, quels sont ceux qui soulèvent le plus de litiges, ou pour lesquels le processus de facturation est le plus inefficace. Cela permet une gestion de la relation client ciblée et des stratégies de recouvrement adaptées. Pourquoi c'est important Il permet une analyse axée sur le client, aidant à identifier les comportements de paiement, les fréquences de litiges et les inefficacités de processus pour des comptes spécifiques. Où obtenir Récupéré de la table de Exemples Centrale électrique de SpringfieldKwik-E-MartCyberdyne Systems | |||
| Région Region | La région géographique du client. | ||
| Description L' Cet Pourquoi c'est important Il permet de comparer les performances de facturation entre différentes zones géographiques, aidant à identifier les disparités régionales et à standardiser les processus. Où obtenir Récupéré de la table de Exemples CANYTXBA | |||
| Code société CompanyCode | L'unité organisationnelle pour laquelle la transaction financière est enregistrée. | ||
| Description Le code société est une entité organisationnelle fondamentale dans SAP Financials, représentant une entreprise juridiquement indépendante pour laquelle des états financiers sont créés. Chaque document de facturation est affecté à un code société spécifique. L'analyse par code société est essentielle dans les organisations multi-sociétés pour comparer la performance des processus, les métriques financières comme le DSO, et la Pourquoi c'est important Il permet de segmenter l'analyse des processus par entité juridique, facilitant la comparaison des performances et la consolidation financière à l'échelle de l'organisation. Où obtenir Table SAP : VBRK, Champ : BUKRS Exemples 10002000US01 | |||
| Conditions de paiement PaymentTerms | Le code définissant les conditions de paiement, tel que la période allouée pour le paiement. | ||
| Description Les conditions de paiement sont des modalités prédéfinies, convenues avec un client, qui stipulent quand le règlement d'une facture est dû. Les exemples incluent 'Net 30' (paiement dû sous 30 jours) ou '2/10 Net 30' (une remise de 2 % si payé sous 10 jours, sinon dû sous 30 jours). L'analyse par conditions de paiement permet d'évaluer leur efficacité. En corrélant différentes conditions de paiement avec le délai réel de réception du règlement, une entreprise peut déterminer quelles conditions sont les plus efficaces pour encourager un paiement rapide et optimiser ses conditions pour améliorer sa trésorerie. Pourquoi c'est important Il définit l'échéancier de paiement convenu, permettant d'analyser quelles conditions sont les plus efficaces pour assurer un paiement rapide des clients. Où obtenir Table SAP : VBRK, Champ : ZTERM Exemples Z030Z060ZB60 | |||
| Dernière mise à jour des données LastDataUpdate | Le `timestamp` indiquant la dernière extraction ou le dernier rafraîchissement des `données` pour cet `event`. | ||
| Description Cet Cette information est utilisée pour valider la récence de l'analyse et pour gérer les plannings de rafraîchissement des Pourquoi c'est important Il indique la fraîcheur des données, ce qui est vital pour la fiabilité de l'analyse et la compréhension de sa pertinence par rapport à l'état actuel des opérations. Où obtenir Ce Exemples 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Devise Currency | Le code de devise pour le montant de la facture. | ||
| Description Cet Dans une organisation mondiale, la devise est essentielle pour une analyse et un reporting financier corrects. Elle permet une agrégation appropriée des Pourquoi c'est important Il fournit un contexte essentiel pour toutes les valeurs monétaires, garantissant une analyse et un reporting financiers précis, en particulier dans les opérations multinationales. Où obtenir Table SAP : VBRK, Champ : WAERK Exemples USDEURGBP | |||
| Est `payé à temps` IsPaidOnTime | Un indicateur booléen signalant si la facture a été payée à ou avant sa date d'échéance. | ||
| Description Ceci est un Ce drapeau simplifie le calcul et la visualisation du KPI de Taux de paiement à temps. Il permet un filtrage et une segmentation faciles pour analyser les caractéristiques des factures payées en retard par rapport à celles payées à temps. Cela peut aider à découvrir des schémas liés à des clients spécifiques, des régions ou des conditions de paiement qui entraînent des retards de paiement. Pourquoi c'est important Il simplifie la mesure des performances en signalant clairement chaque facture comme 'à temps' ou 'en retard', soutenant directement le KPI de Taux de paiement à temps. Où obtenir Ceci est un champ calculé. La logique compare le Exemples truefaux | |||
| Motif de l'avoir CreditMemoReason | Le code motif indiquant pourquoi une note de crédit a été émise. | ||
| Description Lorsqu'une facture est incorrecte et doit être créditée, un motif est généralement attribué au document d'avoir. Cela offre une manière structurée de catégoriser les sources d'erreurs de facturation. Cet Pourquoi c'est important Il catégorise les raisons d'émission de crédit, ce qui aide à identifier les sources les plus fréquentes d'erreurs de facturation et à stimuler les améliorations de qualité. Où obtenir Table SAP : VBRK, Champ : AUGRU (Motif de commande). Ce champ est utilisé sur les demandes d'avoir/débit qui sont ensuite facturées. Exemples 001 - Différence de prix002 - Mauvaise qualité005 - Retour client | |||
| Motif du litige CustomerDisputeReason | Le motif invoqué par un client pour contester une facture. | ||
| Description Lorsqu'un client conteste une facture, le motif du litige est souvent enregistré. Cela peut être dû à des erreurs de prix, des quantités incorrectes ou des marchandises endommagées. Cette information peut être stockée dans le module SAP Dispute Management ou sous forme de notes textuelles. L'analyse des motifs de litige est fondamentale pour le KPI du Taux d'erreur de facturation et l'analyse d'erreurs associée. Elle aide à identifier les causes profondes des inexactitudes de facturation, permettant à l'entreprise de résoudre les problèmes systémiques dans les processus en amont, d'améliorer la qualité des factures et d'accroître la satisfaction client. Pourquoi c'est important Il explique pourquoi les factures sont contestées, offrant un aperçu direct des causes profondes des erreurs de facturation et de l'insatisfaction client. Où obtenir Si SAP Dispute Management est utilisé, ces informations peuvent être trouvées dans des tables comme UDM_DISPUTE. Sinon, elles peuvent être dérivées de codes de motif sur des documents liés ou des champs de texte. Exemples Prix incorrectDivergence de quantitéMarchandises endommagées reçues | |||
| Numéro de commande de vente SalesOrderNumber | L'identifiant de la commande client originale ayant mené à la facture. | ||
| Description Le numéro de commande client relie le document de facturation aux Cet Pourquoi c'est important Il relie la facture à la commande client d'origine, permettant une vue plus large et de bout en bout du processus De la commande à l'encaissement au-delà de la simple facturation. Où obtenir Table SAP : VBRP (Données de poste de document de facturation), Champ : AUBEL Exemples 100001231000045610000789 | |||
| Statut du paiement PaymentStatus | Le statut actuel du paiement de la facture, tel que Ouverte, Payée ou En retard. | ||
| Description Le statut de paiement offre une vue d'ensemble de la position d'une facture dans le cycle de recouvrement. Ce n'est pas un champ unique dans SAP, mais il est déterminé en vérifiant le statut de lettrage du document comptable correspondant. Cet attribut est essentiel pour le tableau de bord de l'ancienneté des factures impayées. Il permet de segmenter toutes les factures ouvertes par leur statut et leur âge, aidant ainsi l'équipe de recouvrement à prioriser efficacement ses efforts. Le suivi des transitions entre les statuts est également un moyen de surveiller le processus de recouvrement lui-même. Pourquoi c'est important Il offre une vue claire et rapide du statut de recouvrement d'une facture, ce qui est essentiel pour gérer les créances et prioriser les efforts de recouvrement. Où obtenir Dérivé en vérifiant le statut de compensation du document comptable (VBRK-BELNR) dans des tables financières comme BSID (postes ouverts) et BSAD (postes compensés). Exemples OuvertPayéEn retardPartiellement payé | |||
| Système source SourceSystem | Identifie le système source spécifique à partir duquel les données ont été extraites. | ||
| Description Cet En analyse, il aide à différencier les processus et les performances entre différents systèmes ou entités organisationnelles. Il assure la lignée des Pourquoi c'est important Il fournit un contexte crucial sur l'origine des données, assurant la clarté dans les environnements multi-systèmes et soutenant la gouvernance des données. Où obtenir Ceci est généralement une valeur statique définie lors de l'extraction des Exemples S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Temps de traitement ProcessingTime | La durée d'une `activité`, calculée de son heure de début à son heure de fin. | ||
| Description Le temps de traitement mesure le temps passé à travailler activement sur une tâche, par opposition au temps d'attente entre les tâches. Il est calculé comme la différence entre l'heure de fin et l'heure de début d'une Cette métrique calculée est une pierre angulaire de l'analyse des performances. Elle est utilisée dans des Pourquoi c'est important Il mesure la durée active des étapes du processus, aidant à identifier les activités inefficaces qui sont des candidats privilégiés pour l'optimisation ou l'automatisation. Où obtenir Métriques calculées, dérivées en soustrayant le 'StartTime' du 'EndTime' pendant le processus de transformation des données. Exemples PT30MPT5MPT1H15M | |||
| Type de document de facturation BillingDocumentType | Un code qui classifie le document de facturation, tel qu'une facture, un avoir ou une annulation. | ||
| Description Le type de document de facturation est un champ clé qui catégorise les transactions au sein du processus de facturation. Il contrôle la manière dont le document est traité, y compris sa plage de numéros et ses règles de comptabilisation. Cet Pourquoi c'est important Il classe les transactions, permettant une analyse ciblée sur des flux de documents spécifiques comme les factures standard, les avoirs ou les annulations. Où obtenir Table SAP : VBRK, Champ : FKART Exemples F2G2S1L2 | |||
Activités De la commande à l'encaissement - Facturation et Recouvrement
| Activité | Description | ||
|---|---|---|---|
| Encaissement appliqué/réconcilié | Représente le moment où le paiement client entrant est rapproché et utilisé pour lettrer le poste de facture ouvert du grand livre auxiliaire des comptes clients. Cette `activité` achève la transaction d'un point de vue financier. | ||
| Pourquoi c'est important Mesure l'efficacité du processus d'application des encaissements. Des retards ici peuvent fausser l'état réel des comptes clients et créer un travail inutile pour les équipes de recouvrement. Où obtenir Cet Capture Capturé à partir du champ de la date de compensation (AUGDT) dans la table BSEG/ACDOCA pour le poste de facture. Type d'événement explicit | |||
| Facture clôturée | Cette `activité` signifie l'état final d'une facture payée avec succès. Elle est fonctionnellement identique à 'Espèces appliquées/réconciliées' et indique que le processus pour cette facture est terminé. | ||
| Pourquoi c'est important Sert de Où obtenir Inférencé à partir du statut du poste client dans le document comptable. Un poste est fermé ou 'compensé' lorsque les champs date de compensation (BSEG-AUGDT) et document de compensation (BSEG-AUGBL) sont renseignés. Capture Inférencé à partir du remplissage de la date de compensation (AUGDT) dans la table BSEG/ACDOCA pour le poste de facture. Type d'événement inferred | |||
| Facture comptabilisée | Représente la comptabilisation réussie du document de facturation dans le module de comptabilité financière. C'est une étape cruciale où la facture devient un poste officiel des comptes clients, créant des écritures dans le grand livre général. | ||
| Pourquoi c'est important Cette Où obtenir Cet Capture Capturé à partir de la date de comptabilisation (BUDAT) du document comptable dans la table BKPF lié au document de facturation. Type d'événement explicit | |||
| Facture générée | Cette `activité` marque la création du document de facturation dans le système. Il s'agit d'un `event` explicite capturé lorsqu'un utilisateur exécute une transaction comme VF01 ou lorsqu'un travail de fond crée la facture, résultant en une nouvelle entrée dans la table d'en-tête du document de facturation. | ||
| Pourquoi c'est important Ceci est l' Où obtenir Enregistré dans la table SAP S/4HANA VBRK (Document de facturation : Données d'en-tête) lors de sa création. La date de création (VBRK-ERDAT) et l'heure (VBRK-ERZET) servent de Capture L'événement est capturé à partir de l'horodatage de création de l'enregistrement du document de facturation dans la table VBRK. Type d'événement explicit | |||
| Paiement client reçu | Cette `activité` marque la comptabilisation d'un paiement client entrant dans le système financier. Le paiement peut ne pas encore être appliqué à une facture spécifique à ce stade, mais les fonds ont été enregistrés. | ||
| Pourquoi c'est important Un jalon crucial pour le calcul du délai moyen de recouvrement (DSO). Il signifie que l'argent a été reçu, même si la réconciliation est toujours en attente. Où obtenir Capturé à partir de la date de comptabilisation (BKPF-BUDAT) du document de paiement client (généralement le type de document 'DZ' dans la table BKPF). Capture L'événement est basé sur la création du document de paiement dans BKPF/BSEG. Type d'événement explicit | |||
| Avoir émis | Cette `activité` représente la création d'une note de crédit, qui est émise à un client pour corriger une surfacturation ou accorder un crédit pour des marchandises retournées. Elle est souvent liée à une facture originale. | ||
| Pourquoi c'est important Met en évidence les problèmes qui entraînent des ajustements financiers après la facturation. L'analyse des avoirs peut révéler des erreurs de prix, des problèmes de produits ou d'autres causes profondes de fuite de revenus. Où obtenir Créé explicitement comme un nouveau document de facturation (dans VBRK) avec un type de facturation spécifique pour les avoirs (par exemple, 'G2'). Il fait souvent référence à la commande client ou à la facture d'origine. Capture Capturé à partir de la création d'un document de facturation dans VBRK avec un type de facturation d'avoir. Type d'événement explicit | |||
| Comptabilisation de facture bloquée | Cet `event` se produit si une facture est créée mais automatiquement bloquée pour la comptabilisation dans la comptabilité financière pour diverses raisons, telles que les vérifications de crédit ou les incohérences de `données`. Ce statut est déduit du champ de statut de comptabilisation sur le document de facturation. | ||
| Pourquoi c'est important Identifie les goulots d'étranglement où les factures sont créées mais non immédiatement transmises à la finance, retardant ainsi l'intégralité du cycle de recouvrement. C'est un indicateur clé des problèmes de qualité des données ou de gestion du crédit. Où obtenir Inférencé à partir du champ de statut de comptabilisation dans l'en-tête du document de facturation (VBRK-RFBSK). Un statut comme 'A' (Document de facturation bloqué pour transfert à la FI) indique un blocage. Capture Inférencé en vérifiant la valeur du champ de statut de comptabilisation (VBRK-RFBSK) immédiatement après la génération de la facture. Type d'événement inferred | |||
| Date d'échéance de paiement atteinte | Un événement calculé représentant la date à laquelle le paiement de la facture est officiellement dû selon les conditions de paiement convenues. Ce n'est pas un événement transactionnel, mais il est dérivé des données de facturation. | ||
| Pourquoi c'est important Ceci fournit une base de référence critique pour mesurer la performance de paiement à temps et analyser le comportement de paiement des clients. Cela aide à distinguer les paiements à temps des paiements en retard. Où obtenir Calculé sur la base de la date de référence pour le paiement (BSEG-ZFBDT) et des conditions de paiement enregistrées dans le poste client du document comptable. Capture Dérivé en ajoutant les jours des conditions de paiement à la date de référence de paiement trouvée dans le poste du document comptable (BSEG). Type d'événement calculated | |||
| Facture annulée | Se produit lorsqu'une facture précédemment créée est annulée, ce qui implique généralement la création d'un document d'annulation correspondant. Cela annule effectivement la facture originale et son impact comptable. | ||
| Pourquoi c'est important Indique des retouches, des corrections ou des erreurs de facturation. Une fréquence élevée d'annulations pointe vers des problèmes importants en amont dans la saisie des commandes clients ou la configuration de la facturation. Où obtenir Capturé lorsqu'un document de facturation d'annulation est créé (par exemple, type de document 'S1'). Ce nouveau document dans VBRK fera référence au numéro de facture original dans le champ VBRK-SFAKN. Capture L'événement est capturé à partir de la date de création du document d'annulation dans VBRK qui fait référence à la facture originale. Type d'événement explicit | |||
| Facture envoyée au client | Cette `activité` marque le moment où la facture a été transmise au client, par exemple, via impression, e-mail ou EDI. Le mécanisme de capture dépend de la configuration de la gestion des sorties dans SAP. | ||
| Pourquoi c'est important Le début officiel du décompte du paiement du point de vue du client. Les retards dans l'envoi de la facture impactent directement le délai moyen de recouvrement des créances clients (DSO) et la trésorerie. Où obtenir Peut être explicitement enregistré dans les tables de contrôle de sortie (comme NAST pour les méthodes plus anciennes ou son équivalent S/4HANA). S'il n'est pas explicitement enregistré, il est souvent inféré comme se produisant en même temps que Capture Vérifiez les journaux de traitement dans les tables de gestion des sorties pour un horodatage associé au type de sortie de facture. Type d'événement explicit | |||
| Litige client ouvert | Cette `activité` se produit lorsqu'un client soulève un litige concernant une facture, lequel est ensuite formellement enregistré dans le système. Cela nécessite l'utilisation du module SAP Dispute Management. | ||
| Pourquoi c'est important Met en évidence les problèmes de précision de la facturation, de qualité des produits ou de prestation de services qui entraînent des retards de paiement. L'analyse des motifs de litige peut aider à résoudre les causes profondes et à améliorer la satisfaction client. Où obtenir Enregistré lors de la création d'un litige dans les tables de gestion des litiges (par exemple, UDM_CASE), qui est lié au poste du document comptable. Capture Capturé à partir de l'horodatage de création de l'enregistrement du litige lié à la facture. Type d'événement explicit | |||
| Rappel de paiement émis | Représente l'envoi d'un rappel de paiement ou d'une lettre de relance à un client pour une facture en retard. Il s'agit d'un `event` explicite généré par la procédure de relance automatisée. | ||
| Pourquoi c'est important Permet l'analyse de l'efficacité du processus de relance. Il aide à déterminer si les rappels accélèrent les paiements et quels niveaux de relance sont les plus efficaces. Où obtenir Enregistré dans les tables d'historique de relance (MAHNV, MHND) lorsque l'exécution de la relance (Transaction F150) est effectuée pour le poste non soldé de la facture. Capture Capturé à partir de la date d'exécution de l'avis de relance enregistré dans les tables d'historique de relance. Type d'événement explicit | |||
| Retravail de facturation identifié | Un événement calculé qui identifie une boucle de retravail où une facture a été annulée puis une nouvelle a été générée pour la même commande client. Ce n'est pas une transaction unique, mais un modèle d'événements. | ||
| Pourquoi c'est important Soutient directement le KPI de Taux de Retravail de la Facturation en quantifiant les instances de correction. Cela aide à identifier les inefficacités et à mesurer le coût de la mauvaise qualité dans le processus de facturation. Où obtenir Ce schéma est calculé en identifiant un Capture Dérivé en détectant une séquence de "Facture annulée" et "Facture générée" pour la même référence de commande client. Type d'événement calculated | |||
Guides d'extraction
Étapes
- Prérequis : Assurez-vous de disposer d'un compte utilisateur dans SAP S/4HANA avec les autorisations nécessaires pour interroger les vues Core Data Services (CDS). Plus précisément, vous avez besoin d'un accès en lecture aux vues comme I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase et I_DunningHistory.
- Accéder à l'outil d'extraction de données : Connectez-vous à votre système SAP S/4HANA. Vous pouvez utiliser divers outils pour exécuter des requêtes SQL sur les vues CDS, tels que SAP HANA Studio, DBeaver connecté via le client SAP HANA, ou le plugin SAP Analysis for Microsoft Excel. Pour ce guide, nous supposerons un client SQL standard.
- Identifier les paramètres du système : Avant d'exécuter la requête, identifiez les codes société spécifiques et la plage de dates pertinente pour votre analyse. Il est recommandé de commencer avec une portée limitée, par exemple, les 3 à 6 derniers mois de données, pour garantir des temps d'exécution de requête gérables.
- Préparer la requête SQL : Copiez la requête SQL complète fournie dans la section 'requête' de ce document dans le client SQL de votre choix.
- Personnaliser les espaces réservés : Modifiez les valeurs des espaces réservés dans la requête. Remplacez 'YYYY-MM-DD' par vos dates de début et de fin souhaitées. Remplacez 'XXXX' par votre ou vos codes société cibles. Vous devrez peut-être également ajuster l'espace réservé pour les types de documents d'avoir, par exemple, 'G2', en fonction de la configuration de votre système.
- Exécuter la requête : Exécutez la requête SQL modifiée sur la base de données SAP S/4HANA. Le temps d'exécution variera en fonction du volume de données dans la plage de dates sélectionnée.
- Examiner les résultats : Une fois la requête terminée, examinez la sortie. Le jeu de résultats doit être une table plate où chaque ligne représente une seule activité dans le processus de facturation. C'est votre journal d'événements.
- Transformation des données (si nécessaire) : La requête est conçue pour produire un format de journal d'événements propre. Cependant, vérifiez le format de l'horodatage pour vous assurer qu'il est compatible avec votre outil de process mining. La requête utilise
ABAP_SYSTEM_UTCL_TO_TIMESTAMPpour convertir en un horodatage UTC standard, qui devrait être largement compatible. - Exporter le journal des événements : Exportez l'ensemble complet des résultats de votre client SQL vers un fichier CSV. Assurez-vous que le fichier est encodé en UTF-8 pour éviter les problèmes de caractères.
- Télécharger vers ProcessMind : Téléchargez le fichier CSV généré vers la plateforme ProcessMind, en mappant les colonnes du fichier, comme InvoiceNumber, ActivityName et EventTime, aux champs correspondants de l'outil.
Configuration
- Période : Définissez les dates de début et de fin dans la clause
WHEREde l'expression de table commune (CTE) initiale. Une plage de 3 à 6 mois est recommandée pour une analyse initiale afin d'équilibrer le volume de données et les performances. Le filtre s'applique àBillingDocumentDate. - Code société : Filtrez par une ou plusieurs valeurs de
CompanyCodepour restreindre l'extraction aux entités juridiques pertinentes. C'est un filtre essentiel pour gérer la portée des données. - Types de documents : La requête inclut une logique pour identifier les avoirs basés sur le
BillingDocumentType. Vous devez configurer l'espace réservé, par exemple,('G2', 'CR'), avec les types de documents spécifiques utilisés pour les avoirs dans votre organisation. - Prérequis : L'accès aux vues CDS sous-jacentes est obligatoire. Cela nécessite des rôles et autorisations spécifiques attribués par votre équipe de sécurité SAP. De plus, pour des activités comme 'Litige client ouvert' ou 'Rappel de paiement émis', les modules SAP respectifs, SAP Dispute Management et SAP Financials Dunning, doivent être activement utilisés dans votre système.
- Performances : La requête utilise plusieurs jointures et unions. Pour les très grands jeux de données, par exemple, plusieurs années de données, envisagez de l'exécuter pendant les heures creuses ou d'appliquer des filtres plus restrictifs pour limiter l'extraction initiale des données.
a Exemple de requête sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Étapes
- Prérequis : Assurez-vous de disposer d'un compte utilisateur dans SAP S/4HANA avec les autorisations nécessaires pour interroger les vues Core Data Services (CDS). Plus précisément, vous avez besoin d'un accès en lecture aux vues comme I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase et I_DunningHistory.
- Accéder à l'outil d'extraction de données : Connectez-vous à votre système SAP S/4HANA. Vous pouvez utiliser divers outils pour exécuter des requêtes SQL sur les vues CDS, tels que SAP HANA Studio, DBeaver connecté via le client SAP HANA, ou le plugin SAP Analysis for Microsoft Excel. Pour ce guide, nous supposerons un client SQL standard.
- Identifier les paramètres du système : Avant d'exécuter la requête, identifiez les codes société spécifiques et la plage de dates pertinente pour votre analyse. Il est recommandé de commencer avec une portée limitée, par exemple, les 3 à 6 derniers mois de données, pour garantir des temps d'exécution de requête gérables.
- Préparer la requête SQL : Copiez la requête SQL complète fournie dans la section 'requête' de ce document dans le client SQL de votre choix.
- Personnaliser les espaces réservés : Modifiez les valeurs des espaces réservés dans la requête. Remplacez 'YYYY-MM-DD' par vos dates de début et de fin souhaitées. Remplacez 'XXXX' par votre ou vos codes société cibles. Vous devrez peut-être également ajuster l'espace réservé pour les types de documents d'avoir, par exemple, 'G2', en fonction de la configuration de votre système.
- Exécuter la requête : Exécutez la requête SQL modifiée sur la base de données SAP S/4HANA. Le temps d'exécution variera en fonction du volume de données dans la plage de dates sélectionnée.
- Examiner les résultats : Une fois la requête terminée, examinez la sortie. Le jeu de résultats doit être une table plate où chaque ligne représente une seule activité dans le processus de facturation. C'est votre journal d'événements.
- Transformation des données (si nécessaire) : La requête est conçue pour produire un format de journal d'événements propre. Cependant, vérifiez le format de l'horodatage pour vous assurer qu'il est compatible avec votre outil de process mining. La requête utilise
ABAP_SYSTEM_UTCL_TO_TIMESTAMPpour convertir en un horodatage UTC standard, qui devrait être largement compatible. - Exporter le journal des événements : Exportez l'ensemble complet des résultats de votre client SQL vers un fichier CSV. Assurez-vous que le fichier est encodé en UTF-8 pour éviter les problèmes de caractères.
- Télécharger vers ProcessMind : Téléchargez le fichier CSV généré vers la plateforme ProcessMind, en mappant les colonnes du fichier, comme InvoiceNumber, ActivityName et EventTime, aux champs correspondants de l'outil.
Configuration
- Période : Définissez les dates de début et de fin dans la clause
WHEREde l'expression de table commune (CTE) initiale. Une plage de 3 à 6 mois est recommandée pour une analyse initiale afin d'équilibrer le volume de données et les performances. Le filtre s'applique àBillingDocumentDate. - Code société : Filtrez par une ou plusieurs valeurs de
CompanyCodepour restreindre l'extraction aux entités juridiques pertinentes. C'est un filtre essentiel pour gérer la portée des données. - Types de documents : La requête inclut une logique pour identifier les avoirs basés sur le
BillingDocumentType. Vous devez configurer l'espace réservé, par exemple,('G2', 'CR'), avec les types de documents spécifiques utilisés pour les avoirs dans votre organisation. - Prérequis : L'accès aux vues CDS sous-jacentes est obligatoire. Cela nécessite des rôles et autorisations spécifiques attribués par votre équipe de sécurité SAP. De plus, pour des activités comme 'Litige client ouvert' ou 'Rappel de paiement émis', les modules SAP respectifs, SAP Dispute Management et SAP Financials Dunning, doivent être activement utilisés dans votre système.
- Performances : La requête utilise plusieurs jointures et unions. Pour les très grands jeux de données, par exemple, plusieurs années de données, envisagez de l'exécuter pendant les heures creuses ou d'appliquer des filtres plus restrictifs pour limiter l'extraction initiale des données.
a Exemple de requête sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime;