> Amélioration continue des processus > Traitement des retours et des remboursements > Oracle Fusion SCM > Modèle de données

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

Oracle Fusion SCM

← Retour au guide d’amélioration

Attributs du traitement des retours et des remboursements (21) Activités de traitement des retours et des remboursements (15) Guides d’extraction (3)

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

Ce modèle vous aide à analyser le traitement des retours et des remboursements dans Oracle Fusion SCM. Il présente les attributs essentiels à recueillir, les principales activités à suivre et explique clairement comment extraire ces données. Utilisez-le pour mieux comprendre votre processus et repérer les points à améliorer.

Attributs recommandés à recueillir
Activités clés à suivre pour analyser le processus
Guide d’extraction étape par étape pour Oracle Fusion SCM

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 dans Oracle Fusion SCM.

5 Obligatoire 7 Recommandé 9 Facultatif

	Nom	Description
	Activité ActivityName	Nom d’une étape 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, par exemple « RMA créée », « Article inspecté » ou « Remboursement traité ». Chaque activité correspond à un point distinct du processus, enregistré dans les journaux d’événements du système. L’analyse de l’ordre et de la durée de ces activités est au cœur du Process Mining. Elle permet de visualiser les cartes de processus, de repérer les goulots d’étranglement entre les étapes et de calculer les délais propres à chaque activité. Ces données sont essentielles pour comprendre le déroulement du processus, les boucles de reprise et le respect des procédures opérationnelles standard. Pourquoi est-ce important ? Les activités constituent la structure de la carte de processus et permettent de visualiser et d’analyser le déroulement du processus, ses variations et ses goulots d’étranglement. Où trouver ces données Cet attribut est dérivé des journaux d’événements, des changements de statut ou des enregistrements de transactions spécifiques dans des modules Oracle Fusion SCM tels qu’Order Management et Inventory Management. Exemples RMA crééeArticle reçuAvoir crééRemboursement traité
	Heure de l’événement EventTime	Horodatage indiquant le moment où une activité ou un événement précis s’est produit.
Description L’heure de l’événement, ou heure de début, correspond à la date et à l’heure précises auxquelles une activité a été enregistrée dans le système source. Elle situe chaque étape du processus dans le temps. Cet horodatage est indispensable à toute analyse temporelle. Il sert à remettre les événements dans le bon ordre, à calculer les temps de cycle entre les activités, à mesurer la durée totale d’un dossier et à évaluer les performances au regard des accords de niveau de service (SLA). Sans horodatages exacts, il est impossible d’analyser l’efficacité du processus, de repérer les retards ou d’en comprendre le fonctionnement. Pourquoi est-ce important ? Cet attribut établit l’ordre chronologique des événements. Il est indispensable pour calculer les indicateurs de durée et repérer les goulots d’étranglement du processus. Où trouver ces données Cette information figure généralement dans un champ « Date de création », « Horodatage » ou « Date de dernière mise à jour » associé aux transactions ou aux enregistrements de statut dans Oracle Fusion SCM. Exemples 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
	ID du dossier de retour ReturnCaseId	Identifiant principal reliant toutes les activités associées à une demande de retour ou de remboursement d’un client.
Description L’ID du dossier de retour est l’identifiant unique du dossier pour l’ensemble du processus de retour et de remboursement. Il relie tous les événements, de la création de l’autorisation de retour de marchandise (RMA) au traitement final du remboursement et à la clôture du dossier. Dans une analyse de Process Mining, cet attribut est essentiel pour reconstituer le parcours complet de chaque retour. Il permet aux analystes de suivre tout le cycle de vie, de mesurer les temps de cycle totaux et de comprendre les différences de traitement entre les retours. Toutes les autres données au niveau des événements sont regroupées sous cet identifiant afin de présenter une vue cohérente du processus. Pourquoi est-ce important ? Cette clé est indispensable pour réunir tous les événements associés dans une seule instance de processus et permettre une analyse de bout en bout. Où trouver ces données Cet identifiant est généralement généré dans les modules Oracle Order Management ou Service au lancement d’une demande de retour. Exemples RMA-2023-00123RMA-2023-00456RMA-2023-00789
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation ou extraction des données depuis le système source.
Description Cet attribut indique la date de la dernière mise à jour du jeu de données dans son ensemble, et non celle de chaque événement. Connaître la date de la dernière mise à jour aide les utilisateurs à évaluer l’actualité de l’analyse. Ils peuvent interpréter correctement les Dashboards et les KPI en sachant s’ils consultent des informations en temps réel ou des données datant de quelques heures ou de plusieurs jours. Il s’agit d’une métadonnée essentielle à tout projet de Process Mining. Pourquoi est-ce important ? Cet attribut indique aux utilisateurs l’actualité des données et leur permet de tenir compte de leur contexte et de leur date lors de l’analyse. Où trouver ces données Cet horodatage est généré et ajouté pendant le processus d’extraction, de transformation et de chargement (ETL) des données. Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Système source SourceSystem	Système dont les données ont été extraites.
Description Cet attribut identifie le système d’information d’origine dans lequel les données de l’événement ont été enregistrées. Pour ce processus, il s’agit généralement d’« Oracle Fusion SCM ». Dans les environnements où plusieurs systèmes sont intégrés, ce champ est essentiel pour assurer la traçabilité des données et faciliter le diagnostic des problèmes. Il permet de confirmer leur origine et de filtrer l’analyse par système source, tout en préservant la qualité et le contexte des données. Pourquoi est-ce important ? Cet attribut précise l’origine des données, une information essentielle à leur validation et à leur analyse dans les environnements qui utilisent plusieurs systèmes. Où trouver ces données Il s’agit souvent d’une valeur statique ajoutée pendant le processus d’extraction, de transformation et de chargement (ETL) pour indiquer l’origine du jeu de données. Exemples Oracle Fusion SCMOracle SCM Cloud
	Agent de traitement ProcessingAgent	Utilisateur ou agent chargé d’exécuter une activité précise du processus de retour.
Description Cet attribut identifie l’employé ou l’utilisateur du système qui a effectué une tâche, par exemple approuver une RMA ou traiter un remboursement. Il peut aussi désigner une équipe ou un service si les affectations individuelles ne sont pas suivies. L’analyse des performances par agent est essentielle à la gestion opérationnelle. Cet attribut permet d’alimenter le Dashboard « Performance des agents chargés du traitement des retours » et de comparer la charge de travail, la durée des activités et les taux de reprises entre agents. Ces analyses peuvent révéler des besoins de formation, repérer les personnes les plus performantes et éclairer la répartition des ressources. Pourquoi est-ce important ? Cet attribut permet d’analyser les performances par utilisateur ou par équipe, de repérer les personnes les plus performantes, les besoins de formation et les déséquilibres de charge de travail. Où trouver ces données Ces informations figurent généralement dans des champs tels que « USER_ID », « PROCESSED_BY » ou « AGENT_NAME » des journaux de transactions Oracle Fusion SCM. Exemples j.doea.smithm.jones
	Date cible du remboursement selon le SLA RefundSlaTargetDate	Date à laquelle le remboursement doit être effectué conformément à l’accord de niveau de service.
Description Cet attribut définit la date limite de traitement du remboursement pour un dossier donné. La cible du SLA dépend souvent de la politique de l’entreprise, du niveau de service du client ou du motif du retour. Cette date sert de référence pour mesurer le respect des délais et des engagements. Elle est directement utilisée dans le Dashboard « Respect du SLA de la politique de remboursement » et permet de calculer l’indicateur « Taux de respect du SLA de remboursement ». La comparaison entre la date réelle de traitement du remboursement et cette cible permet de repérer les dépassements du SLA et de prioriser les dossiers susceptibles d’être en retard. Pourquoi est-ce important ? Sert de référence pour mesurer le respect des délais et permet de calculer les indicateurs de conformité au SLA. Où trouver ces données Il peut s’agir d’un champ de date propre au dossier de retour ou d’une date à calculer en ajoutant une période prédéfinie, par exemple 14 jours, à la date d’ouverture du retour. Exemples 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z
	Heure de fin EndTime	Horodatage indiquant le moment où une activité a été terminée.
Description L’heure de fin marque l’achèvement d’une activité. L’heure de début indique quand un événement a commencé, tandis que l’heure de fin permet de calculer sa durée réelle de traitement. Pour un événement instantané, les heures de début et de fin peuvent être identiques. Dans une analyse, la différence entre l’heure de fin et l’heure de début donne la durée de traitement d’une activité. Elle permet de repérer les étapes qui prennent du temps, par opposition aux temps d’attente entre les étapes. Cette information est essentielle à l’analyse détaillée des goulots d’étranglement et à l’évaluation de l’efficacité des ressources. Pourquoi est-ce important ? Cet attribut est nécessaire pour calculer la durée réelle de traitement de chaque activité et distinguer le temps de travail effectif du temps d’attente. Où trouver ces données Cette information peut figurer dans un champ distinct des journaux du système source ou être déduite de l’heure de début de l’activité suivante. Exemples 2023-10-26T10:05:00Z2023-10-26T15:00:10Z2023-10-27T11:30:00Z
	Montant du remboursement demandé RequestedRefundAmount	Montant que le client a initialement demandé pour le retour.
Description Cet attribut indique le montant du remboursement demandé par le client au début du processus. Il sert de référence pour le comparer au montant finalement remboursé. Cette donnée est essentielle au Dashboard « Montants des remboursements demandés et réels » et à l’indicateur « Taux d’écart des montants remboursés ». L’analyse de l’écart entre les montants demandés et réels peut révéler des problèmes, comme le retour d’un article incorrect, des frais de remise en stock ou des ajustements liés à la politique de retour. Elle permet ainsi d’évaluer la précision financière et la satisfaction client. Pourquoi est-ce important ? Sert de référence pour l’analyse financière, permet de calculer les écarts de remboursement et de repérer les problèmes potentiels. Où trouver ces données Cette valeur doit être enregistrée dans l’en-tête de la demande RMA ou de retour, probablement dans le module Order Management d’Oracle Fusion SCM. Exemples 129.9945.501200.00
	Montant réel du remboursement ActualRefundAmount	Montant final effectivement traité et remboursé au client.
Description Cet attribut correspond au montant final confirmé, versé au client après les inspections, les ajustements et l’application des frais. Il reflète le résultat financier réel du dossier de retour. Cette donnée financière essentielle figure dans le Dashboard « Montants des remboursements demandés et réels ». Sa comparaison avec le montant demandé permet de calculer l’indicateur « Taux d’écart des montants remboursés » et de comprendre l’incidence financière des politiques de retour, de l’état des articles et des ajustements apportés au traitement. Pourquoi est-ce important ? Représente le résultat financier réel du retour et permet d’analyser les écarts et d’établir des rapports financiers. Où trouver ces données Cette information provient probablement des avoirs ou des écritures fournisseurs associés au dossier de retour dans Oracle Fusion Financials. Exemples 129.9940.000.00
	Motif du retour ReturnReason	Motif indiqué par le client pour le retour de l’article.
Description Cet attribut indique le motif du retour, généralement choisi par le client dans une liste prédéfinie, par exemple « Article défectueux », « Mauvaise taille » ou « N’est plus nécessaire ». L’analyse des motifs de retour permet de mieux comprendre la qualité des produits, la précision du processus de vente et le comportement des clients. Ces données peuvent servir à repérer les produits présentant un taux de défaut élevé, à améliorer les descriptions pour limiter les erreurs de commande et à comprendre les causes profondes des retours. Les résultats peuvent orienter des améliorations qui réduisent le volume global des retours. Pourquoi est-ce important ? Indique les raisons des retours et permet d’améliorer les produits et les processus de vente. Où trouver ces données Généralement enregistré sous forme de code ou de texte sur la ligne RMA dans Oracle Order Management. Exemples DéfectueuxMauvais article expédiéArrivé trop tardPrix plus avantageux disponible
	Statut du retour ReturnStatus	Statut actuel ou final du dossier de retour.
Description Cet attribut indique le statut général du dossier de retour à un moment donné ou son résultat final, par exemple « Clôturé, remboursé », « Clôturé, rejeté » ou « En cours ». Le statut du retour est essentiel à l’analyse des résultats et au suivi du processus. Il permet de filtrer les dossiers selon leur résultat, de comparer les parcours des retours approuvés et rejetés, et d’alimenter le Dashboard « Statut actuel des dossiers de retour ». Comprendre la répartition des résultats est indispensable pour mesurer l’efficacité du processus. Pourquoi est-ce important ? Cet attribut indique le résultat d’un dossier. Il est essentiel pour filtrer les données, comparer les résultats et comprendre le taux de réussite du processus. Où trouver ces données Cette information est généralement disponible dans un champ de statut de l’en-tête principal de la commande de retour ou de la RMA dans Oracle Order Management. Exemples En attente de réceptionInspection terminéeClôturé : rembourséClôturé : refusé
	Code de traitement final DispositionCode	Code indiquant le traitement final de l’article physique retourné.
Description Le code de traitement final précise ce qu’il advient du produit retourné après inspection : remise en stock, mise au rebut, reconditionnement ou retour au fournisseur, par exemple. Ces informations permettent d’analyser les conséquences financières et opérationnelles des retours. L’analyse des codes de traitement final aide l’entreprise à comprendre le coût des articles invendables et à repérer des possibilités d’amélioration du reconditionnement. Elle relie le processus de retour aux résultats liés aux stocks et aux finances. Pourquoi est-ce important ? Relie le processus de retour au devenir physique de l’article dans les stocks et permet d’analyser les taux et les coûts de récupération. Où trouver ces données Cette information est enregistrée dans les modules Oracle Inventory Management ou Warehouse Management une fois l’inspection terminée. Exemples RETURN_TO_STOCKSCRAPREFURBISHRETURN_TO_VENDOR
	Écart du montant remboursé RefundAmountDiscrepancy	Différence calculée entre le montant du remboursement demandé et le montant réellement remboursé.
Description Cette métrique mesure l’écart entre le montant demandé par le client et celui qu’il a reçu. Elle est calculée en soustrayant « ActualRefundAmount » de « RequestedRefundAmount ». Cette valeur calculée sert de base à l’indicateur « Taux d’écart des montants remboursés ». Une valeur non nulle indique qu’un ajustement a été effectué au cours du processus. L’analyse des causes de ces écarts, comme les frais de remise en stock ou les retenues pour dommages, permet d’évaluer l’efficacité des politiques et la qualité de la communication avec les clients. Pourquoi est-ce important ? Mesure les ajustements financiers apportés au remboursement et permet d’analyser l’incidence des politiques et des résultats d’inspection. Où trouver ces données Champ calculé : « RequestedRefundAmount » - « ActualRefundAmount ». Exemples 0.005.50-10.00
	ID de l’entrepôt WarehouseId	Identifiant de l’entrepôt ou du site ayant réceptionné l’article retourné.
Description Cet attribut indique le lieu physique précis, par exemple un centre de distribution ou un entrepôt, où l’article retourné par le client a été réceptionné et traité. L’analyse du processus par entrepôt permet de repérer les problèmes de performance propres à chaque site. Elle facilite la comparaison des délais d’inspection, des décisions de traitement final et des temps de cycle entre les différents sites. Elle peut ainsi mettre en évidence des inefficacités opérationnelles, des problèmes d’effectifs ou des besoins de formation. Pourquoi est-ce important ? Permet d’analyser les performances par site et de repérer les goulots d’étranglement et les inefficacités propres à une région ou à un établissement. Où trouver ces données Ce champ, souvent nommé « ORGANIZATION_ID », est associé à la transaction de réception dans Oracle Inventory Management. Exemples WH-US-WESTWH-EU-CENTRALDC-01
	ID du client CustomerId	Identifiant unique du client à l’origine du retour.
Description Cet attribut est l’identifiant unique du client associé au dossier de retour. Il relie le processus de retour à la base de données clients. L’analyse des retours du point de vue du client peut révéler des tendances importantes. Elle peut, par exemple, aider à repérer les clients qui retournent des articles à une fréquence inhabituelle, ce qui peut signaler un problème de satisfaction ou une fraude potentielle. Elle permet aussi d’analyser les retours par segment de clientèle et de déterminer si certains groupes ont des comportements différents. Pourquoi est-ce important ? Permet une analyse centrée sur le client afin de repérer les retours répétés, de comparer les comportements par segment et de détecter les fraudes potentielles. Où trouver ces données Identifiant du client ou de la partie figurant dans l’en-tête de la commande initiale ou de la demande de retour dans Oracle Order Management. Exemples CUST-100589743ACC-54321
	ID du produit ProductId	Identifiant unique du produit retourné.
Description Cet attribut est l’identifiant unique, tel qu’une référence SKU ou un numéro d’article, du produit concerné par le retour. Il relie le processus de retour au catalogue de produits. L’analyse par produit est essentielle pour repérer les articles problématiques. En filtrant ou en ventilant l’analyse du processus par ID du produit, les entreprises peuvent identifier les produits qui présentent un taux de retour élevé, des délais d’inspection longs ou des types de défauts particuliers. Ces informations sont importantes pour le contrôle qualité, la gestion de la chaîne d’approvisionnement et le développement des produits. Pourquoi est-ce important ? Relie le processus de retour aux produits concernés et permet d’analyser leur qualité ainsi que les tendances des retours. Où trouver ces données Il s’agit du champ « INVENTORY_ITEM_ID » ou d’un champ similaire sur la ligne RMA dans les modules Oracle Order Management ou Inventory. Exemples PROD-5540-ASKU-98765ITEM-001-B
	Numéro RMA RmaNumber	Identifiant unique de la transaction d’autorisation de retour de marchandise.
Description Le numéro RMA est une autorisation officielle permettant au client de retourner un produit. Il correspond souvent à l’ID du dossier de retour, mais certains systèmes utilisent un identifiant distinct, attribué au préalable. Cet attribut sert de référence commerciale, connue des équipes internes comme des clients. Il permet de rechercher et de filtrer les dossiers et constitue souvent le numéro principal utilisé dans les échanges au sujet du retour. Pourquoi est-ce important ? Sert de référence commerciale principale pour le suivi opérationnel et les échanges avec les clients. Où trouver ces données Il s’agit de l’identifiant principal de l’objet d’autorisation de retour de marchandise dans Oracle Order Management. Exemples 789001789002789003
	Reprise IsRework	Indicateur booléen précisant si une activité fait partie d’une boucle de reprise.
Description Cet indicateur repère les activités qui répètent des étapes antérieures du même dossier, signe d’une boucle ou d’une reprise. Par exemple, si un article échoue à l’inspection et doit être inspecté à nouveau, le second événement d’inspection est signalé comme une reprise. Cet attribut est essentiel pour quantifier les inefficacités du processus. Il est utilisé dans le Dashboard « Taux de reprise du traitement des retours » et pour calculer l’indicateur « Fréquence des événements de reprise des retours ». Repérer le volume et les causes des reprises est un objectif majeur du Process Mining, car elles révèlent directement le travail inutile, les retards et les coûts supplémentaires. Pourquoi est-ce important ? Signale directement les inefficacités et les boucles du processus, ce qui facilite la mesure et l’analyse des causes des reprises. Où trouver ces données Il s’agit d’un attribut calculé par les algorithmes du logiciel de Process Mining, qui détectent les activités répétées au sein d’un même dossier. Exemples truefalse
	Respect du SLA IsSlaCompliant	Indicateur booléen précisant si le remboursement a été traité dans le délai cible défini par le SLA.
Description Cet attribut calculé indique simplement, par vrai ou faux, si chaque dossier de retour respecte le SLA. Il est déterminé en comparant l’horodatage réel de fin du remboursement à « RefundSlaTargetDate ». Cet indicateur facilite la mesure et la visualisation des taux de conformité. Il alimente le Dashboard « Respect du SLA de la politique de remboursement » et simplifie le calcul de l’indicateur « Taux de respect du SLA de remboursement ». Il permet de filtrer rapidement les dossiers et d’en analyser les causes profondes pour comprendre pourquoi certains ne respectent pas le SLA. Pourquoi est-ce important ? Simplifie le suivi et le reporting du SLA en transformant la comparaison de dates en un indicateur booléen. Où trouver ces données Champ calculé. La valeur est vraie si l’horodatage « Refund Processed » est antérieur ou égal à « RefundSlaTargetDate », et fausse dans le cas contraire. Exemples truefalse
	Type de retour ReturnType	Classe le retour selon le résultat attendu, par exemple un remboursement, un échange ou une réparation.
Description Cet attribut classe le type de retour traité. Le déroulement du processus et les étapes requises peuvent varier considérablement selon que le client reçoit un remboursement, un produit de remplacement ou un article réparé. L’analyse du processus par type de retour est essentielle pour comprendre ses différentes variantes. Elle permet de créer des cartes de processus distinctes pour les remboursements et les échanges, afin de repérer les goulots d’étranglement et les caractéristiques de performance propres à chaque parcours. Cette segmentation aide à cibler les efforts d’amélioration. Pourquoi est-ce important ? Permet de segmenter l’analyse selon les différents parcours du processus, car les échanges et les remboursements suivent souvent des étapes distinctes. Où trouver ces données Il s’agit généralement d’un champ de catégorie ou de type dans l’en-tête ou sur la ligne RMA d’Oracle Order Management. Exemples RemboursementÉchangeRéparation

Obligatoire Recommandé Facultatif

Activités de traitement des retours et des remboursements

Voici les principales étapes et les jalons à enregistrer dans votre journal d’événements pour découvrir le processus avec précision et repérer les goulots d’étranglement.

7 Recommandé 8 Facultatif

	Activité	Description
	Article inspecté	Cette activité marque la fin de l’inspection de l’article et l’enregistrement de son évaluation qualité. Elle correspond généralement à une transaction explicite dans Oracle Inventory Management ou Quality Management, qui met à jour le statut de la RMA.
Pourquoi est-ce important ? Le résultat de l’inspection détermine directement les étapes suivantes, comme l’approbation ou le rejet du remboursement. La durée de l’inspection est un indicateur clé de l’efficacité de l’entrepôt. Où trouver ces données Cet événement est enregistré à partir de l’horodatage de la transaction effectuée lorsque l’inspecteur termine l’inspection de la réception liée à la RMA dans Oracle Inventory ou Quality Management. Données à recueillir Utilisez l’horodatage de fin de la transaction d’inspection. Type d’événement explicit
	Article reçu	Cette activité marque la réception physique de l’article retourné dans l’entrepôt ou le centre de traitement. Il s’agit d’un événement explicite enregistré dans Oracle Fusion Inventory Management lorsque les marchandises sont scannées et déclarées reçues au titre de la RMA.
Pourquoi est-ce important ? La réception de l’article est une étape importante qui déclenche l’inspection et les étapes de traitement suivantes. Mesurer le délai entre « RMA approuvée » et « Article reçu » permet d’analyser les performances logistiques et d’expédition. Où trouver ces données Il s’agit d’une transaction explicite enregistrée dans Oracle Inventory Management. L’événement correspond à la date de transaction de la réception liée à la RMA. Données à recueillir Utilisez l’horodatage de la transaction de réception de la RMA dans Inventory. Type d’événement explicit
	Avoir créé	Cette activité financière correspond à la création d’un avoir dans Accounts Receivable pour autoriser le remboursement du client. Il s’agit d’un événement explicite déclenché par le processus de retour dans Order Management.
Pourquoi est-ce important ? La création d’un avoir marque une étape décisive : l’entreprise s’engage à rembourser le client. Elle déclenche la phase de règlement financier du processus. Où trouver ces données Il s’agit d’une transaction explicite dans Oracle Accounts Receivable. La référence à la commande de vente figurant sur l’avoir permet de relier l’événement à la RMA d’origine. Données à recueillir Utilisez la date de création de la transaction d’avoir dans AR. Type d’événement explicit
	Dossier de retour clôturé	Il s’agit de la dernière activité : toutes les opérations liées à la RMA sont terminées, y compris la réception, la décision sur le sort de l’article et le règlement financier. Cet événement est déduit du statut final « Clôturé » de la commande RMA.
Pourquoi est-ce important ? Cet événement marque la fin définitive du processus. Il est essentiel pour calculer le temps de cycle de bout en bout et vérifier qu’aucun dossier ne reste ouvert indéfiniment. Où trouver ces données Cet événement est déduit de l’horodatage auquel l’en-tête de commande RMA et toutes ses lignes atteignent le statut final « Clôturé » dans Oracle Order Management. Données à recueillir Enregistrez le dernier horodatage auquel le statut de l’en-tête ou de la ligne RMA passe à « Clôturé ». Type d’événement inferred
	Remboursement traité	Cette activité marque la fin du paiement du remboursement au client. Il s’agit d’un événement explicite enregistré lorsque la transaction de compensation du paiement est saisie dans Oracle Financials.
Pourquoi est-ce important ? Cette étape marque la fin du temps de cycle total du remboursement du point de vue du client. Elle confirme que l’obligation financière envers le client a été honorée. Où trouver ces données Cet événement est enregistré à partir de la date comptable ou de compensation de la transaction de paiement dans Oracle Accounts Payable ou Treasury, qui règle l’avoir. Données à recueillir Utilisez la date de compensation de la transaction de paiement qui règle l’avoir. Type d’événement explicit
	RMA approuvée	Cette étape importante confirme que la demande de retour a été validée et approuvée conformément aux règles métier. Elle est généralement déduite d’un changement de statut de la RMA et permet de passer aux étapes suivantes, comme l’expédition par le client.
Pourquoi est-ce important ? L’approbation est une étape déterminante du processus. Tout retard à ce stade allonge directement le temps de cycle total du retour et peut nuire à la satisfaction client. Cette activité est essentielle pour analyser les goulots d’étranglement liés aux approbations. Où trouver ces données Cet événement est déduit de l’horodatage auquel le statut de l’en-tête ou de la ligne de commande RMA passe à « Approuvé » ou « En attente de réception ». Données à recueillir Enregistrez l’horodatage de la mise à jour du statut de la RMA à l’état approuvé. Type d’événement inferred
	RMA créée	Cette activité marque le début officiel du processus de retour : une autorisation de retour de marchandise (RMA) est créée dans Oracle Fusion SCM. L’événement est généralement enregistré lorsqu’un utilisateur ou un processus automatisé génère une nouvelle commande de vente RMA.
Pourquoi est-ce important ? Il s’agit de l’événement de début principal de l’ensemble du processus de retour. L’analyse du délai entre cette activité et les suivantes révèle la durée totale du processus et aide à repérer les premiers retards. Où trouver ces données Cet événement est enregistré à partir de l’horodatage de création de l’en-tête de commande de retour dans Oracle Fusion Order Management. Il correspond à l’enregistrement initial du document RMA. Données à recueillir Suivez la date de création de l’enregistrement de l’en-tête de commande de retour. Type d’événement explicit
	Article expédié par le client	Cet événement correspond à l’expédition de l’article retourné par le client à l’entreprise. Il n’est souvent pas enregistré directement dans Oracle SCM, mais peut être déduit des données d’intégration du transporteur ou d’une mise à jour manuelle.
Pourquoi est-ce important ? Cette activité renseigne sur le comportement du client et sur le temps de transport des marchandises. Elle permet de distinguer les retards de traitement internes de ceux liés à l’expédition. Où trouver ces données Cet événement peut être déduit des données d’expédition du transporteur associées à la RMA ou d’une mise à jour manuelle du statut dans Oracle SCM. En l’absence d’intégration, il peut ne pas être disponible. Données à recueillir Horodatage provenant de l’API intégrée du transporteur ou d’un champ de saisie manuelle. Type d’événement inferred
	Client informé	Cet événement correspond au message envoyé au client pour confirmer la résolution de son dossier de retour, par exemple le traitement du remboursement ou l’expédition d’un article de remplacement. Il est souvent enregistré dans un journal de communication ou au moyen d’une mise à jour du statut du dossier.
Pourquoi est-ce important ? Une communication rapide avec le client est essentielle à sa satisfaction. L’analyse de cette activité permet de vérifier que les accords de niveau de service en matière de communication sont respectés. Où trouver ces données Une analyse du système est nécessaire. L’événement peut être enregistré par un CRM intégré ou une plateforme de communication, ou correspondre à une mise à jour manuelle du statut de la RMA ou d’une demande de service associée. Données à recueillir Horodatage provenant d’un système de communication externe ou d’une mise à jour manuelle. Type d’événement inferred
	Commande d’échange créée	Cette activité intervient lorsque le client demande un échange plutôt qu’un remboursement. Il s’agit d’un événement explicite correspondant à la création d’une nouvelle commande de vente, souvent liée à la RMA d’origine.
Pourquoi est-ce important ? Cette activité signale une variante importante du processus. Il est essentiel de distinguer les échanges des remboursements pour analyser correctement le temps de cycle de chaque parcours. Où trouver ces données Il s’agit d’un événement explicite : la création d’un nouveau document de commande de vente dans Order Management. Un champ de référence permet de le relier à la RMA. Données à recueillir Utilisez la date de création de la nouvelle commande de vente liée à la RMA. Type d’événement explicit
	Décision sur le sort de l’article retourné	Après l’inspection, cette activité correspond à la décision concernant le sort de l’article retourné, par exemple « Remettre en stock » ou « Mettre au rebut ». Elle est enregistrée au moyen d’une transaction de stock explicite qui déplace l’article vers sa destination finale.
Pourquoi est-ce important ? Cette étape est essentielle à l’exactitude des stocks et au rapprochement financier. L’analyse des décisions sur le sort des articles aide à comprendre les motifs de retour et les problèmes de qualité des produits. Où trouver ces données Cet événement est enregistré dans Oracle Inventory Management sous la forme d’une transaction, par exemple un transfert entre sous-stocks ou une mise à jour du statut de l’article, après l’inspection. Données à recueillir Suivez l’horodatage de la transaction de stock qui met en œuvre la décision sur le sort de l’article. Type d’événement explicit
	Demande d’approbation de la RMA soumise	Cet événement correspond au moment où la RMA créée est soumise à un examen et à une approbation internes. Il est souvent déduit d’un changement de statut de la RMA, qui passe de l’état brouillon ou saisie à l’état en attente d’approbation.
Pourquoi est-ce important ? Son suivi permet de mesurer la durée de la phase précédant l’approbation. Il distingue le temps de saisie des données du temps d’attente avant l’intervention d’un approbateur. Où trouver ces données Cet événement est déduit de l’horodatage auquel le statut de l’en-tête ou de la ligne de commande RMA passe à « En attente d’approbation » ou à un statut équivalent dans le flux de travail d’approbation d’Order Management. Données à recueillir Repérez l’horodatage du changement de statut à « En attente d’approbation ». Type d’événement inferred
	Inspection de l’article commencée	Cet événement indique le début de l’inspection physique de l’article retourné afin d’en évaluer l’état. Il peut être déduit d’un changement d’emplacement ou de statut de l’article dans le module de gestion d’entrepôt, ou correspondre à un scan explicite.
Pourquoi est-ce important ? Mesurer le délai entre la réception de l’article et le début de l’inspection permet de repérer les attentes dans la file d’inspection, un goulot d’étranglement fréquent. Où trouver ces données Cet événement peut être enregistré à la suite d’un changement de statut de la ligne de réception ou d’une transaction qui déplace l’article vers un emplacement d’inspection dans Oracle Inventory Management. Une configuration personnalisée peut être nécessaire pour l’enregistrer explicitement. Données à recueillir Horodatage d’un changement de statut ou d’un transfert de stock vers une zone d’inspection. Type d’événement inferred
	Remboursement lancé	Cette activité indique le début du processus de paiement du remboursement. Elle est souvent déduite d’un changement de statut de l’avoir, qui passe de l’état ouvert à un état indiquant que le paiement est en cours de traitement.
Pourquoi est-ce important ? Cette activité permet de distinguer l’approbation et la création de l’avoir du traitement du paiement proprement dit. Celui-ci peut être pris en charge par une autre équipe ou un autre système et être à l’origine de retards. Où trouver ces données Cet événement est déduit d’un changement de statut de l’avoir dans Accounts Receivable ou de la création, dans Accounts Payable, d’un enregistrement de paiement faisant référence à l’avoir. Données à recueillir Repérez l’horodatage auquel le statut de l’avoir passe à « En attente de paiement » ou à un statut similaire. Type d’événement inferred
	RMA rejetée	Cet événement correspond à la décision définitive de rejeter la demande de retour du client. Il est généralement déduit d’un changement de statut de la RMA à « Rejeté » ou « Annulé » pendant la phase d’approbation.
Pourquoi est-ce important ? Il s’agit d’un parcours d’exception important. L’analyse de la fréquence et des motifs de rejet peut révéler des problèmes liés aux politiques de retour, aux attentes des clients ou à des tentatives de fraude. Où trouver ces données Cet événement est déduit de l’horodatage auquel le statut de l’en-tête ou de la ligne de commande RMA passe à « Rejeté » ou à un statut final équivalent. Données à recueillir Repérez l’horodatage du changement de statut à « Rejeté » ou « Annulé ». Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données d’Oracle Fusion SCM

Étapes

Accédez à l’éditeur d’analyse OTBI : Connectez-vous à votre instance Oracle Fusion Cloud SCM. Dans le menu Navigator, accédez à Tools, puis sélectionnez Reports and Analytics. Cliquez sur le bouton « Create » et choisissez « Analysis » dans le menu déroulant.
Sélectionnez les domaines fonctionnels : Dans la fenêtre « Select Subject Area », choisissez les principaux domaines fonctionnels contenant les données sur les retours et les remboursements. Sélectionnez « Sales - CRM All Lines » et « Receivables - Transactions Real Time ». Vous combinerez ces domaines pour obtenir une vue complète du processus.
Passez en mode avancé : Après avoir sélectionné les domaines fonctionnels, l’éditeur d’analyse s’ouvre. Passez immédiatement à l’onglet « Advanced » pour accéder à l’éditeur SQL logique, nécessaire à la création de la structure du journal d’événements.
Rédigez la requête du journal d’événements : Copiez l’intégralité du SQL logique fourni dans la section « Query » de ce document, puis collez-le dans la zone de texte « SQL Query » de l’onglet Advanced. Cette requête utilise plusieurs clauses UNION ALL pour récupérer chacune des 15 activités requises sur une ligne distincte.
Définissez les paramètres de la requête : Modifiez les valeurs de remplacement dans la requête. Remplacez notamment [START_DATE] et [END_DATE] pour définir la période d’extraction. Vous devrez peut-être aussi ajuster les filtres selon les unités opérationnelles ou les types de commande de retour configurés dans votre organisation.
Validez la requête : Cliquez sur le bouton « Validate SQL » pour vérifier la syntaxe. Le système contrôle les noms et la structure des colonnes par rapport aux domaines fonctionnels sélectionnés.
Examinez les résultats : Accédez à l’onglet « Results » pour prévisualiser le résultat. Les données doivent apparaître sous la forme d’un journal d’événements, chaque ligne correspondant à une activité distincte du processus de retour. Vérifiez que les colonnes telles que ReturnCaseId, ActivityName et EventTime sont renseignées comme prévu.
Enregistrez l’analyse : Lorsque les résultats vous conviennent, cliquez sur l’icône « Save Analysis ». Donnez-lui un nom explicite, par exemple « ProcessMind Returns and Refund Extraction », puis enregistrez-la dans un dossier partagé.
Planifiez l’exportation : Pour automatiser l’extraction, vous pouvez programmer l’exécution régulière de l’analyse. Depuis la page d’accueil Oracle BI, recherchez l’analyse enregistrée, cliquez sur « More », puis sélectionnez « Schedule ».
Configurez la tâche d’exportation : Dans les options de planification, définissez la fréquence, par exemple quotidienne ou hebdomadaire. Dans la section « Delivery », choisissez le format CSV. Configurez la destination, par exemple le serveur de contenu ou une adresse e-mail, où le fichier sera envoyé. Activez la planification pour lancer les extractions automatiques.

Configuration

Domaines fonctionnels : Les principaux domaines fonctionnels de cette analyse sont « Sales - CRM All Lines », qui contient les en-têtes et les lignes des commandes RMA ainsi que l’historique de leur statut, et « Receivables - Transactions Real Time », qui contient les détails des avoirs et des paiements de remboursement. D’autres domaines, comme « Inventory - Inventory Transactions Real Time », peuvent être nécessaires pour obtenir des informations plus détaillées sur l’inspection et la décision concernant les articles.
Filtrage par période : Il est essentiel d’appliquer un filtre de dates pour limiter le volume de données et garantir la bonne exécution de l’analyse. Nous recommandons d’extraire les données par périodes de 3 à 6 mois. La requête fournie filtre les données selon la date de création de la RMA.
Filtres principaux : En plus de la période, filtrez les données par type de commande afin de sélectionner uniquement les commandes d’autorisation de retour de marchandise (RMA). Il est également recommandé de filtrer par unité opérationnelle ou entité juridique pour définir précisément le périmètre des données.
Mode SQL logique : Cette méthode d’extraction nécessite l’onglet « Advanced » et une requête SQL logique personnalisée utilisant des instructions UNION ALL. Cette approche permet de restructurer les données transactionnelles au format de journal d’événements requis par ProcessMind.
Prérequis : La personne qui exécute l’extraction doit disposer d’un rôle lui permettant de créer et d’exécuter des analyses OTBI, tel que le rôle « BI Author ». L’accès aux domaines fonctionnels Sales, Receivables et, éventuellement, Inventory est également indispensable.

a Exemple de requête sql

SELECT
    "Sales - CRM All Lines"."Order"."Order Number" AS "ReturnCaseId",
    'RMA Created' AS "ActivityName",
    CAST("Sales - CRM All Lines"."Order"."Creation Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Sales - CRM All Lines"."Order"."Created By" AS "ProcessingAgent",
    "Sales - CRM All Lines"."Order"."Header Status" AS "ReturnStatus",
    "Sales - CRM All Lines"."Order"."Order Amount" AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    "Sales - CRM All Lines"."Order"."Return Reason" AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines"
WHERE "Sales - CRM All Lines"."Order"."Order Type" = 'Return'
AND "Sales - CRM All Lines"."Order"."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'RMA Approval Submitted' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" = 'Pending Approval' AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'RMA Approved' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" = 'Awaiting Receiving' AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Item Shipped By Customer' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: This event is not standard. Adapt if custom fields exist.
UNION ALL
SELECT
    "Sales - CRM All Lines"."Order"."Order Number" AS "ReturnCaseId",
    'Item Received' AS "ActivityName",
    CAST("Sales - CRM All Lines"."Fulfillment Line"."Actual Arrival Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Sales - CRM All Lines"."Fulfillment Line"."Last Updated By" AS "ProcessingAgent",
    "Sales - CRM All Lines"."Fulfillment Line"."Fulfillment Line Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines"
WHERE "Sales - CRM All Lines"."Order"."Order Type" = 'Return' AND "Sales - CRM All Lines"."Fulfillment Line"."Actual Arrival Date" IS NOT NULL
AND "Sales - CRM All Lines"."Order"."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Item Inspection Started' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires Inventory subject area or custom fields.
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Item Inspected' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires Inventory subject area or custom fields.
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Return Disposition Determined' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires Inventory subject area.
UNION ALL
SELECT
    "Receivables - Transactions Real Time"."Transaction Details"."Reference Transaction Number" AS "ReturnCaseId",
    'Credit Memo Created' AS "ActivityName",
    CAST("Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Receivables - Transactions Real Time"."Transaction Details"."Created By" AS "ProcessingAgent",
    "Receivables - Transactions Real Time"."Transaction Details"."Transaction Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    "Receivables - Transactions Real Time"."Transaction Details"."Transaction Amount" AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Receivables - Transactions Real Time"
WHERE "Receivables - Transactions Real Time"."Transaction Details"."Transaction Class" = 'Credit Memo'
AND "Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    "Receivables - Transactions Real Time"."Transaction Details"."Reference Transaction Number" AS "ReturnCaseId",
    'Refund Initiated' AS "ActivityName",
    CAST("Receivables - Transactions Real Time"."Receipt Application Details"."Application Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Created By" AS "ProcessingAgent",
    'Refund Initiated' AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Amount Applied" * -1 AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Receivables - Transactions Real Time"
WHERE "Receivables - Transactions Real Time"."Transaction Details"."Transaction Class" = 'Credit Memo'
AND "Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    "Receivables - Transactions Real Time"."Transaction Details"."Reference Transaction Number" AS "ReturnCaseId",
    'Refund Processed' AS "ActivityName",
    CAST("Receivables - Transactions Real Time"."Receipt Application Details"."GL Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Created By" AS "ProcessingAgent",
    'Refund Processed' AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    "Receivables - Transactions Real Time"."Receipt Application Details"."Amount Applied" * -1 AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Receivables - Transactions Real Time"
WHERE "Receivables - Transactions Real Time"."Transaction Details"."Transaction Class" = 'Credit Memo' AND "Receivables - Transactions Real Time"."Receipt Application Details"."GL Date" IS NOT NULL
AND "Receivables - Transactions Real Time"."Transaction Details"."Transaction Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Customer Notified' AS "ActivityName",
    CAST(NULL AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime", NULL AS "ProcessingAgent", NULL AS "ReturnStatus", NULL AS "RequestedRefundAmount", NULL AS "ActualRefundAmount", NULL AS "ReturnReason", NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654 WHERE T4654."Order Type" = 'Return' AND 1=0 -- Placeholder: Requires integration with a notification or CRM system.
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'Return Case Closed' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" = 'Closed' AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    T4654."Order Number" AS "ReturnCaseId",
    'RMA Rejected' AS "ActivityName",
    CAST(T4663."Status Change Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    T4663."Updated By" AS "ProcessingAgent",
    T4663."New Status" AS "ReturnStatus",
    NULL AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    NULL AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines" T4649, "Sales - CRM All Lines"."Order" T4654, "Sales - CRM All Lines"."Header Status History" T4663
WHERE T4654."Order Key" = T4663."Order Key" AND T4654."Order Type" = 'Return' AND T4663."New Status" IN ('Canceled', 'Rejected') AND T4654."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'
UNION ALL
SELECT
    "Sales - CRM All Lines"."Order"."Return Reference Order Number" AS "ReturnCaseId",
    'Exchange Order Created' AS "ActivityName",
    CAST("Sales - CRM All Lines"."Order"."Creation Date" AS TIMESTAMP) AS "EventTime",
    'Oracle Fusion SCM' AS "SourceSystem",
    CURRENT_TIMESTAMP AS "LastDataUpdate",
    NULL AS "EndTime",
    "Sales - CRM All Lines"."Order"."Created By" AS "ProcessingAgent",
    "Sales - CRM All Lines"."Order"."Header Status" AS "ReturnStatus",
    "Sales - CRM All Lines"."Order"."Order Amount" AS "RequestedRefundAmount",
    NULL AS "ActualRefundAmount",
    "Sales - CRM All Lines"."Order"."Return Reason" AS "ReturnReason",
    NULL AS "RefundSlaTargetDate"
FROM "Sales - CRM All Lines"
WHERE "Sales - CRM All Lines"."Order"."Return Reference Order Number" IS NOT NULL
AND "Sales - CRM All Lines"."Order"."Creation Date" BETWEEN TIMESTAMP '[START_DATE]' AND TIMESTAMP '[END_DATE]'

Étapes

Vérifiez que votre environnement dispose d’Oracle BI Cloud Connector, des domaines fonctionnels ou objets de vue SCM requis, de la livraison vers un stockage cloud et des sources de données nécessaires pour Oracle Fusion SCM, Inventory Management, Quality Management, Order Management, Accounts Receivable, les paiements et les communications. Confirmez les autorisations auprès de votre administrateur Oracle.
Repérez les objets de vue BICC configurés qui contiennent les informations sur l’en-tête du retour, l’historique des approbations, les transactions de réception, les dossiers d’inspection, les décisions concernant les articles, les avoirs, les remboursements, les commandes d’échange, les notifications et la clôture. RmaHeaderAll est un exemple d’objet de vue d’en-tête de retour. Dans le script d’extraction, remplacez chaque référence de source entre crochets par l’objet de vue correspondant ou l’extraction disponible dans votre environnement.
Configurez une tâche d’extraction BICC pour les objets de vue requis. Choisissez une extraction incrémentielle ou complète selon les champs de suivi des modifications disponibles, configurez la livraison vers le stockage cloud et définissez les dates de début et de fin de la période d’extraction. Utilisez [Configure based on your system] lorsque le nom de la tâche BICC, l’emplacement de stockage ou la configuration des objets de vue diffère.
Extrayez les données sources vers le stockage cloud. Conservez les identifiants sources, les horodatages des événements, les valeurs de statut, les identifiants des utilisateurs ou des agents, les montants, les motifs de retour, les dates SLA et l’horodatage d’actualisation BICC. Ne remplacez pas les horodatages sources lors de la consolidation des fichiers.
Chargez les fichiers livrés dans une zone de préparation. Normalisez les noms des colonnes sources selon les valeurs suivantes : ReturnCaseId, ActivityName, EventTime, SourceSystem, LastDataUpdate, EndTime, ProcessingAgent, ReturnStatus, RequestedRefundAmount, ActualRefundAmount, ReturnReason et RefundSlaTargetDate. Convertissez les horodatages dans un même fuseau horaire convenu et, si nécessaire, conservez séparément le fuseau horaire d’origine.
Appliquez les règles d’événement du script d’extraction. Chaque règle doit produire une ligne d’événement distincte. Les changements de statut utilisés pour déduire des activités doivent s’appuyer sur l’historique de statut pertinent ou sur un horodatage de dernière mise à jour fiable. Si l’historique des changements est nécessaire, ne vous fiez pas uniquement au statut actuel, car les événements antérieurs seraient omis.
Regroupez toutes les lignes d’événement propres à chaque activité, supprimez uniquement les doublons exacts dus à des livraisons répétées de la source et conservez les répétitions légitimes lorsque les enregistrements sources correspondent à des événements métier distincts. Vérifiez que ReturnCaseId est renseigné pour chaque ligne d’événement.
Enrichissez chaque événement avec les attributs de cas les plus récents, tout en préservant les valeurs propres à l’événement lorsqu’elles sont disponibles. Renseignez SourceSystem avec Oracle Fusion SCM ou le nom de la source configurée, et LastDataUpdate avec l’horodatage d’extraction BICC ou d’actualisation de la source.
Effectuez les contrôles de validation décrits ci-dessous. Vérifiez la présence des 15 noms d’activité requis, assurez-vous que les horodatages se situent dans la période d’extraction ou dans une période opérationnelle explicitement documentée, et confirmez que les activités terminales correspondent au statut final du retour.
Exportez le journal d’événements obtenu au format CSV ou dans un autre format pris en charge par ProcessMind. Incluez une ligne par événement et les colonnes exactes ReturnCaseId, ActivityName, EventTime, SourceSystem et LastDataUpdate, ainsi que les attributs recommandés lorsqu’ils sont disponibles. Importez le fichier dans ProcessMind et associez ReturnCaseId à l’identifiant du cas, ActivityName à l’activité et EventTime à l’horodatage de l’événement.

Configuration

Méthode d’extraction : Configurez Oracle BI Cloud Connector pour livrer en masse les objets de vue SCM requis et les objets associés vers un stockage cloud. La tâche BICC, le chemin de stockage et la disponibilité des objets de vue dépendent de votre environnement Oracle Fusion.
Objets sources : RmaHeaderAll peut fournir les informations sur l’en-tête du retour. L’historique des approbations, les réceptions, les inspections, les décisions concernant les articles, les avoirs, les remboursements, les échanges, les notifications et les clôtures peuvent nécessiter d’autres objets de vue ou extractions livrées. Utilisez [Your view object name] lorsqu’une source correspondante n’a pas été confirmée.
Période : Commencez par extraire 3 à 6 mois de données. N’élargissez la période qu’après avoir vérifié le volume, la disponibilité de l’historique des statuts et la capacité de stockage cloud. Pour les chargements incrémentiels, prévoyez une période de chevauchement afin de récupérer les mises à jour tardives.
Extraction incrémentielle : Privilégiez un horodatage de modification documenté ou un mécanisme incrémentiel pris en charge par BICC. Si seules les données d’état actuel sont disponibles, il est impossible de reconstituer de manière fiable les événements historiques déduits.
Filtres : N’appliquez des filtres par entreprise, unité opérationnelle, organisation de stock, type de document, type de retour, type de commande, unité opérationnelle ou statut qu’après avoir confirmé les champs sources et leur signification métier. Utilisez [Company-specific filter] et [Document type filter] pour les critères propres à votre environnement.
Horodatages des événements : Utilisez l’horodatage de l’événement métier lorsqu’il est disponible. N’utilisez un horodatage de statut ou de mise à jour de l’enregistrement que pour les événements déduits explicitement documentés, et consignez la règle de dérivation dans le dictionnaire de données.
Déduplication : Dédupliquez selon ReturnCaseId, ActivityName, EventTime, l’identifiant de l’événement source et le système source, lorsqu’ils sont disponibles. Ne fusionnez pas des événements distincts de réception, d’inspection ou de paiement au seul motif qu’ils partagent le même identifiant de cas.
Performances : Répartissez l’extraction par période, unité opérationnelle, organisation de stock ou autre partition prise en charge par la source. Dans les environnements à fort volume, évitez les extractions complètes sans restriction pendant les heures ouvrées. Surveillez la durée des tâches BICC, la taille des fichiers, la capacité de stockage cloud et les performances de la zone de préparation en aval.
Prérequis : Confirmez l’accès à BICC et au stockage cloud, la disponibilité des rôles Oracle Fusion requis, l’accès aux données SCM, Inventory Management, Quality Management, Order Management, Accounts Receivable, aux données de paiement et de communication, ainsi que les licences de reporting ou d’intégration nécessaires.
Sécurité : Utilisez des identifiants approuvés et un stockage cloud chiffré. Limitez les extractions aux attributs strictement nécessaires et appliquez les politiques de conservation et d’accès de votre organisation.
Disponibilité des sources : Certaines activités, notamment l’expédition au client, le début de l’inspection, le lancement du remboursement et la notification au client, peuvent nécessiter des données externes provenant du transporteur, de l’entrepôt, du système de paiement ou des outils de communication. Utilisez [Configure based on your system] lorsque ces sources ne sont pas fournies par BICC.

a Exemple de requête sql

WITH
source_data AS (
    SELECT
        r.return_case_id,
        r.created_timestamp,
        r.approval_submitted_timestamp,
        r.approved_timestamp,
        r.customer_shipped_timestamp,
        r.item_received_timestamp,
        r.inspection_started_timestamp,
        r.inspected_timestamp,
        r.disposition_determined_timestamp,
        r.credit_memo_created_timestamp,
        r.refund_initiated_timestamp,
        r.refund_processed_timestamp,
        r.customer_notified_timestamp,
        r.closed_timestamp,
        r.rejected_timestamp,
        r.exchange_order_created_timestamp,
        r.end_timestamp,
        r.processing_agent,
        r.return_status,
        r.requested_refund_amount,
        r.actual_refund_amount,
        r.return_reason,
        r.refund_sla_target_date,
        r.last_data_update
    FROM [Your configured return event source] r
    WHERE r.last_data_update >= [Start date parameter]
      AND r.last_data_update < [End date parameter]
      AND ([Company-specific filter])
),
events AS (
    SELECT return_case_id AS ReturnCaseId, 'RMA Created' AS ActivityName, created_timestamp AS EventTime, 'Oracle Fusion SCM' AS SourceSystem, last_data_update AS LastDataUpdate, end_timestamp AS EndTime, processing_agent AS ProcessingAgent, return_status AS ReturnStatus, requested_refund_amount AS RequestedRefundAmount, actual_refund_amount AS ActualRefundAmount, return_reason AS ReturnReason, refund_sla_target_date AS RefundSlaTargetDate FROM source_data WHERE created_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'RMA Approval Submitted', approval_submitted_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE approval_submitted_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'RMA Approved', approved_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE approved_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Shipped By Customer', customer_shipped_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE customer_shipped_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Received', item_received_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE item_received_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Inspection Started', inspection_started_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE inspection_started_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Item Inspected', inspected_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE inspected_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Return Disposition Determined', disposition_determined_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE disposition_determined_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Credit Memo Created', credit_memo_created_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE credit_memo_created_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Refund Initiated', refund_initiated_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE refund_initiated_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Refund Processed', refund_processed_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE refund_processed_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Customer Notified', customer_notified_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE customer_notified_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Return Case Closed', closed_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE closed_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'RMA Rejected', rejected_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE rejected_timestamp IS NOT NULL
    UNION ALL
    SELECT return_case_id, 'Exchange Order Created', exchange_order_created_timestamp, 'Oracle Fusion SCM', last_data_update, end_timestamp, processing_agent, return_status, requested_refund_amount, actual_refund_amount, return_reason, refund_sla_target_date FROM source_data WHERE exchange_order_created_timestamp IS NOT NULL
)
SELECT
    ReturnCaseId,
    ActivityName,
    EventTime,
    SourceSystem,
    LastDataUpdate,
    EndTime,
    ProcessingAgent,
    ReturnStatus,
    RequestedRefundAmount,
    ActualRefundAmount,
    ReturnReason,
    RefundSlaTargetDate
FROM events
WHERE ReturnCaseId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY ReturnCaseId, EventTime, ActivityName;

Étapes

Configurez l’environnement Python : Vérifiez que Python 3.6 ou une version ultérieure est installé. Installez les bibliothèques nécessaires avec pip : pip install requests pandas.
Configurez l’accès à Oracle Fusion SCM : Obtenez les identifiants d’un utilisateur Oracle disposant des rôles nécessaires pour accéder aux API REST. Il s’agit généralement des rôles Order Manager et Accounts Receivable Manager. L’utilisateur doit être autorisé à consulter les commandes client (RMA) et les avoirs clients.
Repérez les points de terminaison de l’API : Confirmez l’URL de base de votre instance Oracle Fusion SCM. Le script utilise les ressources REST salesOrdersForOrderHub et receivablesCreditMemos. Vous devrez peut-être adapter la version 11.13.18.05 à votre environnement.
Personnalisez le script Python : Ouvrez le script Python fourni. Modifiez les variables de remplacement en haut du script : ORACLE_BASE_URL, ORACLE_USERNAME et ORACLE_PASSWORD. Adaptez la variable RMA_ORDER_TYPE au code de type de commande RMA utilisé dans votre système.
Définissez la période d’extraction : Modifiez les variables START_DATE et END_DATE dans le script pour définir la période d’extraction des données. Pour tester le script, il est recommandé de commencer par une période plus courte, par exemple un mois.
Exécutez le script : Lancez le script depuis la ligne de commande : python extract_oracle_returns.py. Le script se connecte aux API Oracle, récupère et traite les données, puis affiche l’état d’avancement dans la console.
Récupérez le journal d’événements : Une fois l’exécution terminée, le script crée un fichier nommé returns_event_log.csv dans le même répertoire. Ce fichier contient le journal d’événements extrait.
Vérifiez le fichier avant l’importation : Ouvrez returns_event_log.csv dans un tableur. Vérifiez que les données sont complètes et exactes, en portant une attention particulière aux colonnes ActivityName et EventTime. Assurez-vous que les en-têtes de colonnes correspondent aux exigences de votre outil de Process Mining.
Importez les données dans ProcessMind : Importez directement le fichier CSV généré dans ProcessMind. Associez les colonnes du fichier aux attributs correspondants dans ProcessMind (ReturnCaseId à Case ID, ActivityName à Activity, EventTime à Timestamp).

Configuration

Points de terminaison de l’API : Le script utilise principalement deux points de terminaison d’API REST : /fscmRestApi/resources/11.13.18.05/salesOrdersForOrderHub pour les données des commandes RMA et /fscmRestApi/resources/11.13.18.05/receivablesCreditMemos pour les données financières des remboursements.
Authentification : Le script utilise l’authentification de base. Le nom d’utilisateur et le mot de passe fournis doivent correspondre à un compte disposant d’un accès à l’API et des privilèges nécessaires pour lire les données des commandes et des créances.
Période : L’extraction est filtrée selon la date CreationDate des commandes RMA. Configurez les variables START_DATE et END_DATE dans le script. Pour le chargement initial, une période de 3 à 6 mois est recommandée. Pour les actualisations régulières, utilisez une fenêtre glissante.
Filtre sur le type de commande RMA : Il est essentiel de configurer la variable RMA_ORDER_TYPE dans le script. Vous vous assurerez ainsi de n’extraire que les commandes de retour, et non les commandes de vente standard. Vous trouverez le code correspondant à votre type de commande RMA dans la tâche de configuration « Manage Order Types » d’Oracle Fusion.
Correspondance des codes de statut : Le script associe les codes de statut internes d’Oracle, par exemple DOO_AWAITING_RECEIVING et DOO_CLOSED, aux valeurs métier de ActivityName. Cette correspondance devra peut-être être adaptée à la configuration Oracle SCM de votre environnement.
Prérequis : Vous devez avoir accès à un environnement Oracle Fusion SCM. Le compte utilisé pour l’extraction doit disposer de rôles tels que Order Manager (ORA_DOO_ORDER_MANAGER_JOB) et Accounts Receivable Manager (ORA_AR_ACCOUNTS_RECEIVABLE_MANAGER_JOB), ou de rôles personnalisés équivalents donnant accès aux API REST requises.

a Exemple de requête python

import requests
import pandas as pd
from datetime import datetime
import json

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
ORACLE_BASE_URL = class="hl-string">"https://[your_oracle_fusion_instance].fa.ocs.oraclecloud.com"
ORACLE_USERNAME = class="hl-string">"[your_api_user]"
ORACLE_PASSWORD = class="hl-string">"[your_api_password]"
RMA_ORDER_TYPE = class="hl-string">"ORA_RETURN_ORDER"  class=class="hl-string">"hl-comment"># IMPORTANT: Configure with your specific RMA Order Type Code
START_DATE = class="hl-string">"2023-01-01T00:00:00.000Z" class=class="hl-string">"hl-comment"># Format: YYYY-MM-DDTHH:MM:SS.sssZ
END_DATE = class="hl-string">"2023-06-30T23:59:59.000Z"

class=class="hl-string">"hl-comment"># --- Helper Functions --- #
def get_paginated_data(endpoint, params):
    class="hl-string">"""Fetches all data from a paginated Oracle REST API endpoint."""
    all_items = []
    url = fclass="hl-string">"{ORACLE_BASE_URL}{endpoint}"
    params[class="hl-string">'limit'] = 200 class=class="hl-string">"hl-comment"># Max limit can be up to 500
    params[class="hl-string">'offset'] = 0

    while True:
        print(fclass="hl-string">"Fetching data from {url} with offset {params['offset']}...")
        try:
            response = requests.get(url, auth=(ORACLE_USERNAME, ORACLE_PASSWORD), params=params)
            response.raise_for_status()
            data = response.json()
            items = data.get(class="hl-string">'items', [])
            if not items:
                break
            all_items.extend(items)
            if data.get(class="hl-string">'hasMore', False):
                params[class="hl-string">'offset'] += len(items)
            else:
                break
        except requests.exceptions.HTTPError as e:
            print(fclass="hl-string">"HTTP Error: {e}")
            print(fclass="hl-string">"Response content: {response.text}")
            break
        except json.JSONDecodeError as e:
            print(fclass="hl-string">"JSON Decode Error: {e}")
            print(fclass="hl-string">"Response content: {response.text}")
            break
    return all_items

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- #
if __name__ == class="hl-string">"__main__":
    event_log_records = []
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># 1. Fetch all RMA Orders
    print(class="hl-string">"Fetching RMA orders...")
    rma_params = {
        class="hl-string">'finder': class="hl-string">'findOrders',
        class="hl-string">'q': fclass="hl-string">"OrderTypeCode='{RMA_ORDER_TYPE}' and CreationDate between '{START_DATE}' and '{END_DATE}'",
        class="hl-string">'fields': class="hl-string">'OrderNumber,CreationDate,CreatedBy,LastUpdateDate,LastUpdatedBy,OrderStatus,ReturnReasonCode,CrossReference,lines',
        class="hl-string">'expand': class="hl-string">'lines.fulfillmentLines'
    }
    rma_orders = get_paginated_data(class="hl-string">"/fscmRestApi/resources/11.13.18.05/salesOrdersForOrderHub", rma_params)

    class=class="hl-string">"hl-comment"># 2. Fetch all related Credit Memos (can be optimized by filtering on creation date)
    print(class="hl-string">"Fetching Credit Memos...")
    cm_params = {
        class="hl-string">'fields': class="hl-string">'TransactionNumber,TransactionDate,Amount,CustomerTransactionId,SalesOrderNumber'
    }
    credit_memos = get_paginated_data(class="hl-string">"/fscmRestApi/resources/11.13.18.05/receivablesCreditMemos", cm_params)
    cm_map = {cm[class="hl-string">'SalesOrderNumber']: cm for cm in credit_memos if class="hl-string">'SalesOrderNumber' in cm}

    print(fclass="hl-string">"Processing {len(rma_orders)} RMA orders...")
    for rma in rma_orders:
        case_id = rma.get(class="hl-string">'OrderNumber')
        if not case_id:
            continue

        class=class="hl-string">"hl-comment"># Helper to add events
        def add_event(activity, timestamp, agent, status, reason=None, end_time=None):
            if timestamp:
                event_log_records.append({
                    class="hl-string">'ReturnCaseId': case_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': timestamp,
                    class="hl-string">'EndTime': end_time if end_time else timestamp,
                    class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion SCM',
                    class="hl-string">'LastDataUpdate': last_data_update,
                    class="hl-string">'ProcessingAgent': agent,
                    class="hl-string">'ReturnStatus': status,
                    class="hl-string">'ReturnReason': reason,
                    class="hl-string">'RequestedRefundAmount': None, class=class="hl-string">"hl-comment"># Placeholder
                    class="hl-string">'ActualRefundAmount': None, class=class="hl-string">"hl-comment"># Placeholder
                    class="hl-string">'RefundSlaTargetDate': None class=class="hl-string">"hl-comment"># Placeholder
                })

        class=class="hl-string">"hl-comment"># Activity: RMA Created
        add_event(class="hl-string">'RMA Created', rma.get(class="hl-string">'CreationDate'), rma.get(class="hl-string">'CreatedBy'), class="hl-string">'Draft', rma.get(class="hl-string">'ReturnReasonCode'))

        class=class="hl-string">"hl-comment"># Activities from Fulfillment Lines
        if class="hl-string">'lines' in rma and rma[class="hl-string">'lines']:
            for line in rma[class="hl-string">'lines'][class="hl-string">'items']:
                if class="hl-string">'fulfillmentLines' in line and line[class="hl-string">'fulfillmentLines']:
                    for ff_line in line[class="hl-string">'fulfillmentLines'][class="hl-string">'items']:
                        ff_status = ff_line.get(class="hl-string">'StatusCode')
                        last_update = ff_line.get(class="hl-string">'LastUpdateDate', rma.get(class="hl-string">'LastUpdateDate'))
                        agent = ff_line.get(class="hl-string">'LastUpdatedBy', rma.get(class="hl-string">'LastUpdatedBy'))

                        class=class="hl-string">"hl-comment"># The following is an inference based on typical status flows.
                        class=class="hl-string">"hl-comment"># Your specific statuses may vary.
                        if ff_status in [class="hl-string">'DOO_AWAIT_APPROVAL', class="hl-string">'DOO_SUBMITTED']:
                            add_event(class="hl-string">'RMA Approval Submitted', last_update, agent, ff_status)
                        elif ff_status == class="hl-string">'DOO_AWAIT_RECEIVING':
                            add_event(class="hl-string">'RMA Approved', last_update, agent, ff_status)
                        elif ff_status in [class="hl-string">'DOO_PARTIALLY_FULFILLED', class="hl-string">'DOO_SHIPMENT_CONFIRMED']:
                             add_event(class="hl-string">'Item Received', ff_line.get(class="hl-string">'ActualShipDate', last_update), agent, ff_status)
                             class=class="hl-string">"hl-comment"># Infer inspection events based on receipt
                             add_event(class="hl-string">'Item Inspection Started', ff_line.get(class="hl-string">'ActualShipDate', last_update), agent, class="hl-string">'Awaiting Inspection')
                             add_event(class="hl-string">'Item Inspected', last_update, agent, class="hl-string">'Inspection Complete')
                        elif ff_status == class="hl-string">'DOO_AWAIT_BILLING':
                            add_event(class="hl-string">'Return Disposition Determined', last_update, agent, ff_status)
                        elif ff_status == class="hl-string">'DOO_CLOSED':
                            add_event(class="hl-string">'Return Case Closed', last_update, agent, ff_status)
                        elif ff_status in [class="hl-string">'DOO_CANCELED', class="hl-string">'DOO_REJECTED']:
                            add_event(class="hl-string">'RMA Rejected', last_update, agent, ff_status)
                        
                        class=class="hl-string">"hl-comment"># Placeholder activities not directly available
                        add_event(class="hl-string">'Item Shipped By Customer', None, class="hl-string">'Customer', class="hl-string">'In Transit')
                        add_event(class="hl-string">'Customer Notified', None, class="hl-string">'System', class="hl-string">'Notification Sent')

        class=class="hl-string">"hl-comment"># Activity: Exchange Order Created
        if rma.get(class="hl-string">'CrossReference'):
             add_event(class="hl-string">'Exchange Order Created', rma.get(class="hl-string">'LastUpdateDate'), rma.get(class="hl-string">'LastUpdatedBy'), rma.get(class="hl-string">'OrderStatus'))

        class=class="hl-string">"hl-comment"># Activities from Credit Memos
        if case_id in cm_map:
            cm = cm_map[case_id]
            cm_date = cm.get(class="hl-string">'TransactionDate')
            cm_amount = cm.get(class="hl-string">'Amount')
            add_event(class="hl-string">'Credit Memo Created', cm_date, class="hl-string">'System', class="hl-string">'Credit Memo Issued')
            add_event(class="hl-string">'Refund Initiated', cm_date, class="hl-string">'System', class="hl-string">'Refund In Progress')
            class=class="hl-string">"hl-comment"># Assuming refund is processed shortly after creation for this example
            add_event(class="hl-string">'Refund Processed', cm_date, class="hl-string">'System', class="hl-string">'Refund Complete')

            class=class="hl-string">"hl-comment"># Update refund amounts on all events for this case
            for rec in event_log_records:
                if rec[class="hl-string">'ReturnCaseId'] == case_id:
                    rec[class="hl-string">'ActualRefundAmount'] = cm_amount
                    rec[class="hl-string">'RequestedRefundAmount'] = cm_amount class=class="hl-string">"hl-comment"># Assuming requested equals actual

    class=class="hl-string">"hl-comment"># 4. Create and Save DataFrame
    if not event_log_records:
        print(class="hl-string">"No events were generated. Check your configuration and date range.")
    else:
        df = pd.DataFrame(event_log_records)
        df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'], errors=class="hl-string">'coerce')
        df = df.dropna(subset=[class="hl-string">'EventTime'])
        df = df.sort_values(by=[class="hl-string">'ReturnCaseId', class="hl-string">'EventTime'])

        class=class="hl-string">"hl-comment"># Reorder columns
        column_order = [
            class="hl-string">'ReturnCaseId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
            class="hl-string">'ProcessingAgent', class="hl-string">'ReturnStatus', class="hl-string">'ReturnReason', class="hl-string">'RequestedRefundAmount', 
            class="hl-string">'ActualRefundAmount', class="hl-string">'RefundSlaTargetDate'
        ]
        df = df[column_order]

        df.to_csv(class="hl-string">'returns_event_log.csv', index=False)
        print(class="hl-string">"Successfully created returns_event_log.csv")

Prêt à commencer ?

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

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

Éliminez les goulots d’étranglement et optimisez le traitement des retours et des remboursements dès maintenant

Repérez les inefficacités et réduisez le temps de cycle de 30 % dans Oracle Fusion SCM.

Démarrez l’essai gratuit

Aucune carte bancaire n’est requise. La configuration prend moins de 5 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 de traitement des retours et des remboursements

Guides d’extraction

Export depuis Oracle Transactional Business Intelligence (OTBI)

Étapes

Configuration

a Exemple de requête sql

Extraction des objets de vue Oracle BI Cloud Connector (BICC)

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant les API REST d’Oracle Fusion SCM

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Éliminez les goulots d’étranglement et optimisez le traitement des retours et des remboursements dès maintenant

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

Guides d’extraction

Export depuis Oracle Transactional Business Intelligence (OTBI)

Étapes

Configuration

a Exemple de requête sql

Extraction des objets de vue Oracle BI Cloud Connector (BICC)

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant les API REST d’Oracle Fusion SCM

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Éliminez les goulots d’étranglement et optimisez le traitement des retours et des remboursements dès maintenant

Nous respectons votre vie privée

Prêt à commencer ?