Votre template de données pour le processus Achat au Paiement - Bon de Commande
Votre template de données pour le processus Achat au Paiement - Bon de Commande
- 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
Achat au paiement - Attributs des bons de commande
| Nom | Description | ||
|---|---|---|---|
| Activité ActivityName | Le nom de l'événement ou de l'étape métier qui s'est produit dans le processus de bon de commande. | ||
| Description Cet attribut décrit une action spécifique ou un changement de statut au sein du cycle de vie du bon de commande, tel que 'Bon de commande créé', 'Bon de commande approuvé' ou 'Réception de marchandises enregistrée'. La séquence de ces activités forme le flux de processus. L'analyse de la séquence et de la fréquence des activités est au cœur du Process Mining. Elle aide à découvrir le processus réel, à le comparer au modèle conçu, à identifier les goulots d'étranglement (par exemple, de longues attentes après 'Facture reçue') et à quantifier le travail de reprise (par exemple, des activités 'Bon de commande modifié' répétées). Pourquoi c'est important Il définit les étapes du processus, permettant la visualisation et l'analyse du flux de bout en bout, l'analyse des variantes et l'identification des goulots d'étranglement. Où obtenir Généralement dérivé d'une combinaison de tables et de champs, tels que les champs de statut dans EKKO/EKPO ou les journaux de documents de modification dans CDHDR/CDPOS, pour représenter les étapes clés de l'entreprise. Exemples Commande d'achat crééeCommande d'achat approuvéeRéception de marchandises enregistréeFacture reçue | |||
| Bon de commande PurchaseOrderNumber | L'identifiant unique du bon de commande (PO), servant d'identifiant de cas principal pour le suivi du cycle de vie des achats. | ||
| Description Le numéro de bon de commande est l'identifiant central qui relie toutes les activités associées, de la création initiale à la réception finale des marchandises et à l'achèvement. Il agit comme l'identifiant de cas pour l'analyse de Process Mining. En analyse, le regroupement des événements par ce numéro permet de reconstituer le parcours de chaque bon de commande individuel. Ceci est essentiel pour calculer les temps de cycle, analyser les variantes de processus et identifier les goulots d'étranglement ou les écarts spécifiques à une seule commande. Pourquoi c'est important C'est la clé essentielle pour connecter tous les événements d'approvisionnement en un processus unique de bout en bout, permettant une analyse détaillée du cycle de vie de chaque bon de commande. Où obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ EBELN. Exemples 450001712345000171244500017125 | |||
| Heure de l'événement EventTime | Le `timestamp` indiquant quand l'activité a eu lieu. | ||
| Description Cet attribut enregistre la date et l'heure exactes de chaque activité dans le processus. Il est fondamental pour toutes les analyses basées sur le temps en Process Mining. L'heure de l'événement est utilisée pour ordonner les activités chronologiquement afin de construire le flux de processus. De plus, elle constitue la base pour le calcul de toutes les métriques basées sur la durée, telles que les temps de cycle entre les activités, les temps d'attente et les temps de traitement, qui sont essentiels pour 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 toutes les métriques de performance, y compris les temps de cycle, les délais et les temps d'attente. Où obtenir Champs d'horodatage associés à des activités spécifiques, tels que la date de création (EKKO-AEDAT pour les modifications) ou la date de comptabilisation (MKPF-BUDAT pour les réceptions de marchandises). Nécessite souvent la combinaison de 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 | L'horodatage de la dernière actualisation ou extraction des données du système source. | ||
| Description Cet attribut indique la fraîcheur des données analysées. Il affiche la date et l'heure de la dernière extraction de données de SAP S/4HANA. Connaître la dernière heure de mise à jour des données est essentiel pour que les utilisateurs comprennent l'actualité de leur analyse. Cela les aide à interpréter correctement les résultats, en sachant s'ils consultent des informations en temps réel ou un instantané d'un point spécifique dans le temps, ce qui affecte la pertinence de toute action entreprise sur la base de l'analyse. Pourquoi c'est important Informe les utilisateurs sur l'actualité des données, garantissant qu'ils comprennent le contexte et la pertinence de leurs résultats analytiques. Où obtenir Il s'agit d'un horodatage de métadonnées ajouté lors du processus d'extraction, de transformation et de chargement (ETL) des données. Exemples 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| Système source SourceSystem | Identifie le système source d'où les `données` ont été extraites. | ||
| Description Cet attribut spécifie le système d'origine des données d'événement, par exemple, 'SAP S/4HANA Production' ou 'SAP ECC'. Dans les environnements multi-systèmes, ce champ est crucial pour la traçabilité des données, le dépannage et la garantie que les données de différentes sources sont correctement interprétées. Il aide à comprendre le contexte des données et peut être utilisé pour filtrer l'analyse pour des environnements système spécifiques. Pourquoi c'est important Fournit un contexte essentiel sur l'origine des données, ce qui est crucial pour la gouvernance des données, la validation et l'analyse dans des environnements multi-systèmes. Où obtenir Il s'agit généralement d'une valeur statique ajoutée pendant le processus d'extraction, de transformation et de chargement (ETL) des données pour étiqueter l'ensemble de données avec son origine. Exemples S4H_PROD_100ECC_EU_200S4H_US_300 | |||
| Date de livraison demandée RequestedDeliveryDate | La date à laquelle l'entreprise a demandé au fournisseur de livrer les biens ou services. | ||
| Description Cet attribut spécifie la date de livraison cible convenue dans le bon de commande. Il sert de base 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 (horodatage 'Réception de marchandises enregistrée') pour calculer le KPI 'Taux de livraison à temps des fournisseurs'. L'analyse des écarts par rapport à cette date aide à évaluer la fiabilité des fournisseurs et à gérer les risques de la chaîne d'approvisionnement. Pourquoi c'est important Sert de référence pour mesurer la performance de livraison à temps des fournisseurs, un KPI critique pour la gestion de la chaîne d'approvisionnement et la planification opérationnelle. Où obtenir Ceci se trouve dans la table de lignes d'échéance EKET, champ EINDT. Exemples 2023-06-012023-06-152023-07-01 | |||
| Demande d'achat PurchaseRequisitionNumber | L'identifiant de la demande d'achat (DA) qui a initié le bon de commande. | ||
| Description Cet attribut relie le bon de commande à sa demande d'achat d'origine. Tous les bons de commande n'auront pas une DA s'ils sont créés directement. Ce lien est essentiel pour analyser l'ensemble du processus d'approvisionnement de bout en bout, en commençant par la demande initiale. Il supporte des KPI tels que le 'Temps d'approbation des demandes d'achat' et est fondamental pour identifier les 'Dépenses sauvages', où les bons de commande sont créés sans demande préalable approuvée. Pourquoi c'est important Relie la commande d'achat à la demande initiale, permettant une analyse de processus de bout en bout et l'identification des dépenses sauvages non conformes. Où obtenir Cet attribut se trouve dans la table SAP S/4HANA EKPO (niveau poste de bon de commande), champ BANFN. Exemples 1001005110010052 | |||
| ID fournisseur VendorId | L'identifiant unique du fournisseur ou du vendeur qui fournit les biens ou les services. | ||
| Description L'ID fournisseur est une donnée de base critique qui lie un bon de commande à un fournisseur spécifique. 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 des performances par fournisseur. Il est essentiel pour des tableaux de bord tels que 'Performance du délai de livraison des fournisseurs' et 'Taux de retour des marchandises par fournisseur', aidant à identifier les fournisseurs les plus fiables et ceux qui peuvent causer des retards ou des problèmes de qualité. Pourquoi c'est important Permet une analyse axée sur les fournisseurs, aidant à évaluer les performances, à identifier les fournisseurs performants et moins performants, et à optimiser la chaîne d'approvisionnement. Où obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ LIFNR. Exemples 100023100045100088 | |||
| Montant net total TotalNetAmount | La valeur totale du bon de commande, hors taxes et frais de transport. | ||
| Description Cet attribut représente la valeur monétaire nette du bon de commande. C'est un chiffre financier clé qui indique l'ampleur de la transaction d'approvisionnement. Ce montant est crucial pour l'analyse financière, comme la catégorisation des bons de commande par valeur (valeur élevée vs. valeur faible) pour voir si leurs chemins de processus diffèrent. Il peut également être utilisé pour prioriser l'analyse, en se concentrant sur les commandes de grande valeur qui peuvent comporter plus de risques financiers ou avoir un impact plus important sur l'entreprise. Pourquoi c'est important Permet une analyse financière, aidant à segmenter les commandes d'achat par valeur et à prioriser les efforts d'amélioration des processus sur les zones à fortes dépenses. Où obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ NETWR. Exemples 1500.0025000.50125.75 | |||
| Type de document de bon de commande DocumentType | Une classification qui distingue différents types de commandes d'achat, tels que les commandes d'achat standard, les commandes d'achat de services ou les commandes de transfert de stock. | ||
| Description Le type de document est un élément de configuration clé dans SAP qui contrôle le flux de processus, la plage de numéros et les champs d'un bon de commande. Il permet aux entreprises d'adapter le processus d'approvisionnement à différents scénarios. L'analyse du processus par type de document est cruciale pour comprendre les variations de processus. Par exemple, le processus pour un bon de commande de marchandises standard peut être très différent d'un bon de commande de services ou d'un transfert de stock. Cet attribut permet de filtrer et de comparer ces flux de processus distincts afin de trouver des opportunités d'amélioration spécifiques. Pourquoi c'est important Il catégorise les bons de commande, permettant de comparer différents processus d'approvisionnement et d'expliquer les variations dans les flux de processus et les temps de cycle. Où obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ BSART. Exemples NBFOUB | |||
| Utilisateur UserName | L'identifiant de l'utilisateur qui a effectué une activité spécifique. | ||
| Description Cet attribut capture l'ID 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 aide à identifier les besoins en formation, la répartition de la charge de travail et les performances individuelles. Par exemple, elle peut être utilisée pour voir si des utilisateurs spécifiques sont constamment associés à de longs délais d'approbation ou à des modifications fréquentes après approbation, ce qui peut éclairer la gestion des ressources et les initiatives d'amélioration des processus. Pourquoi c'est important Assure la responsabilisation et permet l'analyse des performances au niveau individuel ou d'équipe, aidant à identifier les opportunités de formation ou les contraintes de ressources. Où obtenir Cette information se trouve 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 | |||
| `Numéro d'article` MaterialNumber | L'identifiant du matériel ou du bien spécifique faisant l'objet de l'approvisionnement. | ||
| Description Le numéro de matériel est un code unique attribué à chaque fiche article dans SAP. Il est utilisé pour toutes les transactions liées à ce matériel, y compris l'approvisionnement, la gestion des stocks et les ventes. L'analyse par numéro de matériel ou groupe de matériels permet une analyse basée sur les produits. Elle peut aider à identifier si les processus d'approvisionnement pour certains types de matériels sont moins efficaces, ont des délais plus longs ou sont plus sujets aux retours, fournissant des informations pour la gestion des catégories. Pourquoi c'est important Permet une analyse par catégorie de marchandises, aidant à identifier les problèmes de processus ou les problèmes de performance des fournisseurs liés à des produits ou matériaux spécifiques. Où obtenir Cet attribut se trouve dans la table SAP S/4HANA EKPO, champ MATNR. Exemples RM100-100FG210SERV-CONSULT | |||
| Catégorie d'article ItemCategory | Classe un poste de commande d'achat, tel que standard, en consignation, en sous-traitance ou de service. | ||
| Description La catégorie d'article détermine la manière dont l'approvisionnement d'un matériel ou d'un service spécifique est contrôlé et traité. Elle influence les étapes ultérieures comme la réception des marchandises et la vérification des factures. Cet attribut est important pour analyser les variantes de processus en fonction de ce qui est acheté. Par exemple, le processus pour un article de service (qui nécessite une feuille de saisie de services) diffère significativement d'un article de stock standard. L'analyse par catégorie d'article aide à expliquer ces différences et permet des améliorations de processus ciblées. Pourquoi c'est important Explique les variations de processus en distinguant différents types d'approvisionnement, tels que les biens, les services ou la sous-traitance. Où obtenir Cet attribut se trouve dans la table SAP S/4HANA EKPO, champ PSTYP. Exemples 093 | |||
| Code société CompanyCode | L'identifiant de l'entité juridique ou de l'entreprise pour laquelle le bon de commande est créé. | ||
| Description Le code société représente une unité comptable indépendante au sein d'une organisation. Toutes les transactions financières liées à un bon de commande sont imputées à un code société spécifique. 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 de processus par entité juridique, facilitant les comparaisons de performance et de conformité entre les différentes parties de l'entreprise. Où obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ BUKRS. Exemples 101017102000 | |||
| Est un retravail IsRework | Un indicateur calculé signalant si la commande d'achat a fait l'objet de retravail, tel qu'une modification post-approbation ou un retour de marchandises. | ||
| Description Cet attribut booléen est calculé en analysant la séquence des activités pour chaque bon de commande. Il est marqué comme 'vrai' si un événement 'Bon de commande modifié' se produit après un événement 'Bon de commande approuvé', ou si un événement 'Marchandises retournées' est présent. Cet indicateur simplifie le calcul du KPI 'Taux de traitement direct'. Il permet un filtrage et une visualisation faciles de tous les bons de commande qui ont nécessité une intervention manuelle ou une correction, aidant à quantifier le coût et la fréquence des retouches. Pourquoi c'est important Aide à quantifier l'inefficacité des processus en signalant les cas de retravail, ce qui est crucial pour le calcul des taux de traitement direct et l'identification des causes profondes des déviations. Où obtenir Champ calculé basé sur la séquence d'activités. La logique vérifie si un événement « Commande d'achat modifiée » suit une approbation ou si un événement « Marchandises retournées » existe. Exemples truefaux | |||
| Est une dépense sauvage IsMaverickSpend | Un indicateur calculé signalant si une commande d'achat a été créée sans demande d'achat préalable approuvée. | ||
| Description Cet indicateur booléen est dérivé lors du traitement des données. Il est défini sur 'vrai' si un bon de commande ne dispose pas d'une demande d'achat associée ou si la création du bon de commande contourne le workflow d'approbation standard. Cet attribut prend directement en charge le tableau de bord 'Identification des dépenses sauvages' et les KPI associés. Il aide à quantifier l'ampleur des comportements d'achat non conformes, permettant aux entreprises de cibler des départements ou des groupes d'utilisateurs spécifiques pour renforcer les politiques et les contrôles d'approvisionnement. Pourquoi c'est important Identifie directement les achats non conformes, aidant à quantifier les écarts de processus et à appliquer les contrôles financiers et les politiques d'approvisionnement. Où obtenir Champ calculé basé sur l'absence de valeur dans 'PurchaseRequisitionNumber' pour des types de documents spécifiques, ou par analyse de la séquence d'événements. Exemples truefaux | |||
| Groupe d'Achats PurchasingGroup | Le groupe spécifique d'acheteurs responsables de certaines activités d'approvisionnement. | ||
| Description Un groupe d'acheteurs est un acheteur ou un ensemble d'acheteurs responsables d'activités d'achat, de matériaux ou de fournisseurs spécifiques. Ils sont le principal point de contact pour les fournisseurs. Cet attribut permet une analyse plus granulaire de la charge de travail et des performances que l'organisation d'achat. Il peut être utilisé pour identifier les équipes surchargées, mesurer l'efficacité des différents groupes d'acheteurs et comprendre quels groupes sont plus sujets aux déviations de processus comme les dépenses sauvages. Pourquoi c'est important Offre une vue granulaire de la performance du groupe d'acheteurs, permettant l'analyse de la charge de travail, de l'efficacité et du respect des processus au niveau de l'équipe. Où obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ EKGRP. Exemples 001002N00 | |||
| Livraison à temps des fournisseurs SupplierOnTimeDelivery | Un indicateur calculé indiquant si la réception des marchandises a été enregistrée à la date de livraison demandée ou avant. | ||
| Description Cet attribut booléen est dérivé en comparant l'horodatage de l'activité 'Réception de marchandises enregistrée' avec la 'Date de livraison demandée'. Si la réception des marchandises est à la date demandée ou avant, il est marqué 'vrai'. Cet attribut supporte directement le KPI 'Taux de livraison à temps des fournisseurs'. Il simplifie l'analyse en permettant aux utilisateurs de filtrer facilement les livraisons à temps ou en retard, ce qui est essentiel pour les tableaux de bord de performance des fournisseurs et l'évaluation des fournisseurs. Pourquoi c'est important Mesure directement la fiabilité des fournisseurs, servant de base à l'indicateur clé de performance de livraison à temps et permettant une gestion efficace des performances des fournisseurs. Où obtenir Calculé en comparant l'horodatage de l'activité « Réception de marchandises enregistrée » avec l'attribut « RequestedDeliveryDate ». Exemples truefaux | |||
| Organisation d'Achats PurchasingOrganization | L'`unité organisationnelle` responsable de l'`approvisionnement en matériaux` et `services` et de la `négociation` avec les `fournisseurs`. | ||
| Description L'organisation d'achat est une unité organisationnelle clé dans l'approvisionnement. Elle peut être structurée au niveau de l'entreprise, de la société ou de l'usine et est responsable de toutes les activités d'achat. L'analyse du processus par organisation d'achat aide à évaluer l'efficacité et la performance des différentes équipes ou régions d'approvisionnement. Elle peut mettre en évidence des différences dans la négociation avec les fournisseurs, la conformité des processus ou les retards d'approbation entre les unités organisationnelles. Pourquoi c'est important Permet la comparaison des performances entre différents départements d'approvisionnement ou régions, aidant à identifier les meilleures pratiques et les domaines d'amélioration. Où obtenir Cet attribut se trouve dans la table SAP S/4HANA EKKO, champ EKORG. Exemples 10101710US01 | |||
| Temps de Cycle d'Approbation du Bon de Commande PoApprovalCycleTime | La durée calculée entre la création d'un bon de commande et sa réception de l'approbation finale. | ||
| Description Cette métrique mesure le temps écoulé entre l'activité 'Bon de commande créé' et l'activité 'Bon de commande approuvé'. Elle est calculée pour chaque cas de bon de commande. Cet attribut fournit une mesure directe de l'efficacité de l'approbation interne. C'est la métrique principale pour le tableau de bord et le KPI 'Temps de cycle d'approbation des bons de commande', aidant à identifier où se produisent les retards dans le processus d'approbation et à repérer les opportunités d'accélération. Pourquoi c'est important Mesure directement l'efficacité du processus d'approbation interne, aidant à identifier et à résoudre les goulots d'étranglement qui ralentissent l'approvisionnement. Où obtenir Calculé en trouvant la différence de temps entre l'événement « Commande d'achat approuvée » et l'événement « Commande d'achat créée » pour chaque commande d'achat. Exemples P2D4H30MP0D2H15MP5D | |||
| Usine Plant | L'établissement opérationnel ou le lieu où les marchandises sont livrées ou les services rendus. | ||
| Description Dans SAP, une usine est un emplacement physique où les marchandises sont produites, stockées ou les services sont exécutés. C'est un élément clé pour la logistique et la planification. La segmentation de l'analyse de processus par usine peut révéler des variations régionales ou spécifiques au site dans le processus d'approvisionnement. Par exemple, elle peut montrer si certaines usines connaissent des délais de livraison plus longs ou ont des taux de retour de marchandises plus élevés, indiquant des problèmes localisés de logistique ou de contrôle qualité. Pourquoi c'est important Permet une analyse basée sur la localisation, mettant en évidence les différences de performance des processus entre divers sites opérationnels, usines ou entrepôts. Où obtenir Cet attribut se trouve dans la table SAP S/4HANA EKPO, champ WERKS. Exemples 10101710DE01 | |||
Achat au paiement - Activités des bons de commande
| Activité | Description | ||
|---|---|---|---|
| Bon de commande achevé | Cette activité signifie qu'un poste de bon de commande est considéré comme clôturé d'un point de vue logistique. Elle est déduite lorsque les indicateurs 'Livraison Complète' et 'Facture Finale' sont tous deux définis. | ||
| Pourquoi c'est important Ceci sert de point final à l'analyse du cycle de vie du bon de commande. Mesurer le temps jusqu'à cet événement fournit le temps de cycle de bout en bout pour les opérations d'approvisionnement. Où obtenir Déduit des indicateurs de statut de la table des postes de commande d'achat, EKPO. L'événement se produit lorsque les indicateurs « Livraison terminée » (ELIKZ) et « Facture finale » (EREKZ) sont tous deux définis sur vrai. Capture Déduit des journaux de modifications lorsque les champs EKPO ELIKZ et EREKZ sont tous deux marqués comme complets. Type d'événement inferred | |||
| Commande d'achat approuvée | Signifie que le bon de commande a reçu toutes les approbations internes nécessaires et est autorisé à être envoyé au fournisseur. L'événement est déduit d'un changement de statut dans la stratégie de déblocage du bon de commande. | ||
| Pourquoi c'est important C'est un jalon clé pour mesurer l'efficacité de l'approbation et le travail de reprise post-approbation. L'analyse du temps entre la création et l'approbation d'un bon de commande met en évidence les retards de processus internes. Où obtenir Déduit de l'indicateur de diffusion (FRGKE) dans la table EKKO. L'horodatage est déterminé en examinant l'historique des modifications (CDHDR/CDPOS) pour savoir quand ce champ a été mis à jour au statut « diffusé ». Capture Déduit des journaux de modifications pour le champ de l'indicateur de diffusion (FRGKE) dans la table EKKO. Type d'événement inferred | |||
| Commande d'achat créée | Marque la création du document officiel de bon de commande, qui peut être créé avec ou sans référence à une demande d'achat. Il s'agit d'un événement explicite enregistré lorsque le document de bon de commande est sauvegardé pour la première fois dans le système. | ||
| Pourquoi c'est important Cette activité peut servir de point de départ alternatif pour le processus, en particulier pour l'analyse des achats sauvages. C'est un événement fondamental pour le suivi du temps global de traitement des bons de commande. Où obtenir Enregistré dans la table d'en-tête des bons de commande EKKO. La date (AEDAT) et l'heure de création sont stockées directement dans cette table pour le document. Capture Horodatage de création (AEDAT) dans la table EKKO pour le document de commande d'achat. Type d'événement explicit | |||
| Demande d'achat approuvée | Représente l'approbation formelle d'une demande d'achat par un responsable ou un approbateur désigné. Ceci est généralement déduit d'un changement de statut dans le document de demande, signifiant qu'il est prêt à être converti en bon de commande. | ||
| Pourquoi c'est important C'est un jalon critique pour le suivi des temps de cycle d'approbation et l'identification des goulots d'étranglement. Les retards ici ont un impact direct sur la rapidité avec laquelle un bon de commande peut être créé et envoyé à un fournisseur. Où obtenir Déduit des champs de statut de diffusion dans la table EBAN (par exemple, FRGZU - Indicateur de diffusion). L'horodatage est dérivé des documents de modification (CDHDR/CDPOS) qui enregistrent le moment où le statut de diffusion final a été défini. Capture Déduit des journaux de modifications (CDHDR/CDPOS) pour les champs de statut de diffusion dans la table EBAN. Type d'événement inferred | |||
| Demande d'achat créée | Cette activité marque la demande formelle de biens ou de services, initiant le processus d'approvisionnement. L'événement est explicitement capturé lorsqu'un utilisateur enregistre un nouveau document de demande d'achat (par exemple, en utilisant la transaction ME51N). | ||
| Pourquoi c'est important C'est le point de départ principal pour de nombreux cycles de vie des bons de commande. L'analyse du temps entre cet événement et la création du bon de commande aide à identifier les retards dans l'approvisionnement et le traitement interne. Où obtenir Enregistré dans la table EBAN (Demande d'achat). L'horodatage de l'événement de création se trouve dans les tables d'historique des modifications CDHDR et CDPOS pour l'objet EBAN. Capture Événement enregistré lors de la création d'un document dans la table EBAN. Type d'événement explicit | |||
| Facture reçue | Représente la saisie de la facture d'un fournisseur dans le système SAP, la liant au bon de commande correspondant. Il s'agit d'une imputation financière explicite qui crée un document comptable. | ||
| Pourquoi c'est important C'est un jalon critique qui relie le processus d'approvisionnement au processus de comptabilité fournisseurs. Il permet l'analyse du temps entre la réception des marchandises et le traitement des factures. Où obtenir Un document comptable est créé dans la table BKPF (en-tête) et ses postes se trouvent dans BSEG ou le journal universel ACDOCA. Le document est lié à la commande d'achat dans la table RSEG. Capture Date de saisie du document (CPUDT) de la table d'en-tête de document comptable BKPF. Type d'événement explicit | |||
| Réception de marchandises enregistrée | Représente la réception physique des marchandises du fournisseur et l'enregistrement correspondant dans le système. Il s'agit d'une transaction explicite qui met à jour l'historique des bons de commande. | ||
| Pourquoi c'est important C'est un jalon majeur qui met fin au délai de livraison du fournisseur et débute le processus interne de vérification des factures. Il est essentiel pour suivre les taux de livraison à temps. Où obtenir Enregistré comme document article dans les tables MKPF (en-tête) et MSEG (poste), et lié dans la table d'historique des bons de commande EKBE avec un type de mouvement spécifique (par exemple, 101). Capture Date de comptabilisation (BUDAT) de l'en-tête du document article (MKPF) liée via EKBE. Type d'événement explicit | |||
| Bon de commande envoyé au fournisseur | Représente le moment où le bon de commande est communiqué au fournisseur, par exemple, via EDI, e-mail ou impression. Cet événement est souvent capturé via les journaux de gestion des sorties du système. | ||
| Pourquoi c'est important Cette activité marque le véritable début du délai de livraison fournisseur. Elle est cruciale pour mesurer avec précision la performance du fournisseur dès la réception de la commande. Où obtenir Capturé à partir de la table de contrôle de sortie NAST, qui enregistre les messages envoyés pour un document d'achat. La date et l'heure du type de sortie pertinent (par exemple, EDI, e-mail) peuvent être utilisées. Capture Horodatage du premier message de sortie réussi pour le bon de commande dans la table NAST. Type d'événement inferred | |||
| Bon de commande supprimé | Représente l'annulation ou la suppression logique d'un poste de bon de commande ou du document entier. Cela est enregistré par un utilisateur définissant un indicateur de suppression sur le document. | ||
| Pourquoi c'est important Cette activité est un point de fin alternatif pour le processus, indiquant un échec ou une annulation. L'analyse des raisons pour lesquelles les bons de commande sont supprimés peut révéler des problèmes de planification de la demande ou de définition des exigences. Où obtenir Capturé à partir 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 est dérivé des documents de modification (CDHDR/CDPOS). Capture Horodatage des documents de modification (CDHDR/CDPOS) lorsque l'indicateur de suppression (LOEKZ) est activé. Type d'événement explicit | |||
| Commande d'achat modifiée | Cette activité indique qu'une modification a été apportée au bon de commande après sa création initiale, comme un changement de quantité, de prix ou de date de livraison. Elle est explicitement enregistrée dans les journaux de modifications du système. | ||
| Pourquoi c'est important Le suivi des modifications, en particulier après approbation, est essentiel pour identifier les inefficacités de processus, le travail de reprise et les problèmes potentiels de conformité. Des modifications fréquentes peuvent indiquer des spécifications initiales médiocres. Où obtenir Enregistré dans les tables de documents de modification CDHDR (en-tête) et CDPOS (poste) pour les objets de bon de commande (EINKBELEG). Chaque modification crée une entrée de journal détaillée. Capture Événement enregistré pour les modifications des champs clés dans les tables EKKO ou EKPO, enregistrées dans CDHDR/CDPOS. Type d'événement explicit | |||
| Confirmation des Services Saisie | Cette activité marque la confirmation qu'un service spécifié sur un bon de commande a été rendu. Elle est explicitement enregistrée par la création d'une feuille de saisie de services. | ||
| Pourquoi c'est important Pour l'approvisionnement basé sur les services, ceci est l'équivalent d'une réception de marchandises. C'est crucial pour le suivi des délais de livraison de services et pour permettre des paiements fournisseurs en temps voulu. Où obtenir Enregistré via la création d'une feuille de saisie de services, avec des données stockées dans les tables ESSR (en-tête) et ESLL (lignes). La date de création sert d'horodatage. Capture Date de création du document de feuille de saisie de services dans la table ESSR. Type d'événement explicit | |||
| Facture payée | Marque le règlement final de la facture fournisseur via une exécution de paiement ou un paiement manuel. Il s'agit d'une transaction financière explicite qui crée un document de compensation. | ||
| Pourquoi c'est important Bien que techniquement une partie du processus de paiement, l'inclusion de cette activité offre une vue complète du cycle d'achat-paiement. Elle est essentielle pour analyser les conditions et la performance des paiements. Où obtenir Le paiement est enregistré comme document de compensation dans BKPF/ACDOCA. La date de compensation (AUGDT) sur la ligne de facture dans la table BSEG ou ACDOCA indique l'événement de paiement. Capture Date de lettrage (AUGDT) du document de facture, trouvée dans BSEG ou ACDOCA. Type d'événement explicit | |||
| Marchandises retournées | Indique que les 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'expéditions incorrectes. Ceci est enregistré comme un mouvement de marchandises de retour explicite. | ||
| Pourquoi c'est important Cette activité met en évidence le travail de reprise et les problèmes potentiels liés à la qualité du fournisseur ou à la précision de la commande. Une fréquence élevée de retours pour un fournisseur ou un matériel spécifique signale un problème. Où obtenir Enregistré comme document article avec un type de mouvement de retour spécifique (par exemple, 122). L'événement est enregistré dans MKPF/MSEG et lié au bon de commande dans la table d'historique EKBE. Capture Date de comptabilisation du document article avec un type de mouvement de retour dans EKBE. Type d'événement explicit | |||
Guides d'extraction
Étapes
- Prérequis et Accès: Assurez-vous de disposer d'un utilisateur avec les autorisations appropriées pour interroger les vues Core Data Services (CDS) dans le système SAP S/4HANA. L'accès peut se faire via SAP HANA Studio, les Outils de Développement ABAP (ADT) pour Eclipse, ou un outil d'extraction de données tiers supportant les connexions SQL à la base de données SAP HANA.
- Identifier les Détails de Connexion Système: Obtenez les paramètres de connexion nécessaires pour votre système SAP S/4HANA, y compris l'hôte, le numéro d'instance et vos identifiants d'authentification.
- Connecter à la Base de Données: À l'aide de votre client SQL préféré, établissez une connexion à la base de données SAP S/4HANA où résident les vues CDS.
- Préparer la Requête SQL: Copiez la requête SQL complète fournie dans la section de requête de ce document dans votre éditeur SQL. Cette requête est conçue pour extraire toutes les activités et attributs requis.
- Définir les Paramètres de Filtrage: Localisez les valeurs des marqueurs de position dans la requête. Remplacez _start_date et _end_date par la plage de dates souhaitée pour votre analyse (par exemple, '20230101' et '20231231'). Modifiez le filtre poh.CompanyCode pour inclure les codes de société spécifiques que vous souhaitez analyser.
- Exécuter la Requête: Exécutez la requête SQL modifiée sur la base de données S/4HANA. Selon le volume de données et la plage de dates spécifiée, cette exécution peut prendre un certain temps.
- Examiner les Résultats Préliminaires: Une fois la requête terminée, effectuez un examen rapide du résultat dans votre client SQL. Vérifiez la présence de différentes activités, assurez-vous que les horodatages sont correctement renseignés et vérifiez que l'ID de cas (PurchaseOrderNumber) est cohérent.
- Exporter les Données: Exportez l'ensemble complet des résultats de votre outil SQL vers un fichier CSV (Comma Separated Values). Assurez-vous que le fichier utilise l'encodage UTF-8 pour éviter les problèmes de caractères.
- Préparer pour le Téléchargement: Avant de télécharger vers ProcessMind, ouvrez le fichier CSV et vérifiez que les en-têtes de colonne correspondent exactement aux attributs définis dans les exigences de données (PurchaseOrderNumber, ActivityName, EventTime, etc.). Ajustez les noms de colonne si votre outil d'exportation les a modifiés.
- Télécharger vers ProcessMind: Téléchargez le fichier CSV finalisé vers votre projet ProcessMind. Mappez les colonnes de votre fichier aux champs correspondants d'ID de cas, d'activité et d'horodatage pendant le processus d'importation.
Configuration
- Vues CDS clés utilisées: La logique d'extraction repose sur un ensemble de vues CDS standard et sémantiquement riches. Les vues principales incluent :
- I_PurchaseOrderItemAPI01: Pour les données de postes de commande d'achat principales.
- I_PurchaseRequisitionItemAPI01: Pour les détails des demandes d'achat.
- I_MaterialDocumentItem: Pour les mouvements de marchandises tels que les réceptions et les retours.
- I_ServiceEntrySheetAPI01: Pour les événements de confirmation de service.
- I_SupplierInvoiceAPI01: Pour les informations de facture fournisseur.
- I_OperationalAcctgDocItem: Pour lier les factures aux documents financiers pour le suivi des paiements.
- I_ChangeDocument: Pour capturer les modifications de la commande d'achat.
- Filtrage par plage de dates: Il est essentiel d'appliquer un filtre de plage de dates pour gérer les performances et le volume de données. La requête utilise les marqueurs de position _start_date et _end_date sur la date de création de la commande d'achat (PurchaseOrderDate). Une plage initiale recommandée est de 3 à 6 mois de données.
- Filtrage organisationnel: La requête doit toujours être filtrée par CompanyCode pour limiter le périmètre d'extraction aux unités commerciales pertinentes. Des filtres supplémentaires sur PurchaseOrderType ou PurchasingOrganization peuvent être ajoutés à l'expression de table commune principale PO_base pour un affinement ultérieur.
- Prérequis: L'utilisateur exécutant la requête requiert l'autorisation SELECT sur toutes les vues CDS énumérées ci-dessus. L'accès à ces vues est généralement accordé via des rôles métier ou d'analyse spécifiques dans S/4HANA. Sans les autorisations appropriées, 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
- Prérequis et Accès: Assurez-vous de disposer d'un utilisateur avec les autorisations appropriées pour interroger les vues Core Data Services (CDS) dans le système SAP S/4HANA. L'accès peut se faire via SAP HANA Studio, les Outils de Développement ABAP (ADT) pour Eclipse, ou un outil d'extraction de données tiers supportant les connexions SQL à la base de données SAP HANA.
- Identifier les Détails de Connexion Système: Obtenez les paramètres de connexion nécessaires pour votre système SAP S/4HANA, y compris l'hôte, le numéro d'instance et vos identifiants d'authentification.
- Connecter à la Base de Données: À l'aide de votre client SQL préféré, établissez une connexion à la base de données SAP S/4HANA où résident les vues CDS.
- Préparer la Requête SQL: Copiez la requête SQL complète fournie dans la section de requête de ce document dans votre éditeur SQL. Cette requête est conçue pour extraire toutes les activités et attributs requis.
- Définir les Paramètres de Filtrage: Localisez les valeurs des marqueurs de position dans la requête. Remplacez _start_date et _end_date par la plage de dates souhaitée pour votre analyse (par exemple, '20230101' et '20231231'). Modifiez le filtre poh.CompanyCode pour inclure les codes de société spécifiques que vous souhaitez analyser.
- Exécuter la Requête: Exécutez la requête SQL modifiée sur la base de données S/4HANA. Selon le volume de données et la plage de dates spécifiée, cette exécution peut prendre un certain temps.
- Examiner les Résultats Préliminaires: Une fois la requête terminée, effectuez un examen rapide du résultat dans votre client SQL. Vérifiez la présence de différentes activités, assurez-vous que les horodatages sont correctement renseignés et vérifiez que l'ID de cas (PurchaseOrderNumber) est cohérent.
- Exporter les Données: Exportez l'ensemble complet des résultats de votre outil SQL vers un fichier CSV (Comma Separated Values). Assurez-vous que le fichier utilise l'encodage UTF-8 pour éviter les problèmes de caractères.
- Préparer pour le Téléchargement: Avant de télécharger vers ProcessMind, ouvrez le fichier CSV et vérifiez que les en-têtes de colonne correspondent exactement aux attributs définis dans les exigences de données (PurchaseOrderNumber, ActivityName, EventTime, etc.). Ajustez les noms de colonne si votre outil d'exportation les a modifiés.
- Télécharger vers ProcessMind: Téléchargez le fichier CSV finalisé vers votre projet ProcessMind. Mappez les colonnes de votre fichier aux champs correspondants d'ID de cas, d'activité et d'horodatage pendant le processus d'importation.
Configuration
- Vues CDS clés utilisées: La logique d'extraction repose sur un ensemble de vues CDS standard et sémantiquement riches. Les vues principales incluent :
- I_PurchaseOrderItemAPI01: Pour les données de postes de commande d'achat principales.
- I_PurchaseRequisitionItemAPI01: Pour les détails des demandes d'achat.
- I_MaterialDocumentItem: Pour les mouvements de marchandises tels que les réceptions et les retours.
- I_ServiceEntrySheetAPI01: Pour les événements de confirmation de service.
- I_SupplierInvoiceAPI01: Pour les informations de facture fournisseur.
- I_OperationalAcctgDocItem: Pour lier les factures aux documents financiers pour le suivi des paiements.
- I_ChangeDocument: Pour capturer les modifications de la commande d'achat.
- Filtrage par plage de dates: Il est essentiel d'appliquer un filtre de plage de dates pour gérer les performances et le volume de données. La requête utilise les marqueurs de position _start_date et _end_date sur la date de création de la commande d'achat (PurchaseOrderDate). Une plage initiale recommandée est de 3 à 6 mois de données.
- Filtrage organisationnel: La requête doit toujours être filtrée par CompanyCode pour limiter le périmètre d'extraction aux unités commerciales pertinentes. Des filtres supplémentaires sur PurchaseOrderType ou PurchasingOrganization peuvent être ajoutés à l'expression de table commune principale PO_base pour un affinement ultérieur.
- Prérequis: L'utilisateur exécutant la requête requiert l'autorisation SELECT sur toutes les vues CDS énumérées ci-dessus. L'accès à ces vues est généralement accordé via des rôles métier ou d'analyse spécifiques dans S/4HANA. Sans les autorisations appropriées, 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
- Spécification et Conception: Définissez la structure de données finale pour le fichier 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, CDPOS, BKPF) qui seront utilisées pour sourcer les données pour chacune des 13 activités requises.
- Création du Programme: Dans l'interface graphique SAP (SAP GUI), naviguez vers l'Éditeur ABAP en utilisant le code de transaction SE38 ou SE80. Créez un nouveau programme exécutable, par exemple, Z_PM_PO_EXTRACT.
- Définir l'Écran de Sélection: Codez l'écran de sélection pour le rapport. Cela permet aux utilisateurs de filtrer les données qu'ils souhaitent extraire. Incluez des paramètres pour la plage de dates de création de la Commande d'achat (P_AEDAT), le Code de 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 inclut une table interne pour le journal d'événements final qui correspond à la structure définie à l'étape de spécification.
- Implémenter la Logique de Sélection des Données: Écrivez la logique ABAP principale pour sélectionner les données de chacune des 13 activités. Cela implique une série d'instructions SELECT sur les tables SAP pertinentes, jointes si nécessaire. Pour les événements basés sur les modifications, lisez à partir des tables de journal des modifications CDHDR et CDPOS.
- Transformer et Mapper les Données: Pour chaque enregistrement récupéré, mappez les champs de la table SAP aux colonnes correspondantes de votre table interne de journal d'événements final. Définissez l'ActivityName en fonction de l'événement traité (par exemple, « Commande d'achat créée »). Convertissez les champs de date et d'heure dans un format d'horodatage cohérent pour EventTime.
- Consolider les Données d'Événements: Après avoir traité les 13 types d'activités, assurez-vous que toutes les données sont collectées dans une table interne unique et unifiée. Cette table représente désormais le journal d'événements complet pour les commandes d'achat sélectionnées.
- Implémenter la Sortie Fichier: Ajoutez des fonctionnalités pour écrire la table interne finale dans un fichier. L'approche recommandée est d'utiliser la méthode cl_gui_frontend_services=>gui_download pour permettre aux utilisateurs d'enregistrer le fichier au format CSV sur leur machine locale, ou d'utiliser OPEN DATASET pour l'enregistrer sur le serveur d'applications SAP pour un traitement en arrière-plan.
- Créer un Code de Transaction (Facultatif): Pour rendre le programme facilement accessible aux utilisateurs métier, utilisez le code de transaction SE93 pour créer un code de transaction personnalisé (par exemple, ZPM_PO_EXTRACT) qui exécute votre programme ABAP.
- Planifier une Tâche d'Arrière-Plan: Pour les grands volumes de données ou les extractions automatisées, utilisez le code de transaction SM36 pour planifier l'exécution du programme en tant que tâche d'arrière-plan. Le fichier de sortie sera écrit dans le chemin du serveur d'applications spécifié dans la logique du programme.
Configuration
- Critères de sélection: Le programme doit inclure des paramètres de sélection pour filtrer efficacement les données. Les principaux filtres sont :
- Plage de dates: Une plage de dates obligatoire pour la date de création de la commande d'achat (EKKO-AEDAT). Il est recommandé de commencer par une période de 3 à 6 mois afin de gérer le volume de données et la performance du rapport.
- Code de société (BUKRS): Essentiel pour les organisations multi-entités afin de réduire le périmètre d'extraction.
- Type de document d'achat (BSART): Permet de filtrer des types spécifiques de commandes d'achat, tels que les commandes standard, les commandes-cadres ou les commandes de transfert de stock, pour affiner l'analyse.
- Lecture du journal des modifications: L'extraction d'activités comme « Commande d'achat approuvée » ou « Commande d'achat modifiée » repose sur la lecture des tables du journal des modifications SAP (CDHDR, CDPOS). Cela peut être gourmand en ressources. La logique ABAP doit être optimisée pour sélectionner uniquement les classes d'objets (EINKBELEG, BANF) et les combinaisons table/champ nécessaires.
- Autorisations: L'utilisateur ou le compte technique exécutant ce rapport nécessite des autorisations de lecture étendues pour les tables de plusieurs modules SAP, y compris la Gestion des articles (MM), la Comptabilité financière (FI) et les tables système. Cela inclut des tables comme 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 s'exécutant dans un système à fort volume de transactions, exécutez toujours le programme en arrière-plan pour é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.