Votre modèle de données pour le processus de la comptabilisation au reporting : pièces comptables
Votre modèle de données pour le processus de la comptabilisation au reporting : pièces comptables
- Attributs recommandés pour une analyse complète
- Activités clés à suivre pour les pièces comptables
- Conseils pratiques pour extraire les données de SAP ECC
Attributs du processus de la comptabilisation au reporting : pièces comptables
| Nom | Description | ||
|---|---|---|---|
| Heure de l’événement EventTime | Horodatage indiquant à quel moment une activité ou un événement précis s’est produit pour l’écriture comptable. | ||
| Description L’heure de l’événement indique la date et l’heure exactes de chaque activité du processus de traitement des écritures comptables. Ces données sont indispensables au calcul de toutes les mesures temporelles, notamment les temps de cycle, les durées de traitement et les délais entre les étapes. La source de l’horodatage varie selon l’activité : il peut s’agir de la date et de l’heure de création du document (CPUDT/CPUTM) ou des horodatages de modification issus des journaux (CDHDR-UDATE/UTIME). Dans l’analyse, l’heure de l’événement sert à classer les événements par ordre chronologique et constitue la base de la carte de processus. Elle est indispensable au calcul de tous les indicateurs temporels, comme le temps de cycle moyen d’une écriture comptable, le temps d’approbation moyen et le délai entre l’approbation et la comptabilisation. Pourquoi est-ce important ? Cet horodatage est à la base de toutes les analyses temporelles. Il permet de calculer les temps de cycle, les durées et les goulots d’étranglement. Où trouver ces données La source varie selon l’activité. Il s’agit principalement de l’horodatage de création (CPUDT, CPUTM) dans BKPF ou des horodatages de modification (UDATE, UTIME) dans CDHDR. Exemples 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| Identifiant de l’écriture comptable JournalEntryId | Identifiant unique d’un document comptable, composé du code société, du numéro de document et de l’exercice. | ||
| Description L’identifiant de l’écriture comptable est l’identifiant de cas principal permettant de suivre le cycle de vie d’une écriture. Il s’agit d’une clé composite, généralement formée par la concaténation du code société (BUKRS), du numéro de document (BELNR) et de l’exercice (GJAHR), afin de garantir son unicité dans l’ensemble du système SAP. Dans l’analyse des processus, cet identifiant relie toutes les activités associées, comme la création, la mise en attente, la soumission, l’approbation, le rejet et la comptabilisation. En suivant cet identifiant, vous pouvez reconstituer le parcours de bout en bout de chaque écriture comptable, mesurer les temps de cycle et repérer les écarts ou les goulots d’étranglement propres à certaines écritures. Pourquoi est-ce important ? Cette clé est indispensable pour suivre une écriture comptable de sa création à sa comptabilisation finale. Elle permet d’analyser le processus de bout en bout et de comparer ses variantes. Où trouver ces données Cet attribut est dérivé, généralement par concaténation de champs de la table BKPF : code société (BUKRS), numéro de document (BELNR) et exercice (GJAHR). Exemples 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Nom de l’activité ActivityName | Nom de l’activité métier ou de l’événement survenu à une étape précise du processus de traitement des écritures comptables. | ||
| Description Le nom de l’activité désigne une étape précise du cycle de vie d’une écriture comptable, comme « Écriture comptable créée », « Écriture comptable approuvée » ou « Écriture comptable comptabilisée ». Cet attribut est généralement dérivé de plusieurs sources SAP, notamment les codes de transaction (TCODE), les journaux de modifications (tables CDHDR et CDPOS) et les champs de statut des documents. L’analyse des activités est au cœur du Process Mining. Elle permet de visualiser les cartes de processus, de calculer les temps de transition entre les étapes et de repérer les boucles de reprise, par exemple lorsqu’une « Écriture comptable rejetée » est suivie d’une « Écriture comptable corrigée ». Ces données sont essentielles aux Dashboards consacrés aux temps de cycle, aux taux de reprise et aux variantes du processus. Pourquoi est-ce important ? Cet attribut définit les étapes de la carte de processus et permet de visualiser, d’analyser et d’optimiser le flux de travail de traitement des écritures comptables. Où trouver ces données Cet attribut est dérivé de plusieurs sources, notamment les codes de transaction de BKPF (TCODE), le statut des documents, les journaux du flux de travail dans des tables comme SWW_WI2OBJ ou les journaux de modifications dans CDHDR et CDPOS. Exemples Écriture comptable crééeÉcriture comptable approuvéeÉcriture comptable rejetéeÉcriture comptable comptabilisée | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage de la dernière extraction ou actualisation des données depuis le système source. | ||
| Description Cet attribut indique la date et l’heure de la dernière extraction des données depuis SAP ECC. Ce champ de métadonnées est essentiel pour connaître l’actualité des données analysées. Dans un Dashboard ou une analyse de Process Mining, connaître la date de la dernière mise à jour aide les utilisateurs à se fier aux données et à prendre des décisions éclairées. Cet attribut répond à la question : « Ces informations sont-elles à jour ? » Pourquoi est-ce important ? Indique aux utilisateurs si les données sont à jour, afin qu’ils connaissent la période couverte par l’analyse et puissent se fier aux résultats. Où trouver ces données Ce champ de métadonnées est généré et enregistré par l’outil d’extraction des données ou le processus ETL lors de leur actualisation. Exemples 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| Système source SourceSystem | Système à partir duquel les données du processus ont été extraites. | ||
| Description Cet attribut indique l’origine des données, en l’occurrence l’instance SAP ECC concernée. Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction des données. Même simple, cet attribut est important lorsque l’environnement comprend plusieurs ERP ou sources de données. Il assure la traçabilité des données et permet de filtrer ou de segmenter l’analyse selon le système d’origine. Pourquoi est-ce important ? Cet attribut assure la traçabilité des données et permet de suivre leur qualité, notamment lorsque plusieurs systèmes sources sont utilisés. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de la transformation des données pour identifier l’instance SAP ECC concernée, par exemple 'ECC_PROD_100'. Exemples SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Code de transaction TransactionCode | Code de transaction SAP utilisé pour créer ou traiter l’écriture comptable. | ||
| Description Le code de transaction (T-Code) est un identifiant unique associé à une fonction ou à un programme SAP. Pour les écritures comptables, il indique comment l’écriture a été créée, par exemple manuellement (FB01, F-02), par mise en attente (FV50) ou au moyen d’une interface automatisée. Cet attribut est particulièrement utile pour le Dashboard « Optimisation des activités manuelles ». L’analyse du T-Code permet de distinguer les activités manuelles des activités automatisées, de repérer les processus manuels les plus longs et de déterminer où l’automatisation pourrait réduire le travail manuel et améliorer l’efficacité. Pourquoi est-ce important ? Permet de distinguer les processus manuels des processus automatisés, et de repérer les possibilités d’automatisation et de standardisation. Où trouver ces données Se trouve dans le champ TCODE de la table d’en-tête des documents BKPF. Exemples FB01F-02FV50FBD1 | |||
| Code société CompanyCode | Unité organisationnelle représentant une entité juridique indépendante pour laquelle des états financiers sont établis. | ||
| Description Le code société est une unité organisationnelle fondamentale de SAP Financials. Il représente une société juridiquement indépendante et constitue un champ clé de l’en-tête d’une écriture comptable. Cet attribut est essentiel pour segmenter l’analyse des processus par entité juridique. Il permet de comparer les performances des processus, les taux de conformité et les résultats des indicateurs entre différentes parties de l’entreprise. Vous pouvez, par exemple, déterminer si les retards d’approbation ou les taux élevés de contrepassation concernent certains codes société en particulier. Pourquoi est-ce important ? Permet de filtrer et de comparer les performances des processus entre les différentes entités juridiques ou unités opérationnelles de l’organisation. Où trouver ces données Se trouve dans le champ BUKRS de la table d’en-tête des documents BKPF. Exemples 10002000US01DE01 | |||
| Contrepassée IsReversed | Indicateur booléen précisant si l’écriture comptable a été contrepassée. | ||
| Description Cet indicateur signale les pièces comptables qui ont ensuite été contrepassées par une autre pièce. Dans SAP, la pièce contrepassée est liée à la pièce de contrepassation, ce qui permet de suivre clairement les opérations à des fins d’audit. Cet attribut est essentiel au Dashboard « Analyse des contrepassations de pièces comptables » et au KPI « Taux de contrepassation des pièces comptables ». Il permet d’isoler les pièces contrepassées afin d’en rechercher les causes, par exemple des erreurs de saisie ou des traitements comptables incorrects, et de réduire la fréquence des contrepassations. Pourquoi est-ce important ? Permet d’analyser directement les contrepassations en signalant les pièces annulées par la suite, afin d’identifier les causes des erreurs et d’améliorer l’intégrité des données. Où trouver ces données Dérivé du champ du numéro de la pièce de contrepassation (STBLG) dans la table BKPF. Si STBLG n’est pas vide, l’indicateur est vrai. Exemples truefalse | |||
| Date de comptabilisation PostingDate | Date à laquelle la transaction est enregistrée dans le grand livre et affecte la période financière. | ||
| Description La date de comptabilisation détermine la période comptable dans laquelle l’écriture est enregistrée. Elle est importante du point de vue financier et de la conformité : elle doit respecter le calendrier de clôture des périodes comptables et les réglementations applicables. Dans le cadre du Process Mining, cette date sert au suivi de la conformité. Le Dashboard « Suivi du respect des exigences de conformité » et l’indicateur « Taux de conformité » utilisent cet attribut pour vérifier si les écritures sont comptabilisées dans la bonne période. Il permet également d’analyser l’évolution du volume d’écritures comptables au fil du temps. Pourquoi est-ce important ? Indispensable au reporting financier et à l’analyse de conformité, cet attribut permet de vérifier que les écritures sont comptabilisées dans la bonne période comptable. Où trouver ces données Se trouve dans le champ BUDAT de la table d’en-tête des documents BKPF. Exemples 2023-10-312023-11-302024-01-15 | |||
| Type de document DocumentType | Catégorie de document comptable qui détermine son traitement et son enregistrement. | ||
| Description Le type de document distingue les différentes catégories de transactions métier, comme une écriture au grand livre (SA), une facture fournisseur (KR) ou une comptabilisation d’immobilisation (AA). Il est défini lors de la configuration du système et attribué à chaque écriture comptable. Cet attribut est important pour l’analyse, car il permet de segmenter le processus selon la nature de la transaction. Le Dashboard « Volume d’écritures comptables par type » et l’indicateur « Temps de cycle moyen par type d’écriture comptable » reposent directement sur ce champ. Il aide à déterminer si certains types d’écritures sont davantage sujets aux retards, aux reprises ou aux contrepassations. Pourquoi est-ce important ? Permet de segmenter l’analyse par type de transaction et de déterminer si certains types d’écritures comptables sont particulièrement concernés par des problèmes de processus. Où trouver ces données Se trouve dans le champ BLART de la table d’en-tête des documents BKPF. Exemples SAKRREAA | |||
| Utilisateur User | Identifiant de l’utilisateur SAP qui a créé ou modifié l’écriture comptable. | ||
| Description Cet attribut indique le nom d’utilisateur SAP associé à une activité donnée, comme la création, la mise en attente ou la comptabilisation d’un document. Il provient directement de l’en-tête du document ou des tables de journaux de modifications. L’analyse de l’attribut Utilisateur permet de mieux comprendre les performances des équipes et des personnes. Elle alimente le Dashboard de productivité des utilisateurs en suivant les volumes d’activité et les temps de traitement par utilisateur. Elle aide également à repérer les personnes concernées par des boucles de reprise, des contrepassations ou des écarts de conformité, afin de cibler les formations ou les améliorations du processus. Pourquoi est-ce important ? Identifie l’utilisateur associé à chaque activité et permet d’analyser ses performances, la répartition de la charge de travail et les schémas de reprise. Où trouver ces données Provient généralement de la table BKPF (champ USNAM pour le créateur) ou de la table CDHDR (champ USERNAME pour la personne ayant effectué la modification). Exemples ABROWNCJONESDSMITH | |||
| Centre de coûts CostCenter | Unité organisationnelle d’un périmètre analytique qui représente un lieu où des coûts sont engagés. | ||
| Description Le centre de coûts est une donnée de base importante du module de contrôle de gestion (CO), souvent affectée au niveau du poste de la pièce comptable. Il sert à suivre les coûts d’un service, d’une fonction ou d’un site donné. L’inclusion du centre de coûts permet d’analyser plus finement le processus de traitement des pièces comptables. Elle aide à déterminer si certains services génèrent davantage de reprises, ont des temps de cycle plus longs ou sont responsables d’un plus grand nombre de saisies manuelles. Vous pouvez ainsi évaluer l’efficacité du processus par service. Pourquoi est-ce important ? Permet d’analyser la performance du processus par service ou domaine fonctionnel et de repérer les inefficacités locales. Où trouver ces données Se trouve dans le champ KOSTL de la table des postes de pièces BSEG. Exemples 4100CC_FINANCE_US10010101 | |||
| Code devise CurrencyKey | Code de la devise des montants enregistrés dans la pièce comptable. | ||
| Description Cet attribut indique la devise de la pièce comptable, par exemple USD, EUR ou JPY. Il permet de contextualiser les montants financiers associés à la pièce. Même si elle ne constitue pas toujours un axe d’analyse principal, la devise est indispensable pour interpréter correctement les valeurs monétaires. Elle permet aussi de segmenter les analyses dans les organisations internationales et de comparer les processus selon que les pièces sont libellées en devise étrangère ou locale. Pourquoi est-ce important ? Fournit le contexte nécessaire à l’interprétation des valeurs monétaires et à la précision des analyses financières. Où trouver ces données Se trouve dans le champ WAERS de la table d’en-tête des pièces BKPF. Exemples USDEURGBPJPY | |||
| Comporte des reprises IsRework | Indicateur booléen précisant si une pièce comptable a suivi une boucle de reprise, par exemple après avoir été rejetée puis corrigée. | ||
| Description Cet indicateur signale les cas qui s’écartent du parcours nominal et nécessitent une correction. Il prend généralement la valeur vrai lorsqu’une séquence d’activités telle que « Pièce comptable rejetée », puis « Pièce comptable corrigée », est observée pour une pièce donnée. Cet attribut est essentiel au calcul du KPI « Taux de reprises des pièces comptables » et à l’analyse du Dashboard « Taux de reprises et de rejets ». Il permet de mesurer l’ampleur des inefficacités du processus et de rechercher les causes des reprises, comme des exigences imprécises ou une documentation insuffisante. Pourquoi est-ce important ? Signale les pièces qui ont nécessité une correction, afin de mesurer les reprises et d’en rechercher les causes pour améliorer le taux de traitement correct dès la première fois. Où trouver ces données Attribut calculé à partir de l’analyse de la séquence d’activités d’un cas. Une boucle de reprise est détectée lorsqu’une activité de rejet ou de correction apparaît. Exemples truefalse | |||
| Délai d’approbation ApprovalTime | Temps écoulé entre la soumission d’une pièce comptable pour approbation et son approbation ou son rejet. | ||
| Description Cette métrique mesure la durée du sous-processus d’approbation, qui contribue souvent de manière importante au temps de cycle global. Elle correspond à l’écart entre l’activité « Pièce comptable soumise » et l’activité correspondante « Pièce comptable approuvée » ou « Pièce comptable rejetée ». Le délai d’approbation est la métrique principale du Dashboard « Performance de l’approbation des pièces comptables » et du KPI « Délai moyen d’approbation des pièces comptables ». Son analyse permet de repérer les goulots d’étranglement dans le flux de travail d’approbation, de mesurer les délais des approbateurs et d’étayer des changements de processus, comme l’ajustement des seuils d’approbation. Pourquoi est-ce important ? Mesure la durée de l’étape d’approbation et aide à repérer puis à réduire les retards lors de la vérification et de l’approbation. Où trouver ces données Calculé en soustrayant l’horodatage de l’événement « Pièce comptable soumise » de celui de l’événement « Pièce comptable approuvée » ou « Pièce comptable rejetée ». Exemples P1DT2HPT4H15MP3D | |||
| Est en attente IsParked | Indicateur booléen précisant si la pièce comptable a été enregistrée comme pièce préenregistrée avant sa comptabilisation. | ||
| Description Le préenregistrement permet à un utilisateur d’enregistrer une pièce comptable incomplète sans modifier les soldes financiers. Un autre utilisateur peut ensuite la compléter ou la vérifier avant sa comptabilisation. Cet indicateur signale les pièces qui sont passées par une étape de préenregistrement. L’analyse de cet attribut permet de mieux comprendre l’utilisation de cette fonctionnalité. Elle peut révéler que le préenregistrement sert d’étape de vérification informelle et entraîne éventuellement des retards. Elle permet aussi d’analyser le temps de cycle de bout en bout en distinguant les pièces comptabilisées directement de celles qui ont d’abord été préenregistrées. Pourquoi est-ce important ? Signale les pièces passées par l’étape de préenregistrement, qui peut entraîner des retards ou indiquer l’existence d’une vérification informelle. Où trouver ces données Dérivé du champ de statut de la pièce (BSTAT) dans la table BKPF. La valeur « V » indique une pièce préenregistrée. Exemples truefalse | |||
| Montant total du document TotalDocumentAmount | Valeur totale de l’écriture comptable dans la devise du document. | ||
| Description Cet attribut représente la valeur financière totale de l’écriture comptable. Il est généralement calculé en additionnant les valeurs absolues de tous les postes au débit ou au crédit associés au document. L’analyse du processus selon la valeur financière peut révéler des tendances importantes. Par exemple, les écritures de montant élevé peuvent suivre un parcours d’approbation différent et plus strict. Cet attribut permet de filtrer ou de segmenter l’analyse pour vérifier si les temps de cycle, les taux de rejet ou les retards d’approbation sont liés au montant de l’écriture. Pourquoi est-ce important ? Permet d’analyser l’incidence financière, par exemple en comparant les temps de traitement ou les taux de rejet à la valeur monétaire des écritures comptables. Où trouver ces données Il s’agit d’un champ calculé, obtenu en agrégeant le montant (WRBTR ou DMBTR) de tous les postes de la table BSEG pour une écriture comptable donnée. Exemples 1500.0025000.75125.50 | |||
| Motif de contrepassation ReversalReason | Code indiquant le motif de la contrepassation d’une pièce comptable. | ||
| Description Lorsqu’une pièce est contrepassée, SAP permet à l’utilisateur de préciser un code de motif. Ce code fournit des informations structurées sur la raison de la contrepassation, par exemple une date comptable incorrecte ou une erreur de saisie. Cet attribut est une donnée clé du Dashboard « Analyse des contrepassations de pièces comptables ». L’analyse des motifs les plus fréquents aide les organisations à repérer les problèmes récurrents dans leurs processus ou les lacunes de formation, puis à prendre des mesures ciblées pour éviter de nouvelles erreurs et réduire le taux de contrepassation. Pourquoi est-ce important ? Indique directement les raisons des contrepassations et permet d’en rechercher les causes afin de réduire les erreurs à l’avenir. Où trouver ces données Se trouve dans le champ STGRD de la table d’en-tête des pièces BKPF. Exemples 010205 | |||
Activités du processus de la comptabilisation au reporting : pièces comptables
| Activité | Description | ||
|---|---|---|---|
| Contrepassation d’écriture comptable traitée | Cette activité marque la contrepassation d’une écriture comptable précédemment comptabilisée. Une contrepassation est un nouveau document comptable qui annule l’écriture d’origine. | ||
| Pourquoi est-ce important ? Cet événement est important pour mesurer la qualité des données et l’exactitude du processus. Un taux élevé de contrepassations révèle des problèmes récurrents lors de la saisie initiale ou des étapes d’approbation. Chaque contrepassation entraîne une reprise. Où trouver ces données Cet événement est identifié dans l’en-tête du document d’origine (table BKPF). Lorsqu’un document est contrepassé, SAP renseigne le numéro du document de contrepassation (BKPF-STBLG) et le motif de contrepassation (BKPF-STGRD). L’horodatage de l’événement correspond à la date de comptabilisation du nouveau document de contrepassation. Données à recueillir Repérez le renseignement de BKPF-STBLG dans le document d’origine. L’horodatage correspond à la date de comptabilisation du document de contrepassation. Type d’événement explicit | |||
| Écriture comptable approuvée | Cette activité marque l’approbation finale d’une écriture comptable dans un flux de travail, qui peut alors être comptabilisée. L’événement est extrait du journal du flux de travail lorsque la dernière étape de type « libérer » ou « approuver » est terminée. | ||
| Pourquoi est-ce important ? Ce jalon marque la fin du processus d’approbation. Le délai jusqu’à cette étape est un indicateur important de l’efficacité des approbations. Le temps écoulé entre cet événement et la comptabilisation mesure le retard après approbation. Où trouver ces données L’événement est déduit de l’horodatage de fin de l’étape d’approbation finale dans le journal SAP Business Workflow. Il s’agit de la dernière action d’approbation avant la comptabilisation du document ou sa mise à disposition pour comptabilisation. Données à recueillir Repérez la fin de la dernière étape de type « libérer » ou « approuver » dans les journaux du flux de travail. Type d’événement inferred | |||
| Écriture comptable comptabilisée | Cette activité centrale correspond à l’enregistrement officiel de l’écriture comptable dans le grand livre, avec une incidence sur les états financiers. SAP enregistre explicitement cet événement lorsque le statut du document passe à « comptabilisé » et qu’une date de comptabilisation lui est attribuée. | ||
| Pourquoi est-ce important ? Ce jalon, le plus important, marque le traitement réussi de l’écriture comptable. Le temps de cycle de bout en bout est souvent mesuré jusqu’à cette étape, qui joue également un rôle clé dans l’analyse de la clôture financière. Où trouver ces données L’événement est identifié lorsqu’une date de comptabilisation (BKPF-BUDAT) figure dans la table BKPF pour un document. Pour les documents mis en attente, il correspond au moment où le statut BKPF-BSTAT passe de 'V' à une valeur vide. L’horodatage de la comptabilisation est la date de saisie BKPF-CPUDT. Données à recueillir Repérez le passage de BKPF-BSTAT de 'V' à une valeur vide ou, pour les comptabilisations directes, l’événement de création. Type d’événement explicit | |||
| Écriture comptable mise en attente | Cette activité correspond à la création initiale d’une écriture comptable à l’état provisoire, avant sa comptabilisation officielle dans le grand livre. SAP enregistre explicitement cette étape lorsqu’un utilisateur enregistre un document à l’aide d’une transaction de mise en attente, ce qui lui attribue le statut « en attente ». | ||
| Pourquoi est-ce important ? Il s’agit d’un événement de début important pour les processus qui comportent une étape d’examen et d’approbation. L’analyse du délai entre la mise en attente et la comptabilisation permet de repérer les retards avant comptabilisation et pendant l’approbation. Où trouver ces données Cet événement est identifié à partir de la table d’en-tête des documents BKPF. Un document est considéré comme mis en attente lorsque son statut est BKPF-BSTAT = 'V'. L’horodatage de l’événement correspond à la date et à l’heure de création, BKPF-CPUDT et BKPF-CPUTM. Données à recueillir Repérez la création du document dans BKPF lorsque BKPF-BSTAT vaut 'V'. Type d’événement explicit | |||
| Écriture comptable soumise | Cette activité indique que le créateur a finalisé une écriture comptable mise en attente et que celle-ci est prête à être examinée et approuvée. Elle est généralement enregistrée au démarrage d’une tâche SAP Business Workflow associée au document mis en attente. | ||
| Pourquoi est-ce important ? Cette étape marque le passage du créateur à l’approbateur et lance le calcul des indicateurs de temps de cycle d’approbation. C’est un jalon important pour mesurer l’efficacité du flux de travail d’approbation. Où trouver ces données L’événement est déduit de l’heure de début de l’instance de flux de travail d’approbation liée à l’objet du document financier. Il faut pour cela analyser les tables de journal du flux de travail, comme SWW_WI2OBJ, afin de repérer le flux de travail lancé pour la société, le numéro de document et l’exercice concernés. Données à recueillir Repérez l’événement de début du flux de travail pour l’objet du document mis en attente. Type d’événement inferred | |||
| Comptabilisation intersociétés identifiée | Cette activité calculée signale une écriture comptable qui concerne plusieurs sociétés. Elle est déterminée par l’analyse des postes d’un même document financier. | ||
| Pourquoi est-ce important ? Les transactions intersociétés peuvent nécessiter un traitement et des approbations plus complexes. Les repérer permet d’analyser séparément leurs temps de cycle et leurs parcours afin d’identifier les goulots d’étranglement qui leur sont propres. Où trouver ces données Le résultat est calculé en examinant la table des postes BSEG pour un numéro de document donné (BELNR). Si les postes contiennent plusieurs codes société distincts (BSEG-BUKRS), il s’agit d’une comptabilisation intersociétés. Données à recueillir Vérifiez si plusieurs valeurs distinctes de BSEG-BUKRS existent pour un même BKPF-BELNR. Type d’événement calculated | |||
| Écriture comptable corrigée | Cette activité indique que le créateur initial a modifié une écriture comptable mise en attente après son renvoi pour correction. Elle est déduite de la détection de modifications apportées au document après l’événement « Modifications demandées ». | ||
| Pourquoi est-ce important ? Le suivi des corrections permet de quantifier le travail consacré aux reprises. Le délai entre une demande de modification et la correction met en évidence les retards dans la résolution des problèmes liés aux écritures soumises. Où trouver ces données L’événement est déduit de l’analyse des journaux de modifications (tables CDHDR et CDPOS) du document mis en attente. Une modification enregistrée après un événement de rejet dans le flux de travail indique qu’une correction a été apportée. L’horodatage provient de la table CDHDR. Données à recueillir Repérez une entrée dans le journal des modifications CDHDR/CDPOS après un événement de rejet. Type d’événement inferred | |||
| Écriture comptable créée | Cette activité correspond à la création d’une écriture comptable directement comptabilisée, sans étape préalable de mise en attente. SAP l’enregistre lorsqu’un document est créé à l’aide d’une transaction de comptabilisation directe. | ||
| Pourquoi est-ce important ? Cette activité constitue un point de départ alternatif pour les processus d’écriture comptable simples qui ne nécessitent pas de flux de travail d’approbation. Elle permet de distinguer les comptabilisations directes simples des écritures plus complexes mises en attente. Où trouver ces données Cet événement correspond à la création d’un document dans la table BKPF lorsque le statut BKPF-BSTAT est vide (document comptabilisé). Son horodatage est la date de création, BKPF-CPUDT. Pour ces documents, les événements « Création » et « Comptabilisation » ont lieu simultanément. Données à recueillir Repérez la création du document dans BKPF lorsque BKPF-BSTAT est vide. Type d’événement explicit | |||
| Écriture comptable mise en attente supprimée | Cette activité correspond à la suppression d’une écriture comptable mise en attente qui n’a jamais été comptabilisée. Cela peut se produire après un rejet ou si l’écriture a été créée par erreur. | ||
| Pourquoi est-ce important ? Cette activité marque l’échec du processus. L’analyse des raisons de la suppression des documents mis en attente peut révéler des problèmes tels que des doublons ou une mauvaise compréhension du processus. Où trouver ces données Cet événement est enregistré lorsque le statut d’un document mis en attente dans la table BKPF est modifié. Le champ de statut BKPF-BSTAT prend alors la valeur 'Z' (document mis en attente supprimé). L’horodatage de la modification figure dans les journaux de modifications des documents (CDHDR). Données à recueillir Repérez le passage de BKPF-BSTAT à 'Z'. Type d’événement explicit | |||
| Écriture comptable rejetée | Cette activité indique le rejet définitif d’une écriture comptable, qui ne sera alors pas comptabilisée. Il s’agit généralement d’un statut terminal dans un flux de travail d’approbation, suivi de la suppression du document mis en attente. | ||
| Pourquoi est-ce important ? Le suivi des rejets est essentiel à la gestion de la qualité. L’analyse de leurs motifs et de leur fréquence permet d’améliorer le taux d’écritures comptables correctes dès la première soumission. Où trouver ces données Ce résultat est extrait du journal SAP Business Workflow. Il correspond à une décision finale de l’utilisateur de type « rejeter », qui met fin au processus. Le document mis en attente peut ensuite être supprimé. Données à recueillir Repérez le statut terminal « rejet » dans le journal du flux de travail associé au document. Type d’événement inferred | |||
| Modifications demandées sur l’écriture comptable | Cette étape du flux de travail correspond à l’examen de l’écriture comptable par un approbateur, qui la renvoie au créateur pour correction. L’événement est extrait des journaux du flux de travail, où figure une décision utilisateur de type « rejet » ou « renvoi ». | ||
| Pourquoi est-ce important ? Cette activité est essentielle pour repérer les boucles de reprise, qui sont une source importante d’inefficacité et d’écarts dans le processus. Si elle se produit fréquemment, cela peut révéler des problèmes de qualité des écritures ou des exigences peu claires. Où trouver ces données Cet événement est déduit de l’horodatage d’une étape de décision précise dans le journal SAP Business Workflow, correspondant à une action de type « rejeter » ou « renvoyer pour correction ». Données à recueillir Repérez l’horodatage d’une décision de type « rejet » ou « reprise » dans les journaux du flux de travail. Type d’événement inferred | |||
| Pièces justificatives jointes | Cette activité correspond à l’ajout par un utilisateur de pièces justificatives, comme des factures ou des feuilles de calcul, à une écriture comptable. Cet événement n’est pas consigné explicitement comme un événement comptable standard. Il est généralement déduit de la création de pièces jointes liées à l’objet du document comptable. | ||
| Pourquoi est-ce important ? Le suivi de cette activité permet de vérifier le respect des politiques qui imposent de fournir des pièces justificatives. Un retard dans leur ajout peut prolonger le cycle d’approbation. Où trouver ces données Il est difficile de capturer cet événement de manière fiable avec un horodatage. Il peut éventuellement être déduit de l’analyse des tables de pièces jointes Generic Object Services (GOS), comme SOOD, en reliant l’horodatage de création de la pièce jointe à la clé de l’objet d’écriture comptable. Données à recueillir Déduisez l’événement de l’horodatage de création des objets associés dans les tables GOS, par exemple SOOD. Type d’événement inferred | |||
| Poste d’écriture comptable lettré | Cette activité correspond au rapprochement d’un poste d’un compte général géré par postes non soldés, comme un compte d’attente bancaire. Elle a lieu lorsqu’un poste est rapproché d’un autre et soldé. | ||
| Pourquoi est-ce important ? Dans les processus tels que le rapprochement bancaire, le délai de lettrage des postes est un indicateur important. Cette activité permet d’analyser l’efficacité du rapprochement et des procédures de clôture mensuelle. Où trouver ces données Cet événement est extrait de la table des postes BSEG. Lorsqu’un poste est lettré, les champs de date de lettrage (BSEG-AUGDT) et de document de lettrage (BSEG-AUGBL) sont renseignés. L’horodatage de l’événement correspond à la date de lettrage. Données à recueillir Repérez le renseignement de la date de lettrage (BSEG-AUGDT) pour un poste. Type d’événement explicit | |||
| Saisie manuelle identifiée | Cette activité permet de déterminer si une écriture comptable a été créée au moyen d’une transaction en ligne saisie manuellement, plutôt que par une interface automatisée ou un traitement par lots. Il ne s’agit pas d’une action utilisateur, mais d’un attribut calculé à partir des données du système. | ||
| Pourquoi est-ce important ? Distinguer les écritures manuelles des écritures automatisées est essentiel pour cibler les améliorations du processus. Les processus manuels sont souvent concernés par les initiatives de standardisation et d’automatisation. Où trouver ces données Ce résultat est calculé à partir de l’analyse des champs de la table d’en-tête des documents BKPF. Les codes de transaction (BKPF-TCODE) tels que 'FB01', 'FB50' ou 'FV50' indiquent une saisie manuelle, tandis que d’autres codes T ou certains noms de saisie par lots (BKPF-AWKEY) suggèrent un traitement automatisé. Données à recueillir Déduisez l’information de BKPF-TCODE ou d’autres indicateurs du système source figurant dans l’en-tête du document. Type d’événement calculated | |||
Guides d’extraction
Étapes
- Créez le programme ABAP : Dans le système SAP, ouvrez le code de transaction SE38 (éditeur ABAP). Saisissez un nom pour le nouveau programme, par exemple Z_PM_JE_EXTRACTION, puis cliquez sur Créer. Donnez-lui un titre approprié et définissez son type comme « Programme exécutable ».
- Définissez l’écran de sélection : Dans le code source du programme, définissez l’écran de sélection. Les utilisateurs pourront ainsi préciser des paramètres, comme une plage de dates de création des pièces, des codes société et des types de pièce, afin de limiter le volume de données à extraire.
- Déclarez les structures de données : Définissez une structure de table interne qui contiendra le journal d’événements final. Elle doit inclure tous les champs requis : JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, ainsi que les attributs recommandés, comme User, CompanyCode et PostingDate.
- Mettez en place la logique de sélection des données : Rédigez les requêtes SQL ABAP nécessaires pour extraire les données correspondant aux 14 activités requises. Il s’agit notamment de sélectionner des données dans les tables principales BKPF (en-tête) et BSEG (poste), les tables de journal des modifications CDHDR et CDPOS, les tables de flux de travail telles que SWWLOGHIST et les tables de compensation telles que BSAS et BSAK.
- Extrayez les pièces préenregistrées et comptabilisées : Pour les événements « Pièce comptable préenregistrée », sélectionnez dans BKPF les pièces dont le statut (BSTAT) est « V ». Pour les événements « Pièce comptable créée » et « Pièce comptable comptabilisée », sélectionnez dans BKPF les pièces dont le statut est vide, ce qui indique une pièce normale comptabilisée.
- Extrayez les événements de modification et de suppression : Interrogez les tables de pièces de modification CDHDR et CDPOS pour la classe d’objet « BELEG ». Filtrez sur la clé de pièce afin de repérer les modifications correspondant aux activités « Pièce comptable corrigée » ou « Pièce comptable préenregistrée supprimée ».
- Extrayez les événements du flux de travail : Pour enregistrer des activités telles que « Pièce comptable soumise », « Approuvée », « Rejetée » et « Modifications demandées », interrogez les tables du flux de travail. Utilisez la table SWW_WI2OBJ pour relier la pièce comptable à une instance du flux de travail, puis consultez SWWLOGHIST pour obtenir les décisions des utilisateurs ou les changements de statut.
- Repérez les événements calculés : Pour l’activité « Saisie manuelle détectée », comparez le code de transaction (BKPF-TCODE) à une liste de codes de transaction connus pour les saisies manuelles. Pour l’activité « Comptabilisation intersociétés détectée », examinez les postes BSEG d’une pièce afin de déterminer si plusieurs codes société sont concernés.
- Consolidez et transformez les données : À mesure que vous sélectionnez les données de chaque activité, convertissez-les au format du journal d’événements final. Concaténez le code société, le numéro de pièce et l’exercice pour créer JournalEntryId. Convertissez les dates et heures SAP en un horodatage EventTime unique. Ajoutez les résultats de chaque requête à la table interne finale.
- Mettez en place l’exportation du fichier : Utilisez les instructions de gestion des fichiers ABAP, comme OPEN DATASET, LOOP AT, TRANSFER et CLOSE DATASET, pour écrire la table interne consolidée dans un fichier CSV ou texte brut, dans un répertoire du serveur d’applications SAP (consultable avec la transaction AL11).
- Planifiez l’exécution en tâche de fond : Ouvrez la transaction SM36 (définition des tâches de fond). Créez une tâche, définissez une étape qui exécute votre programme ABAP et planifiez son exécution, par exemple chaque nuit ou chaque semaine en dehors des heures de pointe, afin d’automatiser l’extraction.
- Récupérez et formatez le fichier : Utilisez la transaction CG3Y ou demandez à votre administrateur système de télécharger le fichier généré depuis le serveur d’applications vers votre poste. Vérifiez que l’encodage et le format du fichier conviennent à son importation dans votre outil de Process Mining.
Configuration
- Plage de dates : Il est essentiel de définir une plage de dates pour maîtriser les performances. Utilisez la date de création de la pièce (BKPF-CPUDT) comme filtre principal. Pour une première analyse, une période de 3 à 6 mois est recommandée. Pour les tests, choisissez une plage de quelques jours dont vous savez qu’elle contient des données.
- Filtre sur le code société : Filtrez toujours par code société (BKPF-BUKRS). L’extraction simultanée des données de tous les codes société peut consommer énormément de ressources. Commencez par un seul code société ou par un petit groupe de codes pertinents.
- Filtre sur le type de pièce : Utilisez le filtre sur le type de pièce (BKPF-BLART) pour limiter l’analyse à certains types de pièces comptables, par exemple « SA » pour les pièces du grand livre, si vous n’avez pas besoin d’analyser tous les types.
- Identifiants des tâches du flux de travail : L’extraction des événements du flux de travail dépend des identifiants de tâche utilisés dans votre système pour l’approbation, le rejet et la soumission. Ils doivent être définis dans le code source du programme selon les paramètres du flux de travail de votre entreprise.
- Performances : Le programme joint plusieurs tables volumineuses, notamment CDPOS et les tables d’historique du flux de travail. Son exécution pendant les heures de pointe peut ralentir le système. Planifiez-la toujours comme tâche de fond en dehors des heures de pointe. Si les problèmes de performance se répètent, envisagez de créer des index secondaires dans la base de données.
- Prérequis : Cette méthode nécessite un utilisateur disposant des autorisations de développement ABAP (pour SE38) et des droits nécessaires à la création et à la gestion de tâches de fond (pour SM36). Cet utilisateur ou la tâche doit également avoir un accès en lecture à toutes les tables financières, de flux de travail et système pertinentes (BKPF, BSEG, CDHDR, CDPOS, SWWLOGHIST, etc.).
Exemple de requête abap
REPORT Z_PM_JE_EXTRACTION.
*&---------------------------------------------------------------------*
*& Data Structures for Final Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
username TYPE uname,
companycode TYPE bukrs,
documenttype TYPE blart,
postingdate TYPE budat,
transactioncode TYPE tcode,
isreversed TYPE abap_bool,
END OF ty_event_log.
DATA: lt_final_log TYPE STANDARD TABLE OF ty_event_log.
DATA: ls_event TYPE ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen Parameters
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_blart FOR bkpf-blart,
s_cpudt FOR bkpf-cpudt OBLIGATORY.
PARAMETERS: p_sysid TYPE sy-sysid DEFAULT sy-sysid.
*&---------------------------------------------------------------------*
*& Main Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
DATA(lv_last_update) = cl_abap_context_info=>get_system_timestamp( ).
" 1. Journal Entry Parked
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
'Journal Entry Parked' AS activityname,
a~cpudt, a~cputm,
a~usnam AS username,
a~bukrs AS companycode,
a~blart AS documenttype,
a~bldat AS postingdate,
a~tcode AS transactioncode
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~bstat = 'V' " Parked Document
INTO TABLE @DATA(lt_parked).
IF sy-subrc = 0.
LOOP AT lt_parked ASSIGNING FIELD-SYMBOL(<fs_parked>).
ls_event-journalentryid = <fs_parked>-journalentryid.
ls_event-activityname = <fs_parked>-activityname.
CONVERT DATE <fs_parked>-cpudt TIME <fs_parked>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_parked>-username.
ls_event-companycode = <fs_parked>-companycode.
ls_event-documenttype = <fs_parked>-documenttype.
ls_event-postingdate = <fs_parked>-postingdate.
ls_event-transactioncode = <fs_parked>-transactioncode.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 2. Journal Entry Created (directly posted, not parked first)
" 9. Journal Entry Posted
" These two events happen at the same time for a direct posting.
SELECT CONCAT( bukrs, belnr, gjahr ) AS journalentryid,
cpudt, cputm, usnam, bukrs, blart, budat, tcode, stblg
FROM bkpf
WHERE bukrs IN s_bukrs
AND blart IN s_blart
AND cpudt IN s_cpudt
AND bstat = '' " Normal, posted document
INTO TABLE @DATA(lt_posted).
IF sy-subrc = 0.
LOOP AT lt_posted ASSIGNING FIELD-SYMBOL(<fs_posted>).
" Activity: Journal Entry Created
ls_event-journalentryid = <fs_posted>-journalentryid.
ls_event-activityname = 'Journal Entry Created'.
CONVERT DATE <fs_posted>-cpudt TIME <fs_posted>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_posted>-usnam.
ls_event-companycode = <fs_posted>-bukrs.
ls_event-documenttype = <fs_posted>-blart.
ls_event-postingdate = <fs_posted>-budat.
ls_event-transactioncode = <fs_posted>-tcode.
ls_event-isreversed = COND #( WHEN <fs_posted>-stblg IS NOT INITIAL THEN abap_true ELSE abap_false ).
APPEND ls_event TO lt_final_log.
" Activity: Journal Entry Posted
ls_event-activityname = 'Journal Entry Posted'.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 3. Documentation Attached (via GOS)
SELECT a~instid_a, c~cr_timestamp
FROM srgbtbrel AS a
INNER JOIN sood AS b ON a~instid_b = b~objid
INNER JOIN socf AS c ON b~filid = c~filid
WHERE a~typeid_a = 'BKPF'
AND a~bukrs IN s_bukrs
INTO TABLE @DATA(lt_attachments).
IF sy-subrc = 0.
LOOP AT lt_attachments ASSIGNING FIELD-SYMBOL(<fs_attach>).
ls_event-journalentryid = |{ <fs_attach>-instid_a(4) }{ <fs_attach>-instid_a+4(10) }{ <fs_attach>-instid_a+14(4) }|.
ls_event-activityname = 'Documentation Attached'.
ls_event-eventtime = <fs_attach>-cr_timestamp.
" Other attributes may need to be looked up from BKPF if needed.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 4, 5, 6, 7, 8: Workflow events (Submitted, Changes Requested, Corrected, Approved, Rejected)
" This is a simplified example. Real logic depends on specific workflow templates.
SELECT a~instid, b~wi_cd, b~wi_ct, b~wi_aagent, b~wi_text
FROM sww_wi2obj AS a
INNER JOIN swwloghist AS b ON a~wi_id = b~wi_id
WHERE a~typeid = 'BKPF'
AND a~catid = 'BO'
AND a~bukrs IN s_bukrs
AND b~wi_cd BETWEEN s_cpudt-low AND s_cpudt-high
INTO TABLE @DATA(lt_workflow).
IF sy-subrc = 0.
LOOP AT lt_workflow ASSIGNING FIELD-SYMBOL(<fs_wf>).
ls_event-journalentryid = |{ <fs_wf>-instid(4) }{ <fs_wf>-instid+4(10) }{ <fs_wf>-instid+14(4) }|.
ls_event-activityname = CASE <fs_wf>-wi_text. " Simplified logic based on work item text
WHEN '[Placeholder for Submit Text]' THEN 'Journal Entry Submitted'
WHEN '[Placeholder for Approve Text]' THEN 'Journal Entry Approved'
WHEN '[Placeholder for Reject Text]' THEN 'Journal Entry Rejected'
WHEN '[Placeholder for Rework Text]' THEN 'Journal Entry Changes Requested'
ELSE ''
ENDCASE.
IF ls_event-activityname IS NOT INITIAL.
CONVERT DATE <fs_wf>-wi_cd TIME <fs_wf>-wi_ct INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_wf>-wi_aagent.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
ENDIF.
" 10. Manual Entry Identified & 11. Cross-Company Posting Identified
SELECT bukrs, belnr, gjahr, tcode FROM bkpf
WHERE bukrs IN s_bukrs AND blart IN s_blart AND cpudt IN s_cpudt
INTO TABLE @DATA(lt_calc_base).
LOOP AT lt_calc_base ASSIGNING FIELD-SYMBOL(<fs_calc>).
ls_event-journalentryid = |{ <fs_calc>-bukrs }{ <fs_calc>-belnr }{ <fs_calc>-gjahr }|.
" Check for manual entry T-Codes
IF <fs_calc>-tcode = 'FB01' OR <fs_calc>-tcode = 'F-02' OR <fs_calc>-tcode = 'FB50'.
ls_event-activityname = 'Manual Entry Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
" Check for cross-company posting
SELECT SINGLE bukrs FROM bseg WHERE belnr = <fs_calc>-belnr AND gjahr = <fs_calc>-gjahr AND bukrs <> <fs_calc>-bukrs INTO @DATA(lv_cross_bukrs).
IF sy-subrc = 0.
ls_event-activityname = 'Cross-Company Posting Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 12. Journal Entry Line Item Cleared
SELECT a~bukrs, a~belnr, a~gjahr, a~augdt, a~augbl
FROM bsas AS a " G/L Cleared Items
WHERE a~bukrs IN s_bukrs
AND a~budat IN s_cpudt
INTO TABLE @DATA(lt_cleared_gl).
IF sy-subrc = 0.
LOOP AT lt_cleared_gl ASSIGNING FIELD-SYMBOL(<fs_clr>).
ls_event-journalentryid = |{ <fs_clr>-bukrs }{ <fs_clr>-belnr }{ <fs_clr>-gjahr }|.
ls_event-activityname = 'Journal Entry Line Item Cleared'.
CONVERT DATE <fs_clr>-augdt INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
" User is often not directly available for clearing events
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 13. Parked Journal Entry Deleted & 6. Journal Entry Corrected
SELECT objectid, changenr, username, udate, utime FROM cdhdr
WHERE objectclas = 'BELEG'
AND udate IN s_cpudt
INTO TABLE @DATA(lt_cdhdr).
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
SELECT SINGLE tcode FROM cdpos WHERE changenr = <fs_cdhdr>-changenr AND fname = 'BSTAT' AND value_new = 'Z' INTO @DATA(lv_deleted_tcode).
ls_event-journalentryid = |{ <fs_cdhdr>-objectid(4) }{ <fs_cdhdr>-objectid+4(10) }{ <fs_cdhdr>-objectid+14(4) }|.
CONVERT DATE <fs_cdhdr>-udate TIME <fs_cdhdr>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_cdhdr>-username.
IF sy-subrc = 0.
ls_event-activityname = 'Parked Journal Entry Deleted'.
APPEND ls_event TO lt_final_log.
ELSE.
ls_event-activityname = 'Journal Entry Corrected'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 14. Journal Entry Reversal Processed
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
a~cpudt, a~cputm, a~usnam
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~stblg IS NOT NULL " Document is a reversal
INTO TABLE @DATA(lt_reversals).
IF sy-subrc = 0.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
ls_event-journalentryid = <fs_rev>-journalentryid.
ls_event-activityname = 'Journal Entry Reversal Processed'.
CONVERT DATE <fs_rev>-cpudt TIME <fs_rev>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_rev>-usnam.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" Final step: Output to file
DATA(lv_filename) = |/tmp/je_extraction_{ sy-datum }_{ sy-uzeit }.csv|.
OPEN DATASET lv_filename FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
" Write header
DATA(lv_header) = 'JournalEntryId,ActivityName,EventTime,SourceSystem,LastDataUpdate,User,CompanyCode,DocumentType,PostingDate,TransactionCode,IsReversed'.
TRANSFER lv_header TO lv_filename.
LOOP AT lt_final_log INTO ls_event.
DATA(lv_line) = |"{ ls_event-journalentryid }","|
|{ ls_event-activityname }","|
|{ ls_event-eventtime }","|
|{ ls_event-sourcesystem }","|
|{ ls_event-lastdataupdate }","|
|{ ls_event-username }","|
|{ ls_event-companycode }","|
|{ ls_event-documenttype }","|
|{ ls_event-postingdate }","|
|{ ls_event-transactioncode }","|
|{ ls_event-isreversed }"|.
TRANSFER lv_line TO lv_filename.
ENDLOOP.
CLOSE DATASET lv_filename.
ENDIF. Étapes
- Établissez la connexion à la base de données : Obtenez des identifiants en lecture seule pour la base de données SAP ECC. Utilisez un client SQL standard, comme DBeaver, SAP HANA Studio ou SQL Server Management Studio, pour vous connecter à la base de données.
- Préparez la requête SQL : Copiez dans votre client SQL la requête complète fournie dans la section « query » de ce document.
- Définissez les paramètres d’extraction : Avant l’exécution, configurez les espaces réservés de la requête. Remplacez « [START_DATE] » et « [END_DATE] » par la plage de dates souhaitée au format « YYYYMMDD ». Remplacez « [COMPANY_CODE_1] », « [COMPANY_CODE_2] » par les codes société SAP à analyser.
- Définissez le système source : Dans l’instruction principale
SELECT, remplacez l’espace réservé « [Your SAP System ID] » par l’identifiant réel du système SAP (SID) afin d’identifier correctement la source des données. - Exécutez la requête : Lancez la requête SQL configurée sur la base de données SAP. La durée d’exécution dépendra de la plage de dates et de la taille des tables de la base de données.
- Vérifiez les premiers résultats : Une fois la requête terminée, parcourez rapidement les lignes renvoyées pour vérifier que les données sont renseignées comme prévu. Assurez-vous que plusieurs activités sont présentes et que les champs clés, comme
JournalEntryIdetEventTime, ne sont pas vides. - Gérez les horodatages : La requête concatène les champs de date et d’heure dans une chaîne au format
YYYYMMDDHHMMSS. Vérifiez que votre système cible ou votre traitement ultérieur peut lire ce format. Sinon, adaptez la fonction SQLCONCATpour obtenir un format ISO 8601, commeYYYY-MM-DDTHH:MI:SS, si votre base de données le permet. - Exportez les données : Exportez l’ensemble des résultats de votre client SQL dans un 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 que les en-têtes de colonnes correspondent au schéma de données requis.
JournalEntryId,ActivityNameetEventTimesont indispensables. Ajoutez la colonneLastDataUpdateet renseignez-la avec l’horodatage de l’extraction. - Effectuez la validation finale : Suivez les étapes de la section « validationSteps » pour vérifier que les données extraites sont complètes et exactes avant de commencer l’analyse.
Configuration
- Autorisations sur la base de données : L’utilisateur de la base de données doit disposer d’un accès en lecture aux tables SAP suivantes : BKPF, BSEG, CDHDR, CDPOS, T001 et V_USERNAME. Pour les activités liées au flux de travail, l’accès à SWW_WI2OBJ et SWWLOGHIST est également nécessaire. Seules des équipes techniques spécialisées disposent généralement de ce niveau d’accès.
- Filtrage par plage de dates : Il est essentiel de filtrer les données selon une plage de dates précise pour préserver les performances des requêtes. La requête fournie utilise des espaces réservés pour les dates de début et de fin, appliqués à la date de création de la pièce (
BKPF.CPUDT). Pour une première analyse, une période de 3 à 6 mois est recommandée. - Filtrage par entité : Pour maîtriser le volume de données et cibler l’analyse, filtrez toujours par code société (
BKPF.BUKRS). Vous pouvez également filtrer par type de pièce (BKPF.BLART) pour ne retenir que les types de pièces comptables pertinents, par exemple « SA » pour les pièces du grand livre, et exclure les pièces opérationnelles, comme les factures ou les paiements, si elles ne font pas partie du périmètre. - Performances : Les requêtes directes sur des tables centrales comme BSEG et CDPOS peuvent consommer beaucoup de ressources. Il est fortement recommandé d’effectuer l’extraction en dehors des heures de pointe afin de ne pas ralentir le système pour les utilisateurs. Évitez d’extraire plus d’un an de données en une seule exécution.
- Identifiants des tâches du flux de travail : La requête contient des espaces réservés comme
'[WF_TASK_ID_SUBMIT]'et'[WF_TASK_ID_APPROVE]'. Remplacez-les par les identifiants de tâche réellement utilisés dans la configuration du flux de travail de traitement des pièces comptables de votre système. Pour les trouver, consultez un spécialiste SAP Workflow ou analysez la définition technique du flux de travail dans la transaction PFTC.
Exemple de requête sql
WITH DOC_HEADERS AS (
SELECT
BUKRS,
BELNR,
GJAHR,
BLART,
BLDAT,
BUDAT,
CPUDT,
CPUTM,
USNAM,
TCODE,
BSTAT,
STBLG,
XRECH
FROM BKPF
WHERE CPUDT BETWEEN '[START_DATE]' AND '[END_DATE]'
AND BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]')
)
-- Event 1: Journal Entry Created (Directly Posted)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = '' OR H.BSTAT = 'U'
UNION ALL
-- Event 2: Journal Entry Parked
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = 'V'
UNION ALL
-- Event 3: Journal Entry Posted (from Parked state)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT <> 'V'
AND P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW <> 'V'
UNION ALL
-- Event 4: Parked Journal Entry Deleted
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Parked Journal Entry Deleted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND C.TCODE = 'FBV0'
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW = 'Z'
UNION ALL
-- Event 5: Journal Entry Reversal Processed
SELECT
CONCAT(H.BUKRS, H.STBLG, H.GJAHR) AS "JournalEntryId", -- Linking to the original document
'Journal Entry Reversal Processed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
TRUE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.STBLG IS NOT NULL AND H.STBLG <> ''
UNION ALL
-- Event 6: Journal Entry Line Item Cleared
SELECT
CONCAT(B.BUKRS, B.BELNR, B.GJAHR) AS "JournalEntryId",
'Journal Entry Line Item Cleared' AS "ActivityName",
TO_TIMESTAMP(B.AUGDT, 'YYYYMMDD') AS "EventTime", -- Clearing date used as event time
U.NAME_TEXT AS "User",
B.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode", -- Clearing transaction is in the clearing document header, complex to retrieve here
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM BSEG B
JOIN DOC_HEADERS H ON B.BUKRS = H.BUKRS AND B.BELNR = H.BELNR AND B.GJAHR = H.GJAHR
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE B.AUGBL IS NOT NULL AND B.AUGBL <> '' AND B.AUGDT <> '00000000'
UNION ALL
-- Event 7: Journal Entry Corrected (changes to a parked document)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT = 'V' AND C.TCODE IN ('FBV2', 'FBV4') -- FBV2 is change parked doc, FBV4 is change parked doc header
UNION ALL
-- Event 8: Documentation Attached (inferred from GOS attachment creation, requires configuration)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(CONCAT(REL.RECDATE, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SRGBTBREL REL ON REL.INSTID_A = CONCAT('BUS2081', H.BUKRS, H.BELNR, H.GJAHR) -- BUS2081 is object type for BKPF
LEFT JOIN V_USERNAME U ON REL.RECUNAM = U.BNAME
WHERE REL.TYPEID_A = 'BUS2081' AND REL.RELTYPE = 'ATTA'
UNION ALL
-- Events 9-13 from Workflow (Submitted, Changes Requested, Approved, Rejected) requires specific workflow config
-- This is a generic template. The WI_RH_TASK must be adapted to your system.
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
CASE
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_SUBMIT]' THEN 'Journal Entry Submitted'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_APPROVE]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Approved'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_REJECT]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Rejected'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_CHANGES_REQ]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Changes Requested'
ELSE NULL
END AS "ActivityName",
TO_TIMESTAMP(CONCAT(LOG.EVT_DATE, LOG.EVT_TIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SWW_WI2OBJ WIOBJ ON WIOBJ.INSTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND WIOBJ.TYPEID = 'BKPF'
JOIN SWWLOGHIST LOG ON WIOBJ.WI_ID = LOG.WI_ID
LEFT JOIN V_USERNAME U ON LOG.EXEC_USER = U.BNAME
WHERE LOG.WI_RH_TASK IN ('[WF_TASK_ID_SUBMIT]', '[WF_TASK_ID_APPROVE]', '[WF_TASK_ID_REJECT]', '[WF_TASK_ID_CHANGES_REQ]')
UNION ALL
-- Event 14: Manual Entry Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Manual Entry Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.TCODE IN ('FB01', 'F-02', 'FB50', 'F-04', 'F-22', 'F-43', 'FB60', 'FB70', 'FV50', 'FV60', 'FV70')
UNION ALL
-- Event 15: Cross-Company Posting Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Cross-Company Posting Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.XRECH = 'X' Étapes
- Établissez la connexion SAP : Dans votre outil ETL tiers, configurez une nouvelle connexion source à votre système SAP ECC. Vous aurez généralement besoin des informations du serveur d’applications, du client, du numéro de système et d’un utilisateur SAP dédié disposant des autorisations RFC nécessaires.
- Définissez les sources de données : Dans votre projet d’extraction, ajoutez les tables SAP requises comme sources de données. Les principales tables sont BKPF (en-tête de document comptable), BSEG (poste de document comptable), VBSEGK (en-tête de document mis en attente), CDHDR (en-tête de document de modification), CDPOS (postes de document de modification), SWW_WI2OBJ (liens entre flux de travail et objets), SWWLOGHIST (journal du flux de travail) et SRGBTBREL (relations des pièces jointes GOS).
- Extrayez les événements de base (création et mise en attente) : Créez le premier flux de données pour extraire les événements initiaux. Pour « Écriture comptable mise en attente », utilisez VBSEGK comme source. Pour « Écriture comptable créée », utilisez BKPF en filtrant les documents qui ne sont pas des extournes et qui n’ont pas été initialement mis en attente. Vous pouvez le faire au moyen d’une jointure anti avec VBSEGK.
- Extrayez les événements du flux de travail : Créez un flux de données qui joint BKPF à SWW_WI2OBJ à l’aide de la clé d’objet (code société + numéro de document + exercice) pour trouver l’ID de l’instance du flux de travail. Joignez le résultat à SWWLOGHIST pour extraire des événements comme « Soumise », « Approuvée », « Rejetée » et « Modifications demandées », à partir des résultats des tâches du flux de travail et des décisions des utilisateurs consignées dans le journal.
- Extrayez les événements de modification et de suppression : Utilisez les tables CDHDR et CDPOS pour repérer les modifications. Pour « Écriture comptable corrigée », filtrez les modifications apportées aux documents mis en attente (classe d’objet « FIPP »). Pour « Écriture comptable mise en attente supprimée », recherchez les marqueurs de suppression dans les journaux de modification des documents mis en attente.
- Extrayez les événements liés aux pièces jointes : Pour enregistrer « Documentation jointe », joignez BKPF à SRGBTBREL lorsque le type d’objet est « BKPF » et que la relation est « [Your attachment relationship type] ». La date de création du lien sert d’horodatage à l’événement.
- Extrayez les événements de lettrage et d’extourne : Pour « Poste d’écriture comptable lettré », interrogez la table BSEG lorsque le champ du document de lettrage (AUGBL) est renseigné. L’horodatage de l’événement correspond à la date de comptabilisation du document de lettrage (AUGDT). Pour « Extourne d’écriture comptable effectuée », interrogez BKPF afin de repérer les documents extournés, identifiés par une valeur dans le champ du document extourné (STBLG).
- Déduisez les événements calculés : Créez des blocs de logique distincts pour les événements calculés. Pour « Saisie manuelle identifiée », filtrez BKPF selon une liste de codes de transaction manuels, par exemple FB01, FB50 et F-02. Pour « Comptabilisation intersociétés identifiée », regroupez la table BSEG par ID de document et repérez les documents associés à plusieurs codes société distincts.
- Regroupez tous les flux d’événements : Utilisez une transformation UNION dans votre outil ETL pour fusionner les résultats de chaque flux d’événements (création, mise en attente, approbation, etc.) dans une seule table de journal d’événements. Vérifiez que les noms et les types de données des colonnes sont cohérents dans tous les flux.
- Associez les données au schéma final : Faites correspondre les données regroupées à la structure requise du journal d’événements, en créant les champs
JournalEntryId,ActivityName,EventTime,Utilisateuret les autres attributs requis ou recommandés. Ajoutez des colonnes statiques commeSourceSystemet utilisez l’heure d’exécution du traitement ETL pourLastDataUpdate. - Configurez le chargement incrémentiel : Pour les extractions régulières, configurez une stratégie de chargement incrémentiel. Utilisez la dernière date de création ou de modification, par exemple BKPF.CPUDT ou CDHDR.UDATE, comme point de reprise afin de ne récupérer que les nouveaux enregistrements ou ceux modifiés depuis la dernière exécution.
- Exportez les données pour ProcessMind : Planifiez le traitement d’extraction et configurez l’étape de sortie finale pour enregistrer le journal d’événements dans un fichier CSV ou Parquet, à un emplacement accessible à ProcessMind pour l’importation.
Configuration
- Prérequis : Un outil ETL tiers sous licence (par exemple, Theobald Xtract Universal, Informatica ou Talend) doté d’un connecteur SAP dédié. Un compte utilisateur SAP disposant d’un accès RFC et des autorisations nécessaires pour lire les tables financières (par exemple, S_TABU_DIS pour les groupes de tables F_00 et F_WF), les données des flux de travail et les journaux de modifications.
- Paramètres de connexion : Vous aurez besoin de l’adresse IP ou du nom d’hôte du serveur d’applications SAP, du numéro de système et de l’identifiant du mandant. Utilisez une solution sécurisée pour gérer le nom d’utilisateur et le mot de passe SAP.
- Filtres principaux : Appliquez toujours des filtres sur le code société (BKPF.BUKRS) et l’exercice (BKPF.GJAHR) à la source afin de limiter le volume de données. Il est fortement recommandé de filtrer également sur la date de création de la pièce (BKPF.CPUDT) pour définir une période d’extraction précise, par exemple les six derniers mois.
- Sélection de la période : Pour le chargement initial, choisissez une période représentative, par exemple de trois à six mois. Pour les chargements différentiels suivants, utilisez un horodatage tel que
CPUDTcomme point de reprise afin de récupérer uniquement les nouveaux enregistrements. - Considérations relatives aux performances : Les jointures sur BSEG, CDPOS et les tables des flux de travail peuvent être très lentes. Dans la mesure du possible, configurez votre outil ETL pour appliquer les filtres directement à la source SAP. Si l’outil le permet, extrayez les données par lots plus petits, en particulier pour les chargements portant sur un historique volumineux.
- Personnalisation des flux de travail : La logique permettant de repérer des activités telles que « Approuvée » ou « Rejetée » dépend fortement des modèles de flux de travail propres à votre organisation. Vous devrez identifier dans votre système les identifiants des tâches de flux de travail et les clés de décision des utilisateurs à utiliser dans les filtres.
Exemple de requête sql
/*
This is a logical representation of the extraction configuration in a third-party ETL tool.
It is not executable SQL but defines the sources, joins, and transformations for each activity.
Placeholders like [Your SAP Source], [Date Filter], and [Company Code Filter] must be configured in the tool.
*/
-- Extraction block for 'Journal Entry Parked'
SELECT
CONCAT(v.BUKRS, v.VBELN, v.GJAHR) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(CONCAT(v.CPUDT, v.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
v.USNAM AS User,
v.BUKRS AS CompanyCode,
v.BLART AS DocumentType,
v.BUDAT AS PostingDate,
v.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].VBSEGK v
WHERE [Date Filter on v.CPUDT] AND [Company Code Filter on v.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Created'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
LEFT JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE h.BSTAT = '' AND v.VBELN IS NULL AND h.STBLG IS NULL
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Posted' (from parked)
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Or a more precise posting time from change logs if available
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Submitted', 'Approved', 'Rejected', 'Changes Requested'
SELECT
CONCAT(SUBSTRING(o.INSTID, 3, 4), SUBSTRING(o.INSTID, 7, 10), SUBSTRING(o.INSTID, 17, 4)) AS JournalEntryId,
CASE
WHEN wl.WI_TEXT LIKE '%Submit%' THEN 'Journal Entry Submitted'
WHEN wl.WI_TEXT LIKE '%Approve%' THEN 'Journal Entry Approved'
WHEN wl.WI_TEXT LIKE '%Reject%' THEN 'Journal Entry Rejected'
WHEN wl.WI_TEXT LIKE '%Request Changes%' THEN 'Journal Entry Changes Requested'
END AS ActivityName,
CAST(CONCAT(wl.WI_CD, wl.WI_CT) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
wl.EXEC_USER AS User,
SUBSTRING(o.INSTID, 3, 4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SWW_WI2OBJ o
JOIN [Your SAP Source].SWWLOGHIST wl ON o.WI_ID = wl.WI_ID
WHERE o.TYPEID = 'BKPF' AND o.CATID = 'BO'
AND wl.WI_TEXT IN ('[Your Submit Task Name]', '[Your Approve Task Name]', '[Your Reject Task Name]', '[Your Changes Request Task Name]')
AND [Date Filter on wl.WI_CD]
UNION ALL
-- Extraction block for 'Journal Entry Corrected'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'U'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Parked Journal Entry Deleted'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Parked Journal Entry Deleted' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'D'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Documentation Attached'
SELECT
CONCAT(SUBSTRING(r.INSTID_A, 3, 4), SUBSTRING(r.INSTID_A, 7, 10), SUBSTRING(r.INSTID_A, 17, 4)) AS JournalEntryId,
'Documentation Attached' AS ActivityName,
-- Note: A precise timestamp is often unavailable. Using document creation time as a proxy.
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SRGBTBREL r
JOIN [Your SAP Source].BKPF h ON h.BUKRS = SUBSTRING(r.INSTID_A, 3, 4) AND h.BELNR = SUBSTRING(r.INSTID_A, 7, 10) AND h.GJAHR = SUBSTRING(r.INSTID_A, 17, 4)
WHERE r.TYPEID_A = 'BKPF' AND r.RELTYPE = '[Configure based on your system]'
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Reversal Processed'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.STBLG IS NOT NULL AND h.STBLG <> ''
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Is Reversed' flag on original document
SELECT
CONCAT(h_orig.BUKRS, h_orig.BELNR, h_orig.GJAHR) AS JournalEntryId,
'Is Reversed' AS ActivityName, -- This is an attribute update, modeled as an event
CAST(CONCAT(h_rev.CPUDT, h_rev.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h_rev.USNAM AS User,
h_orig.BUKRS AS CompanyCode,
h_orig.BLART AS DocumentType,
h_orig.BUDAT AS PostingDate,
h_orig.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h_rev
JOIN [Your SAP Source].BKPF h_orig ON h_rev.STBLG = h_orig.BELNR AND h_rev.BUKRS = h_orig.BUKRS AND h_rev.GJAHR_S = h_orig.GJAHR
WHERE h_rev.STBLG IS NOT NULL AND h_rev.STBLG <> ''
AND [Date Filter on h_rev.CPUDT] AND [Company Code Filter on h_rev.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Line Item Cleared'
SELECT
CONCAT(i.BUKRS, i.BELNR, i.GJAHR) AS JournalEntryId,
'Journal Entry Line Item Cleared' AS ActivityName,
CAST(i.AUGDT AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
NULL AS User, -- User who performed clearing is on the clearing document header
i.BUKRS AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BSEG i
WHERE i.AUGBL IS NOT NULL AND i.AUGBL <> ''
AND [Date Filter on i.AUGDT] AND [Company Code Filter on i.BUKRS]
UNION ALL
-- Extraction block for 'Manual Entry Identified'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Manual Entry Identified' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.TCODE IN ('FB01', 'F-02', 'FB50', 'FV50', '[Add other manual T-Codes]')
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Cross-Company Posting Identified'
SELECT
JournalEntryId,
'Cross-Company Posting Identified' AS ActivityName,
EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
User,
CompanyCode,
DocumentType,
PostingDate,
TransactionCode,
IsReversed
FROM (
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed,
(SELECT COUNT(DISTINCT i.BUKRS) FROM [Your SAP Source].BSEG i WHERE i.BELNR = h.BELNR AND i.BUKRS = h.BUKRS AND i.GJAHR = h.GJAHR) as CompanyCodeCount
FROM [Your SAP Source].BKPF h
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
) AS CrossCompanyCheck
WHERE CompanyCodeCount > 1 Prêt à commencer ?
Utilisez ce modèle de données pour démarrer votre démarche de Process Mining sur le processus de la comptabilisation au reporting pour les pièces comptables. Approfondissez vos analyses et améliorez l’efficacité de vos opérations financières.
Optimisez dès maintenant le processus de la comptabilisation au reporting : pièces comptables
Réduisez de 30 % le temps de cycle des pièces comptables et produisez des rapports fiables.
Aucune carte bancaire requise. Commencez à améliorer vos processus dès aujourd’hui.