Votre modèle de données Purchase to Pay - Purchase Order
Votre modèle de données Purchase to Pay - Purchase Order
- 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
Attributs du processus Purchase to Pay - Purchase Order
| Nom | Description | ||
|---|---|---|---|
| Activité ActivityName | Nom de l’événement ou de l’étape métier qui s’est produit dans le processus de commande d’achat. | ||
| Description Cet attribut décrit une action ou un changement de statut précis dans le cycle de vie d’une commande d’achat, par exemple « Commande d’achat créée », « Commande d’achat approuvée » ou « Entrée de marchandises enregistrée ». La succession de ces activités constitue le flux du processus. L’analyse de l’ordre et de la fréquence des activités est au cœur du process mining. Elle permet de découvrir le processus réel, de le comparer au modèle prévu, de repérer les goulots d’étranglement, par exemple les longues attentes après la « Réception de la facture », et de quantifier les reprises, comme les modifications répétées d’une commande d’achat. Pourquoi est-ce important ? Cet attribut définit les étapes du processus et permet de représenter et d’analyser le flux de bout en bout, les variantes et les goulots d’étranglement. Où trouver ces données Cet attribut est généralement établi à partir d’une combinaison de tables et de champs, comme les champs de statut dans EKKO/EKPO ou les journaux de documents de modification dans CDHDR/CDPOS, afin de représenter les principales étapes métier. Exemples Commande d’achat crééeCommande d’achat approuvéeEntrée de marchandises enregistréeFacture reçue | |||
| Commande d’achat PurchaseOrderNumber | Identifiant unique de la commande d’achat, qui sert d’ID de cas principal 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 de cas pour l’analyse par process mining. En regroupant les événements par numéro de commande, vous pouvez reconstituer le parcours de chaque commande. C’est indispensable pour calculer les temps de cycle, analyser les variantes du processus et repérer les goulots d’étranglement ou les écarts propres à une commande. Pourquoi est-ce important ? C’est la clé indispensable pour relier tous les événements d’approvisionnement au sein d’un même processus de bout en bout et analyser en détail le cycle de vie de chaque commande d’achat. Où trouver ces données Cet attribut se trouve dans la table EKKO de SAP S/4HANA, champ EBELN. Exemples 450001712345000171244500017125 | |||
| Heure de l’événement EventTime | Horodatage indiquant le moment où l’activité s’est produite. | ||
| Description Cet attribut consigne la date et l’heure exactes de chaque activité du processus. Il est indispensable à toutes les analyses temporelles réalisées avec le process mining. L’heure de l’événement sert à classer les activités par ordre chronologique et à reconstituer le flux du processus. Elle permet également de calculer 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, essentiels à l’analyse des performances et à la détection des goulots d’étranglement. Pourquoi est-ce important ? Cet horodatage est essentiel pour remettre les événements dans le bon ordre et calculer tous les indicateurs de performance, notamment les temps de cycle, les délais et les temps d’attente. Où trouver ces données Champs d’horodatage associés à des activités précises, comme la date de création (EKKO-AEDAT pour les modifications) ou la date comptable (MKPF-BUDAT pour les entrées de marchandises). Il faut souvent 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 de la dernière actualisation ou extraction des données depuis le système source. | ||
| Description Cet attribut indique l’actualité des données analysées. Il précise la date et l’heure de la dernière extraction des données depuis SAP S/4HANA. La date de la dernière mise à jour aide les utilisateurs à évaluer l’actualité de leur analyse. Ils peuvent ainsi interpréter correctement les résultats, en sachant s’ils consultent des informations en temps réel ou un instantané datant d’un moment précis. Cette distinction influe sur la pertinence des décisions prises à partir de l’analyse. Pourquoi est-ce important ? Indique aux utilisateurs l’actualité des données afin qu’ils comprennent le contexte et la pertinence des résultats de leur analyse. Où trouver ces données Il s’agit d’un horodatage de métadonnées ajouté pendant le 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énement, par exemple « SAP S/4HANA Production » ou « SAP ECC ». Dans un environnement comportant plusieurs systèmes, ce champ est essentiel pour assurer la traçabilité des données, résoudre les problèmes et interpréter correctement les données provenant de différentes sources. Il aide à comprendre leur contexte et permet de filtrer l’analyse selon l’environnement système concerné. Pourquoi est-ce important ? Cet attribut fournit un contexte essentiel sur l’origine des données, indispensable à leur gouvernance, à leur validation et à leur analyse dans des environnements comportant plusieurs systèmes. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée pendant le processus d’extraction, de transformation et de chargement (ETL) pour indiquer 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 indique la date de livraison prévue, convenue dans la commande d’achat. Elle sert de référence pour mesurer les performances de livraison du fournisseur. Avec le process mining, cette date est comparée à la date réelle de réception des marchandises, indiquée par l’horodatage « Entrée de marchandises enregistrée », afin de calculer l’indicateur clé de performance du taux de livraisons des fournisseurs dans les délais. L’analyse des écarts permet d’évaluer la fiabilité des fournisseurs et de gérer les risques liés à la chaîne d’approvisionnement. Pourquoi est-ce important ? Sert de référence pour mesurer les livraisons des fournisseurs dans les délais, un indicateur clé de performance pour la gestion de la chaîne d’approvisionnement et la planification opérationnelle. Où trouver ces données Cet attribut se trouve dans la table des échéances EKET, champ EINDT. Exemples 2023-06-012023-06-152023-07-01 | |||
| Demande d’achat PurchaseRequisitionNumber | Identifiant de la demande d’achat (PR) à l’origine de la commande d’achat. | ||
| Description Cet attribut relie la commande d’achat à la demande d’achat dont elle est issue. Certaines commandes n’ont pas de demande d’achat préalable, car elles sont créées directement. Ce lien est essentiel pour analyser l’ensemble du processus d’approvisionnement, depuis la demande initiale. Il permet de suivre des indicateurs clés tels que le délai d’approbation des demandes d’achat et de repérer les achats non autorisés, c’est-à-dire les commandes créées sans demande préalable approuvée. Pourquoi est-ce important ? Relie la commande d’achat à la demande initiale, ce qui permet d’analyser le processus de bout en bout et de repérer les achats non autorisés et non conformes. Où trouver ces données Cet attribut se trouve dans la table EKPO de SAP S/4HANA, au niveau du poste de commande d’achat, champ BANFN. Exemples 1001005110010052 | |||
| ID du fournisseur VendorId | Identifiant unique du fournisseur qui fournit les biens ou les services. | ||
| Description L’ID du fournisseur est une donnée de référence essentielle qui relie une commande d’achat à un fournisseur précis. Il est utilisé tout au long du processus d’approvisionnement pour les communications, les livraisons et les paiements. Avec le process mining, cet attribut permet d’analyser les performances par fournisseur. Il est indispensable pour des Dashboards tels que « Performance des délais de livraison des fournisseurs » et « Taux de retour des marchandises par fournisseur ». Vous pouvez ainsi repérer les fournisseurs les plus fiables et ceux qui sont susceptibles d’entraîner des retards ou des problèmes de qualité. Pourquoi est-ce important ? Permet d’analyser le processus par fournisseur, d’évaluer les performances, de repérer les fournisseurs les plus et les moins performants et d’optimiser la chaîne d’approvisionnement. Où trouver ces données Cet attribut se trouve dans la table EKKO de SAP S/4HANA, champ LIFNR. Exemples 100023100045100088 | |||
| Montant net total TotalNetAmount | Valeur totale de la commande d’achat, hors taxes et frais de transport. | ||
| Description Cet attribut représente la valeur monétaire nette de la commande d’achat. Il s’agit d’un indicateur financier clé qui reflète l’importance de la transaction d’approvisionnement. Ce montant est essentiel à l’analyse financière. Vous pouvez, par exemple, classer les commandes selon leur valeur, élevée ou faible, pour vérifier si elles suivent des parcours différents. Il permet également de prioriser les analyses en se concentrant sur les commandes de valeur élevée, qui peuvent présenter un risque financier supérieur ou avoir une incidence plus importante sur l’activité. Pourquoi est-ce important ? Permet d’analyser les commandes d’achat selon leur valeur et de concentrer les efforts d’amélioration des processus sur les dépenses les plus importantes. Où trouver ces données Cet attribut se trouve dans la table EKKO de SAP S/4HANA, champ NETWR. Exemples 1500.0025000.50125.75 | |||
| Type de document de commande d’achat DocumentType | Classification qui distingue les différents types de commandes d’achat, comme les commandes standard, les commandes de services ou les commandes de transfert de stock. | ||
| Description Dans SAP, le type de document est un élément de configuration essentiel qui détermine le flux du processus, la plage de numéros et les champs d’une commande d’achat. Il permet aux entreprises d’adapter le processus d’approvisionnement à différents cas de figure. L’analyse du processus par type de document est essentielle pour comprendre les variations. Par exemple, le processus d’une commande standard de marchandises peut différer considérablement de celui d’une commande de services ou d’un transfert de stock. Cet attribut permet de filtrer et de comparer ces différents flux afin de repérer des possibilités d’amélioration précises. Pourquoi est-ce important ? Classe les commandes d’achat par catégorie, ce qui permet de comparer les processus d’approvisionnement et de comprendre les variations des flux et des temps de cycle. Où trouver ces données Cet attribut se trouve dans la table EKKO de SAP S/4HANA, champ BSART. Exemples NBFOUB | |||
| Utilisateur UserName | Identifiant de l’utilisateur qui a effectué une activité donnée. | ||
| Description Cet attribut enregistre l’ID utilisateur SAP de la personne qui a créé, modifié ou approuvé un document. Il assure la traçabilité des actions réalisées dans le système. L’analyse par utilisateur aide à repérer les besoins de formation, à répartir la charge de travail et à évaluer les performances individuelles. Elle permet, par exemple, de vérifier 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’orienter la gestion des ressources et l’amélioration du processus. Pourquoi est-ce important ? Assure la traçabilité des responsabilités et permet d’analyser les performances à l’échelle individuelle ou collective, afin de repérer les besoins de formation ou les contraintes de ressources. Où trouver ces données Ces informations figurent dans des champs tels que ERNAM (Créé par) dans EKKO ou dans le champ utilisateur des tables de documents de modification (CDHDR-USERNAME). Exemples CB9980000012JSMITHRROE | |||
| Achats hors contrat IsMaverickSpend | Indicateur calculé qui précise si une commande d’achat a été créée sans demande d’achat préalable approuvée. | ||
| Description Cet indicateur booléen est calculé lors du traitement des données. Il prend la valeur « true » si aucune demande d’achat n’est associée à une commande d’achat ou si la création de la commande contourne le flux d’approbation standard. Cet attribut alimente directement le Dashboard « Identification des achats hors contrat » et les KPI associés. Il permet de quantifier les achats non conformes et d’identifier les services ou groupes d’utilisateurs concernés afin de renforcer les politiques et les contrôles d’approvisionnement. Pourquoi est-ce important ? Repère directement les achats non conformes, aide à quantifier les écarts de processus et contribue à faire respecter les contrôles financiers et les politiques d’approvisionnement. Où trouver ces données Champ calculé à partir de l’absence de valeur dans « PurchaseRequisitionNumber » pour certains types de documents, ou de l’analyse de la séquence des événements. Exemples truefalse | |||
| Catégorie de poste ItemCategory | Classe le poste d’une commande d’achat, par exemple comme poste standard, de consignation, de sous-traitance ou de service. | ||
| 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 l’entrée de 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 traitement d’un poste de service, qui nécessite une feuille de saisie des services, diffère sensiblement de celui d’un article standard en stock. L’analyse par catégorie de poste aide à comprendre ces différences et à cibler les améliorations. Pourquoi est-ce important ? Décrit les variantes du processus en distinguant les différents types d’approvisionnement, par exemple les marchandises, les services ou la sous-traitance. Où trouver ces données Cet attribut se trouve dans la table EKPO de SAP S/4HANA, dans le 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é désigne une unité comptable indépendante au sein d’une organisation. Toutes les opérations financières liées à une commande d’achat sont imputées à un code société précis. Cet attribut organisationnel fondamental permet de filtrer et de comparer les processus d’approvisionnement entre différentes entités juridiques. Une analyse par code société peut révéler des écarts dans l’exécution des processus, des différences d’efficacité ou des niveaux de conformité variables au sein de l’organisation. Pourquoi est-ce important ? Permet de segmenter l’analyse des processus par entité juridique et de comparer les performances et la conformité entre les différentes parties de l’entreprise. Où trouver ces données Cet attribut se trouve dans la table EKKO de SAP S/4HANA, dans le champ BUKRS. Exemples 101017102000 | |||
| Groupe d’acheteurs PurchasingGroup | Groupe d’acheteurs chargé de certaines activités d’approvisionnement. | ||
| Description Un groupe d’acheteurs désigne un acheteur ou une équipe chargée d’activités d’achat, de matériaux ou de fournisseurs spécifiques. Il constitue le principal interlocuteur des fournisseurs. Cet attribut permet d’analyser la charge de travail et les performances avec davantage de précision qu’à l’échelle de l’organisation d’achats. Il aide à repérer les équipes surchargées, à mesurer l’efficacité des différents groupes d’acheteurs et à déterminer lesquels sont davantage concernés par des écarts de processus, comme les achats hors contrat. Pourquoi est-ce important ? Donne 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 à l’échelle des équipes. Où trouver ces données Cet attribut se trouve dans la table EKKO de SAP S/4HANA, dans le champ EKGRP. Exemples 001002N00 | |||
| Livraison à temps par le fournisseur SupplierOnTimeDelivery | Indicateur calculé qui précise 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é « Réception des marchandises enregistrée » à la « Date de livraison demandée ». Si la réception a lieu à la date demandée ou avant, l’attribut prend la valeur « true ». Cet attribut alimente directement le KPI « Taux de livraison à temps des fournisseurs ». Il simplifie l’analyse en permettant de filtrer facilement les livraisons à temps ou en retard, un élément essentiel des Dashboards de performance fournisseur et de l’évaluation des fournisseurs. Pourquoi est-ce important ? Mesure directement la fiabilité des fournisseurs, sert de base au KPI de livraison à temps et permet de suivre efficacement leurs performances. Où trouver ces données Calculé en comparant l’horodatage de l’activité « Réception des marchandises enregistrée » à 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 Dans SAP, le numéro de matériau est un code unique attribué à chaque fiche de données de base d’un matériau. Il sert pour toutes les opérations liées à ce matériau, notamment l’approvisionnement, la gestion des stocks et les ventes. Une analyse par numéro ou groupe de matériaux permet d’étudier les achats par catégorie de produits. Elle peut révéler si l’approvisionnement de certains types de matériaux est moins efficace, entraîne des délais plus longs ou donne lieu à davantage de retours, et ainsi éclairer la gestion des catégories. Pourquoi est-ce important ? Permet d’analyser les achats par catégorie de produits et de repérer les problèmes de processus ou de performance fournisseur liés à des produits ou matériaux précis. Où trouver ces données Cet attribut se trouve dans la table EKPO de SAP S/4HANA, dans le champ MATNR. Exemples RM100-100FG210SERV-CONSULT | |||
| Organisation d’achats PurchasingOrganization | Unité organisationnelle chargée de l’approvisionnement en matériaux et services ainsi que des négociations avec les fournisseurs. | ||
| Description L’organisation d’achats est une unité organisationnelle clé de l’approvisionnement. Elle peut être structurée à l’échelle du groupe, de la société ou de l’usine, et prend en charge 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 les négociations avec les fournisseurs, le respect des processus ou les délais d’approbation entre les unités organisationnelles. Pourquoi est-ce important ? Permet de comparer les performances des différents services ou régions d’approvisionnement, afin de repérer les bonnes pratiques et les points à améliorer. Où trouver ces données Cet attribut se trouve dans la table EKKO de SAP S/4HANA, dans le champ EKORG. Exemples 10101710US01 | |||
| Reprises IsRework | Indicateur calculé qui précise si la commande d’achat a fait l’objet de reprises, par exemple après une modification suivant l’approbation ou un retour de marchandises. | ||
| Description Cet attribut booléen est calculé à partir de la séquence des activités de chaque commande d’achat. Il prend la valeur « true » si l’événement « Commande d’achat modifiée » survient après l’événement « Commande d’achat approuvée », ou si un événement « Marchandises retournées » est présent. Cet indicateur simplifie le calcul du KPI « Taux de traitement sans intervention ». Il permet de filtrer et de visualiser facilement les commandes d’achat qui ont nécessité une intervention ou une correction manuelle, afin d’en mesurer le coût et la fréquence. Pourquoi est-ce important ? Aide à mesurer les inefficacités du processus en repérant les cas avec reprises, ce qui est essentiel pour calculer le taux de traitement sans intervention et déterminer les causes des écarts. Où trouver ces données Champ calculé à partir de la séquence des activités. La logique vérifie si un événement « Commande d’achat modifiée » survient après une approbation ou si un événement « Marchandises retournées » est présent. Exemples truefalse | |||
| Usine Plant | Site ou lieu d’exploitation où les marchandises sont livrées ou les services fournis. | ||
| Description Dans SAP, une usine est un site physique où des marchandises sont produites ou stockées, ou des services sont réalisés. Elle joue un rôle clé dans la logistique et la planification. La segmentation de l’analyse par usine peut révéler des différences régionales ou propres à un site dans le processus d’approvisionnement. Elle peut, par exemple, montrer si certaines usines connaissent des délais de livraison plus longs ou un taux de retour des marchandises plus élevé, ce qui peut signaler des problèmes locaux de logistique ou de contrôle qualité. Pourquoi est-ce important ? Permet une analyse par site et met en évidence les différences de performance entre les sites opérationnels, les usines ou les entrepôts. Où trouver ces données Cet attribut se trouve dans la table EKPO de SAP S/4HANA, dans le champ WERKS. Exemples 10101710DE01 | |||
Activités du processus Purchase to Pay - Purchase Order
| Activité | Description | ||
|---|---|---|---|
| Commande d’achat approuvée | Cette activité indique que la commande d’achat a reçu toutes les approbations internes requises et qu’elle peut être envoyée au fournisseur. L’événement est déduit d’un changement de statut dans la stratégie de validation de la commande. | ||
| Pourquoi est-ce important ? Cette étape clé permet de mesurer l’efficacité des approbations et les reprises après approbation. Le délai entre la création et l’approbation de la commande met en évidence les retards du processus interne. Où trouver ces données L’événement est déduit de l’indicateur de validation (FRGKE) dans la table EKKO. L’horodatage est déterminé à partir de l’historique des modifications (CDHDR/CDPOS), qui indique quand ce champ a pris le statut « libéré ». Données à recueillir Événement déduit des journaux de modification du champ de l’indicateur de validation (FRGKE) dans la table EKKO. Type d’événement inferred | |||
| Commande d’achat créée | Cette activité marque la création du document officiel de commande d’achat, avec ou sans référence à une demande d’achat. L’événement est enregistré explicitement lorsque le document de commande est enregistré pour la première fois dans le système. | ||
| Pourquoi est-ce important ? Cette activité peut constituer un autre point de départ pour l’analyse du processus, notamment pour repérer les achats non autorisés. C’est un événement fondamental pour suivre le temps de traitement global des commandes d’achat. Où trouver ces données L’événement est enregistré dans la table d’en-tête des commandes d’achat EKKO. La date de création (AEDAT) et l’heure du document y sont stockées directement. Données à recueillir Horodatage de création (AEDAT) du document de commande d’achat dans la table EKKO. Type d’événement explicit | |||
| Commande d’achat terminée | Cette activité indique qu’un poste de commande d’achat est considéré comme clôturé du point de vue logistique. Elle est déduite lorsque les indicateurs « Livraison terminée » et « Facture finale » sont tous deux activés. | ||
| Pourquoi est-ce important ? Cette activité marque la fin du cycle de vie de la commande d’achat. Le délai jusqu’à cet événement correspond au temps de cycle de bout en bout des opérations d’approvisionnement. Où trouver ces données L’événement est déduit des indicateurs de statut du poste de commande d’achat dans la table EKPO. Il se produit lorsque les indicateurs « Livraison terminée » (ELIKZ) et « Facture finale » (EREKZ) sont tous deux activés. Données à recueillir Événement déduit des journaux de modification lorsque les champs ELIKZ et EREKZ de la table EKPO indiquent tous deux que le poste est terminé. Type d’événement inferred | |||
| Demande d’achat approuvée | Cette activité correspond à l’approbation officielle d’une demande d’achat par un responsable ou un approbateur désigné. Elle est généralement déduite d’un changement de statut du document, qui indique que la demande peut être convertie en commande d’achat. | ||
| Pourquoi est-ce important ? Cette étape clé permet de suivre les temps de cycle d’approbation et de repérer les goulots d’étranglement. Tout retard à ce stade ralentit directement la création et l’envoi de la commande d’achat au fournisseur. Où trouver ces données L’événement est déduit des champs de statut de validation de la table EBAN, par exemple FRGZU, l’indicateur de validation. L’horodatage provient des documents de modification (CDHDR/CDPOS), qui indiquent quand le statut de validation final a été défini. Données à recueillir Événement déduit des journaux de modification (CDHDR/CDPOS) des champs de statut de validation de la table EBAN. Type d’événement inferred | |||
| Demande d’achat 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 enregistre un nouveau document de demande d’achat, par exemple avec la transaction ME51N. | ||
| Pourquoi est-ce important ? C’est le point de départ de nombreux cycles de vie de commande d’achat. Analyser le délai entre cet événement et la création de la commande permet de repérer les retards liés à la recherche de fournisseurs et au traitement interne. Où trouver ces données L’événement est enregistré dans la table EBAN (demande d’achat). Son horodatage de création figure dans l’historique des modifications des tables CDHDR et CDPOS pour l’objet EBAN. Données à recueillir Événement enregistré lors de la création d’un document dans la table EBAN. Type d’événement explicit | |||
| Entrée de marchandises enregistrée | Cette activité correspond à la réception physique des marchandises du fournisseur et à son enregistrement dans le système. Cette transaction explicite met à jour l’historique de la commande d’achat. | ||
| Pourquoi est-ce important ? Cette étape importante met fin au délai de livraison du fournisseur et marque le début du processus interne de vérification des factures. Elle est essentielle pour suivre le taux de livraisons dans les délais. Où trouver ces données L’événement est enregistré sous la forme d’un document article dans les tables MKPF (en-tête) et MSEG (poste), puis lié à l’historique de la commande d’achat dans la table EKBE avec un type de mouvement spécifique, par exemple 101. Données à recueillir Date comptable (BUDAT) de l’en-tête du document article (MKPF), liée via EKBE. Type d’événement explicit | |||
| Facture reçue | Cette activité correspond à la saisie de la facture du fournisseur dans SAP et à son association à la commande d’achat correspondante. Cette écriture financière explicite crée un document comptable. | ||
| Pourquoi est-ce important ? Cette étape clé 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ù trouver ces données 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 lié à la commande d’achat dans la table RSEG. Données à recueillir Date de saisie du document (CPUDT) dans la table d’en-tête des documents comptables BKPF. Type d’événement explicit | |||
| Commande d’achat envoyée au fournisseur | Cette activité correspond au moment où la commande d’achat est transmise au fournisseur, par exemple par EDI, par e-mail ou sous forme imprimée. L’événement est souvent enregistré dans les journaux de gestion des sorties du système. | ||
| Pourquoi est-ce important ? Cette activité marque le véritable début du délai de livraison du fournisseur. Elle est indispensable pour mesurer avec précision la performance du fournisseur à partir du moment où il reçoit la commande. Où trouver ces données L’événement est extrait de la table de contrôle des sorties NAST, qui consigne 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. Données à recueillir Horodatage du premier message de sortie envoyé avec succès pour la commande d’achat dans la table NAST. Type d’événement inferred | |||
| Commande d’achat modifiée | Cette activité indique qu’une modification a été apportée à la commande d’achat après sa création, par exemple à la quantité, au prix ou à la date de livraison. Elle est enregistrée explicitement dans les journaux de modification du système. | ||
| Pourquoi est-ce important ? Le suivi des modifications, en particulier après approbation, est essentiel pour repérer les inefficacités, les reprises et les éventuels problèmes de conformité. Des modifications fréquentes peuvent révéler des spécifications initiales insuffisantes. Où trouver ces données L’événement est enregistré dans les tables de documents de modification CDHDR (en-tête) et CDPOS (poste) pour les objets de commande d’achat (EINKBELEG). Chaque modification génère une entrée détaillée dans le journal. Données à recueillir Événement consigné lors de la modification de champs clés des tables EKKO ou EKPO, dans CDHDR/CDPOS. Type d’événement explicit | |||
| Commande d’achat supprimée | Cette activité correspond à l’annulation ou à la suppression logique d’un poste de commande d’achat ou du document entier. Elle est enregistrée lorsqu’un utilisateur active un indicateur de suppression sur le document. | ||
| Pourquoi est-ce important ? Cette activité constitue un autre point de fin du processus et signale un échec ou une annulation. L’analyse des raisons de la suppression des commandes d’achat peut révéler des problèmes de planification de la demande ou de définition des besoins. Où trouver ces données L’événement est extrait de l’indicateur de suppression (LOEKZ) dans les tables d’en-tête (EKKO) ou de poste (EKPO) de la commande d’achat. L’horodatage provient des documents de modification (CDHDR/CDPOS). Données à recueillir Horodatage des documents de modification (CDHDR/CDPOS) au moment de l’activation de l’indicateur de suppression (LOEKZ). Type d’événement explicit | |||
| Confirmation de service saisie | Cette activité indique que le service prévu dans une commande d’achat a été réalisé. Elle est enregistrée explicitement lors de la création d’une feuille de saisie des services. | ||
| Pourquoi est-ce important ? Pour les achats de services, cette étape équivaut à une entrée de marchandises. Elle est essentielle pour suivre les délais de livraison des services et permettre le paiement des fournisseurs dans les délais. Où trouver ces données L’événement est enregistré lors de la création d’une feuille de saisie des services. Les données sont stockées dans les tables ESSR (en-tête) et ESLL (lignes). La date de création sert d’horodatage. Données à recueillir Date de création du document de feuille de saisie des services dans la table ESSR. Type d’événement explicit | |||
| Facture payée | Cette activité marque le règlement final de la facture du fournisseur, par un cycle de paiement ou un paiement manuel. Cette transaction financière explicite crée un document de compensation. | ||
| Pourquoi est-ce important ? Bien que cette activité relève techniquement du processus de paiement, son inclusion donne une vue complète du cycle Purchase to Pay. Elle est essentielle pour analyser les conditions et les performances de paiement. Où trouver ces données Le paiement est enregistré sous la forme d’un document de compensation dans BKPF/ACDOCA. La date de compensation (AUGDT) du poste de facture dans la table BSEG ou ACDOCA indique l’événement de paiement. Données à recueillir Date de compensation (AUGDT) du document de facture, dans BSEG ou ACDOCA. Type d’événement explicit | |||
| Marchandises retournées | Cette activité indique que des marchandises précédemment reçues ont été retournées au fournisseur, généralement en raison d’un problème de qualité, d’un dommage ou d’une erreur de livraison. Elle est enregistrée explicitement comme une contre-passation de mouvement de marchandises. | ||
| Pourquoi est-ce important ? Cette activité met en évidence les reprises et les problèmes éventuels de qualité du fournisseur ou d’exactitude de la commande. Des retours fréquents pour un fournisseur ou un article donné signalent un problème. Où trouver ces données L’événement est enregistré sous la forme d’un document article avec un type de mouvement de retour spécifique, par exemple 122. Il est consigné dans MKPF/MSEG et lié à la commande d’achat dans l’historique de la table EKBE. Données à recueillir Date comptable du document article associé à un type de mouvement de retour dans EKBE. Type d’événement explicit | |||
Guides d’extraction
Étapes
- Prérequis et accès : vérifiez que vous disposez d’un utilisateur autorisé à interroger les vues Core Data Services (CDS) dans le système SAP S/4HANA. Vous pouvez y accéder avec SAP HANA Studio, ABAP Development Tools (ADT) pour Eclipse ou un outil tiers d’extraction de données prenant en charge les connexions SQL à la base SAP HANA.
- Repérez les paramètres de connexion au système : récupérez les paramètres nécessaires pour vous connecter à 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 : avec le client SQL de votre choix, établissez une connexion à la base SAP S/4HANA où se trouvent les vues CDS.
- Préparez la requête SQL : copiez dans votre éditeur SQL la requête complète fournie dans la section correspondante de ce document. Elle 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 de remplacement 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 pour 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 choisie, l’exécution peut prendre un certain temps.
- Vérifiez les premiers résultats : une fois la requête terminée, examinez rapidement les résultats dans votre client SQL. Vérifiez que les différentes activités sont présentes, que les horodatages sont correctement renseignés et que l’identifiant de cas (PurchaseOrderNumber) est cohérent.
- Exportez les données : exportez l’ensemble des résultats depuis votre outil SQL dans un fichier CSV (valeurs séparées par des virgules). Vérifiez que le fichier utilise l’encodage UTF-8 pour éviter les problèmes de caractères.
- Préparez l’importation : avant d’importer le fichier dans ProcessMind, ouvrez-le et vérifiez que les en-têtes de colonnes correspondent exactement aux attributs définis dans les exigences relatives aux données (PurchaseOrderNumber, ActivityName, EventTime, etc.). Modifiez les noms de colonnes si votre outil d’exportation les a changés.
- Importez les données dans ProcessMind : importez le fichier CSV final dans votre projet ProcessMind. Pendant l’importation, associez les colonnes du fichier aux champs correspondants pour l’identifiant de cas, l’activité et l’horodatage.
Configuration
- Principales vues CDS utilisées : la logique d’extraction s’appuie sur plusieurs vues CDS standard, riches en informations sémantiques. Les principales sont les suivantes :
- I_PurchaseOrderItemAPI01 : données essentielles sur les 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 de service.
- I_SupplierInvoiceAPI01 : informations sur les factures fournisseurs.
- I_OperationalAcctgDocItem : association des factures aux documents financiers pour le suivi des paiements.
- I_ChangeDocument : modifications apportées aux commandes d’achat.
- Filtrage par période : il est essentiel de filtrer les données par période afin de maîtriser les performances et le volume de données. La requête utilise les valeurs de remplacement _start_date et _end_date pour filtrer la date de création des commandes 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 spécifiques liés aux activités métier ou à l’analyse dans S/4HANA. Sans les autorisations nécessaires, la requête échouera.
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 vous disposez d’un accès SQL direct au schéma SAP HANA contenant EKKO et EKPO, ainsi que des autorisations de lecture requises. Remplacez les valeurs de remplacement 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 des filtres sur le code société et le type de document que s’ils sont nécessaires au périmètre des rapports.
- Repérez 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 et l’heure de création, ainsi que les attributs au niveau du poste. Agrégez les valeurs nettes d’EKPO pour 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. Utilisez le numéro de demande d’achat et la référence de poste disponibles dans EKPO pour associer les demandes aux commandes d’achat. Les indicateurs d’approbation et leurs horodatages variant selon la configuration de la version, définissez les expressions correspondant au statut et à l’horodatage d’approbation en fonction de la stratégie de validation 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. Pour la création, utilisez la date et l’heure de création d’EKKO. L’approbation, la modification et la suppression nécessitent des sources contenant l’historique des validations ou des modifications. Configurez les expressions de source correspondantes à l’aide de [Your table name] et [Your column name] lorsque l’historique concerné 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 de service, de retour de marchandises, de réception des factures et de paiement des factures depuis les sources pertinentes : sorties, documents de mouvement de marchandises, entrées de service, factures, comptabilité et lettrage. La requête comprend des valeurs de remplacement explicites pour les objets propres au système, car EKKO et EKPO ne couvrent pas ces sources à elles seules.
- Normalisez tous les événements sources selon 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 identiques et ne déduisez pas d’activités sans 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 les résultats dans un fichier délimité ou un jeu de résultats de base de données comportant une ligne d’en-tête 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 le journal d’événements complet 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 des commandes d’achat. Configurez les objets supplémentaires pour les demandes d’achat, les statuts de validation, l’historique des modifications, les sorties, les mouvements de marchandises, les entrées de service, les factures, les paiements et le lettrage en fonction de la version SAP S/4HANA et du modèle de données actif.
- Identifiant de cas : utilisez PurchaseOrderNumber comme identifiant de cas. Associez les événements au niveau du poste au numéro de commande d’achat et conservez les références de poste 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 sur le code société, le type de document, VendorId, l’organisation d’achats, le groupe d’acheteurs et la date de l’événement en fonction du 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 du document ou les journaux correspondants 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 d’un statut actuel seul, sans horodatage d’événement fiable.
- Performances : appliquez tôt les filtres sur les dates des événements et le périmètre organisationnel, agrégez EKPO avant de joindre les sources d’événements lorsque c’est possible et traitez les grands chargements historiques 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 postes, les sources comptables et l’historique des modifications.
- Horodatage d’actualisation : renseignez LastDataUpdate avec l’horodatage d’exécution de l’extraction pour chaque ligne du traitement.
- Prérequis : vous devez disposer d’une connexion SAP HANA, d’autorisations de lecture sur tous les objets sources configurés, d’un accès aux données pertinentes sur les achats, la gestion des stocks, les achats de services, la vérification des factures et les comptes fournisseurs, ainsi que d’une connexion ProcessMind capable d’importer le fichier ou le jeu de résultats sélectionné.
- Configuration propre au système : remplacez chaque valeur de remplacement entre crochets dans la requête par une table, une vue, une colonne ou une expression approuvée dans le système SAP S/4HANA cible. N’incluez pas d’identifiants dans la requête ni dans la configuration de l’extraction.
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, avec tous les attributs requis et recommandés. Documentez les tables SAP concernées (par exemple, EKKO, EKPO, EKBE, CDHDR, CDPOS, BKPF) qui fourniront les données 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 afin de permettre 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. Prévoyez notamment une table interne pour le journal d’événements final, conforme à la structure définie dans la spécification.
- Mise en œuvre de la logique de sélection des données : écrivez la logique ABAP principale pour sélectionner les données correspondant à chacune des 13 activités. Elle comprend plusieurs instructions SELECT sur les tables SAP concernées, avec des jointures lorsque cela est nécessaire. Pour les événements liés aux modifications, lisez les tables de journal CDHDR et CDPOS.
- Transformation et association 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 en fonction de 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.
- Regroupement 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 seule table interne unifiée. Celle-ci représente alors le journal d’événements complet des commandes d’achat sélectionnées.
- Mise en place de l’exportation de fichiers : ajoutez une fonction d’écriture du contenu de 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, ou OPEN DATASET pour l’enregistrer sur le serveur d’applications SAP en vue 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 un code personnalisé (par exemple, ZPM_PO_EXTRACT) qui exécute votre programme ABAP.
- Planification d’un traitement en arrière-plan : pour les volumes importants ou les extractions automatisées, utilisez le code de transaction SM36 pour planifier l’exécution du programme en arrière-plan. Le fichier de sortie sera écrit dans le chemin du serveur d’applications défini dans la logique du programme.
Configuration
- Critères de sélection : le programme doit inclure 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 aux organisations qui comptent plusieurs entités juridiques, afin de limiter 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, pour cibler l’analyse.
- Lecture du journal des modifications : l’extraction d’activités telles que 'Purchase Order Approved' ou 'Purchase Order Changed' nécessite la lecture des tables de journal SAP (CDHDR, CDPOS), une opération qui peut mobiliser beaucoup de ressources. La logique ABAP doit être optimisée pour ne sélectionner que les classes d’objets (EINKBELEG, BANF) et les combinaisons de tables et de champs nécessaires.
- Autorisations : l’utilisateur ou le compte technique qui exécute ce rapport doit disposer d’autorisations de lecture étendues sur les tables de plusieurs modules SAP, notamment Materials Management (MM), Financial Accounting (FI) et les tables système. Cela concerne entre autres 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 de données ou exécutées dans un système à fort volume de transactions, lancez toujours le programme en arrière-plan afin d’éviter les délais d’expiration des processus de dialogue.
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 démarrer votre démarche de Process Mining. Utilisez dès aujourd’hui vos données SAP S/4HANA pour repérer les gains d’efficacité possibles et transformer votre processus Purchase to Pay.
Optimisez vos commandes d’achat P2P et réduisez dès maintenant leur temps de cycle
Éliminez les inefficacités et réduisez de 30 % le temps de cycle de vos commandes d’achat P2P.
Aucune carte bancaire requise. Configuration en quelques minutes.