Votre modèle de données pour le processus de commande à encaissement, traitement des commandes clients
Votre modèle de données pour le processus de commande à encaissement, traitement des commandes clients
- Attributs recommandés à recueillir
- Activités clés à suivre
- Conseils d’extraction pour SAP ECC
Attributs du processus de commande à encaissement, traitement des commandes clients
| Nom | Description | ||
|---|---|---|---|
| Commande client SalesOrder | Identifiant unique d’un document de commande client, utilisé comme cas principal pour suivre l’ensemble du processus de la commande à l’encaissement. | ||
| Description La commande client est le document central du processus de vente. Elle représente la demande de biens ou de services d’un client et contient toutes les informations nécessaires à son traitement, du début à la fin. En Process Mining, cet attribut sert d’ID de cas. Chaque numéro de commande client unique correspond à une instance complète du processus. L’analyse par commande client permet d’en suivre tout le cycle de vie, de mesurer les temps de cycle et de repérer les variations propres à chaque commande. Pourquoi est-ce important ? C’est la clé qui relie toutes les activités et tous les événements associés, pour permettre une analyse complète du parcours de chaque commande client. Où trouver ces données Se trouve dans la table des données d’en-tête du document commercial (VBAK), dans le champ VBELN. Exemples 900001234590000123469000012347 | |||
| Activité Activity | Nom d’une étape métier ou d’un événement précis survenu dans le processus de commande client. | ||
| Description Cet attribut décrit une étape du processus de la commande à l’encaissement, par exemple « Commande client créée », « Livraison créée » ou « Paiement reçu ». Ces activités servent à reconstituer le déroulement du processus pour chaque commande client. L’analyse de leur séquence et de leur durée est au cœur du Process Mining. Elle permet de visualiser le processus, de repérer les goulots d’étranglement, de découvrir les variantes et de vérifier la conformité à un modèle de référence. 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 enregistrés dans le système. Pourquoi est-ce important ? Les activités constituent la base de la représentation du processus. Elles permettent d’en visualiser et d’en analyser le déroulement, les écarts et les goulots d’étranglement. Où trouver ces données Cet attribut est dérivé, généralement 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 modification (tables CDHDR et CDPOS) à des noms d’activité compréhensibles. Exemples Commande client crééeLivraison crééeSortie de marchandises effectuéeFacture 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 indique la date et l’heure de la dernière extraction ou mise à jour des données pour un événement ou un cas donné. Il permet de connaître leur degré d’actualité. Dans les Dashboards et les rapports, cette information aide les utilisateurs à évaluer l’actualité des analyses. Elle permet de vérifier si celles-ci reflètent l’état le plus récent des opérations ou reposent sur des données plus anciennes, et de définir ainsi les attentes concernant leur fraîcheur. Pourquoi est-ce important ? Les utilisateurs savent ainsi si les données sont à jour, un point essentiel pour prendre des décisions éclairées au bon moment à partir de l’analyse Process Mining. Où trouver ces données Cet attribut de métadonnées est 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, indique la date et l’heure précises auxquelles une activité a eu lieu. Elle permet, par exemple, de savoir quand une commande client a été créée, quand les marchandises sont sorties ou quand une facture a été enregistrée. Cet horodatage est indispensable à toute analyse temporelle en Process Mining. Il sert à calculer les temps de cycle entre les activités, à mesurer la durée totale d’un cas et à repérer les retards ou les goulots d’étranglement. Des horodatages exacts sont essentiels aux Dashboards d’analyse des performances, notamment pour suivre les livraisons dans les délais ou les délais d’exécution. Pourquoi est-ce important ? Cet attribut est essentiel au calcul des indicateurs de performance, notamment des temps de cycle et des durées, qui permettent de repérer les goulots d’étranglement. Où trouver ces données Cet attribut composite est généralement dérivé de la combinaison d’un champ de date (par exemple ERDAT) et d’un champ d’heure (par exemple ERZET) provenant de différentes tables SAP, comme 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 dont les données ont été extraites. | ||
| Description Cet attribut indique le système d’origine, par exemple le nom d’une instance SAP ECC ou le numéro d’un mandant. Il apporte un contexte aux données, notamment lorsque l’environnement comprend plusieurs systèmes de production ou des données issues de systèmes existants. L’analyse permet de filtrer ou de segmenter les données selon leur origine. Cette possibilité est particulièrement utile pour comparer les processus entre différents systèmes ou lors d’une migration, afin de vérifier l’intégrité et la cohérence des données. Pourquoi est-ce important ? Cet attribut apporte un contexte essentiel, notamment dans les environnements comportant plusieurs systèmes. Il permet de comparer les processus et de retracer clairement l’origine des données. Où trouver ces données Cette valeur est généralement ajoutée lors de l’extraction des données. Il s’agit souvent d’une valeur statique correspondant à l’identifiant du système SAP (SAPSID) ou du 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 au niveau de l’en-tête ou du poste d’une commande client pour suspendre temporairement le processus avant l’étape de livraison. Un utilisateur peut le définir manuellement, ou le système peut l’appliquer automatiquement, par exemple en cas de dépassement de la limite de crédit ou de données incomplètes. Cet attribut est essentiel au Dashboard « Analyse des blocages et des reprises des commandes client ». L’analyse de la fréquence, de la durée et des motifs de blocage permet de repérer les principaux goulots d’étranglement du processus d’exécution. Réduire ces blocages contribue à améliorer les livraisons dans les délais et le temps de cycle global. Pourquoi est-ce important ? Cet attribut met directement en évidence les goulots d’étranglement du processus d’exécution. Analyser les raisons et la fréquence des blocages aide à améliorer l’efficacité du processus. Où trouver ces données Se trouve dans la table des données d’en-tête du document commercial (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 correspond à la valeur monétaire de la commande client. Il s’agit d’un indicateur financier associé à chaque instance du processus. Cet attribut est indispensable à l’analyse des processus selon leur valeur. Il permet de hiérarchiser les initiatives d’amélioration en donnant la priorité aux commandes de valeur élevée. Les analystes peuvent mettre en relation les problèmes de processus, comme les retards ou les reprises, et leurs conséquences financières, afin d’étayer l’analyse de rentabilité d’un changement. Ils peuvent, par exemple, comparer l’efficacité du traitement des commandes de valeur élevée et de valeur faible. Pourquoi est-ce important ? Permet d’analyser les processus selon leur valeur et de concentrer les efforts d’amélioration sur les commandes ayant le plus fort impact financier pour l’entreprise. Où trouver ces données Se trouve dans la table des données d’en-tête du document commercial (VBAK), dans le champ NETWR. Exemples 1500.0012550.75850.50 | |||
| Motif de rejet RejectionReason | Code indiquant pourquoi 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, d’une indisponibilité du produit ou d’autres raisons commerciales. Cet attribut est essentiel au Dashboard « Tendances des annulations de commandes client ». L’analyse des motifs de rejet les plus fréquents aide l’entreprise à repérer les causes profondes des ventes perdues. Elle peut ensuite orienter les améliorations de la gestion des stocks, de la stratégie tarifaire ou de la communication avec les clients, afin de réduire le taux d’annulation des commandes. Pourquoi est-ce important ? Explique les raisons des annulations de commandes et permet d’en rechercher les causes profondes pour réduire les ventes perdues et améliorer la précision des prévisions. Où trouver ces données Se trouve dans la table des données de poste du document commercial (VBAP), dans le champ ABGRU. Exemples 0215Z5 | |||
| Numéro d’article MaterialNumber | Identifiant unique d’un produit ou d’un service vendu. | ||
| Description Le numéro d’article identifie le produit ou le service d’un poste de commande client. Une commande pouvant contenir plusieurs articles, cet attribut est généralement analysé au niveau du poste. L’analyse par numéro d’article permet de repérer les problèmes propres à certains produits. Elle peut révéler que 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. Ces informations aident les équipes de la chaîne d’approvisionnement et de gestion des produits à adapter le processus aux différentes gammes. Pourquoi est-ce important ? Permet d’analyser les processus par produit et de repérer ceux qui sont associés à des inefficacités, comme des retards, des blocages ou des reprises. Où trouver ces données Se trouve dans la table des données de poste du document commercial (VBAP), dans le champ MATNR. Exemples FG-1001-ARAW-205BSERV-INSTALL | |||
| Numéro de client CustomerNumber | Identifiant unique du client ayant passé la commande. | ||
| Description Cet attribut désigne le « donneur d’ordre », c’est-à-dire le compte client principal associé à la commande. 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 pour comprendre les comportements et les performances propres à chaque client. Elle aide à répondre à des questions telles que : quels clients ont les temps de cycle les plus longs, les taux de reprises les plus élevés ou les changements de commande les plus fréquents ? Ces informations sont importantes pour améliorer la gestion de la relation client et la qualité de service. Pourquoi est-ce important ? Permet une analyse centrée sur les clients, afin de repérer les problèmes de processus qui les touchent et de mesurer les performances propres à chacun. Où trouver ces données Se trouve dans la table des données d’en-tête du document commercial (VBAK), dans le champ KUNNR. Exemples 100234100567200112 | |||
| Organisation commerciale SalesOrganization | Unité organisationnelle responsable de la vente de produits ou de services. | ||
| Description Dans SAP, l’organisation commerciale est une entité qui structure l’entreprise en fonction de ses besoins de vente. Elle est chargée de négocier les conditions de vente et de distribuer les biens et les services. En Process Mining, cet attribut constitue un axe d’analyse important. Il permet de comparer les performances, l’efficacité et la conformité des processus entre différentes unités commerciales, régions ou divisions. Vous pouvez ainsi repérer les pratiques efficaces dans les unités les plus performantes et les domaines à améliorer dans les autres. Pourquoi est-ce important ? Permet de comparer l’efficacité et la conformité des processus entre différentes unités opérationnelles ou régions. Où trouver ces données Se trouve dans la table des données d’en-tête du document commercial (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 effectué l’activité. | ||
| Description Cet attribut indique l’identifiant de l’utilisateur SAP responsable d’un événement donné du processus. Il permet, par exemple, d’identifier l’employé commercial qui a créé la commande ou le personnel d’entrepôt qui a enregistré la sortie des marchandises. L’analyse par utilisateur aide à comprendre la répartition de la charge de travail, à repérer les besoins de formation et à détecter les différences dans la manière dont les utilisateurs effectuent une même tâche. Elle est essentielle aux Dashboards consacrés à la performance des ressources, à la conformité et au repérage des interventions manuelles. Pourquoi est-ce important ? Cet attribut donne de la visibilité sur la performance des ressources et la charge de travail. Il aide à repérer les écarts propres à certains utilisateurs et contribue aux analyses de conformité et d’automatisation. Où trouver ces données Figure 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 les modalités générales d’expédition des marchandises au client. | ||
| Description Les conditions d’expédition déterminent le mode d’expédition d’une commande, par exemple « Standard », « Express » ou « Retrait ». Elles sont convenues avec le client et influent sur la planification logistique. Cet attribut sert à 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 entraînent davantage de retards ou des temps de cycle plus longs. Ces données aident à optimiser la logistique et à mieux gérer les attentes des clients concernant les délais de livraison. Pourquoi est-ce 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ù trouver ces données Se trouve dans la table des données d’en-tête du document commercial (VBAK), dans le champ VSBED. Exemples 011020 | |||
| Date de livraison confirmée ConfirmedDeliveryDate | Date à laquelle la livraison des biens 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 les performances de livraison. Cet attribut est à la base du Dashboard « Performance des livraisons dans les délais » et de l’indicateur de taux de livraison dans les délais. En comparant la date de livraison confirmée à la date réelle de sortie des marchandises, l’analyse détermine si la commande a été livrée à temps, en avance ou en retard. C’est un indicateur majeur de la fiabilité de la chaîne d’approvisionnement et de la satisfaction client. Pourquoi est-ce important ? Cette date sert de référence pour mesurer les performances de livraison dans les délais, un indicateur important de la satisfaction client et de l’efficacité de la chaîne d’approvisionnement. Où trouver ces données Se trouve dans la table des échéances du document commercial (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 des marchandises à la date de livraison confirmée d’une commande client. Si les marchandises sont sorties à la date confirmée ou avant, 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 de l’indicateur de taux de livraison dans les délais. Il facilite l’agrégation et la visualisation des performances, sans avoir à comparer les dates à la volée dans chaque analyse ou graphique. Vous disposez ainsi d’une mesure claire et immédiate de la fiabilité des livraisons. Pourquoi est-ce important ? Fournit une mesure claire et simple des performances de livraison et facilite le calcul du taux global de livraison dans les délais. Où trouver ces données Cet attribut est calculé en comparant l’horodatage de l’activité « Sortie de marchandises enregistrée » à la valeur de l’attribut « ConfirmedDeliveryDate ». Exemples truefalse | |||
| Reprises IsRework | Indicateur booléen signalant 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é repère les instances du processus ayant fait l’objet de reprises, par exemple après une ou plusieurs activités « Commande client modifiée ». Les critères définissant une reprise, comme une modification du prix, de la quantité ou de la date de livraison, sont établis lors de la configuration du projet. Cet attribut est essentiel au Dashboard « Reprises et fréquence des modifications des commandes client » et à l’indicateur de taux de reprises des commandes client. Il simplifie l’analyse en permettant de comparer directement les commandes traitées sans interruption avec celles qui ont nécessité des modifications manuelles. Vous pouvez ainsi mesurer l’effet des reprises sur les temps de cycle et les coûts. Pourquoi est-ce important ? Mesure directement la fréquence des reprises et permet d’en analyser les causes ainsi que les effets sur l’efficacité globale du processus et le temps de cycle. Où trouver ces données Cet attribut calculé est dérivé 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 dans les tables CDHDR/CDPOS. Exemples truefalse | |||
| Statut du contrôle de solvabilité CreditCheckStatus | Indique le statut du contrôle de solvabilité du document commercial. | ||
| Description Cet attribut indique le résultat du contrôle de solvabilité, manuel ou automatisé, effectué sur une commande client. Les statuts courants sont « Approuvé », « Rejeté » ou « Bloqué ». Cet attribut est essentiel au Dashboard « Analyse du temps de traitement du contrôle de solvabilité ». Les retards ou les blocages à cette étape peuvent allonger considérablement le temps de cycle global d’exécution de la commande. L’analyse de ce statut aide à évaluer l’efficacité de la gestion du crédit et son effet sur le rythme des ventes. Pourquoi est-ce important ? Ce statut a un effet direct sur la vitesse de traitement des commandes. Son analyse permet de repérer les goulots d’étranglement de la gestion du crédit qui retardent leur exécution. Où trouver ces données Se trouve dans la table des statuts d’en-tête du document commercial (VBUK) ou directement dans VBAK, dans le champ de statut de crédit (par exemple CMGST). Exemples ABD | |||
Activités du processus de commande à encaissement, traitement des commandes clients
| Activité | Description | ||
|---|---|---|---|
| Commande client créée | Indique la création d’un nouveau document de commande client. Cet événement explicite est enregistré lorsqu’un utilisateur sauvegarde une nouvelle commande, généralement au moyen de la transaction VA01 dans SAP. | ||
| Pourquoi est-ce important ? Il s’agit de l’événement de début principal du processus de la commande à l’encaissement. L’analyse de son horodatage est essentielle pour mesurer le temps de cycle global et le rythme de réception des commandes. Où trouver ces données Enregistré dans la table VBAK (données d’en-tête du document de vente) à l’aide de la date de création (ERDAT) et de l’heure (ERZET). Le code de transaction est stocké dans VBAK-TCODE. Données à recueillir É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 qu’elle est confirmée pour exécution. Elle est généralement déduite du fait que la commande n’est plus bloquée et que des quantités sont confirmées dans ses lignes d’échéancier. | ||
| Pourquoi est-ce important ? Cette étape importante marque le passage de la saisie de la commande à son exécution. Elle sert de point de départ pour mesurer les délais d’exécution et la performance des livraisons dans les délais. Où trouver ces données 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 livraison (par exemple, lorsque VBUK-LIFSK est vide). Données à recueillir Déduit de la confirmation de la ligne 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 | Indique la création de la facture client ou du document de facturation. Cet événement explicite génère un nouveau document dans le système et marque le début de la phase de paiement du processus. | ||
| Pourquoi est-ce important ? Cette étape importante marque le début du « temps de cycle entre la facturation et le paiement ». Les retards de facturation ont un effet direct sur la trésorerie. Où trouver ces données Enregistré dans la table VBRK (document de facturation : données d’en-tête) à partir de sa date de création (ERDAT). Le lien avec la commande client ou la livraison figure dans la table VBFA. Données à recueillir Événement basé 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 imputé à la facture, ce qui solde la créance ouverte. Il s’agit d’un événement comptable, déduit du lettrage d’un document financier. | ||
| Pourquoi est-ce important ? Cette étape finale concrétise l’encaissement de la vente. Elle marque la fin de la période mesurée pour le « temps de cycle entre la facturation et le paiement » et le « temps de cycle d’exécution de la commande client ». Où trouver ces données Déduit des informations de lettrage figurant 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. Données à recueillir Déduit du renseignement de la date de lettrage (AUGDT) dans la table BSEG pour le poste 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 : la livraison et la facturation sont terminées, et le poste est considéré comme achevé. La clôture est déduite du statut global du poste. | ||
| Pourquoi est-ce important ? Marque la fin normale du processus. L’analyse des dates de clôture permet de comprendre la durée totale du processus et de repérer les commandes qui restent ouvertes inutilement. Où trouver ces données Déduit du champ de statut global du poste dans la table VBUP (document commercial : statut du poste). Lorsque VBUP-GBSTA est égal à « C » (traitement terminé), le poste est clôturé. Données à recueillir Déduit du passage du statut du poste (VBUP-GBSTA) à « C » (traitement terminé). Type d’événement inferred | |||
| Sortie de marchandises effectuée | Cet événement important marque le transfert de propriété des marchandises et leur sortie officielle de l’entrepôt. Cette comptabilisation financière explicite crée un document article et met à jour les stocks. | ||
| Pourquoi est-ce important ? Il s’agit de l’événement d’expédition et d’une étape clé pour mesurer les livraisons dans les délais et les délais d’exécution. Il déclenche des mises à jour financières et marque un point de non-retour dans l’exécution physique de la commande. Où trouver ces données 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. Données à recueillir 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 | Indique qu’un blocage de livraison a été appliqué à la commande client, empêchant 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 est-ce important ? Cette activité est directement liée au KPI « Taux de blocage des commandes clients ». Comprendre pourquoi et à quelle fréquence des blocages sont définis permet de repérer les causes des retards d’exécution. Où trouver ces données Peut être repéré dans les journaux de modifications (CDHDR/CDPOS) pour le champ VBAK-LIFSK. Il peut aussi être déduit lorsque le champ VBAK-LIFSK est renseigné. Données à recueillir Événement issu des documents de modification du 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. En général, cet événement est enregistré lorsqu’un « motif de rejet » est attribué à tous les postes concernés de la commande. | ||
| Pourquoi est-ce important ? Cette fin de processus signale un échec important et contribue directement au calcul de l’indicateur « taux d’annulation des commandes ». Comprendre quand et pourquoi les commandes sont annulées permet de repérer les problèmes liés au processus de vente. Où trouver ces données Déduit du renseignement du champ VBAP-ABGRU (motif de rejet) pour tous les postes actifs d’une commande client. La date de modification figure dans CDHDR/CDPOS. Données à recueillir Déduit du renseignement du champ « motif de rejet » (VBAP-ABGRU) pour tous les postes. Type d’événement inferred | |||
| Commande client modifiée | Indique la modification d’une commande client 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 comme la quantité, le prix ou les dates sont modifiés. | ||
| Pourquoi est-ce important ? Le suivi des modifications permet de repérer les reprises, l’instabilité du processus et les problèmes de qualité des données. Des changements fréquents peuvent révéler des problèmes lors de la saisie initiale de la commande et entraîner des retards. Où trouver ces données 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. Données à recueillir Événement issu des tables des documents de modification (CDHDR, CDPOS) pour les objets de document de vente. Type d’événement explicit | |||
| Confirmation de la preuve de livraison | Cette activité indique 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 est-ce important ? Cet événement fournit la date réelle de livraison, indispensable pour mesurer avec précision le « taux de livraison dans les délais » par rapport à la date promise. Où trouver ces données Déduit du statut de preuve de livraison (VBUK-PODAT) défini sur « C » (confirmé). La date de confirmation est enregistrée dans VLPOD-PODAT. Cette fonctionnalité n’est pas toujours mise en œuvre. Données à recueillir Déduit de la mise à jour du statut POD de la livraison (VBUK-PODAT) ou d’une entrée dans la table VLPOD. Type d’événement inferred | |||
| Contrôle de solvabilité effectué | Indique la fin du contrôle de solvabilité, automatique ou manuel, du client associé à la commande. Cet événement est généralement déduit d’un changement du statut global de crédit du document. | ||
| Pourquoi est-ce important ? Le contrôle de solvabilité constitue souvent un goulot d’étranglement important. Mesurer le temps nécessaire à cette étape est essentiel pour analyser le temps de traitement des contrôles de solvabilité et accélérer le traitement des commandes. Où trouver ces données Déduit des champs de statut de crédit de la table VBUK (statut d’en-tête du document de vente). Le passage de VBUK-CMGST de bloqué à libéré marque cette activité. Données à recueillir Déduit des changements apportés au champ de statut global de crédit (VBUK-CMGST). Type d’événement inferred | |||
| Facture annulée | Indique l’annulation d’un document de facturation créé précédemment. Cette transaction explicite crée un nouveau document d’annulation qui vient compenser le document d’origine. | ||
| Pourquoi est-ce important ? Le suivi des annulations de factures permet de repérer les problèmes de tarification, les écarts de livraison ou les erreurs de données. Il contribue au calcul de l’indicateur « taux d’écart de facturation ». Où trouver ces données É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. Données à recueillir Création d’un document d’annulation dans VBRK, avec 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 demande à l’entrepôt de commencer le prélèvement et l’expédition des marchandises. Il s’agit d’un événement explicite enregistré dans le flux documentaire. | ||
| Pourquoi est-ce important ? C’est la première étape de l’exécution physique de la commande. 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ù trouver ces données Création d’un enregistrement dans la table LIKP (données d’en-tête du document de livraison SD). Le lien avec la commande client est conservé dans la table de flux documentaire VBFA. Données à recueillir Événement fondé sur l’horodatage de création dans la table LIKP, avec un lien établi par la table VBFA. Type d’événement explicit | |||
| Prélèvement terminé | Indique que tous les articles de la livraison ont été prélevés physiquement dans l’entrepôt. Si Warehouse Management (WM) est utilisé, cet événement peut être déduit du statut de l’ordre de transfert. | ||
| Pourquoi est-ce important ? L’analyse du temps de prélèvement aide à optimiser les opérations de l’entrepôt. Les retards à cette étape affectent directement le calendrier d’expédition et le cycle d’exécution de la commande. Où trouver ces données Déduit du changement du statut de prélèvement du poste de livraison dans le champ LIPS-KOSTA, qui passe à ’C’ (prélèvement complet). Si WM est actif, l’événement peut être déduit de la confirmation de l’ordre de transfert (tables LTAK/LTAP). Données à recueillir Déduit d’un changement du statut de prélèvement (LIPS-KOSTA) ou de la confirmation de l’ordre de transfert WM. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Développer le programme : à l’aide de la transaction SE38 ou SE80, créez un programme ABAP exécutable. Il contiendra toute la logique d’extraction.
- Définir l’écran de sélection : créez dans le programme un écran permettant de 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 stocker les données provenant des différentes tables SAP (par exemple VBAK, VBAP, VBFA, CDHDR, CDPOS, VBRK, BSAD). Définissez également la structure de sortie du journal d’événements, en veillant à ce qu’elle contienne les attributs requis.
- Sélectionner les commandes clients de base : rédigez l’instruction SELECT initiale pour récupérer les en-têtes (VBAK) et les postes (VBAP) des commandes clients selon les critères saisis dans l’écran de sélection. Vous obtenez ainsi les dossiers à analyser.
- Extraire l’événement de création : parcourez les enregistrements VBAK sélectionnés. Pour chacun, renseignez la structure du journal d’événements avec l’activité « Commande client créée », en utilisant VBAK-ERDAT et VBAK-ERZET comme StartTime.
- Extraire les événements du journal de modifications : sélectionnez dans CDHDR et CDPOS les enregistrements dont OBJECTCLAS vaut « VERKBELEG » pour les commandes clients sélectionnées. Parcourez les résultats afin de repérer les modifications de champs. Par exemple, une modification de VBAK-LIFSK indique « Blocage de livraison défini », tandis qu’une modification de VBUK-CMGST indique « Contrôle de crédit effectué ». Toute autre modification pertinente peut être consignée sous « Commande client modifiée ».
- Extraire les données du flux de documents : pour les commandes sélectionnées, interrogez la table du flux des documents (VBFA). Elle relie les commandes clients aux documents ultérieurs, comme les livraisons, les mouvements de marchandises et les factures. Sélectionnez tous les documents associés pour les traiter ensuite.
- Extraire les événements de livraison et d’exécution : à partir des numéros de livraison de VBFA, interrogez LIKP et LIPS pour repérer les événements « Livraison créée ». Interrogez MKPF et MSEG pour les documents de sortie de marchandises (type de mouvement « 601 ») afin de consigner l’événement « Marchandises sorties ». 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 le moment où la préparation est terminée. Vérifiez le statut d’en-tête de livraison VBUK-PODAT pour repérer la confirmation de preuve de livraison.
- Extraire les événements de facturation et de paiement : à partir des numéros de documents de facturation de VBFA, interrogez VBRK et VBRP pour repérer les événements « Facture créée » et « Facture annulée » (lorsque VBRK-FKSTO = « X »). Pour repérer l’événement « Paiement reçu », reliez la facture de VBRK au document comptable dans BKPF, puis recherchez le document de compensation et sa date dans BSAD.
- Déduire les événements à partir des statuts : utilisez les tables de statut VBUP (statut des postes) et VBUK (statut des en-têtes) pour déduire les événements métier. Par exemple, un poste est considéré comme « Poste de commande clôturé » lorsque VBUP-GBSTA vaut « C ». Une commande est considérée comme « Commande annulée » lorsque le motif de rejet (VBAP-ABGRU) est renseigné pour tous les postes concernés.
- Consolider et mettre en forme : regroupez tous les événements relevés dans une seule table interne finale. Vérifiez que tous les attributs (SalesOrder, Activity, StartTime, User, etc.) sont correctement renseignés pour chaque événement. Ajoutez les horodatages SourceSystem et LastDataUpdate.
- Générer le fichier de sortie : utilisez le module 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 de l’utilisateur. Enregistrez le fichier en UTF-8.
Configuration
- Prérequis : autorisations de développement ABAP (par exemple, 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 sont les suivants :
- Période : une période obligatoire pour la date de création des commandes clients (VBAK-ERDAT). Commencez par une période récente de trois à six mois afin de conserver un volume de données gérable.
- Organisation commerciale : filtrez selon VBAK-VKORG pour limiter l’analyse à certaines unités opérationnelles.
- Type de document de vente : filtrez selon VBAK-AUART pour inclure uniquement les types de commande pertinents, comme les commandes standard, et exclure les autres, comme les devis et les retours.
- Performances : l’extraction des journaux de modifications (CDHDR, CDPOS) et du flux des documents (VBFA) peut être très lente lorsque les volumes sont importants. Optimisez le programme en utilisant des champs indexés dans les clauses WHERE. Pour les extractions de très grande ampleur, planifiez son exécution 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é de gestion des documents de modification de SAP. 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 dans la transaction SCDO pour l’objet VERKBELEG.
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 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.
- Récupérer 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 connectez-vous à l’instance 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 correspondant à votre analyse.
- Exécuter la requête : lancez le script SQL configuré. Selon la période choisie 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 (SalesOrder, Activity, StartTime, etc.) et des lignes correspondant à différentes activités.
- Exporter les données : utilisez la fonction d’exportation de votre client de base de données pour enregistrer les résultats dans un fichier CSV. Choisissez un nom explicite, par exemple SAP_O2C_Event_Log.csv.
- Mettre le fichier au format requis par 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, StartTime). Assurez-vous que StartTime et LastDataUpdate utilisent un format de date et d’heure cohérent, pris en charge par ProcessMind, tel que YYYY-MM-DD HH:MI:SS.
- Importer les données dans ProcessMind : importez le fichier CSV final mis en forme 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 trois à six mois permet généralement d’obtenir un échantillon représentatif sans solliciter excessivement la base de données.
- Filtre sur l’organisation commerciale : utilisez la valeur « {SalesOrgs} » pour limiter l’extraction à certaines organisations commerciales, par exemple « 1000 » et « 2000 ». Ce filtre permet de cibler l’analyse et d’améliorer les performances de la requête.
- Filtre sur le type de document : utilisez la valeur « {DocTypes} » pour sélectionner certains types de commandes clients, par exemple « OR » pour une commande standard. Vous pouvez ainsi exclure du flux de processus 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 à indiquer le système d’origine de chaque enregistrement. Remplacez-la par un nom explicite pour votre instance SAP ECC, par exemple SAP_ECC_PRD.
- Compatibilité avec la base de données : la fonction de combinaison des champs de date et d’heure, [Your DB-specific timestamp function], est une valeur fictive. Remplacez-la 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 donnant un accès direct 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.
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 ce modèle de données pour votre processus de commande à encaissement, traitement des commandes clients. Commencez dès aujourd’hui à améliorer l’efficacité et à accélérer les encaissements.
Optimisez dès aujourd’hui le traitement des commandes, de la commande à l’encaissement
Éliminez les goulots d’étranglement, réduisez le temps de cycle de 30 % et accélérez les encaissements.
Aucune carte bancaire requise. Configuration en quelques minutes.