Votre modèle de données Purchase to Pay, commandes d’achat
Votre modèle de données Purchase to Pay, commandes d’achat
- Attributs recommandés pour une analyse détaillée
- Activités clés à suivre dans le processus
- Guide d’extraction des données, étape par étape
Purchase to Pay - Purchase Order : attributs
| Nom | Description | ||
|---|---|---|---|
| Activité ActivityName | Nom de l’événement ou de l’étape métier qui s’est produit dans le processus du Purchase Order. | ||
| Description Cet attribut décrit une action précise ou une modification de statut au cours du cycle de vie de la commande d’achat, par exemple « Commande d’achat créée », « Commande d’achat approuvée » ou « Réception des marchandises comptabilisée ». La séquence de ces activités forme le flux du processus. L’analyse de la séquence et de la fréquence des activités constitue le cœur du Process Mining. Elle permet de découvrir le processus réel, de le comparer au modèle conçu, d’identifier les goulots d’étranglement, par exemple les longues attentes après « Facture reçue », et de quantifier les reprises, par exemple les activités répétées « Commande d’achat modifiée ». Pourquoi c’est important Il définit les étapes du processus et permet de visualiser et d’analyser le flux de bout en bout, les variantes et les goulots d’étranglement. Où les obtenir Généralement dérivé d’une combinaison de tables et de champs, comme les champs de statut d’EKKO/EKPO ou les journaux de documents de modification CDHDR/CDPOS, afin de représenter les principales étapes métier. Exemples Purchase Order crééPurchase Order approuvéRéception de marchandises enregistréeFacture reçue | |||
| Commande d’achat PurchaseOrderNumber | Identifiant unique du Purchase Order (PO), qui sert d’identifiant principal du cas pour suivre le cycle de vie de l’approvisionnement. | ||
| Description Le numéro de commande d’achat est l’identifiant central qui relie toutes les activités associées, de la création initiale à la réception finale des marchandises et à la clôture. Il sert d’identifiant du cas pour l’analyse de Process Mining. Dans l’analyse, le regroupement des événements par numéro permet de reconstituer le parcours de chaque commande d’achat. Cette étape est essentielle pour calculer les temps de cycle, analyser les variantes du processus et identifier les goulots d’étranglement ou les écarts propres à une commande donnée. Pourquoi c’est important Il s’agit de la clé essentielle qui relie tous les événements d’approvisionnement au sein d’un même processus de bout en bout et permet d’analyser en détail le cycle de vie de chaque Purchase Order. Où les obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ EBELN. Exemples 450001712345000171244500017125 | |||
| Heure de l’événement EventTime | Horodatage indiquant le moment où l’activité s’est produite. | ||
| Description Cet attribut enregistre la date et l’heure exactes de chaque activité du processus. Il est indispensable à toutes les analyses temporelles du Process Mining. L’heure de l’événement sert à classer les activités par ordre chronologique afin de construire le flux du processus. Elle constitue également la base du calcul de toutes les métriques de durée, notamment les temps de cycle entre les activités, les temps d’attente et les durées de traitement, qui sont essentiels à l’analyse des performances et à l’identification des goulots d’étranglement. Pourquoi c’est important Cet horodatage est essentiel pour ordonner correctement les événements et calculer tous les indicateurs de performance, notamment les temps de cycle, les délais fournisseurs et les temps d’attente. Où les obtenir Champs d’horodatage associés à des activités précises, comme la date de création (EKKO-AEDAT pour les modifications) ou la date de comptabilisation (MKPF-BUDAT pour les réceptions de marchandises). Leur détermination nécessite souvent de combiner des données provenant de plusieurs tables. Exemples 2023-04-15T10:00:00Z2023-04-15T14:30:00Z2023-05-01T09:15:00Z | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage correspondant au dernier rafraîchissement ou à la dernière extraction des données depuis le système source. | ||
| Description Cet attribut indique l’actualité des données analysées. Il affiche la date et l’heure de la dernière extraction des données depuis SAP S/4HANA. Connaître la date de la dernière mise à jour est essentiel pour comprendre l’actualité de l’analyse. Cela permet d’interpréter correctement les résultats, en sachant si vous consultez des informations en temps réel ou un instantané pris à un moment donné, ce qui influe sur la pertinence des mesures prises à partir de l’analyse. Pourquoi c’est important Informe les utilisateurs sur l’actualité des données afin qu’ils comprennent le contexte et la pertinence de leurs résultats d’analyse. Où les obtenir Il s’agit d’un horodatage de métadonnées ajouté lors du processus d’extraction, de transformation et de chargement (ETL). Exemples 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| Système source SourceSystem | Identifie le système source depuis lequel les données ont été extraites. | ||
| Description Cet attribut précise le système d’origine des données d’événements, par exemple « SAP S/4HANA Production » ou « SAP ECC ». Dans les environnements comprenant plusieurs systèmes, ce champ est essentiel pour assurer la traçabilité des données, résoudre les problèmes et garantir l’interprétation correcte des données provenant de différentes sources. Il aide à comprendre le contexte des données et peut servir à filtrer l’analyse sur des environnements système précis. Pourquoi c’est important Fournit un contexte essentiel sur l’origine des données, indispensable à leur gouvernance, à leur validation et à leur analyse dans des environnements multisystèmes. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL) pour identifier l’origine du jeu de données. Exemples S4H_PROD_100ECC_EU_200S4H_US_300 | |||
| Date de livraison demandée RequestedDeliveryDate | Date à laquelle l’entreprise a demandé au fournisseur de livrer les biens ou les services. | ||
| Description Cet attribut précise la date de livraison cible convenue dans le Purchase Order. Il sert de référence pour mesurer la performance de livraison du fournisseur. Dans le Process Mining, cette date est comparée à la date réelle de réception des marchandises, c’est-à-dire à l’horodatage « Goods Receipt Posted », afin de calculer le KPI « Supplier On-Time Delivery Rate ». L’analyse des écarts par rapport à cette date aide à évaluer la fiabilité du fournisseur et à gérer les risques de la chaîne d’approvisionnement. Pourquoi c’est important Sert de référence pour mesurer la performance des livraisons fournisseurs à temps, un KPI important pour la gestion de la chaîne d’approvisionnement et la planification opérationnelle. Où les obtenir Cet attribut se trouve dans la table des lignes d’échéancier EKET, champ EINDT. Exemples 2023-06-012023-06-152023-07-01 | |||
| Demande d’achat PurchaseRequisitionNumber | Identifiant de la Purchase Requisition à l’origine du Purchase Order. | ||
| Description Cet attribut relie le Purchase Order à la Purchase Requisition dont il est issu. Tous les PO ne disposent pas d’une PR, notamment lorsqu’ils sont créés directement. Ce lien est essentiel pour analyser le processus d’approvisionnement complet, depuis la demande initiale. Il permet de suivre des KPI tels que le délai d’approbation de la Purchase Requisition et joue un rôle fondamental dans l’identification des achats hors procédure, lorsque des PO sont créés sans Purchase Requisition préalable et approuvée. Pourquoi c’est important Relie le PO à la demande initiale, ce qui permet d’analyser le processus de bout en bout et d’identifier les achats hors procédure non conformes. Où les obtenir Cet attribut se trouve dans la table SAP S/4HANA EKPO, au niveau du poste du PO, champ BANFN. Exemples 1001005110010052 | |||
| Identifiant du fournisseur VendorId | Identifiant unique du fournisseur qui fournit les biens ou les services. | ||
| Description L’identifiant du fournisseur est une donnée de référence essentielle qui relie un Purchase Order à un fournisseur précis. Il est utilisé tout au long du processus d’approvisionnement pour la communication, la livraison et le paiement. Dans le Process Mining, cet attribut permet de segmenter l’analyse de la performance par fournisseur. Il est essentiel pour des Dashboards tels que « Supplier Lead Time Performance » et « Goods Return Rate by Vendor », qui aident à identifier les fournisseurs les plus fiables et ceux susceptibles d’entraîner des retards ou des problèmes de qualité. Pourquoi c’est important Permet une analyse centrée sur les fournisseurs, afin d’évaluer leur performance, d’identifier les fournisseurs les plus et les moins performants et d’optimiser la chaîne d’approvisionnement. Où les obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ LIFNR. Exemples 100023100045100088 | |||
| Montant net total TotalNetAmount | Valeur totale du Purchase Order, hors taxes et frais de transport. | ||
| Description Cet attribut représente la valeur monétaire nette du Purchase Order. Il s’agit d’un indicateur financier clé qui reflète l’importance de la transaction d’approvisionnement. Ce montant est essentiel pour les analyses financières, notamment pour classer les PO par valeur, entre commandes de montant élevé et faible, et vérifier si leurs parcours diffèrent. Il peut également servir à prioriser l’analyse en se concentrant sur les commandes de montant élevé, qui peuvent présenter un risque financier supérieur ou avoir une incidence plus importante sur l’entreprise. Pourquoi c’est important Permet une analyse fondée sur la valeur financière, en segmentant les Purchase Orders par montant et en donnant la priorité aux efforts d’amélioration des processus dans les domaines de dépenses élevées. Où les obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ NETWR. Exemples 1500.0025000.50125.75 | |||
| Type de document du PO DocumentType | Classification qui distingue différents types de Purchase Orders, comme les PO standards, les PO de services ou les ordres de transfert de stock. | ||
| Description Le type de document est un élément de configuration clé dans SAP. Il contrôle le flux du processus, la plage de numérotation et les champs d’un Purchase Order. Il permet aux entreprises d’adapter le processus d’approvisionnement à différents scénarios. L’analyse du processus par type de document est essentielle pour comprendre les variantes. Par exemple, le processus d’un PO standard de marchandises peut être très différent de celui d’un PO de services ou d’un transfert de stock. Cet attribut permet de filtrer et de comparer ces flux distincts afin d’identifier des possibilités d’amélioration précises. Pourquoi c’est important Catégorise les Purchase Orders, permet de comparer différents processus d’approvisionnement et aide à expliquer les variations des flux et des temps de cycle. Où les obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ BSART. Exemples NBFOUB | |||
| Utilisateur UserName | Identifiant de l’utilisateur qui a effectué une activité donnée. | ||
| Description Cet attribut enregistre l’identifiant de l’utilisateur SAP responsable de la création, de la modification ou de l’approbation d’un document. Il assure la traçabilité des actions effectuées dans le système. L’analyse par utilisateur permet d’identifier les besoins de formation, de répartir la charge de travail et d’évaluer la performance individuelle. Elle peut notamment révéler si certains utilisateurs sont régulièrement associés à de longs délais d’approbation ou à des modifications fréquentes après approbation, afin d’éclairer la gestion des Ressources et les initiatives d’amélioration des processus. Pourquoi c’est important Assure la responsabilité des actions et permet d’analyser la performance au niveau individuel ou de l’équipe, afin d’identifier les besoins de formation ou les contraintes de Ressources. Où les obtenir Ces informations figurent dans des champs tels que ERNAM (Created by) dans EKKO ou dans le champ utilisateur des tables de documents de modification (CDHDR-USERNAME). Exemples CB9980000012JSMITHRROE | |||
| Achats hors procédure IsMaverickSpend | Indicateur calculé précisant si une commande d’achat a été créée sans demande d’achat approuvée au préalable. | ||
| Description Cet indicateur booléen est calculé lors du traitement des données. Il prend la valeur « true » lorsqu’une commande d’achat ne possède pas de demande d’achat associée ou lorsque sa création contourne le flux de travail de validation standard. Cet attribut alimente directement le Dashboard « Identification des dépenses hors procédure » et les KPI associés. Il aide à mesurer l’ampleur des comportements d’achat non conformes et permet aux entreprises de cibler certains services ou groupes d’utilisateurs afin de renforcer les politiques et les contrôles d’achat. Pourquoi c’est important Identifie directement les achats non conformes, aide à mesurer les écarts de processus et contribue à faire respecter les contrôles financiers et les politiques d’approvisionnement. Où les obtenir Champ calculé à partir de l’absence de valeur dans « PurchaseRequisitionNumber » pour certains types de documents, ou par l’analyse de la séquence des événements. Exemples truefalse | |||
| Catégorie de poste ItemCategory | Classe un poste de Purchase Order, par exemple comme poste standard, en consignation, de sous-traitance ou de services. | ||
| Description La catégorie de poste détermine la manière dont l’approvisionnement d’un article ou d’un service donné est contrôlé et traité. Elle influe sur les étapes suivantes, comme la réception des marchandises et la vérification des factures. Cet attribut est important pour analyser les variantes du processus selon la nature de l’achat. Par exemple, le processus d’un poste de services, qui nécessite une feuille de saisie de services, diffère sensiblement de celui d’un article standard en stock. L’analyse par catégorie de poste permet d’expliquer ces différences et de cibler les améliorations. Pourquoi c’est important Explique les variantes du processus en distinguant les différents types d’approvisionnement, comme les biens, les services ou la sous-traitance. Où les obtenir Cet attribut se trouve dans la table SAP S/4HANA EKPO, champ PSTYP. Exemples 093 | |||
| Code société CompanyCode | Identifiant de l’entité juridique ou de la société pour laquelle la commande d’achat est créée. | ||
| Description Le code société représente une unité comptable indépendante au sein d’une organisation. Toutes les transactions financières liées à une commande d’achat sont enregistrées dans un code société donné. Il s’agit d’un attribut organisationnel fondamental, qui permet de filtrer et de comparer les processus d’approvisionnement entre différentes entités juridiques. L’analyse par code société peut révéler des incohérences dans l’exécution des processus, des niveaux d’efficacité différents ou des taux de conformité variables au sein de l’organisation. Pourquoi c’est important Permet de segmenter l’analyse des processus par entité juridique et de comparer les performances et la conformité entre les différentes composantes de l’entreprise. Où les obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ BUKRS. Exemples 101017102000 | |||
| Groupe d’achats PurchasingGroup | Groupe spécifique d’acheteurs responsable de certaines activités d’approvisionnement. | ||
| Description Un groupe d’achats désigne un acheteur ou un groupe d’acheteurs responsable de certaines activités d’achat, de matériaux ou de fournisseurs. Il constitue le principal interlocuteur des fournisseurs. Cet attribut permet une analyse plus fine de la charge de travail et des performances que l’organisation d’achats. Il peut servir à identifier les équipes surchargées, à mesurer l’efficacité des différents groupes d’acheteurs et à déterminer quels groupes sont davantage exposés aux écarts de processus, comme les achats hors procédure. Pourquoi c’est important Fournit une vue détaillée des performances des groupes d’acheteurs et permet d’analyser la charge de travail, l’efficacité et le respect des processus au niveau de l’équipe. Où les obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ EKGRP. Exemples 001002N00 | |||
| Livraison fournisseur dans les délais SupplierOnTimeDelivery | Indicateur calculé précisant si la réception des marchandises a été enregistrée à la date de livraison demandée ou avant celle-ci. | ||
| Description Cet attribut booléen est calculé en comparant l’horodatage de l’activité « Goods Receipt Posted » à la « Requested Delivery Date ». Si la réception des marchandises a lieu à la date demandée ou avant, l’attribut prend la valeur « true ». Cet attribut alimente directement le KPI « Taux de livraison fournisseur dans les délais ». Il simplifie l’analyse en permettant de filtrer facilement les livraisons effectuées à temps ou en retard, ce qui est essentiel pour les Dashboards de performance fournisseurs et l’évaluation des fournisseurs. Pourquoi c’est important Mesure directement la fiabilité des fournisseurs, sert de base au KPI de livraison dans les délais et permet une gestion efficace de leur performance. Où les obtenir Calculé en comparant l’horodatage de l’activité « Goods Receipt Posted » à l’attribut « RequestedDeliveryDate ». Exemples truefalse | |||
| Numéro de matériau MaterialNumber | Identifiant du matériau ou du bien faisant l’objet de l’approvisionnement. | ||
| Description Le numéro de matériau est un code unique attribué à chaque fiche article dans SAP. Il est utilisé pour toutes les transactions liées à ce matériau, notamment l’approvisionnement, la gestion des stocks et les ventes. L’analyse par numéro de matériau ou groupe de matériaux permet d’étudier les achats par catégorie de produits. Elle peut aider à déterminer si les processus d’approvisionnement de certains types de matériaux sont moins efficaces, présentent des délais plus longs ou sont davantage sujets aux retours, afin d’éclairer la gestion des catégories d’achat. Pourquoi c’est important Permet une analyse par catégorie de produits et aide à identifier les problèmes de processus ou de performance fournisseur liés à certains produits ou matériaux. Où les obtenir Cet attribut se trouve dans la table SAP S/4HANA EKPO, champ MATNR. Exemples RM100-100FG210SERV-CONSULT | |||
| Organisation d’achats PurchasingOrganization | Unité organisationnelle chargée de l’approvisionnement en matériaux et services ainsi que de la négociation avec les fournisseurs. | ||
| Description L’organisation d’achats est une unité organisationnelle essentielle de l’approvisionnement. Elle peut être structurée au niveau du groupe, de la société ou de l’usine, et elle est responsable de l’ensemble des activités d’achat. L’analyse du processus par organisation d’achats permet d’évaluer l’efficacité et les performances des différentes équipes ou régions d’approvisionnement. Elle peut mettre en évidence des écarts dans la négociation avec les fournisseurs, le respect des processus ou les délais d’approbation entre les unités organisationnelles. Pourquoi c’est important Permet de comparer les performances de différents services ou régions d’approvisionnement, afin d’identifier les bonnes pratiques et les domaines à améliorer. Où les obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ EKORG. Exemples 10101710US01 | |||
| Retraitement IsRework | Indicateur calculé précisant si la commande d’achat a fait l’objet d’un retraitement, par exemple à la suite d’une modification après approbation ou d’un retour de marchandises. | ||
| Description Cet attribut booléen est calculé en analysant la séquence des activités de chaque commande d’achat. Il prend la valeur « true » si un événement « Purchase Order Changed » survient après un événement « Purchase Order Approved », ou si un événement « Goods Returned » est présent. Cet indicateur simplifie le calcul du KPI « Taux de traitement direct ». Il permet de filtrer et de visualiser facilement toutes les commandes d’achat ayant nécessité une intervention ou une correction manuelle, afin de mesurer le coût et la fréquence des retraitements. Pourquoi c’est important Aide à mesurer l’inefficacité du processus en signalant les cas ayant fait l’objet d’un retraitement. Il est essentiel pour calculer les taux de traitement direct et identifier les causes profondes des écarts. Où les obtenir Champ calculé à partir de la séquence des activités. La logique vérifie si un événement « Purchase Order Changed » suit une approbation ou si un événement « Goods Returned » est présent. Exemples truefalse | |||
| Site Plant | Installation ou emplacement opérationnel où les marchandises sont livrées ou les services réalisés. | ||
| Description Dans SAP, un site est un emplacement physique où les marchandises sont produites ou stockées, ou dans lequel les services sont réalisés. Il constitue un élément essentiel de la logistique et de la planification. La segmentation de l’analyse des processus par site peut révéler des variations régionales ou propres à certains établissements dans le processus d’approvisionnement. Elle peut notamment montrer si certains sites connaissent des délais de livraison plus longs ou des taux de retour de marchandises plus élevés, ce qui peut signaler des problèmes logistiques ou de contrôle qualité localisés. Pourquoi c’est important Permet une analyse par emplacement et met en évidence les écarts de performance entre différents sites opérationnels, usines ou entrepôts. Où les obtenir Cet attribut se trouve dans la table SAP S/4HANA EKPO, champ WERKS. Exemples 10101710DE01 | |||
Purchase to Pay - Purchase Order : activités
| Activité | Description | ||
|---|---|---|---|
| Facture reçue | Représente l’enregistrement de la facture d’un fournisseur dans le système SAP et son association au Purchase Order correspondant. Il s’agit d’une écriture financière explicite qui crée un document comptable. | ||
| Pourquoi c’est important Cette étape importante relie le processus d’approvisionnement à celui des comptes fournisseurs. Elle permet d’analyser le délai entre la réception des marchandises et le traitement de la facture. Où les obtenir Un document comptable est créé dans la table BKPF (en-tête) et ses postes figurent dans BSEG ou dans le journal universel ACDOCA. Le document est associé au PO dans la table RSEG. Collecte Date de saisie du document (CPUDT) dans la table d’en-tête du document comptable BKPF. Type d’événement explicit | |||
| Purchase Order approuvé | Indique que le Purchase Order a reçu toutes les approbations internes nécessaires et qu’il peut être envoyé au fournisseur. L’événement est déduit d’un changement de statut dans la stratégie de libération du Purchase Order. | ||
| Pourquoi c’est important Il s’agit d’une étape clé pour mesurer l’efficacité des approbations et les reprises après approbation. L’analyse du délai entre la création et l’approbation du PO met en évidence les retards du processus interne. Où les obtenir Déduit de l’indicateur de libération (FRGKE) dans la table EKKO. L’horodatage est déterminé à partir de l’historique des modifications (CDHDR/CDPOS), lorsque ce champ a été mis à jour avec le statut « released ». Collecte Déduit des journaux de modification du champ d’indicateur de libération (FRGKE) dans la table EKKO. Type d’événement inferred | |||
| Purchase Order créé | Cette activité marque la création du document officiel de Purchase Order, avec ou sans référence à une Purchase Requisition. Il s’agit d’un événement explicite, enregistré lors de la première sauvegarde du document PO dans le système. | ||
| Pourquoi c’est important Cette activité peut constituer un autre point de départ du processus, notamment pour analyser les achats hors procédure. Il s’agit d’un événement fondamental pour suivre le temps global de traitement des PO. Où les obtenir Enregistré dans la table d’en-tête des Purchase Orders EKKO. La date de création (AEDAT) et l’heure sont stockées directement dans cette table pour le document. Collecte Horodatage de création (AEDAT) dans la table EKKO du document Purchase Order. Type d’événement explicit | |||
| Purchase Order terminé | Cette activité indique qu’un poste de Purchase Order est considéré comme clôturé du point de vue logistique. Elle est déduite lorsque les indicateurs « Delivery Completed » et « Final Invoice » sont tous deux activés. | ||
| Pourquoi c’est important Elle constitue le point final de l’analyse du cycle de vie du Purchase Order. La mesure du délai jusqu’à cet événement fournit le temps de cycle de bout en bout des opérations d’approvisionnement. Où les obtenir Déduit des indicateurs de statut de la table des postes de Purchase Orders EKPO. L’événement se produit lorsque les indicateurs « Delivery Completed » (ELIKZ) et « Final Invoice » (EREKZ) sont tous deux définis sur true. Collecte Déduit des journaux de modification lorsque les champs ELIKZ et EREKZ de la table EKPO sont tous deux marqués comme terminés. Type d’événement inferred | |||
| Purchase Requisition approuvée | Cette activité représente l’approbation officielle d’une Purchase Requisition par un responsable ou un approbateur désigné. Elle est généralement déduite d’un changement de statut du document de demande, indiquant que celui-ci peut être converti en Purchase Order. | ||
| Pourquoi c’est important Il s’agit d’une étape essentielle pour suivre les temps de cycle de validation et identifier les goulots d’étranglement. Les retards à ce stade ont une incidence directe sur la rapidité de création et d’envoi d’une commande d’achat au fournisseur. Où les obtenir Déduit des champs de statut de libération de la table EBAN, par exemple FRGZU, Release indicator. L’horodatage est établi à partir des documents de modification CDHDR/CDPOS, qui enregistrent le moment où le statut final de libération a été défini. Collecte Déduit des journaux de modification CDHDR/CDPOS relatifs aux champs de statut de libération de la table EBAN. Type d’événement inferred | |||
| Purchase Requisition créée | Cette activité correspond à la demande officielle de biens ou de services et marque le début du processus d’approvisionnement. L’événement est enregistré explicitement lorsqu’un utilisateur sauvegarde un nouveau document de Purchase Requisition, par exemple avec la transaction ME51N. | ||
| Pourquoi c’est important Il s’agit du principal point de départ du cycle de vie de nombreux Purchase Orders. L’analyse du délai entre cet événement et la création du PO permet d’identifier les retards liés au sourcing et au traitement interne. Où les obtenir Enregistré dans la table EBAN (Purchase Requisition). L’horodatage de création peut être trouvé dans les tables d’historique des modifications CDHDR et CDPOS pour l’objet EBAN. Collecte Événement enregistré lors de la création d’un document dans la table EBAN. Type d’événement explicit | |||
| Réception de marchandises enregistrée | Représente la réception physique des marchandises du fournisseur et son enregistrement correspondant dans le système. Il s’agit d’une transaction explicite qui met à jour l’historique du Purchase Order. | ||
| Pourquoi c’est important Cette étape importante met fin au délai fournisseur et marque le début du processus interne de vérification des factures. Elle est essentielle pour suivre le taux de livraison à temps. Où les obtenir Enregistré comme document article dans les tables MKPF (en-tête) et MSEG (poste), puis associé à l’historique du Purchase Order dans la table EKBE avec un type de mouvement spécifique, par exemple 101. Collecte Date de comptabilisation (BUDAT) de l’en-tête du document article (MKPF), associée via EKBE. Type d’événement explicit | |||
| Confirmation de services saisie | Cette activité confirme qu’un service indiqué dans un Purchase Order a été réalisé. Elle est enregistrée explicitement lors de la création d’une feuille de saisie de services. | ||
| Pourquoi c’est important Pour les achats de services, cette activité équivaut à une réception de marchandises. Elle est essentielle pour suivre les délais de prestation et permettre le paiement des fournisseurs dans les délais. Où les obtenir Enregistré lors de la création d’une feuille de saisie de services, dont les données sont stockées dans les tables ESSR (en-tête) et ESLL (lignes). La date de création sert d’horodatage. Collecte Date de création du document Service Entry Sheet dans la table ESSR. Type d’événement explicit | |||
| Facture payée | Marque le règlement final de la facture fournisseur au moyen d’une proposition de paiement ou d’un paiement manuel. Il s’agit d’une transaction financière explicite qui crée un document de compensation. | ||
| Pourquoi c’est important Bien qu’elle fasse techniquement partie du processus de paiement, cette activité offre une vue complète du cycle procure-to-pay. Elle est essentielle pour analyser les conditions et la performance des paiements. Où les obtenir Le paiement est enregistré comme document de compensation dans BKPF/ACDOCA. La date de compensation (AUGDT) du poste de facture dans BSEG ou ACDOCA indique l’événement de paiement. Collecte Date de compensation (AUGDT) du document de facture, présente dans BSEG ou ACDOCA. Type d’événement explicit | |||
| Marchandises retournées | Indique que des marchandises précédemment reçues ont été retournées au fournisseur, généralement en raison de problèmes de qualité, de dommages ou d’une livraison incorrecte. L’événement est enregistré comme un mouvement de marchandises d’annulation explicite. | ||
| Pourquoi c’est important Cette activité met en évidence les reprises et les problèmes potentiels liés à la qualité du fournisseur ou à l’exactitude de la commande. Un nombre élevé de retours pour un fournisseur ou un article donné signale un problème. Où les obtenir Enregistré comme document article avec un type de mouvement de retour spécifique, par exemple 122. L’événement est consigné dans MKPF/MSEG et associé au PO dans la table d’historique EKBE. Collecte Date de comptabilisation du document article avec un type de mouvement de retour dans EKBE. Type d’événement explicit | |||
| Purchase Order envoyé au fournisseur | Représente le moment où le Purchase Order est communiqué au fournisseur, par exemple par EDI, e-mail ou impression. Cet événement est souvent enregistré dans les journaux de gestion des sorties du système. | ||
| Pourquoi c’est important Cette activité marque le véritable début du délai fournisseur. Elle est essentielle pour mesurer précisément la performance du fournisseur à partir du moment où celui-ci reçoit la commande. Où les obtenir Capturé dans la table de contrôle des sorties NAST, qui enregistre les messages envoyés pour un document d’achat. La date et l’heure du type de sortie concerné, par exemple EDI ou e-mail, peuvent être utilisées. Collecte Horodatage du premier message de sortie envoyé avec succès pour le PO dans la table NAST. Type d’événement inferred | |||
| Purchase Order modifié | Cette activité indique qu’une modification a été apportée au Purchase Order après sa création initiale, par exemple une modification de quantité, de prix ou de date de livraison. Elle est enregistrée explicitement dans les journaux de modification du système. | ||
| Pourquoi c’est important Le suivi des modifications, notamment après approbation, est essentiel pour repérer les inefficacités, les reprises et les risques potentiels de non-conformité. Des modifications fréquentes peuvent révéler des spécifications initiales insuffisantes. Où les obtenir Enregistré dans les tables de documents de modification CDHDR (en-tête) et CDPOS (poste) pour les objets Purchase Order (EINKBELEG). Chaque modification crée une entrée détaillée dans le journal. Collecte Événement enregistré pour les modifications de champs clés des tables EKKO ou EKPO, consignées dans CDHDR/CDPOS. Type d’événement explicit | |||
| Purchase Order supprimé | Représente l’annulation ou la suppression logique d’un poste de Purchase Order ou du document complet. L’événement est enregistré lorsqu’un utilisateur active un indicateur de suppression sur le document. | ||
| Pourquoi c’est important Cette activité constitue un autre point final du processus et indique un échec ou une annulation. L’analyse des raisons de suppression des PO peut révéler des problèmes de planification de la demande ou de définition des besoins. Où les obtenir Capturé à partir de l’indicateur de suppression (LOEKZ) dans les tables d’en-tête (EKKO) ou de postes (EKPO) du Purchase Order. L’horodatage est établi à partir des documents de modification (CDHDR/CDPOS). Collecte Horodatage des documents de modification (CDHDR/CDPOS) lorsque l’indicateur de suppression (LOEKZ) est activé. Type d’événement explicit | |||
Guides d’extraction
Étapes
- Prérequis et accès : vérifiez que vous disposez d’un utilisateur doté des autorisations nécessaires pour interroger les vues Core Data Services (CDS) dans le système SAP S/4HANA. L’accès peut s’effectuer via SAP HANA Studio, ABAP Development Tools (ADT) pour Eclipse ou un outil d’extraction de données tiers prenant en charge les connexions SQL à la base de données SAP HANA.
- Identifiez les paramètres de connexion au système : obtenez les paramètres nécessaires pour votre système SAP S/4HANA, notamment l’hôte, le numéro d’instance et vos identifiants d’authentification.
- Connectez-vous à la base de données : à l’aide de votre client SQL habituel, établissez une connexion à la base de données SAP S/4HANA qui contient les vues CDS.
- Préparez la requête SQL : copiez la requête SQL complète fournie dans la section correspondante de ce document dans votre éditeur SQL. Cette requête est conçue pour extraire toutes les activités et tous les attributs requis.
- Définissez les paramètres de filtrage : repérez les valeurs fictives dans la requête. Remplacez _start_date et _end_date par la période souhaitée pour votre analyse, par exemple « 20230101 » et « 20231231 ». Modifiez le filtre poh.CompanyCode afin d’inclure les codes société à analyser.
- Exécutez la requête : lancez la requête SQL modifiée sur la base de données S/4HANA. Selon le volume de données et la période définie, cette opération peut prendre un certain temps.
- Examinez les premiers résultats : une fois la requête terminée, vérifiez rapidement le résultat dans votre client SQL. Contrôlez la présence des différentes activités, la bonne alimentation des horodatages et la cohérence de l’identifiant de cas (PurchaseOrderNumber).
- Exportez les données : exportez l’ensemble des résultats depuis votre outil SQL dans un fichier CSV (Comma Separated Values). Vérifiez que le fichier utilise l’encodage UTF-8 afin d’éviter les problèmes de caractères.
- Préparez le chargement : avant l’importation dans ProcessMind, ouvrez le fichier CSV et vérifiez que les en-têtes de colonnes correspondent exactement aux attributs définis dans les exigences de données (PurchaseOrderNumber, ActivityName, EventTime, etc.). Corrigez les noms de colonnes si votre outil d’exportation les a modifiés.
- Importez les données dans ProcessMind : chargez le fichier CSV finalisé dans votre projet ProcessMind. Lors de l’importation, associez les colonnes de votre fichier aux champs correspondants de l’identifiant de cas, de l’activité et de l’horodatage.
Configuration
- Principales vues CDS utilisées : la logique d’extraction repose sur un ensemble de vues CDS standard, riches sur le plan sémantique. Les principales vues sont les suivantes :
- I_PurchaseOrderItemAPI01 : données essentielles des postes de commande d’achat.
- I_PurchaseRequisitionItemAPI01 : détails des demandes d’achat.
- I_MaterialDocumentItem : mouvements de marchandises, notamment les réceptions et les retours.
- I_ServiceEntrySheetAPI01 : événements de confirmation des services.
- I_SupplierInvoiceAPI01 : informations relatives aux factures fournisseurs.
- I_OperationalAcctgDocItem : association des factures aux documents financiers pour le suivi des paiements.
- I_ChangeDocument : enregistrement des modifications apportées aux commandes d’achat.
- Filtrage par période : il est essentiel d’appliquer un filtre de dates afin de maîtriser les performances et le volume de données. La requête utilise les valeurs fictives _start_date et _end_date sur la date de création de la commande d’achat (PurchaseOrderDate). Il est recommandé de commencer par une période de 3 à 6 mois.
- Filtrage organisationnel : la requête doit toujours être filtrée par CompanyCode afin de limiter l’extraction aux unités opérationnelles concernées. Vous pouvez ajouter des filtres sur PurchaseOrderType ou PurchasingOrganization dans l’expression de table commune PO_base pour affiner les résultats.
- Prérequis : l’utilisateur qui exécute la requête doit disposer de l’autorisation SELECT sur toutes les vues CDS répertoriées ci-dessus. L’accès à ces vues est généralement accordé par l’intermédiaire de rôles métier ou analytiques spécifiques dans S/4HANA. Sans les autorisations adéquates, la requête échouera.
a Exemple de requête sql
WITH PO_base AS (
SELECT
poh.PurchaseOrder AS PurchaseOrderNumber,
poi.PurchaseOrderItem AS PurchaseOrderItem,
poh.CompanyCode,
poh.PurchaseOrderType AS DocumentType,
poh.Supplier AS VendorId,
poh.PurchaseOrderDate,
poi.PurchaseRequisition AS PurchaseRequisitionNumber,
poi.NetPriceAmount * poi.OrderQuantity AS TotalNetAmount, -- Note: This is item-level net amount
poh.CreationDate AS POCreationDate,
poh.CreationTime AS POCreationTime,
poh.LastChangeDateTime AS POLastChangeDateTime,
poi.IsDeleted,
poi.DeliveryIsCompleted,
poi.FinalInvoiceIsExpected,
poi.GoodsReceiptIsExpected,
poi.LastGoodsReceiptDate,
poi.LastInvoiceReceiptDate
FROM I_PurchaseOrderAPI01 poh
JOIN I_PurchaseOrderItemAPI01 poi
ON poh.PurchaseOrder = poi.PurchaseOrder
WHERE
poh.PurchaseOrderDate BETWEEN '_start_date' AND '_end_date' -- Placeholder: e.g., '20230101' and '20230630'
AND poh.CompanyCode IN ('[YourCompanyCode]') -- Placeholder: e.g., '1010'
)
-- 1. Purchase Requisition Created
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Created' AS ActivityName,
CAST(CONCAT(pr.CreationDate, 'T', pr.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem, -- Placeholder
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
pr.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate, -- Available in PR, add if needed
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
UNION ALL
-- 2. Purchase Requisition Approved
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Approved' AS ActivityName,
CAST(CONCAT(pr.PurReqnReleaseDate, 'T', '000000') AS TIMESTAMP) AS EventTime, -- Time is not available in this view
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
WHERE
pr.PurReqnReleaseDate IS NOT NULL
UNION ALL
-- 3. Purchase Order Created
SELECT
po.PurchaseOrderNumber,
'Purchase Order Created' AS ActivityName,
CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
poh.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
UNION ALL
-- 4. Purchase Order Approved
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Approved' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Assuming ReleaseDate reflects final approval
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 5. Purchase Order Sent to Vendor
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Sent to Vendor' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Using ReleaseDate as a proxy for sending time
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 6. Purchase Order Changed
SELECT DISTINCT
ch.OBJECTID AS PurchaseOrderNumber,
'Purchase Order Changed' AS ActivityName,
CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
ch.UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ChangeDocument ch
JOIN PO_base po ON ch.OBJECTID = po.PurchaseOrderNumber
WHERE
ch.ObjectClassName = 'EINKBELEG' -- Object Class for Purchase Documents
AND CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) > CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP)
UNION ALL
-- 7. Goods Receipt Posted
SELECT
po.PurchaseOrderNumber,
'Goods Receipt Posted' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '101'
UNION ALL
-- 8. Services Confirmation Entered
SELECT
po.PurchaseOrderNumber,
'Services Confirmation Entered' AS ActivityName,
CAST(se.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
se.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ServiceEntrySheetAPI01 se
JOIN PO_base po
ON se.PurchaseOrder = po.PurchaseOrderNumber AND se.PurchaseOrderItem = po.PurchaseOrderItem
UNION ALL
-- 9. Goods Returned
SELECT
po.PurchaseOrderNumber,
'Goods Returned' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '122'
UNION ALL
-- 10. Invoice Received
SELECT
po.PurchaseOrderNumber,
'Invoice Received' AS ActivityName,
CAST(inv.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
inv.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
inv.DebitCreditCode = 'H' -- 'H' for Credit (Supplier Invoice)
UNION ALL
-- 11. Invoice Paid
SELECT
po.PurchaseOrderNumber,
'Invoice Paid' AS ActivityName,
CAST(doc.ClearingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
doc.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN I_OperationalAcctgDocItem doc
ON inv.AccountingDocument = doc.AccountingDocument
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
doc.IsCleared = 'X' AND doc.ClearingDate IS NOT NULL
UNION ALL
-- 12. Purchase Order Completed
SELECT
po.PurchaseOrderNumber,
'Purchase Order Completed' AS ActivityName,
CAST(GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
'SYSTEM' AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.DeliveryIsCompleted = 'X'
AND (po.FinalInvoiceIsExpected = 'X' OR po.GoodsReceiptIsExpected = '') -- Logic for completion
AND GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) IS NOT NULL
UNION ALL
-- 13. Purchase Order Deleted
SELECT
po.PurchaseOrderNumber,
'Purchase Order Deleted' AS ActivityName,
CAST(po.POLastChangeDateTime AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- User who set the flag is in change docs
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.IsDeleted = 'X' Étapes
- Vérifiez que l’accès SQL direct au schéma SAP HANA contenant EKKO et EKPO est disponible et obtenez les autorisations de lecture nécessaires. Remplacez les valeurs fictives du schéma et de la connexion par celles configurées pour votre système.
- Définissez la période d’extraction à l’aide de [Start timestamp] et [End timestamp]. Pour le chargement initial, une période de trois à six mois est recommandée. N’appliquez les filtres sur le code société et le type de document que s’ils sont nécessaires au périmètre de reporting.
- Identifiez les commandes d’achat dans EKKO et EKPO, en conservant le numéro de commande, le fournisseur, le type de document, le code société, la date de création, l’heure de création et les attributs au niveau du poste. Agrégez les valeurs nettes d’EKPO afin de calculer TotalNetAmount au niveau de la commande d’achat.
- Extrayez les événements de création et d’approbation des demandes d’achat depuis EBAN, en utilisant le numéro de demande et la référence de poste disponibles dans EKPO pour associer les demandes aux commandes d’achat. Les indicateurs et horodatages d’approbation variant selon la configuration de la stratégie de validation, configurez les expressions relatives au statut et à l’horodatage en fonction de la stratégie SAP active dans [Configure based on your system].
- Extrayez les événements de création, d’approbation, de modification, de suppression et de clôture des commandes d’achat. La création utilise la date et l’heure de création d’EKKO. L’approbation, la modification et la suppression nécessitent des sources relatives à la validation ou à l’historique des modifications. Configurez les expressions sources correspondantes à l’aide de [Your table name] et [Your column name] lorsque l’historique pertinent n’est pas exposé dans le schéma sélectionné.
- Extrayez les événements de communication avec les fournisseurs, de réception des marchandises, de confirmation des services, de retour de marchandises, de réception des factures et de paiement des factures depuis les sources appropriées relatives aux sorties, aux documents de matériel, aux entrées de services, aux factures, à la comptabilité et au lettrage. La requête contient des valeurs fictives explicites pour les objets propres au système, car ces sources ne sont pas représentées par EKKO et EKPO seuls.
- Normalisez chaque événement source dans la même structure de journal d’événements. Chaque ligne doit contenir PurchaseOrderNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate, VendorId, UserName, TotalNetAmount, PurchaseRequisitionNumber, RequestedDeliveryDate et DocumentType. Conservez les occurrences multiples d’une activité lorsque la source contient plusieurs événements valides.
- Validez les horodatages, supprimez uniquement les lignes sources strictement dupliquées et n’inférez aucune activité dépourvue d’enregistrement source. ProcessMind lit le journal d’événements tel quel : chaque activité affichée dans la visualisation du processus doit donc figurer dans une ligne explicite.
- Exportez le résultat dans un fichier délimité ou un jeu de résultats de base de données comportant une seule ligne d’en-têtes et des noms de colonnes stables. Utilisez un format d’horodatage pris en charge par la configuration d’importation de ProcessMind, conservez PurchaseOrderNumber au format texte et importez l’intégralité du journal d’événements via la connexion de données ProcessMind configurée.
Configuration
- Objets sources : EKKO et EKPO sont les sources confirmées pour les en-têtes et les postes de commandes d’achat. Les objets supplémentaires relatifs aux demandes d’achat, au statut de validation, à l’historique des modifications, aux sorties, aux mouvements de marchandises, aux feuilles d’entrée de services, aux factures, aux paiements et au lettrage doivent être configurés selon la version SAP S/4HANA et le modèle de données actifs.
- Identifiant de cas : utilisez PurchaseOrderNumber comme identifiant de cas. Les événements au niveau du poste doivent être associés au numéro de commande d’achat, tandis que les références de poste doivent être conservées dans une colonne supplémentaire propre à la source si nécessaire.
- Période : commencez par trois à six mois. Pour les chargements historiques, traitez des périodes plus courtes et rapprochez les limites qui se chevauchent afin d’éviter les omissions.
- Filtres : configurez les filtres Company Code, Document Type, VendorId, organisation d’achat, groupe d’acheteurs et date de l’événement selon le périmètre requis. Les filtres sur le code société et le type de document doivent utiliser des valeurs valides dans le système cible.
- Sémantique des événements : la création et la suppression peuvent être explicites lorsque les champs ou journaux de documents pertinents sont disponibles. L’approbation et la clôture sont des événements fondés sur le statut et nécessitent des horodatages de statut configurés. Ne créez pas de lignes à partir du seul statut actuel sans horodatage d’événement justifiable.
- Performances : filtrez dès que possible sur les dates des événements et le périmètre organisationnel, agrégez EKPO avant de joindre les sources d’événements lorsque cela est possible et exécutez les chargements historiques volumineux par périodes. Vérifiez que les statistiques de la base de données sont adaptées et évitez les jointures sans restriction entre les sources de postes, de comptabilité et d’historique des modifications.
- Horodatage de rafraîchissement : définissez LastDataUpdate sur l’horodatage d’exécution de l’extraction pour chaque ligne d’une même exécution.
- Prérequis : les prérequis comprennent la connectivité SAP HANA, les autorisations de lecture sur tous les objets sources configurés, l’accès aux données pertinentes des achats, de la gestion des stocks, des achats de services, de la vérification des factures et des comptes fournisseurs, ainsi qu’une connexion ProcessMind capable d’importer le fichier ou le jeu de résultats sélectionné.
- Configuration propre au système : remplacez chaque valeur fictive entre crochets dans la requête par une table, une vue, une colonne ou une expression approuvée du système SAP S/4HANA cible. N’exposez pas les identifiants dans la requête ou la configuration d’extraction.
a Exemple de requête sql
WITH
params AS (
SELECT
CAST('[Start timestamp]' AS TIMESTAMP) AS start_ts,
CAST('[End timestamp]' AS TIMESTAMP) AS end_ts,
CAST(CURRENT_TIMESTAMP AS TIMESTAMP) AS last_data_update,
CAST('[Source system]' AS NVARCHAR(100)) AS source_system
FROM DUMMY
),
po_base AS (
SELECT
h.MANDT,
h.EBELN AS PurchaseOrderNumber,
h.LIFNR AS VendorId,
h.BSART AS DocumentType,
h.BUKRS AS CompanyCode,
CAST(h.AEDAT AS DATE) AS POChangedDate,
CAST(h.AEDAT AS TIMESTAMP) AS POChangedTimestamp,
CAST(h.ERNAM AS NVARCHAR(100)) AS POCreatedBy,
CAST(h.BEDAT AS DATE) AS PODate,
CAST(h.EBELN AS NVARCHAR(20)) AS PurchaseOrderKey,
CAST(SUM(COALESCE(i.NETWR, 0)) AS DECIMAL(23, 2)) AS TotalNetAmount,
CAST(MIN(i.BEDNR) AS NVARCHAR(20)) AS PurchaseRequisitionNumber,
CAST(MIN(i.EINDT) AS DATE) AS RequestedDeliveryDate
FROM EKKO h
INNER JOIN EKPO i
ON i.MANDT = h.MANDT
AND i.EBELN = h.EBELN
WHERE h.AEDAT >= (SELECT start_ts FROM params)
AND h.AEDAT < (SELECT end_ts FROM params)
AND h.BUKRS IN ([Company Code filter])
AND h.BSART IN ([Document Type filter])
GROUP BY
h.MANDT,
h.EBELN,
h.LIFNR,
h.BSART,
h.BUKRS,
h.AEDAT,
h.ERNAM,
h.BEDAT
),
po_items AS (
SELECT
i.MANDT,
i.EBELN AS PurchaseOrderNumber,
i.EBELP,
i.BANFN AS PurchaseRequisitionNumber,
i.BEDNR,
i.EINDT AS RequestedDeliveryDate
FROM EKPO i
),
events AS (
SELECT
p.PurchaseOrderNumber,
'Purchase Requisition Created' AS ActivityName,
CAST(r.[Purchase requisition creation timestamp] AS TIMESTAMP) AS EventTime,
s.source_system AS SourceSystem,
s.last_data_update AS LastDataUpdate,
p.VendorId,
CAST(r.[Purchase requisition created by] AS NVARCHAR(100)) AS UserName,
p.TotalNetAmount,
CAST(r.[Purchase requisition number] AS NVARCHAR(20)) AS PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your requisition source table or view] r
ON r.[Client] = p.MANDT
AND r.[Purchase requisition number] = p.PurchaseRequisitionNumber
CROSS JOIN params s
WHERE r.[Purchase requisition creation timestamp] >= s.start_ts
AND r.[Purchase requisition creation timestamp] < s.end_ts
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Requisition Approved' AS ActivityName,
CAST(r.[Purchase requisition approval timestamp] AS TIMESTAMP) AS EventTime,
s.source_system,
s.last_data_update,
p.VendorId,
CAST(r.[Purchase requisition approver] AS NVARCHAR(100)),
p.TotalNetAmount,
CAST(r.[Purchase requisition number] AS NVARCHAR(20)),
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your requisition approval history table or view] r
ON r.[Client] = p.MANDT
AND r.[Purchase requisition number] = p.PurchaseRequisitionNumber
CROSS JOIN params s
WHERE r.[Purchase requisition approval timestamp] >= s.start_ts
AND r.[Purchase requisition approval timestamp] < s.end_ts
AND r.[Approval status] = '[Approved status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Created',
CAST(p.PODate AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
p.POCreatedBy,
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
CROSS JOIN params s
WHERE p.PODate >= CAST(s.start_ts AS DATE)
AND p.PODate < CAST(s.end_ts AS DATE)
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Approved',
CAST(a.[Purchase order approval timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(a.[Approver] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order release history table or view] a
ON a.[Client] = p.MANDT
AND a.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE a.[Purchase order approval timestamp] >= s.start_ts
AND a.[Purchase order approval timestamp] < s.end_ts
AND a.[Release status] = '[Approved release status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Sent to Vendor',
CAST(o.[Output timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(o.[Output user] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order output source table or view] o
ON o.[Client] = p.MANDT
AND o.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE o.[Output timestamp] >= s.start_ts
AND o.[Output timestamp] < s.end_ts
AND o.[Output status] = '[Successfully processed output status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Changed',
CAST(c.[Change timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(c.[Changed by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order change history table or view] c
ON c.[Client] = p.MANDT
AND c.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE c.[Change timestamp] >= s.start_ts
AND c.[Change timestamp] < s.end_ts
AND c.[Change indicator] = '[Changed indicator value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Goods Receipt Posted',
CAST(g.[Goods movement timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(g.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your goods movement source table or view] g
ON g.[Client] = p.MANDT
AND g.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE g.[Goods movement timestamp] >= s.start_ts
AND g.[Goods movement timestamp] < s.end_ts
AND g.[Movement type] IN ([Goods receipt movement types])
AND g.[Reversal indicator] IS NULL
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Services Confirmation Entered',
CAST(v.[Service entry timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(v.[Entered by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your service entry sheet source table or view] v
ON v.[Client] = p.MANDT
AND v.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE v.[Service entry timestamp] >= s.start_ts
AND v.[Service entry timestamp] < s.end_ts
AND v.[Service entry status] = '[Accepted service entry status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Goods Returned',
CAST(g.[Goods movement timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(g.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your goods movement source table or view] g
ON g.[Client] = p.MANDT
AND g.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE g.[Goods movement timestamp] >= s.start_ts
AND g.[Goods movement timestamp] < s.end_ts
AND g.[Movement type] IN ([Goods return movement types])
AND g.[Reversal indicator] IS NULL
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Invoice Received',
CAST(i.[Invoice posting timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(i.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your supplier invoice source table or view] i
ON i.[Client] = p.MANDT
AND i.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE i.[Invoice posting timestamp] >= s.start_ts
AND i.[Invoice posting timestamp] < s.end_ts
AND i.[Invoice status] = '[Posted invoice status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Invoice Paid',
CAST(i.[Clearing timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(i.[Cleared by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your supplier invoice clearing source table or view] i
ON i.[Client] = p.MANDT
AND i.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE i.[Clearing timestamp] >= s.start_ts
AND i.[Clearing timestamp] < s.end_ts
AND i.[Clearing status] = '[Cleared status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Completed',
CAST(x.[Completion timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(x.[Completion user] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order item status source table or view] x
ON x.[Client] = p.MANDT
AND x.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE x.[Completion timestamp] >= s.start_ts
AND x.[Completion timestamp] < s.end_ts
AND x.[Delivery completed indicator] = '[Set indicator value]'
AND x.[Final invoice indicator] = '[Set indicator value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Deleted',
CAST(d.[Deletion timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(d.[Deleted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order deletion history table or view] d
ON d.[Client] = p.MANDT
AND d.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE d.[Deletion timestamp] >= s.start_ts
AND d.[Deletion timestamp] < s.end_ts
AND d.[Deletion indicator] = '[Set deletion indicator value]'
)
SELECT
PurchaseOrderNumber,
ActivityName,
EventTime,
SourceSystem,
LastDataUpdate,
VendorId,
UserName,
TotalNetAmount,
PurchaseRequisitionNumber,
RequestedDeliveryDate,
DocumentType
FROM events
WHERE PurchaseOrderNumber IS NOT NULL
AND ActivityName IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY PurchaseOrderNumber, EventTime, ActivityName; Étapes
- Spécification et conception : définissez la structure finale du fichier de journal d’événements, y compris tous les attributs requis et recommandés. Documentez les tables SAP spécifiques, par exemple EKKO, EKPO, EKBE, CDHDR et CDPOS, BKPF, qui serviront de sources pour chacune des 13 activités requises.
- Création du programme : dans SAP GUI, ouvrez l’éditeur ABAP à l’aide du code de transaction SE38 ou SE80. Créez un nouveau programme exécutable, par exemple Z_PM_PO_EXTRACT.
- Définition de l’écran de sélection : codez l’écran de sélection du rapport. Il permet aux utilisateurs de filtrer les données à extraire. Ajoutez des paramètres pour la période de création des commandes d’achat (P_AEDAT), le code société (P_BUKRS) et le type de document d’achat (P_BSART).
- Déclarations de données : définissez les tables internes et les structures de données nécessaires au programme. Cela comprend une table interne pour le journal d’événements final, conforme à la structure définie lors de l’étape de spécification.
- Mise en œuvre de la logique de sélection : écrivez la logique ABAP principale pour sélectionner les données correspondant aux 13 activités. Elle repose sur une série d’instructions SELECT exécutées sur les tables SAP pertinentes, avec des jointures lorsque cela est nécessaire. Pour les événements fondés sur des modifications, lisez les tables de journal des modifications CDHDR et CDPOS.
- Transformation et mappage des données : pour chaque enregistrement récupéré, associez les champs des tables SAP aux colonnes correspondantes de la table interne du journal d’événements final. Définissez ActivityName selon l’événement traité, par exemple « Purchase Order Created ». Convertissez les champs de date et d’heure dans un format d’horodatage cohérent pour EventTime.
- Consolidation des données d’événements : après le traitement des 13 types d’activité, vérifiez que toutes les données sont réunies dans une table interne unique et unifiée. Cette table représente alors le journal d’événements complet des commandes d’achat sélectionnées.
- Mise en œuvre de la sortie fichier : ajoutez une fonction permettant d’écrire la table interne finale dans un fichier. Il est recommandé d’utiliser la méthode cl_gui_frontend_services=>gui_download pour permettre aux utilisateurs d’enregistrer le fichier au format CSV sur leur poste local, ou d’utiliser OPEN DATASET pour l’enregistrer sur le serveur d’applications SAP dans le cadre d’un traitement en arrière-plan.
- Création d’un code de transaction, facultatif : pour faciliter l’accès au programme par les utilisateurs métier, utilisez le code de transaction SE93 afin de créer une transaction personnalisée, par exemple ZPM_PO_EXTRACT, qui exécute votre programme ABAP.
- Planification d’un job en arrière-plan : pour les volumes importants ou les extractions automatisées, utilisez le code de transaction SM36 afin de planifier l’exécution du programme en arrière-plan. Le fichier de sortie sera écrit dans le chemin du serveur d’applications indiqué dans la logique du programme.
Configuration
- Critères de sélection : le programme doit comporter des paramètres de sélection permettant de filtrer efficacement les données. Les principaux filtres sont les suivants :
- Période : une période obligatoire pour la date de création des commandes d’achat (EKKO-AEDAT). Il est recommandé de commencer par une période de 3 à 6 mois afin de maîtriser le volume de données et les performances du rapport.
- Code société (BUKRS) : indispensable pour les organisations comprenant plusieurs entités juridiques, afin de restreindre le périmètre de l’extraction.
- Type de document d’achat (BSART) : permet de filtrer certains types de commandes d’achat, comme les commandes standard, les commandes-cadres ou les commandes de transfert de stock, afin de cibler l’analyse.
- Lecture du journal des modifications : l’extraction d’activités telles que « Purchase Order Approved » ou « Purchase Order Changed » repose sur la lecture des tables du journal des modifications SAP (CDHDR, CDPOS). Cette opération peut mobiliser beaucoup de ressources. La logique ABAP doit être optimisée pour ne sélectionner que les classes d’objets nécessaires (EINKBELEG, BANF) ainsi que les combinaisons de tables et de champs pertinentes.
- Autorisations : l’utilisateur ou le compte technique qui exécute ce rapport doit disposer d’importantes autorisations de lecture sur les tables de plusieurs modules SAP, notamment Materials Management (MM), Financial Accounting (FI) et les tables communes au système. Cela comprend notamment EKKO, EKPO, EBAN, EKBE, BKPF, BSAK, RBKP, NAST, CDHDR et CDPOS.
- Exécution en arrière-plan : pour les extractions couvrant plus de quelques mois ou exécutées dans un système à fort volume transactionnel, lancez toujours le programme en arrière-plan afin d’éviter les dépassements de délai des processus de dialogue.
a Exemple de requête abap
REPORT z_pm_po_extract.
" ====================================================================
" SELECTION SCREEN
" ====================================================================
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
SELECT-OPTIONS: s_aedat FOR sy-datum OBLIGATORY.
SELECT-OPTIONS: s_bukrs FOR ekko-bukrs.
SELECT-OPTIONS: s_bsart FOR ekko-bsart.
PARAMETERS: p_sysid TYPE string DEFAULT '[Your SAP System ID]'.
SELECTION-SCREEN END OF BLOCK b1.
" ====================================================================
" DATA DECLARATIONS
" ====================================================================
TYPES: BEGIN OF ty_event_log,
purchaseordernumber TYPE ebeln,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
vendorid TYPE lifnr,
username TYPE ernam,
totalnetamount TYPE netwr,
purchaserequisitionnumber TYPE banfn,
requesteddeliverydate TYPE eedat,
documenttype TYPE bsart,
END OF ty_event_log.
DATA: lt_event_log TYPE TABLE OF ty_event_log,
ls_event_log TYPE ty_event_log.
DATA: lt_ekko TYPE TABLE OF ekko,
lt_ekpo TYPE TABLE OF ekpo.
" ====================================================================
" START OF SELECTION
" ====================================================================
START-OF-SELECTION.
" Get current timestamp for LastDataUpdate
GET TIME STAMP FIELD ls_event_log-lastdataupdate.
ls_event_log-sourcesystem = p_sysid.
" --- Initial Data Selection: Purchase Orders in Scope ---
SELECT * FROM ekko INTO TABLE lt_ekko
WHERE aedat IN s_aedat
AND bukrs IN s_bukrs
AND bsart IN s_bsart.
IF lt_ekko IS INITIAL.
MESSAGE 'No Purchase Orders found for the given criteria.' TYPE 'S' DISPLAY LIKE 'E'.
RETURN.
ENDIF.
SELECT * FROM ekpo INTO TABLE lt_ekpo
FOR ALL ENTRIES IN lt_ekko
WHERE ebeln = lt_ekko-ebeln.
" --- 1. Purchase Requisition Created ---
SELECT ban.banfn, ban.erdat, ban.erzet, ban.ernam,
ekpo.ebeln, ekpo.netwr, ekpo.eindt, ekpo.bsart, ekpo.lifnr, ekko.bukrs
FROM eban AS ban
INNER JOIN ekpo AS ekpo ON ban.banfn = ekpo.banfn AND ban.bnfpo = ekpo.bnfpo
INNER JOIN ekko AS ekko ON ekpo.ebeln = ekko.ebeln
WHERE ekko.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_pr_created).
LOOP AT lt_pr_created INTO DATA(ls_pr_created).
ls_event_log-purchaseordernumber = ls_pr_created-ebeln.
ls_event_log-activityname = 'Purchase Requisition Created'.
CONVERT DATE ls_pr_created-erdat TIME ls_pr_created-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-vendorid = ls_pr_created-lifnr.
ls_event_log-username = ls_pr_created-ernam.
ls_event_log-totalnetamount = ls_pr_created-netwr.
ls_event_log-purchaserequisitionnumber = ls_pr_created-banfn.
ls_event_log-requesteddeliverydate = ls_pr_created-eindt.
ls_event_log-documenttype = ls_pr_created-bsart.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 2. Purchase Requisition Approved (via Change Docs on Release Indicator) ---
SELECT h.objectid, h.udate, h.utime, h.username
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.objectclas = p.objectclas AND h.objectid = p.objectid AND h.changenr = p.changenr
INNER JOIN ekpo AS ekpo ON h.objectid = ekpo.banfn
INNER JOIN ekko AS ekko ON ekpo.ebeln = ekko.ebeln
WHERE h.objectclas = 'BANF'
AND p.tabname = 'EBAN'
AND p.fname = 'FRGZU'
AND p.value_new = 'X' "Configure based on your system release indicator for 'Approved'
AND ekko.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_pr_approved).
LOOP AT lt_pr_approved INTO DATA(ls_pr_approved).
SELECT SINGLE ebeln FROM ekpo INTO ls_event_log-purchaseordernumber WHERE banfn = ls_pr_approved-objectid.
ls_event_log-activityname = 'Purchase Requisition Approved'.
CONVERT DATE ls_pr_approved-udate TIME ls_pr_approved-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_pr_approved-username.
" Other attributes can be populated with another SELECT if needed.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 3. Purchase Order Created ---
LOOP AT lt_ekko INTO DATA(ls_ekko_created).
ls_event_log-purchaseordernumber = ls_ekko_created-ebeln.
ls_event_log-activityname = 'Purchase Order Created'.
CONVERT DATE ls_ekko_created-aedat TIME ls_ekko_created-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-vendorid = ls_ekko_created-lifnr.
ls_event_log-username = ls_ekko_created-ernam.
ls_event_log-totalnetamount = ls_ekko_created-rlwrt.
ls_event_log-purchaserequisitionnumber = ''. "Can be enriched later if needed
ls_event_log-requesteddeliverydate = ''. "Can be enriched from EKPO
ls_event_log-documenttype = ls_ekko_created-bsart.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 4. Purchase Order Approved (via Change Docs on Release Indicator) ---
SELECT h.objectid, h.udate, h.utime, h.username
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.objectclas = p.objectclas AND h.objectid = p.objectid AND h.changenr = p.changenr
WHERE h.objectclas = 'EINKBELEG'
AND p.tabname = 'EKKO'
AND p.fname = 'FRGKE'
AND p.value_new = 'R' "R for Released
AND h.objectid IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_approved).
LOOP AT lt_po_approved INTO DATA(ls_po_approved).
ls_event_log-purchaseordernumber = ls_po_approved-objectid.
ls_event_log-activityname = 'Purchase Order Approved'.
CONVERT DATE ls_po_approved-udate TIME ls_po_approved-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_approved-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 5. Purchase Order Sent to Vendor ---
SELECT n.objky, n.vstat, n.datvr, n.uhrvr, e.ernam
FROM nast AS n
INNER JOIN ekko AS e ON n.objky = e.ebeln
WHERE n.kappl = 'EF' "Application for Purchasing
AND n.kschl = '[Your PO Output Type]' "e.g. NEU
AND n.vstat = '1' "Successfully processed
AND n.objky IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_sent).
LOOP AT lt_po_sent INTO DATA(ls_po_sent).
ls_event_log-purchaseordernumber = ls_po_sent-objky.
ls_event_log-activityname = 'Purchase Order Sent to Vendor'.
CONVERT DATE ls_po_sent-datvr TIME ls_po_sent-uhrvr INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_sent-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 6. Purchase Order Changed ---
SELECT objectid, udate, utime, username FROM cdhdr
WHERE objectclas = 'EINKBELEG'
AND tcode IN ('ME22', 'ME22N')
AND objectid IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_changed).
LOOP AT lt_po_changed INTO DATA(ls_po_changed).
ls_event_log-purchaseordernumber = ls_po_changed-objectid.
ls_event_log-activityname = 'Purchase Order Changed'.
CONVERT DATE ls_po_changed-udate TIME ls_po_changed-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_changed-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 7. Goods Receipt Posted & 9. Goods Returned ---
SELECT e.ebeln, m.budat, m.cpudt, m.cputm, m.usnam, b.shkzg, b.bwart
FROM mkpf AS m
INNER JOIN mseg AS s ON m.mblnr = s.mblnr AND m.mjahr = s.mjahr
INNER JOIN t156 AS t ON s.bwart = t.bwart
INNER JOIN ekbe AS e ON s.ebeln = e.ebeln AND s.ebelp = e.ebelp AND s.mblnr = e.belnr AND s.mjahr = e.gjahr
WHERE e.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
AND e.bwart IN ('101', '102', '122', '123') "GR, GR Reversal, Return
INTO TABLE @DATA(lt_goods_mvmt).
LOOP AT lt_goods_mvmt INTO DATA(ls_goods_mvmt).
ls_event_log-purchaseordernumber = ls_goods_mvmt-ebeln.
IF ls_goods_mvmt-bwart = '101'.
ls_event_log-activityname = 'Goods Receipt Posted'.
ELSE.
ls_event_log-activityname = 'Goods Returned'.
ENDIF.
CONVERT DATE ls_goods_mvmt-cpudt TIME ls_goods_mvmt-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_goods_mvmt-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 8. Services Confirmation Entered ---
SELECT h.erdat, h.erzeit, h.ernam, l.ebeln
FROM essr AS h
INNER JOIN esll AS l ON h.lblni = l.lblni
WHERE l.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_services).
LOOP AT lt_services INTO DATA(ls_services).
ls_event_log-purchaseordernumber = ls_services-ebeln.
ls_event_log-activityname = 'Services Confirmation Entered'.
CONVERT DATE ls_services-erdat TIME ls_services-erzeit INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_services-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 10. Invoice Received ---
SELECT r.ebeln, r.cpudt, r.cputm, r.usnam
FROM rbkp AS r
WHERE r.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_invoice_rcvd).
LOOP AT lt_invoice_rcvd INTO DATA(ls_invoice_rcvd).
ls_event_log-purchaseordernumber = ls_invoice_rcvd-ebeln.
ls_event_log-activityname = 'Invoice Received'.
CONVERT DATE ls_invoice_rcvd-cpudt TIME ls_invoice_rcvd-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_invoice_rcvd-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 11. Invoice Paid ---
SELECT b.ebeln, s.augdt, s.augbl, b.usnam
FROM rbkp AS b
INNER JOIN bseg AS e ON b.belnr = e.belnr AND b.gjahr = e.gjahr
INNER JOIN bsak AS s ON e.bukrs = s.bukrs AND e.belnr = s.belnr AND e.gjahr = s.gjahr AND e.buzei = s.buzei
WHERE b.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
AND s.augdt IS NOT NULL
INTO TABLE @DATA(lt_invoice_paid).
LOOP AT lt_invoice_paid INTO DATA(ls_invoice_paid).
ls_event_log-purchaseordernumber = ls_invoice_paid-ebeln.
ls_event_log-activityname = 'Invoice Paid'.
CONVERT DATE ls_invoice_paid-augdt INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_invoice_paid-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 12. Purchase Order Completed & 13. Purchase Order Deleted (via Change Docs) ---
SELECT h.objectid, h.udate, h.utime, h.username, p.fname
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.changenr = p.changenr
INNER JOIN ekpo AS ekpo ON h.objectid = |{ ekpo.ebeln }{ ekpo.ebelp }|
WHERE h.objectclas = 'EINKBELEG'
AND p.tabname = 'EKPO'
AND p.fname IN ('ELIKZ', 'EREKZ', 'LOEKZ')
AND p.value_new = 'X'
AND ekpo.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_status_change).
LOOP AT lt_po_status_change INTO DATA(ls_po_status_change).
ls_event_log-purchaseordernumber = substring( val = ls_po_status_change-objectid, off = 0, len = 10 ).
CASE ls_po_status_change-fname.
WHEN 'LOEKZ'.
ls_event_log-activityname = 'Purchase Order Deleted'.
WHEN 'ELIKZ' OR 'EREKZ'.
"This logic may need refinement to check if both are now set.
ls_event_log-activityname = 'Purchase Order Completed'.
ENDCASE.
CONVERT DATE ls_po_status_change-udate TIME ls_po_status_change-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_status_change-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- Final Output to CSV ---
CALL METHOD cl_gui_frontend_services=>gui_download
EXPORTING
filename = 'C:\temp\po_event_log.csv'
filetype = 'ASC'
CHANGING
data_tab = lt_event_log. Prêt à commencer ?
Ce modèle constitue une base solide pour commencer votre démarche de Process Mining. Commencez dès aujourd’hui à utiliser vos données SAP S/4HANA pour révéler les gains d’efficacité et transformer votre processus Purchase to Pay.
Optimisez vos commandes d’achat P2P et réduisez dès maintenant la durée du cycle
Éliminez les inefficacités et réduisez de 30 % la durée du cycle de vos commandes d’achat P2P.
Aucune carte bancaire requise. La configuration ne prend que quelques minutes.