> Amélioration continue des processus > Traitement des retours et des remboursements > SAP ECC > Modèle de données

Votre modèle de données pour le traitement des retours et des remboursements

SAP ECC

Attributs du traitement des retours et des remboursements (21) Activités liées au traitement des retours et des remboursements (12) Guides d’extraction (2)

Votre modèle de données pour le traitement des retours et des remboursements

Ce modèle vous guide dans la collecte des données nécessaires à l’analyse du traitement des retours et des remboursements. Il présente les attributs et les activités à suivre pour enregistrer tous les événements utiles et obtenir une vue complète du processus. Il vous indique également comment extraire ces données de votre système source. Vous pourrez ainsi préparer vos données pour le Process Mining et mieux comprendre le déroulement du processus.

Attributs recommandés à collecter
Activités clés à suivre
Guide d’extraction

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du traitement des retours et des remboursements

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail le traitement des retours et des remboursements.

5 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Date et heure exactes auxquelles l’activité a eu lieu.
Description Cet horodatage indique le moment précis où un événement métier s’est produit. Il est enregistré pour chaque activité du processus et fournit la séquence chronologique des événements d’un dossier. L’heure de l’événement est indispensable à toutes les analyses temporelles : calcul des temps de cycle entre les activités, repérage des goulots d’étranglement où les dossiers attendent et mesure de la durée totale de chaque dossier. Elle permet d’analyser la performance et de vérifier le respect des accords de niveau de service (SLA). Pourquoi est-ce important ? Cet horodatage est indispensable pour calculer les durées, analyser la performance du processus, repérer les goulots d’étranglement et comprendre le déroulement de chaque dossier de retour. Où trouver ces données Extrait de différents champs de date et d’heure des tables SAP. Pour les événements de création, il s’agit souvent des champs ERDAT et ERZET (par exemple dans VBAK). Pour les événements de modification, il s’agit des champs UDATE et UTIME de la table CDHDR. Exemples 2023-04-15T10:22:05Z2023-04-16T14:01:30Z2023-04-18T09:15:00Z
	ID du dossier de retour ReturnCaseId	Identifiant unique de la demande de retour d’un client, qui relie toutes les activités et tous les documents associés.
Description L’ID du dossier de retour sert de clé principale pour suivre tout le cycle de vie d’un retour, de son lancement à sa clôture. Chaque ID correspond à un retour client précis et regroupe tous les événements associés, comme la création de la commande, la livraison, l’inspection et le traitement de la note de crédit. Dans l’analyse des processus, cet attribut est indispensable à la création de la carte du processus. Il permet au système de regrouper les événements individuels en parcours de bout en bout, afin d’analyser les variantes du processus, les temps de cycle et les goulots d’étranglement pour chaque retour. Pourquoi est-ce important ? Cet identifiant de dossier relie toutes les étapes d’un retour et permet d’analyser le déroulement et la performance du processus de bout en bout. Où trouver ces données Il s’agit généralement du numéro de commande de retour du module Ventes et distribution (SD). Il se trouve dans la table VBAK (données d’en-tête du document de vente), dans le champ VBELN. La catégorie de document (VBAK-VBTYP) est « H » pour les retours. Exemples 600001236000045660000789
	Nom de l’activité ActivityName	Nom d’un événement ou d’une étape métier précis survenu au cours du processus de retour.
Description Cet attribut décrit une action ou un changement de statut précis dans le cycle de vie d’un retour, par exemple « Commande de retour créée », « Entrée de marchandises comptabilisée » ou « Note de crédit créée ». Ces activités constituent les éléments de base de la carte du processus. L’analyse de leur séquence et de leur fréquence permet de repérer les parcours les plus courants, les écarts et les boucles de reprise. Elle est essentielle pour comprendre ce qui se passe dans un dossier et dans quel ordre, et constitue le fondement de toute analyse Process Mining. Pourquoi est-ce important ? Les activités définissent les étapes du processus. L’analyse de leur séquence, de leur durée et de leur fréquence est au cœur du Process Mining et révèle comment le travail se déroule réellement. Où trouver ces données Déduit des changements de statut dans des tables comme VBUK/VBUP, des événements de création de documents (par exemple dans VBAK, LIKP, VBRK) ou des journaux de modifications des tables CDHDR/CDPOS. Exemples Commande de retour crééeEntrée de marchandises comptabiliséeAvoir crééPoste de commande de retour traité
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation des données de ce processus.
Description Cet attribut enregistre la date et l’heure de la dernière extraction ou mise à jour des données. Il indique clairement leur degré d’actualité. Pour l’analyse, il est important de savoir à quel moment les données ont été mises à jour. Les utilisateurs peuvent ainsi vérifier leur actualité, qui influe sur la pertinence des résultats, notamment pour le suivi des opérations en cours. Pourquoi est-ce important ? Indique l’actualité des données, afin que les utilisateurs sachent à quand remonte l’analyse du processus et quand la prochaine mise à jour est prévue. Où trouver ces données Cet attribut de métadonnées est renseigné avec l’horodatage d’exécution de la tâche d’extraction des données. Exemples 2023-05-20T02:00:00Z2023-05-21T02:00:00Z
	Système source SourceSystem	Système dont les données ont été extraites.
Description Cet attribut indique l’origine des données, ce qui est essentiel dans les environnements comportant plusieurs systèmes. Il apporte du contexte et contribue à garantir la traçabilité et l’intégrité des données. Lors de l’analyse, il sert à segmenter ou à filtrer les données lorsque des processus issus de différents systèmes sources sont regroupés. Il permet de vérifier que les événements proviennent bien de l’application attendue, en l’occurrence SAP ECC. Pourquoi est-ce important ? Indique l’origine des données, un élément essentiel à leur gouvernance et aux analyses couvrant plusieurs systèmes d’entreprise. Où trouver ces données Cette valeur statique est définie lors de l’extraction des données afin d’identifier l’instance SAP ECC concernée (par exemple, « ECC_PROD_100 »). Exemples SAP_ECC_PRODSAPECC_FINANCE_200
	Agent de traitement ProcessingAgent	Identifiant de l’employé qui a réalisé l’activité.
Description Cet attribut enregistre le nom d’utilisateur de la personne chargée d’exécuter une étape précise du processus, comme la création de la commande de retour ou la comptabilisation de l’entrée de marchandises. Il correspond souvent à l’utilisateur indiqué dans les champs « Modifié par » ou « Créé par ». L’analyse par agent de traitement est utile pour le suivi de la performance et l’analyse des ressources. Elle permet de repérer les personnes les plus performantes, celles qui pourraient avoir besoin d’une formation complémentaire et la répartition de la charge de travail au sein d’une équipe. Elle est utilisée dans des Dashboards comme « Performance des agents de traitement des retours » pour comparer les temps de cycle et le débit. Pourquoi est-ce important ? Suit la participation des utilisateurs et permet d’analyser la performance de l’équipe, la répartition de la charge de travail et les besoins de formation ou les bonnes pratiques. Où trouver ces données Se trouve généralement dans des champs comme ERNAM (créé par) ou AENAM (modifié par) des tables d’en-tête telles que VBAK, LIKP et VBRK. Pour les événements de modification, il s’agit du champ USERNAME dans CDHDR. Exemples CBURNSDSCRANTONJHALPERT
	Canal de retour ReturnChannel	Canal par lequel le retour a été initié, par exemple en ligne, en magasin ou par centre d’appels.
Description Cet attribut indique l’origine ou le mode de réception de la demande de retour. Il permet de distinguer les retours initiés sur un portail Web, dans un magasin ou auprès d’un représentant du service client. La segmentation du processus par canal de retour est importante pour comprendre les différences opérationnelles et répartir les ressources. Par exemple, l’inspection des retours en magasin peut être plus rapide, mais les étapes de documentation peuvent différer de celles des retours en ligne. Cet attribut est un axe essentiel du Dashboard « Tendances du débit du processus de retour ». Pourquoi est-ce important ? Distingue les modes d’initiation des retours, qui ont souvent une incidence sur le déroulement du processus, les ressources nécessaires et les temps de cycle selon le canal. Où trouver ces données Ce champ n’est souvent pas standard dans SAP ECC. Il peut être nécessaire de l’extraire d’un champ personnalisé (par exemple dans VBAK) ou de le déduire d’autres données, comme l’organisation commerciale (VKORG) ou le canal de distribution (VTWEG). Consultez la documentation SAP ECC pour connaître les détails de votre implémentation. Exemples Portail en ligneEn magasinCentre d’appels
	Montant du remboursement demandé RequestedRefundAmount	Montant estimé du remboursement, généralement calculé à partir de la valeur nette des articles retournés.
Description Cet attribut représente le montant initial du retour, tel qu’il figure dans la commande de retour. Il sert de référence pour l’analyse et le rapprochement financiers. Ce montant est comparé au « Montant réel du remboursement » afin de repérer les écarts. Il s’agit d’une métrique essentielle du Dashboard « Suivi des écarts de montant des remboursements ». L’analyse de cette valeur permet de suivre l’incidence financière des retours et de repérer d’éventuels problèmes de tarification ou de calcul du crédit. Pourquoi est-ce important ? Établit la valeur financière initiale du retour, utile pour suivre les écarts financiers et connaître la valeur totale des marchandises retournées. Où trouver ces données Il s’agit généralement de la valeur nette au niveau du poste de la commande de retour. Elle se trouve dans la table VBAP, dans le champ NETWR. Exemples 150.0049.991250.75
	Montant réel du remboursement ActualRefundAmount	Montant final crédité au client, tel qu’il figure dans les documents financiers.
Description Cet attribut correspond au montant final confirmé du remboursement, traité et comptabilisé dans le système comptable. Il peut différer du montant demandé en raison de frais de remise en stock, d’ajustements liés à l’état de l’article ou de l’application d’autres règles. Cet attribut est essentiel au Dashboard « Suivi des écarts de montant des remboursements ». La comparaison avec le montant demandé permet de repérer les problèmes récurrents dans le calcul et l’approbation des remboursements, et de vérifier l’exactitude des comptes. Pourquoi est-ce important ? Représente le résultat financier final du retour. La comparaison avec le montant demandé permet d’en vérifier l’exactitude et de repérer les pertes financières. Où trouver ces données Extrait du document financier associé à la note de crédit. Il se trouve généralement dans la table BSEG (postes du document comptable), dans le champ WRBTR (montant dans la devise du document), pour le poste concerné du compte général. Exemples 150.0045.001200.75
	Motif du retour ReturnReason	Code de motif fourni par le client pour expliquer le retour de l’article.
Description Cet attribut indique pourquoi un produit a été retourné, à l’aide des codes de motif prédéfinis dans SAP. Exemples : « Endommagé pendant le transport », « Mauvais article expédié » ou « Ne convient pas ». Il s’agit d’un axe essentiel pour l’analyse des causes profondes. En filtrant la carte du processus ou les KPI par motif de retour, les analystes peuvent déterminer si certains motifs sont associés à des délais de traitement plus longs, à davantage d’échecs lors de l’inspection ou à des écarts précis dans le processus. Ces résultats peuvent guider les améliorations de la qualité des produits, de la logistique ou des processus de vente. Pourquoi est-ce important ? Explique les raisons des retours et permet d’en réduire le nombre en s’attaquant aux problèmes de qualité des produits, d’expédition ou de description. Où trouver ces données Se trouve dans la table des postes de documents de vente VBAP, dans le champ ABGRU (motif de rejet des documents de vente). Exemples 001 - Produit endommagé002 - Produit incorrect005 - Arrivé trop tard
	Numéro d’article MaterialNumber	Identifiant unique du produit retourné.
Description Le numéro d’article, ou SKU, désigne précisément le produit concerné par le retour. Il permet une analyse détaillée par produit. L’analyse des retours par numéro d’article aide les entreprises à repérer les produits souvent retournés, ce qui peut révéler des problèmes de qualité, des descriptions inexactes ou des défauts de fabrication. Cet attribut est essentiel pour des Dashboards comme « Incidence des retours sur les stocks » et pour comprendre le parcours des différents produits dans le processus de retour. Pourquoi est-ce important ? Indique quels produits sont retournés et met en évidence d’éventuels problèmes de contrôle qualité ou des descriptions de produits inexactes. Où trouver ces données Se trouve dans la table des postes de documents de vente VBAP, dans le champ MATNR. Exemples RM-1025FG-2050-BACC-5591
	Code société CompanyCode	Entité juridique ou société responsable de la transaction.
Description Dans SAP, le code société désigne une unité comptable autonome. Toutes les transactions financières, y compris les retours et les remboursements, sont comptabilisées dans un code société précis. Cet attribut est essentiel aux rapports financiers et à la segmentation du processus dans les organisations multinationales ou composées de plusieurs entités. L’analyse par code société permet de comparer la performance du processus de retour entre les différentes entités juridiques de l’entreprise. Pourquoi est-ce important ? Permet de filtrer et de comparer les processus de retour entre les différentes entités juridiques d’une organisation, ce qui est essentiel à l’analyse financière. Où trouver ces données Se trouve dans la table des en-têtes de documents de vente VBAK, dans le champ BUKRS_VF (code société pour la facturation). Exemples 10002000US01
	Date cible du SLA de remboursement RefundSLATargetDate	Date à laquelle le remboursement doit être traité, conformément aux accords de niveau de service.
Description Cet attribut définit la date limite de traitement du remboursement pour un dossier de retour donné. Elle est généralement calculée selon des règles métier, par exemple « 5 jours ouvrés après la réception des marchandises ». Cette date cible sert de référence pour mesurer la performance réelle. Elle est au cœur du Dashboard « Respect du SLA de traitement des remboursements » et permet à l’entreprise de vérifier le respect de ses engagements envers les clients et de repérer les dossiers susceptibles de dépasser le délai prévu. Pourquoi est-ce important ? Fixe l’objectif de délai de traitement des remboursements, afin que l’entreprise puisse mesurer et communiquer le respect du SLA et donner la priorité aux dossiers en retard. Où trouver ces données Il ne s’agit généralement pas d’un champ SAP standard. Il doit être calculé à partir de règles métier, par exemple en ajoutant une durée définie à une date de référence (comme la date de réception des marchandises dans MKPF). Consultez la documentation SAP ECC ou les exigences métier. Exemples 2023-04-25T23:59:59Z2023-04-28T23:59:59Z2023-05-02T23:59:59Z
	Division Plant	Lieu ou site physique où l’article retourné est reçu et traité.
Description Dans SAP, une division désigne un site physique, comme un entrepôt ou un centre de distribution, où les marchandises sont prises en charge. Pour les retours, il s’agit généralement du lieu où l’article est reçu et inspecté. L’analyse du processus par division permet de repérer les différences de performance entre les sites. Elle peut montrer quels entrepôts inspectent les articles plus efficacement ou traitent davantage de retours, et alimenter le Dashboard « Débit et efficacité de l’inspection des articles ». Pourquoi est-ce important ? Indique le site physique qui traite le retour et permet de comparer la performance des différents entrepôts ou centres de distribution. Où trouver ces données Se trouve au niveau du poste de la commande de retour, dans la table VBAP, champ WERKS. Exemples PL01WH02DC05
	Document de vente d’origine OriginalSalesDocument	Numéro de la commande de vente d’origine concernée par le retour.
Description Cet attribut renvoie directement à l’achat initial du client. Il s’agit d’un document de référence qui relie le retour aux détails de la transaction d’origine. Ce lien est très utile pour approfondir l’analyse. Il permet aux analystes de rechercher pourquoi les articles de certaines commandes sont retournés, de vérifier les prix et les conditions d’origine et de comprendre l’ensemble du parcours entre la commande et le retour. Il peut notamment aider à déterminer si les produits vendus dans le cadre de campagnes ou par certains canaux sont davantage retournés. Pourquoi est-ce important ? Relie le retour à la vente d’origine et permet d’examiner l’ensemble de la transaction client ainsi que les causes profondes du retour. Où trouver ces données Cette référence est enregistrée au niveau du poste de la commande de retour. Elle se trouve dans la table VBAP, dans le champ VGBEL (numéro du document de référence). Exemples 100034561000987110012345
	Écart sur le montant du remboursement RefundAmountDiscrepancy	Différence calculée entre le montant réel et le montant demandé du remboursement.
Description Cette métrique calculée quantifie l’écart entre le montant initialement demandé dans la commande de retour et celui finalement accordé dans la note de crédit. Une valeur positive peut indiquer un remboursement partiel. Une valeur négative est inhabituelle, mais peut signaler un trop-perçu. Cet attribut est la mesure principale du Dashboard « Suivi des écarts de montant des remboursements ». Il aide à repérer et à analyser rapidement les dossiers présentant des écarts financiers, qui peuvent être dus à l’évaluation de l’état de l’article, à des frais de remise en stock ou à des erreurs. Son suivi contribue à la maîtrise financière et au respect des politiques. Pourquoi est-ce important ? Mesure directement les écarts financiers du processus de remboursement et aide à repérer les manquements aux politiques, les erreurs de traitement ou les pertes financières. Où trouver ces données Champ calculé : ActualRefundAmount - RequestedRefundAmount. Exemples 0.00-4.99-50.00
	ID client CustomerId	Identifiant unique du client à l’origine du retour.
Description Cet attribut identifie le client concerné, appelé « donneur d’ordre » dans SAP, qui retourne le produit. Il relie la transaction de retour aux données de base du client. L’analyse par ID client permet de repérer les clients qui effectuent souvent des retours, ce qui peut signaler une insatisfaction ou un éventuel abus des politiques de retour. Associée aux données de segmentation des clients, elle permet aussi de déterminer si certains groupes ont des comportements ou des expériences de retour différents. Pourquoi est-ce important ? Relie les retours à des clients précis et permet d’analyser leur comportement, de repérer les retours répétés et d’évaluer leurs effets sur la relation client. Où trouver ces données Se trouve dans la table des en-têtes de documents de vente VBAK, dans le champ KUNNR (donneur d’ordre). Exemples CUST-100432CUST-203991CUST-831102
	Numéro de la note de crédit CreditMemoNumber	Identifiant unique du document de note de crédit émis pour le remboursement.
Description Dans SAP, la note de crédit est le document de facturation officiel qui formalise le remboursement à verser au client. Son numéro identifie ce document financier de manière unique. Cet attribut est essentiel au rapprochement financier et au suivi du processus, du retour opérationnel au règlement financier. Il constitue une étape clé du processus et permet de retrouver les documents comptables associés à des attributs comme le « Montant réel du remboursement ». Pourquoi est-ce important ? Renvoie directement au document financier qui autorise le remboursement du client, un élément essentiel à l’audit et au rapprochement financiers. Où trouver ces données La note de crédit est un document de facturation. Son numéro figure dans la table VBRK (document de facturation : données d’en-tête), dans le champ VBELN. Le lien se trouve dans le flux documentaire de la commande de retour. Exemples 900011229000334490005566
	Respect de la politique de retour ReturnPolicyAdherence	Indicateur précisant si le retour respecte l’ensemble des règles et politiques métier définies.
Description Cet attribut booléen calculé indique si un dossier de retour a suivi les politiques standard de l’entreprise. La logique peut vérifier plusieurs conditions : le retour a-t-il été initié dans le délai autorisé ? Le code de motif est-il valide pour le produit ? Une approbation du responsable a-t-elle été obtenue en cas d’exception ? Cet attribut alimente le Dashboard « Respect de la politique d’approbation des retours ». Il permet de mesurer directement le taux de conformité et de repérer les politiques les plus souvent contournées, afin de cibler les améliorations du processus ou les formations. Pourquoi est-ce important ? Mesure le respect des règles métier, contribue à l’application cohérente des politiques et permet de repérer les dossiers nécessitant un examen ou une approbation particulière. Où trouver ces données Cet attribut est déduit d’un ensemble de règles métier. Exemple : (date d’initiation du retour - date d’achat d’origine) <= 30 jours ET ReturnReason IS NOT NULL. Exemples truefalse
	Respect du SLA IsSLACompliant	Indicateur précisant si le remboursement a été traité dans le délai convenu dans l’accord de niveau de service (SLA).
Description Cet attribut booléen calculé compare la date réelle de l’activité « Remboursement traité » à la « Date cible du SLA de remboursement ». Il renvoie vrai si le remboursement a été effectué dans les délais, et faux dans le cas contraire. Cet attribut simplifie l’analyse et les rapports en donnant un résultat clair, sous forme binaire, pour le respect du SLA de chaque dossier. Il sert à calculer le taux global de respect du « SLA de traitement des remboursements » et à filtrer facilement les dossiers non conformes pour les analyser. Pourquoi est-ce important ? Indique clairement, sous forme binaire, si chaque dossier respecte le SLA, ce qui simplifie le suivi de la conformité et la production de rapports. Où trouver ces données Cet attribut est calculé selon la logique suivante : EventTime de « Remboursement traité » <= RefundSLATargetDate. Exemples truefalse
	Statut de la commande de retour ReturnOrderStatus	Statut général de traitement du dossier de retour.
Description Cet attribut donne un aperçu de l’état actuel du dossier de retour, par exemple « Ouvert », « En cours » ou « Terminé ». Il est déduit de la combinaison des statuts de l’en-tête ou des postes du document de vente. En analyse, il permet de filtrer les dossiers pour se concentrer sur les retours en cours ou terminés. Il aide à suivre la charge de travail globale et l’avancement des dossiers ouverts, et donne une vue d’ensemble du résultat de chaque retour. Pourquoi est-ce important ? Indique où en est un dossier, ce qui permet de filtrer et d’analyser les retours ouverts, en cours ou clôturés. Où trouver ces données Déduit des champs de statut des tables VBUK (statut de l’en-tête) et VBUP (statut du poste). Par exemple, VBUK-GBSTK indique le statut général de traitement du document. Exemples OuvertEn coursTerminé

Obligatoire Recommandé Facultatif

Activités liées au traitement des retours et des remboursements

Voici les étapes clés et les jalons à enregistrer dans votre journal d’événements pour découvrir le processus avec précision.

6 Recommandé 6 Facultatif

	Activité	Description
	Avoir créé	Un document de facturation (note de crédit) est généré pour autoriser le crédit financier accordé au client. Ce document officiel formalise le montant du remboursement.
Pourquoi est-ce important ? Il s’agit d’une étape financière importante du processus. L’analyse du délai de création de la note de crédit permet de repérer les retards dans le traitement des documents financiers après la réception et l’inspection des marchandises. Où trouver ces données Cet événement explicite est enregistré dans la table VBRK (en-tête du document de facturation). La date de création figure dans le champ VBRK-ERDAT. Dans le flux documentaire, la note de crédit est liée à la commande de retour ou à la demande de note de crédit. Données à recueillir Utilisez l’horodatage de création (ERDAT) de la table VBRK pour le document de facturation concerné. Type d’événement explicit
	Commande de retour créée	Cette activité marque le début du processus de retour, lorsqu’un client demande à retourner un produit. Elle est enregistrée lors de la création dans SAP ECC d’un nouveau document de vente de type « Retour » (par exemple, RE).
Pourquoi est-ce important ? Il s’agit de l’événement de début principal du processus de retours. L’analyse du délai entre cette activité et les suivantes permet de mesurer le temps de cycle total et de repérer les premiers retards de traitement. Où trouver ces données Il s’agit d’un événement explicite enregistré dans la table VBAK (en-tête du document de vente). L’horodatage de création est stocké dans VBAK-ERDAT et VBAK-ERZET pour le numéro de document de vente correspondant (VBAK-VBELN), dont le type de commande est VBAK-AUART = « RE ». Données à recueillir Utilisez l’horodatage de création (ERDAT, ERZET) de la table VBAK pour les documents de vente de type « RE ». Type d’événement explicit
	Commande de retour terminée	Cette activité marque la fin du processus de retour du point de vue des ventes et de la distribution. Elle intervient lorsque tous les postes de la commande de retour sont entièrement traités et clôturés.
Pourquoi est-ce important ? Il s’agit du principal événement de fin du processus. Le délai entre « Commande de retour créée » et cette activité correspond au temps de cycle de bout en bout du dossier de retour. Où trouver ces données Cet événement est déduit des tables de statut. Il est enregistré lorsque le statut global de l’en-tête du document de vente (VBUK-GBSTK) passe à « C » (entièrement traité). Données à recueillir Repérez, dans les documents de modification (CDHDR/CDPOS), l’horodatage auquel le champ de statut de l’en-tête VBUK-GBSTK passe à « C ». Type d’événement inferred
	Décision d’utilisation prise	Après l’inspection, un ingénieur qualité ou un inspecteur prend une décision officielle sur l’état de l’article retourné. Cette décision détermine la suite du processus : remise en stock, mise au rebut ou réparation, par exemple.
Pourquoi est-ce important ? Cette activité permet de comprendre l’efficacité des inspections et leurs résultats. La décision a une incidence directe sur le montant du remboursement et la gestion des stocks. Où trouver ces données Si SAP QM est utilisé, il s’agit d’un événement explicite enregistré dans la table QAVE (décision d’utilisation du traitement de l’inspection). La date de décision est stockée dans QAVE-VDATUM. Le lien avec la livraison se trouve dans la table QALS. Données à recueillir Utilisez la date de décision d’utilisation (VDATUM) de la table QAVE, associée au lot d’inspection (QALS-PRUEFLOS). Type d’événement explicit
	Entrée de marchandises comptabilisée	Cette activité a lieu lorsque l’article retourné est réceptionné physiquement à l’entrepôt ou au centre de traitement. Elle est enregistrée lors de la comptabilisation d’un document de mouvement de marchandises associé à la livraison de retour.
Pourquoi est-ce important ? Cette étape importante indique que l’entreprise a pris possession de l’article retourné. Elle marque le début de l’inspection physique et influe sur l’exactitude des stocks. Où trouver ces données Cet événement peut être déduit du statut du mouvement de marchandises de l’article de livraison de retour dans la table VBUP (par exemple, WBSTA = « C »). L’horodatage exact figure dans l’en-tête du document article (MKPF-BUDAT) correspondant à l’entrée de marchandises. Données à recueillir Recherchez la date de comptabilisation (BUDAT) dans la table MKPF pour le document article lié à la livraison de retour. Type d’événement inferred
	Note de crédit comptabilisée en FI	La note de crédit est transmise à la comptabilité financière et devient une écriture officielle dans les comptes clients. Cette étape déclenche le processus de remboursement effectif du client.
Pourquoi est-ce important ? Cette activité marque le moment où l’entreprise comptabilise le remboursement. Un délai entre la création et la comptabilisation de la note de crédit peut retarder le remboursement effectif du client. Où trouver ces données Cet événement est déduit de la mise à jour du statut de comptabilisation dans l’en-tête du document de facturation (VBRK-RFBSK), qui passe à « C » (document de comptabilisation créé). La date de création du document comptable figure dans la table BKPF. Données à recueillir Repérez l’horodatage auquel VBRK-RFBSK prend la valeur « C », ou utilisez la date de création (CPUDT) du document comptable BKPF associé. Type d’événement inferred
	Blocage de la commande de retour levé	Cette activité correspond à l’approbation de la demande de retour, qui peut alors passer à l’étape suivante. Elle est généralement enregistrée lors d’un changement du statut du document ou de la levée d’un blocage de livraison ou de facturation.
Pourquoi est-ce important ? Cette activité marque une étape essentielle de l’approbation. Le temps nécessaire pour l’atteindre permet de repérer les goulots d’étranglement dans le processus d’autorisation et d’approbation des retours. Où trouver ces données Il s’agit d’un événement déduit des journaux de modification du document de vente. Consultez les tables CDHDR et CDPOS pour repérer les modifications des champs de blocage dans VBAK ou VBAP, ou des champs de statut dans VBUK/VBUP. Données à recueillir Repérez dans les tables des documents de modification (CDHDR/CDPOS) l’horodatage auquel le statut de blocage concerné a été levé. Type d’événement inferred
	Demande d’avoir créée	Une demande d’avoir est créée pour formaliser le remboursement à effectuer. Dans de nombreuses configurations, la commande de retour tient elle-même lieu de demande d’avoir.
Pourquoi est-ce important ? Cette activité marque le début officiel du règlement financier du processus de retours. Elle déclenche les approbations financières et la création des documents qui suivent. Où trouver ces données Il peut s’agir d’un événement explicite dans VBAK pour un document de vente de type « Demande d’avoir » (par exemple, CR), ou du même événement que « Commande de retour créée » si le type de commande est configuré pour une facturation liée à la commande. Données à recueillir Utilisez l’horodatage de création (ERDAT) de VBAK pour le type de document « CR », ou réutilisez l’événement de création de la commande de retour. Type d’événement explicit
	Livraison de retour créée	Un document de livraison est généré pour gérer la réception physique des marchandises retournées. Cet événement indique le début du processus logistique du retour.
Pourquoi est-ce important ? Cette activité marque le passage du traitement administratif à la logistique physique. Tout retard à cette étape peut perturber la planification de l’entrepôt et allonger le temps de cycle global du retour. Où trouver ces données Il s’agit d’un événement explicite enregistré dans la table LIKP (en-tête de livraison). L’horodatage de création figure dans LIKP-ERDAT. Le lien avec la commande de retour d’origine se trouve dans la table LIPS (LIPS-VGBEL). Données à recueillir Utilisez l’horodatage de création (ERDAT) de la table LIKP pour la livraison associée à la commande de retour. Type d’événement explicit
	Note de crédit compensée	Le poste de crédit ouvert dans les comptes clients est compensé, généralement par un paiement sortant au client. Cet événement marque la clôture financière définitive du remboursement.
Pourquoi est-ce important ? Cette activité confirme le décaissement et clôt le volet financier du processus. Du point de vue du client, elle marque la fin effective du remboursement. Où trouver ces données Cet événement explicite provient du module FI. La date de compensation du document comptable est enregistrée dans la table BSEG (BSEG-AUGDT), pour le poste client correspondant. Données à recueillir Utilisez la date de compensation (AUGDT) de la table BSEG ou BSAD pour le document comptable lié à la note de crédit. Type d’événement explicit
	Poste de commande de retour rejeté	Un poste précis de la commande de retour est rejeté, lors de l’examen initial ou après inspection. Aucun traitement ultérieur, comme un remboursement, n’aura donc lieu pour ce poste.
Pourquoi est-ce important ? L’analyse des rejets permet de repérer les demandes de retour non valides et d’adapter les informations communiquées aux clients sur les politiques de retour. Il s’agit d’un parcours important du processus qui n’aboutit pas à un remboursement. Où trouver ces données Cet événement est déduit de la définition d’un code unique de « motif de rejet » pour le poste dans la table VBAP (VBAP-ABGRU). L’horodatage doit être extrait des journaux de modifications. Données à recueillir Repérez, dans les documents de modification (CDHDR/CDPOS), l’horodatage auquel le champ VBAP-ABGRU est renseigné pour un poste de retour. Type d’événement inferred
	Poste de commande de retour traité	Un poste de la commande de retour est marqué comme entièrement traité. Cela se produit généralement une fois tous les documents logistiques et financiers associés à ce poste établis.
Pourquoi est-ce important ? Le suivi par poste permet de repérer les produits ou les motifs de retour qui entraînent les délais les plus longs. Il donne une vue plus détaillée de l’avancement du processus. Où trouver ces données Cet événement est déduit des tables de statut. Il est enregistré lorsque le statut global du poste du document de vente (VBUP-GBSTK) passe à « C » (entièrement traité). Données à recueillir Repérez, dans les documents de modification (CDHDR/CDPOS), l’horodatage auquel le champ de statut du poste VBUP-GBSTK passe à « C ». Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de SAP ECC

Étapes

Créez un programme ABAP : Utilisez le code de transaction SE38 pour créer un programme ABAP exécutable, par exemple Z_PM_RETURN_EXTRACTION. Donnez-lui un titre explicite et enregistrez-le comme objet local ou dans un package de développement.
Définissez l’écran de sélection : Dans le programme, créez un écran de sélection permettant de filtrer les données. Les principaux filtres sont la période de création des commandes de retour (S_ERDAT), le type de document de vente pour les retours (S_AUART, par exemple « RE ») et le code société (P_BUKRS).
Définissez les structures de données : Créez un type de structure local correspondant au format requis pour le journal d’événements. Il doit inclure les champs ReturnCaseId, ActivityName, EventTime, SourceSystem, LastDataUpdate, ProcessingAgent, ReturnReason et les autres attributs requis.
Implémentez la logique de sélection des données : Écrivez la logique ABAP nécessaire pour sélectionner les données des 12 activités requises. Vous devrez interroger plusieurs tables SAP, notamment VBAK, VBAP, LIKP, VBRK, BKPF, CDHDR et CDPOS. Utilisez la table de flux documentaire (VBFA) pour relier les documents associés, comme les livraisons et les avoirs, à la commande de retour d’origine.
Extrayez l’événement « Création de la commande de retour » : Sélectionnez les enregistrements des tables VBAK et VBAP selon les critères de l’écran de sélection. Le numéro du document de vente (VBAK-VBELN) servira de ReturnCaseId.
Extrayez les changements de statut et les événements clés : Pour des activités comme « Suppression du blocage de la commande de retour » ou « Rejet d’un poste de commande de retour », interrogez les tables de documents de modification (CDHDR, CDPOS) ou les champs de statut de tables comme VBAP (ABGRU). Pour les activités logistiques et financières qui suivent, sélectionnez les données dans des tables comme LIKP, MKPF, VBRK et BKPF, en utilisant VBFA pour vérifier qu’elles sont liées aux commandes de retour initiales.
Alimentez la table du journal d’événements : Pour chaque activité extraite, créez un enregistrement dans une table interne définie à l’aide de la structure du journal d’événements. Associez les données des tables SAP sources aux champs correspondants. Par exemple, associez VBAK-ERNAM à ProcessingAgent, et VBAK-ERDAT ainsi que VBAK-ERZET à EventTime.
Regroupez les données d’activité : Veillez à ce que chaque instruction SELECT ajoute ses résultats à une seule table interne principale. Vous obtiendrez ainsi un fichier plat final dans lequel chaque ligne correspond à un événement.
Gérez les horodatages et les informations système : Utilisez les champs système SY-DATUM et SY-UZEIT pour renseigner l’horodatage LastDataUpdate de chaque ligne. Utilisez SY-SYSID pour renseigner SourceSystem.
Ajoutez une fonction d’export : Ajoutez une fonction permettant d’afficher les résultats dans une grille ALV (SAP List Viewer) pour les analyser en ligne, à l’aide de modules fonction tels que REUSE_ALV_GRID_DISPLAY. Prévoyez une option pour télécharger la table interne finale sur l’ordinateur de l’utilisateur au format CSV ou texte brut.
Exécutez le programme et exportez les données : Lancez le programme avec SE38. Saisissez les critères de sélection souhaités, puis exécutez-le. Une fois les données affichées ou traitées, utilisez la fonction d’export du programme pour enregistrer le fichier du journal d’événements. Vérifiez que le format est compatible avec ProcessMind, généralement un fichier CSV avec une ligne d’en-tête.

Configuration

Période : Sur l’écran de sélection, indiquez une période pour la date de création des commandes de retour. Pour une première analyse, une période de 3 à 6 mois est recommandée afin de trouver un équilibre entre le volume de données et la précision de l’analyse.
Type de document de retour : Filtrez les données selon le type de document de vente utilisé pour les retours dans votre système, par exemple « RE » pour les retours ou « CR » pour les demandes d’avoir. Ce filtre est essentiel pour isoler le bon processus. Saisissez ces valeurs dans l’option de sélection S_AUART.
Code société : Indiquez le code société concerné (P_BUKRS) pour limiter les données à une entité juridique précise. Ce filtre est indispensable dans les environnements qui comptent plusieurs sociétés.
Prérequis : L’utilisateur qui exécute le programme doit être autorisé à utiliser SE38 (exécution du programme) et à accéder aux tables SD, MM et FI sous-jacentes, par exemple VBAK, LIKP, VBRK, BKPF et CDHDR. Le développement nécessite un rôle de développeur ABAP.
Performances : Sur de très grands ensembles de données couvrant plusieurs années, le programme peut prendre beaucoup de temps. Envisagez de l’exécuter en arrière-plan (SM36) et d’écrire les résultats dans le système de fichiers du serveur d’applications plutôt que de les afficher en ligne.

a Exemple de requête abap

REPORT Z_PM_RETURN_EXTRACTION.

" =======================================================================
" DATA DECLARATIONS
" =======================================================================

TYPES: BEGIN OF ty_event_log,
         returncaseid           TYPE vbeln_va,
         activityname         TYPE string,
         eventtime            TYPE timestamp,
         sourcesystem         TYPE sysysid,
         lastdataupdate       TYPE timestamp,
         processingagent      TYPE ernam,
         returnreason         TYPE augru,
         materialnumber       TYPE matnr,
         returnchannel        TYPE string, " Placeholder, needs custom logic
         requestedrefundamount TYPE netwr,
         actualrefundamount   TYPE netwr,
       END OF ty_event_log.

DATA: lt_event_log TYPE TABLE OF ty_event_log,
      ls_event_log TYPE ty_event_log.

DATA: lv_timestamp     TYPE timestamp,
      lv_last_update   TYPE timestamp.

" =======================================================================
" SELECTION SCREEN
" =======================================================================

SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY,
                s_auart FOR vbak-auart.
PARAMETERS:     p_bukrs TYPE bukrs OBLIGATORY.

" =======================================================================
" MAIN LOGIC
" =======================================================================

START-OF-SELECTION.

  " Set static values for the extraction run
  GET TIME STAMP FIELD lv_last_update.

  " 1. Return Order Created & 6. Credit Memo Request Created
  " Note: In many SAP standard processes, the Return Order itself acts as the Credit Memo Request.
  SELECT h~vbeln, h~erdat, h~erzet, h~ernam, h~augru, i~matnr, i~netwr
    INTO TABLE @DATA(lt_return_orders)
    FROM vbak AS h
    INNER JOIN vbap AS i ON h~vbeln = i~vbeln
    WHERE h~erdat IN @s_erdat
      AND h~auart IN @s_auart
      AND h~bukrs_vf = @p_bukrs.

  LOOP AT lt_return_orders INTO DATA(ls_return_order).
    " Activity: Return Order Created
    ls_event_log-returncaseid = ls_return_order-vbeln.
    ls_event_log-activityname = 'Return Order Created'.
    CONVERT DATE ls_return_order-erdat TIME ls_return_order-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
    ls_event_log-sourcesystem = sy-sysid.
    ls_event_log-lastdataupdate = lv_last_update.
    ls_event_log-processingagent = ls_return_order-ernam.
    ls_event_log-returnreason = ls_return_order-augru.
    ls_event_log-materialnumber = ls_return_order-matnr.
    ls_event_log-requestedrefundamount = ls_return_order-netwr.
    APPEND ls_event_log TO lt_event_log.

    " Activity: Credit Memo Request Created
    ls_event_log-activityname = 'Credit Memo Request Created'.
    APPEND ls_event_log TO lt_event_log.
  ENDLOOP.

  IF lt_return_orders IS NOT INITIAL.
    " 2. Return Order Block Removed (Example for Delivery Block)
    SELECT objectid, udate, utime, username
      FROM cdhdr
      INTO TABLE @DATA(lt_block_changes)
      FOR ALL ENTRIES IN @lt_return_orders
      WHERE objectclas = 'VERKBELEG'
        AND objectid   = @lt_return_orders-vbeln
        AND tcode      = 'VA02'.

    IF sy-subrc = 0.
      SELECT objectid, fname, value_new
        INTO TABLE @DATA(lt_cdpos_block)
        FROM cdpos
        FOR ALL ENTRIES IN @lt_block_changes
        WHERE objectclas = @lt_block_changes-objectclas
          AND objectid   = @lt_block_changes-objectid
          AND changenr   = @lt_block_changes-changenr
          AND tabname    = 'VBAK'
          AND fname      = 'LIFSK' " Delivery Block field
          AND value_new  = ''.

      LOOP AT lt_cdpos_block INTO DATA(ls_cdpos_block).
        READ TABLE lt_block_changes INTO DATA(ls_block_change) WITH KEY objectid = ls_cdpos_block-objectid.
        IF sy-subrc = 0.
          ls_event_log-returncaseid = ls_cdpos_block-objectid.
          ls_event_log-activityname = 'Return Order Block Removed'.
          CONVERT DATE ls_block_change-udate TIME ls_block_change-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
          ls_event_log-sourcesystem = sy-sysid.
          ls_event_log-lastdataupdate = lv_last_update.
          ls_event_log-processingagent = ls_block_change-username.
          CLEAR: ls_event_log-returnreason, ls_event_log-materialnumber, ls_event_log-requestedrefundamount, ls_event_log-actualrefundamount.
          APPEND ls_event_log TO lt_event_log.
        ENDIF.
      ENDLOOP.
    ENDIF.

    " Get subsequent documents from flow
    SELECT vbelv, vbtyp_n, vbeln, rfbsk
      INTO TABLE @DATA(lt_doc_flow)
      FROM vbfa
      FOR ALL ENTRIES IN @lt_return_orders
      WHERE vbelv = @lt_return_orders-vbeln
        AND vbtyp_n IN ('J', 'R', 'M'). " J=Delivery, R=Goods Mvmt, M=Invoice

    " 3. Return Delivery Created
    SELECT vbeln, erdat, erzet, ernam FROM likp
      INTO TABLE @DATA(lt_deliveries)
      FOR ALL ENTRIES IN @lt_doc_flow
      WHERE vbeln = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'J'.

    LOOP AT lt_deliveries INTO DATA(ls_delivery).
      READ TABLE lt_doc_flow INTO DATA(ls_doc_flow_del) WITH KEY vbeln = ls_delivery-vbeln.
      ls_event_log-returncaseid = ls_doc_flow_del-vbelv.
      ls_event_log-activityname = 'Return Delivery Created'.
      CONVERT DATE ls_delivery-erdat TIME ls_delivery-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
      ls_event_log-sourcesystem = sy-sysid.
      ls_event_log-lastdataupdate = lv_last_update.
      ls_event_log-processingagent = ls_delivery-ernam.
      APPEND ls_event_log TO lt_event_log.
    ENDLOOP.

    " 4. Goods Receipt Posted
    SELECT mblnr, mjahr, budat, cputm, usnam FROM mkpf
      INTO TABLE @DATA(lt_goods_receipt)
      FOR ALL ENTRIES IN @lt_doc_flow
      WHERE xblnr = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'R'.

    LOOP AT lt_goods_receipt INTO DATA(ls_goods_receipt).
      READ TABLE lt_doc_flow INTO DATA(ls_doc_flow_gr) WITH KEY vbeln = ls_goods_receipt-mblnr.
      ls_event_log-returncaseid = ls_doc_flow_gr-vbelv.
      ls_event_log-activityname = 'Goods Receipt Posted'.
      CONVERT DATE ls_goods_receipt-budat TIME ls_goods_receipt-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
      ls_event_log-sourcesystem = sy-sysid.
      ls_event_log-lastdataupdate = lv_last_update.
      ls_event_log-processingagent = ls_goods_receipt-usnam.
      APPEND ls_event_log TO lt_event_log.
    ENDLOOP.

    " 5. Usage Decision Made (Requires QM Module implementation)
    SELECT q~prueflos, q~vdatu, q~vzeit, q~vname
      FROM qals AS q
      INNER JOIN qave AS v ON q~prueflos = v~prueflos
      INTO TABLE @DATA(lt_usage_decisions)
      FOR ALL ENTRIES IN @lt_deliveries
      WHERE q~kdauf = @lt_deliveries-vbeln.

    LOOP AT lt_usage_decisions INTO DATA(ls_ud).
       SELECT SINGLE vbelv FROM vbfa INTO @DATA(lv_vbelv_ud) WHERE vbeln = @ls_ud-prueflos.
       ls_event_log-returncaseid = lv_vbelv_ud.
       ls_event_log-activityname = 'Usage Decision Made'.
       CONVERT DATE ls_ud-vdatu TIME ls_ud-vzeit INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
       ls_event_log-sourcesystem = sy-sysid.
       ls_event_log-lastdataupdate = lv_last_update.
       ls_event_log-processingagent = ls_ud-vname.
       APPEND ls_event_log TO lt_event_log.
    ENDLOOP.

    " 7. Credit Memo Created
    SELECT h~vbeln, h~erdat, h~erzet, h~ernam, i~netwr, i~vgbel
      INTO TABLE @DATA(lt_cred_memos)
      FROM vbrk AS h
      INNER JOIN vbrp AS i ON h~vbeln = i~vbeln
      FOR ALL ENTRIES IN @lt_doc_flow
      WHERE h~vbeln = @lt_doc_flow-vbeln AND @lt_doc_flow-vbtyp_n = 'M'.

    LOOP AT lt_cred_memos INTO DATA(ls_cred_memo).
      ls_event_log-returncaseid = ls_cred_memo-vgbel.
      ls_event_log-activityname = 'Credit Memo Created'.
      CONVERT DATE ls_cred_memo-erdat TIME ls_cred_memo-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
      ls_event_log-sourcesystem = sy-sysid.
      ls_event_log-lastdataupdate = lv_last_update.
      ls_event_log-processingagent = ls_cred_memo-ernam.
      ls_event_log-actualrefundamount = ls_cred_memo-netwr.
      APPEND ls_event_log TO lt_event_log.

      " 8. Credit Memo Posted To FI
      SELECT SINGLE budat, cputime, usnam FROM bkpf
        INTO @DATA(ls_bkpf_post)
        WHERE awkey = @ls_cred_memo-vbeln AND awtyp = 'VBRK'.
      IF sy-subrc = 0.
        ls_event_log-activityname = 'Credit Memo Posted To FI'.
        CONVERT DATE ls_bkpf_post-budat TIME ls_bkpf_post-cputime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
        ls_event_log-processingagent = ls_bkpf_post-usnam.
        APPEND ls_event_log TO lt_event_log.
      ENDIF.

      " 12. Credit Memo Cleared
      SELECT SINGLE augdt FROM bseg
        INTO @DATA(lv_augdt)
        WHERE bukrs = @p_bukrs
          AND belnr = @ls_cred_memo-vbeln
          AND augdt IS NOT NULL.
      IF sy-subrc = 0 AND lv_augdt IS NOT INITIAL.
        ls_event_log-activityname = 'Credit Memo Cleared'.
        CONVERT DATE lv_augdt INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
        CLEAR: ls_event_log-processingagent.
        APPEND ls_event_log TO lt_event_log.
      ENDIF.
    ENDLOOP.

    " 9. Return Order Item Completed
    SELECT vbeln, erdat, erzet, ernam, abgru FROM vbap
      INTO TABLE @DATA(lt_items_completed)
      FOR ALL ENTRIES IN @lt_return_orders
      WHERE vbeln = @lt_return_orders-vbeln
        AND gbsta = 'C'.

    LOOP AT lt_items_completed INTO DATA(ls_item_completed).
      ls_event_log-returncaseid = ls_item_completed-vbeln.
      ls_event_log-activityname = 'Return Order Item Completed'.
      CONVERT DATE ls_item_completed-erdat TIME ls_item_completed-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
      ls_event_log-sourcesystem = sy-sysid.
      ls_event_log-lastdataupdate = lv_last_update.
      ls_event_log-processingagent = ls_item_completed-ernam.
      APPEND ls_event_log TO lt_event_log.
    ENDLOOP.

    " 10. Return Order Completed
    SELECT vbeln, erdat, erzet, ernam FROM vbak
      INTO TABLE @DATA(lt_orders_completed)
      FOR ALL ENTRIES IN @lt_return_orders
      WHERE vbeln = @lt_return_orders-vbeln
        AND gbsta = 'C'.

    LOOP AT lt_orders_completed INTO DATA(ls_order_completed).
      ls_event_log-returncaseid = ls_order_completed-vbeln.
      ls_event_log-activityname = 'Return Order Completed'.
      CONVERT DATE ls_order_completed-erdat TIME ls_order_completed-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
      ls_event_log-sourcesystem = sy-sysid.
      ls_event_log-lastdataupdate = lv_last_update.
      ls_event_log-processingagent = ls_order_completed-ernam.
      APPEND ls_event_log TO lt_event_log.
    ENDLOOP.

    " 11. Return Order Item Rejected
    SELECT vbeln, erdat, erzet, ernam FROM vbap
      INTO TABLE @DATA(lt_items_rejected)
      FOR ALL ENTRIES IN @lt_return_orders
      WHERE vbeln = @lt_return_orders-vbeln
        AND abgru IS NOT NULL AND abgru <> ''.

    LOOP AT lt_items_rejected INTO DATA(ls_item_rejected).
      ls_event_log-returncaseid = ls_item_rejected-vbeln.
      ls_event_log-activityname = 'Return Order Item Rejected'.
      CONVERT DATE ls_item_rejected-erdat TIME ls_item_rejected-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
      ls_event_log-sourcesystem = sy-sysid.
      ls_event_log-lastdataupdate = lv_last_update.
      ls_event_log-processingagent = ls_item_rejected-ernam.
      APPEND ls_event_log TO lt_event_log.
    ENDLOOP.

  ENDIF.

  " =======================================================================
  " OUTPUT
  " =======================================================================
  cl_salv_table=>factory(
    IMPORTING
      r_salv_table = DATA(lo_alv)
    CHANGING
      t_table      = lt_event_log ).

  lo_alv->display( ).

Étapes

Prérequis : Vérifiez que vous disposez d’un utilisateur de base de données ayant un accès en lecture aux tables SAP ECC requises, notamment celles des modules Ventes et distribution (SD), Gestion des articles (MM) et Comptabilité financière (FI). Vous aurez besoin d’un client SQL adapté, comme DBeaver, SAP HANA Studio ou Oracle SQL Developer, pour vous connecter à la base de données.
Repérez les spécificités du système : Avant d’exécuter la requête, identifiez les types de documents utilisés par votre organisation pour les retours. La requête contient le paramètre fictif [YOUR_RETURN_ORDER_TYPES], à remplacer par les valeurs réelles, par exemple « RE » pour les retours standard.
Préparez la requête : Copiez la requête SQL complète fournie dans la section « query » dans votre client SQL.
Configurez les paramètres : Repérez au début de la requête l’expression de table commune (CTE) nommée BaseReturnOrders. Modifiez la clause WHERE pour définir la période souhaitée en remplaçant [START_DATE] et [END_DATE]. Mettez à jour la liste des types de commandes de retour et, si nécessaire, filtrez selon un code société précis (BUKRS_VF).
Exécutez la requête : Lancez la requête modifiée sur la base de données SAP ECC. La durée d’exécution varie selon la période sélectionnée et la taille de la base de données.
Vérifiez les données brutes : Une fois la requête terminée, examinez rapidement les résultats. Vérifiez que les colonnes ReturnCaseId, ActivityName et EventTime sont renseignées et que plusieurs activités sont représentées.
Exportez les données au format CSV : Exportez l’ensemble des résultats depuis votre client SQL dans un fichier CSV. Utilisez l’encodage UTF-8 pour préserver correctement tous les caractères.
Préparez l’importation : Ouvrez le fichier CSV et vérifiez que les en-têtes de colonnes correspondent exactement aux attributs requis : ReturnCaseId, ActivityName, EventTime, SourceSystem, etc. Corrigez-les si votre client SQL les a modifiés lors de l’export.
Importez le fichier : Importez le fichier CSV vérifié dans la plateforme ProcessMind pour l’analyse.

Configuration

Types de documents de retour : Configurez la requête avec les types de documents de vente qui correspondent aux commandes de retour dans votre système SAP. Pour cela, remplacez le paramètre fictif [YOUR_RETURN_ORDER_TYPES]. Les valeurs courantes sont « RE » ou des types personnalisés commençant par « Z ».
Période : Il est essentiel de définir une période adaptée à l’extraction. Pour une première analyse, il est généralement recommandé de commencer par 3 à 6 mois de données. Renseignez les paramètres [START_DATE] et [END_DATE] au format « AAAAMMJJ ».
Code société : Si votre organisation utilise plusieurs codes société, filtrez les données pour cibler l’analyse. Vous pouvez ajouter un filtre tel que VBAK.BUKRS_VF = '[YOUR_COMPANY_CODE]' dans la CTE initiale afin de limiter le périmètre.
Dialecte SQL : La requête fournie utilise des fonctions SQL courantes. Toutefois, les conversions de date et d’heure, comme TO_TIMESTAMP, et la concaténation de chaînes (CONCAT) peuvent nécessiter de légères adaptations selon le système de base de données utilisé, par exemple Oracle, HANA ou DB2.
Autorisations requises : L’utilisateur de la base de données doit disposer d’un accès en lecture aux principales tables suivantes : VBAK, VBAP, VBFA, LIKP, LIPS, VBRK, VBRP, MKPF, MSEG, BKPF, BSAD, QALS, QAVE, CDHDR et CDPOS.

a Exemple de requête sql

WITH BaseReturnOrders AS (
  SELECT 
    VBAK.VBELN AS ReturnOrderNumber,
    VBAP.POSNR AS ReturnOrderItemNumber
  FROM VBAK
  JOIN VBAP ON VBAK.VBELN = VBAP.VBELN
  WHERE VBAK.AUART IN ('[YOUR_RETURN_ORDER_TYPES]') -- e.g., 'RE'
  AND VBAK.ERDAT BETWEEN '[START_DATE]' AND '[END_DATE]' -- e.g., '20230101' and '20231231'
)
-- 1. Return Order Created
SELECT
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Return Order Created' AS "ActivityName",
  TO_TIMESTAMP(CONCAT(VBAK.ERDAT, VBAK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  VBAK.ERNAM AS "ProcessingAgent",
  VBAK.AUGRU AS "ReturnReason",
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR

UNION ALL

-- 2. Return Order Block Removed
SELECT
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Return Order Block Removed' AS "ActivityName",
  TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  CDHDR.USERNAME AS "ProcessingAgent",
  VBAK.AUGRU AS "ReturnReason",
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON B.ReturnOrderNumber = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
  AND CDPOS.TABNAME = 'VBAK'
  AND CDPOS.FNAME IN ('LIFSK', 'FAKSK')
  AND CDPOS.VALUE_NEW = ''
  AND CDPOS.VALUE_OLD <> ''

UNION ALL

-- 3. Return Delivery Created
SELECT
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Return Delivery Created' AS "ActivityName",
  TO_TIMESTAMP(CONCAT(LIKP.ERDAT, LIKP.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  LIKP.ERNAM AS "ProcessingAgent",
  VBAK.AUGRU AS "ReturnReason",
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN LIKP ON VBFA.VBELN = LIKP.VBELN

UNION ALL

-- 4. Goods Receipt Posted
SELECT
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Goods Receipt Posted' AS "ActivityName",
  TO_TIMESTAMP(CONCAT(MKPF.CPUDT, MKPF.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  MKPF.USNAM AS "ProcessingAgent",
  VBAK.AUGRU AS "ReturnReason",
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN LIPS ON VBFA.VBELN = LIPS.VBELN AND VBFA.POSNN = LIPS.POSNR
JOIN MSEG ON LIPS.VBELN = MSEG.LFBNR AND LIPS.POSNR = MSEG.LFPOS
JOIN MKPF ON MSEG.MBLNR = MKPF.MBLNR AND MSEG.MJAHR = MKPF.MJAHR
WHERE MSEG.BWART IN ('651', '653', '655') -- Standard returns movement types

UNION ALL

-- 5. Usage Decision Made
SELECT
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Usage Decision Made' AS "ActivityName",
  TO_TIMESTAMP(CONCAT(QAVE.ADAT, QAVE.ATIM), 'YYYYMMDDHH24MISS') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  QAVE.AENAME AS "ProcessingAgent",
  VBAK.AUGRU AS "ReturnReason",
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'J'
JOIN QALS ON VBFA.VBELN = QALS.VBELN AND VBFA.POSNN = QALS.POSNR -- Linking inspection lot to delivery item
JOIN QAVE ON QALS.PRUEFLOS = QAVE.PRUEFLOS

UNION ALL

-- 6. Credit Memo Request Created (assumes a separate doc, or can be the return order itself)
SELECT 
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Credit Memo Request Created' AS "ActivityName",
  TO_TIMESTAMP(CONCAT(CMR_VBAK.ERDAT, CMR_VBAK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  CMR_VBAK.ERNAM AS "ProcessingAgent",
  VBAK.AUGRU AS "ReturnReason",
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'K' -- 'K' is Credit Memo Request
JOIN VBAK AS CMR_VBAK ON VBFA.VBELN = CMR_VBAK.VBELN

UNION ALL

-- 7. Credit Memo Created
SELECT
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Credit Memo Created' AS "ActivityName",
  TO_TIMESTAMP(CONCAT(VBRK.ERDAT, VBRK.ERZET), 'YYYYMMDDHH24MISS') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  VBRK.ERNAM AS "ProcessingAgent",
  VBAK.AUGRU AS "ReturnReason",
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
WHERE VBRK.FKART IN ('[YOUR_CREDIT_MEMO_TYPES]') -- e.g., 'G2'

UNION ALL

-- 8. Credit Memo Posted To FI
SELECT
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Credit Memo Posted To FI' AS "ActivityName",
  TO_TIMESTAMP(CONCAT(BKPF.CPUDT, BKPF.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  BKPF.USNAM AS "ProcessingAgent",
  VBAK.AUGRU AS "ReturnReason",
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
JOIN BKPF ON VBRK.VBELN = BKPF.AWKEY AND BKPF.AWTYP = 'VBRK'

UNION ALL

-- 9. Return Order Item Completed
SELECT 
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Return Order Item Completed' AS "ActivityName",
  TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  CDHDR.USERNAME AS "ProcessingAgent",
  VBAK.AUGRU AS "ReturnReason",
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON CONCAT(B.ReturnOrderNumber, LPAD(B.ReturnOrderItemNumber, 6, '0')) = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
  AND CDPOS.TABNAME = 'VBUP'
  AND CDPOS.FNAME = 'GBSTA'
  AND CDPOS.VALUE_NEW = 'C'

UNION ALL

-- 10. Return Order Completed
SELECT
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Return Order Completed' AS "ActivityName",
  TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  CDHDR.USERNAME AS "ProcessingAgent",
  VBAK.AUGRU AS "ReturnReason",
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON B.ReturnOrderNumber = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
  AND CDPOS.TABNAME = 'VBUK'
  AND CDPOS.FNAME = 'GBSTK'
  AND CDPOS.VALUE_NEW = 'C'

UNION ALL

-- 11. Return Order Item Rejected
SELECT 
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Return Order Item Rejected' AS "ActivityName",
  TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  CDHDR.USERNAME AS "ProcessingAgent",
  CDPOS.VALUE_NEW AS "ReturnReason", -- Using rejection reason for this specific event
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  NULL AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN CDHDR ON CONCAT(B.ReturnOrderNumber, LPAD(B.ReturnOrderItemNumber, 6, '0')) = CDHDR.OBJECTID
JOIN CDPOS ON CDHDR.OBJECTCLAS = CDPOS.OBJECTCLAS AND CDHDR.OBJECTID = CDPOS.OBJECTID AND CDHDR.CHANGENR = CDPOS.CHANGENR
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
WHERE CDHDR.OBJECTCLAS = 'VERKBELEG'
  AND CDPOS.TABNAME = 'VBAP'
  AND CDPOS.FNAME = 'ABGRU'
  AND CDPOS.VALUE_NEW <> ''

UNION ALL

-- 12. Credit Memo Cleared
SELECT
  CONCAT(B.ReturnOrderNumber, '-', B.ReturnOrderItemNumber) AS "ReturnCaseId",
  'Credit Memo Cleared' AS "ActivityName",
  TO_TIMESTAMP(BSAD.AUGDT, 'YYYYMMDD') AS "EventTime",
  'SAP ECC' AS "SourceSystem",
  CURRENT_TIMESTAMP AS "LastDataUpdate",
  CLEAR_DOC.USNAM AS "ProcessingAgent",
  VBAK.AUGRU AS "ReturnReason",
  VBAP.MATNR AS "MaterialNumber",
  VBAK.VTWEG AS "ReturnChannel",
  VBAP.NETWR AS "RequestedRefundAmount",
  VBRP.NETWR AS "ActualRefundAmount"
FROM BaseReturnOrders B
JOIN VBAK ON B.ReturnOrderNumber = VBAK.VBELN
JOIN VBAP ON B.ReturnOrderNumber = VBAP.VBELN AND B.ReturnOrderItemNumber = VBAP.POSNR
JOIN VBFA ON B.ReturnOrderNumber = VBFA.VBELV AND B.ReturnOrderItemNumber = VBFA.POSNV AND VBFA.VBTYP_N = 'M'
JOIN VBRK ON VBFA.VBELN = VBRK.VBELN
JOIN VBRP ON VBRK.VBELN = VBRP.VBELN AND VBFA.POSNN = VBRP.POSNR
JOIN BSAD ON VBRK.VBELN = BSAD.VBELN
JOIN BKPF AS CLEAR_DOC ON BSAD.AUGBL = CLEAR_DOC.BELNR AND BSAD.BUKRS = CLEAR_DOC.BUKRS AND BSAD.GJAHR_AUGL = CLEAR_DOC.GJAHR;

Prêt à commencer ?

Utilisez ce modèle dès aujourd’hui pour simplifier la collecte de vos données et mieux comprendre le traitement des retours et des remboursements.

Retour au guide d’amélioration Télécharger le modèle

Optimisez dès maintenant le traitement de vos retours et remboursements

Optimisez le traitement des retours dans SAP ECC et réduisez le temps de cycle de 30 %. Commencez dès aujourd’hui.

Démarrez l’essai gratuit

Aucune carte bancaire requise, configuration en quelques minutes

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 du traitement des retours et des remboursements

Activités liées au traitement des retours et des remboursements

Guides d’extraction

Programme ABAP personnalisé pour extraire les données des retours et remboursements

Étapes

Configuration

a Exemple de requête abap

Requête SQL directe sur les tables sous-jacentes de la base de données SAP

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Optimisez dès maintenant le traitement de vos retours et remboursements

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 du traitement des retours et des remboursements

Activités liées au traitement des retours et des remboursements

Guides d’extraction

Programme ABAP personnalisé pour extraire les données des retours et remboursements

Étapes

Configuration

a Exemple de requête abap

Requête SQL directe sur les tables sous-jacentes de la base de données SAP

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Optimisez dès maintenant le traitement de vos retours et remboursements

Nous respectons votre vie privée

Prêt à commencer ?