Votre modèle de données pour le traitement des retours et remboursements
Votre modèle de données pour le traitement des retours et remboursements
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction
Attributs de traitement des retours et remboursements
| Nom | Description | ||
|---|---|---|---|
| Heure de l'événement EventTime | L'horodatage précis indiquant le moment où une activité spécifique s'est produite. | ||
| Description L'heure de l'événement (Event Time) capture la date et l'heure auxquelles un événement métier a été enregistré dans le système. Cet horodatage est crucial pour ordonner les activités chronologiquement et pour toute analyse temporelle. Dans le Process Mining, cet attribut est utilisé pour calculer les temps de cycle entre les activités, identifier la durée de chaque étape et analyser la performance du processus au fil du temps. Il constitue la base pour découvrir les goulots d'étranglement, surveiller le respect des SLA et comprendre la dynamique temporelle du processus de retours. Pourquoi c'est important Cet horodatage est essentiel pour ordonner les événements, calculer toutes les durées et les temps de cycle, et identifier les retards de processus. Où obtenir Généralement tiré des champs de date et d'heure associés à la création de documents ou aux changements de statut, tels que ERDAT (Date de création) et ERZET (Heure de création) dans des tables comme VBAK, LIKP et BKPF, ou la date de comptabilisation (BUDAT) dans les documents comptables. Exemples 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| ID du dossier de retour ReturnCaseId | L'identifiant unique pour un processus de retour client unique, reliant toutes les activités connexes de l'initiation à la clôture. | ||
| Description L'ID du dossier de retour sert d'identifiant principal regroupant tous les événements et activités appartenant à une même instance de retour. Chaque demande de retour client se voit attribuer un ID unique, permettant un suivi de bout en bout de l'ensemble du processus. En Process Mining, cet attribut est fondamental pour la reconstruction du flux de processus. Il permet l'analyse des durées de dossier, des variantes de processus et des goulots d'étranglement en reliant des événements disparates comme 'Demande de retour initiée', 'Marchandises reçues' et 'Remboursement traité' dans une chronologie cohérente pour chaque retour spécifique. Pourquoi c'est important C'est la clé essentielle pour suivre un retour du début à la fin, permettant toutes les analyses au niveau du dossier, y compris le temps de cycle et la découverte des variantes de processus. Où obtenir C'est généralement le numéro du document de vente (VBELN) de la table d'en-tête de commande de retour VBAK, où la catégorie de document (VBTYP) indique un retour. Exemples 600001896000019060000191 | |||
| Nom de l'activité ActivityName | Le nom d'une activité commerciale ou d'un événement spécifique survenu au sein du processus de retour et de remboursement. | ||
| Description Cet attribut décrit une seule étape ou un jalon du cycle de vie des retours. Les activités représentent le travail effectué, telles que « Commande de retour approuvée » ou « Inspection de l'article terminée ». Elles sont dérivées des changements de statut, de la création de documents ou d'actions utilisateur spécifiques enregistrées dans SAP S/4HANA. L'analyse de la séquence et de la fréquence de ces activités est au cœur du Process Mining. Elle aide à visualiser la carte des processus, à identifier les chemins de processus courants et rares, et à localiser les activités fréquemment répétées, indiquant un retrabalho ou des inefficacités. Pourquoi c'est important Les activités constituent l'épine dorsale de la carte des processus, permettant la visualisation et l'analyse du flux de processus, des goulots d'étranglement et des variations. Où obtenir Les noms d'activité sont généralement dérivés d'une combinaison de données, telles que les changements de statut de document dans des tables comme VBUK/VBUP, les événements de création dans des tables d'en-tête comme VBAK (documents de vente) et BKPF (documents comptables), et les statuts de mouvement de marchandises dans MSEG. Exemples Demande de retour initiéeMarchandises reçues à l'entrepôtAvoir émisRemboursement traité | |||
| Dernière mise à jour des données LastDataUpdateTimestamp | Le timestamp indiquant la dernière fois que les données de cet événement ont été rafraîchies ou extraites. | ||
| Description Cet attribut enregistre la date et l'heure de la dernière extraction ou mise à jour des données. Il fournit des métadonnées sur la fraîcheur de l'ensemble de données analysé. Il est important pour comprendre l'actualité de l'analyse Process Mining. Les utilisateurs peuvent voir à quel point les données sont récentes, ce qui est particulièrement pertinent pour la surveillance opérationnelle et les Dashboards qui suivent les cas en cours. Pourquoi c'est important Indique la fraîcheur des données, ce qui est essentiel pour garantir que les analyses et les dashboards sont basés sur des informations à jour. Où obtenir Ceci est généralement généré et estampillé sur l'ensemble de données au moment de l'extraction des données par l'outil ETL ou de pipeline de données. Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| ID du système source SourceSystemId | Identifiant du système source d'où les données ont été extraites. | ||
| Description Cet attribut spécifie le système d'enregistrement où les données d'événement ont été générées. Pour ce processus, il s'agirait généralement de l'ID d'instance SAP S/4HANA. Dans les environnements multi-systèmes, ce champ est essentiel pour la traçabilité des données, le dépannage et la garantie de l'intégrité des données. Il aide à différencier les données si les retours sont traités sur différentes instances ERP ou intégrés à des systèmes externes comme un système de gestion d'entreрôt. Pourquoi c'est important Fournit un contexte crucial pour l'origine et la lignée des données, particulièrement dans les environnements multi-systèmes, assurant la traçabilité et la fiabilité des données. Où obtenir Cette valeur est généralement statique et configurée lors de l'extraction des données. Elle peut être récupérée à partir des informations administratives du système SAP, telles que l'ID du système (SID). Exemples S4H_PROD_100S4Q_DEV_200 | |||
| Heure de fin de l'événement EventEndTime | Le timestamp marquant l'achèvement d'une activité, utilisé pour calculer sa durée. | ||
| Description Alors que StartTime (EventTime) marque le début d'une activité, EventEndTime marque sa conclusion. Pour de nombreux événements générés par le système, les heures de début et de fin sont identiques, représentant une occurrence instantanée. Cependant, pour les activités ayant une durée mesurable, comme l'« Inspection des articles », cet attribut est crucial. Cet attribut permet le calcul direct du temps de traitement de l'activité. C'est fondamental pour l'analyse des performances, aidant à identifier quelles étapes spécifiques, et pas seulement les écarts entre elles, consomment le plus de temps. Pourquoi c'est important Permet le calcul précis des durées d'activité individuelles, ce qui est essentiel pour identifier les inefficacités au sein d'étapes de processus spécifiques. Où obtenir C'est souvent un champ dérivé. Pour certaines activités, il peut s'agir d'un champ distinct. Plus communément, c'est le StartTime de l'activité suivante dans le dossier. Exemples 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| ID client CustomerId | L'identifiant unique du client qui initie le retour. | ||
| Description Cet attribut identifie le client qui a demandé le retour. Il relie l'instance de processus à une partie spécifique des données de base client. L'analyse des retours par client aide à identifier des modèles, tels que des clients ayant des taux de retour anormalement élevés, ce qui pourrait indiquer un comportement frauduleux ou une insatisfaction. Elle permet également de segmenter le processus de retour en fonction du type de client, de sa valeur ou de son historique, autorisant des niveaux de service adaptés. Pourquoi c'est important Relie les retours à des clients spécifiques, permettant l'analyse du comportement client, la segmentation et l'identification des clients qui retournent fréquemment des articles. Où obtenir Trouvé dans le champ du numéro de client (KUNNR) de la table d'en-tête de commande de retour (VBAK). Exemples CLIENT-001234CUST-005678CUST-009012 | |||
| ID Produit ProductId | L'identifiant unique de l'article retourné. | ||
| Description Cet attribut spécifie le matériel ou le produit qui fait l'objet du retour. Il relie le processus de retour à un article spécifique du catalogue de produits. L'analyse des retours par produit est fondamentale pour identifier les articles avec des taux de retour élevés, ce qui peut indiquer des défauts de qualité, de mauvaises descriptions de produits ou des problèmes de fabrication. Ces données aident les entreprises à prendre des décisions éclairées concernant la conception des produits, la gestion des fournisseurs et la stratégie d'inventaire. Pourquoi c'est important Relie le processus de retour à des produits spécifiques, permettant l'analyse des taux de retour au niveau de l'article et l'identification des problèmes de qualité ou de description. Où obtenir Trouvé dans le champ du numéro d'article (MATNR) de la table d'articles de commande de retour (VBAP) ou de la table d'articles de livraison de retour (LIPS). Exemples FG-10023HW-45981SW-LICENSE-PREM | |||
| Montant du remboursement RefundAmount | La valeur monétaire finale du remboursement émis au client. | ||
| Description Cet attribut représente le montant réel crédité ou remboursé au client à l'issue du processus de retour. Cette valeur est enregistrée dans des documents financiers tels que les avoirs. Il s'agit d'une métrique financière clé utilisée dans diverses analyses. Elle est essentielle pour le Dashboard « Analyse des écarts de montant de remboursement » afin de comparer le montant demandé. Elle permet également de segmenter les retours par valeur pour identifier si les retours de grande valeur suivent un processus différent ou prennent plus de temps à être résolus. Pourquoi c'est important Suit l'impact financier des retours et est essentiel pour analyser l'exactitude des remboursements, identifier les dossiers de grande valeur et comprendre les coûts globaux. Où obtenir Provenant du champ de valeur nette (NETWR) du document d'avoir, trouvé dans des tables comme VBRK (En-tête de document de facturation) ou BSEG (Segment de document comptable). Exemples 125.50999,0049.99 | |||
| Motif de retour ReturnReason | La raison fournie par le client pour le retour de l'article. | ||
| Description Cet attribut capture la raison invoquée par le client pour le retour, telle que « Article défectueux », « Mauvaise taille » ou « Plus nécessaire ». Elle est généralement sélectionnée dans une liste prédéfinie de codes de motif lors du processus d'initiation du retour. L'analyse des motifs de retour est cruciale pour identifier les problèmes de qualité des produits, améliorer les descriptions de produits ou affiner les processus de vente. Elle fournit un aperçu direct de l'insatisfaction client et aide à prioriser les domaines d'amélioration commerciale pour réduire le taux de retour global. Pourquoi c'est important Offre un aperçu critique des raisons des retours, permettant une analyse des causes profondes pour résoudre les problèmes de qualité des produits, les erreurs de traitement des commandes ou les écarts par rapport aux attentes des clients. Où obtenir Généralement stocké dans la table des postes de commande de retour (VBAP) dans le champ ABGRU (Motif de rejet des documents de vente). Exemples 001 - Mauvaise qualité002 - Endommagé pendant le transport005 - Article incorrect expédié | |||
| Nom d'utilisateur UserName | L'ID utilisateur de l'employé qui a exécuté l'`activité`. | ||
| Description Cet attribut identifie l'utilisateur ou l'agent système spécifique responsable de l'exécution d'une tâche, comme l'approbation d'un retour ou la création d'un avoir. Dans SAP, cela est souvent capturé dans des champs qui enregistrent l'utilisateur qui a créé ou modifié un document. L'analyse par utilisateur aide à identifier les individus ou équipes très performants, les besoins en formation et la répartition de la charge de travail. Elle est également essentielle pour investiguer les déviations, car elle relie les actions de processus à des individus spécifiques, soutenant les efforts de conformité et d'audit. Pourquoi c'est important Associe les activités du processus à des utilisateurs spécifiques, permettant l'analyse de la performance de l'équipe, de la charge de travail et de la conformité. Où obtenir Généralement trouvé dans les tables d'en-tête de document, telles que ERNAM (Créé par) dans VBAK (Commandes de vente), LIKP (Livraisons) et BKPF (Documents comptables). Les détails de l'utilisateur peuvent être enrichis à partir de la table maîtresse d'utilisateurs USR21. Exemples CBROWNASMITHWF_BATCH | |||
| Adhérence à la politique de retour ReturnPolicyAdherence | Un indicateur signalant si le cas de retour est conforme à la politique de retour définie. | ||
| Description Cet attribut booléen calculé indique si un retour respecte les critères définis dans la politique de retour applicable. La logique pourrait vérifier, par exemple, si le retour a été initié dans le délai autorisé ou si le motif de retour est valide pour le produit. Cet attribut soutient directement le Dashboard « Vue d'ensemble de la conformité à la politique de retour ». Il quantifie les taux de conformité et permet d'explorer les cas non conformes pour comprendre les raisons des déviations, aidant à appliquer les politiques plus efficacement. Pourquoi c'est important Quantifie la conformité aux règles métier, aidant à identifier et à réduire les violations de politique qui peuvent impacter la rentabilité ou créer des exceptions de processus. Où obtenir Calculé sur la base de règles métier. Par exemple, (Date d'initiation du retour - Date d'achat originale) <= [Jours de retour autorisés]. Cela nécessite la Date d'achat originale et les règles de politique. Exemples truefaux | |||
| Agent de traitement ProcessingAgent | L'agent ou le groupe de ressources spécifique responsable du traitement d'une activité manuelle. | ||
| Description Cet attribut identifie la personne ou l'équipe qui a effectué une tâche donnée. Il peut être plus spécifique que le « Nom d'utilisateur » en se référant à un rôle ou à une équipe, notamment dans un environnement de services partagés. Ceci est précieux pour le Dashboard « Efficacité de l'approbation des remboursements » afin d'analyser les performances entre différents agents ou équipes. Cela aide à comprendre la répartition de la charge de travail, à identifier les besoins en formation et à reconnaître les meilleurs performeurs ou les équipes qui pourraient partager des bonnes pratiques. Pourquoi c'est important Permet une analyse des performances au niveau de l'agent ou de l'équipe, aidant à gérer la charge de travail, à identifier les opportunités de formation et à améliorer l'efficacité. Où obtenir Ces informations pourraient être disponibles via les fonctions SAP Business Partner si des agents sont affectés, ou elles pourraient être dérivées du département ou du rôle de l'utilisateur dans la structure organisationnelle RH. Exemples Support de Niveau 1Équipe d'inspection de l'entrepôtDépartement Finance - AP | |||
| Date cible du SLA de remboursement RefundSlaTargetDate | La date cible à laquelle le remboursement du dossier de retour doit être traité. | ||
| Description Cet attribut définit la date limite de l'accord de niveau de service (SLA) pour le traitement du remboursement. Cette date est généralement calculée en fonction de règles métier, par exemple, un certain nombre de jours après l'approbation du retour ou la réception des marchandises. Ce champ est la base du Dashboard de suivi de la conformité aux SLA de remboursement et du KPI associé. Il permet un suivi proactif des dossiers risquant de ne pas respecter leur SLA et d'analyser les causes profondes des retards, contribuant ainsi à améliorer la satisfaction client. Pourquoi c'est important Fournit la base de référence pour mesurer la conformité aux SLA, aidant à surveiller les performances, à prioriser les cas en attente et à améliorer la satisfaction client. Où obtenir Il s'agit presque toujours d'un champ dérivé. La logique serait basée sur une date clé (par exemple, la date de création de la demande de retour) plus une durée définie par des règles métier, qui pourraient dépendre de facteurs tels que le type de client ou le motif de retour. Exemples 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| Délai de traitement global CycleTime | Le temps total écoulé entre l'initiation et la clôture d'un dossier de retour. | ||
| Description Cette métrique calculée mesure la durée de bout en bout de l'ensemble du processus de retours pour un seul dossier. Elle est généralement calculée comme la différence de temps entre le premier et le dernier événement, par exemple de « Demande de retour initiée » à « Dossier de retour fermé ». Le temps de cycle est un KPI primaire pour l'efficacité des processus. Il est utilisé dans le Dashboard « Temps de cycle global des retours » pour surveiller les performances, établir des repères et identifier les tendances. L'analyse des facteurs corrélés aux temps de cycle plus longs, tels que le type de produit ou le motif de retour, peut révéler des inefficacités systémiques. Pourquoi c'est important C'est un KPI fondamental pour mesurer l'efficacité globale des processus et il impacte directement la satisfaction client et les coûts opérationnels. Où obtenir Il s'agit d'un champ calculé. Il est obtenu en prenant la différence entre le EventTime maximum et minimum pour chaque ReturnCaseId unique. Exemples 5j 4h 30m12j 2h 15m2j 8h 0m | |||
| Est Automatisé IsAutomated | Un indicateur signalant si une activité a été réalisée par un système ou par un humain. | ||
| Description Cet attribut booléen distingue les activités exécutées automatiquement par un système, comme un Workflow ou un job en arrière-plan, et celles effectuées manuellement par un utilisateur. Il est essentiel pour calculer le KPI « Taux d'approbation automatique des remboursements » et pour identifier les opportunités d'accroître l'automatisation. En filtrant les tâches manuelles, les entreprises peuvent concentrer leurs efforts d'amélioration des processus sur les domaines où l'automatisation pourrait apporter les avantages les plus significatifs en termes de rapidité, de coût et de précision. Pourquoi c'est important Distingue les tâches manuelles des tâches automatisées, ce qui est crucial pour identifier les opportunités d'automatisation et mesurer l'impact de la transformation numérique. Où obtenir Ceci est généralement dérivé en fonction du nom d'utilisateur. Par exemple, si l'utilisateur est 'WF_BATCH' ou un autre ID système, l'activité est marquée comme automatisée. Exemples truefaux | |||
| Est un retravail IsRework | Un indicateur signalant si une activité dans un cas est une répétition d'une activité précédente. | ||
| Description Cet attribut booléen calculé identifie les instances de retrabalho, où une activité est effectuée plus d'une fois au sein du même dossier. Par exemple, si une inspection d'article doit être répétée ou si un avoir est créé, annulé, puis recréé. Cet attribut est essentiel pour le Dashboard « Analyse du retrabalho du traitement des remboursements » et le KPI « Taux de retrabalho des remboursements ». Il aide à quantifier l'inefficacité des processus en mettant en évidence les activités sujettes aux erreurs ou nécessitant plusieurs tentatives, signalant les domaines nécessitant de meilleurs contrôles ou une formation améliorée. Pourquoi c'est important Met en évidence les inefficacités et les erreurs de processus en signalant le travail répété, permettant des améliorations ciblées pour réduire le gaspillage et les retards. Où obtenir Cet indicateur est généralement calculé par l'outil de Process Mining lui-même ou peut être précalculé lors de la transformation des données. Il vérifie si le même nom d'activité est déjà apparu précédemment dans le même dossier. Exemples truefaux | |||
| ID de la politique de retour ReturnPolicyId | L'identifiant de la politique de retour qui s'applique à ce dossier de retour spécifique. | ||
| Description Cet attribut indique la politique de retour spécifique ou l'ensemble de règles applicable à la transaction. Les politiques peuvent varier en fonction du type de produit, du segment de clientèle ou du temps écoulé depuis l'achat. Ces données sont essentielles pour le « Vue d'ensemble de la conformité à la politique de retour ». En associant chaque dossier à une politique, le système peut vérifier automatiquement l'adhérence aux règles, telles que les délais de retour ou les exigences d'état des articles, et signaler les déviations pour analyse. Pourquoi c'est important Permet une vérification automatisée de la conformité par rapport aux règles métier, aidant à garantir que les retours sont traités de manière cohérente et conformément à la politique. Où obtenir Ce n'est souvent pas un champ SAP standard et il peut devoir être dérivé en fonction de la logique métier utilisant des données comme le type de produit, le client et la date de vente. Il pourrait être stocké dans un champ personnalisé s'il est implémenté. Exemples STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Montant du remboursement demandé RequestedRefundAmount | Le montant du remboursement initialement demandé ou attendu au début du processus. | ||
| Description Cet attribut capture la valeur des marchandises retournées selon la demande de retour initiale. Il sert de base de référence pour comparer le montant remboursé final. Ce champ est spécifiquement requis pour le Dashboard d'analyse des écarts de montant de remboursement. La comparaison du montant demandé avec le montant réel remboursé aide à identifier des problèmes tels que les remboursements partiels dus à des articles endommagés, des frais de restockage ou d'autres ajustements, garantissant la précision financière et la transparence. Pourquoi c'est important Sert de référence pour mesurer l'exactitude des remboursements, aidant à identifier et à analyser les écarts entre les montants de remboursement prévus et réels. Où obtenir Généralement extrait de la valeur nette des articles de la commande de vente de retour initiale. Il s'agirait de la valeur nette (NETWR) des lignes correspondantes dans la table VBAP. Exemples 125.501050,0049.99 | |||
| Numéro d'avoir CreditMemoNumber | L'identifiant unique du document d'avoir, qui autorise le remboursement. | ||
| Description Un avoir est le document de facturation qui crédite officiellement le compte du client pour les articles retournés. Cet attribut est le numéro unique de ce document financier. Le suivi du Numéro d'avoir est essentiel pour analyser la partie règlement financier du processus de retours. Il marque une étape critique, déclenchant souvent le paiement effectif du remboursement, et est nécessaire pour la réconciliation financière et l'audit. Pourquoi c'est important Représente la transaction financière officielle pour le remboursement, essentielle pour le suivi des étapes finales du processus et pour l'audit financier. Où obtenir C'est le numéro du document de facturation (VBELN) de la table d'en-tête du document de facturation (VBRK), où la catégorie de document indique un avoir. Exemples 900003459000034690000347 | |||
| Numéro de livraison de retour ReturnDeliveryNumber | L'identifiant unique du document de livraison de retour. | ||
| Description Lorsqu'un client retourne physiquement des marchandises, un document de livraison de retour est créé dans SAP pour gérer la logistique entrante. Cet attribut est le numéro unique de ce document. Cet ID est important pour suivre le mouvement physique des marchandises retournées. Il relie les aspects financiers et logistiques du retour, permettant une analyse détaillée des phases de réception et d'inspection des marchandises du processus. Pourquoi c'est important Fournit un lien essentiel entre la commande de retour et la réception physique des marchandises, crucial pour l'analyse des délais de traitement logistique et d'entrepôt. Où obtenir C'est le numéro du document de livraison (VBELN) de la table d'en-tête de livraison (LIKP), où la catégorie de document indique une livraison de retour. Exemples 840000128400001384000014 | |||
| Organisation commerciale SalesOrganization | L'unité organisationnelle responsable de la vente originale et du retour. | ||
| Description L'organisation commerciale est un élément clé de la structure organisationnelle de SAP qui représente une unité responsable de la vente et de la distribution de produits et services. Elle est affectée à la transaction de retour. Cet attribut permet de filtrer et de comparer le processus de retours entre différentes unités commerciales, régions ou divisions. Il aide à identifier si certaines organisations commerciales ont des taux de retour plus élevés ou des processus de traitement des retours moins efficaces, fournissant une base pour l'analyse de la performance organisationnelle. Pourquoi c'est important Permet la comparaison de la performance et des taux du processus de retour entre différentes unités commerciales, régions ou canaux de vente. Où obtenir Trouvé dans le champ de l'organisation des ventes (VKORG) de la table d'en-tête de commande de retour (VBAK). Exemples 10002100US01 | |||
| Respect du SLA de remboursement RefundSlaAdherence | Un indicateur qui signale si le remboursement a été traité dans le respect de l'objectif de l'accord de niveau de service (SLA). | ||
| Description Cet attribut calculé vérifie si l'activité « Remboursement traité » a eu lieu à la date cible du SLA de remboursement ou avant. Il fournit un simple indicateur vrai ou faux de la conformité au SLA pour chaque dossier. C'est la métrique centrale pour le Dashboard « Suivi de la conformité au SLA de remboursement » et le KPI « Taux de conformité au SLA de remboursement ». Il aide à mesurer la performance par rapport aux engagements clients et identifie les dossiers qui n'ont pas répondu aux attentes, permettant une analyse des causes profondes des retards. Pourquoi c'est important Mesure directement la performance par rapport aux engagements envers les clients, en faisant un indicateur critique de la qualité du service et de la satisfaction client. Où obtenir Calculé en comparant l'EventTime de l'activité 'Remboursement traité' à la 'RefundSlaTargetDate' pour chaque cas. Exemples truefaux | |||
| Résultat de l'inspection de l'article ItemInspectionOutcome | Le résultat de l'inspection physique de l'article retourné. | ||
| Description Cet attribut enregistre le résultat du processus d'inspection effectué après la réception des marchandises à l'entrepôt. Les résultats courants incluent « Accepté », « Rejeté - Endommagé » ou « Accepté - Revendable ». Ces données fournissent un contexte crucial pour les étapes de processus ultérieures. Elles déterminent si un remboursement complet, partiel ou aucun remboursement n'est émis. L'analyse de ce résultat aide à identifier les raisons des rejets et peut fournir des retours d'information sur l'emballage des produits ou les partenaires d'expédition si les articles sont fréquemment endommagés en transit. Pourquoi c'est important Explique le processus de prise de décision derrière les approbations ou rejets de remboursement, fournissant des données précieuses sur l'état de l'article et les raisons des ajustements de remboursement. Où obtenir Ces informations peuvent être enregistrées dans un lot d'inspection du module de gestion de la qualité (QM), ou comme un statut ou un code de motif sur la ligne de livraison de retour (LIPS). Elles peuvent également exister dans un champ personnalisé. Exemples Accepté - RevendableAccepté - À remettre à neufRejeté - Dommage causé par le clientRejeté - Mauvais article retourné | |||
| Statut de la commande de retour ReturnOrderStatus | Le statut global actuel du dossier de retour. | ||
| Description Cet attribut fournit un statut de haut niveau du dossier de retour à tout moment, tel que « Ouvert », « En cours » ou « Fermé ». Il s'agit souvent d'un statut agrégé dérivé du dernier jalon majeur achevé. Ceci est essentiel pour le « Dashboard du statut actuel des dossiers de retour », qui offre une vue opérationnelle de la charge de travail et de la distribution des dossiers. Il aide les gestionnaires à comprendre combien de dossiers se trouvent à chaque étape du processus, permettant une meilleure allocation des ressources et une gestion de la charge de travail. Pourquoi c'est important Fournit un aperçu de l'état d'avancement de chaque dossier dans le processus, essentiel pour les tableaux de bord opérationnels qui suivent la charge de travail et le statut actuels. Où obtenir Dérivé des champs de statut sur les documents pertinents. Par exemple, du statut d'en-tête (GBSTK) ou du statut d'article (LFSTK) dans la commande client (VBUK/VBUP) ou les documents de livraison associés. Exemples En attente de réception des marchandisesEn attente d'inspectionRemboursement en attenteClôturé | |||
Activités de traitement des retours et remboursements
| Activité | Description | ||
|---|---|---|---|
| Avoir émis | C'est la création du document de facturation officiel qui crédite le compte du client pour l'article retourné. Il s'agit d'un événement explicite capturé lorsque l'avoir est généré à partir de la demande d'avoir. | ||
| Pourquoi c'est important La création de l'avoir est un jalon financier critique. Elle confirme le montant à rembourser et autorise le début du processus de paiement. Où obtenir Saisi lors de la création d'un document de facturation dans la table VBRK avec une catégorie de document indiquant un avoir. Ceci est lié à la demande d'avoir dans la table VBFA. Capture L'événement est enregistré lors de la sauvegarde d'un nouveau document de facturation d'avoir (par exemple, en utilisant la transaction VF01). Type d'événement explicit | |||
| Demande d'avoir créée | Suite à une inspection réussie, cette activité marque la création d'une demande d'émission d'un avoir au client. Ceci est enregistré comme un nouveau document de vente, une demande d'avoir, qui fait référence à la commande de retour originale. | ||
| Pourquoi c'est important C'est le déclencheur de la partie règlement financier du processus de retours. L'analyse du temps écoulé entre l'inspection et cette étape révèle l'efficacité du transfert de la logistique à la finance. Où obtenir Saisi lors de la création d'un document de vente dans la table VBAK avec une catégorie de document pour Demande d'avoir. Le lien vers le retour est maintenu dans la table de flux de documents VBFA. Capture L'événement est enregistré lors de la sauvegarde d'un nouveau document de demande d'avoir. Type d'événement explicit | |||
| Demande de retour initiée | C'est le point de départ du processus de retours, où une commande de retour est formellement créée dans le système. Cet événement est capturé explicitement lorsqu'un nouveau document de vente de type commande de retour est enregistré dans SAP S/4HANA. | ||
| Pourquoi c'est important Cette activité marque le début officiel du cycle de vie du dossier de retour. L'analyse du temps écoulé entre cet événement et la clôture est cruciale pour mesurer le temps de cycle global de retour et l'expérience client. Où obtenir Il s'agit d'un événement explicite capturé à partir de la création d'un document de vente dans la table VBAK où la catégorie de document (VBAK-VBTYP) indique une commande de retour. L'horodatage de création est VBAK-ERDAT. Capture L'événement est enregistré lors de la sauvegarde d'une nouvelle commande client de retour (par exemple, en utilisant la transaction VA01). Type d'événement explicit | |||
| Dossier de retour clos | C'est l'activité finale, indiquant que le processus de retours est terminé et qu'aucune autre action n'est attendue pour le dossier. Cela est généralement déduit lorsque le document de commande de retour atteint un statut final et fermé dans le système. | ||
| Pourquoi c'est important Cet événement définit la fin du cycle de vie du processus, permettant le calcul du temps de cycle total de bout en bout. Il confirme que le dossier a été entièrement résolu. Où obtenir Déduit du statut global de la commande de retour dans la table VBAK ou de ses articles dans VBAP atteignant un état 'Terminé' ou 'Clos'. Ceci est déterminé par la configuration de la gestion des statuts du système. Capture Déduit du changement de statut du document de commande de retour en 'Terminé'. Type d'événement inferred | |||
| Inspection de l'article terminée | Représente l'achèvement de l'évaluation de la qualité et de l'état des marchandises retournées. Dans la gestion avancée des retours, il s'agit souvent d'une étape explicite qui enregistre le résultat de l'inspection et détermine l'action subséquente, comme le remboursement ou la mise au rebut. | ||
| Pourquoi c'est important La durée et le résultat de l'inspection impactent directement le temps de traitement du remboursement et la gestion des stocks. Cette activité est essentielle pour analyser l'efficacité de l'inspection et les retrabail. Où obtenir Dans SAP Advanced Returns Management (ARM), il peut s'agir d'un événement explicite de la transaction d'inspection. Il peut également être déduit d'un changement de statut sur l'article de commande de retour indiquant le résultat de l'inspection. Capture Saisi à partir des journaux de transactions ou des changements de statut liés aux activités de suivi logistique dans l'ARM. Type d'événement explicit | |||
| Marchandises reçues à l'entrepôt | Cet événement marque la réception physique de l'article retourné à l'entrepôt ou au centre de traitement. Il est explicitement capturé lorsqu'une Entrée de Marchandises (PGR) est exécutée contre la livraison de retour, créant un document matériel. | ||
| Pourquoi c'est important Il s'agit d'un jalon critique qui déclenche le décompte pour l'inspection et la disposition. Les retards antérieurs à ce point sont dus au client, tandis que les retards ultérieurs sont internes. Où obtenir Saisi à partir des tables de documents de marchandises MSEG et MKPF pour le type de mouvement d'entrée de marchandises associé aux retours. La date de comptabilisation (MKPF-BUDAT) indique l'heure de l'événement. Capture L'événement correspond à la comptabilisation d'une entrée de marchandises pour la livraison de retour. Type d'événement explicit | |||
| Remboursement traité | Cette activité marque la dernière étape du processus de remboursement, où l'avoir financier est soldé, signifiant que le paiement a été envoyé au client. Cela est déduit par la création d'un document de compensation dans le module financier qui solde le crédit ouvert sur le compte du client. | ||
| Pourquoi c'est important C'est le moment où le client est effectivement payé. Le temps nécessaire pour atteindre cette étape depuis l'initiation du retour est un facteur majeur de satisfaction client et est essentiel pour mesurer le respect du SLA. Où obtenir Déduit des informations du document de compensation dans la table des postes de comptabilité financière BSEG. La date de compensation (BSEG-AUGDT) sur le poste client associé à l'avoir indique quand le remboursement a été traité. Capture Déduit du renseignement du champ de date de compensation pour le document comptable associé à l'avoir. Type d'événement inferred | |||
| Commande d'échange créée | Cette activité représente une résolution alternative où, au lieu d'un remboursement, une nouvelle commande client est créée pour expédier un article de remplacement au client. Cela est capturé lorsqu'une nouvelle commande client est créée avec une référence au retour original. | ||
| Pourquoi c'est important Cette activité aide à différencier les retours pour remboursement et les retours pour échange, qui ont des parcours de processus et des résultats clients différents. Elle est essentielle pour l'analyse des variantes. Où obtenir Saisi lors de la création d'un nouveau document de vente dans VBAK qui est lié à la commande de retour dans la table de flux de documents (VBFA). Capture L'événement est enregistré lors de la sauvegarde d'un nouveau document de commande client désigné comme un remplacement. Type d'événement explicit | |||
| Commande de retour approuvée | Représente l'approbation formelle ou la libération de la commande de retour, lui permettant de passer à l'étape suivante. Cela est généralement déduit d'un changement de statut sur l'en-tête ou l'article du document de vente, indiquant qu'il a été libéré de tout blocage. | ||
| Pourquoi c'est important Les étapes d'approbation peuvent être une source importante de retard. Le suivi de cette activité aide à identifier les goulots d'étranglement dans la phase d'autorisation initiale du processus de retours. Où obtenir Déduit des tables de gestion de statut ou des champs de statut directement au sein des tables VBAK ou VBAP. Un changement de statut de libération ou la suppression d'un blocage de livraison (VBAP-LIFSP) peut signifier une approbation. Capture Déduit d'un changement dans les champs de statut d'en-tête ou d'article de la commande de retour indiquant une libération ou une approbation. Type d'événement inferred | |||
| Document comptable créé | Cet événement se produit lorsque l'avoir est correctement enregistré dans le module de comptabilité financière. Il crée les écritures correspondantes dans le grand livre général, officialisant le crédit d'un point de vue comptable. | ||
| Pourquoi c'est important Cette activité confirme que l'avoir a été intégré au système financier. Le temps entre la création de l'avoir et la comptabilisation peut révéler des problèmes dans l'interface entre la facturation et la finance. Où obtenir Saisi lors de la création d'un en-tête de document dans la table comptable BKPF, qui est lié à l'avoir dans VBRK (VBRK-BELNR). Capture L'événement est enregistré lors de la comptabilisation réussie du document de facturation en Comptabilité financière. Type d'événement explicit | |||
| Retour de livraison créé | Cette activité signifie la création d'un document de livraison entrante, utilisé pour gérer la réception physique des marchandises retournées. Le système le capture comme un événement de création explicite pour un document de livraison faisant référence à la commande de retour. | ||
| Pourquoi c'est important Cette étape est un jalon logistique clé. Le temps entre l'approbation du retour et la création de la livraison met en évidence l'efficacité de la communication des informations de retour à l'entrepôt ou au service de réception. Où obtenir Saisi lors de la création d'un en-tête de livraison dans la table LIKP, lié à la commande de retour précédente via la table de flux de documents VBFA. Capture L'événement est enregistré lors de la sauvegarde d'un nouveau document de livraison de retour (par exemple, en utilisant la transaction VL01N). Type d'événement explicit | |||
| Retour rejeté | Indique que l'article retourné ne répondait pas aux critères de la politique de retour et que la demande de remboursement ou d'avoir a été refusée. Ceci est généralement capturé par l'application d'un statut ou d'un code motif spécifique à l'article de commande de retour après inspection. | ||
| Pourquoi c'est important Le suivi des rejets aide à analyser la conformité aux politiques de retour et à identifier les raisons courantes de refus. C'est un chemin d'exception clé dans le processus. Où obtenir Déduit d'un motif de rejet (VBAP-ABGRU) défini sur l'article de commande de retour ou d'un statut spécifique attribué lors du processus d'inspection dans Advanced Returns Management. Capture Déduit de la définition d'un motif de rejet ou d'un statut spécifique 'rejeté' sur l'article du document de retour. Type d'événement inferred | |||
Guides d'extraction
Étapes
- Vérification des prérequis : Assurez-vous que le compte utilisateur exécutant l'extraction dispose des autorisations nécessaires dans SAP S/4HANA pour accéder aux vues CDS (Core Data Services) requises. Les vues clés incluent I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry et I_ClearedItem.
- Accès à l'outil de requête : Connectez-vous à votre client SQL préféré ou à votre outil d'intégration de données disposant d'une connexion établie à la base de données SAP S/4HANA. Il peut s'agir d'outils SAP comme SAP Analytics Cloud ou d'une plateforme ETL tierce.
- Définition des paramètres de requête : Avant l'exécution, vous devez modifier la requête SQL fournie. Localisez les valeurs d'espace réservé et remplacez-les par les paramètres corrects pour votre environnement. Cela inclut la définition de la
[Date de début], de la[Date de fin], de votre[ID système source], de votre[Type de commande de retour]et d'autres filtres de type de document ou de code de société. - Exécution de la requête d'extraction : Copiez la requête SQL complète et exécutez-la dans votre outil. La requête est conçue pour collecter toutes les activités spécifiées dans un seul jeu de données en unionnant les résultats de plusieurs instructions select.
- Compréhension de la logique de la requête : Chaque bloc
SELECTdans la structureUNION ALLest responsable de l'extraction d'une activité spécifique. Il joint plusieurs vues CDS pour collecter les attributs requis, attribue une chaîne fixe commeActivityNameet sélectionne l'horodatage pertinent pour l'EventTime. - Examen des données brutes : Une fois la requête terminée, effectuez un bref examen de la sortie. Vérifiez un nombre raisonnable de lignes et assurez-vous que les colonnes clés telles que
ReturnCaseId,ActivityNameetEventTimesont renseignées comme prévu. - Transformation des données : La requête est structurée pour produire un format de journal d'événements plat. Aucune transformation structurelle significative n'est généralement nécessaire. Cependant, vous pourriez avoir besoin d'ajuster les formats d'horodatage ou les types de données en fonction des exigences de votre système cible.
- Exportation du journal d'événements : Exportez le jeu de résultats de la requête sous forme de fichier CSV. Assurez-vous que le fichier utilise l'encodage UTF-8 pour éviter les problèmes de caractères, en particulier avec les noms d'utilisateur ou les descriptions de produits.
- Téléchargement vers l'outil de Process Mining : Le fichier CSV résultant est maintenant prêt à être téléchargé sur votre plateforme de Process Mining, telle que ProcessMind. Mappez les colonnes du fichier aux champs correspondants de l'outil, par exemple,
ReturnCaseIdà l'ID du cas,ActivityNameà l'activité, etEventTimeà l'horodatage.
Configuration
- Prérequis : L'utilisateur exécutant l'extraction doit disposer des autorisations d'affichage pour les objets liés aux documents de vente (VBAK), aux livraisons (LIKP), à la facturation (VBRK) et à la comptabilité (BSEG, BKPF). L'accès aux vues CDS sous-jacentes est essentiel.
- Filtres de portée des données : Il est crucial de filtrer la requête pour des types de documents spécifiques afin d'isoler le processus de retour. Configurez les espaces réservés pour les types de commandes de retour (par exemple, 'RE'), les types de demandes d'avoir (par exemple, 'G2') et les types de commandes d'échange (par exemple, 'SO'). Le filtrage par
CompanyCodeouSalesOrganizationest également fortement recommandé pour limiter la portée des données. - Filtrage par plage de dates : Pour gérer les performances et le volume de données, appliquez toujours un filtre par plage de dates. Commencez par une période récente de 3 à 6 mois de données. La requête utilise la date de création de la commande de retour initiale (
I_SalesDocument.CreationDate) comme condition de filtre principale. - Considérations relatives aux performances : Il s'agit d'une requête complète qui joint plusieurs grandes vues CDS. L'exécution peut être gourmande en ressources sur le système source S/4HANA. Planifiez l'extraction pendant les heures creuses pour minimiser l'impact. Pour de très grands jeux de données, envisagez des stratégies de chargement incrémentiel.
a Exemple de requête sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed' Étapes
- Vérification des prérequis : Assurez-vous que le compte utilisateur exécutant l'extraction dispose des autorisations nécessaires dans SAP S/4HANA pour accéder aux vues CDS (Core Data Services) requises. Les vues clés incluent I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry et I_ClearedItem.
- Accès à l'outil de requête : Connectez-vous à votre client SQL préféré ou à votre outil d'intégration de données disposant d'une connexion établie à la base de données SAP S/4HANA. Il peut s'agir d'outils SAP comme SAP Analytics Cloud ou d'une plateforme ETL tierce.
- Définition des paramètres de requête : Avant l'exécution, vous devez modifier la requête SQL fournie. Localisez les valeurs d'espace réservé et remplacez-les par les paramètres corrects pour votre environnement. Cela inclut la définition de la
[Date de début], de la[Date de fin], de votre[ID système source], de votre[Type de commande de retour]et d'autres filtres de type de document ou de code de société. - Exécution de la requête d'extraction : Copiez la requête SQL complète et exécutez-la dans votre outil. La requête est conçue pour collecter toutes les activités spécifiées dans un seul jeu de données en unionnant les résultats de plusieurs instructions select.
- Compréhension de la logique de la requête : Chaque bloc
SELECTdans la structureUNION ALLest responsable de l'extraction d'une activité spécifique. Il joint plusieurs vues CDS pour collecter les attributs requis, attribue une chaîne fixe commeActivityNameet sélectionne l'horodatage pertinent pour l'EventTime. - Examen des données brutes : Une fois la requête terminée, effectuez un bref examen de la sortie. Vérifiez un nombre raisonnable de lignes et assurez-vous que les colonnes clés telles que
ReturnCaseId,ActivityNameetEventTimesont renseignées comme prévu. - Transformation des données : La requête est structurée pour produire un format de journal d'événements plat. Aucune transformation structurelle significative n'est généralement nécessaire. Cependant, vous pourriez avoir besoin d'ajuster les formats d'horodatage ou les types de données en fonction des exigences de votre système cible.
- Exportation du journal d'événements : Exportez le jeu de résultats de la requête sous forme de fichier CSV. Assurez-vous que le fichier utilise l'encodage UTF-8 pour éviter les problèmes de caractères, en particulier avec les noms d'utilisateur ou les descriptions de produits.
- Téléchargement vers l'outil de Process Mining : Le fichier CSV résultant est maintenant prêt à être téléchargé sur votre plateforme de Process Mining, telle que ProcessMind. Mappez les colonnes du fichier aux champs correspondants de l'outil, par exemple,
ReturnCaseIdà l'ID du cas,ActivityNameà l'activité, etEventTimeà l'horodatage.
Configuration
- Prérequis : L'utilisateur exécutant l'extraction doit disposer des autorisations d'affichage pour les objets liés aux documents de vente (VBAK), aux livraisons (LIKP), à la facturation (VBRK) et à la comptabilité (BSEG, BKPF). L'accès aux vues CDS sous-jacentes est essentiel.
- Filtres de portée des données : Il est crucial de filtrer la requête pour des types de documents spécifiques afin d'isoler le processus de retour. Configurez les espaces réservés pour les types de commandes de retour (par exemple, 'RE'), les types de demandes d'avoir (par exemple, 'G2') et les types de commandes d'échange (par exemple, 'SO'). Le filtrage par
CompanyCodeouSalesOrganizationest également fortement recommandé pour limiter la portée des données. - Filtrage par plage de dates : Pour gérer les performances et le volume de données, appliquez toujours un filtre par plage de dates. Commencez par une période récente de 3 à 6 mois de données. La requête utilise la date de création de la commande de retour initiale (
I_SalesDocument.CreationDate) comme condition de filtre principale. - Considérations relatives aux performances : Il s'agit d'une requête complète qui joint plusieurs grandes vues CDS. L'exécution peut être gourmande en ressources sur le système source S/4HANA. Planifiez l'extraction pendant les heures creuses pour minimiser l'impact. Pour de très grands jeux de données, envisagez des stratégies de chargement incrémentiel.
a Exemple de requête sql
WITH ReturnOrders AS (
SELECT
SalesDocument AS ReturnCaseId,
CreationDate,
CreationDateTime,
CreatedByUser,
OrderReason,
SoldToParty
FROM I_SalesDocument
WHERE SalesDocumentType = '[Your Return Order Type]' -- e.g., 'RE'
AND CreationDate BETWEEN '[Start Date]' AND '[End Date]'
AND CompanyCode = '[Your Company Code]'
)
-- 1. Return Request Initiated
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Return Request Initiated' AS "ActivityName",
RO.CreationDateTime AS "EventTime",
RO.CreationDateTime AS "EventEndTime",
RO.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM ReturnOrders RO
JOIN I_SalesDocumentItem I ON RO.ReturnCaseId = I.SalesDocument
UNION ALL
-- 2. Return Order Approved
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Order Approved' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus <> 'A' -- Not Open, implying it has been processed/approved
AND I.SDProcessStatus <> 'A'
UNION ALL
-- 3. Return Delivery Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Return Delivery Created' AS "ActivityName",
LH.CreationDateTime AS "EventTime",
LH.CreationDateTime AS "EventEndTime",
LH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
LI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocument AS LH ON DF.SubsequentDocument = LH.DeliveryDocument
JOIN I_DeliveryDocumentItem AS LI ON LH.DeliveryDocument = LI.DeliveryDocument
WHERE DF.PrecedingDocumentCategory = 'C' AND DF.SubsequentDocumentCategory = 'J'
UNION ALL
-- 4. Goods Received at Warehouse
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Goods Received at Warehouse' AS "ActivityName",
MH.CreationDateTime AS "EventTime",
MH.CreationDateTime AS "EventEndTime",
MH.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
MI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_DeliveryDocumentItem AS LI ON DF.SubsequentDocument = LI.DeliveryDocument AND DF.SubsequentDocumentItem = LI.DeliveryDocumentItem
JOIN I_MaterialDocumentItem AS MI ON LI.DeliveryDocument = MI.DeliveryDocument AND LI.DeliveryDocumentItem = MI.DeliveryDocumentItem
JOIN I_MaterialDocumentHeader AS MH ON MI.MaterialDocument = MH.MaterialDocument AND MI.MaterialDocumentYear = MH.MaterialDocumentYear
WHERE DF.SubsequentDocumentCategory = 'J' AND MH.GoodsMovementType = '[Your Return Goods Receipt MVT]' -- e.g., '651', '653'
UNION ALL
-- 5. Item Inspection Completed
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Item Inspection Completed' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.ReturnsInspectionStatus = '4' -- 'Inspection Completed', adjust value based on your config
UNION ALL
-- 6. Return Rejected
SELECT
SDI.SalesDocument AS "ReturnCaseId",
'Return Rejected' AS "ActivityName",
SDI.LastChangeDateTime AS "EventTime",
SDI.LastChangeDateTime AS "EventEndTime",
SDI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
SDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocumentItem AS SDI
JOIN ReturnOrders RO ON SDI.SalesDocument = RO.ReturnCaseId
WHERE SDI.SalesDocumentItemRejectionReason <> ''
UNION ALL
-- 7. Credit Memo Request Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Request Created' AS "ActivityName",
CM_REQ.CreationDateTime AS "EventTime",
CM_REQ.CreationDateTime AS "EventEndTime",
CM_REQ.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument
JOIN I_SalesDocumentItem I ON CM_REQ.SalesDocument = I.SalesDocument
WHERE CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]' -- e.g., 'CR'
UNION ALL
-- 8. Exchange Order Created
SELECT
DF.PrecedingDocument AS "ReturnCaseId",
'Exchange Order Created' AS "ActivityName",
EX_ORD.CreationDateTime AS "EventTime",
EX_ORD.CreationDateTime AS "EventEndTime",
EX_ORD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
JOIN I_SalesDocument AS EX_ORD ON DF.SubsequentDocument = EX_ORD.SalesDocument
JOIN I_SalesDocumentItem I ON EX_ORD.SalesDocument = I.SalesDocument
WHERE EX_ORD.SalesDocumentType = '[Your Exchange Order Type]' -- e.g., 'OR'
UNION ALL
-- 9. Credit Memo Created
SELECT
DF_CM.PrecedingDocument AS "ReturnCaseId",
'Credit Memo Created' AS "ActivityName",
BD.CreationDateTime AS "EventTime",
BD.CreationDateTime AS "EventEndTime",
BD.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
BD.TotalNetAmount AS "RefundAmount",
BDI.Material AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SDDocumentFlow AS DF
JOIN I_SalesDocument AS CM_REQ ON DF.SubsequentDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow AS DF_CM ON CM_REQ.SalesDocument = DF_CM.PrecedingDocument
JOIN I_BillingDocument AS BD ON DF_CM.SubsequentDocument = BD.BillingDocument
JOIN I_BillingDocumentItem AS BDI ON BD.BillingDocument = BDI.BillingDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE DF.PrecedingDocumentCategory = 'C'
UNION ALL
-- 10. Accounting Document Created
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Accounting Document Created' AS "ActivityName",
JE.CreationDateTime AS "EventTime",
JE.CreationDateTime AS "EventEndTime",
JE.CreatedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
JE.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_JournalEntry AS JE
JOIN I_JournalEntryItem JRI ON JE.AccountingDocument = JRI.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK'
UNION ALL
-- 11. Refund Processed
SELECT
RO.ReturnCaseId AS "ReturnCaseId",
'Refund Processed' AS "ActivityName",
CI.ClearingDate AS "EventTime",
CI.ClearingDate AS "EventEndTime",
CI.LastChangedByUser AS "UserName",
RO.OrderReason AS "ReturnReason",
CI.AmountInCompanyCodeCurrency AS "RefundAmount",
JRI.ProductName AS "ProductId",
RO.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_ClearedItem AS CI
JOIN I_JournalEntryItem JRI ON CI.AccountingDocument = JRI.AccountingDocument AND CI.FiscalYear = JRI.FiscalYear AND CI.LedgerGLLineItem = JRI.LedgerGLLineItem
JOIN I_JournalEntry JE ON JRI.AccountingDocument = JE.AccountingDocument
JOIN I_BillingDocument BD ON JE.ReferenceDocument = BD.BillingDocument
JOIN I_SDDocumentFlow DF_CM ON BD.BillingDocument = DF_CM.SubsequentDocument
JOIN I_SalesDocument CM_REQ ON DF_CM.PrecedingDocument = CM_REQ.SalesDocument AND CM_REQ.SalesDocumentType = '[Your Credit Memo Request Type]'
JOIN I_SDDocumentFlow DF ON CM_REQ.SalesDocument = DF.SubsequentDocument
JOIN ReturnOrders RO ON DF.PrecedingDocument = RO.ReturnCaseId
WHERE JE.OriginalReferenceDocumentType = 'VBRK' AND CI.ClearingDate IS NOT NULL
UNION ALL
-- 12. Return Case Closed
SELECT
SD.SalesDocument AS "ReturnCaseId",
'Return Case Closed' AS "ActivityName",
SD.LastChangeDateTime AS "EventTime",
SD.LastChangeDateTime AS "EventEndTime",
SD.LastChangedByUser AS "UserName",
SD.OrderReason AS "ReturnReason",
CAST(NULL AS DECIMAL(17, 2)) AS "RefundAmount",
I.Material AS "ProductId",
SD.SoldToParty AS "CustomerId",
'[Your Source System ID]' AS "SourceSystemId",
CURRENT_UTCTIMESTAMP AS "LastDataUpdateTimestamp"
FROM I_SalesDocument AS SD
JOIN ReturnOrders RO ON SD.SalesDocument = RO.ReturnCaseId
JOIN I_SalesDocumentItem I ON SD.SalesDocument = I.SalesDocument
WHERE SD.OverallSDProcessStatus = 'C' -- 'Completed'