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 à recueillir
- Activités clés à suivre
- Conseils pour l’extraction des données
Attributs du traitement des retours et des remboursements
| Nom | Description | ||
|---|---|---|---|
| Date et heure de l’événement EventTime | Horodatage précis indiquant le moment où une activité donnée s’est produite. | ||
| Description La date et l’heure de l’événement correspondent au moment où 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 les performances du processus au fil du temps. Il permet de repérer les goulots d’étranglement, de suivre le respect des SLA et de comprendre la dynamique temporelle du processus de retour. Pourquoi est-ce important ? Cet horodatage est essentiel pour ordonner les événements, calculer les durées et les temps de cycle, et repérer les retards dans le processus. Où trouver ces données Les données proviennent généralement des champs de date et d’heure associés à la création d’un document ou à un changement de statut, comme ERDAT (date de création) et ERZET (heure de création) dans des tables telles que VBAK, LIKP et BKPF, ou de 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 | Identifiant unique d’un processus de retour client, qui relie toutes les activités associées, du lancement à la clôture. | ||
| Description L’ID du dossier de retour est l’identifiant principal qui regroupe tous les événements et toutes les activités associés à un même retour. Chaque demande de retour client reçoit un ID unique, qui permet de suivre l’ensemble du processus de bout en bout. Dans le Process Mining, cet attribut est essentiel pour reconstituer le flux du processus. Il permet d’analyser la durée des dossiers, les variantes du processus et les goulots d’étranglement en reliant des événements distincts, comme « Demande de retour créée », « Marchandises reçues » et « Remboursement traité », dans une chronologie cohérente pour chaque retour. Pourquoi est-ce important ? Cet identifiant est indispensable pour suivre un retour de bout en bout et réaliser toutes les analyses au niveau du dossier, notamment le calcul du temps de cycle et la découverte des variantes du processus. Où trouver ces données Il s’agit généralement du numéro de document commercial (VBELN) figurant dans la table d’en-tête des commandes de retour VBAK, où la catégorie du 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 au cours du processus de retour et de remboursement. | ||
| Description Cet attribut décrit une étape ou un jalon du cycle de vie d’un retour. Les activités correspondent au travail effectué, par exemple « Commande de retour approuvée » ou « Inspection de l’article terminée ». Elles sont déduites des changements de statut, de la création de documents ou d’actions précises des utilisateurs enregistrées dans SAP S/4HANA. L’analyse de l’ordre et de la fréquence de ces activités est au cœur du Process Mining. Elle permet de visualiser la cartographie du processus, de repérer les parcours courants et rares, et de mettre en évidence les activités souvent répétées, signe de reprises ou d’inefficacités. Pourquoi est-ce important ? Les activités constituent la base de la cartographie du processus. Elles permettent de visualiser et d’analyser le flux du processus, ses goulots d’étranglement et ses variantes. Où trouver ces données Les noms des activités sont généralement établis à partir de plusieurs sources : les changements de statut des documents dans des tables comme VBUK/VBUP, les événements de création dans les tables d’en-tête comme VBAK (documents commerciaux) et BKPF (documents comptables), ainsi que les statuts des mouvements de marchandises dans MSEG. Exemples Demande de retour crééeMarchandises reçues à l’entrepôtAvoir crééRemboursement traité | |||
| Dernière mise à jour des données LastDataUpdateTimestamp | Horodatage indiquant la dernière actualisation ou extraction des données de cet événement. | ||
| Description Cet attribut indique la date et l’heure de la dernière extraction ou mise à jour des données. Il fournit des métadonnées sur leur fraîcheur dans le jeu de données analysé. Il permet de savoir si l’analyse du Process Mining repose sur des données récentes. Les utilisateurs peuvent vérifier leur actualité, un point particulièrement important pour le suivi opérationnel et les Dashboards qui suivent les dossiers en cours. Pourquoi est-ce important ? Cet attribut indique si les données sont à jour, afin que les analyses et les Dashboards reposent sur des informations récentes. Où trouver ces données Cet horodatage est généralement généré et ajouté au jeu de données au moment de l’extraction par l’outil ETL ou le 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 à partir duquel les données ont été extraites. | ||
| Description Cet attribut indique le système d’enregistrement d’où proviennent les données de l’événement. Pour ce processus, il s’agit généralement de l’ID de l’instance SAP S/4HANA. Dans les environnements qui comptent plusieurs systèmes, ce champ est essentiel pour assurer la traçabilité des données, faciliter le dépannage et garantir leur intégrité. Il permet de distinguer les données lorsque les retours sont traités dans plusieurs instances ERP ou en lien avec des systèmes externes, comme un système de gestion d’entrepôt. Pourquoi est-ce important ? Cet attribut précise l’origine et la traçabilité des données, notamment dans les environnements comportant plusieurs systèmes, et permet d’en garantir le suivi et la fiabilité. Où trouver ces données Cette valeur est généralement statique et configurée lors de l’extraction des données. Elle peut être récupérée dans les informations d’administration du système SAP, par exemple 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é et permettant d’en calculer la 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 ils sont instantanés. Cet attribut est toutefois essentiel pour les activités dont la durée peut être mesurée, comme « Inspection de l’article ». Il permet de calculer directement la durée de traitement d’une activité. C’est une base importante pour l’analyse des performances : vous pouvez repérer les étapes qui prennent le plus de temps, et pas seulement les intervalles entre elles. Pourquoi est-ce important ? Cet attribut permet de calculer précisément la durée de chaque activité et de repérer les inefficacités propres à certaines étapes du processus. Où trouver ces données Cette valeur est souvent déduite. Certaines activités disposent d’un champ distinct, mais le plus souvent, elle correspond à StartTime de l’activité suivante dans le dossier. Exemples 2023-10-26T11:25:30Z2023-10-27T15:00:00Z2023-10-28T09:10:45Z | |||
| ID du client CustomerId | Identifiant unique du client à l’origine du retour. | ||
| Description Cet attribut identifie le client qui a 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 de repérer des tendances, par exemple un taux de retour inhabituellement élevé, qui peut signaler un comportement frauduleux ou une insatisfaction. Elle permet aussi de segmenter le processus de retour selon le type de client, sa valeur ou son historique, afin d’adapter le niveau de service. Pourquoi est-ce important ? Cet attribut relie les retours à des clients précis et permet d’analyser leur comportement, de les segmenter et de repérer ceux qui effectuent souvent des retours. Où trouver ces données Cette information figure 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 | |||
| ID du produit ProductId | Identifiant unique de l’article retourné. | ||
| Description Cet attribut indique la matière ou le produit faisant l’objet du retour. Il relie le processus de retour à un article précis du catalogue de produits. L’analyse des retours par produit est essentielle pour repérer les articles dont le taux de retour est élevé, ce qui peut signaler des défauts de qualité, une description insuffisante 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 est-ce important ? Cet attribut relie le processus de retour à des produits précis. Il permet d’analyser les taux de retour par article et de repérer les problèmes de qualité ou de description. Où trouver ces données Cette information figure dans le champ du numéro de matière (MATNR) de la table des postes de commande de retour (VBAP) ou de la table des postes de livraison de retour (LIPS). Exemples FG-10023HW-45981SW-LICENSE-PREM | |||
| Montant du remboursement RefundAmount | Montant final remboursé au client. | ||
| Description Cet attribut correspond au montant effectivement crédité ou remboursé au client à la fin du processus de retour. Cette valeur figure dans les documents financiers, comme les avoirs. Il s’agit d’une métrique financière importante pour différentes analyses. Le Dashboard « Analyse des écarts de montant des remboursements » s’en sert pour comparer le montant remboursé au montant demandé. Il permet aussi de répartir les retours par valeur afin de déterminer si les retours de montant élevé suivent un parcours différent ou prennent plus de temps à être résolus. Pourquoi est-ce important ? Cet attribut mesure l’incidence financière des retours. Il est essentiel pour analyser l’exactitude des remboursements, repérer les dossiers de montant élevé et comprendre les coûts globaux. Où trouver ces données La valeur provient du champ de valeur nette (NETWR) du document d’avoir, dans des tables comme 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 le retour de l’article. | ||
| Description Cet attribut indique le motif du retour déclaré par le client, par exemple « Article défectueux », « Taille incorrecte » ou « N’est plus nécessaire ». Le motif est généralement choisi dans une liste prédéfinie de codes lors du lancement du retour. L’analyse des motifs de retour est essentielle pour repérer les problèmes de qualité des produits, améliorer leur description ou revoir les processus de vente. Elle renseigne directement sur l’insatisfaction des clients et aide à déterminer les améliorations à apporter pour réduire le taux global de retour. Pourquoi est-ce important ? Cet attribut aide à comprendre les raisons des retours et à en rechercher les causes profondes, qu’il s’agisse de problèmes de qualité, d’erreurs de préparation ou d’un décalage entre les attentes des clients et les produits. Où trouver ces données Cette information est généralement stockée dans le champ ABGRU (motif de rejet des documents commerciaux) de la table des postes de commande de retour (VBAP). Exemples 001 - Qualité insuffisante002 - Endommagé pendant le transport005 - Article expédié incorrect | |||
| Nom de l’utilisateur UserName | ID de l’employé qui a exécuté l’activité. | ||
| Description Cet attribut identifie l’utilisateur ou l’agent système qui a effectué une tâche, par exemple l’approbation d’un retour ou la création d’un avoir. Dans SAP, cette information figure souvent dans les champs qui enregistrent l’utilisateur ayant créé ou modifié un document. L’analyse par utilisateur permet de repérer les personnes ou les équipes les plus performantes, les besoins de formation et la répartition de la charge de travail. Elle est également essentielle à l’examen des écarts, car elle relie les actions du processus à des personnes précises et facilite les contrôles de conformité et les audits. Pourquoi est-ce important ? Cet attribut relie les activités du processus à des utilisateurs précis et permet d’analyser les performances des équipes, la charge de travail et la conformité. Où trouver ces données Cette information figure généralement dans les tables d’en-tête des documents, par exemple dans ERNAM (créé par) pour VBAK (commandes commerciales), LIKP (livraisons) et BKPF (documents comptables). Les détails des utilisateurs peuvent être complétés à partir de la table des données de base des utilisateurs USR21. Exemples CBROWNASMITHWF_BATCH | |||
| Agent de traitement ProcessingAgent | Agent ou groupe de ressources chargé d’effectuer une activité manuelle. | ||
| Description Cet attribut désigne la personne ou l’équipe qui a effectué une tâche. Il peut être plus précis que « Nom d’utilisateur » en indiquant un rôle ou une équipe, notamment dans un environnement de services partagés. Il permet au tableau de bord « Efficacité de l’approbation des remboursements » de comparer les résultats des différents agents ou équipes. Vous pouvez ainsi comprendre la répartition de la charge de travail, repérer les besoins de formation et identifier les personnes ou équipes les plus performantes, ainsi que les bonnes pratiques à partager. Pourquoi est-ce important ? Permet d’analyser les résultats par agent ou par équipe, de gérer la charge de travail, de repérer les besoins de formation et d’améliorer l’efficacité. Où trouver ces données Ces informations peuvent être disponibles dans les fonctions SAP Business Partner si des agents y sont affectés. Elles peuvent aussi être déduites du service ou du rôle de l’utilisateur dans la structure organisationnelle des ressources humaines. Exemples Assistance de niveau 1Équipe d’inspection de l’entrepôtService financier, comptabilité fournisseurs | |||
| Comporte des reprises IsRework | Indique si une activité du dossier répète une activité précédente. | ||
| Description Cet attribut booléen calculé repère les reprises, c’est-à-dire les activités effectuées plusieurs fois dans un même dossier. Par exemple, une inspection d’article répétée ou un avoir créé, annulé, puis recréé. Cet attribut est essentiel au tableau de bord « Analyse des reprises dans le traitement des remboursements » et à l’indicateur clé de performance « Taux de reprises des remboursements ». Il permet de mesurer les inefficacités du processus en mettant en évidence les activités sujettes aux erreurs ou nécessitant plusieurs tentatives, et de repérer celles qui demandent de meilleurs contrôles ou une formation complémentaire. Pourquoi est-ce important ? Met en évidence les inefficacités et les erreurs en signalant les tâches répétées, afin de cibler les améliorations et de réduire les pertes de temps et les retards. Où trouver ces données Cet indicateur est généralement calculé par l’outil de Process Mining ou en amont, lors de la transformation des données. Il vérifie si le même nom d’activité est déjà apparu dans le dossier. Exemples truefalse | |||
| Date limite de remboursement selon le SLA RefundSlaTargetDate | Date à laquelle le remboursement du dossier de retour doit avoir été traité. | ||
| Description Cet attribut définit l’échéance de l’accord de niveau de service (SLA) pour le 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 sert de référence au tableau de bord « Suivi du respect des SLA de remboursement » et à l’indicateur clé de performance associé. Il permet de repérer à l’avance les dossiers susceptibles de dépasser leur échéance et d’analyser les causes des retards, afin d’améliorer la satisfaction client. Pourquoi est-ce important ? Fournit une référence pour mesurer le respect des SLA, suivre les résultats, traiter en priorité les dossiers en attente depuis longtemps et améliorer la satisfaction client. Où trouver ces données Il s’agit presque toujours d’un champ calculé. 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. Cette durée 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 | Indique si une activité a été effectué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, par exemple un flux de travail ou une tâche en arrière-plan, de celles effectuées manuellement par un utilisateur. Il est essentiel au calcul de l’indicateur clé de performance « Taux d’approbation automatisée des remboursements » et permet de repérer les possibilités d’automatisation. En filtrant les tâches manuelles, les entreprises peuvent concentrer leurs efforts d’amélioration sur les activités où l’automatisation aurait le plus d’effet sur les délais, les coûts et la précision. Pourquoi est-ce important ? Distingue les tâches manuelles des tâches automatisées, ce qui permet de repérer les possibilités d’automatisation et de mesurer les effets de la transformation numérique. Où trouver ces données Cette valeur est généralement déduite du nom d’utilisateur. Par exemple, si l’utilisateur est « WF_BATCH » ou un autre identifiant système, l’activité est considérée comme automatisée. Exemples truefalse | |||
| Identifiant de la politique de retour ReturnPolicyId | Identifiant de la politique de retour applicable à ce dossier. | ||
| 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 de clientèle ou le délai écoulé depuis l’achat. Ces données sont essentielles pour le tableau de bord « Vue d’ensemble de la conformité aux politiques de retour ». En associant chaque dossier à une politique, le système peut vérifier automatiquement le respect des règles, par exemple les délais de retour ou l’état requis des articles, et signaler les écarts à analyser. Pourquoi est-ce important ? Permet de vérifier automatiquement le respect des règles métier, afin que les retours soient traités de manière cohérente et conformément à la politique applicable. Où trouver ces données Il ne s’agit souvent pas d’un champ SAP standard. Sa valeur peut devoir être calculée à partir de règles métier et de données telles que le type de produit, le client et la date de vente. Si cette fonctionnalité est mise en place, la valeur peut être enregistrée dans un champ personnalisé. Exemples STD-30DAYELEC-90DAY-WARRANTYFINAL-SALE-DEFECT | |||
| Montant du remboursement demandé RequestedRefundAmount | Montant du remboursement demandé ou prévu au début du processus. | ||
| Description Cet attribut indique la valeur des marchandises retournées, telle qu’elle figure dans la demande de retour initiale. Il sert de référence pour la comparer au montant finalement remboursé. Ce champ est nécessaire au Dashboard « Analyse des écarts de montant des remboursements ». La comparaison du montant demandé et du montant effectivement remboursé permet de repérer les écarts dus, par exemple, à un remboursement partiel après détérioration de l’article, à des frais de remise en stock ou à d’autres ajustements, et de garantir l’exactitude et la transparence des opérations financières. Pourquoi est-ce important ? Sert de référence pour mesurer la précision des remboursements et repérer les écarts entre les montants attendus et les montants réellement remboursés. Où trouver ces données Cette valeur correspond généralement à la valeur nette des articles de la commande 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 d’avoir CreditMemoNumber | Identifiant unique du document d’avoir qui autorise le remboursement. | ||
| Description L’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 d’avoir est essentiel pour analyser le règlement financier du processus de retour. Il marque un jalon important, qui déclenche souvent le paiement du remboursement, et est nécessaire au rapprochement financier et aux audits. Pourquoi est-ce important ? Cet attribut représente la transaction financière officielle liée au remboursement. Il est essentiel pour suivre les dernières étapes du processus et réaliser les audits financiers. Où trouver ces données Il s’agit du numéro du document de facturation (VBELN) figurant dans la table d’en-tête des documents de facturation (VBRK), où la catégorie du 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, SAP crée un document de livraison de retour pour gérer la logistique entrante. Cet attribut correspond au numéro unique de ce document. Cet ID 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 étapes de réception des marchandises et d’inspection. Pourquoi est-ce important ? Cet attribut relie la commande de retour à la réception physique des marchandises. Il est essentiel pour analyser les délais de traitement logistique et en entrepôt. Où trouver ces données Il s’agit du numéro du document de livraison (VBELN) figurant dans la table d’en-tête des livraisons (LIKP), où la catégorie du document indique une livraison de retour. Exemples 840000128400001384000014 | |||
| Organisation commerciale SalesOrganization | Unité organisationnelle responsable de la vente initiale et du retour. | ||
| Description L’organisation commerciale est un élément clé de la structure organisationnelle de SAP. Elle représente une unité responsable de la vente et de la distribution de produits et de 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 opérationnelles, régions ou divisions. Il aide à déterminer si certaines organisations commerciales affichent des taux de retour plus élevés ou traitent les retours moins efficacement, et fournit ainsi une base pour analyser les performances de l’organisation. Pourquoi est-ce important ? Cet attribut permet de comparer les performances et les taux de retour entre différentes unités opérationnelles, régions ou canaux de vente. Où trouver ces données Cette information figure 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 retour ReturnPolicyAdherence | Indique si le dossier de retour respecte la politique de retour définie. | ||
| Description Cet attribut booléen calculé indique si un retour respecte les critères de la politique applicable. La logique peut vérifier, par exemple, si le retour a été demandé dans le délai autorisé ou si le motif est valable pour le produit concerné. Cet attribut contribue directement au tableau de bord « Vue d’ensemble de la conformité aux politiques de retour ». Il permet de mesurer le taux de conformité et d’examiner les dossiers non conformes pour comprendre les écarts et mieux faire respecter les politiques. Pourquoi est-ce important ? Mesure le respect des règles métier et aide à repérer et à réduire les infractions aux politiques susceptibles de nuire à la rentabilité ou de créer des exceptions dans le processus. Où trouver ces données Calculé selon les règles métier. Par exemple : (date de demande de retour - date d’achat initiale) <= [délai de retour autorisé]. Le calcul nécessite la date d’achat initiale et les règles de la politique. Exemples truefalse | |||
| Respect du SLA de remboursement RefundSlaAdherence | Indique si le remboursement a été traité dans le délai prévu par l’accord de niveau de service (SLA). | ||
| Description Cet attribut calculé vérifie si l’activité « Remboursement traité » a eu lieu au plus tard à la « Date limite de remboursement selon le SLA ». Il indique simplement si le SLA a été respecté pour chaque dossier. Il s’agit de la métrique principale du tableau de bord « Suivi du respect des SLA de remboursement » et de l’indicateur clé de performance « Taux de respect des SLA de remboursement ». Elle permet de mesurer les résultats au regard des engagements pris envers les clients et de repérer les dossiers qui n’ont pas répondu aux attentes, afin d’analyser les causes des retards. Pourquoi est-ce important ? Mesure directement le respect des engagements envers les clients et constitue un indicateur important de la qualité du service et de la satisfaction client. Où trouver ces données Calculé en comparant l’EventTime de l’activité « Remboursement traité » à la « RefundSlaTargetDate » de chaque dossier. Exemples truefalse | |||
| Résultat de l’inspection de l’article ItemInspectionOutcome | Résultat de l’inspection physique de l’article retourné. | ||
| Description Cet attribut consigne le résultat de l’inspection effectuée après la réception des marchandises à l’entrepôt. Les résultats possibles comprennent « Accepté, peut être revendu », « Refusé, endommagé » ou « Accepté, peut être remis en vente ». Ces données apportent un contexte essentiel aux étapes suivantes du processus. Elles déterminent si le remboursement est intégral, partiel ou refusé. L’analyse des résultats permet de comprendre les motifs de refus et peut fournir des indications sur l’emballage des produits ou les transporteurs, si les articles sont souvent endommagés pendant le transport. Pourquoi est-ce important ? Explique les décisions d’approbation ou de refus des remboursements et fournit des informations utiles sur l’état des articles et les motifs d’ajustement des remboursements. Où trouver ces données Ces informations peuvent être enregistrées dans un lot d’inspection du module de gestion de la qualité (QM), ou sous forme de statut ou de code motif dans le poste de livraison de retour (LIPS). Elles peuvent également figurer dans un champ personnalisé. Exemples Accepté, peut être revenduAccepté, à remettre en étatRefusé, article endommagé par le clientRefusé, article retourné incorrect | |||
| Statut de la commande de retour ReturnOrderStatus | Statut général actuel du dossier de retour. | ||
| Description Cet attribut indique le statut général du dossier de retour à un moment donné, par exemple « Ouvert », « En cours » ou « Clôturé ». Il s’agit souvent d’un statut agrégé, déduit de la dernière étape importante terminée. Il est essentiel au tableau de bord « Statut actuel des dossiers de retour », qui donne une vue opérationnelle de la charge de travail et de la répartition des dossiers. Les responsables peuvent voir combien de dossiers se trouvent à chaque étape du processus et mieux répartir les ressources et la charge de travail. Pourquoi est-ce important ? Indique où en est chaque dossier dans le processus. Cette information est essentielle aux tableaux de bord opérationnels qui suivent la charge de travail et les statuts en cours. Où trouver ces données 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 client associée (VBUK/VBUP) ou des documents de livraison. Exemples En attente de réception des marchandisesEn attente d’inspectionEn attente de remboursementClôturé | |||
Activités de traitement des retours et des remboursements
| Activité | Description | ||
|---|---|---|---|
| Avoir créé | Cette activité correspond à 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, enregistré lorsque l’avoir est généré à partir de la demande d’avoir. | ||
| Pourquoi est-ce important ? La création de l’avoir constitue un jalon financier important. Elle confirme le montant à rembourser et autorise le lancement du paiement. Où trouver ces données L’événement est enregistré lors de la création d’un document de facturation dans la table VBRK, dont la catégorie indique qu’il s’agit d’un avoir. Ce document est relié à la demande d’avoir dans la table VBFA. Données à recueillir L’événement est enregistré à l’enregistrement d’un nouveau document de facturation d’avoir (par exemple, avec la transaction VF01). Type d’événement explicit | |||
| Demande d’avoir créée | Après une inspection concluante, cette activité marque la création d’une demande d’avoir au client. Elle est enregistrée sous la forme d’un nouveau document commercial, la demande d’avoir, qui fait référence à la commande de retour d’origine. | ||
| Pourquoi est-ce 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ù trouver ces données L’événement est enregistré lors de la création d’un document commercial 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 documentaire VBFA. Données à recueillir L’événement est enregistré à l’enregistrement d’un nouveau document de demande d’avoir. Type d’événement explicit | |||
| Demande de retour créée | Le processus de retour commence lorsque la commande de retour est officiellement créée dans le système. Cet événement est enregistré explicitement à l’enregistrement d’un nouveau document commercial de type commande de retour dans SAP S/4HANA. | ||
| Pourquoi est-ce important ? Cette activité marque le début officiel du cycle de vie du dossier de retour. L’analyse du délai entre cet événement et la clôture est essentielle pour mesurer le temps de cycle global du retour et évaluer l’expérience client. Où trouver ces données Cet événement explicite est enregistré lors de la création d’un document commercial dans la table VBAK, lorsque la catégorie du document (VBAK-VBTYP) indique une commande de retour. L’horodatage de création est VBAK-ERDAT. Données à recueillir L’événement est enregistré à l’enregistrement d’une nouvelle commande commerciale de retour (par exemple, avec la transaction VA01). Type d’événement explicit | |||
| Dossier de retour clôturé | Cette dernière activité 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 du passage du document de commande de retour à un statut final de clôture dans le système. | ||
| Pourquoi est-ce important ? Cet événement marque la fin du cycle de vie du processus et permet de calculer le temps de cycle total de bout en bout. Il confirme que le dossier a été entièrement traité. Où trouver ces données L’événement est déduit du passage du statut global de la commande de retour dans la table VBAK, ou de ses postes dans VBAP, à l’état « Terminé » ou « Clôturé ». Le résultat dépend de la configuration de la gestion des statuts du système. Données à recueillir L’événement est déduit du passage du statut du document de commande de retour à « Terminé ». Type d’événement inferred | |||
| Inspection de l’article terminée | Cette activité correspond à la fin de l’évaluation de la qualité et de l’état des marchandises retournées. Dans Advanced Returns Management, il s’agit souvent d’une étape explicite qui consigne le résultat de l’inspection et détermine la suite, par exemple un remboursement ou une mise au rebut. | ||
| Pourquoi est-ce important ? La durée et le résultat de l’inspection ont une incidence directe sur le délai de traitement du remboursement et sur la gestion des stocks. Le suivi de cette activité est essentiel pour analyser l’efficacité des inspections et les reprises. Où trouver ces données Dans SAP Advanced Returns Management (ARM), cet événement peut être enregistré explicitement à partir de la transaction d’inspection. Il peut aussi être déduit d’un changement de statut du poste de la commande de retour indiquant le résultat de l’inspection. Données à recueillir 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 | |||
| 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 enregistré explicitement lors de la comptabilisation de l’entrée de marchandises (PGR) pour la livraison de retour, qui crée un document article. | ||
| Pourquoi est-ce important ? Ce jalon important marque le début du délai d’inspection et de traitement de l’article. Les retards qui le précèdent dépendent du client, tandis que ceux qui suivent relèvent de l’organisation. Où trouver ces données L’événement est enregistré dans les tables de documents article MSEG et MKPF pour le type de mouvement d’entrée de marchandises associé aux retours. La date de comptabilisation (MKPF-BUDAT) indique la date de l’événement. Données à recueillir 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 : l’avoir financier est soldé, ce qui signifie que le paiement a été envoyé au client. L’événement est déduit de la création, dans le module financier, d’un document de compensation qui solde l’avoir ouvert sur le compte du client. | ||
| Pourquoi est-ce important ? C’est à cette étape que le client reçoit effectivement son remboursement. Le délai entre le lancement du retour et cette étape influe fortement sur la satisfaction client et permet de mesurer le respect des SLA. Où trouver ces données L’événement est déduit des informations de compensation figurant dans la table des postes comptables BSEG. La date de compensation (BSEG-AUGDT) du poste client associé à l’avoir indique la date de traitement du remboursement. Données à recueillir L’événement est 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é correspond à une autre issue possible : au lieu d’un remboursement, une nouvelle commande commerciale est créée pour envoyer un article de remplacement au client. L’événement est enregistré lors de la création d’une nouvelle commande commerciale faisant référence au retour d’origine. | ||
| Pourquoi est-ce 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 n’aboutissent pas au même résultat pour le client. Elle est essentielle à l’analyse des variantes. Où trouver ces données L’événement est enregistré lors de la création d’un nouveau document commercial dans VBAK, relié à la commande de retour dans la table de flux documentaire VBFA. Données à recueillir L’événement est enregistré à l’enregistrement d’un nouveau document de commande commerciale 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 de statut de l’en-tête ou du poste du document commercial, indiquant la levée des blocages. | ||
| Pourquoi est-ce important ? Les étapes d’approbation peuvent entraîner des retards importants. Le suivi de cette activité permet de repérer les goulots d’étranglement lors de la phase initiale d’autorisation du processus de retour. Où trouver ces données L’événement est déduit des tables de gestion des statuts ou des champs de statut des tables VBAK ou VBAP. Un changement de statut de libération ou la suppression d’un blocage de livraison (VBAP-LIFSP) peut indiquer une approbation. Données à recueillir L’événement est déduit d’un changement des champs de statut de l’en-tête ou du poste de la commande de retour indiquant sa libération ou son 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 génère les écritures correspondantes dans le grand livre et officialise ainsi l’avoir sur le plan comptable. | ||
| Pourquoi est-ce 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 d’interface entre la facturation et la finance. Où trouver ces données L’événement est enregistré lors de la création d’un en-tête de document dans la table comptable BKPF, relié à l’avoir dans VBRK (VBRK-BELNR). Données à recueillir L’événement est enregistré lorsque le document de facturation est comptabilisé avec succès dans la comptabilité financière. Type d’événement explicit | |||
| Livraison de retour créée | Cette activité correspond à la création d’un document de livraison entrante, utilisé pour gérer la réception physique des marchandises retournées. Le système enregistre explicitement la création d’un document de livraison faisant référence à la commande de retour. | ||
| Pourquoi est-ce important ? Cette étape constitue un jalon logistique important. Le délai entre l’approbation du retour et la création de la livraison indique dans quelle mesure les informations sur le retour sont transmises efficacement à l’entrepôt ou au service de réception. Où trouver ces données 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. Données à recueillir L’événement est enregistré à l’enregistrement d’un nouveau document de livraison de retour (par exemple, avec la transaction VL01N). Type d’événement explicit | |||
| Retour refusé | Cet événement indique que l’article retourné ne répond pas aux critères de la politique de retour et que la demande de remboursement ou d’avoir a été refusée. Il est généralement enregistré par l’application d’un statut ou d’un code motif spécifique au poste de la commande de retour après l’inspection. | ||
| Pourquoi est-ce important ? Le suivi des refus permet d’analyser le respect des politiques de retour et de repérer les motifs de refus récurrents. Il s’agit d’un parcours d’exception important dans le processus. Où trouver ces données L’événement est déduit de la saisie d’un motif de refus (VBAP-ABGRU) sur le poste de la commande de retour ou de l’attribution d’un statut spécifique pendant l’inspection dans Advanced Returns Management. Données à recueillir L’événement est déduit de la saisie d’un motif de refus ou de l’attribution du statut spécifique « refusé » au poste du document de retour. Type d’événement inferred | |||
Guides d’extraction
Étapes
- Vérifiez les prérequis : assurez-vous que le compte utilisateur chargé de 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édez à l’outil de requête : connectez-vous au client SQL ou à l’outil d’intégration de données de votre choix, configuré pour se connecter à la base de données SAP S/4HANA. Il peut s’agir d’un outil SAP, comme SAP Analytics Cloud, ou d’une plateforme ETL tierce.
- Définissez les paramètres de la requête : avant de l’exécuter, modifiez la requête SQL fournie. Repérez les valeurs de remplacement et remplacez-les par les paramètres adaptés à votre environnement. Vous devez notamment renseigner
[Start Date],[End Date],[Your Source System ID],[Your Return Order Type]ainsi que les filtres relatifs aux autres types de documents ou aux codes société. - Exécutez la requête d’extraction : copiez la requête SQL complète et exécutez-la dans votre outil. Elle rassemble dans un même jeu de données les activités spécifiées, en combinant les résultats de plusieurs instructions SELECT.
- Comprenez la logique de la requête : chaque bloc
SELECTde la structureUNION ALLextrait une activité précise. Il joint plusieurs vues CDS pour récupérer les attributs requis, attribue une chaîne fixe àActivityNameet sélectionne l’horodatage correspondant àEventTime. - Examinez les données brutes : une fois la requête terminée, vérifiez rapidement les résultats. Assurez-vous que le nombre de lignes est cohérent et que les colonnes clés, comme
ReturnCaseId,ActivityNameetEventTime, sont renseignées comme prévu. - Transformez les données : la requête produit un journal d’événements à plat. En général, aucune transformation structurelle importante n’est nécessaire. Vous devrez peut-être toutefois adapter les formats d’horodatage ou les types de données aux exigences du système cible.
- Exportez le journal d’événements : exportez les résultats de la requête dans un fichier CSV. Vérifiez que le fichier est encodé en UTF-8 afin d’éviter les problèmes de caractères, notamment dans les noms d’utilisateur ou les descriptions de produits.
- Importez le fichier dans l’outil de Process Mining : le fichier CSV obtenu peut maintenant être importé dans votre plateforme de Process Mining, par exemple ProcessMind. Associez les colonnes du fichier aux champs correspondants dans l’outil, par exemple
ReturnCaseIdà ID de cas,ActivityNameà Activité etEventTimeà l’horodatage.
Configuration
- Prérequis : l’utilisateur chargé de l’extraction doit disposer d’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 indispensable.
- Filtres sur le périmètre des données : il est essentiel de filtrer la requête par types de documents afin d’isoler le processus de retour. Configurez les valeurs de remplacement 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'). Il est également vivement recommandé de filtrer par
CompanyCodeouSalesOrganizationpour 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 dates. Commencez par une période récente de 3 à 6 mois. La requête utilise comme filtre principal la date de création de la commande de retour initiale (
I_SalesDocument.CreationDate). - Performances : cette requête complète joint plusieurs vues CDS volumineuses. Son exécution peut solliciter fortement le système source S/4HANA. Planifiez l’extraction en dehors des heures de pointe pour limiter son impact. Pour les très grands jeux de données, envisagez une stratégie de chargement incrémentiel.
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 vous disposez d’un accès direct en lecture au schéma SAP HANA contenant les données pertinentes sur les ventes, les livraisons, la facturation, les documents articles, les inspections, les statuts et la comptabilité. Le schéma, les vues et les noms de champs varient selon le déploiement SAP S/4HANA. Remplacez donc chaque valeur entre crochets par les objets et champs configurés dans votre système.
- Définissez le périmètre de l’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. N’allongez cette période qu’après avoir vérifié les performances et l’exhaustivité des résultats.
- Identifiez les commandes de retour dans [Your sales document header table] et [Your sales document item table]. Limitez la sélection aux types de documents de commande de retour configurés dans [Your return order document type configuration]. Conservez le numéro de commande de retour et le numéro de poste comme clés principales de liaison avec les documents ultérieurs.
- Retracez le flux documentaire des commandes de retour vers 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 partez pas du principe 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 de création explicites à partir des en-têtes et des postes de documents concernés. Extrayez les événements d’approbation, de rejet, d’inspection, de clôture, de réception des marchandises, de comptabilisation et de lettrage à partir des sources configurées pour les statuts, les inspections, les documents articles, la comptabilité et le 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 en utilisant un type d’horodatage et un fuseau horaire cohérents. Pour chaque activité, appliquez l’ordre de priorité configuré pour les horodatages des événements. Si seule une date et une heure sont disponibles, combinez-les en utilisant le fuseau horaire système défini 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. Excluez les événements qui ne peuvent pas être associés à un cas de retour ou placez-les dans un fichier d’exception à traiter.
- Renseignez les colonnes obligatoires ReturnCaseId, ActivityName, EventTime, SourceSystemId et LastDataUpdateTimestamp. Si elles sont disponibles, renseignez également les colonnes recommandées, notamment EventEndTime, UserName, ReturnReason, RefundAmount, ProductId et CustomerId. Conservez une ligne par occurrence d’activité et ne regroupez pas les activités dans une seule ligne par cas.
- Validez les résultats à l’aide des contrôles de validation définis dans validationSteps. Vérifiez que les douze noms d’activité sont présents, que l’ordre des horodatages est plausible pour chaque cas et que les références aux documents concordent avec les tables sources.
- Exportez les résultats au format CSV UTF-8 ou dans un autre format tabulaire pris en charge par ProcessMind. Conservez les noms de colonnes exacts, une seule ligne d’en-tête et des horodatages au format ISO non ambigu. Importez le journal d’événements 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 prendre en compte les cas commencés avant la période sélectionnée, mais terminés pendant celle-ci.
- Population de retours : filtrez selon les types de documents de commande de retour configurés dans [Your return order document type configuration]. Ne définissez pas un type de document en dur sans l’avoir vérifié dans le système cible.
- Filtres organisationnels : appliquez les filtres [Company Code filter], organisation commerciale, canal de distribution, division, usine ou client uniquement si nécessaire. Vérifiez que ces filtres n’excluent pas les documents ultérieurs intersociétés ou entre sociétés.
- Objets sources : remplacez les valeurs de remplacement [Your table name] et [Your view name] par des tables SAP S/4HANA ou des 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 source 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 les valeurs de statut exactes, les codes de motif, les résultats d’inspection et les indicateurs de clôture qui correspondent, dans le système, à l’approbation, au rejet, à la fin de l’inspection et à la clôture du cas.
- Identifiant du système source : remplacez [Source system identifier] par une valeur stable, comme 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 extraction, sauf si un horodatage d’actualisation par ligne est nécessaire.
- Performances : limitez la population initiale de retours avant de joindre les sources volumineuses relatives au flux documentaire, à la comptabilité, aux documents articles et aux statuts. Utilisez des champs indexés ou permettant l’élagage des partitions, évitez les balayages sans restriction et ne matérialisez les résultats intermédiaires qu’avec l’accord de l’administrateur de la base de données.
- Extraction incrémentielle : 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 les résultats à l’aide de ReturnCaseId, ActivityName, de la clé du document source et de EventTime.
- Autorisations et prérequis : obtenez les autorisations de lecture pour tous les objets et champs sources configurés, l’approbation de l’accès direct à la base de données et la confirmation que les composants SAP requis et les fonctions Advanced Returns Management sont actifs, le cas échéant.
- Protection des données : limitez les champs relatifs aux clients et aux finances au strict nécessaire, respectez les règles de confidentialité de votre organisation et sécurisez les fichiers exportés.
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 ?
Ce modèle vous apporte les connaissances de base nécessaires pour extraire et analyser les données relatives au traitement des retours et des remboursements. Commencez dès aujourd’hui à améliorer vos processus.
Optimisez dès maintenant le traitement des retours et des remboursements dans SAP S/4HANA
Repérez les inefficacités, réduisez le temps de cycle de 30 % et améliorez la satisfaction.
Aucune carte bancaire n’est requise. Commencez à optimiser dès aujourd’hui.