Votre modèle de données Record to Report - Journal Entry
Votre modèle de données Record to Report - Journal Entry
- Attributs recommandés à collecter
- Activités clés à suivre
- Recommandations pratiques pour l’extraction
Record to Report - Attributs des écritures comptables
| Nom | Description | ||
|---|---|---|---|
| Activité ActivityName | Nom de l’activité métier exécutée à un moment précis du processus d’écriture comptable. | ||
| Description L’activité représente une étape ou un événement précis du cycle de vie d’une écriture comptable, comme « Journal Entry Created », « Journal Submitted For Review » ou « Journal Entry Posted ». Ces activités sont généralement dérivées des journaux de modification, 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 parcours du processus, d’identifier les chemins fréquents et de repérer les écarts par rapport à la procédure standard. Elle est indispensable au calcul d’indicateurs tels 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, ce qui permet de visualiser les cartes de processus et d’analyser les schémas du flux de travail. Où les obtenir Dérivé de plusieurs sources, notamment des champs de statut des tables d’en-tête et de postes, par exemple BKPF-BSTAT, des journaux des documents de modification (CDHDR/CDPOS) et des journaux de flux de travail. Exemples Écriture comptable crééeÉcriture comptable mise en attenteÉcriture comptable soumise pour vérificationÉcriture comptable approuvéeÉcriture comptable comptabilisée | |||
| Heure de l’événement EventTime | Horodatage indiquant le moment où une activité précise a eu lieu pour l’écriture comptable. | ||
| Description L’heure de l’événement correspond à la date et à l’heure précises auxquelles une activité métier a été exécutée et enregistrée dans le système. Chaque activité d’un dossier possède son propre horodatage, ce qui crée une séquence chronologique d’événements. Cet attribut est essentiel pour toutes les analyses de processus fondées sur le temps. Il sert à calculer les temps de cycle, les durées entre les activités et les temps d’attente, ainsi qu’à comprendre la répartition temporelle du travail. Des horodatages exacts sont indispensables pour construire un modèle de processus fiable et calculer des indicateurs clés tels que le temps de cycle d’approbation. Pourquoi c’est important Il fournit l’ordre chronologique des événements, indispensable au calcul de tous les indicateurs fondés sur la durée et à la compréhension de la chronologie du processus. Où les obtenir Provient des journaux des documents de modification (CDHDR-UDATE, CDHDR-UTIME), des journaux de flux de travail ou des horodatages de création ou de saisie de tables telles que BKPF (CPUDT, CPUTM). Exemples 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| Identifiant de l’écriture comptable JournalEntryId | Identifiant unique d’une écriture comptable, utilisé comme identifiant principal du dossier dans le processus. | ||
| Description L’identifiant de l’écriture comptable est un numéro unique attribué à chaque document comptable lors de sa création dans SAP S/4HANA. Cet identifiant est indispensable pour suivre l’ensemble du cycle de vie d’une écriture comptable, depuis sa création initiale ou sa mise en attente, en passant par les flux de travail d’approbation, jusqu’à sa comptabilisation finale et à son éventuelle extourne ou compensation. Dans une analyse de Process Mining, cet identifiant sert à relier toutes les activités associées au sein d’un même cas. En regroupant les événements sous un identifiant d’écriture comptable commun, les analystes peuvent reconstituer le flux de bout en bout, mesurer les temps de cycle et repérer les variations ou les goulots d’étranglement propres à chaque transaction financière. Il s’agit de l’attribut fondamental pour construire l’ensemble de la vue du processus. Pourquoi c’est important Cet identifiant relie toutes les étapes associées du processus et permet d’analyser le parcours de bout en bout de chaque écriture comptable. Où les obtenir Il s’agit d’une clé composite, généralement constituée par la concaténation du code société (BKPF-BUKRS), du numéro de document (BKPF-BELNR) et de l’exercice fiscal (BKPF-GJAHR). Exemples 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Code société CompanyCode | Identifiant unique de la société ou de l’entité juridique pour laquelle l’écriture comptable est enregistrée. | ||
| Description Le code société est une unité organisationnelle fondamentale de SAP Financials. Il représente une entité juridique indépendante pour laquelle des états financiers sont établis. Chaque écriture comptable est affectée à un code société donné. Cet attribut est essentiel pour segmenter et comparer les performances du processus entre les différentes composantes de l’organisation. Les analystes peuvent l’utiliser pour filtrer la vue du processus sur une entité juridique précise, comparer les taux de rejet entre plusieurs codes société ou identifier des variations propres à certaines régions. Pourquoi c’est important Permet de filtrer et de comparer le processus d’écriture comptable entre différentes entités juridiques ou unités opérationnelles de l’organisation. Où les obtenir Table SAP S/4HANA BKPF, champ BUKRS (code société). Exemples 10001710US01 | |||
| Date de comptabilisation PostingDate | Date à laquelle l’écriture comptable est enregistrée dans le grand livre, ce qui détermine la période financière concernée. | ||
| Description La date de comptabilisation détermine la période fiscale dans laquelle la transaction apparaît dans les états financiers. Il s’agit d’une date essentielle en comptabilité, qui peut différer de la date de création ou de saisie du document dans le système. Dans le Process Mining, la date de comptabilisation sert à réaliser des analyses par cohortes temporelles, par exemple pour comparer les processus de clôture mensuelle ou analyser les tendances de performance sur différentes périodes financières. Elle permet également de mesurer les délais entre la création de l’écriture et sa comptabilisation effective. Pourquoi c’est important Essentielle pour replacer les données dans leur contexte financier, elle permet d’analyser les performances du processus sur des périodes comptables précises, comme les clôtures mensuelles ou annuelles. Où les obtenir Table SAP S/4HANA BKPF, champ BUDAT (date de comptabilisation du document). Exemples 2023-10-312023-11-012024-02-29 | |||
| Montant en devise locale AmountInLocalCurrency | Valeur totale de l’écriture comptable exprimée dans la devise locale du code société. | ||
| Description Cet attribut représente le montant financier de l’écriture comptable. Il correspond généralement à la somme des valeurs absolues de tous les postes au débit ou au crédit du document, convertie dans la devise locale du code société. L’analyse par montant permet de segmenter le processus selon son impact financier. Par exemple, les écritures de montant élevé peuvent suivre un processus d’approbation plus strict que les écritures de faible montant. Elle aide à prioriser les initiatives d’amélioration sur les transactions qui présentent le risque financier le plus élevé. Pourquoi c’est important Fournit la valeur financière de l’écriture et permet d’analyser l’évolution du comportement du processus en fonction du montant concerné. Où les obtenir Calculé en additionnant les montants de la table des postes BSEG, champ DMBTR, pour une écriture donnée, BELNR, puis en convertissant le résultat en valeur positive. Exemples 1500.75125000.0050.20 | |||
| Type d’écriture comptable JournalEntryType | Classe l’écriture comptable selon son objectif métier, par exemple une comptabilisation d’immobilisation, une facture fournisseur ou une écriture de grand livre. | ||
| Description Le type d’écriture comptable, appelé type de document dans la terminologie SAP, est une clé qui catégorise les documents comptables. Il détermine notamment 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 est essentielle pour comprendre les comportements propres à chaque contexte. Par exemple, le processus d’approbation d’une simple charge à payer de type SA peut être beaucoup plus simple que celui d’une acquisition d’immobilisation complexe de type AA. Cette dimension est essentielle pour le Dashboard « Conformité par type d’écriture ». Pourquoi c’est important Catégorise les écritures selon leur contexte métier et permet d’analyser les variations du processus ainsi que les performances associées aux différents types de transactions financières. Où les obtenir Table SAP S/4HANA BKPF, champ BLART (type de document). Exemples SAKRAA | |||
| Utilisateur ayant créé l’écriture CreatedByUser | Identifiant de l’utilisateur qui a créé l’écriture comptable. | ||
| Description Cet attribut contient l’identifiant unique de l’utilisateur qui a lancé le processus d’écriture comptable en créant le document initial. Il peut s’agir d’un comptable, d’un utilisateur métier ou d’un identifiant système pour les écritures automatisées. L’analyse du processus par créateur permet d’identifier les tendances associées à certains utilisateurs ou équipes. Elle peut révéler des besoins de formation lorsque certains utilisateurs présentent des taux de rejet plus élevés, ou mettre en évidence les personnes les plus performantes. Cet attribut est essentiel pour le Dashboard « Activité et productivité des utilisateurs ». Pourquoi c’est important Associe les activités du processus à des utilisateurs précis, ce qui permet d’analyser les performances, de répartir la charge de travail et d’identifier les besoins de formation. Où les obtenir Table SAP S/4HANA BKPF, champ USNAM (nom d’utilisateur). Exemples ABROWNCJONESBATCH_USER | |||
| Code de transaction TransactionCode | Code de transaction SAP utilisé pour créer ou modifier l’écriture comptable. | ||
| Description Le code de transaction, ou T-Code, est un raccourci qui identifie une fonction ou un programme précis dans SAP. Pour les écritures comptables, différents T-Codes peuvent indiquer la manière dont l’écriture a été créée, par exemple FB01 pour une comptabilisation manuelle dans le grand livre, FV50 pour une mise en attente ou un code automatisé pour les écritures générées par le système. Cet attribut indique clairement si une activité a été réalisée manuellement par un utilisateur ou automatiquement par le système. Il est essentiel pour calculer le KPI du taux de comptabilisation manuelle et identifier les possibilités d’automatisation. Pourquoi c’est important Indique comment l’écriture a été traitée, par exemple manuellement ou automatiquement, ce qui est essentiel pour analyser l’automatisation et comprendre les variations du processus. Où les 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 actualisation des données de cet enregistrement 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 depuis le système source. Il indique clairement le degré d’actualité des données analysées. Connaître l’heure de la dernière mise à jour est important pour évaluer l’actualité de l’analyse du processus. Cela aide les utilisateurs à interpréter correctement les Dashboards et les KPI, en sachant s’ils consultent des données quasi en temps réel ou un instantané d’une période antérieure. Pourquoi c’est important Indique l’actualité des données et permet aux utilisateurs de savoir dans quelle mesure l’analyse du processus reflète la situation actuelle. Où les obtenir Il s’agit d’un attribut de métadonnées, généralement généré et horodaté pour chaque enregistrement lors du pipeline d’ingestion des données. Exemples 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Durée du cycle d’approbation ApprovalCycleTime | Temps écoulé entre la soumission d’une écriture comptable pour approbation et son approbation ou son rejet. | ||
| Description Cette métrique calculée porte spécifiquement sur la durée de l’étape d’approbation. Elle mesure le temps écoulé entre l’activité « Journal Submitted For Review » et l’activité suivante « Journal Entry Approved » ou « Journal Entry Rejected ». Ce KPI est essentiel pour identifier les goulots d’étranglement au sein du flux de travail d’approbation. Des temps de cycle d’approbation élevés peuvent retarder considérablement l’ensemble du processus. L’analyse de cette métrique par approbateur, code société ou type d’écriture comptable peut révéler des axes d’amélioration précis. Pourquoi c’est important Isole la durée de l’étape d’approbation afin de localiser et de traiter les goulots d’étranglement lors de l’examen et de l’approbation. Où les obtenir Calculé en mesurant la différence entre l’événement « Écriture comptable soumise pour examen » et l’événement « Écriture comptable approuvée » ou « Écriture comptable rejetée ». Exemples 1 jour et 2 heures4 heures et 25 minutes5 jours et 0 heure | |||
| Exercice fiscal FiscalYear | Exercice fiscal auquel l’écriture comptable est rattachée. | ||
| Description L’exercice fiscal fait partie de la clé unique d’une écriture comptable, avec le code société et le numéro de document. Il représente l’année financière au cours de laquelle le document est pertinent. Dans le cadre de l’analyse, l’exercice fiscal sert à étudier les tendances à long terme et à garantir l’unicité de l’identifiant du cas. La comparaison des indicateurs du processus entre différents exercices fiscaux peut révéler des améliorations ou des dégradations des performances au fil du temps. Pourquoi c’est important Constitue un élément essentiel pour identifier les documents de manière unique et permet d’analyser les performances du processus d’une année sur l’autre. Où les obtenir Table SAP S/4HANA BKPF, champ GJAHR (exercice fiscal). Exemples 202320242022 | |||
| Heure de fin EndTime | Horodatage indiquant le moment où l’activité a été terminé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, ce qui correspond à un événement instantané. En revanche, pour les activités dont la durée est mesurable, comme l’examen actif d’un document par un utilisateur, cet attribut permet d’enregistrer cette durée. Une heure de fin distincte permet de calculer plus précisément le temps de traitement de l’activité et le temps d’attente. Elle aide à distinguer le temps consacré activement à une tâche du temps pendant lequel celle-ci est restée en attente dans une file. Pourquoi c’est important Permet de calculer précisément le temps de traitement des activités et de distinguer le temps de travail actif du temps d’attente. Où les obtenir Généralement identique à StartTime pour les événements atomiques. Pour les activités qui s’étendent dans le temps, il peut provenir des journaux de flux de travail ou être calculé à partir des événements suivants. Exemples 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Indicateur de comptabilisation manuelle IsManualPosting | Indicateur booléen précisant si l’écriture comptable a été comptabilisée manuellement par un utilisateur. | ||
| Description Cet attribut identifie les écritures comptables enregistrées à la suite d’une intervention manuelle, par opposition à celles comptabilisées automatiquement 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. Cet indicateur sert à calculer le KPI du taux de comptabilisation manuelle et aide les organisations à suivre leurs progrès dans l’automatisation du processus Record to Report. En filtrant les écritures comptabilisées manuellement, les analystes peuvent identifier les situations qui nécessitent encore une intervention humaine et évaluer leur potentiel d’automatisation. Pourquoi c’est important Distingue les comptabilisations effectuées par un utilisateur de celles pilotées par le système, ce qui est essentiel pour mesurer le niveau d’automatisation et identifier de nouvelles possibilités. Où les obtenir Il s’agit d’un attribut calculé à partir de TransactionCode. Une liste prédéfinie de codes de transaction manuels, par exemple « FB01 » et « F-02 », permet de définir l’indicateur sur « true ». Exemples truefalse | |||
| Indicateur de reprise IsRework | Indicateur booléen précisant si l’écriture comptable a fait l’objet d’une reprise, par exemple après un rejet. | ||
| Description Cet attribut calculé signale les écritures comptables qui s’écartent du parcours nominal du processus. Il prend généralement la valeur true lorsqu’une activité telle que « Écriture comptable rejetée » ou « Écriture comptable corrigée » intervient dans le cas. Cet indicateur simplifie l’analyse de l’efficacité du processus. Il permet de calculer rapidement le KPI du taux de reprise et de comparer directement les délais de traitement et les coûts des cas avec ou sans reprise. Identifier les facteurs à l’origine des reprises constitue un objectif majeur de nombreuses initiatives d’amélioration des processus. Pourquoi c’est important Signale les cas qui ont nécessité une correction ou des boucles supplémentaires, afin de quantifier facilement les inefficacités du processus et d’en analyser les causes profondes. Où les obtenir Il s’agit d’un attribut calculé à partir de la séquence des activités d’un cas. Il prend la valeur « true » lorsqu’une activité telle que « Écriture comptable rejetée » est présente. Exemples truefalse | |||
| Motif d’annulation ReversalReason | Code indiquant la raison pour laquelle une écriture comptable comptabilisée a été annulée. | ||
| Description Lorsqu’une écriture comptable comptabilisée est incorrecte, elle ne peut pas être supprimée et doit être annulée au moyen d’un nouveau document. Le code du motif d’annulation explique la raison de cette opération, par exemple une date de comptabilisation ou un montant incorrect. L’analyse des motifs d’annulation aide à identifier les causes profondes des erreurs dans le processus Record to Report. La fréquence élevée d’un motif particulier peut révéler des problèmes systémiques, comme une formation insuffisante ou des défaillances des contrôles, auxquels il faut remédier pour améliorer la qualité dès la première exécution. Pourquoi c’est important Aide à diagnostiquer la cause profonde des erreurs à l’origine des annulations et fournit les analyses nécessaires pour réduire les reprises et améliorer la qualité du processus. Où les obtenir Table SAP S/4HANA BKPF, champ STGRD (motif d’annulation). Exemples 010205 | |||
| Statut du document DocumentStatus | Statut actuel de traitement de l’écriture comptable, par exemple mise en attente, comptabilisée ou lettrée. | ||
| Description Le statut du document indique l’état de l’écriture comptable au cours de son cycle de vie. Par exemple, un document mis en attente est enregistré, mais pas encore comptabilisé dans le grand livre, tandis qu’un document comptabilisé est finalisé. L’analyse du statut aide à comprendre le déroulement du travail et à identifier les goulots d’étranglement. Un volume important de documents restant longtemps à l’état « mis en attente » ou « en attente d’approbation » peut révéler des inefficacités dans le processus. Le statut constitue également une source importante pour dériver les activités du processus. Pourquoi c’est important Donne une vue instantanée de la position de l’écriture comptable dans son cycle de vie et aide à identifier les files d’attente ainsi que les goulots d’étranglement. Où les obtenir Table SAP S/4HANA BKPF, champ BSTAT (statut du document). Exemples VAB | |||
| Système source SourceSystem | Identifie le système source depuis lequel les données des écritures comptables ont été extraites. | ||
| Description Cet attribut indique le système de référence dans lequel les données de l’écriture comptable ont été créées. Pour les entreprises qui utilisent plusieurs instances ERP ou un ensemble de systèmes historiques et modernes, il permet de distinguer les sources de données. Dans le cadre de l’analyse, il peut servir à comparer les performances du processus entre différents systèmes ou à filtrer les données provenant d’une source donnée. Il joue un rôle important dans la gouvernance des données et permet de préserver le contexte nécessaire à leur bonne compréhension. Pourquoi c’est important Fournit le contexte sur l’origine des données, un élément essentiel dans les environnements multi-systèmes pour analyser et comparer correctement les processus. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction des données, qui identifie l’instance SAP S/4HANA concernée, par exemple le SID ou le nom du système logique. Exemples S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Utilisateur approbateur ApproverUser | Identifiant de l’utilisateur qui a approuvé ou rejeté l’écriture comptable. | ||
| Description Cet attribut identifie l’utilisateur chargé d’examiner une écriture comptable soumise et de prendre une décision. Dans un flux de travail d’approbation à plusieurs niveaux, plusieurs approbateurs peuvent intervenir pour une même écriture comptable. Ces informations sont indispensables pour analyser précisément le processus d’approbation. Elles permettent de mesurer la charge de travail des différents approbateurs, de calculer leurs temps d’approbation individuels et d’identifier les goulots d’étranglement dans la chaîne d’approbation. Elles alimentent directement le Dashboard « User Activity and Throughput ». Pourquoi c’est important Identifie la personne responsable de l’approbation et permet d’analyser la charge de travail, les performances et les goulots d’étranglement liés aux approbations. Où les obtenir Provient des journaux de flux de travail, par exemple SWW_WI2OBJ et SWWLOG, ou des tables de documents de modification (CDHDR/CDPOS), en identifiant l’utilisateur qui a exécuté l’étape d’approbation. Exemples DMILLERFWHITEKCHEN | |||
Record to Report - Activités liées aux écritures comptables
| Activité | Description | ||
|---|---|---|---|
| Écriture comptable approuvée | L’écriture comptable reçoit l’approbation finale d’un responsable habilité, qui en confirme la validité et l’exactitude. Cette activité constitue le dernier contrôle avant la comptabilisation du document dans le grand livre. | ||
| Pourquoi c’est important Il s’agit d’une étape importante qui clôt le cycle d’approbation. Le délai nécessaire pour l’atteindre représente une part majeure de la durée globale du processus et constitue un indicateur clé de l’efficacité des approbateurs. Où les obtenir Cet événement est déduit d’un journal de flux de travail indiquant l’étape d’approbation finale ou d’un changement de statut du document. L’identifiant utilisateur de l’approbateur et l’horodatage peuvent provenir des données du flux de travail ou des journaux de modification. Collecte Identifiez l’horodatage de l’étape d’approbation finale dans les journaux de flux de travail ou le passage du statut à « Approved » dans les documents de modification. Type d’événement inferred | |||
| Écriture comptable comptabilisée | L’écriture comptable est officiellement enregistrée dans le grand livre et a un impact sur les états financiers de l’entreprise. C’est à ce moment que le document devient une pièce financière permanente. | ||
| Pourquoi c’est important Il s’agit du principal jalon de réussite, qui marque la fin du cycle de traitement central. L’analyse du débit des écritures comptabilisées et du délai nécessaire pour atteindre cette étape constitue un indicateur fondamental du process mining. Où les obtenir Il s’agit d’un événement explicite, marqué par la date de comptabilisation (BUDAT) dans la table BKPF. Un document comptabilisé possède un statut de document vide (BSTAT), ce qui le distingue des documents mis en attente (« V ») ou bloqués (« D »). Collecte Utilisez la date de comptabilisation (BKPF-BUDAT) et la date de saisie (BKPF-CPUDT) pour horodater l’événement. Une valeur BKPF-BSTAT vide indique un document comptabilisé. Type d’événement explicit | |||
| Écriture comptable créée | Cette activité correspond à la création initiale d’un document d’écriture comptable dans le système. L’enregistrement est créé dans la table d’en-tête BKPF, mais n’est pas encore comptabilisé dans le grand livre. Il s’agit du point de départ du cycle de vie de l’écriture comptable. | ||
| Pourquoi c’est important Il s’agit de l’événement de début principal du processus. L’analyse du délai entre cet événement et la comptabilisation est essentielle pour mesurer le temps de cycle global et identifier les retards initiaux de saisie des données. Où les obtenir Cet événement peut être capturé explicitement dans la table SAP BKPF à partir des champs de date de création (CPUDT) et d’heure de création (CPUTM), pour un numéro de document donné (BELNR). Collecte Utilisez BKPF-CPUDT et BKPF-CPUTM pour l’horodatage de l’événement. Type d’événement explicit | |||
| Écriture comptable lettrée | Un poste ouvert d’une écriture comptable est compensé par une autre comptabilisation, par exemple lorsqu’un paiement solde une facture. Cette activité marque le rapprochement de postes précis et leur clôture effective. | ||
| Pourquoi c’est important Cette activité représente l’étape finale de rapprochement pour de nombreuses écritures comptables, notamment celles qui concernent des comptes d’attente ou des comptes gérés par postes ouverts. L’analyse du délai entre la comptabilisation et le lettrage permet de mesurer l’efficacité du rapprochement. Où les obtenir Cet événement est déduit de la table des postes (BSEG ou vue ACDOCA). Lorsqu’un poste est lettré, les champs Date de lettrage (AUGDT) et Document de lettrage (AUGBL) sont renseignés pour ce poste. Collecte Utilisez la date de lettrage (BSEG-AUGDT) du poste comme horodatage de l’événement. Type d’événement inferred | |||
| Écriture comptable soumise pour vérification | Le créateur de l’écriture comptable soumet officiellement le document au flux de travail de contrôle et d’approbation. Cette activité marque le passage de la saisie des données au processus de contrôle formel et lance le cycle d’approbation. | ||
| Pourquoi c’est important Cette activité marque le début du temps de cycle d’approbation. Mesurer la durée entre ce point et l’approbation ou le rejet final permet d’isoler les goulots d’étranglement propres aux étapes de contrôle et d’approbation. Où les obtenir Cette activité est souvent capturée dans les journaux des flux de travail, notamment les tables SWW_WIHEAD et SWWLOG, reliées à l’objet métier. Elle peut également être déduite d’un changement de statut dans un champ personnalisé de l’en-tête du document (BKPF). Collecte Horodatage de la création d’un élément de flux de travail ou du passage d’un champ de statut à « Submitted » ou « In Review ». Type d’événement inferred | |||
| Processus d’extourne d’écriture comptable traité | Une écriture comptable précédemment comptabilisée est extournée par la création d’un nouveau document contenant les écritures inverses. Cette opération corrige les erreurs des documents comptabilisés et constitue une transaction explicite et auditable. | ||
| Pourquoi c’est important Les extournes indiquent qu’une erreur a été commise dans un document comptabilisé. Un taux élevé d’extournes révèle des problèmes sous-jacents dans le processus d’approbation ou dans la qualité de la saisie. Leur suivi contribue à améliorer l’exactitude dès la première saisie. Où les obtenir L’extourne constitue un événement explicite. L’en-tête du nouveau document d’extourne (BKPF) contient une référence au document d’origine dans le champ Numéro du document extourné (STBLG). La date de comptabilisation du nouveau document correspond à l’heure de l’événement. Collecte Identifiez les documents pour lesquels BKPF-STBLG est renseigné. L’horodatage de l’événement correspond à la date de comptabilisation du document d’extourne. Type d’événement explicit | |||
| Comptabilisation manuelle identifiée | L’écriture comptable a été comptabilisée à l’aide d’un code de transaction manuel, plutôt que par une interface automatisée ou un traitement 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 essentielle pour les initiatives d’automatisation. Un taux élevé de comptabilisations manuelles indique des possibilités d’amélioration, notamment par l’intégration de sous-systèmes ou l’utilisation de programmes de comptabilisation automatisés. Où les obtenir Cette classification est calculée en analysant le champ du code de transaction (TCODE) dans la table d’en-tête des documents (BKPF). Une liste de T-Codes manuels connus, comme FB01, F-02 et FB50, est utilisée pour classer l’écriture. Collecte Classez l’événement selon BKPF-TCODE, en le comparant à une liste prédéfinie de codes de transaction manuels au moment de la comptabilisation. Type d’événement calculated | |||
| Écriture comptable corrigée | L’utilisateur modifie une écriture comptable après son rejet ou son renvoi pour correction. Cette activité représente le travail de reprise nécessaire pour traiter les problèmes identifiés lors de la vérification avant une nouvelle soumission. | ||
| Pourquoi c’est important Cette activité quantifie les boucles de reprise. L’analyse de la fréquence et de la durée des corrections permet de repérer les sources d’inefficacité et de mettre en évidence les possibilités d’amélioration de la formation et de la clarté du processus. Où les obtenir Cet événement peut être déduit en suivant la date de dernière modification (« Last Changed On », AEDAT) dans la table BKPF pour un document qui se trouvait précédemment à l’état « Rejected ». Les documents de modification fournissent des informations plus précises sur les changements effectués. Collecte Utilisez l’horodatage des en-têtes des documents de modification (CDHDR-UDATE) pour les changements effectués après un événement de rejet. Type d’événement inferred | |||
| Écriture comptable mise en attente | Un utilisateur enregistre une écriture comptable incomplète sans la comptabiliser, afin de la compléter ou de la vérifier ultérieurement. Cette action explicite crée un enregistrement d’en-tête avec le statut « mise en attente », qui conserve le document dans un état non comptabilisé. | ||
| Pourquoi c’est important La mise en attente constitue une étape courante avant la soumission. Le suivi de la durée de cet état permet d’identifier les retards dans la finalisation et la préparation des données avant le début du processus formel de vérification et d’approbation. Où les obtenir Dans la table BKPF, un document mis en attente est identifié par la valeur « V » du champ de statut du document (BSTAT). L’horodatage de l’événement correspond à la date de création (CPUDT). Collecte Filtrez les documents pour lesquels BKPF-BSTAT = « V » au moment de la création. Type d’événement explicit | |||
| Écriture comptable modifiée après comptabilisation | Un utilisateur modifie un nombre limité de champs d’une écriture comptable après sa comptabilisation dans le grand livre. Même si la plupart des données financières sont immuables après comptabilisation, certains champs, comme le texte ou les affectations, peuvent être modifiés. | ||
| Pourquoi c’est important Cette activité constitue un indicateur de conformité important. Les modifications effectuées après la comptabilisation peuvent révéler des tentatives d’altération des registres. Elles doivent donc être surveillées attentivement afin de prévenir la fraude et de garantir l’intégrité des données. Où les obtenir Cet événement peut être déduit de manière fiable à partir des tables des documents de modification (CDHDR et CDPOS). Une entrée CDHDR associée au numéro de document et présentant une date de modification postérieure à la date de comptabilisation indique une modification après comptabilisation. Collecte Recherchez dans CDHDR les enregistrements dont l’horodatage de modification (UDATE/UTIME) est postérieur à la date de comptabilisation du document (BKPF-BUDAT). Type d’événement inferred | |||
| Écriture comptable rejetée | Un vérificateur ou un approbateur refuse l’écriture comptable, ce qui empêche sa comptabilisation. Le document est généralement renvoyé à son créateur pour correction, ce qui déclenche une boucle de reprise. | ||
| Pourquoi c’est important Le suivi des rejets est essentiel pour comprendre la qualité du processus et identifier les erreurs fréquentes. Un taux de rejet élevé révèle des problèmes d’exactitude des données, de compréhension des politiques ou de documentation justificative insuffisante. Où les obtenir Cet événement est déduit d’un changement de statut dans un journal de flux de travail ou dans un champ de statut personnalisé du document d’écriture comptable. Les journaux des documents de modification (CDHDR/CDPOS) associés au champ de statut concerné peuvent fournir l’horodatage. Collecte Identifiez le changement du champ de statut à « Rejected » à l’aide des documents de modification (CDHDR/CDPOS) ou des journaux de flux de travail. Type d’événement inferred | |||
| Pièces justificatives jointes | Un utilisateur joint une ou plusieurs pièces justificatives, comme des factures ou des feuilles de calcul, à l’écriture comptable. Cette étape vise généralement à fournir des éléments de preuve et du contexte pour la transaction financière lors de la vérification et de l’audit. | ||
| Pourquoi c’est important Il est essentiel de joindre les pièces justificatives avant la vérification pour garantir la conformité et l’efficacité des approbations. Cette activité permet de mesurer le respect des politiques documentaires et son impact sur les délais d’approbation. Où les obtenir Cet événement est généralement déduit en vérifiant l’horodatage de création des pièces jointes associées via Generic Object Services (GOS). La table SRGBTBREL relie l’objet métier, par exemple le document BKPF, à la pièce jointe. Collecte Interrogez les tables des pièces jointes GOS, par exemple SRGBTBREL, pour rechercher les liens vers l’objet BKPF et utilisez l’horodatage de création de la pièce jointe. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Prérequis et accès : vérifiez que vous disposez d’un utilisateur possédant 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 et I_JournalEntryItem, ainsi qu’aux tables CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ et SWWLOGHIST. L’accès est généralement accordé au moyen d’un client de base de données tel que SAP HANA Studio ou DBeaver, ou à l’aide des SAP ABAP Development Tools (ADT) pour Eclipse.
- Identifiez les configurations propres au système : avant d’exécuter la requête, identifiez les codes de tâche utilisés dans votre Workflow d’approbation des écritures. Consultez l’administrateur de votre SAP Workflow pour trouver les identifiants de tâche, par exemple TS12345678, correspondant aux événements de soumission, de rejet et d’approbation. Ces identifiants sont nécessaires pour renseigner les placeholders de la requête finale.
- Préparez la requête SQL : copiez la requête SQL complète fournie dans la section
querydans le client SQL ou l’outil de développement de votre choix. - Définissez les paramètres de la requête : repérez les placeholders dans la requête et remplacez-les par vos valeurs. Vous devez notamment renseigner les paramètres
[YourCompanyCode],[StartDate]et[EndDate]. Remplacez également les identifiants de tâche Workflow ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) par les valeurs identifiées à l’étape précédente. - Exécutez la requête d’extraction : lancez la requête SQL modifiée sur la base de données SAP S/4HANA. Selon la période et le volume de données, son exécution peut prendre un certain temps. Il est recommandé de l’exécuter en dehors des heures de pointe.
- Examinez les premiers résultats : une fois la requête terminée, vérifiez les premières lignes du résultat afin de vous assurer que toutes les colonnes, notamment JournalEntryId, ActivityName et EventTime, sont renseignées comme prévu. Le résultat doit contenir une ligne pour chaque événement métier distinct du cycle de vie de l’écriture.
- Exportez les données au format CSV : exportez l’intégralité du résultat depuis votre outil SQL dans un seul fichier CSV. Vérifiez que le fichier utilise l’encodage UTF-8 afin d’éviter les problèmes liés aux caractères spéciaux.
- Préparez le chargement : avant d’importer le fichier dans un outil de Process Mining, vérifiez que le fichier CSV contient les en-têtes requis. Les données sont déjà structurées sous forme d’Event Log, aucune transformation ni aucun pivot supplémentaire ne devrait donc être nécessaire.
Configuration
- Vues Core Data Services (CDS) : l’extraction utilise principalement
I_JournalEntrypour les données d’en-tête etI_JournalEntryItempour les détails des postes et des montants. Ces vues offrent une interface simplifiée et riche sur le plan sémantique vers le journal universel (ACDOCA). - Tables complémentaires : pour obtenir une vue complète du processus, la requête joint également plusieurs tables SAP standard :
CDHDRetCDPOSpour suivre les modifications apportées aux documents.SRGBRELetSOODpour identifier le moment où des pièces jointes sont associées via Generic Object Services (GOS).SWW_WI2OBJetSWWLOGHISTpour extraire les événements clés du Workflow d’approbation.
- Filtrage par période : il est essentiel de limiter les données à une période précise afin de préserver les performances. Utilisez le champ
I_JournalEntry.CreationDateTimedans la clauseWHERE. Pour une première analyse, une période de 3 à 6 mois est recommandée. - Filtrage organisationnel : filtrez toujours par
CompanyCodeafin de limiter l’extraction aux entités juridiques concernées. Dans un système volumineux, interroger tous les codes société en une seule fois peut entraîner des temps d’exécution très longs. - Identifiants de tâche Workflow : la requête contient des placeholders pour les identifiants de tâche Workflow, par exemple
[Workflow Approved Task ID]. Ces identifiants sont propres à chaque installation SAP et doivent être correctement configurés pour extraire les activités du Workflow. Sans eux, aucun événement de soumission, d’approbation ou de rejet ne sera capturé. - Prérequis : l’utilisateur qui exécute la requête doit disposer d’autorisations étendues en lecture sur les tables financières, système et 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
- Vérifiez que l’accès SQL direct à la base de données SAP HANA est approuvé et que l’utilisateur chargé de l’extraction dispose d’une autorisation de lecture sur BKPF et ACDOCA, ainsi que sur les sources configurées pour les flux de travail, les pièces jointes, l’historique des modifications, les compensations ou les extournes requises par votre système. L’accès direct à la base de données s’effectue généralement avec SAP HANA Database Explorer, SAP HANA Studio ou un client SQL approuvé. N’exécutez pas de requêtes d’extraction dans une transaction d’application SAP, sauf si votre système autorise explicitement cet accès.
- Vérifiez le schéma physique de BKPF et d’ACDOCA, notamment le champ client, le champ du code société, le champ de l’exercice, le champ du numéro de document, le champ du type de document, le champ de la date de comptabilisation, le champ de la date de création, le champ de l’heure de création, le champ utilisateur, le champ du montant en devise locale et les éventuels champs d’extourne ou de compensation. Les déploiements SAP S/4HANA peuvent différer par leur schéma et la disponibilité des champs. Remplacez donc les paramètres entre crochets dans la requête par des champs vérifiés dans votre système.
- Identifiez les sources faisant autorité pour les événements de flux de travail et de pièces jointes. BKPF et ACDOCA fournissent les données des documents comptables et des postes, mais ne permettent pas à elles seules d’exposer de manière fiable chaque événement de mise en attente, de soumission, de rejet, de correction, d’approbation ou de pièce jointe. Remplacez les paramètres entre crochets des sources de flux de travail et de pièces jointes par les vues ou tables approuvées de votre implémentation. Si une source n’est pas disponible, n’inventez pas d’événements. Configurez la source correspondante ou excluez l’activité avec une validation documentée.
- Définissez les paramètres d’extraction pour la période, les codes société, les types de document et le client requis. Pour une première validation, une période de trois à six mois est recommandée. Utilisez la période des horodatages d’événements pour les événements opérationnels et la période de date de comptabilisation pour les événements comptables, conformément au périmètre convenu.
- Exécutez la requête SQL complète dans le client SQL HANA approuvé. La requête crée une ligne d’événement pour chaque activité explicitement extraite. Elle utilise BKPF et ACDOCA pour les événements comptables, ainsi que les vues sources configurées pour les événements de flux de travail, de pièces jointes, de modification, de compensation et d’extourne. Elle ne déduit pas d’activités de la seule existence d’un document.
- Examinez le schéma de sortie. JournalEntryId est l’identifiant du cas, ActivityName le libellé de l’activité et EventTime l’horodatage de l’événement. Les attributs métier recommandés sont renvoyés lorsqu’ils sont disponibles. Vérifiez qu’EventTime est un horodatage et que toutes les lignes possèdent un JournalEntryId et un ActivityName non vides.
- Rapprochez la population comptable en comparant les valeurs distinctes de JournalEntryId à la population BKPF attendue pour le client, les codes société, les exercices et la période sélectionnés. Rapprochez séparément les populations des flux de travail et des pièces jointes, car leurs règles de conservation et d’horodatage peuvent différer de celles des données comptables.
- Validez l’ordre des événements et le traitement des doublons. Plusieurs postes dans ACDOCA ne doivent pas créer de doublons d’événements comptables, sauf si la conception du processus prévoit explicitement des événements au niveau du poste. Utilisez la logique d’agrégation de la requête pour produire un événement comptable par écriture et par type d’événement, tout en conservant les identifiants d’événement des sources configurées lorsqu’ils sont disponibles.
- Exportez le résultat au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Conservez exactement les noms de colonnes JournalEntryId, ActivityName et EventTime. Triez le fichier par JournalEntryId et EventTime, puis conservez les attributs supplémentaires sous forme de colonnes. Importez le fichier dans ProcessMind et configurez JournalEntryId comme identifiant du cas, ActivityName comme activité et EventTime comme horodatage de l’événement.
Configuration
- Période : Commencez par trois à six mois. Utilisez une période plus courte pour tester les performances, puis élargissez-la uniquement après avoir validé le nombre de lignes et la couverture des événements.
- Périmètre client et société : Définissez le [paramètre Client] et limitez CompanyCode aux entités juridiques requises. N’omettez pas le prédicat client dans un système multi-client.
- Périmètre comptable : Configurez [le filtre sur le type de document] et, si nécessaire, les filtres sur l’exercice fiscal et la date de comptabilisation. N’incluez les documents comptabilisés et non comptabilisés que si la source sélectionnée les représente de manière fiable.
- Périmètre du flux de travail : Configurez [la source des événements du flux de travail] et les associations de types d’événements pour les activités soumises, rejetées, corrigées et approuvées. Vérifiez si les horodatages correspondent à la création, à l’exécution ou à l’achèvement de l’action du flux de travail.
- Périmètre des pièces jointes : Configurez [la source des événements de pièces jointes] et le champ de relation qui associe une pièce jointe à l’écriture de journal. Vérifiez si la source enregistre la création, le remplacement ou la suppression de la pièce jointe.
- Périmètre des modifications : Configurez [la source de l’historique des modifications] pour les modifications postérieures à la comptabilisation. Vérifiez que la source identifie l’écriture de journal et fournit un horodatage de modification fiable.
- Périmètre du lettrage : Configurez [la source du lettrage] et la relation entre le document comptable lettré et le document de lettrage. Déterminez si l’événement doit être associé à l’écriture de journal d’origine, au document de lettrage ou aux deux.
- Périmètre des extournes : Configurez [la source des extournes] et la relation entre les documents d’origine et d’extourne. La requête associe l’activité d’extourne à l’identifiant JournalEntryId d’origine lorsque cette relation est disponible.
- Classification des comptabilisations manuelles : Configurez [la source des comptabilisations manuelles] ou un champ d’origine de comptabilisation vérifié. Manual Posting Identified est un événement de classification qui doit utiliser de manière cohérente l’horodatage de comptabilisation ou un autre horodatage approuvé.
- Montant en devise : ACDOCA repose sur les postes. La requête agrège les montants en devise locale par écriture de journal. Vérifiez la convention de signe et déterminez si les lignes statistiques, propres à un ledger ou issues d’un ledger d’extension doivent être incluses.
- Performances : Sélectionnez uniquement les colonnes nécessaires, appliquez les filtres le plus tôt possible, évitez les analyses sans restriction d’ACDOCA et exécutez la requête pendant une fenêtre de reporting approuvée. Utilisez l’élagage des partitions au moyen des prédicats sur le client, l’exercice fiscal, le code société et la date de comptabilisation lorsque cette fonction est prise en charge.
- Gestion des doublons : Utilisez les identifiants d’événement source lorsqu’ils sont disponibles. Si une source peut contenir des enregistrements techniques répétés, appliquez la règle de déduplication documentée sans regrouper des actions de flux de travail réellement distinctes.
- Prérequis : Autorisations requises sur la base de données, connectivité SAP HANA approuvée, accès aux sources de flux de travail et de pièces jointes configurées, configuration appropriée de SAP Financial Accounting et du flux de travail, ainsi qu’un format d’export pris en charge par ProcessMind.
a Exemple de requête sql
WITH
accounting_base AS (
SELECT
b.[Client field] AS ClientId,
b.[Company code field] AS CompanyCode,
b.[Fiscal year field] AS FiscalYear,
b.[Document number field] AS AccountingDocumentNumber,
b.[Document type field] AS JournalEntryType,
b.[Created by field] AS CreatedByUser,
b.[Document date field] AS DocumentDate,
b.[Posting date field] AS PostingDate,
b.[Creation date field] AS CreationDate,
b.[Creation time field] AS CreationTime,
b.[Reversal document field] AS ReversalDocumentNumber,
b.[Reversed document field] AS ReversedDocumentNumber,
b.[Reversal fiscal year field] AS ReversalFiscalYear,
SUM(a.[Local currency amount field]) AS AmountInLocalCurrency,
MAX(a.[Local currency field]) AS LocalCurrency
FROM [Your schema].[BKPF] b
INNER JOIN [Your schema].[ACDOCA] a
ON a.[Client field] = b.[Client field]
AND a.[Company code field] = b.[Company code field]
AND a.[Fiscal year field] = b.[Fiscal year field]
AND a.[Document number field] = b.[Document number field]
WHERE b.[Client field] = '[Client parameter]'
AND b.[Company code field] IN ([Company code filter])
AND b.[Posting date field] BETWEEN '[Start date parameter]' AND '[End date parameter]'
AND b.[Document type field] IN ([Document type filter])
GROUP BY
b.[Client field],
b.[Company code field],
b.[Fiscal year field],
b.[Document number field],
b.[Document type field],
b.[Created by field],
b.[Document date field],
b.[Posting date field],
b.[Creation date field],
b.[Creation time field],
b.[Reversal document field],
b.[Reversed document field],
b.[Reversal fiscal year field]
),
base_cases AS (
SELECT
ClientId,
CompanyCode,
FiscalYear,
AccountingDocumentNumber,
CAST(CompanyCode || '/' || FiscalYear || '/' || AccountingDocumentNumber AS NVARCHAR(100)) AS JournalEntryId,
JournalEntryType,
CreatedByUser,
PostingDate,
AmountInLocalCurrency,
LocalCurrency,
CreationDate,
CreationTime,
ReversalDocumentNumber,
ReversedDocumentNumber,
ReversalFiscalYear
FROM accounting_base
),
created_events AS (
SELECT
JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CreationDate || ' ' || CreationTime AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
),
parked_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Parked event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
attachment_events AS (
SELECT
CAST(x.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Supporting Documentation Attached' AS ActivityName,
CAST(x.[Event timestamp field] AS TIMESTAMP) AS EventTime,
x.[User field] AS CreatedByUser,
x.[Company code field] AS CompanyCode,
x.[Journal entry type field] AS JournalEntryType,
x.[Posting date field] AS PostingDate,
x.[Amount in local currency field] AS AmountInLocalCurrency,
x.[Local currency field] AS LocalCurrency
FROM [Your schema].[Attachment event source] x
WHERE x.[Client field] = '[Client parameter]'
AND x.[Event type field] = '[Attachment created event type]'
AND CAST(x.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
submitted_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Submitted For Review' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Submitted event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
rejected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Rejected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Rejected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
corrected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Corrected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
approved_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Approved' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Approved event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
manual_events AS (
SELECT
JournalEntryId,
'Manual Posting Identified' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Manual posting condition verified for this system]
),
posted_events AS (
SELECT
JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Posted document condition verified for this system]
),
changed_events AS (
SELECT
CAST(c.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Changed After Posting' AS ActivityName,
CAST(c.[Change timestamp field] AS TIMESTAMP) AS EventTime,
c.[User field] AS CreatedByUser,
c.[Company code field] AS CompanyCode,
c.[Journal entry type field] AS JournalEntryType,
c.[Posting date field] AS PostingDate,
c.[Amount in local currency field] AS AmountInLocalCurrency,
c.[Local currency field] AS LocalCurrency
FROM [Your schema].[Change history source] c
WHERE c.[Client field] = '[Client parameter]'
AND c.[Post posting change indicator field] = '[Post posting change value]'
AND CAST(c.[Change timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
cleared_events AS (
SELECT
CAST(cl.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Cleared' AS ActivityName,
CAST(cl.[Clearing timestamp field] AS TIMESTAMP) AS EventTime,
cl.[User field] AS CreatedByUser,
cl.[Company code field] AS CompanyCode,
cl.[Journal entry type field] AS JournalEntryType,
cl.[Posting date field] AS PostingDate,
cl.[Amount in local currency field] AS AmountInLocalCurrency,
cl.[Local currency field] AS LocalCurrency
FROM [Your schema].[Clearing source] cl
WHERE cl.[Client field] = '[Client parameter]'
AND CAST(cl.[Clearing timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
reversal_events AS (
SELECT
CAST(r.[Original journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(r.[Reversal timestamp field] AS TIMESTAMP) AS EventTime,
r.[User field] AS CreatedByUser,
r.[Company code field] AS CompanyCode,
r.[Journal entry type field] AS JournalEntryType,
r.[Posting date field] AS PostingDate,
r.[Amount in local currency field] AS AmountInLocalCurrency,
r.[Local currency field] AS LocalCurrency
FROM [Your schema].[Reversal source] r
WHERE r.[Client field] = '[Client parameter]'
AND CAST(r.[Reversal timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
)
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM created_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM parked_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM attachment_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM submitted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM rejected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM corrected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM approved_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM manual_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM posted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM changed_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM cleared_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM reversal_events
ORDER BY JournalEntryId, EventTime, ActivityName; Étapes
- Créez le programme ABAP : accédez à l’éditeur ABAP à l’aide du code de transaction
SE38. Saisissez un nom pour le nouveau programme, par exempleZ_PM_JE_EXTRACT, puis cliquez sur « Create ». Indiquez un titre approprié, définissez « Type » sur « Executable Program » et enregistrez le programme comme objet local ou dans un package. - Définissez l’écran de sélection : dans le programme, définissez les paramètres et les select-options qui permettront aux utilisateurs de filtrer les données. Ils doivent inclure une période pour la date de création de l’écriture comptable (
P_CPUDT_FR,P_CPUDT_TO), un select-option pour le code société (SO_BUKRS) et un chemin de fichier de sortie sur le serveur d’application (P_FPATH). - Déclarez les structures de données : définissez une structure de table interne correspondant au format requis du journal d’événements. Cette structure contiendra le résultat final. Déclarez également les tables internes et les zones de travail correspondant aux tables SAP interrogées, telles que BKPF, ACDOCA, CDHDR, CDPOS et diverses tables de flux de travail.
- Implémentez la logique de sélection des données : écrivez la logique ABAP principale pour extraire les données des 12 activités requises. Créez une sous-routine (FORM) distincte pour chaque activité afin de conserver un code organisé. Vous pouvez par exemple créer une FORM pour
get_created_events,get_parked_events,get_workflow_events, etc. - Sélectionnez les événements « Created » et « Posted » : lisez la table BKPF selon les critères définis sur l’écran de sélection. Une entrée dans BKPF indique une création. Un document dont le statut
BSTAT = ' 'est considéré comme comptabilisé. Utilisez l’horodatage de création (CPUDT,CPUTM) comme heure de l’événement. - Sélectionnez les événements « Parked » : lisez la table VBKPF, qui stocke les en-têtes des documents mis en attente. L’horodatage de création de cette table représente l’événement de mise en attente.
- Sélectionnez les événements de flux de travail (« Submitted », « Approved », « Rejected ») : interrogez des tables de flux de travail telles que SWW_WI2OBJ, pour relier un objet d’écriture comptable à une instance de flux de travail, et SWWLOGHIST ou SWWIHEAD, pour obtenir les détails et le calendrier des étapes concernées. Vous devrez identifier les identifiants des tâches de flux de travail correspondant à la soumission, à l’approbation et au rejet dans votre système.
- Sélectionnez les événements « Change » et « Correction » : interrogez les tables des documents de modification CDHDR, pour l’en-tête, et CDPOS, pour le poste, avec
OBJECTCLAS = 'BELEG'. Pour « Changed After Posting », filtrez les modifications dont l’horodatage est postérieur à la date de comptabilisation du document. Pour « Corrected », filtrez les modifications apportées aux documents mis en attente ou rejetés. - Sélectionnez les événements « Reversal » et « Cleared » : identifiez les extournes en recherchant les documents dont le champ
STBLG(numéro du document extourné) de BKPF est renseigné. L’heure de l’événement d’extourne est l’heure de création du document d’extourne. Identifiez les événements de compensation en sélectionnant la dernière date de compensation (AUGDT) dans ACDOCA pour les postes d’une écriture comptable donnée. - Combinez et triez les données : à 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 cette table par
JournalEntryIdetEventTimeafin de garantir l’ordre chronologique de chaque cas. - Générez le fichier de sortie : utilisez les instructions
OPEN DATASET,LOOP AT... TRANSFERetCLOSE DATASETpour écrire le contenu de la table interne finale triée dans le chemin de fichier indiqué sur le serveur d’application SAP. Le fichier doit être au format CSV et comporter une ligne d’en-tête. - Planifiez l’exécution : pour les extractions régulières, utilisez le code de transaction
SM36afin de créer un job en arrière-plan qui exécute le programmeZ_PM_JE_EXTRACTselon une fréquence définie, par exemple chaque semaine ou chaque mois. Cette planification automatise l’exportation des données.
Configuration
- Période : l’écran de sélection doit comporter une période obligatoire pour la date de création de l’écriture comptable (
CPUDT). Il est recommandé d’extraire les données par tranches maîtrisables, par exemple trois à six 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 concernées par l’analyse de Process Mining. Il n’est pas recommandé d’extraire tous les codes société en une seule fois. - Type de document (
BLART) : vous pouvez ajouter ce filtre facultatif pour vous concentrer sur certains types d’écritures comptables, par exemple « SA » pour une comptabilisation sur compte général ou « KR » pour des factures fournisseurs. Cela peut réduire le volume de données et accroître la pertinence du jeu de données. - Chemin de fichier : le programme nécessite un chemin de fichier logique sur le serveur d’application SAP, où le fichier de sortie sera écrit. Vérifiez 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
AL11pour gérer et consulter les répertoires du serveur. - Identifiants des tâches du flux de travail : la logique d’extraction des événements de flux de travail (« Submitted », « Approved », « Rejected ») doit être configurée avec les identifiants de tâche utilisés dans le flux de travail d’approbation des écritures comptables de votre organisation. Ces identifiants sont souvent personnalisés et doivent être déterminés par un consultant ou un développeur spécialisé dans les flux de travail.
- Prérequis : l’utilisateur ou le compte système qui exécute le programme doit disposer d’autorisations de développement pour créer et exécuter des programmes ABAP (
S_DEVELOP), ainsi que d’un large accès en lecture aux tables financières (BKPF, ACDOCA), aux tables des journaux de modification (CDHDR, CDPOS) et aux tables de flux de travail (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. Prêt à commencer ?
Utilisez ce modèle pour préparer vos données en toute confiance et obtenir des analyses essentielles de votre processus Record to Report - Journal Entry. Commencez dès aujourd’hui votre démarche vers l’excellence des processus.
Optimisez Record to Report Journal Entry pour une efficacité maximale
Transformez votre processus et réduisez de 30 % le temps de cycle des écritures Record to Report.
Aucune carte bancaire requise. Configuration en quelques minutes.