> Amélioration Continue des Processusus > Traitement des facturess factures fournisseurs factures fournisseurs retours et remboursements > Oracle Fusion SCM > Template de données

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

Oracle Fusion SCM

← Retour au Guide d'amélioration

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

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

Ce modèle est conçu pour vous aider à analyser votre processus de retours et remboursements dans Oracle Fusion SCM. Il décrit les attributs essentiels à collecter, les activités clés à suivre, et fournit des conseils clairs sur la manière d'extraire ces données. Utilisez-le pour obtenir des enseignements précieux sur votre processus et identifier les domaines d'amélioration.

Attributs recommandés à collecter
Activités clés à suivre pour l'analyse des processus
Guide d'extraction étape par étape pour Oracle Fusion SCM

Vous découvrez les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs de traitement des retours et remboursements

Ce sont les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de vos processus de retours et remboursements au sein d'Oracle Fusion SCM.

5 Obligatoire 7 Recommandé 9 Facultatif

	Nom	Descriptionn
	Activité ActivityName	Le nom d'une étape métier ou d'un événement spécifique survenu au sein du processus de retours et remboursements.
Descriptionn Cet attribut décrit une étape ou un jalon unique dans le cycle de vie du retour, tel que 'RMA créée', « Article inspecté » ou « Remboursement traité ». Chaque activité représente un point distinct du processus capturé dans les journaux d'événements du système. L'analyse de la séquence et de la durée de ces activités constitue le fondement du Process Mining. Elle facilite la visualisation des cartes de processus, l'identification des points de blocage entre les étapes et le calcul des temps de cycle spécifiques à l'activité. Ces données sont indispensables pour comprendre le flux de processus, les boucles de reprise et la conformité aux procédures d'exploitation standard. Pourquoi est-ce important ? : Les activités constituent l'pilier central de la cartographie des processus, pour visualiser et l'analyse du flux de processus, de ses variations et de ses points de blocage. Source des données : Dérivé des journaux d'événements, des changements de statut ou des enregistrements de transactions spécifiques danss modules Oracle Fusion SCM comme la gestion des commandes et la gestion des stocks. Exemples RMA crééArticle reçuAvoir émisRemboursement traité
	Heure de l'événement EventTime	L'horodatage indiquant quand une activité ou un événement spécifique s'est produit.
Descriptionn L'heure de l'événement, ou l'heure de début, est la date et l'heure précises auxquelles une activité a été enregistrée dans le système source. Elle fournit le contexte chronologique pour chaque étape du processus. Cet horodatage est indispensable pour toute analyse basée sur le temps. Il est utilisé pour ordonner correctement les événements, calculer les temps de cycle entre les activités, mesurer la durée totale d'un cas et évaluer les performances par rapport aux accords de niveau de service (SLA). Sans horodatages précis, il est impossible d'analyser l'efficacité du processus, d'identifier les retards ou de comprendre la dynamique du processus. Pourquoi est-ce important ? : Cet attribut fournit la séquence chronologique des événements, clée pour le calcul de toutes les métriques basées sur la durée et la découverte des points de blocage du processus. Source des données : Ces informationsns se trouvent généralement dans un champ 'Creation Date', 'Horodatage' ou 'Last Update Date' associé aux enregistrements de transaction ou 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	L'identifiant principal qui relie toutes les activités associées à une demande spécifique de retour ou de remboursement client.
Descriptionn L'ID du dossier de retour sert d'identifiant unique pour l'ensemble du processus de retours et remboursements. Il connecte chaque événement, de la création initiale de l'autorisation de retour de marchandise (RMA) au traitement final du remboursement et à la clôture du dossier. Dans l'analyse Process Mining, cet attribut est indispensable pour reconstituer le parcours complet de chaque retour. Il permet aux analystes de suivre le cycle de vie complet, de mesurer les temps de cycle totaux et de comprendre les variations dans la manière dont les différents retours sont traités. Toutes les autres données au niveau des événements sont regroupés par cet ID pour former une vue de processus cohérente. Pourquoi est-ce important ? : C'est la clé essentielle pour assembler tous les événements liés en une seule instance de processus, permettant l'analyse complet. Source des données : Cet identifiant est généralement généré danss modules Oracle Gestion des commandes ou Service lorsqu'une demande de retour est initiée. Exemples RMA-2023-00123RMA-2023-00456RMA-2023-00789
	Dernière mise à jour des données LastDataUpdate	L'horodatage de la dernière actualisation ou extraction des données du système source.
Descriptionn Cet attribut indique la dernière fois que l'ensemble de données a été mis à jour. Il fournit une date de 'fraîcheur' pour l'ensemble des données, et non pour des événements individuels. Connaître l'heure de la dernière mise à jour des données est indispensable pour que les utilisateurs comprennent la pertinence de l'analyse. Cela les aide à 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 jours. C'est une métadonnée clé pour tout projet de Process Mining. Pourquoi est-ce important ? : Informe les utilisateurs sur la récence des données, garantissant qu'ils comprennent le contexte et la pertinence temporelle de leur analyse. Source des données : Ce `horodatage` est généré et ajouté pendant le processus d'extraction, de transformation et de chargement des `données` (ETL). Exemples 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	Système source SourceSystem	Le système d'où les données ont été extraites.
Descriptionn Cet attribut identifie le système d'information d'origine où les données d'événement ont été enregistrées. Pour ce processus, il s'agirait généralement de 'Oracle Fusion SCM'. Dans les environnements avec plusieurs systèmes intégrés, ce champ est impératif pour la traçabilité des données et le dépannage. Il aide à confirmer l'origine des données et peut être utilisé pour filtrer l'analyse des événements provenant de systèmes spécifiques, garantissant ainsi le maintien de la qualité et du contexte des données. Pourquoi est-ce important ? : Il fournit un contexte essentiel sur l'origine des données, ce qui est indispensable pour la validation et l'analyse des données dans des environnements multi-systèmes. Source des données : C'est souvent une valeur statique ajoutée pendant le processus d'extraction, transformation et chargement (ETL) des données pour étiqueter l'origine de l'ensemble de données. Exemples Oracle Fusion SCMOracle SCM Cloud
	Agent de Traitement ProcessingAgent	L'utilisateur ou l'agent responsable de l'exécution d'une activité spécifique dans le processus de retour.
Descriptionn Cet attribut identifie l'employé ou l'utilisateur du système qui a effectué une tâche donnée, comme l'approbation d'une RMA ou le traitement d'un remboursement. Il peut également désigner une équipe ou un département si l'affectation individuelle n'est pas suivie. L'analyse des performances par agent est indispensablele pour la gestion opérationnelle. Cet attribut active le tableau de bord 'Performance des agents de traitement des retours', permettant des comparaisons de la charge de travail, de la durée des activités et des taux de reprise entre différents agents. Ces informationsns peuvent mettre en évidence les besoins en formation, identifier les meilleurs collaborateurs les plus performants et éclairer une meilleure allocation des ressources. Pourquoi est-ce important ? : Permet l'analyse des performances par utilisateur ou par équipe, aidant à identifier les plus performants, les opportunités de formation et les déséquilibres de charge de travail. Source des données : Généralement disponible dans des champs comme 'USER_ID', 'PROCESSED_BY' ou 'AGENT_NAME' dans les journaux de transactions au sein d'Oracle Fusion SCM. Exemples j.doea.smithm.jones
	Date cible SLA de remboursement RefundSlaTargetDate	La date à laquelle le remboursement doit être effectué conformément à l'accord de niveau de service.
Descriptionn Cet attribut définit la date limite pour l'achèvement du processus de remboursement pour un dossier donné. La cible SLA est souvent déterminée par la politique de l'entreprise, le niveau du client ou la raison du retour. Cette date est la référence pour mesurer la ponctualité et la conformité. Elle est utilisée directement dans le tableau de bord 'Conformité SLA de la politique de remboursement' et est indispensablele pour calculer le KPI 'Taux de conformité SLA de remboursement'. La comparaison de la date d'achèvement réelle du remboursement à cette cible permet l'identification des violations de SLA et aide à prioriser les cas qui risquent d'être en retard. Pourquoi est-ce important ? : Fournit la référence pour mesurer la performance dans les délais et est impératif pour le calcul des KPI de conformité SLA. Source des données : Il peut s'agir d'un champ de date spécifique sur le dossier de retour ou il peut être nécessaire de le dériver en ajoutant une période de temps prédéfinie (par exemple, 14 jours) à la date d'initiation du retour. Exemples 2023-11-10T23:59:59Z2023-11-15T23:59:59Z2023-11-20T23:59:59Z
	Heure de fin EndTime	L'horodatage indiquant quand une activité a été achevée.
Descriptionn L'heure de fin marque la fin d'une activité. Alors que StartTime indique quand un événement a commencé, End Time est nécessaire pour calculer le temps de traitement réel de cet événement spécifique. Pour les événements instantanés, StartTime et End Time peuvent être identiques. En analyse, la différence entre End Time et Heure de début fournit le 'Temps de traitement' pour une activité. Ceci est impératif pour identifier les étapes spécifiques qui prennent du temps, par opposition au temps d'attente entre les étapes. C'est indispensable pour une analyse détaillée des points de blocage et des calculs d'efficacité des ressources. Pourquoi est-ce important ? : Cet attribut est nécessaire pour calculer le temps de traitement réel des activités individuelles, aidant à distinguer le temps de travail actif du temps d'attente. Source des données : Il peut s'agir d'un champ distinct dans les journaux du système source ou peut être dérivé du StartTime de l'activité suivante. Exemples 2023-10-26T10:05:00Z2023-10-26T15:00:10Z2023-10-27T11:30:00Z
	Montant du remboursement demandé RequestedRefundAmount	Le montant monétaire que le client a initialement demandé pour le retour.
Descriptionn Cet attribut capture la valeur du remboursement tel que demandé par le client au début du processus. C'est le montant de référence par rapport auquel le remboursement final est comparé. Ce point de données est indispensable pour le tableau de bord 'Montants de remboursement demandés vs réels' et le KPI 'Taux d'écart des montants de remboursement'. L'analyse de la différence entre les montants demandés et réels peut révéler des problèmes tels que des retours d'articles incorrects, des frais de restockage ou des ajustements de politique, fournissant des informations clés sur la précision financière et la satisfaction client. Pourquoi est-ce important ? : Sert de référence pour l'analyse financière, permettant le calcul des écarts de remboursement et la mise en évidence des problèmes potentiels. Source des données : Cette valeur doit être stockée sur l'en-tête de la RMA ou de la demande de retour dans Oracle Fusion SCM, probablement dans le module Gestion des commandes. Exemples 129.9945.501200.00
	Montant du remboursement réel ActualRefundAmount	Le montant monétaire final qui a été effectivement traité et remboursé au client.
Descriptionn Cet attribut représente le montant final et confirmé remboursé au client après que toutes les inspections, ajustements et frais ont été appliqués. Cette valeur reflète le véritable résultat financier du dossier de retour. Il s'agit d'un point de données financier critique utilisé dans le tableau de bord 'Requested vs Actual Refund Amounts'. La comparaison de ce montant avec le montant demandé est indispensablele pour calculer le KPI 'Refund Amount Discrepancy Rate' et comprendre l'impact financier des politiques de retour, des conditions des articles et des ajustements de traitement. Pourquoi est-ce important ? : Représente le véritable résultat financier du retour, permettant l'analyse des écarts et le reporting financier. Source des données : Ces informationsns proviendraient probablement des enregistrements de transaction de la note de crédit ou des comptes fournisseurs liés au dossier de retour dans Oracle Fusion Financials. Exemples 129.9940.000.00
	Motif de retour ReturnReason	Le motif fourni par le client pour le retour de l'article.
Descriptionn Cet attribut contient la raison du retour, généralement sélectionnée par le client dans une liste prédéfinie, telle que 'Article défectueux', 'Mauvaise taille' ou 'Plus besoin'. L'analyse des raisons de retour fournit des informations puissantes sur la qualité des produits, la précision du processus de vente et le comportement des clients. Ces données peuvent être utilisées pour identifier les produits ayant des taux de défauts élevés, améliorer les descriptions de produits pour réduire les commandes incorrectes et comprendre les causes profondes des retours. Cette analyse peut entraîner des améliorations stratégiques qui réduisent le volume global des retours. Pourquoi est-ce important ? : Fournit un insight critique sur les raisons des retours, qui peut être utilisé pour apporter des améliorations aux produits et aux processus de vente. Source des données : Généralement stocké sous forme de code ou de champ de texte sur l'article de ligne RMA dans Oracle Gestion des commandes. Exemples DéfectueuxArticle erroné expédiéArrivé trop tardMeilleur prix disponible
	Statut du retour ReturnStatus	Le statut actuel ou final du dossier de retour.
Descriptionn Cet attribut indique le statut global du dossier de retour à un moment donné ou son résultat final, tel que 'Clôturé - Remboursé', 'Clôturé - Rejeté' ou 'En cours'. Le statut de retour est indispensable pour l'analyse et le suivi des résultats. Il permet de filtrer les dossiers en fonction de leur résultat, de comparer les flux de processus des retours approuvés et rejetés, et d'alimenter le 'Tableau de bord du statut actuel des dossiers de retour'. Comprendre la distribution des résultats est indispensable pour mesurer l'efficacité des processus. Pourquoi est-ce important ? : Fournit le résultat d'un cas, ce qui est indispensable pour le filtrage, l'analyse comparative et la compréhension des taux de succès du processus. Source des données : Généralement disponible comme champ de statut sur l'enregistrement principal de retour ou l'en-tête de RMA dans Oracle Gestion des commandes. Exemples En attente de réceptionInspection terminéeClôturé - RembourséClôturé - Rejeté
	Code de disposition DispositionCode	Un code indiquant la gestion finale de l'article physique retourné.
Descriptionn Le code de disposition spécifie ce qu'il est advenu du produit retourné après inspection, par exemple, s'il a été retourné en stock, mis au rebut, envoyé pour remise à neuf ou retourné au fournisseur. Ces informationsns sont précieuses pour analyser l'impact financier et opérationnel des retours. En analysant les codes de disposition, une entreprise peut comprendre le coût associé aux biens non revendables et identifier les opportunités d'améliorer les processus de remise à neuf. Il relie le processus de retour aux résultats d'inventaire et financiers. Pourquoi est-ce important ? : Relie le processus de retours à son résultat physique en inventaire, fournissant des informations sur les taux de récupération et les coûts. Source des données : Ces informationsns sont capturées dans les modules Oracle Gestion des stocks ou Gestion d'entrepôt une fois l'activité d'inspection terminée. Exemples RETOUR AU STOCKSCRAPRECONDITIONNERRETURN_TO_VENDOR
	Écart de Montant de Remboursement RefundAmountDiscrepancy	La différence calculée entre le montant de remboursement demandé et le montant de remboursement réel.
Descriptionn Cette métrique quantifie la différence monétaire entre ce que le client a demandé et ce qu'il a reçu. Elle est calculée en soustrayant le 'ActualRefundAmount' du 'RequestedRefundAmount'. Cette valeur calculée est la base du KPI 'Refund Amount Discrepancy Rate'. Une valeur non nulle indique qu'un ajustement a été effectué pendant le processus. L'analyse des raisons de ces écarts, tels que les frais de restockage ou les déductions pour dommages, peut fournir des informations sur l'efficacité de la politique et la communication client. Pourquoi est-ce important ? : Quantifie les ajustements financiers dans le processus de remboursement, aidant à analyser l'impact des politiques et des résultats d'inspection. Source des données : Champ calculé : 'RequestedRefundAmount' - 'ActualRefundAmount'. Exemples 0.005.50-10.00
	Est conforme aux SLA IsSlaCompliant	Un indicateur booléen indiquant si le remboursement a été traité dans les délais de l'objectif SLA défini.
Descriptionn Cet attribut calculé fournit un simple indicateur vrai/faux de la conformité SLA pour chaque cas de retour. Il est déterminé en comparant l'horodatage d'achèvement réel du remboursement avec le 'RefundSlaTargetDate'. Ce drapeau est indispensable pour mesurer et visualiser facilement les taux de conformité. Il alimente le tableau de bord 'Refund Policy SLA Compliance' « what-if »mplifie le calcul du KPI 'Refund SLA Conformance Rate'. Il permet un filtrage rapide et une analyse des causes profondes pour comprendre pourquoi certains dossiers ne respectent pas leur SLA. Pourquoi est-ce important ? : Simplifie le suivi et le reporting des SLA en convertissant une comparaison de dates en une simple métrique booléenne. Source des données : Champ calculé. Il est vrai si l'horodatage 'Remboursement traité' est antérieur ou égal à la 'RefundSlaTargetDate', et faux dans le cas contraire. Exemples truefaux
	Est un reprises IsRework	Un indicateur booléen indiquant si une activité fait partie d'une boucle de reprises.
Descriptionn Ce drapeau identifie les activités qui sont des répétitions d'étapes antérieures dans le même dossier, indiquant une boucle de processus ou un reprises. Par exemple, si un article échoue à l'inspection et doit être réinspecté, le deuxième événement d'inspection serait signalé comme reprises. Cet attribut est indispensable pour quantifier l'inefficacité des processus. Il est utilisé dans le tableau de bord 'Return Processing Rework Rates' et pour calculer le KPI 'Return Rework Event Frequency'. L'identification de la quantité et des causes du reprises est un objectif principal du Process Mining, car elle indique directement le gaspillage d'efforts, les retards et l'augmentation des coûts. Pourquoi est-ce important ? : Signale directement les inefficacités et les boucles de processus, facilitant la quantification et l'analyse des causes de reprises. Source des données : Ceci est un attribut calculé identifié 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 truefaux
	ID client CustomerId	L'identifiant unique du client ayant initié le retour.
Descriptionn Cet attribut est l'ID unique qui identifie le 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 modèles importants. Par exemple, elle peut aider à identifier les clients ayant des fréquences de retour anormalement élevées, ce qui pourrait indiquer des problèmes de satisfaction ou une fraude potentielle. Elle permet également une analyse basée sur les segments de clientèle, aidant à comprendre si certains groupes ont des comportements de retour différents. Pourquoi est-ce important ? : Permet une analyse orientée client, aidant à identifier les clients effectuant des retours répétés, à segmenter les comportements et à détecter les fraudes potentielles. Source des données : Trouvé en tant qu'ID client ou partie sur l'en-tête de la commande de vente originale ou de la demande de retour dans Oracle Gestion des commandes. Exemples CUST-100589743ACC-54321
	ID de l'entrepôt WarehouseId	L'identifiant de l'entrepôt ou de l'installation qui a reçu l'article retourné.
Descriptionn Cet attribut indique l'emplacement physique spécifique, tel qu'un centre de distribution ou un entrepôt, où l'article retourné par le client a été reçu et traité. L'analyse du processus par entrepôt est importante pour identifier les problèmes de performance spécifiques à un lieu. Elle permet de comparer les temps d'inspection, les résultats de disposition et les temps de cycle globaux entre différentes installations. Cela peut mettre en évidence des inefficacités opérationnelles, des problèmes de personnel ou des besoins en formation sur des sites particuliers. Pourquoi est-ce important ? : Permet l'analyse des performances par lieu, aidant à identifier les points de blocage et les inefficacités spécifiques à une région ou à une installation. Source des données : Ce champ, souvent appelé 'ORGANIZATION_ID', est associé à la transaction de réception dans Oracle Gestion des stocks. Exemples WH-US-WESTWH-EU-CENTRALDC-01
	ID Produit ProductId	L'identifiant unique du produit retourné.
Descriptionn Cet attribut est l'identifiant unique, tel qu'un SKU ou un numéro d'article, pour le produit spécifique impliqué dans le retour. Il relie le processus de retour au catalogue de produits. L'analyse au niveau du produit est indispensablele pour identifier les articles problématiques. En filtrant ou en dimensionnant l'analyse de processus par ID de produit, les entreprises peuvent identifier les produits ayant des taux de retour élevés, des temps d'inspection longs ou des modèles de défauts spécifiques. Ces informationsns sont essentielles pour le contrôle qualité, la gestion de la chaîne d'approvisionnement et le développement de produits. Pourquoi est-ce important ? : Lie le processus de retour à des produits spécifiques, permettant l'analyse de la qualité des produits et des modèles de retour. Source des données : Ce serait le 'INVENTORY_ITEM_ID' ou un champ similaire sur l'article de ligne RMA dans les modules Oracle Gestion des commandes ou Inventory. Exemples PROD-5540-ASKU-98765ITEM-001-B
	Numéro RMA RmaNumber	L'identifiant unique de la transaction d'autorisation de retour de marchandise.
Descriptionn Le numéro RMA est une autorisation formelle pour un client de retourner un produit. Bien qu'il soit souvent identique à l'ID du dossier de retour, dans certains systèmes, il peut s'agir d'un identifiant distinct et précédent. Cet attribut sert de numéro de référence commercial clé, familier aux utilisateurs internes et aux clients. Il peut être utilisé pour rechercher et filtrer des dossiers et est souvent le numéro principal utilisé dans la communication concernant le retour. Pourquoi est-ce important ? : Sert de numéro de référence commercial principal, essentiel pour le suivi opérationnel et la communication avec les clients. Source des données : C'est l'identifiant principal de l'objet Autorisation de Retour de Marchandise au sein d'Oracle Gestion des commandes. Exemples 789001789002789003
	Type de retour ReturnType	Catégorise le retour en fonction du résultat attendu, tel que remboursement, échange ou réparation.
Descriptionn Cet attribut classe le type de retour en cours de traitement. Le flux de processus et les étapes requises peuvent varier considérablement selon que le client reçoit un remboursement monétaire, un produit de remplacement ou un article réparé. L'analyse du processus par type de retour est indispensablele pour comprendre les variations de processus. Elle permet la création de cartes de processus distinctes pour les remboursements par rapport aux échanges, aidant à identifier les points de blocage uniques et les caractéristiques de performance pour chaque chemin. Cette segmentation est indispensablele aux efforts d'amélioration ciblés des processus. Pourquoi est-ce important ? : Permet la segmentation de l'analyse en fonction de différents chemins de processus, car les échanges et les remboursements suivent souvent des étapes différentes. Source des données : Il s'agit généralement d'un champ de catégorie ou de type sur l'en-tête ou la ligne de la RMA dans Oracle Gestion des commandes. Exemples RemboursementÉchangeRéparation

Obligatoire Recommandé Facultatif

Activités de traitement des retours et remboursements

Ce sont les étapes clés du processus et les jalons à enregistrer dans votre journal d'événements pour une découverte précise des processus et l'identification des points de blocage.

7 Recommandé 8 Facultatif

	Activité	Descriptionn
	Article inspecté	Cette activité signifie l'achèvement du processus d'inspection des articles, où une évaluation de la qualité est enregistrée. Il s'agit généralement d'une transaction explicite dans Oracle Gestion des stocks ou Quality Management qui met à jour le statut RMA.
Pourquoi est-ce important ? : Le résultat de l'inspection influence directement les étapes suivantes, telles que l'approbation ou le rejet du remboursement. La durée de l'activité d'inspection elle-même est un indicateur de performance clé pour l'efficacité de l'entrepôt. Source des données : Capturé à partir de l'horodatage de la transaction lorsqu'un inspecteur termine la tâche d'inspection par rapport à la réception RMA dans Oracle Inventory ou Quality Management. Capture Utiliser l'horodatage d'achèvement de la transaction d'inspection. Type d'événement explicit
	Article reçu	Cette activité marque la réception physique de l'article retourné à l'entrepôt ou au centre de traitement. C'est un événement explicite capturé dans Oracle Fusion Gestion des stocks lorsque les marchandises sont scannées et enregistrées comme reçues par rapport à la RMA.
Pourquoi est-ce important ? : La réception de l'article est une étape cruciale qui déclenche les étapes d'inspection et de traitement ultérieures. Mesurer le temps entre 'RMA approuvée' et 'Article reçu' aide à analyser les performances logistiques et d'expédition. Source des données : C'est une transaction explicite enregistrée dans Oracle Gestion des stocks. L'événement correspond à la date de transaction de la réception RMA. Capture Utiliser l'horodatage de la transaction de réception RMA en stock. Type d'événement explicit
	Avoir émis	C'est l'activité financière où une note de crédit est générée dans les comptes clients pour autoriser un remboursement au client. C'est un événement explicite déclenché par le processus de retours dans Gestion des commandes.
Pourquoi est-ce important ? : La création d'une note de crédit est une étape décisive indiquant l'engagement de l'entreprise à rembourser le client. C'est le déclencheur de toute la partie règlement financier du processus. Source des données : C'est une transaction explicite dans Oracle Comptabilité Clients. L'événement peut être lié à la RMA originale via la référence de commande client sur la note de crédit. Capture Utiliser la date de création de la transaction de note de crédit dans AR. Type d'événement explicit
	Dossier de retour clos	C'est l'activité finale, signifiant que toutes les actions liées à la RMA sont terminées, y compris la réception, la disposition et le règlement financier. Ceci est déduit d'un statut final 'Closed' sur la commande RMA.
Pourquoi est-ce important ? : Cet événement sert de fin définitive du processus, essentiel pour calculer le temps de cycle complet et garantir qu'aucun dossier ne reste ouvert indéfiniment. Source des données : Déduit de l'horodatage lorsque l'en-tête de commande RMA et toutes ses lignes atteignent un statut final 'Clôturé' dans Oracle Gestion des commandes. Capture Capture l'horodatage de la dernière modificationication du statut d'en-tête ou de ligne RMA à 'Clôturé'. Type d'événement inferred
	Remboursement traité	Cette activité marque l'achèvement du paiement de remboursement au client. C'est un événement explicite capturé lorsque la transaction de compensation de paiement est enregistrée dans Oracle Financials.
Pourquoi est-ce important ? : C'est un point final critique pour mesurer le temps de cycle total du remboursement du point de vue du client. Il confirme que l'obligation financière envers le client a été remplie. Source des données : Cet événement est capturé à partir de la date comptable ou de compensation de la transaction de paiement dans Oracle Comptes fournisseurs ou Treasury qui règle la note de crédit. Capture Utiliser la date de compensation de la transaction de paiement réglant la note de crédit. Type d'événement explicit
	RMA approuvée	Ce jalon clé signifie que la demande de retour a été validée et approuvée conformément aux règles métier. Cela est généralement déduit d'un changement de statut sur la RMA, débloquant les étapes de processus ultérieures comme l'expédition au client.
Pourquoi est-ce important ? : L'approbation est une étape cruciale du processus. Les retards à ce niveau ont un impact direct sur le temps de cycle total des retours et la satisfaction client. Cette activité est indispensablele pour analyser les points de blocage liés à l'approbation. Source des données : Déduit de l'horodatage du changement de statut sur l'en-tête ou la ligne de commande RMA passant à un statut 'Approuvé' ou 'En attente de réception'. Capture Capture l'horodatage lorsque le statut de la RMA est mis à jour vers un état approuvé. Type d'événement inferred
	RMA créé	Cette activité marque le début officiel du processus de retour, où une autorisation de retour de matériel (RMA) est créée dans Oracle Fusion SCM. Cet événement est généralement capturé explicitement lorsqu'un utilisateur ou un processus automatisé génère un nouvel enregistrement de commande client RMA.
Pourquoi est-ce important ? : C'est l'événement de départ principal pour l'ensemble du processus de retours. L'analyse du temps écoulé entre cette activité et les autres révèle la durée globale du processus et aide à identifier les retards initiaux. Source des données : Ceci est capturé à partir de l'horodatage de création de l'en-tête de la commande de retour dans Oracle Fusion Gestion des commandes. L'événement correspond à la sauvegarde initiale du document RMA. Capture Suivre 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	Représente l'action du client d'expédier l'article de retour à l'entreprise. Cet événement n'est souvent pas capturé 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é fournit un aperçu du comportement des clients et du temps nécessaire au transit des marchandises. Elle aide à distinguer les retards de traitement internes des retards causés par l'expédition. Source des données : Il peut s'agir d'un événement inféré basé sur les données d'expédition du transporteur liées à la RMA, ou d'une mise à jour manuelle du statut dans Oracle SCM. Si aucune intégration n'existe, cet événement peut ne pas être disponible. Capture Horodatage d'une API de transporteur intégrée ou d'un champ de saisie de données manuel. Type d'événement inferred
	Client Notifié	Ceci représente la communication envoyée au client confirmant la résolution de son dossier de retour, tel que le remboursement traité ou l'échange expédié. Ceci est souvent capturé à partir d'un journal de communication ou d'une mise à jour de statut sur le dossier.
Pourquoi est-ce important ? : Une communication client rapide est indispensablele pour la satisfaction. L'analyse de ceci aide à garantir que les accords de niveau de service pour la communication sont respectés. Source des données : Nécessite une analyse système. Cela peut être enregistré par un CRM intégré ou une plateforme de communication, ou il peut s'agir d'une mise à jour manuelle du statut sur la RMA ou d'une demande de service connexe. Capture Horodatage 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é se produit dans les scénarios où le client a demandé un échange au lieu d'un remboursement. C'est un événement explicite où une nouvelle commande client est générée, souvent liée à la RMA originale.
Pourquoi est-ce important ? : Cette activité identifie une variante de processus importante. La séparation des processus d'échange des processus de remboursement est indispensablele pour une analyse précise des temps de cycle pour chaque chemin. Source des données : C'est un événement explicite, la création d'un nouveau document de commande client dans Gestion des commandes. Il doit être lié à la RMA via un champ de référence. Capture Utiliser la date de création de la nouvelle commande client liée à la RMA. Type d'événement explicit
	Demande d'approbation RMA soumise	Ceci représente le moment où la RMA créée est soumise pour examen et approbation internes. Cela est souvent déduit d'un changement de statut sur la RMA, indiquant qu'elle est passée d'un état de brouillon ou d'entrée à un état d'approbation en attente.
Pourquoi est-ce important ? : Le suivi de ceci aide à mesurer la durée de la phase de prélèvement.-approbation. Il sépare le temps de saisie des données du temps réel passé à attendre qu'un approbateur agisse. Source des données : Déduit de l'horodatage lorsque le statut de l'en-tête ou de la ligne de commande RMA passe à un statut 'En attente d'approbation' ou équivalent au sein du workflow d'approbation de la gestion des commandes. Capture Identifier l'horodatage du changement de statut à 'En attente d'approbation'. Type d'événement inferred
	Disposition de retour déterminée	Après l'inspection, cette activité représente la décision concernant l'article retourné, telle que 'Retour en stock' ou 'Mise au rebut'. Elle est capturée par une transaction d'inventaire explicite qui déplace l'article vers sa destination finale.
Pourquoi est-ce important ? : Cette étape est indispensable pour la précision des stocks et le rapprochement financier. L'analyse des dispositions aide à comprendre les raisons des retours et les problèmes de qualité des produits. Source des données : Comptabilisé comme une transaction dans Oracle Gestion des stocks, telle qu'un transfert de sous-inventaire ou une mise à jour du statut de l'article, suite à l'inspection. Capture Suivre l'horodatage de la transaction d'inventaire qui actionne la disposition. Type d'événement explicit
	Inspection de l'article commencée	Indique le début de l'inspection physique de l'article retourné pour évaluer son état. Cela peut être déduit de la localisation de l'article ou d'un changement de statut au sein du module de gestion d'entrepôt, ou il pourrait s'agir d'un scan explicite.
Pourquoi est-ce important ? : Mesurer le temps entre la réception de l'article et le début de l'inspection met en évidence les retards d'attente à la station d'inspection, un goulot d'étranglement courant. Source des données : Ceci peut être capturé par un changement de statut sur la ligne de réception ou une transaction déplaçant l'article vers un lieu d'inspection dans Oracle Gestion des stocks. Cela peut nécessiter une configuration personnalisée pour une capture explicite. Capture Horodatage d'un changement de statut ou d'un transfert de stock vers une zone d'inspection. Type d'événement inferred
	Remboursement initié	Cette activité signifie que le processus de paiement du remboursement a commencé. Elle est souvent déduite d'un changement de statut sur la note de crédit, passant d'un état ouvert à un état indiquant qu'elle est en cours de traitement pour paiement.
Pourquoi est-ce important ? : Cette activité aide à séparer l'approbation et la création de la note de crédit du traitement réel du paiement, qui peut être géré par une équipe ou un système différent et pourrait être une source de retard. Source des données : Déduit d'un changement de statut sur la note de crédit dans les comptes clients, ou de la création d'un enregistrement de paiement dans les comptes fournisseurs faisant référence à la note de crédit. Capture Identifier l'horodatage lorsque le statut de la note de crédit passe à 'Paiement en attente' ou similaire. Type d'événement inferred
	RMA rejetée	Représente une décision terminale de rejeter la demande de retour du client. Cela 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 ? : C'est un chemin d'exception critique. L'analyse de la fréquence et des raisons des rejets peut révéler des problèmes liés aux politiques de retour, aux attentes des clients ou aux tentatives de fraude. Source des données : Déduit de l'horodatage du changement de statut sur l'en-tête ou la ligne de commande RMA vers un statut 'Rejeté' ou un statut terminal équivalent. Capture Identifier 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éder à l'éditeur d'analyse OTBI : Connectez-vous à votre instance Oracle Fusion Cloud SCM. Utilisez le menu Navigateur pour aller à Outils, puis sélectionnez Rapports et Analyses. Cliquez sur le bouton 'Créer' et choisissez 'Analyse' dans le menu déroulant.
Sélectionner les domaines thématiques : Dans la fenêtre contextuelle 'Sélectionner le domaine thématique', vous devez choisir les principaux domaines thématiques qui contiennent les données de retours et de remboursements. Sélectionnez "Sales - CRM All Lines" et "Receivables - Transactions Real Time". Vous combinerez ces éléments pour créer une vision globale du processus.
Passer en mode avancé : Après avoir sélectionné les domaines thématiques, l'éditeur d'analyse s'ouvrira. Basculez immédiatement vers l'onglet 'Advanced' pour accéder à l'éditeur SQL logique, nécessaire à la création de la structure de journal d'événements requise.
Construire la requête de journal d'événements : Copiez le SQL logique complet fourni dans la section 'Query' de ce document et collez-le dans la zone de texte 'SQL Query' de l'onglet Advanced. Cette requête est structurée avec plusieurs clauses UNION ALL pour récupérer chacune des 15 activités requises sous forme de lignes distinctes.
Définir les paramètres de requête : Modifiez les valeurs des placeholders dans la requête. Plus précisément, mettez à jour les placeholders [START_DATE] et [END_DATE] pour définir la plage de dates de votre extraction. Vous devrez peut-être aussi ajuster les filtres pour des unités commerciales ou des types de commande de retour spécifiques en fonction de la configuration de votre organisation.
Valider la requête : Cliquez sur le bouton 'Validate SQL' pour vous assurer que la syntaxe est correcte. Le système vérifiera les noms de colonne et la structure par rapport aux domaines thématiques sélectionnés.
Examiner les résultats : Accédez à l'onglet 'Results' pour prévisualiser la sortie. Les données devraient apparaître dans un format de journal d'événements, chaque ligne représentant une activité distincte dans le processus de retour. Vérifiez que les colonnes telles que ReturnCaseId, (ActivityName) et (EventTime) sont renseignées comme prévu.
Enregistrer l'analyse : Une fois que vous êtes satisfait des résultats, cliquez sur l'icône 'Save Analysis'. Donnez-lui un nom descriptif, par exemple, 'Extraction des retours et remboursements ProcessMind', et enregistrez-le dans un dossier partagé.
Créer un calendrier d'exportation : Pour automatiser l'extraction, vous pouvez planifier l'exécution régulière de l'analyse. Depuis la page d'accueil d'Oracle BI, localisez votre analyse enregistrée, cliquez sur 'More', et sélectionnez 'Schedule'.
Configurer le travail d'exportation : Dans les options de planification, définissez la fréquence (par exemple, quotidiennement, hebdomadairement). Dans la section 'Delivery', définissez le format de sortie en CSV. Configurez la destination, telle qu'un serveur de contenu ou un e-mail, où le fichier de sortie sera envoyé. Activez le calendrier pour démarrer les extractions automatisées.

Configuration

Domaines thématiques : Les principaux domaines thématiques pour cette analyse sont "Sales - CRM All Lines" pour les en-têtes de commande RMA, les lignes et l'historique de statut, et "Receivables - Transactions Real Time" pour les détails des notes de crédit et des paiements de remboursement. Des domaines thématiques supplémentaires comme "Inventory - Inventory Transactions Real Time" peuvent être requis si des détails plus précisres sur l'inspection et la disposition sont nécessaires.
Filtrage par plage de dates : Il est indispensable d'appliquer un filtre par plage de dates pour limiter le volume des données et garantir le succès de l'analyse. Nous recommandons d'extraire les données pour une période de 3 à 6 mois à la fois. La requête fournie filtre sur la date de création de la RMA.
Filtres clés : Au-delà de la plage de dates, vous devriez filtrer par type de commande pour sélectionner spécifiquement les commandes d'autorisation de retour de matériel (RMA). Le filtrage par unité commerciale ou entité juridique spécifique est également recommandé pour délimiter les données de manière appropriée.
Mode SQL logique : Cette méthode d'extraction nécessite l'utilisation de l'onglet 'Advanced' et la rédaction d'une requête SQL logique personnalisée avec des instructions UNION ALL. Cette approche est nécessaire pour remodeler les données transactionnelles au format du journal d'événements requis par ProcessMind.
Prérequis : L'utilisateur exécutant cette extraction a besoin d'un rôle avec les permissions nécessaires pour créer et exécuter des analyses OTBI, tel que le rôle 'BI Author'. L'accès aux domaines thématiques spécifiés (Ventes, Créances et potentiellement Inventaire) est également obligatoire.

a Exemple de requête config

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

Accéder à l'éditeur d'analyse OTBI : Connectez-vous à votre instance Oracle Fusion Cloud SCM. Utilisez le menu Navigateur pour aller à Outils, puis sélectionnez Rapports et Analyses. Cliquez sur le bouton 'Créer' et choisissez 'Analyse' dans le menu déroulant.
Sélectionner les domaines thématiques : Dans la fenêtre contextuelle 'Sélectionner le domaine thématique', vous devez choisir les principaux domaines thématiques qui contiennent les données de retours et de remboursements. Sélectionnez "Sales - CRM All Lines" et "Receivables - Transactions Real Time". Vous combinerez ces éléments pour créer une vision globale du processus.
Passer en mode avancé : Après avoir sélectionné les domaines thématiques, l'éditeur d'analyse s'ouvrira. Basculez immédiatement vers l'onglet 'Advanced' pour accéder à l'éditeur SQL logique, nécessaire à la création de la structure de journal d'événements requise.
Construire la requête de journal d'événements : Copiez le SQL logique complet fourni dans la section 'Query' de ce document et collez-le dans la zone de texte 'SQL Query' de l'onglet Advanced. Cette requête est structurée avec plusieurs clauses UNION ALL pour récupérer chacune des 15 activités requises sous forme de lignes distinctes.
Définir les paramètres de requête : Modifiez les valeurs des placeholders dans la requête. Plus précisément, mettez à jour les placeholders [START_DATE] et [END_DATE] pour définir la plage de dates de votre extraction. Vous devrez peut-être aussi ajuster les filtres pour des unités commerciales ou des types de commande de retour spécifiques en fonction de la configuration de votre organisation.
Valider la requête : Cliquez sur le bouton 'Validate SQL' pour vous assurer que la syntaxe est correcte. Le système vérifiera les noms de colonne et la structure par rapport aux domaines thématiques sélectionnés.
Examiner les résultats : Accédez à l'onglet 'Results' pour prévisualiser la sortie. Les données devraient apparaître dans un format de journal d'événements, chaque ligne représentant une activité distincte dans le processus de retour. Vérifiez que les colonnes telles que ReturnCaseId, (ActivityName) et (EventTime) sont renseignées comme prévu.
Enregistrer l'analyse : Une fois que vous êtes satisfait des résultats, cliquez sur l'icône 'Save Analysis'. Donnez-lui un nom descriptif, par exemple, 'Extraction des retours et remboursements ProcessMind', et enregistrez-le dans un dossier partagé.
Créer un calendrier d'exportation : Pour automatiser l'extraction, vous pouvez planifier l'exécution régulière de l'analyse. Depuis la page d'accueil d'Oracle BI, localisez votre analyse enregistrée, cliquez sur 'More', et sélectionnez 'Schedule'.
Configurer le travail d'exportation : Dans les options de planification, définissez la fréquence (par exemple, quotidiennement, hebdomadairement). Dans la section 'Delivery', définissez le format de sortie en CSV. Configurez la destination, telle qu'un serveur de contenu ou un e-mail, où le fichier de sortie sera envoyé. Activez le calendrier pour démarrer les extractions automatisées.

Configuration

Domaines thématiques : Les principaux domaines thématiques pour cette analyse sont "Sales - CRM All Lines" pour les en-têtes de commande RMA, les lignes et l'historique de statut, et "Receivables - Transactions Real Time" pour les détails des notes de crédit et des paiements de remboursement. Des domaines thématiques supplémentaires comme "Inventory - Inventory Transactions Real Time" peuvent être requis si des détails plus précisres sur l'inspection et la disposition sont nécessaires.
Filtrage par plage de dates : Il est indispensable d'appliquer un filtre par plage de dates pour limiter le volume des données et garantir le succès de l'analyse. Nous recommandons d'extraire les données pour une période de 3 à 6 mois à la fois. La requête fournie filtre sur la date de création de la RMA.
Filtres clés : Au-delà de la plage de dates, vous devriez filtrer par type de commande pour sélectionner spécifiquement les commandes d'autorisation de retour de matériel (RMA). Le filtrage par unité commerciale ou entité juridique spécifique est également recommandé pour délimiter les données de manière appropriée.
Mode SQL logique : Cette méthode d'extraction nécessite l'utilisation de l'onglet 'Advanced' et la rédaction d'une requête SQL logique personnalisée avec des instructions UNION ALL. Cette approche est nécessaire pour remodeler les données transactionnelles au format du journal d'événements requis par ProcessMind.
Prérequis : L'utilisateur exécutant cette extraction a besoin d'un rôle avec les permissions nécessaires pour créer et exécuter des analyses OTBI, tel que le rôle 'BI Author'. L'accès aux domaines thématiques spécifiés (Ventes, Créances et potentiellement Inventaire) est également obligatoire.

a Exemple de requête config

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

Configurer l'environnement Python : Assurez-vous d'avoir Python 3.6 ou une version plus récente installée. Installez les bibliothèques nécessaires à l'aide de pip : pip install requests pandas.
Configurer l'accès à Oracle Fusion SCM : Obtenez les identifiants d'un utilisateur Oracle Fusion avec les rôles nécessaires pour accéder aux API REST. Les rôles requis incluent généralement Gestionnaire de commandes et Gestionnaire des comptes clients. L'utilisateur doit avoir les permissions de visualiser les commandes de vente (RMA) et les notes de crédit des créances.
Identifier les API Endpoints : Confirmez l'URL de base de votre instance Oracle Fusion SCM. Le script utilise les ressources REST salesOrdersForOrderHub et receivablesCreditMemos. La version 11.13.18.05 pourrait devoir être ajustée pour correspondre à votre environnement.
Personnaliser le script Python : Ouvrez le script Python fourni. Mettez à jour les variables placeholders en haut du script : ORACLE_BASE_URL, ORACLE_USERNAME, et ORACLE_PASSWORD. Ajustez la variable RMA_ORDER_TYPE pour qu'elle corresponde au code de type de commande spécifique utilisé pour les RMA dans votre système.
Définir la période d'extraction : Modifiez les variables START_DATE et END_DATE dans le script pour définir la fenêtre temporelle de l'extraction de données. Il est recommandé de commencer par une période plus courte, par exemple, un mois, pour tester le script.
Exécuter le script : Exécutez le script depuis votre ligne de commande : python extract_oracle_returns.py. Le script se connectera aux API Oracle, récupérera les données, les traitera et affichera les mises à jour de statut dans la console.
Récupérer le journal d'événements : Une fois l'opération terminée avec succès, le script générera un fichier nommé returns_event_log.csv dans le même répertoire. Ce fichier contient le journal d'événements extrait.
Examiner et préparer pour le téléchargement : Ouvrez le fichier returns_event_log.csv dans une application de feuille de calcul. Examinez les données pour vérifier leur exhaustivité et leur exactitude, en accordant une attention particulière aux colonnes (ActivityName) et (EventTime). Assurez-vous que les en-têtes de colonne correspondent aux exigences de votre outil de Process Mining.
Télécharger vers ProcessMind : Téléchargez le fichier CSV généré directement dans ProcessMind. Mappez les colonnes du fichier CSV aux attributs correspondants dans ProcessMind (ReturnCaseId à ID du cas, (ActivityName) à Activité, (EventTime) à Horodatage).

Configuration

API Endpoints : Le script utilise principalement deux API Endpoints REST : /fscmRestApi/resources/11.13.18.05/salesOrdersForOrderHub pour les données de commande RMA et /fscmRestApi/resources/11.13.18.05/receivablesCreditMemos pour les données de remboursement financier.
Authentification : Le script utilise l'authentification de base. Le nom d'utilisateur et le mot de passe fournis doivent être associés à un compte utilisateur disposant d'un accès API et de privilèges suffisants pour lire les données de commande et de créances.
Plage de dates : L'extraction est filtrée par la CreationDate des commandes RMA. Configurez les variables START_DATE et END_DATE dans le script. Pour les chargements initiaux, une période de 3 à 6 mois est recommandée. Pour les actualisations continues, utilisez une fenêtre glissante.
Filtre par type de commande RMA : Il est indispensable de configurer la variable RMA_ORDER_TYPE dans le script. Cela garantit que vous extrayez uniquement les commandes de retour et non les commandes de vente standard. Vous pouvez trouver votre code de type de commande RMA spécifique dans la tâche de configuration 'Gérer les types de commande' d'Oracle Fusion.
Mappage des codes de statut : Le script mappe les codes de statut internes d'Oracle (par exemple, DOO_AWAITING_RECEIVING, DOO_CLOSED) aux valeurs (ActivityName) adaptées au langage métier. Ce mappage peut nécessiter une personnalisation en fonction de votre configuration Oracle SCM spécifique.
Prérequis : L'accès à un environnement Oracle Fusion SCM est requis. Le compte utilisateur pour l'extraction doit avoir des rôles tels que Gestionnaire de commandes (ORA_DOO_ORDER_MANAGER_JOB) et Gestionnaire des comptes clients (ORA_AR_ACCOUNTS_RECEIVABLE_MANAGER_JOB) ou des rôles personnalisés équivalents qui accordent l'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")

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

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

Attributs de traitement des retours et remboursements

Activités de traitement des retours et remboursements

Guides d'extraction

Oracle Transactional Business Intelligence (OTBI) Export

Étapes

Configuration

a Exemple de requête config

Extraction d'objets de vue (View Object) Oracle BI Cloud Connector (BICC)

Étapes

Configuration

a Exemple de requête config

Script Python utilisant les API REST d'Oracle Fusion SCM

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Éliminez les points de blocage, optimisez le traitement des retours et remboursements dès maintenant

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

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

Attributs de traitement des retours et remboursements

Activités de traitement des retours et remboursements

Guides d'extraction

Oracle Transactional Business Intelligence (OTBI) Export

Étapes

Configuration

a Exemple de requête config

Extraction d'objets de vue (View Object) Oracle BI Cloud Connector (BICC)

Étapes

Configuration

a Exemple de requête config

Script Python utilisant les API REST d'Oracle Fusion SCM

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Éliminez les points de blocage, optimisez le traitement des retours et remboursements dès maintenant