> Amélioration continue des processus > Record to Report Écriture de journal > SAP S/4HANA > Modèle de données

Votre modèle de données Record to Report - Écriture de journal

SAP S/4HANA

Record to Report - Attributs d'écritures de journal (20) Record to Report - Activités d'écritures de journal (12) Guides d'extraction (3)

Votre modèle de données Record to Report - Écriture de journal

Ce modèle fournit un guide complet pour la collecte des données nécessaires à l'analyse de votre processus Record to Report - Écriture de journal. Il décrit les attributs essentiels à collecter, les activités clés à suivre et des conseils pratiques pour extraire ces informations de votre système source. Utilisez cette ressource pour vous assurer de disposer de toutes les données nécessaires à une analyse Process Mining robuste.

Attributs recommandés à collecter
Activités clés à suivre
Guide pratique d’extraction

Nouveau dans les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Record to Report - Attributs d'écritures de journal

Voici les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète du processus Record to Report - Écriture de journal.

3 Obligatoire 5 Recommandé 12 Facultatif

	Nom	Description
	Activité ActivityName	Le nom de l'activité commerciale qui s'est produite à un point spécifique du processus d'écritures de journal.
Description L'Activité représente une étape ou un événement spécifique dans le cycle de vie d'une écriture de journal, tels que 'Écriture de journal créée', 'Journal soumis pour révision' ou 'Écriture de journal comptabilisée'. Ces activités sont généralement dérivées des journaux de modifications, des mises à jour de statut ou des codes de transaction enregistrés dans le système. L'analyse des activités permet de visualiser le flux du processus, d'identifier les parcours courants et de découvrir les écarts par rapport à la procédure standard. Elle est fondamentale pour le calcul de métriques telles que la fréquence des activités, les temps d'attente entre les étapes et les taux de conformité. Pourquoi c'est important Il définit les étapes du processus, permettant la visualisation des cartes de processus et l'analyse des modèles de workflow. Où obtenir Dérivé de diverses sources, y compris les champs de statut dans les tables d'en-tête/poste (par exemple, BKPF-BSTAT), les journaux de documents de modification (CDHDR/CDPOS) et les journaux de workflow. Exemples Écriture de journal crééeÉcriture de journal en attenteJournal soumis pour révisionÉcriture de Journal ApprouvéeÉcriture de journal comptabilisée
	Heure de l'événement EventTime	L'horodatage indiquant quand une activité spécifique s'est produite pour l'écriture de journal.
Description L'Heure de l'Événement est la date et l'heure précises auxquelles une activité commerciale a été exécutée et enregistrée dans le système. Chaque activité d'un cas possède son propre horodatage, créant une séquence chronologique d'événements. Cet attribut est essentiel pour toutes les analyses de processus basées sur le temps. Il est utilisé pour calculer les temps de cycle, les durées entre les activités, les temps d'attente et pour comprendre la distribution temporelle du travail. Des horodatages précis sont essentiels pour construire un modèle de processus fiable et calculer des indicateurs de performance clés comme le Temps de Cycle d'Approbation. Pourquoi c'est important Il fournit l'ordre chronologique des événements, ce qui est essentiel pour calculer toutes les métriques basées sur la durée et comprendre la chronologie du processus. Où obtenir Provient des journaux de documents de modification (CDHDR-UDATE, CDHDR-UTIME), des journaux de workflow ou des horodatages de création/saisie sur des tables comme BKPF (CPUDT, CPUTM). Exemples 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z
	ID d'écriture de journal JournalEntryId	L'identifiant unique pour une écriture de journal financière, qui sert d'identifiant de cas principal pour le processus.
Description L'ID d'écriture de journal est un numéro unique attribué à chaque document comptable lors de sa création dans SAP S/4HANA. Cet identifiant est essentiel pour suivre le cycle de vie complet d'une écriture de journal, de sa création initiale ou sa mise en attente, en passant par les workflows d'approbation, jusqu'à sa comptabilisation finale et son annulation ou sa compensation potentielle. Dans l'analyse Process Mining, cet ID est utilisé pour lier toutes les activités connexes en un seul cas. En regroupant les événements sous un ID d'écriture de journal commun, les analystes peuvent reconstituer le flux de processus de bout en bout, mesurer les temps de cycle et identifier les variations ou les goulots d'étranglement pour chaque transaction financière spécifique. C'est l'attribut fondamental pour construire l'ensemble de la vue du processus. Pourquoi c'est important Cet identifiant connecte toutes les étapes du processus associées, permettant d'analyser le parcours de bout en bout de chaque écriture de journal. Où obtenir Il s'agit d'une clé composite, généralement formée en concaténant le code société (BKPF-BUKRS), le numéro de document (BKPF-BELNR) et l'exercice (BKPF-GJAHR). Exemples 1000-1000000001-20231710-1900000055-20242000-2100003412-2023
	Code société CompanyCode	L'identifiant unique de la société ou de l'entité juridique pour laquelle l'écriture de journal est comptabilisée.
Description Le code société est une unité organisationnelle fondamentale dans SAP Financials, représentant une entité juridique indépendante pour laquelle des états financiers sont générés. Chaque écriture de journal est attribuée à un code société spécifique. Cet attribut est essentiel pour segmenter et comparer la performance des processus entre différentes parties de l'organisation. Les analystes peuvent l'utiliser pour filtrer la vue du processus pour une entité juridique spécifique, comparer les taux de rejet entre les codes société ou identifier les variations de processus propres à une région. Pourquoi c'est important Permet de filtrer et de comparer le processus d'écritures de journal entre différentes entités juridiques ou unités commerciales au sein de l'organisation. Où obtenir Table SAP S/4HANA BKPF, champ BUKRS (Code société). Exemples 10001710US01
	Créé par l'utilisateur CreatedByUser	L'ID utilisateur de la personne qui a créé l'écriture de journal.
Description Cet attribut stocke l'identifiant unique de l'utilisateur qui a initié le processus d'écriture de journal en créant le document initial. Il peut s'agir d'un comptable, d'un utilisateur métier ou d'un ID système pour les écritures automatisées. L'analyse du processus par le créateur aide à identifier des schémas liés à des utilisateurs ou des équipes spécifiques. Elle peut révéler des besoins en formation si certains utilisateurs ont des taux de rejet plus élevés, ou mettre en évidence des individus très performants. Elle est essentielle pour le tableau de bord 'Activité et débit des utilisateurs'. Pourquoi c'est important Attribue les activités de processus à des utilisateurs spécifiques, permettant l'analyse des performances, l'équilibrage de la charge de travail et l'identification des opportunités de formation. Où obtenir Table SAP S/4HANA BKPF, champ USNAM (Nom d'utilisateur). Exemples ABROWNCJONESBATCH_USER
	Date de comptabilisation PostingDate	La date à laquelle l'écriture de journal est enregistrée dans le grand livre général, affectant la période financière.
Description La date de comptabilisation détermine la période fiscale durant laquelle la transaction apparaîtra sur les états financiers. C'est une date critique pour la comptabilité et elle peut différer de la date de création ou de saisie du document dans le système. En Process Mining, la date de comptabilisation est utilisée pour l'analyse de cohortes basée sur le temps, comme la comparaison des processus de clôture de fin de mois ou l'analyse des tendances de performance sur différentes périodes financières. Elle est également utilisée pour mesurer les retards entre la création de l'écriture et la comptabilisation financière réelle. Pourquoi c'est important Crucial pour le contexte financier, il permet d'analyser la performance des processus au sein de périodes comptables spécifiques, comme la fin de mois ou la fin d'année. Où obtenir Table SAP S/4HANA BKPF, champ BUDAT (Date de comptabilisation dans le document). Exemples 2023-10-312023-11-012024-02-29
	Montant en Devise Locale AmountInLocalCurrency	La valeur totale de l'écriture de journal exprimée dans la devise locale du code société.
Description Cet attribut représente l'ampleur financière de l'écriture de journal. Il s'agit généralement de la somme des valeurs absolues de tous les postes de débit ou de crédit du document, convertie dans la devise locale du code société. L'analyse par montant permet la segmentation du processus en fonction de l'impact financier. Par exemple, les écritures de grande valeur peuvent suivre un processus d'approbation plus rigoureux que celles de faible valeur. Cela aide à prioriser les efforts d'amélioration des processus sur les transactions qui présentent le risque financier le plus élevé. Pourquoi c'est important Fournit la valeur financière de l'écriture, permettant d'analyser comment le comportement du processus évolue en fonction de la valeur monétaire en jeu. Où obtenir Calculé en additionnant les montants de la table des postes BSEG (champ DMBTR) pour une écriture de journal donnée (BELNR) et en convertissant en une valeur positive. Exemples 1500.75125000.0050.20
	Type d'écriture de journal JournalEntryType	Classe l'écriture de journal en fonction de son objectif commercial, tel qu'une comptabilisation d'actif, une facture fournisseur ou une écriture de grand livre.
Description Le Type d'écriture de journal, ou Type de document dans la terminologie SAP, est une clé qui catégorise les documents comptables. Il contrôle des aspects tels que la plage de numéros attribuée au document et les types de comptes autorisés pour la comptabilisation. L'analyse du processus par type d'écriture de journal est cruciale pour comprendre les comportements spécifiques au contexte. Par exemple, le processus d'approbation pour une simple régularisation (type SA) peut être beaucoup plus simple que pour une acquisition d'actif complexe (type AA). Cette dimension est essentielle pour le tableau de bord 'Conformité par type d'écriture'. Pourquoi c'est important Catégorise les écritures par contexte commercial, permettant l'analyse des variations de processus et des performances pour différents types de transactions financières. Où obtenir Table SAP S/4HANA BKPF, champ BLART (Type de document). Exemples SAKRAA
	Code de transaction TransactionCode	Le code de transaction SAP utilisé pour créer ou modifier l'écriture de journal.
Description Le code de transaction (T-Code) est un raccourci qui identifie une fonction ou un programme spécifique dans SAP. Pour les écritures de journal, différents T-Codes peuvent indiquer comment l'écriture a été créée, par exemple, FB01 pour une comptabilisation manuelle dans le grand livre, FV50 pour la mise en attente, ou un code automatisé pour les écritures générées par le système. Cet attribut est un indicateur fort de savoir si une activité a été effectuée manuellement par un utilisateur ou automatiquement par le système. Il est essentiel pour calculer le KPI du Taux de comptabilisation manuelle et pour identifier les opportunités d'automatisation. Pourquoi c'est important Indique comment une écriture a été traitée (par exemple, manuellement ou automatiquement), ce qui est essentiel pour l'analyse de l'automatisation et la compréhension des variations de processus. Où obtenir Table SAP S/4HANA BKPF, champ TCODE (Code de transaction). Exemples FB01FV50F-02
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière fois que les données de cet enregistrement ont été actualisées depuis le système source.
Description Cet attribut enregistre la date et l'heure de la dernière extraction ou mise à jour des données du système source. Il offre une transparence sur la fraîcheur des données analysées. Connaître l'heure de la dernière mise à jour est important pour comprendre l'actualité de l'analyse des processus. Cela aide les utilisateurs à interpréter correctement les tableaux de bord et les KPI, en sachant s'ils consultent des données quasi en temps réel ou un instantané d'une période précédente. Pourquoi c'est important Indique la fraîcheur des données, garantissant que les utilisateurs sont conscients de l'actualité de l'analyse du processus. Où obtenir Il s'agit d'un attribut de métadonnées, généralement généré et estampillé sur chaque enregistrement lors du pipeline d'ingestion de données. Exemples 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z
	Durée du cycle d'approbation ApprovalCycleTime	Le temps écoulé entre la soumission d'une écriture de journal pour approbation et son approbation ou son rejet.
Description Cette métrique calculée se concentre spécifiquement sur la durée de l'étape d'approbation. Elle mesure le temps entre l'activité 'Journal soumis pour révision' et l'activité suivante 'Écriture de journal approuvée' ou 'Écriture de journal rejetée'. Ce KPI est essentiel pour identifier les goulots d'étranglement au sein du workflow d'approbation. Des temps de cycle d'approbation élevés peuvent retarder considérablement le processus global. L'analyse de cette métrique par approbateur, code société ou type d'écriture de journal peut révéler des domaines d'amélioration spécifiques. Pourquoi c'est important Isole la durée de l'étape d'approbation, aidant à identifier et à résoudre les goulots d'étranglement dans le workflow de révision et d'approbation. Où obtenir Calculé en trouvant la différence de temps entre l'événement 'Journal Soumis pour Révision' et l'événement 'Écriture de Journal Approuvée' ou 'Écriture de Journal Rejetée'. Exemples 1 jour 2 heures4 heures 25 minutes5 jours 0 heures
	Est Comptabilisation Manuelle IsManualPosting	Un indicateur booléen qui indique si l'écriture de journal a été comptabilisée manuellement par un utilisateur.
Description Cet attribut identifie les écritures de journal qui ont été comptabilisées via une intervention manuelle de l'utilisateur, par opposition à une comptabilisation automatique par une tâche système ou une interface. Il est généralement dérivé du code de transaction utilisé pour comptabiliser le document. Ce drapeau est utilisé pour calculer le KPI du Taux de comptabilisation manuelle et aide les organisations à suivre leurs progrès en matière d'automatisation du processus Record to Report. En filtrant les écritures comptabilisées manuellement, les analystes peuvent identifier les scénarios spécifiques qui nécessitent encore une intervention humaine et les évaluer pour leur potentiel d'automatisation. Pourquoi c'est important Différencie les comptabilisations effectuées par l'homme et celles générées par le système, ce qui est crucial pour mesurer les niveaux d'automatisation et identifier les opportunités d'automatisation. Où obtenir Il s'agit d'un attribut calculé dérivé du code de transaction. Une liste prédéfinie de codes de transaction manuels (par exemple, 'FB01', 'F-02') est utilisée pour définir le drapeau sur 'vrai'. Exemples truefaux
	Est un retravail IsRework	Un indicateur booléen signalant si l'écriture de journal a fait l'objet de retouches, par exemple une correction après un rejet.
Description Cet attribut calculé marque les écritures de journal qui ont dévié du processus idéal ('happy path'). Il est généralement défini sur vrai si une activité telle que 'Écriture de journal rejetée' ou 'Écriture de journal corrigée' se produit dans le cas. Ce drapeau simplifie l'analyse de l'efficacité du processus. Il permet un calcul rapide du KPI du Taux de retravail et une comparaison directe des temps de cycle et des coûts entre les cas avec et sans retravail. L'identification des moteurs du retravail est un objectif principal de nombreuses initiatives d'amélioration des processus. Pourquoi c'est important Signale les cas ayant nécessité une correction ou des boucles supplémentaires, permettant une quantification aisée et une analyse des causes profondes des inefficacités de processus. Où obtenir Il s'agit d'un attribut calculé dérivé de la séquence d'activités dans un cas. Il est marqué comme 'vrai' si une activité telle que 'Écriture de journal rejetée' est présente. Exemples truefaux
	Exercice fiscal FiscalYear	L'exercice auquel appartient l'écriture de journal.
Description L'exercice est une partie de la clé unique d'une écriture de journal, aux côtés du code société et du numéro de document. Il représente l'année financière à laquelle le document est pertinent. Dans l'analyse, l'exercice est utilisé pour l'analyse des tendances à long terme et pour garantir l'unicité de l'identifiant de cas. La comparaison des métriques de processus sur différents exercices peut révéler des améliorations ou des dégradations de performance au fil du temps. Pourquoi c'est important Fournit un composant critique pour l'identification unique des documents et permet l'analyse annuelle de la performance des processus. Où obtenir Table SAP S/4HANA BKPF, champ GJAHR (Exercice). Exemples 202320242022
	Heure de fin EndTime	Le `timestamp` indiquant la date et l'heure à laquelle l'`activité` a été achevée.
Description L'heure de fin marque l'achèvement d'une activité. Dans de nombreux journaux d'événements, l'heure de début et l'heure de fin d'une activité sont identiques, représentant un événement instantané. Cependant, pour les activités ayant une durée mesurable, comme la révision active d'un document par un utilisateur, cet attribut peut capturer cette durée. Avoir une heure de fin distincte permet un calcul plus précis des temps de traitement des activités par rapport aux temps d'attente. Cela aide à différencier le temps où une tâche était activement travaillée du temps où elle était inactive dans une file d'attente. Pourquoi c'est important Permet le calcul des temps de traitement précis des activités, en séparant le temps de travail actif du temps d'attente inactif. Où obtenir Généralement identique à StartTime pour les événements atomiques. Pour les activités durables, il peut provenir des journaux de workflow ou être calculé à partir d'événements ultérieurs. Exemples 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z
	Raison de l'annulation ReversalReason	Un code indiquant la raison pour laquelle une écriture de journal comptabilisée a été contrepassée.
Description Lorsqu'une écriture de journal comptabilisée est incorrecte, elle ne peut pas être supprimée mais doit être annulée par un nouveau document. Le code motif d'annulation explique pourquoi cette action a été effectuée, par exemple, en raison d'une date de comptabilisation ou d'un montant incorrect. L'analyse des motifs d'annulation aide à identifier les causes profondes des erreurs dans le processus Record to Report. Une fréquence élevée d'un motif particulier peut indiquer des problèmes systémiques, tels qu'une formation inadéquate ou des défaillances de contrôle, qui doivent être résolus pour améliorer la qualité dès la première fois. Pourquoi c'est important Aide à diagnostiquer la cause profonde des erreurs menant aux contrepassations, fournissant les insights nécessaires pour réduire les retouches et améliorer la qualité des processus. Où obtenir Table SAP S/4HANA BKPF, champ STGRD (Motif d'annulation). Exemples 010205
	Statut du document DocumentStatus	Le statut de traitement actuel de l'écriture de journal, tel que En attente, Comptabilisée ou Compensée.
Description Le statut du document indique l'état de l'écriture de journal au cours de son cycle de vie. Par exemple, un document 'en attente' est sauvegardé mais pas encore comptabilisé dans le grand livre général, tandis qu'un document 'comptabilisé' est finalisé. L'analyse du statut aide à comprendre le flux de travail et à identifier les goulots d'étranglement. Un volume élevé de documents restant longtemps en état 'en attente' ou 'en attente d'approbation' peut signaler des inefficacités dans le processus. C'est également une source clé pour dériver les activités du processus. Pourquoi c'est important Fournit un aperçu de la position d'une écriture de journal dans son cycle de vie, aidant à identifier les files d'attente et les goulots d'étranglement. Où obtenir Table SAP S/4HANA BKPF, champ BSTAT (Statut du document). Exemples VAB
	Système source SourceSystem	Identifie le système source d'où les données d'écritures de journal ont été extraites.
Description Cet attribut spécifie le système source où les données d'écritures de journal ont été créées. Pour les entreprises ayant plusieurs instances ERP ou un mélange de systèmes anciens et modernes, cela aide à différencier les sources de données. Dans l'analyse, il peut être utilisé pour comparer les performances des processus entre différents systèmes ou pour filtrer les données pour une source spécifique. Il est important pour la gouvernance des données et pour s'assurer que le contexte des données est compris. Pourquoi c'est important Fournit le contexte de l'origine des données, crucial dans les environnements multi-systèmes pour une analyse et une comparaison précises des processus. Où obtenir Il s'agit généralement d'une valeur statique ajoutée lors de l'extraction des données, identifiant l'instance SAP S/4HANA spécifique (par exemple, SID ou nom de système logique). Exemples S4H_PROD_100ECC_FIN_200S4C_US_EAST
	Temps de cycle total TotalCycleTime	La durée totale entre la création de la première activité et l'achèvement de la dernière activité pour une écriture de journal.
Description Cette métrique calculée mesure la durée de bout en bout du processus d'écriture de journal pour chaque cas. Il s'agit de la différence entre l'horodatage de la toute dernière activité observée et l'horodatage de la toute première. Le temps de cycle total est un KPI principal pour mesurer l'efficacité globale du processus. Il offre une vue d'ensemble de la performance du processus et est utilisé dans les tableaux de bord pour suivre les tendances au fil du temps. L'analyse des causes des longs temps de cycle est un point de départ courant pour l'amélioration des processus. Pourquoi c'est important Mesure la durée de bout en bout du processus, fournissant un indicateur clé de performance pour l'efficacité et la rapidité globales du processus. Où obtenir Calculé en soustrayant le EventTime minimum du EventTime maximum pour chaque JournalEntryId unique. Exemples 2 jours 4 heures 30 minutes8 heures 15 minutes15 days 2 hours
	Utilisateur approbateur ApproverUser	L'ID utilisateur de la personne qui a approuvé ou rejeté l'écriture de journal.
Description Cet attribut identifie l'utilisateur responsable de la révision et de la prise de décision concernant une écriture de journal soumise. Dans un workflow d'approbation à plusieurs niveaux, il peut y avoir plusieurs approbateurs pour une seule écriture de journal. Cette information est essentielle pour analyser le processus d'approbation en détail. Elle aide à mesurer la charge de travail des différents approbateurs, à calculer les temps d'approbation individuels et à identifier les goulots d'étranglement dans la chaîne d'approbation. Elle prend en charge directement le tableau de bord 'Activité et débit des utilisateurs'. Pourquoi c'est important Identifie l'individu responsable de l'approbation, permettant l'analyse des charges de travail d'approbation, des performances et des goulots d'étranglement. Où obtenir Provient des journaux de workflow (par exemple, SWW_WI2OBJ, SWWLOG) ou des tables de documents de modification (CDHDR/CDPOS) en suivant qui a exécuté l'étape d'approbation. Exemples DMILLERFWHITEKCHEN

Obligatoire Recommandé Facultatif

Record to Report - Activités d'écritures de journal

Voici les étapes clés du processus et les jalons à capturer dans votre `journal d'événements` pour une découverte et une optimisation précises des processus.

6 Recommandé 6 Facultatif

	Activité	Description
	Annulation d'écriture de journal traitée	Une écriture de journal précédemment comptabilisée est contrepassée en créant un nouveau document avec des écritures inverses. Cette action est prise pour corriger les erreurs dans les documents comptabilisés et est une transaction explicite et auditable.
Pourquoi c'est important Les annulations indiquent une erreur dans un document comptabilisé. Un taux d'annulation élevé suggère des problèmes sous-jacents dans le processus d'approbation ou la qualité de la saisie des données, et le suivi de cet indicateur aide à améliorer la précision dès la première fois. Où obtenir L'annulation est un événement explicite. L'en-tête (BKPF) du nouveau document d'annulation contient une référence au document original dans le champ N° document annulé (STBLG). La date de comptabilisation du nouveau document est l'heure de l'événement. Capture Identifiez les documents où BKPF-STBLG est renseigné. L'horodatage de l'événement est la date de comptabilisation du document de contrepassation. Type d'événement explicit
	Écriture de Journal Approuvée	L'écriture de journal reçoit l'approbation finale d'un gestionnaire autorisé, confirmant sa validité et sa précision. Cette activité est la dernière porte avant que le document ne puisse être comptabilisé dans le grand livre général.
Pourquoi c'est important C'est une étape cruciale qui conclut le cycle d'approbation. Le temps nécessaire pour atteindre cette étape est une composante majeure de la durée totale du processus et un indicateur clé de l'efficacité de l'approbateur. Où obtenir Cet événement est déduit d'un journal de workflow affichant l'étape d'approbation finale ou d'un changement de statut sur le document. L'ID utilisateur et l'horodatage de l'approbateur peuvent être extraits des données de workflow ou des journaux de modifications. Capture Identifier l'horodatage de l'étape finale d'approbation dans les journaux de workflow ou le changement de statut en 'Approuvé' dans les documents de modification. Type d'événement inferred
	Écriture de journal compensée	Un poste ouvert au sein d'une écriture de journal est compensé par une autre comptabilisation, telle qu'un paiement apurant une facture. Cette activité marque le rapprochement de postes spécifiques, les clôturant efficacement.
Pourquoi c'est important Cette activité représente l'étape finale de rapprochement pour de nombreuses écritures de journal, en particulier celles impliquant des comptes de transit ou des comptes à gestion par poste individuel. L'analyse du temps entre la comptabilisation et la compensation aide à mesurer l'efficacité du rapprochement. Où obtenir Cet événement est déduit de la table des postes individuels (BSEG ou la vue ACDOCA). Lorsqu'un poste est compensé, les champs Date de compensation (AUGDT) et Document de compensation (AUGBL) sont renseignés pour cette ligne. Capture Utiliser la date de compensation (BSEG-AUGDT) pour le poste comme horodatage de l'événement. Type d'événement inferred
	Écriture de journal comptabilisée	L'écriture de journal est officiellement enregistrée dans le grand livre général, impactant les états financiers de l'entreprise. C'est à ce moment que le document devient un enregistrement financier permanent.
Pourquoi c'est important C'est le jalon de succès principal, marquant la fin du cycle de traitement principal. L'analyse du débit des écritures comptabilisées et du temps nécessaire pour atteindre cette étape sont des métriques fondamentales du Process Mining. Où obtenir Il s'agit d'un événement explicite marqué par la date de comptabilisation (BUDAT) dans la table BKPF. Un document comptabilisé a un statut de document vide (BSTAT), le distinguant des documents en attente ('V') ou bloqués ('D'). Capture Utiliser la date de comptabilisation (BKPF-BUDAT) et la date de saisie (BKPF-CPUDT) pour horodater l'événement. Un BKPF-BSTAT vide indique un document comptabilisé. Type d'événement explicit
	Écriture de journal créée	Cette activité marque la création initiale d'un document d'écriture de journal dans le système. L'enregistrement est créé dans la table d'en-tête (BKPF), mais il n'a pas encore été comptabilisé dans le grand livre général. C'est le point de départ du cycle de vie de l'écriture de journal.
Pourquoi c'est important C'est l'événement de début principal du processus. L'analyse du temps écoulé entre cet événement et la comptabilisation est cruciale pour mesurer le temps de cycle global et identifier les retards initiaux de saisie des données. Où obtenir Cet événement peut être explicitement capturé à partir de la table SAP BKPF en utilisant les champs de date de création (CPUDT) et d'heure de création (CPUTM) pour un numéro de document donné (BELNR). Capture Utiliser BKPF-CPUDT et BKPF-CPUTM pour l'horodatage de l'événement. Type d'événement explicit
	Journal soumis pour révision	Le créateur de l'écriture de journal soumet formellement le document au workflow de révision et d'approbation. Cette activité représente le transfert de la saisie des données au processus de contrôle formel, initiant le cycle d'approbation.
Pourquoi c'est important Ceci marque le début du temps de cycle d'approbation. Mesurer à partir de ce point jusqu'à l'approbation ou le rejet final aide à isoler les goulots d'étranglement spécifiquement au sein des étapes de révision et d'approbation. Où obtenir Ceci est souvent capturé à partir des journaux de workflow (tables SWW_WIHEAD, SWWLOG) liés à l'objet métier. Il peut également être déduit d'un changement de statut dans un champ personnalisé de l'en-tête de document (BKPF). Capture Horodatage de la création de l'élément de workflow ou d'un changement de champ de statut vers 'Soumis' ou 'En révision'. Type d'événement inferred
	Comptabilisation manuelle identifiée	L'écriture de journal a été comptabilisée à l'aide d'un code de transaction manuel plutôt que via une interface automatisée ou une tâche par lots. Il ne s'agit pas d'un événement temporel mais d'une classification de l'activité de comptabilisation.
Pourquoi c'est important L'identification des comptabilisations manuelles est cruciale pour les initiatives d'automatisation. Un taux élevé de comptabilisations manuelles suggère des opportunités de rationaliser les processus en intégrant des sous-systèmes ou en utilisant des programmes de comptabilisation automatisés. Où obtenir Ceci est calculé en analysant le champ du code de transaction (TCODE) dans la table d'en-tête de document (BKPF). Une liste de T-Codes manuels connus (par exemple, FB01, F-02, FB50) est utilisée pour classer l'écriture. Capture Classer l'événement en fonction du BKPF-TCODE par rapport à une liste prédéfinie de codes de transaction manuels au moment de la comptabilisation. Type d'événement calculated
	Document justificatif joint	Un utilisateur joint un ou plusieurs documents justificatifs, tels que des factures ou des feuilles de calcul, à l'écriture de journal. Ceci est généralement fait pour fournir des preuves et un contexte à la transaction financière pendant le processus de révision et d'audit.
Pourquoi c'est important S'assurer que la documentation est jointe avant la révision est crucial pour la conformité et l'efficacité de l'approbation. Cette activité aide à mesurer l'adhésion aux politiques de documentation et son impact sur les temps de cycle d'approbation. Où obtenir Ceci est généralement déduit en vérifiant l'horodatage de création des pièces jointes liées via les Generic Object Services (GOS). La table SRGBTBREL lie l'objet métier (par exemple, le document BKPF) à la pièce jointe. Capture Interroger les tables de pièces jointes GOS (par exemple, SRGBTBREL) pour les liens vers l'objet BKPF et utiliser l'horodatage de création de la pièce jointe. Type d'événement inferred
	Écriture de journal corrigée	L'utilisateur modifie une écriture de journal après qu'elle ait été rejetée ou renvoyée pour modifications. Cela représente l'effort de retravail nécessaire pour résoudre les problèmes identifiés lors du processus de révision avant la nouvelle soumission.
Pourquoi c'est important Cette activité quantifie les boucles de retravail. L'analyse de la fréquence et de la durée des corrections aide à identifier les sources d'inefficacité et met en évidence les opportunités de formation et de clarification des processus. Où obtenir Cela peut être déduit en suivant la date de 'Dernière modification' (AEDAT) dans la table BKPF pour un document qui était auparavant à l'état 'Rejeté'. Les documents de modification fournissent des détails plus spécifiques sur ce qui a été modifié. Capture Utiliser l'horodatage des en-têtes de documents de modification (CDHDR-UDATE) pour les modifications effectuées après un événement de rejet. Type d'événement inferred
	Écriture de journal en attente	Un utilisateur sauvegarde une écriture de journal incomplète sans la comptabiliser, permettant une complétion ou une révision ultérieure. C'est une action explicite qui crée un enregistrement d'en-tête de document avec un statut 'mis en attente', le maintenant dans un état non comptabilisé.
Pourquoi c'est important La mise en attente est une étape courante avant la soumission. Suivre la durée de l'état "en attente" permet d'identifier les retards dans la complétion et la préparation des données avant le début du processus formel de révision et d'approbation. Où obtenir Dans la table BKPF, un document mis en attente est identifié par le champ de statut du document (BSTAT) ayant une valeur 'V'. L'horodatage de l'événement est la date de création (CPUDT). Capture Filtrer les documents où BKPF-BSTAT = 'V' au moment de la création. Type d'événement explicit
	Écriture de Journal Modifiée après Comptabilisation	Un utilisateur modifie un ensemble limité de champs sur une écriture de journal après qu'elle a déjà été comptabilisée dans le grand livre. Bien que la plupart des données financières soient immuables après la comptabilisation, certains champs comme le texte ou les affectations peuvent être modifiés.
Pourquoi c'est important Cette activité est un indicateur de conformité critique. Les modifications après comptabilisation peuvent indiquer des tentatives d'altération des enregistrements et doivent être étroitement surveillées pour prévenir la fraude et garantir l'intégrité des données. Où obtenir Cela peut être déduit de manière fiable des tables de documents de modification (CDHDR et CDPOS). Une entrée dans CDHDR pour le numéro de document avec une date de modification postérieure à la date de comptabilisation indique une modification après comptabilisation. Capture Recherchez les enregistrements dans CDHDR où l'horodatage de modification (UDATE/UTIME) est postérieur à la date de comptabilisation du document (BKPF-BUDAT). Type d'événement inferred
	Écriture de journal rejetée	Un réviseur ou un approbateur refuse l'écriture de journal, l'empêchant d'être comptabilisée. Le document est généralement renvoyé au créateur pour correction, initiant une boucle de retravail.
Pourquoi c'est important Le suivi des rejets est essentiel pour comprendre la qualité des processus et identifier les erreurs courantes. Des taux de rejet élevés indiquent des problèmes de précision des données, de compréhension des politiques ou une documentation justificative insuffisante. Où obtenir Cet événement est déduit d'un changement de statut dans un journal de workflow ou d'un champ de statut personnalisé sur le document d'écriture de journal. Les journaux de documents de modification (CDHDR/CDPOS) sur le champ de statut pertinent peuvent fournir l'horodatage. Capture Identifier le changement de champ de statut en 'Rejeté' via les documents de modification (CDHDR/CDPOS) ou les journaux de workflow. Type d'événement inferred

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de SAP S/4HANA

Étapes

Prérequis et Accès: Assurez-vous de disposer d'un utilisateur avec les autorisations nécessaires pour interroger la base de données sous-jacente de SAP S/4HANA ou exécuter des rapports ABAP. Vous aurez besoin d'un accès en lecture aux vues CDS I_JournalEntry, I_JournalEntryItem, et aux tables CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ et SWWLOGHIST. L'accès est généralement accordé via un client de base de données comme SAP HANA Studio, DBeaver, ou en utilisant les ABAP Development Tools (ADT) de SAP pour Eclipse.
Identifier les Configurations Spécifiques au Système: Avant d'exécuter la requête, vous devez identifier les codes de tâche spécifiques utilisés dans votre workflow d'approbation des écritures de journal. Consultez votre administrateur de workflow SAP pour trouver les ID de tâche (par exemple, TS12345678) qui correspondent aux événements de soumission, de rejet et d'approbation. Ceux-ci sont requis pour les espaces réservés dans la requête finale.
Préparer la Requête SQL: Copiez la requête SQL complète fournie dans la section query dans votre client SQL ou outil de développement choisi.
Définir les Paramètres de la Requête: Localisez les espaces réservés dans la requête et remplacez-les par vos valeurs spécifiques. Cela inclut la définition des paramètres [YourCompanyCode], [StartDate] et [EndDate]. Vous devez également remplacer les ID de tâches de workflow des espaces réservés ([Workflow Submitted Task ID], [Workflow Rejected Task ID], [Workflow Approved Task ID]) par les valeurs que vous avez identifiées à l'étape précédente.
Exécuter la Requête d'Extraction: Exécutez la requête SQL modifiée sur la base de données SAP S/4HANA. Selon la plage de dates et le volume de données, la requête peut prendre un temps considérable à s'exécuter. Il est recommandé de l'exécuter pendant les heures creuses.
Examiner les Résultats Initiaux: Une fois la requête terminée, examinez les premières lignes de la sortie pour vous assurer que toutes les colonnes, telles que JournalEntryId, ActivityName et EventTime, sont remplies comme prévu. Le jeu de résultats doit contenir une ligne pour chaque événement commercial distinct dans le cycle de vie de l'écriture de journal.
Exporter les Données au Format CSV: Exportez l'ensemble du jeu de résultats de votre outil SQL vers un seul fichier CSV. Assurez-vous que le fichier utilise l'encodage UTF-8 pour éviter les problèmes avec les caractères spéciaux.
Préparer l'Upload: Avant de télécharger vers un outil de Process Mining, confirmez que le fichier CSV a les en-têtes requis. Les données sont déjà structurées comme un journal d'événements, donc aucune transformation ou pivotement supplémentaire ne devrait être nécessaire.

Configuration

Vues Core Data Services (CDS): L'extraction utilise principalement I_JournalEntry pour les données d'en-tête et I_JournalEntryItem pour les détails des postes et des montants. Ces vues offrent une interface simplifiée et sémantiquement riche au journal universel (ACDOCA).
Tables de Support: Pour obtenir une vue complète du processus, la requête joint également plusieurs tables SAP standard:
- CDHDR et CDPOS pour le suivi des modifications apportées aux documents.
- SRGBREL et SOOD pour identifier quand des pièces jointes sont liées via les Generic Object Services (GOS).
- SWW_WI2OBJ et SWWLOGHIST pour extraire les événements clés du workflow d'approbation.
Filtrage par Plage de Dates: Il est essentiel de filtrer les données par une plage de dates spécifique pour gérer les performances. Utilisez le champ I_JournalEntry.CreationDateTime dans la clause WHERE. Une plage de 3 à 6 mois est recommandée pour une analyse initiale.
Filtrage Organisationnel: Filtrez toujours par CompanyCode pour limiter l'extraction aux entités juridiques pertinentes. L'interrogation de tous les codes société en une seule fois dans un grand système peut entraîner des temps d'exécution extrêmement longs.
ID de Tâches de Workflow: La requête contient des espaces réservés pour les ID de tâches de workflow (par exemple, [Workflow Approved Task ID]). Ceux-ci sont uniques à chaque installation SAP et doivent être configurés correctement pour que les activités de workflow soient extraites. Sans eux, aucun événement de soumission, d'approbation ou de rejet ne sera capturé.
Prérequis: L'utilisateur exécutant nécessite des autorisations de lecture étendues sur les tables financières, système et de workflow. Ces autorisations ne sont pas standard et doivent être attribuées spécifiquement.

a Exemple de requête sql

WITH JournalEntryAmountCTE AS (
    SELECT
        CompanyCode,
        AccountingDocument,
        FiscalYear,
        SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
    FROM I_JournalEntryItem
    GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
    SELECT
        JE.CompanyCode,
        JE.AccountingDocument,
        JE.FiscalYear,
        JE.CreatedByUser,
        JE.CreationDateTime,
        JE.PostingDateTime,
        JE.PostingDate,
        JE.AccountingDocumentType,
        JE.DocumentIsParked,
        JE.ReversedJournalEntry,
        JE.TransactionCode,
        JEA.AmountInLocalCurrency
    FROM I_JournalEntry AS JE
    LEFT JOIN JournalEntryAmountCTE AS JEA
        ON JE.CompanyCode = JEA.CompanyCode
        AND JE.AccountingDocument = JEA.AccountingDocument
        AND JE.FiscalYear = JEA.FiscalYear
    WHERE JE.CompanyCode IN ('[YourCompanyCode]')
      AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    BJE.CreationDateTime AS "EventTime",
    BJE.CreatedByUser AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE

UNION ALL

-- 2. Journal Entry Parked
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Parked' AS "ActivityName",
    BJE.CreationDateTime AS "EventTime",
    BJE.CreatedByUser AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'

UNION ALL

-- 3. Supporting Documentation Attached
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
    SOOD.OWNER AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND SRGBREL.TYPEID_A = 'BKPF'
    AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
    AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
    AND SOOD.OBJNO = SRGBREL.INSTID_B(5)

UNION ALL

-- 4. Journal Submitted For Review
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Submitted For Review' AS "ActivityName",
    LOG.END_TS AS "EventTime",
    LOG.EXEC_USER AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    LOG.END_TS AS "EventTime",
    LOG.EXEC_USER AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'

UNION ALL

-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Corrected' AS "ActivityName",
    TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
    CH.USERNAME AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'

UNION ALL

-- 7. Journal Entry Approved
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Approved' AS "ActivityName",
    LOG.END_TS AS "EventTime",
    LOG.EXEC_USER AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'

UNION ALL

-- 8. Manual Posting Identified
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Manual Posting Identified' AS "ActivityName",
    BJE.PostingDateTime AS "EventTime",
    BJE.CreatedByUser AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')

UNION ALL

-- 9. Journal Entry Posted
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    BJE.PostingDateTime AS "EventTime",
    BJE.CreatedByUser AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL

UNION ALL

-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Changed After Posting' AS "ActivityName",
    TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
    CH.USERNAME AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime

UNION ALL

-- 11. Journal Entry Cleared
SELECT
    JEI.AccountingDocument AS "JournalEntryId",
    'Journal Entry Cleared' AS "ActivityName",
    MIN(JEI.ClearingDateTime) AS "EventTime",
    BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
    AND JEI.CompanyCode = BJE.CompanyCode
    AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency

UNION ALL

-- 12. Journal Entry Reversal Processed
SELECT
    OriginalDoc.AccountingDocument AS "JournalEntryId",
    'Journal Entry Reversal Processed' AS "ActivityName",
    ReversalDoc.PostingDateTime AS "EventTime",
    ReversalDoc.CreatedByUser AS "CreatedByUser",
    OriginalDoc.CompanyCode AS "CompanyCode",
    OriginalDoc.AccountingDocumentType AS "JournalEntryType",
    OriginalDoc.PostingDate AS "PostingDate",
    OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
    ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
    AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
    AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL;

Étapes

Prérequis et Accès: Assurez-vous de disposer d'un utilisateur avec les autorisations nécessaires pour interroger la base de données sous-jacente de SAP S/4HANA ou exécuter des rapports ABAP. Vous aurez besoin d'un accès en lecture aux vues CDS I_JournalEntry, I_JournalEntryItem, et aux tables CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ et SWWLOGHIST. L'accès est généralement accordé via un client de base de données comme SAP HANA Studio, DBeaver, ou en utilisant les ABAP Development Tools (ADT) de SAP pour Eclipse.
Identifier les Configurations Spécifiques au Système: Avant d'exécuter la requête, vous devez identifier les codes de tâche spécifiques utilisés dans votre workflow d'approbation des écritures de journal. Consultez votre administrateur de workflow SAP pour trouver les ID de tâche (par exemple, TS12345678) qui correspondent aux événements de soumission, de rejet et d'approbation. Ceux-ci sont requis pour les espaces réservés dans la requête finale.
Préparer la Requête SQL: Copiez la requête SQL complète fournie dans la section query dans votre client SQL ou outil de développement choisi.
Définir les Paramètres de la Requête: Localisez les espaces réservés dans la requête et remplacez-les par vos valeurs spécifiques. Cela inclut la définition des paramètres [YourCompanyCode], [StartDate] et [EndDate]. Vous devez également remplacer les ID de tâches de workflow des espaces réservés ([Workflow Submitted Task ID], [Workflow Rejected Task ID], [Workflow Approved Task ID]) par les valeurs que vous avez identifiées à l'étape précédente.
Exécuter la Requête d'Extraction: Exécutez la requête SQL modifiée sur la base de données SAP S/4HANA. Selon la plage de dates et le volume de données, la requête peut prendre un temps considérable à s'exécuter. Il est recommandé de l'exécuter pendant les heures creuses.
Examiner les Résultats Initiaux: Une fois la requête terminée, examinez les premières lignes de la sortie pour vous assurer que toutes les colonnes, telles que JournalEntryId, ActivityName et EventTime, sont remplies comme prévu. Le jeu de résultats doit contenir une ligne pour chaque événement commercial distinct dans le cycle de vie de l'écriture de journal.
Exporter les Données au Format CSV: Exportez l'ensemble du jeu de résultats de votre outil SQL vers un seul fichier CSV. Assurez-vous que le fichier utilise l'encodage UTF-8 pour éviter les problèmes avec les caractères spéciaux.
Préparer l'Upload: Avant de télécharger vers un outil de Process Mining, confirmez que le fichier CSV a les en-têtes requis. Les données sont déjà structurées comme un journal d'événements, donc aucune transformation ou pivotement supplémentaire ne devrait être nécessaire.

Configuration

Vues Core Data Services (CDS): L'extraction utilise principalement I_JournalEntry pour les données d'en-tête et I_JournalEntryItem pour les détails des postes et des montants. Ces vues offrent une interface simplifiée et sémantiquement riche au journal universel (ACDOCA).
Tables de Support: Pour obtenir une vue complète du processus, la requête joint également plusieurs tables SAP standard:
- CDHDR et CDPOS pour le suivi des modifications apportées aux documents.
- SRGBREL et SOOD pour identifier quand des pièces jointes sont liées via les Generic Object Services (GOS).
- SWW_WI2OBJ et SWWLOGHIST pour extraire les événements clés du workflow d'approbation.
Filtrage par Plage de Dates: Il est essentiel de filtrer les données par une plage de dates spécifique pour gérer les performances. Utilisez le champ I_JournalEntry.CreationDateTime dans la clause WHERE. Une plage de 3 à 6 mois est recommandée pour une analyse initiale.
Filtrage Organisationnel: Filtrez toujours par CompanyCode pour limiter l'extraction aux entités juridiques pertinentes. L'interrogation de tous les codes société en une seule fois dans un grand système peut entraîner des temps d'exécution extrêmement longs.
ID de Tâches de Workflow: La requête contient des espaces réservés pour les ID de tâches de workflow (par exemple, [Workflow Approved Task ID]). Ceux-ci sont uniques à chaque installation SAP et doivent être configurés correctement pour que les activités de workflow soient extraites. Sans eux, aucun événement de soumission, d'approbation ou de rejet ne sera capturé.
Prérequis: L'utilisateur exécutant nécessite des autorisations de lecture étendues sur les tables financières, système et de workflow. Ces autorisations ne sont pas standard et doivent être attribuées spécifiquement.

a Exemple de requête sql

WITH JournalEntryAmountCTE AS (
    SELECT
        CompanyCode,
        AccountingDocument,
        FiscalYear,
        SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
    FROM I_JournalEntryItem
    GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
    SELECT
        JE.CompanyCode,
        JE.AccountingDocument,
        JE.FiscalYear,
        JE.CreatedByUser,
        JE.CreationDateTime,
        JE.PostingDateTime,
        JE.PostingDate,
        JE.AccountingDocumentType,
        JE.DocumentIsParked,
        JE.ReversedJournalEntry,
        JE.TransactionCode,
        JEA.AmountInLocalCurrency
    FROM I_JournalEntry AS JE
    LEFT JOIN JournalEntryAmountCTE AS JEA
        ON JE.CompanyCode = JEA.CompanyCode
        AND JE.AccountingDocument = JEA.AccountingDocument
        AND JE.FiscalYear = JEA.FiscalYear
    WHERE JE.CompanyCode IN ('[YourCompanyCode]')
      AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    BJE.CreationDateTime AS "EventTime",
    BJE.CreatedByUser AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE

UNION ALL

-- 2. Journal Entry Parked
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Parked' AS "ActivityName",
    BJE.CreationDateTime AS "EventTime",
    BJE.CreatedByUser AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'

UNION ALL

-- 3. Supporting Documentation Attached
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
    SOOD.OWNER AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND SRGBREL.TYPEID_A = 'BKPF'
    AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
    AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
    AND SOOD.OBJNO = SRGBREL.INSTID_B(5)

UNION ALL

-- 4. Journal Submitted For Review
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Submitted For Review' AS "ActivityName",
    LOG.END_TS AS "EventTime",
    LOG.EXEC_USER AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    LOG.END_TS AS "EventTime",
    LOG.EXEC_USER AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'

UNION ALL

-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Corrected' AS "ActivityName",
    TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
    CH.USERNAME AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'

UNION ALL

-- 7. Journal Entry Approved
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Approved' AS "ActivityName",
    LOG.END_TS AS "EventTime",
    LOG.EXEC_USER AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'

UNION ALL

-- 8. Manual Posting Identified
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Manual Posting Identified' AS "ActivityName",
    BJE.PostingDateTime AS "EventTime",
    BJE.CreatedByUser AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')

UNION ALL

-- 9. Journal Entry Posted
SELECT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    BJE.PostingDateTime AS "EventTime",
    BJE.CreatedByUser AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL

UNION ALL

-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
    BJE.AccountingDocument AS "JournalEntryId",
    'Journal Entry Changed After Posting' AS "ActivityName",
    TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
    CH.USERNAME AS "CreatedByUser",
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
    AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime

UNION ALL

-- 11. Journal Entry Cleared
SELECT
    JEI.AccountingDocument AS "JournalEntryId",
    'Journal Entry Cleared' AS "ActivityName",
    MIN(JEI.ClearingDateTime) AS "EventTime",
    BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
    BJE.CompanyCode AS "CompanyCode",
    BJE.AccountingDocumentType AS "JournalEntryType",
    BJE.PostingDate AS "PostingDate",
    BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
    AND JEI.CompanyCode = BJE.CompanyCode
    AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency

UNION ALL

-- 12. Journal Entry Reversal Processed
SELECT
    OriginalDoc.AccountingDocument AS "JournalEntryId",
    'Journal Entry Reversal Processed' AS "ActivityName",
    ReversalDoc.PostingDateTime AS "EventTime",
    ReversalDoc.CreatedByUser AS "CreatedByUser",
    OriginalDoc.CompanyCode AS "CompanyCode",
    OriginalDoc.AccountingDocumentType AS "JournalEntryType",
    OriginalDoc.PostingDate AS "PostingDate",
    OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
    ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
    AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
    AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL;

Étapes

Créer le Programme ABAP: Accédez à l'Éditeur ABAP en utilisant le code de transaction SE38. Saisissez un nom pour le nouveau programme, par exemple, Z_PM_JE_EXTRACT, et cliquez sur 'Créer'. Donnez un titre approprié, définissez le 'Type' sur 'Programme Exécutable' et enregistrez-le comme un objet local ou dans un package.
Définir l'Écran de Sélection: Dans le programme, définissez des paramètres et des options de sélection qui permettront aux utilisateurs de filtrer les données. Cela devrait inclure une plage de dates pour la date de création des écritures de journal (P_CPUDT_FR, P_CPUDT_TO), une option de sélection pour le Code Société (SO_BUKRS) et un chemin de fichier pour la sortie sur le serveur d'applications (P_FPATH).
Déclarer les Structures de Données: Définissez une structure de table interne qui correspond au format de journal d'événements requis. Cette structure contiendra la sortie finale. Déclarez également des tables internes et des zones de travail pour les tables SAP à partir desquelles vous effectuerez la sélection, telles que BKPF, ACDOCA, CDHDR, CDPOS, et diverses tables de workflow.
Implémenter la Logique de Sélection des Données: Écrivez la logique ABAP principale pour récupérer les données pour chacune des 12 activités requises. Créez des sous-routines (FORMs) séparées pour chaque activité afin de maintenir le code organisé. Par exemple, créez un FORM pour get_created_events, get_parked_events, get_workflow_events, etc.
Sélectionner les Événements 'Créé' et 'Comptabilisé': Lisez à partir de la table BKPF en fonction des critères de l'écran de sélection de l'utilisateur. Une entrée dans BKPF signifie la création. Un document avec le statut BSTAT = ' ' est considéré comme comptabilisé. Utilisez l'horodatage de création (CPUDT, CPUTM) comme heure de l'événement.
Sélectionner les Événements 'Mises en attente': Lisez à partir de la table VBKPF, qui stocke les en-têtes de documents mis en attente. L'horodatage de création dans cette table représente l'événement de mise en attente.
Sélectionner les Événements 'Workflow' (Soumis, Approuvé, Rejeté): Interrogez les tables de workflow telles que SWW_WI2OBJ (pour lier un objet d'écriture de journal à une instance de workflow) et SWWLOGHIST ou SWWIHEAD (pour obtenir les détails et le calendrier des étapes spécifiques). Vous devrez identifier les ID de tâches de workflow spécifiques pour la soumission, l'approbation et le rejet dans votre système.
Sélectionner les Événements 'Modification' et 'Correction': Interrogez les tables de documents de modification CDHDR (en-tête) et CDPOS (poste) pour OBJECTCLAS = 'BELEG'. Pour les 'Modifiés après comptabilisation', filtrez les modifications dont l'horodatage de modification est postérieur à la date de comptabilisation du document. Pour les 'Corrigés', filtrez les modifications apportées aux documents mis en attente ou rejetés.
Sélectionner les Événements 'Contrepassation' et 'Apurement': Identifiez les contrepassations en recherchant les documents où le champ STBLG (Numéro de Document Contrepassé) dans BKPF est renseigné. L'heure de l'événement de contrepassation est l'heure de création du document de contrepassation. Identifiez les événements d'apurement en sélectionnant la dernière date d'apurement (AUGDT) de la table ACDOCA pour les postes d'une écriture de journal donnée.
Combiner et Trier les Données: Au fur et à mesure que les données de chaque activité sont sélectionnées, ajoutez les résultats à la table interne principale finale. Une fois toutes les sélections terminées, triez la table principale par JournalEntryId et EventTime pour assurer l'ordre chronologique pour chaque cas.
Générer le Fichier de Sortie: Utilisez les instructions OPEN DATASET, LOOP AT... TRANSFER et CLOSE DATASET pour écrire le contenu de la table interne finale triée dans le chemin de fichier spécifié sur le serveur d'applications SAP. Le fichier doit être au format CSV avec une ligne d'en-tête.
Planifier l'Exécution: Pour les extractions régulières, utilisez le code de transaction SM36 pour créer une tâche en arrière-plan qui exécute le programme Z_PM_JE_EXTRACT selon un calendrier défini, par exemple, hebdomadaire ou mensuel. Ceci automatise le processus d'exportation des données.

Configuration

Période: L'écran de sélection doit inclure une plage de dates obligatoire pour la date de création des écritures de journal (CPUDT). Il est recommandé d'extraire les données par blocs gérables, par exemple de 3 à 6 mois à la fois, afin de garantir de bonnes performances.
Code Société (BUKRS): Il s'agit d'un filtre essentiel pour limiter l'extraction aux entités juridiques spécifiques pertinentes pour l'analyse par Process Mining. L'extraction de tous les codes société en une seule fois est déconseillée.
Type de Document (BLART): Vous pouvez ajouter ce filtre facultatif pour vous concentrer sur des types d'écritures de journal spécifiques, tels que 'SA' pour les écritures de compte général ou 'KR' pour les factures fournisseurs. Cela peut aider à réduire le volume de données et à augmenter la pertinence de l'ensemble de données.
Chemin du Fichier: Le programme nécessite un chemin de fichier logique sur le serveur d'applications SAP où le fichier de sortie sera écrit. Assurez-vous que le chemin est valide et que l'utilisateur du système SAP dispose des autorisations d'écriture nécessaires pour ce répertoire. Utilisez la transaction AL11 pour gérer et consulter les répertoires du serveur.
ID de Tâches de Workflow: La logique d'extraction des événements de workflow (Soumis, Approuvé, Rejeté) doit être configurée avec les ID de tâches spécifiques utilisés dans le workflow d'approbation des écritures de journal de votre organisation. Ceux-ci sont souvent personnalisés et doivent être identifiés par un consultant ou un développeur Workflow.
Prérequis: L'utilisateur ou le compte système exécutant le programme nécessite des autorisations de développeur pour créer et exécuter des programmes ABAP (S_DEVELOP) et un accès en lecture étendu aux tables financières (BKPF, ACDOCA), aux tables de journaux de modifications (CDHDR, CDPOS) et aux tables de workflow (SWW*).

a Exemple de requête abap

REPORT Z_PM_JE_EXTRACT.

*&---------------------------------------------------------------------*
*&--                  Data Structures for Event Log                  --*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
         journalentryid         TYPE string,
         activityname           TYPE string,
         eventtime              TYPE string,
         createdbyuser          TYPE uname,
         companycode            TYPE bukrs,
         journalentrytype       TYPE blart,
         postingdate            TYPE budat,
         amountinlocalcurrency  TYPE wrbtr,
       END OF ty_event_log.

*&---------------------------------------------------------------------*
*&--                    Selection Screen Definition                  --*
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
  PARAMETERS: p_erdat_fr TYPE dats OBLIGATORY DEFAULT sy-datum-30,
              p_erdat_to TYPE dats OBLIGATORY DEFAULT sy-datum.
  SELECT-OPTIONS: so_bukrs FOR bkpf-bukrs OBLIGATORY.
  PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/trans/tmp/je_event_log.csv'.
SELECTION-SCREEN END OF BLOCK b1.

*&---------------------------------------------------------------------*
*&--                        Internal Tables                          --*
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log.

*&---------------------------------------------------------------------*
*&--                      Main Processing Block                      --*
*&---------------------------------------------------------------------*
START-OF-SELECTION.

  PERFORM get_created_posted_events.
  PERFORM get_parked_events.
  PERFORM get_attachment_events.
  PERFORM get_workflow_events.
  PERFORM get_change_events.
  PERFORM get_cleared_events.
  PERFORM get_reversal_events.

  SORT gt_event_log BY journalentryid eventtime.
  PERFORM write_output_file.

*&---------------------------------------------------------------------*
*&--      Subroutines for Extracting Individual Activities           --*
*&---------------------------------------------------------------------*
FORM get_created_posted_events.
  DATA: lt_bkpf TYPE TABLE OF bkpf,
        ls_event_log TYPE ty_event_log,
        lv_timestamp TYPE string.

  SELECT * FROM bkpf INTO TABLE lt_bkpf
    WHERE bukrs IN so_bukrs
      AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.

  LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
    CLEAR ls_event_log.
    CONCATENATE <fs_bkpf>-bukrs <fs_bkpf>-belnr <fs_bkpf>-gjahr INTO ls_event_log-journalentryid.
    ls_event_log-companycode = <fs_bkpf>-bukrs.
    ls_event_log-journalentrytype = <fs_bkpf>-blart.
    ls_event_log-postingdate = <fs_bkpf>-budat.
    ls_event_log-createdbyuser = <fs_bkpf>-usnam.

    " Timestamp format YYYY-MM-DDTHH:MI:SS
    CONCATENATE <fs_bkpf>-cpudt(4) '-' <fs_bkpf>-cpudt+4(2) '-' <fs_bkpf>-cpudt+6(2) 'T' <fs_bkpf>-cputm(2) ':' <fs_bkpf>-cputm+2(2) ':' <fs_bkpf>-cputm+4(2) INTO lv_timestamp.
    ls_event_log-eventtime = lv_timestamp.

    " Activity: Journal Entry Created
    ls_event_log-activityname = 'Journal Entry Created'.
    SELECT SUM( hsl ) INTO ls_event_log-amountinlocalcurrency FROM acdoca WHERE belnr = <fs_bkpf>-belnr AND gjahr = <fs_bkpf>-gjahr AND bukrs = <fs_bkpf>-bukrs.
    APPEND ls_event_log TO gt_event_log.

    " Activity: Journal Entry Posted (if not parked)
    IF <fs_bkpf>-bstat = ' '.
      ls_event_log-activityname = 'Journal Entry Posted'.
      APPEND ls_event_log TO gt_event_log.

      " Activity: Manual Posting Identified (based on T-Code)
      CASE <fs_bkpf>-tcode.
        WHEN 'FB01' OR 'F-02' OR 'FB50' OR 'F-22' OR 'F-43'.
          ls_event_log-activityname = 'Manual Posting Identified'.
          APPEND ls_event_log TO gt_event_log.
      ENDCASE.
    ENDIF.
  ENDLOOP.
ENDFORM.

FORM get_parked_events.
  DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.

  SELECT * FROM vbkpf
    WHERE bukrs IN so_bukrs
    AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.

    CLEAR ls_event_log.
    CONCATENATE vbkpf-bukrs vbkpf-belnr vbkpf-gjahr INTO ls_event_log-journalentryid.
    CONCATENATE vbkpf-cpudt(4) '-' vbkpf-cpudt+4(2) '-' vbkpf-cpudt+6(2) 'T' vbkpf-cputm(2) ':' vbkpf-cputm+2(2) ':' vbkpf-cputm+4(2) INTO lv_timestamp.
    ls_event_log-activityname = 'Journal Entry Parked'.
    ls_event_log-eventtime = lv_timestamp.
    ls_event_log-createdbyuser = vbkpf-usnam.
    ls_event_log-companycode = vbkpf-bukrs.
    ls_event_log-journalentrytype = vbkpf-blart.
    ls_event_log-postingdate = vbkpf-budat.
    APPEND ls_event_log TO gt_event_log.
  ENDSELECT.
ENDFORM.

FORM get_attachment_events.
  DATA: lt_bdocs TYPE TABLE OF srgbtbrel, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.

  SELECT * FROM srgbtbrel INTO TABLE lt_bdocs
    WHERE typeid_a = 'BUS2081' " Object type for Accounting Document
      AND catid_a = 'BO'.

  LOOP AT lt_bdocs ASSIGNING FIELD-SYMBOL(<fs_bdocs>).
    CHECK <fs_bdocs>-instid_a(4) IN so_bukrs.
    DATA(lv_bukrs) = <fs_bdocs>-instid_a(4).
    DATA(lv_belnr) = <fs_bdocs>-instid_a+4(10).
    DATA(lv_gjahr) = <fs_bdocs>-instid_a+14(4).

    SELECT SINGLE cpudt, cputm, usnam, blart, budat FROM bkpf
      INTO (DATA(lv_cpudt), DATA(lv_cputm), DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
      WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
    IF sy-subrc = 0 AND lv_cpudt BETWEEN p_erdat_fr AND p_erdat_to.
      CLEAR ls_event_log.
      CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
      " Note: Using document creation time as a proxy for attachment time.
      CONCATENATE lv_cpudt(4) '-' lv_cpudt+4(2) '-' lv_cpudt+6(2) 'T' lv_cputm(2) ':' lv_cputm+2(2) ':' lv_cputm+4(2) INTO lv_timestamp.
      ls_event_log-activityname = 'Supporting Documentation Attached'.
      ls_event_log-eventtime = lv_timestamp.
      ls_event_log-createdbyuser = lv_usnam.
      ls_event_log-companycode = lv_bukrs.
      ls_event_log-journalentrytype = lv_blart.
      ls_event_log-postingdate = lv_budat.
      APPEND ls_event_log TO gt_event_log.
    ENDIF.
  ENDLOOP.
ENDFORM.

FORM get_workflow_events.
  " This is a simplified example. Real workflow logic can be complex.
  " You must identify your specific Task IDs for these events.
  DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
  DATA: BEGIN OF ls_wi, wi_id TYPE sww_wiid, cr_date TYPE sww_cd, cr_time TYPE sww_ct, task TYPE sww_task, instid TYPE swo_typeid, END OF ls_wi.

  SELECT h~wi_id h~cr_date h~cr_time h~wi_rh_task o~instid
    FROM swwwihead AS h
    JOIN sww_wi2obj AS o ON h~wi_id = o~wi_id
    INTO @ls_wi
    WHERE o~typeid = 'BUS2081' AND o~catid = 'BO'
    AND h~cr_date BETWEEN @p_erdat_fr AND @p_erdat_to.

    DATA(lv_bukrs) = ls_wi-instid(4).
    DATA(lv_belnr) = ls_wi-instid+4(10).
    DATA(lv_gjahr) = ls_wi-instid+14(4).

    IF lv_bukrs IN so_bukrs.
      CLEAR ls_event_log.
      CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
      CONCATENATE ls_wi-cr_date(4) '-' ls_wi-cr_date+4(2) '-' ls_wi-cr_date+6(2) 'T' ls_wi-cr_time(2) ':' ls_wi-cr_time+2(2) ':' ls_wi-cr_time+4(2) INTO lv_timestamp.
      ls_event_log-eventtime = lv_timestamp.
      ls_event_log-companycode = lv_bukrs.
      
      CASE ls_wi-task.
        WHEN '[Your Submit Task ID]'. " e.g., TS20000139
          ls_event_log-activityname = 'Journal Submitted For Review'.
          APPEND ls_event_log TO gt_event_log.
        WHEN '[Your Approve Task ID]'. " e.g., TS20000142
          ls_event_log-activityname = 'Journal Entry Approved'.
          APPEND ls_event_log TO gt_event_log.
        WHEN '[Your Reject Task ID]'. " e.g., TS20000141
          ls_event_log-activityname = 'Journal Entry Rejected'.
          APPEND ls_event_log TO gt_event_log.
      ENDCASE.
    ENDIF.
  ENDSELECT.
ENDFORM.

FORM get_change_events.
  DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.

  SELECT * FROM cdhdr INTO TABLE lt_cdhdr
    WHERE objectclas = 'BELEG'
      AND udate BETWEEN p_erdat_fr AND p_erdat_to.

  LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
    DATA(lv_bukrs) = <fs_cdhdr>-objectid(4).
    DATA(lv_belnr) = <fs_cdhdr>-objectid+4(10).
    DATA(lv_gjahr) = <fs_cdhdr>-objectid+14(4).

    IF lv_bukrs IN so_bukrs.
      SELECT SINGLE bstat, budat, blart FROM bkpf
        INTO (DATA(lv_bstat), DATA(lv_budat), DATA(lv_blart))
        WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
      IF sy-subrc = 0.
        CLEAR ls_event_log.
        CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
        CONCATENATE <fs_cdhdr>-udate(4) '-' <fs_cdhdr>-udate+4(2) '-' <fs_cdhdr>-udate+6(2) 'T' <fs_cdhdr>-utime(2) ':' <fs_cdhdr>-utime+2(2) ':' <fs_cdhdr>-utime+4(2) INTO lv_timestamp.
        ls_event_log-eventtime = lv_timestamp.
        ls_event_log-createdbyuser = <fs_cdhdr>-username.
        ls_event_log-companycode = lv_bukrs.
        ls_event_log-journalentrytype = lv_blart.
        ls_event_log-postingdate = lv_budat.

        IF lv_bstat = ' ' AND <fs_cdhdr>-udate > lv_budat.
          ls_event_log-activityname = 'Journal Entry Changed After Posting'.
          APPEND ls_event_log TO gt_event_log.
        ELSEIF lv_bstat <> ' '.
          ls_event_log-activityname = 'Journal Entry Corrected'.
          APPEND ls_event_log TO gt_event_log.
        ENDIF.
      ENDIF.
    ENDIF.
  ENDLOOP.
ENDFORM.

FORM get_cleared_events.
  DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
  DATA: BEGIN OF ls_clear, belnr TYPE belnr_d, gjahr TYPE gjahr, bukrs TYPE bukrs, augdt TYPE augdt, END OF ls_clear, lt_clear LIKE TABLE OF ls_clear.

  SELECT belnr, gjahr, bukrs, MAX( augdt ) AS augdt FROM acdoca
    INTO TABLE @lt_clear
    WHERE bukrs IN @so_bukrs
      AND augdt NE '00000000'
      AND augdt BETWEEN @p_erdat_fr AND @p_erdat_to
    GROUP BY belnr, gjahr, bukrs.

  LOOP AT lt_clear INTO ls_clear.
    SELECT SINGLE usnam, blart, budat FROM bkpf
      INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
      WHERE bukrs = ls_clear-bukrs AND belnr = ls_clear-belnr AND gjahr = ls_clear-gjahr.
    IF sy-subrc = 0.
      CLEAR ls_event_log.
      CONCATENATE ls_clear-bukrs ls_clear-belnr ls_clear-gjahr INTO ls_event_log-journalentryid.
      CONCATENATE ls_clear-augdt(4) '-' ls_clear-augdt+4(2) '-' ls_clear-augdt+6(2) 'T12:00:00' INTO lv_timestamp. " Clearing date has no time, use midday
      ls_event_log-activityname = 'Journal Entry Cleared'.
      ls_event_log-eventtime = lv_timestamp.
      ls_event_log-createdbyuser = lv_usnam.
      ls_event_log-companycode = ls_clear-bukrs.
      ls_event_log-journalentrytype = lv_blart.
      ls_event_log-postingdate = lv_budat.
      APPEND ls_event_log TO gt_event_log.
    ENDIF.
  ENDLOOP.
ENDFORM.

FORM get_reversal_events.
  DATA: lt_reversals TYPE TABLE OF bkpf, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.

  SELECT * FROM bkpf INTO TABLE lt_reversals
    WHERE bukrs IN so_bukrs
      AND cpudt BETWEEN p_erdat_fr AND p_erdat_to
      AND stblg IS NOT NULL.

  LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
    SELECT SINGLE usnam, blart, budat FROM bkpf
      INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
      WHERE bukrs = <fs_rev>-bukrs AND belnr = <fs_rev>-stblg AND gjahr = <fs_rev>-gjahr.
    IF sy-subrc = 0.
      CLEAR ls_event_log.
      CONCATENATE <fs_rev>-bukrs <fs_rev>-stblg <fs_rev>-gjahr INTO ls_event_log-journalentryid.
      CONCATENATE <fs_rev>-cpudt(4) '-' <fs_rev>-cpudt+4(2) '-' <fs_rev>-cpudt+6(2) 'T' <fs_rev>-cputm(2) ':' <fs_rev>-cputm+2(2) ':' <fs_rev>-cputm+4(2) INTO lv_timestamp.
      ls_event_log-activityname = 'Journal Entry Reversal Processed'.
      ls_event_log-eventtime = lv_timestamp.
      ls_event_log-createdbyuser = lv_usnam.
      ls_event_log-companycode = <fs_rev>-bukrs.
      ls_event_log-journalentrytype = lv_blart.
      ls_event_log-postingdate = lv_budat.
      APPEND ls_event_log TO gt_event_log.
    ENDIF.
  ENDLOOP.
ENDFORM.

FORM write_output_file.
  DATA: lv_line TYPE string.
  FIELD-SYMBOLS: <fs_event_log> TYPE ty_event_log.

  OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
  IF sy-subrc NE 0.
    MESSAGE 'Error opening file.' TYPE 'E'.
    RETURN.
  ENDIF.

  " Write Header
  lv_line = 'JournalEntryId,ActivityName,EventTime,CreatedByUser,CompanyCode,JournalEntryType,PostingDate,AmountInLocalCurrency'.
  TRANSFER lv_line TO p_fpath.

  LOOP AT gt_event_log ASSIGNING <fs_event_log>.
    CONCATENATE <fs_event_log>-journalentryid <fs_event_log>-activityname <fs_event_log>-eventtime <fs_event_log>-createdbyuser <fs_event_log>-companycode <fs_event_log>-journalentrytype <fs_event_log>-postingdate <fs_event_log>-amountinlocalcurrency
      INTO lv_line SEPARATED BY ','.
    TRANSFER lv_line TO p_fpath.
  ENDLOOP.

  CLOSE DATASET p_fpath.
  WRITE: / 'File successfully written to', p_fpath.
ENDFORM.

Votre modèle de données Record to Report - Écriture de journal

Votre modèle de données Record to Report - Écriture de journal

Record to Report - Attributs d'écritures de journal

Record to Report - Activités d'écritures de journal

Guides d'extraction

Extraction de vues CDS SAP S/4HANA pour les écritures de journal

Étapes

Configuration

a Exemple de requête sql

Requête SQL Directe sur la Table de Journal Universel ACDOCA

Étapes

Configuration

a Exemple de requête sql

Programme ABAP Personnalisé pour l'Exportation de Fichiers d'Écritures de Journal

Étapes

Configuration

a Exemple de requête abap

Prêt(e) à démarrer ?

Rationaliser les écritures de journal Record to Report pour une efficacité maximale

Votre modèle de données Record to Report - Écriture de journal

Votre modèle de données Record to Report - Écriture de journal

Record to Report - Attributs d'écritures de journal

Record to Report - Activités d'écritures de journal

Guides d'extraction

Extraction de vues CDS SAP S/4HANA pour les écritures de journal

Étapes

Configuration

a Exemple de requête sql

Requête SQL Directe sur la Table de Journal Universel ACDOCA

Étapes

Configuration

a Exemple de requête sql

Programme ABAP Personnalisé pour l'Exportation de Fichiers d'Écritures de Journal

Étapes

Configuration

a Exemple de requête abap

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Rationaliser les écritures de journal Record to Report pour une efficacité maximale