Votre modèle de données pour le traitement des retours et des remboursements
Votre modèle de données pour le traitement des retours et des remboursements
- Attributs recommandés à collecter
- Activités clés à suivre
- Conseils pour l’extraction
Attributs du traitement des retours et remboursements
| Nom | Description | ||
|---|---|---|---|
| Heure de l’événement EventTime | Horodatage précis indiquant le moment où une activité donnée s’est produite. | ||
| Description L’heure de l’événement enregistre la date et l’heure auxquelles un événement métier a été enregistré dans le système. Cet horodatage est essentiel pour ordonner les activités chronologiquement et réaliser toutes les analyses temporelles. Dans le Process Mining, cet attribut sert à calculer les temps de cycle entre les activités, à mesurer la durée de chaque étape et à analyser la performance du processus dans le temps. Il constitue la base de l’identification des goulots d’étranglement, du suivi du respect des SLA et de la compréhension de la dynamique temporelle du processus de retour. Pourquoi c’est important Cet horodatage est essentiel pour ordonner les événements, calculer toutes les durées et tous les temps de cycle et identifier les retards du processus. Où les obtenir Provient généralement des champs de date et d’heure associés à la création des 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 de la date de comptabilisation (BUDAT) des documents comptables. Exemples 2023-10-26T10:05:00Z2023-10-27T14:30:15Z2023-10-28T09:00:00Z | |||
| Identifiant du dossier de retour ReturnCaseId | Identifiant unique d’un processus de retour client, reliant toutes les activités associées, du lancement à la clôture. | ||
| Description L’identifiant du dossier de retour est l’identifiant principal qui regroupe tous les événements et activités associés à une même instance de retour. Chaque demande de retour client reçoit un identifiant unique, ce qui permet de suivre l’ensemble du processus de bout en bout. Dans le Process Mining, cet attribut est fondamental pour reconstituer le flux du processus. Il permet d’analyser la durée des dossiers, les variantes de processus et les goulots d’étranglement en reliant des événements distincts, tels que « Return Request Initiated », « Goods Received » et « Refund Processed », au sein d’une chronologie cohérente pour chaque retour. Pourquoi c’est important Il s’agit de la clé essentielle pour suivre un retour du début à la fin et réaliser toutes les analyses au niveau du dossier, notamment le calcul du temps de cycle et la découverte des variantes de processus. Où les obtenir Il s’agit généralement du numéro du document de vente (VBELN) issu de la table d’en-tête des commandes de retour VBAK, dans laquelle la catégorie de document (VBTYP) indique un retour. Exemples 600001896000019060000191 | |||
| Nom de l’activité ActivityName | Nom d’une activité métier ou d’un événement précis survenu dans le processus de retour et de remboursement. | ||
| Description Cet attribut décrit une étape ou un jalon du cycle de vie des retours. Les activités représentent le travail effectué, par exemple « Return Order Approved » ou « Item Inspection Completed ». Elles sont déduites des changements de statut, de la création de documents ou d’actions utilisateur précises enregistrées dans SAP S/4HANA. L’analyse de la séquence et de la fréquence de ces activités constitue le cœur du Process Mining. Elle permet de visualiser la cartographie du processus, d’identifier les parcours fréquents et rares et de repérer les activités souvent répétées, signe de reprises ou d’inefficacités. Pourquoi c’est important Les activités constituent la structure du processus et permettent de visualiser et d’analyser son flux, ses goulots d’étranglement et ses variations. Où les obtenir Les noms des activités sont généralement déduits d’une combinaison de données, notamment des changements de statut des documents dans des tables telles que VBUK/VBUP, des événements de création dans des tables d’en-tête comme VBAK (documents de vente) et BKPF (documents comptables), ainsi que des statuts de mouvements de marchandises dans MSEG. Exemples Demande de retour initiéeMarchandises reçues dans l’entrepôtAvoir crééRemboursement traité | |||
| Dernière mise à jour des données LastDataUpdateTimestamp | Horodatage indiquant la date de la dernière actualisation ou extraction des données associées à cet événement. | ||
| 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 l’actualité du jeu de données analysé. Il est important pour évaluer la fraîcheur de l’analyse de Process Mining. Les utilisateurs peuvent vérifier l’actualité des données, ce qui est particulièrement pertinent pour le suivi opérationnel et les Dashboards qui surveillent les dossiers en cours. Pourquoi c’est important Indique la fraîcheur des données, un élément essentiel pour garantir que les analyses et les Dashboards reposent sur des informations à jour. Où les obtenir Cette valeur est généralement générée et apposée au jeu de données lors de l’extraction par l’outil ETL ou le pipeline de données. Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z | |||
| Identifiant du système source SourceSystemId | Identifiant du système source à partir duquel les données ont été extraites. | ||
| Description Cet attribut indique le système de référence à l’origine des données d’événements. Pour ce processus, il s’agit généralement de l’identifiant de l’instance SAP S/4HANA. Dans les environnements comportant plusieurs systèmes, ce champ est essentiel à la traçabilité des données, au dépannage et au maintien de leur intégrité. Il permet de distinguer les données lorsque les retours sont traités dans plusieurs instances ERP ou intégrés à des systèmes externes, comme un système de gestion d’entrepôt. Pourquoi c’est important Fournit un contexte important sur l’origine et la traçabilité des données, en particulier dans les environnements multisystèmes, afin de garantir leur suivi et leur fiabilité. Où les 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, notamment l’identifiant système (SID). Exemples S4H_PROD_100S4Q_DEV_200 | |||
| Heure de fin de l’événement EventEndTime | Horodatage marquant la fin d’une activité, utilisé pour calculer sa durée. | ||
| Description Alors que StartTime (EventTime) marque le début d’une activité, EventEndTime en indique la fin. Pour de nombreux événements générés par le système, les heures de début et de fin sont identiques, car il s’agit d’événements instantanés. En revanche, pour les activités ayant une durée mesurable, comme « Item Inspection », cet attribut est essentiel. Il permet de calculer directement le temps de traitement de l’activité. Il est fondamental pour l’analyse de la performance, car il aide à identifier les étapes précises, et pas seulement les intervalles entre elles, qui consomment le plus de temps. Pourquoi c’est important Permet de calculer précisément la durée de chaque activité, ce qui est essentiel pour repérer les inefficacités au sein des différentes étapes du processus. Où les obtenir Cette valeur est souvent dérivée. Pour certaines activités, elle peut provenir d’un champ distinct. Le plus souvent, elle correspond à l’heure de début de l’activité suivante du dossier. Exemples 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| Identifiant du client CustomerId | Identifiant unique du client à l’origine du retour. | ||
| Description Cet attribut identifie le client ayant demandé le retour. Il relie l’instance du processus à une partie précise des données de base clients. L’analyse des retours par client permet d’identifier certains comportements, notamment les clients présentant un taux de retour inhabituellement élevé, ce qui peut signaler une fraude ou une insatisfaction. Elle permet également de segmenter le processus de retour selon le type, la valeur ou l’historique du client et d’adapter ainsi les niveaux de service. Pourquoi c’est important Relie les retours à des clients précis et permet d’analyser leur comportement, de les segmenter et d’identifier les clients effectuant fréquemment des retours. Où les obtenir Se trouve dans le champ du numéro de client (KUNNR) de la table d’en-tête des commandes de retour (VBAK). Exemples CUST-001234CUST-005678CUST-009012 | |||
| Identifiant du produit ProductId | Identifiant unique de l’article retourné. | ||
| Description Cet attribut indique le matériel ou le produit concerné par le retour. Il relie le processus de retour à un article précis du catalogue produit. L’analyse des retours par produit est fondamentale pour identifier les articles présentant un taux de retour élevé, ce qui peut révéler des défauts de qualité, des descriptions insuffisantes 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 de stock. Pourquoi c’est important Relie le processus de retour à des produits précis et permet d’analyser les taux de retour au niveau de l’article ainsi que d’identifier les problèmes de qualité ou de description. Où les obtenir Se trouve dans le champ du numéro de matériel (MATNR) de la table des postes de commandes de retour (VBAP) ou de la table des postes de livraisons de retour (LIPS). Exemples FG-10023HW-45981SW-LICENSE-PREM | |||
| Montant du remboursement RefundAmount | Montant monétaire final du remboursement versé au client. | ||
| Description Cet attribut représente le montant effectivement 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’un indicateur financier important pour différentes analyses. Il est indispensable au Dashboard « Refund Amount Discrepancy Analysis », qui permet de comparer le montant remboursé au montant demandé. Il permet également de segmenter les retours par valeur afin de déterminer si les retours de montant élevé suivent un parcours différent ou nécessitent davantage de temps pour ê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 montant élevé et comprendre les coûts globaux. Où les obtenir Provient du champ de valeur nette (NETWR) du document d’avoir, présent dans des tables telles que VBRK (en-tête du document de facturation) ou BSEG (poste du document comptable). Exemples 125.50999.0049.99 | |||
| Motif du retour ReturnReason | Motif indiqué par le client pour retourner l’article. | ||
| Description Cet attribut enregistre le motif déclaré par le client, par exemple « Defective Item », « Wrong Size » ou « No Longer Needed ». Il est généralement sélectionné dans une liste prédéfinie de codes motif lors du lancement du retour. L’analyse des motifs de retour est essentielle pour identifier les problèmes de qualité des produits, améliorer les descriptions ou perfectionner les processus de vente. Elle fournit une indication directe de l’insatisfaction client et aide à hiérarchiser les améliorations à apporter afin de réduire le taux global de retour. Pourquoi c’est important Fournit des informations importantes sur les causes des retours et permet d’analyser les causes racines liées à la qualité des produits, aux erreurs de préparation ou aux écarts entre les attentes des clients et l’offre. Où les obtenir Est généralement stocké dans la table des postes de commandes de vente 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 de l’utilisateur UserName | Identifiant de l’utilisateur ayant exécuté l’activité. | ||
| Description Cet attribut identifie l’utilisateur ou l’agent système responsable de l’exécution d’une tâche, par exemple l’approbation d’un retour ou la création d’un avoir. Dans SAP, cette information est souvent enregistrée dans les champs qui indiquent l’utilisateur ayant créé ou modifié un document. L’analyse par utilisateur permet d’identifier les personnes ou équipes les plus performantes, les besoins de formation et la répartition de la charge de travail. Elle est également essentielle pour examiner les écarts, car elle relie les actions du processus à des personnes précises et contribue ainsi aux exigences de conformité et d’audit. Pourquoi c’est important Associe les activités du processus à des utilisateurs précis et permet d’analyser la performance des équipes, la charge de travail et la conformité. Où les obtenir Se trouve généralement dans les tables d’en-tête des documents, par exemple dans ERNAM (créé par) de VBAK (commandes de vente), LIKP (livraisons) et BKPF (documents comptables). Les informations utilisateur peuvent être enrichies à partir de la table des utilisateurs USR21. Exemples CBROWNASMITHWF_BATCH | |||
| Agent chargé du traitement ProcessingAgent | Agent ou groupe de Ressources précisément responsable du traitement d’une activité manuelle. | ||
| Description Cet attribut identifie la personne ou l’équipe ayant exécuté une tâche donnée. Il peut être plus précis que le « Nom de l’utilisateur » en faisant référence à un rôle ou à une équipe, notamment dans un environnement de services partagés. Il est utile au Dashboard « Refund Approval Efficiency » pour analyser la performance de différents agents ou équipes. Il permet de comprendre la répartition de la charge de travail, d’identifier les besoins de formation et de repérer les personnes ou équipes les plus performantes susceptibles de partager leurs bonnes pratiques. Pourquoi c’est important Permet d’analyser la performance au niveau de l’agent ou de l’équipe, de gérer la charge de travail, d’identifier les besoins de formation et d’améliorer l’efficacité. Où les obtenir Ces informations peuvent être disponibles dans les fonctions de SAP Business Partner lorsque des agents sont affectés, ou être déduites du service ou du rôle de l’utilisateur dans la structure organisationnelle RH. Exemples Support de niveau 1Équipe d'inspection de l'entrepôtService financier, comptabilité fournisseurs | |||
| Date cible du SLA de remboursement RefundSlaTargetDate | Date cible à laquelle le remboursement du dossier de retour doit être traité. | ||
| Description Cet attribut définit l’échéance du Service Level Agreement (SLA) applicable au traitement du remboursement. Cette date est généralement calculée selon des 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 constitue la base du Dashboard « Refund SLA Adherence Monitoring » et du KPI associé. Il permet de suivre de manière proactive les dossiers susceptibles de dépasser leur SLA et d’analyser les causes racines des retards, afin d’améliorer la satisfaction client. Pourquoi c’est important Fournit la référence nécessaire pour mesurer la conformité aux SLA, suivre la performance, prioriser les dossiers anciens et améliorer la satisfaction client. Où les obtenir Il s’agit presque toujours d’un champ dérivé. La logique repose sur une date de référence, par exemple la date de création de la demande de retour, à laquelle s’ajoute une durée définie par les règles métier, qui peut dépendre de facteurs tels que le type de client ou le motif du retour. Exemples 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z | |||
| Est automatisé IsAutomated | Indicateur précisant si une activité a été exécutée par un système ou par une personne. | ||
| Description Cet attribut booléen distingue les activités exécutées automatiquement par un système, comme un flux de travail ou une tâche en arrière-plan, de celles réalisées manuellement par un utilisateur. Il est essentiel pour calculer le KPI « Automated Refund Approval Rate » et identifier les possibilité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 apporterait les bénéfices les plus importants en matière de rapidité, de coûts et de précision. Pourquoi c’est important Distingue les tâches manuelles des tâches automatisées et permet d’identifier les possibilités d’automatisation et de mesurer les effets de la transformation numérique. Où les obtenir Est généralement déduit du nom de l’utilisateur. Par exemple, si l’utilisateur est « WF_BATCH » ou un autre identifiant système, l’activité est marquée comme automatisée. Exemples truefalse | |||
| Est une reprise IsRework | Indicateur précisant si une activité d’un cas constitue la répétition d’une activité précédente. | ||
| Description Cet attribut booléen calculé identifie les reprises, lorsqu’une activité est exécutée plusieurs fois dans un même cas. Par exemple, lorsqu’une inspection d’article doit être répétée ou lorsqu’un avoir est créé, annulé, puis recréé. Cet attribut est essentiel au Dashboard « Refund Processing Rework Analysis » et au KPI « Refund Rework Rate ». Il permet de quantifier les inefficacités du processus en mettant en évidence les activités sujettes aux erreurs ou nécessitant plusieurs tentatives, et d’identifier les domaines qui requièrent de meilleurs contrôles ou une formation complémentaire. Pourquoi c’est important Met en évidence les inefficacités et les erreurs du processus en signalant les tâches répétées, afin de cibler les améliorations et de réduire les pertes de temps ainsi que les retards. Où les obtenir Cet indicateur est généralement calculé par l’outil de Process Mining lui-même ou en amont, lors de la transformation des données. Il vérifie si le même nom d’activité est déjà apparu plus tôt dans le même cas. Exemples truefalse | |||
| Identifiant de la politique de retour ReturnPolicyId | Identifiant de la politique de retour applicable à ce dossier précis. | ||
| Description Cet attribut indique la politique de retour ou l’ensemble de règles applicable à la transaction. Les politiques peuvent varier selon le type de produit, le segment client ou le délai écoulé depuis l’achat. Ces données sont essentielles au Dashboard « Return Policy Compliance Overview ». En associant chaque dossier à une politique, le système peut vérifier automatiquement le respect des règles, telles que les délais de retour ou les exigences relatives à l’état de l’article, et signaler les écarts à analyser. Pourquoi c’est important Permet de vérifier automatiquement la conformité aux règles métier et contribue à garantir un traitement cohérent des retours, conformément à la politique applicable. Où les obtenir Il ne s’agit souvent pas d’un champ SAP standard et sa valeur doit être déduite à partir de règles métier utilisant des données telles que le type de produit, le client et la date de vente. Elle peut être stockée dans un champ personnalisé si cette fonctionnalité a été mise en place. Exemples STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Montant du remboursement demandé RequestedRefundAmount | Montant du remboursement initialement demandé ou prévu au début du processus. | ||
| Description Cet attribut enregistre la valeur des marchandises retournées selon la demande de retour initiale. Il sert de référence pour comparer le montant finalement remboursé. Ce champ est spécifiquement requis pour le Dashboard « Refund Amount Discrepancy Analysis ». La comparaison entre le montant demandé et le montant effectivement remboursé permet d’identifier les écarts, par exemple les remboursements partiels dus à un article endommagé, à des frais de remise en stock ou à d’autres ajustements, et de garantir l’exactitude et la transparence financières. Pourquoi c’est important Sert de référence pour mesurer l’exactitude des remboursements et identifier et analyser les écarts entre les montants prévus et les montants effectivement remboursés. Où les obtenir Provient généralement de la valeur nette des articles de la commande de vente de retour initiale. Il s’agit de la valeur nette (NETWR) des postes correspondants dans la table VBAP. Exemples 125.501050.0049.99 | |||
| Numéro de l’avoir CreditMemoNumber | Identifiant unique du document d’avoir autorisant 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 correspond au numéro unique de ce document financier. Le suivi du numéro de l’avoir est essentiel pour analyser le règlement financier du processus de retour. Il marque une étape importante, déclenche souvent le paiement effectif du remboursement et est nécessaire au rapprochement financier et aux audits. Pourquoi c’est important Représente la transaction financière officielle du remboursement. Il est essentiel pour suivre les dernières étapes du processus et réaliser les audits financiers. Où les obtenir Il s’agit du numéro du document de facturation (VBELN) issu de la table d’en-tête des documents de facturation (VBRK), dans laquelle la catégorie de document indique un avoir. Exemples 900003459000034690000347 | |||
| Numéro de livraison de retour ReturnDeliveryNumber | 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 correspond au numéro unique de ce document. Cet identifiant est important pour suivre le déplacement physique des marchandises retournées. Il relie les aspects financiers et logistiques du retour et permet d’analyser en détail les phases de réception et d’inspection des marchandises. Pourquoi c’est important Établit un lien essentiel entre la commande de retour et la réception physique des marchandises, indispensable à l’analyse des délais de traitement logistique et en entrepôt. Où les obtenir Il s’agit du numéro du document de livraison (VBELN) issu de la table d’en-tête des livraisons (LIKP), dans laquelle la catégorie de document indique une livraison de retour. Exemples 840000128400001384000014 | |||
| Organisation commerciale SalesOrganization | Unité organisationnelle responsable de la vente d’origine et du retour. | ||
| Description L’organisation commerciale est un élément clé de la structure organisationnelle de SAP. Elle représente l’unité responsable de la vente et de la distribution des produits et services et est associée à la transaction de retour. Cet attribut permet de filtrer et de comparer le processus de retour entre différentes unités, régions ou divisions. Il aide à déterminer si certaines organisations commerciales présentent des taux de retour plus élevés ou des processus de traitement moins efficaces et fournit ainsi une base pour analyser la performance organisationnelle. Pourquoi c’est important Permet de comparer la performance et les taux du processus de retour entre différentes unités, régions ou canaux de vente. Où les obtenir Se trouve dans le champ de l’organisation commerciale (VKORG) de la table d’en-tête des commandes de retour (VBAK). Exemples 10002100US01 | |||
| Respect de la politique de retours ReturnPolicyAdherence | Indicateur précisant si le dossier 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 par la politique applicable. La logique peut vérifier, par exemple, si le retour a été lancé dans le délai autorisé ou si le motif du retour est valide pour le produit. Cet attribut contribue directement au Dashboard « Return Policy Compliance Overview ». Il permet de quantifier les taux de conformité et d’examiner les dossiers non conformes afin de comprendre les motifs des écarts et de faire respecter les politiques plus efficacement. Pourquoi c’est important Quantifie la conformité aux règles métier et aide à identifier et à réduire les violations des politiques susceptibles de diminuer la rentabilité ou de créer des exceptions dans le processus. Où les obtenir Calculé à partir des règles métier. Par exemple, (Date d’initiation du retour - Date d’achat initiale) <= [Nombre de jours autorisés pour le retour]. Cela nécessite la Date d’achat initiale et les règles de la politique. Exemples truefalse | |||
| Respect du SLA de remboursement RefundSlaAdherence | Indicateur précisant si le remboursement a été traité dans le délai cible défini par le Service Level Agreement (SLA). | ||
| Description Cet attribut calculé vérifie si l’activité « Refund Processed » a eu lieu à la date cible du SLA de remboursement ou avant celle-ci. Il fournit, pour chaque cas, un indicateur simple de respect ou de non-respect du SLA. Il s’agit de la métrique principale du Dashboard « Refund SLA Adherence Monitoring » et du KPI « Refund SLA Adherence Rate ». Elle permet de mesurer la performance par rapport aux engagements pris envers les clients et d’identifier les cas qui n’ont pas répondu aux attentes, afin d’analyser les causes profondes des retards. Pourquoi c’est important Mesure directement la performance par rapport aux engagements pris envers les clients, ce qui en fait un indicateur important de la qualité de service et de la satisfaction client. Où les obtenir Calculé en comparant l’EventTime de l’activité « Refund Processed » à la « RefundSlaTargetDate » de chaque cas. Exemples truefalse | |||
| Résultat de l’inspection de l’article ItemInspectionOutcome | Résultat de l’inspection physique de l’article retourné. | ||
| Description Cet attribut enregistre le résultat du processus d’inspection réalisé après la réception des marchandises dans l’entrepôt. Les résultats courants comprennent « Accepted », « Rejected - Damaged » ou « Accepted - Resalable ». Ces données fournissent un contexte important pour les étapes suivantes du processus. Elles déterminent si un remboursement intégral, partiel ou aucun remboursement est accordé. L’analyse de ce résultat permet d’identifier les motifs de rejet et peut fournir des indications sur l’emballage des produits ou les partenaires de transport lorsque les articles sont fréquemment endommagés pendant le transport. Pourquoi c’est important Explique le processus de décision qui sous-tend l’approbation ou le rejet des remboursements et fournit des informations utiles sur l’état des articles et les motifs des ajustements de remboursement. Où les obtenir Ces informations peuvent être enregistrées dans un lot d’inspection du module de gestion de la qualité (QM), ou sous la forme d’un statut ou d’un code motif sur le poste de la livraison de retour (LIPS). Elles peuvent également figurer dans un champ personnalisé. Exemples Accepté, revendableAccepté, à remettre à neufRejeté, dommage imputable au clientRejeté, article incorrect retourné | |||
| Statut de la commande de retour ReturnOrderStatus | Statut global actuel du dossier de retour. | ||
| Description Cet attribut fournit, à un moment donné, une vue synthétique du statut du dossier de retour, par exemple « Open », « In Process » ou « Closed ». Il s’agit souvent d’un statut agrégé déduit du dernier jalon majeur terminé. Il est essentiel au Dashboard « Current Return Case Status Dashboard », qui offre une vue opérationnelle de la charge de travail et de la répartition actuelles des dossiers. Il aide les responsables à comprendre combien de dossiers se trouvent à chaque étape du processus et à mieux affecter les Ressources et gérer la charge de travail. Pourquoi c’est important Fournit une vue instantanée de la position de chaque dossier dans le processus, ce qui est essentiel aux Dashboards opérationnels qui suivent la charge de travail et les statuts actuels. Où les obtenir Est déduit des champs de statut des documents concernés. Par exemple, du statut d’en-tête (GBSTK) ou du statut de poste (LFSTK) de la commande de vente associée (VBUK/VBUP) ou des documents de livraison. Exemples En attente de réception des marchandisesInspection en attenteRemboursement en attenteClôturé | |||
Activités de traitement des retours et remboursements
| Activité | Description | ||
|---|---|---|---|
| Avoir créé | Il s’agit de la création du document de facturation officiel qui crédite le compte du client pour l’article retourné. Cet événement explicite est capturé lorsque l’avoir est généré à partir de la demande d’avoir. | ||
| Pourquoi c’est important La création de l’avoir constitue une étape financière importante. Elle confirme le montant à rembourser et autorise le lancement du processus de paiement. Où les obtenir Capturé lors de la création d’un document de facturation dans la table VBRK, avec une catégorie de document indiquant un avoir. Celui-ci est lié à la demande d’avoir dans la table VBFA. Collecte L’événement est enregistré lors de la sauvegarde d’un nouveau document de facturation d’avoir, par exemple avec la transaction VF01. Type d’événement explicit | |||
| Contrôle de l’article terminé | Cette activité correspond à la fin du contrôle qualité et de l’évaluation de l’état des marchandises retournées. Dans Advanced Returns Management, il s’agit souvent d’une étape explicite qui enregistre le résultat du contrôle et détermine l’action suivante, comme un remboursement ou une mise au rebut. | ||
| Pourquoi c’est important La durée et le résultat du contrôle influent directement sur le délai de traitement du remboursement et sur la gestion des stocks. Cette activité est essentielle pour analyser l’efficacité des contrôles et les reprises. Où les obtenir Dans SAP Advanced Returns Management (ARM), il peut s’agir d’un événement explicite issu de la transaction de contrôle. L’événement peut également être déduit d’un changement de statut du poste de la commande de retour indiquant le résultat du contrôle. Collecte L’événement est enregistré à partir des journaux de transactions ou des changements de statut liés aux activités de suivi logistique dans ARM. Type d’événement explicit | |||
| Demande d’avoir créée | Après une inspection concluante, cette activité indique la création d’une demande d’émission d’un avoir au client. Elle est enregistrée sous la forme d’un nouveau document de vente, une demande d’avoir faisant référence à la commande de retour d’origine. | ||
| Pourquoi c’est important Cette étape déclenche le règlement financier du processus de retour. L’analyse du délai entre l’inspection et cette étape permet d’évaluer l’efficacité du transfert entre la logistique et la finance. Où les obtenir Capturé lors de la création d’un document de vente dans la table VBAK, avec une catégorie de document correspondant à une demande d’avoir. Le lien avec le retour est conservé dans la table de flux de documents VBFA. Collecte 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 | Il s’agit du point de départ du processus de retour, lorsque la commande de retour est officiellement créée dans le système. Cet événement est enregistré 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. Analyser le délai entre cet événement et la clôture est essentiel pour mesurer la durée globale du cycle de retour et l’expérience client. Où les obtenir Il s’agit d’un événement explicite enregistré lors de la création d’un document de vente dans la table VBAK, lorsque la catégorie de document (VBAK-VBTYP) indique une commande de retour. L’horodatage de création est VBAK-ERDAT. Collecte L’événement est enregistré lors de la sauvegarde d’une nouvelle commande de vente de retour, par exemple avec la transaction VA01. Type d’événement explicit | |||
| Dossier de retour clôturé | Il s’agit de l’activité finale, qui indique que le processus de retour est terminé et qu’aucune autre action n’est attendue pour le dossier. Elle est généralement déduite lorsque le document de commande de retour atteint un statut final et clôturé dans le système. | ||
| Pourquoi c’est important Cet événement définit la fin du cycle de vie du processus et permet de calculer sa durée totale de bout en bout. Il confirme que le dossier a été entièrement résolu. Où les obtenir Déduit du statut global de la commande de retour dans la table VBAK ou du statut de ses postes dans VBAP, lorsqu’il atteint l’état « Complete » ou « Closed ». Cette détermination dépend de la configuration de la gestion des statuts du système. Collecte Déduit du passage du statut du document de commande de retour à « Complete ». Type d’événement inferred | |||
| Marchandises reçues dans l’entrepôt | Cet événement marque la réception physique de l’article retourné dans l’entrepôt ou le centre de traitement. Il est enregistré explicitement lorsqu’un Post Goods Receipt (PGR) est exécuté pour la livraison de retour, ce qui crée un document matière. | ||
| Pourquoi c’est important Il s’agit d’un jalon essentiel qui déclenche le délai de contrôle et de décision d’affectation. Les retards antérieurs à ce point sont imputables au client, tandis que ceux qui surviennent ensuite relèvent de l’organisation interne. Où les obtenir L’événement est enregistré à partir des tables de documents matière MSEG et MKPF pour le type de mouvement de réception associé aux retours. La date de comptabilisation (MKPF-BUDAT) indique le moment de l’événement. Collecte L’événement correspond à la comptabilisation d’une réception 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 : le crédit financier est lettré, ce qui signifie que le paiement a été envoyé au client. Elle est déduite de la création, dans le module financier, d’un document de lettrage soldant le crédit ouvert sur le compte du client. | ||
| Pourquoi c’est important C’est à ce moment que le client est effectivement remboursé. Le délai entre le lancement du retour et cette étape influence fortement la satisfaction client et constitue un indicateur important du respect des SLA. Où les obtenir Déduit des informations du document de lettrage dans la table des postes comptables BSEG. La date de lettrage (BSEG-AUGDT) du poste client associé à l’avoir indique la date de traitement du remboursement. Collecte Déduit du renseignement du champ de date de lettrage du document comptable associé à l’avoir. Type d’événement inferred | |||
| Commande d’échange créée | Cette activité représente une solution alternative : au lieu d’un remboursement, une nouvelle commande de vente est créée afin d’expédier un article de remplacement au client. Elle est enregistrée lorsqu’une nouvelle commande de vente faisant référence au retour d’origine est créée. | ||
| Pourquoi c’est important Cette activité permet de distinguer les retours donnant lieu à un remboursement de ceux donnant lieu à un échange, qui suivent des parcours différents et produisent des résultats différents pour le client. Elle est essentielle à l’analyse des variantes. Où les obtenir Capturé lors de la création d’un nouveau document de vente dans VBAK, lié à la commande de retour dans la table de flux de documents VBFA. Collecte L’événement est enregistré lors de la sauvegarde d’un nouveau document de commande de vente désigné comme remplacement. Type d’événement explicit | |||
| Commande de retour approuvée | Cette activité correspond à l’approbation ou à la libération officielle de la commande de retour, qui peut alors passer à l’étape suivante. Elle est généralement déduite d’un changement d’état au niveau de l’en-tête ou du poste du document de vente, indiquant que les blocages ont été levés. | ||
| 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 lors de la phase initiale d’autorisation du processus de retour. Où les obtenir L’événement est déduit des tables de gestion des statuts ou des champs de statut directement présents dans les tables VBAK ou VBAP. Une modification du statut de libération ou la suppression d’un blocage de livraison (VBAP-LIFSP) peut signaler une approbation. Collecte L’événement est déduit d’une modification des champs de statut de l’en-tête ou du poste 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 comptabilisé avec succès dans le module de comptabilité financière. Il crée les écritures correspondantes dans le grand livre et rend ainsi l’avoir officiel du point de vue comptable. | ||
| Pourquoi c’est important Cette activité confirme que l’avoir a été intégré au système financier. Le délai entre la création de l’avoir et sa comptabilisation peut révéler des problèmes dans l’interface entre la facturation et la finance. Où les obtenir Capturé lors de la création d’un en-tête de document dans la table comptable BKPF, lié à l’avoir dans VBRK (VBRK-BELNR). Collecte L’événement est enregistré lors de la comptabilisation réussie du document de facturation dans la comptabilité financière. Type d’événement explicit | |||
| Livraison de retour créée | Cette activité signale la création d’un document de livraison entrante utilisé pour gérer la réception physique des marchandises retournées. Le système l’enregistre explicitement lors de la création d’un document de livraison faisant référence à la commande de retour. | ||
| Pourquoi c’est important Cette étape constitue un jalon logistique important. Le délai entre l’approbation du retour et la création de la livraison met en évidence l’efficacité de la transmission des informations de retour à l’entrepôt ou au service réception. Où les obtenir L’événement est enregistré lors de la création d’un en-tête de livraison dans la table LIKP, relié à la commande de retour précédente par la table de flux documentaire VBFA. Collecte L’événement est enregistré lors de la sauvegarde d’un nouveau document de livraison de retour, par exemple avec la transaction VL01N. Type d’événement explicit | |||
| Retour refusé | 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. L’événement est généralement enregistré lorsqu’un statut ou un code motif spécifique est appliqué au poste de la commande de retour après le contrôle. | ||
| Pourquoi c’est important Le suivi des rejets permet d’analyser la conformité aux politiques de retour et d’identifier les motifs courants de refus. Il s’agit d’un chemin d’exception important du processus. Où les obtenir Déduit de la présence d’un motif de rejet (VBAP-ABGRU) sur le poste de la commande de retour ou de l’attribution d’un statut spécifique pendant le processus d’inspection dans Advanced Returns Management. Collecte Déduit de la définition d’un motif de rejet ou de l’attribution d’un statut spécifique « rejected » au poste du document de retour. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Vérifier les 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 Core Data Services (CDS) requises. Les principales vues sont I_SalesDocument, I_SalesDocumentItem, I_SDDocumentFlow, I_DeliveryDocument, I_MaterialDocumentHeader, I_BillingDocument, I_JournalEntry et I_ClearedItem.
- Accéder à l’outil de requête : connectez-vous à votre client SQL ou à votre outil d’intégration de données habituel, connecté à la base de données SAP S/4HANA. Il peut s’agir d’outils SAP tels que SAP Analytics Cloud ou d’une plateforme ETL tierce.
- Définir les paramètres de la requête : avant l’exécution, modifiez la requête SQL fournie. Repérez les valeurs génériques et remplacez-les par les paramètres appropriés à votre environnement. Cela inclut [Start Date], [End Date], [Your Source System ID], [Your Return Order Type] ainsi que les autres filtres relatifs aux types de documents ou aux codes société.
- Exécuter la requête d’extraction : copiez la requête SQL complète et exécutez-la dans votre outil. Elle rassemble toutes les activités spécifiées dans un même jeu de données en réunissant les résultats de plusieurs instructions SELECT.
- Comprendre la logique de la requête : chaque bloc
SELECTde la structureUNION ALLextrait une activité précise. Il joint plusieurs vues CDS pour réunir les attributs requis, attribue une chaîne fixe àActivityNameet sélectionne l’horodatage pertinent pourEventTime. - Examiner les données brutes : une fois la requête terminée, effectuez une vérification rapide du résultat. Contrôlez que le nombre de lignes est cohérent et que les colonnes clés telles que
ReturnCaseId,ActivityNameetEventTimesont renseignées comme prévu. - Transformer les données : la requête produit un Event Log au format plat. Aucune transformation structurelle importante n’est généralement nécessaire. Vous devrez toutefois peut-être adapter les formats d’horodatage ou les types de données selon les exigences de votre système cible.
- Exporter l’Event Log : exportez le résultat de la requête au format CSV. Vérifiez que le fichier utilise l’encodage UTF-8 afin d’éviter les problèmes de caractères, notamment dans les noms d’utilisateurs ou les descriptions de produits.
- Importer dans l’outil de Process Mining : le fichier CSV obtenu peut maintenant être importé dans votre plateforme de Process Mining, telle que ProcessMind. Associez les colonnes du fichier aux champs correspondants de l’outil, par exemple
ReturnCaseIdà Case ID,ActivityNameà Activity etEventTimeà Timestamp.
Configuration
- Prérequis : l’utilisateur qui exécute la requête doit disposer des autorisations d’affichage pour les objets liés aux documents commerciaux (VBAK), aux livraisons (LIKP), à la facturation (VBRK) et à la comptabilité (BSEG, BKPF). L’accès aux vues CDS sous-jacentes est indispensable.
- Filtres sur le périmètre des données : il est essentiel de filtrer la requête selon des types de documents précis afin d’isoler le processus de retour. Configurez les valeurs génériques correspondant aux types de commandes de retour, par exemple « RE », aux types de demandes d’avoir, par exemple « G2 », et aux types de commandes d’échange, par exemple « SO ». Il est également vivement recommandé de filtrer selon
CompanyCodeouSalesOrganizationafin de limiter le périmètre des données. - Filtrage par période : pour maîtriser les performances et le volume de données, appliquez toujours un filtre de période. Commencez par une période récente de 3 à 6 mois. La requête utilise la date de création de la commande de retour initiale (
I_SalesDocument.CreationDate) comme condition de filtrage principale. - Considérations relatives aux performances : cette requête complète joint plusieurs vues CDS volumineuses. Son exécution peut mobiliser fortement les ressources du système source S/4HANA. Planifiez l’extraction en dehors des heures de pointe afin de limiter son impact. Pour les volumes très importants, envisagez une stratégie de chargement incrémental.
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érifiez que l’accès direct en lecture au schéma SAP HANA contenant les données pertinentes de ventes, de livraisons, de facturation, de documents articles, d’inspection, de statuts et de comptabilité est disponible. Le schéma, les vues et les noms de champs exacts varient selon le déploiement SAP S/4HANA. Remplacez donc chaque élément générique entre crochets par les objets et les champs configurés dans votre système.
- Définissez le périmètre d’extraction à l’aide de [Start date], [End date], [Company Code filter] et [Return document type filter]. Pour l’extraction initiale, utilisez une période glissante de trois à six mois et ne l’étendez qu’après avoir validé les performances et l’exhaustivité des données.
- Identifiez la population des commandes de retour dans [Your sales document header table] et [Your sales document item table]. Limitez cette population aux types de documents de commande de retour configurés dans [Your return order document type configuration]. Conservez le numéro et le numéro de poste de la commande de retour comme clés de liaison principales vers les documents en aval.
- Reconstituez le flux documentaire entre les commandes de retour, les livraisons de retour entrantes, les demandes d’avoir, les commandes d’échange et les avoirs à l’aide de [Your document flow table or view]. Ne supposez pas que le flux documentaire est stocké dans VBAK ou VBAP. Configurez les champs de relation selon le modèle de flux documentaire utilisé dans le système.
- Extrayez les événements explicites de création à partir des enregistrements pertinents d’en-tête et de poste. Extrayez les événements d’approbation, de rejet, d’inspection, de clôture, de réception de marchandises, de comptabilisation et de lettrage à partir des sources configurées de statuts, d’inspection, de documents articles, de comptabilité et de lettrage. Chaque activité doit être produite sous la forme d’une ligne d’événement distincte, car ProcessMind ne déduit pas les événements.
- Normalisez les horodatages dans un type d’horodatage et un fuseau horaire cohérents. Utilisez la priorité d’horodatage configurée pour chaque activité. Si seules une date et une heure sont disponibles, combinez-les en utilisant le fuseau horaire système configuré dans [Your system time zone].
- Renseignez ReturnCaseId pour chaque événement. Utilisez le numéro de la commande de retour d’origine ou l’identifiant de cas de retour configuré si Advanced Returns Management stocke une clé de cas distincte. Les événements qui ne peuvent pas être associés à un cas de retour doivent être exclus ou placés dans un résultat d’exception à traiter.
- Renseignez les colonnes obligatoires ReturnCaseId, ActivityName, EventTime, SourceSystemId et LastDataUpdateTimestamp. Renseignez également les colonnes recommandées lorsqu’elles sont disponibles, notamment EventEndTime, UserName, ReturnReason, RefundAmount, ProductId et CustomerId. Conservez une ligne par occurrence d’activité et n’agrégez pas les activités dans une seule ligne par cas.
- Validez le résultat à l’aide des contrôles définis dans validationSteps. Vérifiez que les douze noms d’activité sont présents, que les horodatages suivent un ordre plausible dans chaque cas et que les références documentaires concordent avec les tables sources.
- Exportez le résultat au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Conservez les noms de colonnes exacts, utilisez une seule ligne d’en-tête, gardez les horodatages dans un format ISO non ambigu et importez l’Event Log en configurant ReturnCaseId comme identifiant de cas et ActivityName comme colonne d’activité.
Configuration
- Période : commencez par trois à six mois. Utilisez les paramètres [Start date] et [End date] et incluez suffisamment d’historique pour couvrir les cas initiés avant la période sélectionnée mais terminés pendant celle-ci.
- Population des retours : filtrez selon les types de documents de commande de retour configurés dans [Your return order document type configuration]. Ne codez pas en dur un type de document sans l’avoir vérifié dans le système cible.
- Filtres organisationnels : appliquez [Company Code filter], l’organisation commerciale, le canal de distribution, la division, le site ou les filtres client uniquement lorsque cela est nécessaire. Vérifiez que ces filtres n’excluent pas les documents de suivi intersociétés ou intragroupe.
- Objets sources : remplacez les éléments génériques [Your table name] et [Your view name] par les tables SAP S/4HANA ou les vues CDS approuvées. VBAK, VBAP, VBRK et VBRP peuvent être disponibles dans le déploiement, mais leur utilisation et leurs extensions doivent être vérifiées avant l’exécution.
- Gestion des horodatages : configurez les champs d’horodatage sources et le fuseau horaire pour chaque activité. Stockez EventTime et EventEndTime de manière cohérente, de préférence en UTC ou dans le fuseau horaire ProcessMind convenu.
- Interprétation des statuts : configurez précisément les valeurs de statut, les codes motif, les résultats d’inspection et les indicateurs de clôture qui représentent l’approbation, le rejet, la fin de l’inspection et la clôture du cas dans le système.
- Identifiant du système source : remplacez [Source system identifier] par une valeur stable, telle que l’identifiant du système SAP utilisé par la plateforme d’extraction.
- Horodatage de l’actualisation : remplacez [Extraction timestamp] par l’horodatage du début de l’exécution de la requête ou de la création de l’instantané source. Utilisez la même valeur pour toutes les lignes d’une même exécution, sauf si des horodatages au niveau de la ligne sont nécessaires.
- Performances : limitez la population initiale des retours avant de joindre les sources volumineuses de flux documentaires, de comptabilité, de documents articles et de statuts. Utilisez des champs indexés ou permettant l’élagage des partitions, évitez les analyses sans restriction et ne matérialisez les résultats intermédiaires qu’après approbation de l’administrateur de base de données.
- Extraction incrémentale : pour les exécutions récurrentes, utilisez [Last successful extraction timestamp] et une fenêtre de chevauchement contrôlée afin de prendre en compte les mises à jour tardives. Dédupliquez à l’aide de ReturnCaseId, ActivityName, de la clé du document source et d’EventTime.
- Autorisations et prérequis : obtenez les autorisations de lecture pour tous les objets et champs sources configurés, l’autorisation d’accès direct à la base de données et la confirmation que les composants SAP requis ainsi que les fonctions Advanced Returns Management sont actifs, le cas échéant.
- Protection des données : limitez les données client et financières au strict nécessaire, respectez les règles internes de protection des données et sécurisez les fichiers exportés.
a Exemple de requête sql
WITH
parameters AS (
SELECT
CAST('[Start date]' AS TIMESTAMP) AS start_ts,
CAST('[End date]' AS TIMESTAMP) AS end_ts,
CAST('[Extraction timestamp]' AS TIMESTAMP) AS extraction_ts,
CAST('[Source system identifier]' AS NVARCHAR(100)) AS source_system_id
FROM DUMMY
),
return_orders AS (
SELECT
h.[Return order number] AS return_case_id,
i.[Return order item number] AS return_item_id,
h.[Return order creation timestamp] AS return_created_ts,
h.[Return order creator] AS return_creator,
h.[Customer number] AS customer_id,
i.[Product number] AS product_id,
i.[Return reason] AS return_reason,
i.[Return order quantity] AS return_quantity,
h.[Company code] AS company_code,
h.[Return order document type] AS return_document_type
FROM [Your sales document header table] h
INNER JOIN [Your sales document item table] i
ON h.[Sales document number] = i.[Sales document number]
CROSS JOIN parameters p
WHERE h.[Return order creation timestamp] >= p.start_ts
AND h.[Return order creation timestamp] < p.end_ts
AND h.[Return order document type] IN ([Your return order document type filter])
AND h.[Company code] IN ([Company Code filter])
),
document_flow AS (
SELECT
ro.return_case_id,
ro.return_item_id,
f.[Preceding document number] AS preceding_document_id,
f.[Preceding item number] AS preceding_item_id,
f.[Subsequent document number] AS subsequent_document_id,
f.[Subsequent item number] AS subsequent_item_id,
f.[Subsequent document category] AS subsequent_document_category,
f.[Document flow creation timestamp] AS flow_created_ts
FROM return_orders ro
LEFT JOIN [Your document flow table or view] f
ON f.[Preceding document number] = ro.return_case_id
AND f.[Preceding item number] = ro.return_item_id
),
return_delivery AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS delivery_id,
df.subsequent_item_id AS delivery_item_id,
d.[Delivery creation timestamp] AS delivery_created_ts,
d.[Delivery creator] AS delivery_creator,
d.[Delivery completion timestamp] AS delivery_completed_ts
FROM document_flow df
INNER JOIN [Your delivery header table] d
ON d.[Delivery number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Inbound delivery document category]'
),
credit_memo_requests AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_request_id,
df.subsequent_item_id AS credit_memo_request_item_id,
c.[Credit memo request creation timestamp] AS request_created_ts,
c.[Credit memo request creator] AS request_creator
FROM document_flow df
INNER JOIN [Your credit memo request header table] c
ON c.[Credit memo request number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo request document category]'
),
exchange_orders AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS exchange_order_id,
df.subsequent_item_id AS exchange_order_item_id,
e.[Exchange order creation timestamp] AS exchange_created_ts,
e.[Exchange order creator] AS exchange_creator
FROM document_flow df
INNER JOIN [Your exchange order header table] e
ON e.[Exchange order number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Exchange order document category]'
),
credit_memos AS (
SELECT
df.return_case_id,
df.return_item_id,
df.subsequent_document_id AS credit_memo_id,
df.subsequent_item_id AS credit_memo_item_id,
b.[Credit memo creation timestamp] AS credit_memo_created_ts,
b.[Credit memo creator] AS credit_memo_creator,
b.[Credit memo amount] AS refund_amount,
b.[Accounting document number] AS accounting_document_id,
b.[Company code] AS billing_company_code
FROM document_flow df
INNER JOIN [Your billing document header table] b
ON b.[Billing document number] = df.subsequent_document_id
WHERE df.subsequent_document_category = '[Credit memo document category]'
),
approval_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Approval timestamp] AS event_ts,
s.[Approval user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your approved or released status values])
),
inspection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Inspection completion timestamp] AS event_ts,
q.[Inspection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection status] IN ([Your completed inspection status values])
),
rejection_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
q.[Rejection timestamp] AS event_ts,
q.[Rejection user] AS user_name
FROM return_orders ro
INNER JOIN [Your return inspection table or view] q
ON q.[Return order number] = ro.return_case_id
AND q.[Return order item number] = ro.return_item_id
WHERE q.[Inspection outcome or rejection code] IN ([Your rejection reason values])
),
goods_receipt_events AS (
SELECT
rd.return_case_id,
rd.return_item_id,
m.[Goods receipt posting timestamp] AS event_ts,
m.[Goods receipt posting user] AS user_name
FROM return_delivery rd
INNER JOIN [Your material document header table] m
ON m.[Reference delivery number] = rd.delivery_id
INNER JOIN [Your material document item table] mi
ON mi.[Material document number] = m.[Material document number]
AND mi.[Material document item number] = [Your material document item linkage]
WHERE m.[Goods movement type] IN ([Your goods receipt movement type values])
),
accounting_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
a.[Accounting posting timestamp] AS event_ts,
a.[Accounting user] AS user_name
FROM credit_memos cm
INNER JOIN [Your accounting document header table] a
ON a.[Accounting document number] = cm.accounting_document_id
AND a.[Company code] = cm.billing_company_code
WHERE a.[Accounting document status] IN ([Your posted accounting status values])
),
refund_events AS (
SELECT
cm.return_case_id,
cm.return_item_id,
cl.[Clearing timestamp] AS event_ts,
cl.[Clearing user] AS user_name
FROM credit_memos cm
INNER JOIN [Your customer clearing table or view] cl
ON cl.[Cleared accounting document number] = cm.accounting_document_id
WHERE cl.[Clearing status] IN ([Your completed clearing status values])
),
closure_events AS (
SELECT
ro.return_case_id,
ro.return_item_id,
s.[Closure timestamp] AS event_ts,
s.[Closure user] AS user_name
FROM return_orders ro
INNER JOIN [Your return status table or view] s
ON s.[Return order number] = ro.return_case_id
AND s.[Return order item number] = ro.return_item_id
WHERE s.[Status code] IN ([Your final closed status values])
),
events AS (
SELECT ro.return_case_id, ro.return_item_id, 'Return Request Initiated' AS activity_name, ro.return_created_ts AS event_time, CAST(NULL AS TIMESTAMP) AS event_end_time, ro.return_creator AS user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)) AS refund_amount, ro.product_id, ro.customer_id FROM return_orders ro
UNION ALL
SELECT ae.return_case_id, ae.return_item_id, 'Return Order Approved', ae.event_ts, CAST(NULL AS TIMESTAMP), ae.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM approval_events ae INNER JOIN return_orders ro ON ro.return_case_id = ae.return_case_id AND ro.return_item_id = ae.return_item_id
UNION ALL
SELECT rd.return_case_id, rd.return_item_id, 'Return Delivery Created', rd.delivery_created_ts, rd.delivery_completed_ts, rd.delivery_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM return_delivery rd INNER JOIN return_orders ro ON ro.return_case_id = rd.return_case_id AND ro.return_item_id = rd.return_item_id
UNION ALL
SELECT gr.return_case_id, gr.return_item_id, 'Goods Received at Warehouse', gr.event_ts, CAST(NULL AS TIMESTAMP), gr.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM goods_receipt_events gr INNER JOIN return_orders ro ON ro.return_case_id = gr.return_case_id AND ro.return_item_id = gr.return_item_id
UNION ALL
SELECT ie.return_case_id, ie.return_item_id, 'Item Inspection Completed', ie.event_ts, CAST(NULL AS TIMESTAMP), ie.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM inspection_events ie INNER JOIN return_orders ro ON ro.return_case_id = ie.return_case_id AND ro.return_item_id = ie.return_item_id
UNION ALL
SELECT re.return_case_id, re.return_item_id, 'Return Rejected', re.event_ts, CAST(NULL AS TIMESTAMP), re.user_name, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM rejection_events re INNER JOIN return_orders ro ON ro.return_case_id = re.return_case_id AND ro.return_item_id = re.return_item_id
UNION ALL
SELECT cr.return_case_id, cr.return_item_id, 'Credit Memo Request Created', cr.request_created_ts, CAST(NULL AS TIMESTAMP), cr.request_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM credit_memo_requests cr INNER JOIN return_orders ro ON ro.return_case_id = cr.return_case_id AND ro.return_item_id = cr.return_item_id
UNION ALL
SELECT eo.return_case_id, eo.return_item_id, 'Exchange Order Created', eo.exchange_created_ts, CAST(NULL AS TIMESTAMP), eo.exchange_creator, ro.return_reason, CAST(NULL AS DECIMAL(19,2)), ro.product_id, ro.customer_id FROM exchange_orders eo INNER JOIN return_orders ro ON ro.return_case_id = eo.return_case_id AND ro.return_item_id = eo.return_item_id
UNION ALL
SELECT cm.return_case_id, cm.return_item_id, 'Credit Memo Created', cm.credit_memo_created_ts, CAST(NULL AS TIMESTAMP), cm.credit_memo_creator, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM credit_memos cm INNER JOIN return_orders ro ON ro.return_case_id = cm.return_case_id AND ro.return_item_id = cm.return_item_id
UNION ALL
SELECT ac.return_case_id, ac.return_item_id, 'Accounting Document Created', ac.event_ts, CAST(NULL AS TIMESTAMP), ac.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM accounting_events ac INNER JOIN return_orders ro ON ro.return_case_id = ac.return_case_id AND ro.return_item_id = ac.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ac.return_case_id AND cm.return_item_id = ac.return_item_id
UNION ALL
SELECT rf.return_case_id, rf.return_item_id, 'Refund Processed', rf.event_ts, CAST(NULL AS TIMESTAMP), rf.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM refund_events rf INNER JOIN return_orders ro ON ro.return_case_id = rf.return_case_id AND ro.return_item_id = rf.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = rf.return_case_id AND cm.return_item_id = rf.return_item_id
UNION ALL
SELECT ce.return_case_id, ce.return_item_id, 'Return Case Closed', ce.event_ts, CAST(NULL AS TIMESTAMP), ce.user_name, ro.return_reason, cm.refund_amount, ro.product_id, ro.customer_id FROM closure_events ce INNER JOIN return_orders ro ON ro.return_case_id = ce.return_case_id AND ro.return_item_id = ce.return_item_id LEFT JOIN credit_memos cm ON cm.return_case_id = ce.return_case_id AND cm.return_item_id = ce.return_item_id
)
SELECT
e.return_case_id AS "ReturnCaseId",
e.activity_name AS "ActivityName",
e.event_time AS "EventTime",
e.event_end_time AS "EventEndTime",
e.user_name AS "UserName",
e.return_reason AS "ReturnReason",
e.refund_amount AS "RefundAmount",
e.product_id AS "ProductId",
e.customer_id AS "CustomerId",
p.source_system_id AS "SourceSystemId",
p.extraction_ts AS "LastDataUpdateTimestamp"
FROM events e
CROSS JOIN parameters p
WHERE e.event_time IS NOT NULL
ORDER BY e.return_case_id, e.event_time, e.activity_name; Prêt à commencer ?
Avec ce modèle, vous disposez des connaissances fondamentales nécessaires pour extraire et analyser les données de votre traitement des retours et des remboursements. Commencez dès aujourd’hui votre démarche vers l’excellence des processus.
Optimisez dès maintenant le traitement des retours et remboursements dans SAP S/4HANA
Identifiez les inefficacités, réduisez le temps de cycle de 30 % et améliorez la satisfaction.
Aucune carte bancaire requise. Commencez votre optimisation dès aujourd’hui.