Votre modèle de données Order to Cash - Sales Order Processing
Votre modèle de données Order to Cash - Sales Order Processing
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d’extraction pour SAP ECC
Order to Cash, attributs du traitement des commandes clients
| Nom | Description | ||
|---|---|---|---|
| Commande client SalesOrder | Identifiant unique d'un document de commande client, qui sert de dossier principal pour suivre l'ensemble du processus Order-to-Cash. | ||
| Description La commande client est le document central du processus commercial. Elle représente la demande d'un client concernant des marchandises ou des services et contient toutes les informations nécessaires au traitement de cette demande, du début à la fin. Dans le Process Mining, cet attribut sert d'identifiant de dossier. Chaque numéro de commande client unique représente une instance de processus de bout en bout. L'analyse des processus par commande client permet de suivre le cycle de vie complet, de mesurer les délais et d'identifier les variations propres à chaque commande. Pourquoi c’est important Il s'agit de la clé essentielle qui relie toutes les activités et tous les événements associés, permettant une analyse complète du parcours de chaque commande client, de bout en bout. Où les obtenir Présent dans la table des données d'en-tête du document de vente (VBAK), dans le champ VBELN. Exemples 900001234590000123469000012347 | |||
| Activité Activity | Nom d'une étape ou d'un événement métier précis survenu dans le processus de commande client. | ||
| Description Cet attribut décrit une étape unique du processus Order-to-Cash, comme « commande client créée », « livraison créée » ou « paiement reçu ». Ces activités constituent les éléments de base utilisés pour reconstituer le flux du processus de chaque commande client. L'analyse de la séquence et du moment de ces activités est au cœur du Process Mining. Elle aide à visualiser la cartographie du processus, à identifier les goulots d'étranglement, à découvrir les variantes du processus et à vérifier la conformité par rapport à un modèle standard. Les activités sont généralement déduites d'une combinaison d'événements de création de documents, de changements de statut ou de codes de transaction spécifiques enregistrés dans le système. Pourquoi c’est important Les activités constituent la structure fondamentale de la cartographie du processus et permettent de visualiser et d'analyser le flux, les écarts et les goulots d'étranglement. Où les obtenir Il s'agit d'un attribut dérivé, généralement généré lors de l'extraction des données en associant les codes de transaction SAP (T-Codes), les changements de statut des documents, par exemple dans les tables VBUK et VBUP, ou les journaux de documents de modification, dans les tables CDHDR et CDPOS, à des noms d'activité compréhensibles. Exemples Commande client crééeLivraison crééeSortie de marchandisesFacture crééePaiement reçu | |||
| Dernière mise à jour des données LastDataUpdate | Horodatage indiquant la dernière actualisation des données de cet enregistrement depuis le système source. | ||
| Description Cet attribut enregistre la date et l'heure de l'extraction ou de la mise à jour la plus récente d'un événement ou d'un dossier donné. Il donne de la visibilité sur l'actualité des données analysées. Dans les Dashboards et les rapports, cette information est essentielle pour comprendre l'actualité des analyses. Elle permet de vérifier si celles-ci reflètent l'état opérationnel le plus récent ou si elles reposent sur des données plus anciennes, et de gérer les attentes des utilisateurs quant à leur fraîcheur. Pourquoi c’est important Permet aux utilisateurs de connaître l'actualité des données, ce qui est essentiel pour prendre rapidement des décisions éclairées à partir de l'analyse du Process Mining. Où les obtenir Il s'agit d'un attribut de métadonnées renseigné par l'outil ou le processus d'extraction au moment de l'ingestion des données. Il n'est pas stocké dans les tables SAP sources. Exemples 2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z | |||
| Heure de début StartTime | Horodatage indiquant le début d'une activité ou d'un événement. | ||
| Description L'heure de début, également appelée horodatage de l'événement, enregistre la date et l'heure précises auxquelles une activité donnée a eu lieu. Elle indique par exemple la création d'une commande client, l'enregistrement d'une sortie de marchandises ou la comptabilisation d'une facture. Cet horodatage est fondamental pour toutes les analyses temporelles du Process Mining. Il sert à calculer les délais entre les activités, à mesurer la durée totale d'un dossier et à identifier les retards ou les goulots d'étranglement. Des horodatages précis sont indispensables aux Dashboards d'analyse des performances, notamment ceux qui suivent les livraisons dans les délais ou les délais d'exécution. Pourquoi c’est important Il s'agit d'un attribut essentiel pour calculer tous les indicateurs de performance, notamment les délais et les durées, qui permettent d'identifier les goulots d'étranglement. Où les obtenir Il s'agit d'un attribut composite, généralement obtenu en combinant un champ de date, par exemple ERDAT, et un champ d'heure, par exemple ERZET, provenant de différentes tables SAP telles que VBAK (commande client), LIKP (livraison) et VBRK (facture). Exemples 2023-04-15T09:00:12Z2023-04-16T14:30:00Z2023-04-20T11:22:45Z | |||
| Système source SourceSystem | Identifie le système source à partir duquel les données ont été extraites. | ||
| Description Cet attribut précise le système d'origine, par exemple le nom d'une instance SAP ECC donnée ou le numéro d'un mandant. Il fournit un contexte aux données, notamment dans les environnements comportant plusieurs systèmes de production ou des données issues de systèmes existants. Dans les analyses, il sert à filtrer ou à segmenter les données selon leur origine. Il est particulièrement utile pour comparer les processus entre différents systèmes ou lors de projets de migration, afin de garantir l'intégrité et la cohérence des données. Pourquoi c’est important Fournit un contexte essentiel, notamment dans les environnements multisystèmes, permet de comparer les processus et garantit la clarté de la traçabilité des données. Où les obtenir Cette valeur est généralement ajoutée lors de l'extraction des données. Il s'agit souvent d'une valeur statique représentant l'identifiant du système SAP (SAPSID) ou le mandant (MANDT). Exemples ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
| Blocage de livraison DeliveryBlock | Code indiquant si une commande client est bloquée pour la livraison, ce qui empêche la création d'un document de livraison. | ||
| Description Le blocage de livraison est un statut défini sur une commande client, au niveau de l'en-tête ou du poste, afin d'interrompre temporairement le processus avant l'étape de livraison. Les blocages peuvent être définis manuellement par un utilisateur ou automatiquement par le système, par exemple en cas de dépassement de limite de crédit ou de données incomplètes. Cet attribut est essentiel au Dashboard « Analyse des blocages et des reprises des commandes clients ». L'analyse de la fréquence, de la durée et des motifs des blocages de livraison aide à identifier les principaux goulots d'étranglement du processus d'exécution. La réduction de ces blocages est déterminante pour améliorer les livraisons dans les délais et le délai global d'exécution. Pourquoi c’est important Identifie directement les goulots d'étranglement du processus d'exécution. L'analyse des raisons et de la fréquence des blocages est essentielle pour améliorer l'efficacité du flux. Où les obtenir Présent dans la table des données d'en-tête du document de vente (VBAK), dans le champ LIFSK. Exemples 0102Z1 | |||
| Montant net NetAmount | Valeur totale de la commande client, hors taxes et remises au niveau de l'en-tête. | ||
| Description Le montant net représente la valeur monétaire de la commande client. Il s'agit d'un indicateur financier clé associé à chaque instance de processus. Cet attribut est essentiel au Process Mining fondé sur la valeur. Il permet de hiérarchiser les initiatives d'amélioration en se concentrant sur les commandes de forte valeur. Les analystes peuvent mettre en relation les problèmes de processus, tels que les retards ou les reprises, avec leur incidence financière, afin de mieux justifier les changements. Il peut par exemple servir à déterminer si les commandes de forte valeur sont traitées plus ou moins efficacement que celles de faible valeur. Pourquoi c’est important Permet une analyse fondée sur la valeur et aide à concentrer les efforts d'amélioration sur les commandes ayant l'incidence financière la plus importante pour l'entreprise. Où les obtenir Présent dans la table des données d'en-tête du document de vente (VBAK), dans le champ NETWR. Exemples 1500.0012550.75850.50 | |||
| Motif de rejet RejectionReason | Code indiquant la raison pour laquelle un poste de commande client a été rejeté ou annulé. | ||
| Description Le motif de rejet explique pourquoi une commande client ou un poste précis n'a pas été exécuté. Il peut s'agir d'une annulation par le client, de l'indisponibilité d'un produit ou d'une autre raison commerciale. Cet attribut est essentiel au Dashboard « Tendances des annulations de commandes clients ». L'analyse des motifs de rejet les plus fréquents permet d'identifier les causes profondes des ventes perdues. Ces résultats peuvent guider des améliorations de la gestion des stocks, de la stratégie tarifaire ou de la communication client afin de réduire le taux d'annulation des commandes. Pourquoi c’est important Explique les raisons des annulations de commandes et permet d'analyser leurs causes profondes afin de réduire les ventes perdues et d'améliorer la précision des prévisions. Où les obtenir Présent dans la table des données de poste du document de vente (VBAP), dans le champ ABGRU. Exemples 0215Z5 | |||
| Numéro d'article MaterialNumber | Identifiant unique du produit ou du service vendu. | ||
| Description Le numéro d'article identifie l'article précis d'un poste de commande client. Une même commande client pouvant contenir plusieurs articles, cet attribut est généralement analysé au niveau du poste. L'analyse du processus par numéro d'article aide à révéler les problèmes propres à certains produits. Elle peut montrer si certains produits sont associés à des délais d'exécution plus longs, à davantage de blocages de livraison ou à des écarts de facturation plus fréquents. Elle est essentielle à la gestion de la chaîne logistique et des produits pour optimiser le processus selon les différentes gammes. Pourquoi c’est important Permet d'analyser les processus par produit et de repérer les produits associés à des inefficacités telles que les retards, les blocages ou les reprises. Où les obtenir Présent dans la table des données de poste du document de vente (VBAP), dans le champ MATNR. Exemples FG-1001-ARAW-205BSERV-INSTALL | |||
| Numéro de client CustomerNumber | Identifiant unique du client ayant passé la commande client. | ||
| Description Cet attribut représente le « donneur d'ordre », c'est-à-dire le compte client principal associé à la commande client. Il relie la transaction à un client précis dans les données de référence. L'analyse par numéro de client permet de segmenter le processus afin de comprendre les comportements et les performances propres à chaque client. Elle aide à répondre à des questions telles que : quels clients ont les délais les plus longs, les taux de reprise les plus élevés ou les changements de commande les plus fréquents ? Elle est essentielle pour améliorer la gestion de la relation client et les niveaux de service. Pourquoi c’est important Permet une analyse centrée sur le client, en aidant à identifier les problèmes de processus qui touchent certains clients et à mesurer les performances propres à chacun. Où les obtenir Présent dans la table des données d'en-tête du document de vente (VBAK), dans le champ KUNNR. Exemples 100234100567200112 | |||
| Organisation commerciale SalesOrganization | Unité organisationnelle responsable de la vente de produits ou de services. | ||
| Description Une organisation commerciale est une entité organisationnelle clé dans SAP, qui structure l'entreprise en fonction de ses besoins commerciaux. Elle est responsable de la négociation des conditions de vente et de la distribution des marchandises et des services. Dans le Process Mining, cet attribut constitue une dimension essentielle de l'analyse. Il permet de comparer les performances, l'efficacité et la conformité des processus entre différentes unités commerciales, régions ou divisions. Cette comparaison aide à repérer les bonnes pratiques des organisations les plus performantes et les domaines à améliorer dans les autres. Pourquoi c’est important Permet d'établir des comparaisons organisationnelles et de comparer l'efficacité et la conformité des processus entre différentes unités opérationnelles ou régions. Où les obtenir Présent dans la table des données d'en-tête du document de vente (VBAK), dans le champ VKORG. Exemples 100025003100 | |||
| Utilisateur User | Identifiant de l'utilisateur ayant créé ou modifié le document pour la dernière fois, ou ayant exécuté l'activité. | ||
| Description Cet attribut enregistre l'identifiant de l'utilisateur SAP responsable d'un événement donné du processus. Il permet par exemple d'identifier le gestionnaire commercial qui a créé la commande ou le personnel d'entrepôt qui a enregistré la sortie de marchandises. L'analyse du processus par utilisateur aide à comprendre la répartition de la charge de travail, à identifier les besoins de formation et à détecter les différences dans l'exécution d'une même tâche. Elle est essentielle pour les Dashboards consacrés à la performance des ressources, à la conformité et à l'identification des interventions manuelles. Pourquoi c’est important Donne de la visibilité sur la performance et la charge de travail des ressources, aide à repérer les écarts propres à certains utilisateurs et joue un rôle clé dans les analyses de conformité et d'automatisation. Où les obtenir Présent dans de nombreuses tables d'en-tête SAP, dans le champ « Créé par » (ERNAM) ou « Modifié par » (AENAM), notamment dans VBAK, LIKP et VBRK. Exemples CBURKEJSMITHRWILLIAMS | |||
| Conditions d'expédition ShippingConditions | Définit la stratégie générale d'expédition des marchandises au client. | ||
| Description Les conditions d'expédition déterminent la manière dont une commande sera expédiée, par exemple en mode « standard », « express » ou « retrait ». Elles sont convenues avec le client et influencent la planification logistique. Cet attribut est utilisé dans l'analyse « Efficacité et coût des modes d'expédition ». En segmentant le processus selon les conditions d'expédition, les entreprises peuvent déterminer si certains modes sont davantage sujets aux retards ou présentent des délais plus longs. Ces données aident à optimiser la logistique et à gérer les attentes des clients concernant les délais de livraison. Pourquoi c’est important Permet d'analyser les performances logistiques et de déterminer si certains modes d'expédition sont associés à des retards ou à une meilleure efficacité. Où les obtenir Présent dans la table des données d'en-tête du document de vente (VBAK), dans le champ VSBED. Exemples 011020 | |||
| Date de livraison confirmée ConfirmedDeliveryDate | Date à laquelle la livraison des marchandises ou des services a été confirmée au client. | ||
| Description Il s'agit de la date de livraison promise au client, déterminée en fonction de la disponibilité des articles et de la planification. Elle sert de référence pour mesurer la performance des livraisons. Cet attribut constitue la base du Dashboard « Performance des livraisons dans les délais » et du KPI de taux de livraison dans les délais. En comparant la date de livraison confirmée à la date réelle de « sortie de marchandises », l'analyse permet de déterminer si une commande a été livrée à temps, en avance ou en retard. Il s'agit d'un indicateur majeur de la fiabilité de la chaîne logistique et de la satisfaction client. Pourquoi c’est important Il s'agit de la référence pour mesurer la performance des livraisons dans les délais, un KPI essentiel pour la satisfaction client et l'efficacité de la chaîne logistique. Où les obtenir Présent dans la table des lignes d'échéancier du document de vente (VBEP), dans le champ EDATU. Exemples 2023-05-102023-06-202023-07-01 | |||
| Livraison dans les délais IsOnTimeDelivery | Indicateur booléen précisant si les marchandises ont été expédiées à la date de livraison confirmée ou avant celle-ci. | ||
| Description Cet attribut calculé compare la date réelle de sortie de marchandises à la « ConfirmedDeliveryDate » d'une commande client. Si la date de sortie de marchandises est antérieure ou égale à la date confirmée, la valeur est « vrai », sinon elle est « faux ». Cet attribut simplifie la création du Dashboard « Performance des livraisons dans les délais » et le calcul du KPI de taux de livraison dans les délais. Il permet d'agréger et de visualiser facilement les performances sans devoir effectuer les comparaisons de dates à la volée dans chaque analyse ou graphique. Il fournit ainsi une mesure claire et immédiate de la fiabilité des livraisons. Pourquoi c’est important Fournit une mesure claire et simple de la performance des livraisons et facilite le calcul du KPI global de taux de livraison dans les délais. Où les obtenir Il s'agit d'un attribut calculé. La logique compare l'horodatage de l'activité « sortie de marchandises » à la valeur de l'attribut « ConfirmedDeliveryDate ». Exemples truefalse | |||
| Reprise nécessaire IsRework | Indicateur booléen précisant si une commande client a fait l'objet d'une modification importante ou d'une reprise après sa création initiale. | ||
| Description Cet attribut calculé identifie les instances de processus ayant fait l'objet d'une reprise, par exemple lorsqu'une ou plusieurs activités « commande client modifiée » ont eu lieu. La logique précise définissant une reprise, comme une modification du prix, de la quantité ou de la date de livraison, est établie lors de la configuration du projet. Cet attribut est essentiel au Dashboard « Reprises et fréquence des modifications des commandes clients » et au KPI de taux de reprise des commandes clients. Il simplifie l'analyse en permettant de filtrer et de comparer directement les commandes ayant suivi un parcours « de bout en bout » à celles qui ont nécessité des modifications manuelles. Il aide ainsi à quantifier l'incidence des reprises sur les délais et les coûts. Pourquoi c’est important Quantifie directement la fréquence des reprises et permet d'analyser leurs causes ainsi que leur incidence sur l'efficacité globale et le délai du processus. Où les obtenir Il s'agit d'un attribut calculé à partir du journal d'événements. La logique vérifie la présence d'activités « commande client modifiée » ou d'événements de modification précis issus des tables CDHDR/CDPOS. Exemples truefalse | |||
| Statut du contrôle de solvabilité CreditCheckStatus | Indique le statut du contrôle de solvabilité du document de vente. | ||
| Description Cet attribut indique le résultat du contrôle de solvabilité automatisé ou manuel effectué sur une commande client. Les statuts courants sont « approuvé », « rejeté » ou « bloqué ». Il s'agit d'un attribut clé du Dashboard « Analyse du délai de traitement du contrôle de solvabilité ». Les retards ou les blocages à cette étape peuvent avoir une incidence importante sur le délai global d'exécution de la commande. L'analyse de ce statut aide à comprendre l'efficacité du processus de gestion du crédit et son incidence sur la rapidité des ventes. Pourquoi c’est important A une incidence directe sur la vitesse de traitement des commandes. L'analyse de ce statut aide à identifier les goulots d'étranglement de la gestion du crédit qui retardent l'exécution des commandes. Où les obtenir Présent dans la table des statuts d'en-tête du document de vente (VBUK) ou directement dans VBAK, dans le champ de statut du crédit, par exemple CMGST. Exemples ABD | |||
Order to Cash, activités de traitement des commandes clients
| Activité | Description | ||
|---|---|---|---|
| Commande client créée | Indique la création d’un nouveau document de commande client. Il s’agit d’un événement explicite enregistré lorsqu’un utilisateur sauvegarde une nouvelle commande, généralement au moyen de la transaction VA01 dans SAP. | ||
| Pourquoi c’est important Il s’agit de l’événement de début principal du processus Order to Cash. L’analyse de son horodatage est essentielle pour mesurer le temps de cycle global et le volume de commandes reçues. Où les obtenir Enregistré dans la table VBAK (données d’en-tête du document commercial) à l’aide de la date de création (ERDAT) et de l’heure de création (ERZET). Le code de transaction est stocké dans VBAK-TCODE. Collecte Événement fondé sur l’horodatage de création (ERDAT, ERZET) dans la table VBAK. Type d’événement explicit | |||
| Commande confirmée | Cette activité indique que la commande client a passé tous les contrôles initiaux et est confirmée pour son exécution. Elle est généralement déduite lorsque la commande n’est plus bloquée et que des quantités sont confirmées dans ses lignes d’échéancier. | ||
| Pourquoi c’est important Il s’agit d’une étape importante qui sépare la saisie de la commande de son exécution. Elle constitue le point de départ pour mesurer les délais d’exécution et la performance des livraisons à temps. Où les obtenir Peut être déduit lorsque les lignes d’échéancier de VBEP comportent une quantité confirmée (BMENG > 0) et que la commande n’est pas bloquée pour la livraison, par exemple lorsque VBUK-LIFSK est vide. Collecte Déduit de la confirmation des lignes d’échéancier (VBEP-BMENG > 0) et de la suppression des blocages au niveau de l’en-tête. Type d’événement inferred | |||
| Facture créée | Marque la création de la facture client ou du document de facturation. Il s'agit d'un événement explicite qui génère un nouveau document dans le système et lance la phase de paiement du processus. | ||
| Pourquoi c’est important Il s'agit d'une étape essentielle qui lance le calcul du « délai entre facturation et paiement ». Les retards de facturation ont une incidence directe sur la trésorerie. Où les obtenir Enregistré dans la table VBRK (document de facturation : données d'en-tête) à partir de sa date de création (ERDAT). Le lien vers la commande client ou la livraison se trouve dans la table VBFA. Collecte Événement fondé sur l'horodatage de création (ERDAT) dans la table VBRK. Type d’événement explicit | |||
| Paiement reçu | Cet événement indique que le paiement du client a été reçu et affecté à la facture, soldant le poste ouvert des créances clients. Il s'agit d'un événement comptable, déduit du lettrage d'un document financier. | ||
| Pourquoi c’est important Il s'agit de la dernière étape pour convertir la vente en encaissement. Elle marque la fin du calcul du « délai entre facturation et paiement » et du « délai global d'exécution de la commande client ». Où les obtenir Déduit des informations du document de lettrage dans la table BSEG pour le poste client. Lorsque BSEG-AUGBL (document de lettrage) et BSEG-AUGDT (date de lettrage) sont renseignés, le paiement est considéré comme reçu. Collecte Déduit du renseignement de la date de lettrage (AUGDT) dans la table BSEG pour le poste de créance client. Type d’événement inferred | |||
| Poste de commande clôturé | Cette activité marque la clôture définitive d'un poste de commande client, indiquant qu'il a été entièrement livré, facturé et considéré comme terminé. Cette information est déduite du statut global du poste. | ||
| Pourquoi c’est important Elle constitue l'événement de fin réussie du processus. L'analyse de la date de clôture des postes aide à comprendre la durée du processus de bout en bout et à repérer les commandes qui restent ouvertes inutilement. Où les obtenir Déduit du champ de statut global de la table VBUP (document de vente : statut du poste). Lorsque VBUP-GBSTA vaut « C » (traité intégralement), le poste est clôturé. Collecte Déduit du changement du statut du poste (VBUP-GBSTA) à « C » (traité intégralement). Type d’événement inferred | |||
| Sortie de marchandises | Événement essentiel au cours duquel la propriété des marchandises est transférée et celles-ci quittent officiellement l'entrepôt. Il s'agit d'une écriture financière explicite qui crée un document article et met à jour les stocks. | ||
| Pourquoi c’est important Il s'agit de l'événement d'expédition et d'une étape clé pour mesurer le taux de livraison dans les délais et les délais d'exécution des commandes. Il déclenche les mises à jour financières et constitue un point de non-retour dans le processus physique d'exécution. Où les obtenir Création d'un document article (MKPF/MSEG) avec un type de mouvement de sortie de marchandises, par exemple 601, lié au document de livraison. Collecte Création d'un document article (MKPF/MSEG) avec un type de mouvement de sortie de marchandises, lié à la livraison. Type d’événement explicit | |||
| Blocage de livraison défini | Représente l’action consistant à appliquer un blocage de livraison à la commande client, ce qui empêche la création d’un document de livraison. Cet événement peut être enregistré explicitement dans les journaux de modifications ou déduit des tables de statut. | ||
| Pourquoi c’est important Cette activité est directement liée au KPI « taux de blocage des commandes client ». Identifier pourquoi et à quelle fréquence les blocages sont définis aide à comprendre les causes des retards d’exécution. Où les obtenir Peut être trouvé dans les journaux de modifications (CDHDR/CDPOS) pour le champ VBAK-LIFSK. Il peut également être déduit en observant les moments où le champ VBAK-LIFSK est renseigné. Collecte Événement issu des documents de modification pour le champ VBAK-LIFSK ou VBAP-LIFSP. Type d’événement explicit | |||
| Commande annulée | Indique qu'une commande client a été annulée avant son exécution. Cette situation est généralement enregistrée lorsqu'un « motif de rejet » est appliqué à tous les postes concernés de la commande. | ||
| Pourquoi c’est important Il s'agit d'un point de terminaison correspondant à un échec important, directement pris en compte dans le KPI « taux d'annulation des commandes ». Comprendre quand et pourquoi les commandes sont annulées permet d'identifier les problèmes du processus commercial. Où les obtenir Déduit du renseignement du champ VBAP-ABGRU (motif de rejet) pour tous les postes actifs d'une commande client. La date de modification peut être trouvée dans CDHDR/CDPOS. Collecte Déduit du renseignement du champ « motif de rejet » (VBAP-ABGRU) sur tous les postes. Type d’événement inferred | |||
| Commande client modifiée | Représente une modification apportée à une commande client existante après sa création initiale. Ces changements sont enregistrés dans les tables dédiées aux journaux de modifications (CDHDR, CDPOS) lorsque des champs tels que la quantité, le prix ou les dates sont modifiés. | ||
| Pourquoi c’est important Le suivi des modifications aide à repérer les reprises, l’instabilité du processus et les problèmes de qualité des données. Une fréquence élevée de changements peut révéler des problèmes lors de la saisie initiale de la commande et entraîner des retards. Où les obtenir Récupéré dans les tables des documents de modification CDHDR (en-tête) et CDPOS (poste) pour OBJECTCLAS = « VERKBELEG ». L’horodatage et le champ modifié peuvent être identifiés. Collecte Événement issu des tables des documents de modification (CDHDR, CDPOS) pour les objets de documents commerciaux. Type d’événement explicit | |||
| Contrôle de crédit effectué | Indique que le contrôle de crédit automatique ou manuel du client associé à la commande client est terminé. Cet événement est généralement déduit d’une modification du statut de crédit global du document. | ||
| Pourquoi c’est important Le contrôle de crédit constitue souvent un goulot d’étranglement important. Mesurer le temps nécessaire à cette étape est essentiel pour l’« analyse de la durée du contrôle de crédit » et pour accélérer le traitement des commandes. Où les obtenir Déduit des champs de statut de crédit de la table VBUK (document commercial : statut d’en-tête). Le passage de VBUK-CMGST de bloqué à libéré marque cette activité. Collecte Déduit des modifications apportées au champ de statut de crédit global (VBUK-CMGST). Type d’événement inferred | |||
| Facture annulée | Représente l'extourne d'un document de facturation créé précédemment. Il s'agit d'une transaction explicite qui crée un nouveau document d'annulation pour contrepasser le document d'origine. | ||
| Pourquoi c’est important Le suivi des annulations de factures aide à identifier les problèmes liés aux prix, aux écarts d'expédition ou aux erreurs de données. Il contribue au KPI « taux d'écart de facturation ». Où les obtenir Événement explicite enregistré lors de la création d'un document de facturation d'annulation (VBRK-VBTYP = « N » ou « O »). La facture d'origine est référencée dans VBRK-SFAKN. Collecte Création d'un document d'annulation dans VBRK, faisant référence à la facture d'origine. Type d’événement explicit | |||
| Livraison créée | Cet événement marque la création du document de livraison sortante, qui constitue l’instruction donnée à l’entrepôt de commencer les activités de picking et d’expédition. Il s’agit d’un événement explicite enregistré dans le flux documentaire. | ||
| Pourquoi c’est important Il s’agit de la première étape du processus d’exécution physique. Le délai entre la confirmation de la commande et la création de la livraison indique la rapidité avec laquelle le processus logistique est lancé. Où les obtenir Création d’un enregistrement dans la table LIKP (données d’en-tête de livraison du document SD). Le lien avec la commande client est conservé dans la table de flux documentaire VBFA. Collecte Événement fondé sur l’horodatage de création dans la table LIKP, avec un lien établi via la table VBFA. Type d’événement explicit | |||
| Picking terminé | Indique que tous les articles destinés à la livraison ont été prélevés physiquement dans l'entrepôt. Si Warehouse Management (WM) est utilisé, cette information peut être déduite du statut de l'ordre de transfert. | ||
| Pourquoi c’est important L'analyse du temps de prélèvement aide à optimiser les opérations d'entrepôt. Les retards à cette étape ont une incidence directe sur le calendrier global d'expédition et le cycle d'exécution des commandes. Où les obtenir Déduit du changement du statut de prélèvement de l'article de livraison dans la table LIPS-KOSTA, qui passe à « C » (entièrement prélevé). Si WM est actif, l'information peut être déduite de la confirmation de l'ordre de transfert (tables LTAK/LTAP). Collecte Déduit de la modification du statut de prélèvement (LIPS-KOSTA) ou de la confirmation de l'ordre de transfert WM. Type d’événement inferred | |||
| Preuve de livraison confirmée | Cette activité représente la confirmation que le client a reçu les marchandises. Elle est enregistrée lorsque la preuve de livraison est saisie dans le système, ce qui met souvent à jour le statut du document de livraison. | ||
| Pourquoi c’est important Cet événement fournit la date réelle de livraison, essentielle pour mesurer précisément le « taux de livraison dans les délais » par rapport à la date promise. Où les obtenir Déduit du statut de la preuve de livraison (VBUK-PODAT) défini sur « C » (confirmé). La date de confirmation est enregistrée dans VLPOD-PODAT. Cette fonction n'est pas toujours mise en œuvre. Collecte Déduit de la mise à jour du statut POD sur la livraison (VBUK-PODAT) ou d'une entrée dans la table VLPOD. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Développer le programme : à l’aide de la transaction SE38 ou SE80, créez un nouveau programme ABAP exécutable. Ce programme contiendra toute la logique d’extraction.
- Définir l’écran de sélection : dans votre programme, créez un écran de sélection pour filtrer les données. Ajoutez des paramètres pour la date de création du document de vente (VBAK-ERDAT), l’organisation commerciale (VBAK-VKORG) et le type de document de vente (VBAK-AUART). L’extraction sera ainsi réutilisable et plus facile à gérer.
- Déclarer les données : définissez les tables internes et les structures nécessaires pour contenir les données des différentes tables SAP, par exemple VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK et BSAD. Définissez également la structure de sortie finale de l’Event Log, en respectant les attributs requis.
- Sélectionner les commandes clients de base : écrivez l’instruction SELECT initiale pour récupérer les en-têtes de commandes clients (VBAK) et les postes (VBAP) à partir des valeurs saisies sur l’écran de sélection. Cet ensemble constitue la base des cas à analyser.
- Extraire l’événement « Création » : parcourez les enregistrements VBAK sélectionnés. Pour chacun, renseignez la structure de l’Event Log avec l’activité « Sales Order Created », en utilisant VBAK-ERDAT et VBAK-ERZET pour StartTime.
- Extraire les événements du journal des modifications : sélectionnez dans CDHDR et CDPOS les enregistrements dont OBJECTCLAS est « VERKBELEG » pour les commandes clients sélectionnées. Parcourez les résultats afin d’identifier les modifications de champs précises. Par exemple, une modification de VBAK-LIFSK indique « Delivery Block Set », tandis qu’une modification de VBUK-CMGST indique « Credit Check Performed ». Toute autre modification pertinente peut être enregistrée comme « Sales Order Changed ».
- Extraire les données du flux de documents : pour les commandes clients sélectionnées, interrogez la table du flux de documents (VBFA). Cette table relie les commandes clients aux documents ultérieurs, tels que les livraisons, les mouvements de marchandises et les factures. Sélectionnez tous les documents associés pour poursuivre le traitement.
- Extraire les événements de livraison et d’exécution : à l’aide des numéros de livraison issus de VBFA, interrogez LIKP pour les événements « Delivery Created ». Interrogez MKPF et MSEG pour les documents de sortie de marchandises, avec le type de mouvement « 601 », afin de capturer l’événement « Goods Issued ». Si Warehouse Management est actif, interrogez LTAK et LTAP pour trouver l’heure de confirmation du dernier poste d’ordre de transfert et déterminer « Picking Completed ». Vérifiez le statut d’en-tête de livraison VBUK-PODAT pour « Proof of Delivery Confirmed ».
- Extraire les événements de facturation et de paiement : à l’aide des numéros de documents de facturation issus de VBFA, interrogez VBRK et VBRP pour capturer les événements « Invoice Created » et « Invoice Cancelled » lorsque VBRK-FKSTO = « X ». Pour trouver « Payment Received », reliez la facture de VBRK au document comptable dans BKPF, puis recherchez le document de compensation et la date de compensation dans BSAD.
- Extraire les événements fondés sur les statuts : utilisez les tables de statuts VBUP (statut de poste) et VBUK (statut d’en-tête) pour déduire les événements métier. Par exemple, un poste est considéré comme « Order Item Closed » lorsque VBUP-GBSTA est égal à « C ». Une commande est « Order Cancelled » lorsqu’un « Reason for Rejection » (VBAP-ABGRU) est défini pour tous les postes concernés.
- Consolider et formater : regroupez tous les événements capturés dans une table interne finale. Vérifiez que tous les attributs, notamment SalesOrder, Activity, StartTime et User, sont correctement renseignés pour chaque enregistrement. Ajoutez les horodatages SourceSystem et LastDataUpdate.
- Générer le fichier de sortie : utilisez le module de fonction GUI_DOWNLOAD ou la méthode cl_gui_frontend_services=>gui_download pour exporter la table interne finale dans un fichier CSV sur l’ordinateur local de l’utilisateur. Vérifiez que le fichier est enregistré avec l’encodage UTF-8.
Configuration
- Prérequis : autorisations de développement ABAP, par exemple l’accès à la transaction SE38, et droits de lecture sur toutes les tables SAP requises, notamment VBAK, VBAP, CDHDR, CDPOS, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG et BSAD.
- Paramètres de sélection : le programme doit comporter un écran de sélection avec des paramètres de filtrage. Les principaux paramètres sont les suivants :
- Période : une période obligatoire pour la création des commandes clients (VBAK-ERDAT). Commencez par une période récente de 3 à 6 mois afin de conserver un volume de données gérable.
- Organisation commerciale : filtrez sur VBAK-VKORG pour concentrer l’analyse sur certaines unités opérationnelles.
- Type de document de vente : filtrez sur VBAK-AUART afin d’inclure uniquement les types de commandes pertinents, par exemple les commandes standard, et d’exclure les autres, comme les offres et les retours.
- Considérations relatives aux performances : l’extraction des tables de journaux de modifications (CDHDR, CDPOS) et du flux de documents (VBFA) peut être très lente pour les volumes importants. Le programme doit être optimisé afin d’utiliser les champs d’index dans les clauses WHERE. Pour les extractions très volumineuses, planifiez l’exécution du programme comme tâche en arrière-plan pendant les heures creuses à l’aide de la transaction SM36.
- Activation du journal des modifications : cette méthode repose sur la fonctionnalité SAP des documents de modification. Vérifiez que la journalisation des modifications est activée pour les éléments de données clés, par exemple LIFSK, CMGST et ABGRU. Vous pouvez le vérifier via la transaction SCDO pour l’objet VERKBELEG.
a Exemple de requête abap
REPORT Z_O2C_PM_EXTRACTOR.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
TABLES: vbak.
TYPES: BEGIN OF ty_event_log,
salesorder TYPE vbeln_va,
activity TYPE string,
starttime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
user TYPE ernam,
customernumber TYPE kunnr,
salesorganization TYPE vkorg,
netamount TYPE netwr,
materialnumber TYPE matnr,
deliveryblock TYPE lifsk,
rejectionreason TYPE abgru,
salesordercycletime TYPE string, " Placeholder for calculation
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gs_event_log TYPE ty_event_log.
DATA: gv_sysid TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbak-erdat OBLIGATORY,
s_vkorg FOR vbak-vkorg,
s_auart FOR vbak-auart.
PARAMETERS: p_file TYPE rlgrap-filename OBLIGATORY DEFAULT 'C:\temp\o2c_event_log.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_sysid.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
PERFORM get_base_data.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form get_base_data
*&---------------------------------------------------------------------*
FORM get_base_data.
TYPES: BEGIN OF ty_order_item,
vbeln TYPE vbeln_va,
posnr TYPE posnr_va,
erdat TYPE erdat,
erzet TYPE erzet,
ernam TYPE ernam,
kunnr TYPE kunnr,
vkorg TYPE vkorg,
netwr TYPE netwr_ak,
matnr TYPE matnr,
lifsk TYPE lifsk,
abgru TYPE abgru,
END OF ty_order_item.
DATA: lt_order_items TYPE TABLE OF ty_order_item.
SELECT h~vbeln i~posnr h~erdat h~erzet h~ernam h~kunnr h~vkorg h~netwr i~matnr h~lifsk i~abgru
INTO TABLE lt_order_items
FROM vbak AS h
INNER JOIN vbap AS i ON h~vbeln = i~vbeln
WHERE h~erdat IN s_erdat
AND h~vkorg IN s_vkorg
AND h~auart IN s_auart.
CHECK sy-subrc = 0.
DATA(lt_vbeln_range) = VALUE rsdsselopt_t(
FOR <fs_item> IN lt_order_items WHERE ( vbeln = <fs_item>-vbeln )
( sign = 'I' option = 'EQ' low = <fs_item>-vbeln ) ).
SORT lt_vbeln_range BY low.
DELETE ADJACENT DUPLICATES FROM lt_vbeln_range COMPARING low.
PERFORM extract_order_created USING lt_order_items.
PERFORM extract_changes USING lt_vbeln_range lt_order_items.
PERFORM extract_doc_flow_events USING lt_vbeln_range lt_order_items.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_order_created
*&---------------------------------------------------------------------*
FORM extract_order_created USING it_order_items TYPE ANY TABLE.
FIELD-SYMBOLS: <fs_item> TYPE any.
DATA: lt_unique_orders TYPE HASHED TABLE OF vbeln_va WITH UNIQUE KEY table_line.
lt_unique_orders = VALUE #( FOR <order> IN it_order_items ( CONV vbeln_va( <order>-vbeln ) ) ).
LOOP AT it_order_items ASSIGNING <fs_item> WHERE table_line IN lt_unique_orders.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Sales Order Created'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
gs_event_log-salesorganization = <fs_item>-vkorg.
gs_event_log-netamount = <fs_item>-netwr.
APPEND gs_event_log TO gt_event_log.
DELETE lt_unique_orders WHERE table_line = <fs_item>-vbeln.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_changes
*&---------------------------------------------------------------------*
FORM extract_changes USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_cdhdr TYPE TABLE OF cdhdr,
lt_cdpos TYPE TABLE OF cdpos.
SELECT * INTO TABLE lt_cdhdr FROM cdhdr
WHERE objectclas = 'VERKBELEG'
AND objectid IN it_vbeln_range
AND tcode = 'VA02'.
IF sy-subrc = 0.
SELECT * INTO TABLE lt_cdpos FROM cdpos
FOR ALL ENTRIES IN lt_cdhdr
WHERE objectclas = lt_cdhdr-objectclas
AND objectid = lt_cdhdr-objectid
AND changenr = lt_cdhdr-changenr.
ENDIF.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_cdhdr>-objectid ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_cdhdr>-objectid.
gs_event_log-user = <fs_cdhdr>-username.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO gs_event_log-starttime.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
" Generic Change Event
gs_event_log-activity = 'Sales Order Changed'.
APPEND gs_event_log TO gt_event_log.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>)
WHERE objectclas = <fs_cdhdr>-objectclas
AND objectid = <fs_cdhdr>-objectid
AND changenr = <fs_cdhdr>-changenr.
CASE <fs_cdpos>-fname.
WHEN 'LIFSK'. " Delivery Block
gs_event_log-activity = 'Delivery Block Set'.
gs_event_log-deliveryblock = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
WHEN 'CMGST'. " Credit Status
IF <fs_cdpos>-value_new = 'B'. " B = Credit Check OK
gs_event_log-activity = 'Credit Check Performed'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'ABGRU'. " Rejection Reason
IF <fs_cdpos>-value_new IS NOT INITIAL.
gs_event_log-activity = 'Order Cancelled'.
gs_event_log-rejectionreason = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_doc_flow_events
*&---------------------------------------------------------------------*
FORM extract_doc_flow_events USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_vbfa TYPE TABLE OF vbfa,
lt_vbrk TYPE TABLE OF vbrk,
lt_likp TYPE TABLE OF likp,
lt_mseg TYPE TABLE OF mseg,
lt_bsad TYPE TABLE OF bsad,
lt_vbup TYPE TABLE OF vbup.
SELECT * INTO TABLE lt_vbfa FROM vbfa
WHERE vbelv IN it_vbeln_range
AND ( vbtyp_n = 'J' " Delivery
OR vbtyp_n = 'M' " Invoice
OR vbtyp_n = 'N' " Invoice Cancellation
OR vbtyp_n = 'R' ). " Goods Movement
IF lt_vbfa IS INITIAL. RETURN. ENDIF.
SELECT vbeln, erdat, erzet, ernam, fksto, belnr FROM vbrk INTO TABLE lt_vbrk
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln
AND ( lt_vbfa-vbtyp_n = 'M' OR lt_vbfa-vbtyp_n = 'N' ).
SELECT vbeln, erdat, erzet, ernam, podat FROM likp INTO TABLE lt_likp
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln AND lt_vbfa-vbtyp_n = 'J'.
SELECT mblnr, mjahr, zeile, bwart, budat, cpuzt, usnam FROM mseg INTO TABLE lt_mseg
FOR ALL ENTRIES IN lt_vbfa
WHERE mblnr = lt_vbfa-vbeln AND mjahr = lt_vbfa-mjahr AND zeile = lt_vbfa-posnn AND lt_vbfa-vbtyp_n = 'R' AND bwart = '601'.
SELECT augdt, belnr, gjahr, kunnr FROM bsad INTO TABLE lt_bsad
FOR ALL ENTRIES IN lt_vbrk
WHERE belnr = lt_vbrk-belnr AND gjahr = SUBSTRING( val = lt_vbrk-erdat len = 4 ).
SELECT vbeln, posnr, gbsta FROM vbup INTO TABLE lt_vbup
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbelv AND posnr = lt_vbfa-posnv.
LOOP AT lt_vbfa ASSIGNING FIELD-SYMBOL(<fs_vbfa>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_vbfa>-vbelv ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_vbfa>-vbelv.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
gs_event_log-materialnumber = lv_order_info->matnr.
CASE <fs_vbfa>-vbtyp_n.
WHEN 'J'. " Delivery
READ TABLE lt_likp ASSIGNING FIELD-SYMBOL(<fs_likp>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Delivery Created'.
CONCATENATE <fs_likp>-erdat <fs_likp>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_likp>-ernam.
APPEND gs_event_log TO gt_event_log.
" Picking Completed - simplified logic, check status
gs_event_log-activity = 'Picking Completed'. APPEND gs_event_log TO gt_event_log.
" POD Confirmed
IF <fs_likp>-podat IS NOT INITIAL.
gs_event_log-activity = 'Proof Of Delivery Confirmed'.
gs_event_log-starttime = <fs_likp>-podat.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'R'. " Goods Issue
READ TABLE lt_mseg ASSIGNING FIELD-SYMBOL(<fs_mseg>) WITH KEY mblnr = <fs_vbfa>-vbeln mjahr = <fs_vbfa>-mjahr zeile = <fs_vbfa>-posnn.
IF sy-subrc = 0.
gs_event_log-activity = 'Goods Issued'.
CONCATENATE <fs_mseg>-budat <fs_mseg>-cpuzt INTO gs_event_log-starttime.
gs_event_log-user = <fs_mseg>-usnam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'M'. " Invoice
READ TABLE lt_vbrk ASSIGNING FIELD-SYMBOL(<fs_vbrk>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Invoice Created'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
" Payment Received
READ TABLE lt_bsad ASSIGNING FIELD-SYMBOL(<fs_bsad>) WITH KEY belnr = <fs_vbrk>-belnr.
IF sy-subrc = 0 AND <fs_bsad>-augdt IS NOT INITIAL.
gs_event_log-activity = 'Payment Received'.
gs_event_log-starttime = <fs_bsad>-augdt.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'N'. " Invoice Cancellation
READ TABLE lt_vbrk ASSIGNING <fs_vbrk> WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0 AND <fs_vbrk>-fksto = 'X'.
gs_event_log-activity = 'Invoice Cancelled'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
" Infer other events from status
LOOP AT lt_vbup ASSIGNING FIELD-SYMBOL(<fs_vbup>).
IF <fs_vbup>-gbsta = 'C'.
DATA(lv_order_info_stat) = REF #( it_order_items[ vbeln = <fs_vbup>-vbeln ] ).
IF lv_order_info_stat IS NOT BOUND. CONTINUE. ENDIF.
gs_event_log-salesorder = <fs_vbup>-vbeln.
gs_event_log-activity = 'Order Item Closed'.
" Timestamp for closed is harder, using current time as placeholder
CONCATENATE sy-datum sy-uzeit INTO gs_event_log-starttime.
gs_event_log-user = sy-uname.
gs_event_log-customernumber = lv_order_info_stat->kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
" Order Confirmed (Simplified - assumes if not blocked it's confirmed)
LOOP AT it_order_items ASSIGNING FIELD-SYMBOL(<fs_item>).
IF <fs_item>-lifsk IS INITIAL.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Order Confirmed'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form write_output_file
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lt_final_output TYPE TABLE OF ty_event_log.
" Add common fields
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
<fs_event>-sourcesystem = gv_sysid.
<fs_event>-lastdataupdate = gv_last_update.
ENDLOOP.
SORT gt_event_log BY salesorder starttime.
DELETE ADJACENT DUPLICATES FROM gt_event_log COMPARING ALL FIELDS.
lt_final_output = gt_event_log.
DATA: lt_fieldnames TYPE TABLE OF string.
APPEND 'SalesOrder' TO lt_fieldnames.
APPEND 'Activity' TO lt_fieldnames.
APPEND 'StartTime' TO lt_fieldnames.
APPEND 'SourceSystem' TO lt_fieldnames.
APPEND 'LastDataUpdate' TO lt_fieldnames.
APPEND 'User' TO lt_fieldnames.
APPEND 'CustomerNumber' TO lt_fieldnames.
APPEND 'SalesOrganization' TO lt_fieldnames.
APPEND 'NetAmount' TO lt_fieldnames.
APPEND 'MaterialNumber' TO lt_fieldnames.
APPEND 'DeliveryBlock' TO lt_fieldnames.
APPEND 'RejectionReason' TO lt_fieldnames.
APPEND 'SalesOrderCycleTime' TO lt_fieldnames.
DATA(lv_header) = REDUCE string(
INIT s = ''
FOR field IN lt_fieldnames
NEXT s = s && COND #( WHEN s = '' THEN field ELSE |,{ field }| ) ).
DATA: lt_file_content TYPE TABLE OF string.
APPEND lv_header TO lt_file_content.
LOOP AT lt_final_output INTO DATA(ls_output).
DATA(lv_line) = |"{ ls_output-salesorder }","{ ls_output-activity }","{ ls_output-starttime }","{ ls_output-sourcesystem }","{ ls_output-lastdataupdate }","{ ls_output-user }","{ ls_output-customernumber }","{ ls_output-salesorganization }",{ ls_output-netamount },"{ ls_output-materialnumber }","{ ls_output-deliveryblock }","{ ls_output-rejectionreason }","{ ls_output-salesordercycletime }"|.
APPEND lv_line TO lt_file_content.
ENDLOOP.
cl_gui_frontend_services=>gui_download(
EXPORTING
filename = p_file
filetype = 'ASC'
CHANGING
data_tab = lt_file_content ).
ENDFORM. Étapes
- Prérequis : vérifiez que vous disposez d’un accès direct en lecture seule à la base de données SAP ECC sous-jacente. Vous aurez besoin d’un outil client de base de données tel que DBeaver, SQL Server Management Studio ou Oracle SQL Developer pour vous connecter et exécuter les requêtes.
- Obtenir le script SQL : copiez la requête SQL complète fournie dans la section « query » de ce document.
- Se connecter à la base de données : ouvrez votre client de base de données et établissez une connexion à l’instance de la base SAP ECC. Vous aurez besoin de l’adresse du serveur, du port, du nom de la base de données et des identifiants de connexion appropriés.
- Configurer la requête : collez le script SQL dans une nouvelle fenêtre de l’éditeur de requêtes. Repérez la section de configuration dans l’expression de table commune (CTE) principale nommée SalesOrders. Remplacez les valeurs fictives de la date de début (« {StartDate} »), de la date de fin (« {EndDate} »), des organisations commerciales (« {SalesOrgs} ») et des types de documents (« {DocTypes} ») par les valeurs réelles de votre analyse.
- Exécuter la requête : lancez le script SQL configuré. Selon la période et la taille de votre base SAP, l’exécution peut prendre plusieurs minutes.
- Vérifier les résultats : une fois la requête terminée, un jeu de résultats s’affiche. Vérifiez rapidement qu’il contient les colonnes attendues, notamment SalesOrder, Activity et StartTime, et que des lignes sont renvoyées pour différentes activités.
- Exporter les données : utilisez la fonction d’exportation de votre client de base de données pour enregistrer le jeu de résultats dans un fichier CSV. Donnez-lui un nom explicite, par exemple SAP_O2C_Event_Log.csv.
- Formater pour ProcessMind : ouvrez le fichier CSV dans un tableur. Vérifiez que les en-têtes de colonnes correspondent exactement aux attributs requis, par exemple SalesOrder, Activity et StartTime. Assurez-vous que le format de date et d’heure de StartTime et LastDataUpdate est cohérent et pris en charge par ProcessMind, par exemple YYYY-MM-DD HH:MI:SS.
- Charger dans ProcessMind : chargez le fichier CSV final, correctement formaté, dans votre projet ProcessMind pour l’analyser.
Configuration
- Période : la requête utilise les valeurs fictives « {StartDate} » et « {EndDate} » pour filtrer les commandes clients selon leur date de création (VBAK.ERDAT). Une période d’analyse de 3 à 6 mois constitue généralement un bon compromis pour obtenir un échantillon représentatif sans surcharger la base de données.
- Filtre sur l’organisation commerciale : utilisez la valeur fictive « {SalesOrgs} » pour limiter l’extraction à certaines organisations commerciales, par exemple « 1000 » et « 2000 ». Ce filtre est essentiel pour cibler l’analyse et améliorer les performances de la requête.
- Filtre sur le type de document : utilisez la valeur fictive « {DocTypes} » pour sélectionner certains types de commandes clients, par exemple « OR » pour une commande standard. Vous pourrez ainsi exclure du flux principal les documents non pertinents, comme les livraisons gratuites ou les retours.
- Identifiant du système source : la valeur fictive codée en dur « {SourceSystemName} » sert à associer chaque enregistrement à son système d’origine. Elle doit être remplacée par un nom explicite correspondant à votre instance SAP ECC, par exemple SAP_ECC_PRD.
- Compatibilité de la base de données : la fonction utilisée pour combiner les champs de date et d’heure, [Your DB-specific timestamp function], est une valeur fictive. Vous devez la remplacer par la fonction adaptée à votre base de données, par exemple TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UZEIT), 'YYYYMMDDHH24MISS') pour SAP HANA ou CAST(CDHDR.UDATE AS DATETIME) + CAST(CDHDR.UZEIT AS DATETIME) pour SQL Server.
- Prérequis : cette méthode nécessite des identifiants directs donnant un accès en lecture seule à la base de données. L’utilisateur de la base doit être autorisé à accéder à toutes les tables référencées dans la requête, notamment VBAK, VBAP, VBFA, CDHDR, CDPOS, LIKP, VBRK et BSAD.
a Exemple de requête sql
WITH SalesOrders AS (
SELECT VBELN
FROM VBAK
WHERE ERDAT BETWEEN '{StartDate}' AND '{EndDate}' -- Filter by creation date
AND VKORG IN ('{SalesOrgs}') -- Filter by Sales Organization(s)
AND AUART IN ('{DocTypes}') -- Filter by Sales Document Type(s)
)
-- 1. Sales Order Created
SELECT
vbak.VBELN AS "SalesOrder",
'Sales Order Created' AS "Activity",
[Your DB-specific timestamp function](vbak.ERDAT, vbak.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbak.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBAK vbak
JOIN SalesOrders so ON vbak.VBELN = so.VBELN
UNION ALL
-- 2. Sales Order Changed
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Sales Order Changed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG' AND cdhdr.TCODE IN ('VA02')
UNION ALL
-- 3. Credit Check Performed (Release)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Credit Check Performed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'CMGST'
AND cdpos.VALUE_NEW = 'B' -- Credit status 'Released'
UNION ALL
-- 4. Order Confirmed (Overall status not blocked)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Order Confirmed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'GBSTK'
AND cdpos.VALUE_OLD <> 'A' AND cdpos.VALUE_NEW = 'A' -- Status changes to 'Not yet processed'
UNION ALL
-- 5. Delivery Block Set
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Delivery Block Set' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
cdpos.VALUE_NEW AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAK'
AND cdpos.FNAME = 'LIFSK'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''
UNION ALL
-- 6. Delivery Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Delivery Created' AS "Activity",
[Your DB-specific timestamp function](likp.ERDAT, likp.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
UNION ALL
-- 7. Picking Completed
SELECT
vbfa.VBELV AS "SalesOrder",
'Picking Completed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN CDHDR cdhdr ON vbfa.VBELN = cdhdr.OBJECTID
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
AND cdhdr.OBJECTCLASS = 'LIEFERUNG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'PKSTK'
AND cdpos.VALUE_NEW = 'C'
UNION ALL
-- 8. Goods Issued
SELECT
vbfa_gi.VBELV AS "SalesOrder",
'Goods Issued' AS "Activity",
[Your DB-specific timestamp function](mkpf.BUDAT, mkpf.CPUTM) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
mkpf.USNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa_gi
JOIN SalesOrders so ON vbfa_gi.VBELV = so.VBELN
JOIN MKPF mkpf ON vbfa_gi.VBELN = mkpf.XBLNR -- XBLNR is Reference Document Number
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa_gi.VBTYP_V = 'J' AND vbfa_gi.VBTYP_N = 'R'
UNION ALL
-- 9. Proof Of Delivery Confirmed
SELECT
vbfa.VBELV AS "SalesOrder",
'Proof Of Delivery Confirmed' AS "Activity",
[Your DB-specific timestamp function](likp.PODAT, '000000') AS "StartTime", -- PODAT is only a date
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.AENAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J' AND likp.PODAT IS NOT NULL AND likp.PODAT <> '00000000'
UNION ALL
-- 10. Invoice Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Created' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
UNION ALL
-- 11. Invoice Cancelled
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Cancelled' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'M' AND vbfa.VBTYP_N = 'N'
UNION ALL
-- 12. Payment Received
SELECT
vbfa.VBELV AS "SalesOrder",
'Payment Received' AS "Activity",
[Your DB-specific timestamp function](bsad.AUGDT, '000000') AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
NULL AS "User", -- Clearing user not readily available here
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN BSAD bsad ON vbrk.VBELN = bsad.VBLNR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
AND bsad.AUGDT IS NOT NULL AND bsad.AUGDT <> '00000000'
UNION ALL
-- 13. Order Item Closed
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Item Closed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
vbap.ABGRU AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUP'
AND cdpos.FNAME = 'GBSTA'
AND cdpos.VALUE_NEW = 'C' -- Item is completely processed
UNION ALL
-- 14. Order Cancelled
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Cancelled' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
cdpos.VALUE_NEW AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAP'
AND cdpos.FNAME = 'ABGRU'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''; Prêt à commencer ?
Tirez le meilleur parti de votre processus Order to Cash - Sales Order Processing grâce à ce modèle de données. Commencez dès aujourd’hui à améliorer la performance et à accélérer les encaissements.
Optimisez dès aujourd’hui votre processus Order to Cash, traitement des commandes clients
Éliminez les goulots d’étranglement, réduisez le temps de cycle de 30 % et améliorez rapidement votre flux de trésorerie.
Aucune carte bancaire requise. La configuration ne prend que quelques minutes.