Votre modèle de données pour le processus de comptabilisation au reporting, écritures comptables
Votre modèle de données pour le processus de comptabilisation au reporting, écritures comptables
- Attributs recommandés à recueillir
- Activités clés à suivre
- Conseils pratiques pour l’extraction
Attributs du processus de comptabilisation au reporting, écritures comptables
| Nom | Description | ||
|---|---|---|---|
| Activité ActivityName | Nom de l’activité métier réalisée à une étape précise du processus de saisie des écritures. | ||
| Description L’activité correspond à une étape ou à un événement précis du cycle de vie d’une écriture comptable, comme « Écriture comptable créée », « Écriture soumise pour vérification » ou « Écriture comptable comptabilisée ». Ces activités sont généralement déduites 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 déroulement du processus, de repérer les parcours courants et de détecter 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 est-ce important ? Cet attribut définit les étapes du processus et permet de visualiser les cartes de processus et d’analyser les schémas des flux de travail. Où trouver ces données Cet attribut est déduit de différentes 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 du flux de travail. Exemples Écriture comptable crééeÉcriture comptable mise en attenteÉcriture 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 cas possède son propre horodatage, ce qui permet d’établir la chronologie des événements. Cet attribut est essentiel à toute analyse temporelle du processus. 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 du travail dans le temps. Des horodatages exacts sont indispensables pour établir un modèle de processus fiable et calculer des indicateurs clés de performance, comme le temps de cycle d’approbation. Pourquoi est-ce important ? Il établit l’ordre chronologique des événements, indispensable au calcul des indicateurs de durée et à la compréhension du déroulement du processus dans le temps. Où trouver ces données Cet attribut provient des journaux des documents de modification (CDHDR-UDATE, CDHDR-UTIME), des journaux du flux de travail ou des horodatages de création et de saisie dans des tables comme 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 cas dans le processus. | ||
| Description L’identifiant de l’écriture comptable est un numéro unique attribué à chaque pièce comptable lors de sa création dans SAP S/4HANA. Il permet de suivre l’ensemble du cycle de vie d’une écriture, de sa création ou de sa mise en attente aux flux de travail d’approbation, jusqu’à sa comptabilisation finale et à une éventuelle extourne ou un éventuel lettrage. Dans une analyse de process mining, cet identifiant sert à regrouper toutes les activités associées dans un même cas. En rassemblant les événements sous un identifiant commun, les analystes peuvent reconstituer le déroulement complet du processus, mesurer les temps de cycle et repérer les variations ou les goulots d’étranglement propres à chaque transaction financière. C’est l’attribut de base qui permet de représenter l’ensemble du processus. Pourquoi est-ce important ? Cet identifiant relie toutes les étapes associées du processus et permet d’analyser le parcours complet de chaque écriture comptable. Où trouver ces données Il s’agit d’une clé composite, généralement formée par la concaténation du code société (BKPF-BUKRS), du numéro de pièce (BKPF-BELNR) et de l’exercice comptable (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 à laquelle l’écriture comptable est imputé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 associée à un code société précis. Cet attribut est essentiel pour segmenter et comparer les performances du processus entre les différentes entités de l’organisation. Vous pouvez filtrer la vue du processus sur une entité juridique, comparer les taux de rejet entre les codes société ou repérer des différences propres à certaines régions. Pourquoi est-ce important ? Permet de filtrer et de comparer le processus de comptabilisation des écritures entre les différentes entités juridiques ou unités opérationnelles de l’organisation. Où trouver ces données 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 et 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. Elle est essentielle en comptabilité et peut différer de la date de création du document ou de sa saisie dans le système. En Process Mining, elle sert à analyser des cohortes dans le temps, par exemple pour comparer les processus de clôture mensuelle ou étudier les tendances de performance sur différentes périodes financières. Elle permet aussi de mesurer le délai entre la création de l’écriture et sa comptabilisation effective. Pourquoi est-ce important ? Indispensable pour situer les données dans leur contexte financier, cet attribut permet d’analyser les performances du processus sur une période comptable précise, par exemple à la clôture mensuelle ou annuelle. Où trouver ces données 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 | Montant total de l’écriture comptable, exprimé dans la devise locale du code société. | ||
| Description Cet attribut indique le montant de l’écriture comptable. Il correspond généralement à la somme des valeurs absolues de toutes les lignes de débit ou de crédit du document, converties dans la devise locale du code société. L’analyse par montant permet de segmenter le processus selon l’incidence financière des écritures. Par exemple, les écritures de montant élevé peuvent suivre un processus d’approbation plus strict que celles de faible montant. Vous pouvez ainsi concentrer les efforts d’amélioration sur les transactions qui présentent le risque financier le plus élevé. Pourquoi est-ce important ? Indique le montant de l’écriture et permet d’analyser les variations du processus selon les sommes en jeu. Où trouver ces données Calculé en additionnant les montants de la table des postes BSEG (champ DMBTR) pour une écriture comptable 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 objet métier, par exemple une immobilisation, une facture fournisseur ou une écriture au 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 comptable aide à comprendre les différences de traitement selon le contexte. Par exemple, le processus d’approbation d’une simple provision (type SA) peut être bien plus simple que celui d’une acquisition complexe d’immobilisation (type AA). Cette dimension est essentielle au Dashboard « Conformité par type d’écriture ». Pourquoi est-ce important ? Classe les écritures selon leur contexte métier afin d’analyser les différences de processus et les performances pour chaque type de transaction financière. Où trouver ces données 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 selon son créateur permet de repérer des tendances liées à certains utilisateurs ou équipes. Elle peut révéler des besoins de formation si certains utilisateurs enregistrent davantage de rejets, ou mettre en évidence les personnes les plus performantes. Cet attribut est essentiel au Dashboard « Activité et débit des utilisateurs ». Pourquoi est-ce important ? Associe les activités du processus à des utilisateurs précis afin d’analyser les performances, d’équilibrer la charge de travail et de repérer les besoins de formation. Où trouver ces données Table SAP S/4HANA BKPF, champ USNAM (nom d’utilisateur). Exemples ABROWNCJONESBATCH_USER | |||
| A nécessité une reprise IsRework | Indicateur booléen précisant si l’écriture comptable a nécessité une reprise, par exemple une correction après un rejet. | ||
| Description Cet attribut calculé signale les écritures comptables qui s’écartent du parcours nominal. Il prend généralement la valeur true lorsqu’une activité telle que « Écriture comptable rejetée » ou « Écriture comptable corrigée » apparaît dans le cas. Cet indicateur simplifie l’analyse de l’efficacité du processus. Il permet de calculer rapidement le KPI de taux de reprise et de comparer directement les temps de cycle et les coûts des cas avec et sans reprise. Repérer les causes des reprises est un objectif majeur de nombreuses initiatives d’amélioration des processus. Pourquoi est-ce important ? Signale les cas qui ont nécessité une correction ou des boucles supplémentaires, pour quantifier facilement les inefficacités du processus et en analyser les causes profondes. Où trouver ces données Cet attribut calculé est déduit de la séquence des activités d’un cas. Il prend la valeur « true » si une activité telle que « Écriture comptable rejetée » est présente. Exemples truefalse | |||
| Code de transaction TransactionCode | Code de transaction SAP utilisé pour créer ou modifier l’écriture comptable. | ||
| Description Le code de transaction (T-Code) est un raccourci qui désigne une fonction ou un programme précis dans SAP. Pour les écritures comptables, les différents T-Codes indiquent comment l’écriture a été créée : FB01 pour une comptabilisation manuelle au 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 permet de déterminer si une activité a été effectuée manuellement par un utilisateur ou automatiquement par le système. Il est essentiel au calcul du KPI de taux de comptabilisation manuelle et à l’identification des possibilités d’automatisation. Pourquoi est-ce important ? Indique le mode de traitement d’une écriture, manuel ou automatique, et aide à analyser les possibilités d’automatisation ainsi que les différences entre les processus. Où trouver ces données Table SAP S/4HANA BKPF, champ TCODE (code de transaction). Exemples FB01FV50F-02 | |||
| 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 comptabilisées à la suite d’une intervention manuelle, plutôt que automatiquement par une tâche système ou une interface. Il est généralement déduit du code de transaction utilisé pour comptabiliser le document. Cet indicateur sert à calculer le KPI de taux de comptabilisation manuelle et à suivre les progrès de l’organisation en matière d’automatisation du processus Record to Report. En filtrant les écritures comptabilisées manuellement, vous pouvez repérer les situations qui nécessitent encore une intervention humaine et évaluer leur potentiel d’automatisation. Pourquoi est-ce important ? Distingue les comptabilisations effectuées par une personne de celles réalisées par le système. Cette distinction permet de mesurer le degré d’automatisation et de repérer de nouvelles possibilités. Où trouver ces données Cet attribut calculé est déduit du code de transaction. 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 | |||
| 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 indique la date et l’heure de la dernière extraction ou mise à jour des données depuis le système source. Il permet de savoir si les données analysées sont récentes. Connaître la date de la dernière mise à jour aide à évaluer l’actualité de l’analyse du processus. Vous pouvez ainsi interpréter correctement les Dashboards et les KPI, en sachant si les données sont presque en temps réel ou correspondent à un instantané d’une période antérieure. Pourquoi est-ce important ? Indique l’actualité des données et permet de savoir à quel point l’analyse du processus est récente. Où trouver ces données Il s’agit d’un attribut de métadonnées, généralement généré et ajouté à chaque enregistrement lors de l’ingestion des données. Exemples 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Exercice fiscal FiscalYear | Exercice fiscal auquel appartient l’écriture comptable. | ||
| 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 correspond à l’année financière à laquelle le document se rapporte. Lors 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 plusieurs exercices fiscaux peut révéler une amélioration ou une dégradation des performances au fil du temps. Pourquoi est-ce important ? Contribue à identifier les documents de manière unique et permet de comparer les performances du processus d’un exercice à l’autre. Où trouver ces données Table SAP S/4HANA BKPF, champ GJAHR (exercice fiscal). Exemples 202320242022 | |||
| Heure de fin EndTime | Horodatage indiquant la fin de l’activité. | ||
| 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 : l’événement est alors instantané. Pour les activités dont la durée peut être mesurée, comme l’examen 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 la durée de traitement des activités et les temps d’attente. Vous pouvez ainsi distinguer le temps consacré activement à une tâche du temps pendant lequel elle reste en attente dans une file. Pourquoi est-ce important ? Permet de calculer précisément la durée de traitement des activités et de distinguer le temps de travail actif du temps d’attente. Où trouver ces données Pour les événements ponctuels, cette valeur est généralement identique à StartTime. Pour les activités qui durent, elle peut provenir des journaux de flux de travail ou être calculée à partir des événements suivants. Exemples 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Motif d’annulation ReversalReason | Code indiquant pourquoi 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 : elle doit être annulée au moyen d’un nouveau document. Le code du motif d’annulation précise la raison de cette opération, par exemple une date ou un montant de comptabilisation incorrect. L’analyse des motifs d’annulation aide à repérer 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 contrôles défaillants. Il est alors possible d’y remédier pour améliorer la qualité dès la première exécution. Pourquoi est-ce important ? Aide à déterminer les causes profondes des erreurs qui entraînent des annulations, afin de réduire les reprises et d’améliorer la qualité du processus. Où trouver ces données Table SAP S/4HANA BKPF, champ STGRD (motif d’annulation). Exemples 010205 | |||
| Statut du document DocumentStatus | État actuel de l’écriture comptable, par exemple en attente, comptabilisée ou lettrée. | ||
| Description Le statut du document indique où en est l’écriture comptable dans son cycle de vie. Par exemple, un document « en attente » est enregistré, mais pas encore comptabilisé dans le grand livre, tandis qu’un document « comptabilisé » est finalisé. L’analyse du statut permet de comprendre le déroulement du travail et de repérer les goulots d’étranglement. Un grand nombre de documents qui restent longtemps « en attente » ou « en attente d’approbation » peut signaler des inefficacités dans le processus. Le statut constitue également une source importante pour déduire les activités du processus. Pourquoi est-ce important ? Indique où se trouve l’écriture comptable dans son cycle de vie et aide à repérer les files d’attente et les goulots d’étranglement. Où trouver ces données Table SAP S/4HANA BKPF, champ BSTAT (statut du document). Exemples VAB | |||
| Système source SourceSystem | Identifie le système source à partir duquel les données des écritures comptables ont été extraites. | ||
| Description Cet attribut indique le système de référence d’où proviennent les données de l’écriture comptable. Dans les entreprises qui utilisent plusieurs instances ERP ou combinent des systèmes anciens et récents, il permet de distinguer les sources de données. Lors de l’analyse, vous pouvez l’utiliser pour comparer les performances du processus entre différents systèmes ou filtrer les données provenant d’une source précise. Il contribue à la gouvernance des données et permet d’en comprendre le contexte. Pourquoi est-ce important ? Cet attribut précise l’origine des données. Il est essentiel pour analyser et comparer correctement les processus dans un environnement composé de plusieurs systèmes. Où trouver ces données 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 au moyen de son SID ou du nom de son système logique. Exemples S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Temps de 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 mesure précisément la durée de l’étape d’approbation. Elle correspond au temps écoulé entre l’activité « Écriture comptable soumise pour examen » et l’activité suivante, « Écriture comptable approuvée » ou « Écriture comptable rejetée ». Ce KPI aide à repérer les goulots d’étranglement dans le 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 mettre en évidence des points à améliorer. Pourquoi est-ce important ? Mesure la durée de l’étape d’approbation afin de repérer et de réduire les goulots d’étranglement lors de l’examen et de l’approbation. Où trouver ces données Calculé en mesurant le temps écoulé 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 | |||
| 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. Un processus d’approbation à plusieurs niveaux peut faire intervenir plusieurs approbateurs pour une même écriture. Ces informations sont essentielles à l’analyse détaillée du processus d’approbation. Elles permettent de mesurer la charge de travail des différents approbateurs, de calculer leurs délais d’approbation et de repérer les goulots d’étranglement dans la chaîne d’approbation. Elles alimentent directement le Dashboard « Activité et débit des utilisateurs ». Pourquoi est-ce important ? Identifie la personne chargée de l’approbation et permet d’analyser la charge de travail, les performances et les goulots d’étranglement. Où trouver ces données Données issues des journaux de flux de travail, par exemple SWW_WI2OBJ et SWWLOG, ou des tables des documents de modification (CDHDR/CDPOS), en identifiant la personne qui a exécuté l’étape d’approbation. Exemples DMILLERFWHITEKCHEN | |||
Activités du processus de comptabilisation au reporting, écritures comptables
| Activité | Description | ||
|---|---|---|---|
| Écriture comptable approuvée | Un responsable habilité accorde l’approbation finale de l’écriture comptable et en confirme la validité et l’exactitude. Cette étape constitue le dernier contrôle avant la comptabilisation de la pièce dans le grand livre. | ||
| Pourquoi est-ce important ? Cette étape importante marque la fin du cycle d’approbation. Le délai nécessaire pour l’atteindre représente une part importante de la durée totale du processus et constitue un indicateur clé de l’efficacité des approbateurs. Où trouver ces données Cet événement est déduit d’un journal du flux de travail indiquant l’étape d’approbation finale ou d’un changement de statut de la pièce. L’identifiant de l’approbateur et l’horodatage peuvent être extraits des données du flux de travail ou des journaux de modification. Données à recueillir Repérez l’horodatage de l’étape d’approbation finale dans les journaux du flux de travail ou le changement de statut à « Approuvé » 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 une incidence sur les états financiers de l’entreprise. La pièce devient alors un enregistrement financier permanent. | ||
| Pourquoi est-ce important ? Il s’agit du principal jalon de réussite et de la fin du cycle de traitement principal. Le débit des écritures comptabilisées et le délai nécessaire pour atteindre cette étape sont des indicateurs fondamentaux du process mining. Où trouver ces données Cet événement explicite est indiqué par la date de comptabilisation (BUDAT) dans la table BKPF. Le champ de statut de la pièce (BSTAT) est vide pour une pièce comptabilisée, ce qui la distingue des pièces mises en attente (« V ») ou conservées (« D »). Données à recueillir Utilisez la date de comptabilisation (BKPF-BUDAT) et la date de saisie (BKPF-CPUDT) pour horodater l’événement. Un champ BKPF-BSTAT vide indique une pièce comptabilisée. Type d’événement explicit | |||
| Écriture comptable créée | Cette activité correspond à la création initiale d’une pièce 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. C’est le point de départ du cycle de vie de l’écriture. | ||
| Pourquoi est-ce 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 repérer les retards initiaux de saisie. Où trouver ces données Cet événement peut être extrait directement de 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 pièce donné (BELNR). Données à recueillir Utilisez BKPF-CPUDT et BKPF-CPUTM pour horodater l’événement. Type d’événement explicit | |||
| Écriture comptable lettrée | Un poste non soldé 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 est-ce important ? Pour de nombreuses écritures comptables, notamment celles qui concernent des comptes d’attente ou gérés par postes ouverts, cette activité constitue la dernière étape du rapprochement. L’analyse du délai entre la comptabilisation et le lettrage permet de mesurer l’efficacité du rapprochement. Où trouver ces données Cet événement est déduit de la table des postes (BSEG ou la vue ACDOCA). Lorsqu’un poste est lettré, les champs Date de lettrage (AUGDT) et Pièce de lettrage (AUGBL) sont renseignés pour ce poste. Données à recueillir Utilisez la date de lettrage du poste (BSEG-AUGDT) comme horodatage de l’événement. Type d’événement inferred | |||
| Écriture soumise pour vérification | Le créateur de l’écriture comptable soumet officiellement la pièce au flux de travail de vérification 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 est-ce important ? Cet événement marque le début du temps de cycle d’approbation. Mesurer le délai jusqu’à l’approbation ou au rejet final permet d’isoler les goulots d’étranglement propres aux étapes de vérification et d’approbation. Où trouver ces données Cet événement est souvent extrait des journaux du flux de travail (tables SWW_WIHEAD, SWWLOG) associés à l’objet métier. Il peut aussi être déduit d’un changement de statut dans un champ personnalisé de l’en-tête de la pièce (BKPF). Données à recueillir Horodatage de création de l’élément de flux de travail ou changement du champ de statut à « Soumis » ou « En cours de vérification ». Type d’événement inferred | |||
| Extourne de l’écriture comptable traitée | Une écriture comptable déjà comptabilisée est extournée par la création d’une nouvelle pièce contenant les écritures inverses. Cette opération explicite et vérifiable sert à corriger les erreurs des pièces comptabilisées. | ||
| Pourquoi est-ce important ? Une extourne indique qu’une erreur a été commise dans une pièce comptabilisée. Un taux d’extourne élevé peut révéler des problèmes sous-jacents dans le processus d’approbation ou la qualité de la saisie. Le suivi de cet indicateur aide à améliorer l’exactitude dès la première saisie. Où trouver ces données L’extourne est un événement explicite. L’en-tête (BKPF) de la nouvelle pièce d’extourne contient une référence à la pièce d’origine dans le champ Numéro de pièce extournée (STBLG). La date de comptabilisation de la nouvelle pièce correspond à l’heure de l’événement. Données à recueillir Repérez les pièces dont le champ BKPF-STBLG est renseigné. L’horodatage de l’événement correspond à la date de comptabilisation de la pièce d’extourne. Type d’événement explicit | |||
| Comptabilisation manuelle détecté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 est-ce important ? Le repérage des comptabilisations manuelles est important pour les initiatives d’automatisation. Une proportion élevée de comptabilisations manuelles peut indiquer qu’il serait utile d’intégrer des sous-systèmes ou d’utiliser des programmes de comptabilisation automatisés. Où trouver ces données Cette classification repose sur l’analyse du champ de code de transaction (TCODE) dans la table d’en-tête de la pièce (BKPF). Une liste de codes de transaction manuels connus, par exemple FB01, F-02 et FB50, permet de classer l’écriture. Données à recueillir Classez l’événement en comparant BKPF-TCODE à une liste prédéfinie de codes de transaction manuels au moment de la comptabilisation. Type d’événement calculated | |||
| Écriture comptable corrigée | Après le rejet de l’écriture ou son renvoi pour modification, l’utilisateur la corrige. Cette activité correspond aux reprises nécessaires pour traiter les problèmes relevés lors de la vérification avant une nouvelle soumission. | ||
| Pourquoi est-ce important ? Cette activité permet de quantifier les boucles de reprise. L’analyse de la fréquence et de la durée des corrections aide à repérer les sources d’inefficacité et les besoins de formation ou de clarification du processus. Où trouver ces données Cet événement peut être déduit du suivi de la date de dernière modification (AEDAT) dans la table BKPF, pour une pièce dont le statut était précédemment « Rejeté ». Les documents de modification fournissent des précisions supplémentaires sur les changements effectués. Données à recueillir Utilisez l’horodatage des en-têtes des documents de modification (CDHDR-UDATE) pour les changements effectués après un 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 en-tête de pièce dont le statut indique une mise en attente, sans comptabilisation. | ||
| Pourquoi est-ce important ? La mise en attente est une étape courante avant la soumission. Le suivi de sa durée permet de repérer les retards dans la saisie des données et la préparation, avant le début de la vérification et de l’approbation formelles. Où trouver ces données Dans la table BKPF, le champ de statut de la pièce (BSTAT) prend la valeur « V » pour identifier une pièce mise en attente. L’horodatage de l’événement correspond à la date de création (CPUDT). Données à recueillir Filtrez les pièces pour lesquelles BKPF-BSTAT = 'V' au moment de leur création. Type d’événement explicit | |||
| Écriture comptable modifiée après comptabilisation | Après la comptabilisation d’une écriture dans le grand livre, un utilisateur en modifie un nombre limité de champs. La plupart des données financières ne peuvent plus être modifiées après la comptabilisation, mais certains champs, comme le texte ou les imputations, peuvent l’être. | ||
| Pourquoi est-ce important ? Cette activité constitue un signal important pour la conformité. Les modifications apportées après la comptabilisation peuvent indiquer une tentative d’altération des enregistrements. Elles doivent donc faire l’objet d’un suivi attentif pour prévenir la fraude et préserver l’intégrité des données. Où trouver ces données Cet événement peut être déduit de manière fiable des tables des documents de modification (CDHDR et CDPOS). Une entrée CDHDR associée au numéro de pièce et dont la date de modification est postérieure à la date de comptabilisation signale une modification après comptabilisation. Données à recueillir Recherchez dans CDHDR les enregistrements dont l’horodatage de modification (UDATE/UTIME) est postérieur à la date de comptabilisation de la pièce (BKPF-BUDAT). Type d’événement inferred | |||
| Écriture comptable rejetée | Un vérificateur ou un approbateur rejette l’écriture comptable, qui ne peut alors pas être comptabilisée. La pièce est généralement renvoyée à son créateur pour correction, ce qui déclenche une boucle de reprise. | ||
| Pourquoi est-ce important ? Le suivi des rejets est essentiel pour comprendre la qualité du processus et repérer les erreurs courantes. Un taux de rejet élevé peut révéler des problèmes de précision des données, une mauvaise compréhension des règles ou des pièces justificatives insuffisantes. Où trouver ces données Cet événement est déduit d’un changement de statut dans un journal du flux de travail ou dans un champ de statut personnalisé de la pièce comptable. Les journaux des modifications (CDHDR/CDPOS) du champ de statut concerné peuvent fournir l’horodatage. Données à recueillir Repérez le changement du champ de statut à « Rejeté » dans les documents de modification (CDHDR/CDPOS) ou les journaux du 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. Ces documents fournissent généralement des éléments de preuve et du contexte pour la transaction financière lors de sa vérification et de son audit. | ||
| Pourquoi est-ce important ? La présence des pièces justificatives avant la vérification est essentielle à la conformité et à l’efficacité des approbations. Cette activité permet de mesurer le respect des règles documentaires et son effet sur les délais d’approbation. Où trouver ces données Cet événement est généralement déduit de 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 une pièce BKPF, à la pièce jointe. Données à recueillir Interrogez les tables des pièces jointes GOS, par exemple SRGBTBREL, pour trouver les liens vers l’objet BKPF, puis 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 autorisé à interroger la base de données sous-jacente de SAP S/4HANA ou à exécuter des rapports ABAP. Vous devez avoir 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 s’effectue généralement à l’aide d’un client de base de données comme SAP HANA Studio ou DBeaver, ou des outils de développement ABAP (ADT) pour Eclipse.
- Repérez les paramètres propres à votre système : avant d’exécuter la requête, identifiez les codes de tâche utilisés dans le flux de travail d’approbation des écritures comptables. Demandez à l’administrateur des flux de travail SAP de vous communiquer les ID de tâche (par exemple, TS12345678) correspondant aux événements de soumission, de rejet et d’approbation. Vous en aurez besoin pour renseigner les espaces réservés de la requête finale.
- Préparez la requête SQL : copiez la requête SQL complète de 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 espaces réservés dans la requête et remplacez-les par vos valeurs. Renseignez notamment les paramètres
[YourCompanyCode],[StartDate]et[EndDate]. Remplacez également les espaces réservés des ID de tâche du flux de travail ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) par les valeurs déterminé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, l’exécution peut prendre beaucoup de temps. Il est recommandé de la lancer en dehors des heures de pointe.
- Vérifiez les premiers résultats : une fois la requête terminée, examinez les premières lignes pour vérifier que toutes les colonnes, notamment JournalEntryId, ActivityName et EventTime, contiennent les valeurs attendues. Le résultat doit comporter une ligne pour chaque événement métier distinct du cycle de vie de l’écriture comptable.
- Exportez les données au format CSV : exportez l’ensemble des résultats de votre outil SQL dans un seul fichier CSV. Utilisez l’encodage UTF-8 pour éviter les problèmes liés aux caractères spéciaux.
- Préparez l’importation : avant d’importer le fichier dans un outil de Process Mining, vérifiez qu’il contient les en-têtes requis. Les données sont déjà structurées sous forme de journal d’événements : aucune transformation ni opération de pivot supplémentaire ne devrait être nécessaire.
Configuration
- Vues Core Data Services (CDS) : l’extraction utilise principalement
I_JournalEntrypour les données d’en-tête etI_JournalEntryItempour le détail 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 repérer les liens entre pièces jointes et documents via Generic Object Services (GOS).SWW_WI2OBJetSWWLOGHISTpour extraire les principaux événements du flux de travail d’approbation.
- Filtrage par période : pour préserver les performances, il est essentiel de limiter les données à une période précise. Utilisez le champ
I_JournalEntry.CreationDateTimedans la clauseWHERE. Pour une première analyse, une période de 3 à 6 mois est recommandée. - Filtrage par organisation : filtrez toujours les données par
CompanyCodeafin de limiter l’extraction aux entités juridiques concernées. Dans un système de grande taille, interroger tous les codes société en une seule fois peut entraîner des délais d’exécution très longs. - ID des tâches du flux de travail : la requête contient des espaces réservés pour les ID de tâche du flux de travail (par exemple,
[Workflow Approved Task ID]). Ces ID sont propres à chaque installation SAP et doivent être correctement configurés pour extraire les activités du flux de travail. Sans eux, aucun événement de soumission, d’approbation ou de rejet ne sera enregistré. - 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 de flux de travail. Ces autorisations ne sont pas attribuées par défaut et doivent faire l’objet d’une attribution spécifique.
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 autorisé et que l’utilisateur chargé de l’extraction dispose des droits 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, le lettrage 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 autorisé. N’exécutez pas de requêtes d’extraction dans une transaction d’application SAP, sauf si votre système prend explicitement en charge cet accès.
- Vérifiez le schéma physique de BKPF et ACDOCA, notamment les champs client, code société, exercice, numéro de document, type de document, date de comptabilisation, date de création, heure de création, utilisateur, montant en devise locale, ainsi que les champs d’extourne ou de lettrage. Les déploiements SAP S/4HANA peuvent différer par leur schéma et les champs disponibles. Remplacez donc les espaces réservés entre crochets dans la requête par les 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 des données sur les documents comptables et les postes, mais ne permettent pas à elles seules de repérer de manière fiable tous les événements de mise en attente, de soumission, de rejet, de correction, d’approbation ou de pièce jointe. Remplacez les espaces réservés des sources de flux de travail et de pièces jointes par les vues ou tables autorisées dans votre environnement. Si une source n’est pas disponible, ne créez pas d’événements fictifs. Configurez la source correspondante ou excluez l’activité après approbation 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. Selon le périmètre convenu, utilisez la période des horodatages des événements pour les activités opérationnelles et la période des dates de comptabilisation pour les événements comptables.
- Exécutez la requête SQL complète dans le client SQL HANA autorisé. 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, et les vues sources configurées pour les événements de flux de travail, de pièces jointes, de modification, de lettrage et d’extourne. Elle ne déduit pas d’activité de la simple existence d’un document.
- Vérifiez le schéma des résultats. 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 également renvoyés lorsqu’ils sont disponibles. Vérifiez que EventTime est un horodatage et que chaque ligne comporte 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 la gestion des doublons. Les postes multiples dans ACDOCA ne doivent pas générer 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 des événements sources configurés lorsqu’ils sont disponibles.
- Exportez les résultats 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, et gardez les attributs supplémentaires dans des colonnes distinctes. Importez le fichier dans ProcessMind et définissez JournalEntryId comme identifiant du cas, ActivityName comme activité et EventTime comme horodatage de l’événement.
Configuration
- Période : Commencez par une période de trois à six mois. Pour tester les performances, choisissez une période plus courte, puis élargissez-la uniquement après avoir vérifié le nombre de lignes et la couverture des événements.
- Périmètre des clients et des sociétés : Définissez le paramètre [Client] et limitez CompanyCode aux entités juridiques concernées. Dans un système multi-client, ne supprimez pas le filtre sur le client.
- Périmètre comptable : Configurez [Filtre sur le type de document] et, si nécessaire, les filtres sur l’exercice 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 [Source des événements du flux de travail] et les correspondances entre ses types d’événements et les activités soumises, rejetées, corrigées et approuvées. Vérifiez si les horodatages correspondent à la création, à l’exécution ou à la fin de l’action du flux de travail.
- Périmètre des pièces jointes : Configurez [Source des événements des pièces jointes] et le champ de relation qui associe une pièce jointe à l’écriture comptable. Vérifiez si la source enregistre la création, le remplacement ou la suppression des pièces jointes.
- Périmètre des modifications : Configurez [Source de l’historique des modifications] pour les changements effectués après la comptabilisation. Vérifiez que la source identifie l’écriture comptable et fournit un horodatage fiable.
- Périmètre du lettrage : Configurez [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 comptable d’origine, au document de lettrage ou aux deux.
- Périmètre des extournes : Configurez [Source des extournes] et la relation entre le document d’origine et le document d’extourne. Lorsque cette relation est disponible, la requête associe l’activité d’extourne au JournalEntryId d’origine.
- Classification des comptabilisations manuelles : Configurez [Source des comptabilisations manuelles] ou un champ vérifié indiquant l’origine de la comptabilisation. Manual Posting Identified est un événement de classification ; utilisez systématiquement l’horodatage de comptabilisation ou un autre horodatage approuvé.
- Montant en devise : ACDOCA contient des lignes de poste. La requête agrège les montants en devise locale par écriture comptable. Vérifiez la convention de signe et déterminez s’il faut inclure les lignes statistiques, propres à un ledger ou issues d’un ledger d’extension.
- Performances : Sélectionnez uniquement les colonnes nécessaires, appliquez les filtres dès le début, évitez les analyses sans restriction d’ACDOCA et exécutez la requête pendant une plage horaire approuvée pour les rapports. Lorsque cette option est prise en charge, utilisez l’élagage des partitions au moyen des filtres sur le client, l’exercice, le code société et la date de comptabilisation.
- Gestion des doublons : Utilisez les identifiants d’événement source lorsqu’ils sont disponibles. Si une source contient des enregistrements techniques répétés, appliquez la règle de déduplication documentée sans regrouper des actions distinctes du flux de travail.
- Prérequis : Autorisations requises sur la base de données, connexion SAP HANA approuvée, accès aux sources configurées pour les flux de travail et les pièces jointes, configuration appropriée de SAP Financial Accounting et des flux de travail, ainsi qu’un format d’export pris en charge par ProcessMind.
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 : ouvrez l’éditeur ABAP avec le code de transaction
SE38. Saisissez un nom pour le nouveau programme, par exempleZ_PM_JE_EXTRACT, puis cliquez sur « Créer ». Donnez-lui un titre approprié, sélectionnez « Programme exécutable » dans le champ « Type », puis enregistrez-le comme objet local ou dans un package. - Définissez l’écran de sélection : dans le programme, définissez des paramètres et des options de sélection permettant de filtrer les données. Prévoyez une période pour la date de création de l’écriture (
P_CPUDT_FR,P_CPUDT_TO), une option de sélection pour le code société (SO_BUKRS) et un chemin de fichier de sortie sur le serveur d’applications (P_FPATH). - Déclarez les structures de données : définissez une structure de table interne conforme au format requis pour le journal d’événements. Elle contiendra les résultats finaux. Déclarez également les tables internes et les zones de travail nécessaires pour les tables SAP interrogées, telles que BKPF, ACDOCA, CDHDR, CDPOS et les différentes tables de flux de travail.
- Mettez en place la logique de sélection des données : écrivez le code ABAP principal pour récupérer les données correspondant aux 12 activités requises. Créez une sous-routine (FORM) distincte pour chaque activité afin de structurer le code. Vous pouvez, par exemple, créer des FORM pour
get_created_events,get_parked_events,get_workflow_events, etc. - Sélectionnez les événements « Créé » et « Comptabilisé » : lisez la table BKPF selon les critères définis dans l’écran de sélection. Une entrée dans BKPF indique la création d’un document. Un document dont le statut est
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 « Mis en attente » : lisez la table VBKPF, qui contient les en-têtes des documents mis en attente. L’horodatage de création de cette table correspond à l’événement de mise en attente.
- Sélectionnez les événements du « flux de travail » (soumis, approuvés, rejetés) : 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 l’horodatage des étapes concernées). Vous devrez identifier les ID de tâche utilisés dans votre système pour la soumission, l’approbation et le rejet.
- Sélectionnez les événements « Modifié » et « Corrigé » : interrogez les tables de documents de modification CDHDR (en-tête) et CDPOS (poste) pour
OBJECTCLAS = 'BELEG'. Pour l’événement « Modifié après comptabilisation », filtrez les modifications dont l’horodatage est postérieur à la date de comptabilisation du document. Pour l’événement « Corrigé », filtrez les modifications apportées aux documents mis en attente ou rejetés. - Sélectionnez les événements « Extourné » et « Lettré » : repérez 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 correspond à l’heure de création du document d’extourne. Repérez les événements de lettrage en sélectionnant la date de lettrage la plus récente (AUGDT) dans la table ACDOCA pour les postes d’une écriture comptable donnée. - Combinez et triez les données : à mesure que vous sélectionnez les données de chaque activité, ajoutez les résultats à la table interne principale. Une fois toutes les sélections terminées, triez cette table par
JournalEntryIdetEventTimeafin de respecter 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 indiqué sur le serveur d’applications SAP. Le fichier doit être au format CSV et comporter une ligne d’en-tête. - Planifiez l’exécution : pour effectuer des extractions régulières, utilisez le code de transaction
SM36afin de créer une tâche d’arrière-plan qui exécutera le programmeZ_PM_JE_EXTRACTselon une fréquence définie, par exemple chaque semaine ou chaque mois. Cette tâche 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 lots de taille raisonnable, par exemple sur 3 à 6 mois, afin de préserver les performances. - Code société (
BUKRS) : ce filtre est essentiel pour limiter l’extraction aux entités juridiques concernées par l’analyse de Process Mining. Il est déconseillé d’extraire simultanément les données de tous les codes société. - Type de document (
BLART) : vous pouvez ajouter ce filtre facultatif pour cibler certains types d’écritures, comme « 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 améliorer la pertinence du jeu de données. - Chemin du fichier : le programme nécessite un chemin logique sur le serveur d’applications SAP où sera enregistré le fichier de sortie. Vérifiez que le chemin est valide et que l’utilisateur du système SAP dispose des droits d’écriture nécessaires dans ce répertoire. Utilisez la transaction
AL11pour gérer et consulter les répertoires du serveur. - ID des tâches du flux de travail : la logique d’extraction des événements du flux de travail (soumis, approuvés, rejetés) doit être configurée avec les ID de tâche utilisés dans le flux d’approbation des écritures comptables de votre organisation. Ces ID sont souvent personnalisés et doivent être identifié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 des autorisations de développement nécessaires pour créer et exécuter des programmes ABAP (
S_DEVELOP), ainsi que d’un accès étendu en lecture aux tables financières (BKPF, ACDOCA), aux tables de journal des modifications (CDHDR, CDPOS) et aux tables de flux de travail (SWW*).
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 ?
Appuyez-vous sur ce modèle pour préparer vos données en toute confiance et mieux comprendre votre processus de comptabilisation au reporting, écritures comptables. Commencez dès aujourd’hui à améliorer vos processus.
Optimisez les écritures comptables du processus de comptabilisation au reporting
Faites évoluer votre processus et réduisez de 30 % le temps de cycle des écritures comptables du processus de comptabilisation au reporting.
Aucune carte bancaire requise. Configuration en quelques minutes.