Votre template de données Order-to-Cash - Facturation

L'horodatage de l'événement enregistre le moment exact où une activité s'est produite. Il fournit l'ordre chronologique des événements pour chaque facture, ce qui est essentiel pour construire le flux de processus et effectuer toute analyse basée sur le temps.

Cet attribut est la base de tous les calculs de durée et de performance. Il est utilisé pour mesurer le temps entre les activités, calculer les temps de cycle de bout en bout, déterminer si les paiements sont à temps et analyser les tendances au fil du temps. Les KPI tels que « Temps moyen d'approbation des factures » et « Temps de cycle de facture de bout en bout » sont directement calculés à partir de ces horodatages.

Les horodatages sont essentiels pour le calcul de toutes les métriques de performance, y compris les temps de cycle, les retards et le respect des délais, constituant la base de l'analyse quantitative des processus.

Ceci est tiré de divers champs de date dans les tables Oracle Fusion Financials, tels que CREATION_DATE dans RA_CUSTOMER_TRX_ALL ou les horodatages de mise à jour de statut dans les tables de workflow.

Le numéro de facture est la pierre angulaire de l'analyse du processus de facturation. Il fonctionne comme l'ID de cas, regroupant tous les événements de la création de la facture au paiement final et à la clôture. Cela permet une vue complète et de bout en bout du cycle de vie pour un seul document de facturation.

En Process Mining, l'analyse par numéro de facture permet la visualisation des variantes de processus, le calcul des temps de cycle pour les factures individuelles, et l'identification des bottleneck (goulots d'étranglement) ou des boucles de retravail affectant des transactions spécifiques. Il est essentiel pour les dashboards (tableaux de bord) comme « Temps de cycle de facture de bout en bout » et pour le calcul de KPI fondamentaux tels que les Jours de Ventes en Suspens (DSO) sur une base par facture.

Cet attribut est critique car il connecte toutes les activités de facturation et de paiement associées en un seul cas, permettant une analyse complète et précise du cycle de vie de la facture.

C'est généralement le Numéro de Transaction (TRX_NUMBER) de la table RA_CUSTOMER_TRX_ALL dans Oracle Fusion Financials.

Le nom de l'activité décrit une étape du processus de facturation, telle que « Facture créée », « Facture approuvée » ou « Paiement client reçu ». Ces événements forment la séquence d'actions qui constituent le flux de processus pour chaque facture.

Cet attribut est fondamental pour la découverte de processus, permettant à l'outil de Process Mining de construire une carte visuelle de la manière dont les factures sont réellement traitées. Il est utilisé pour analyser les variantes de processus, identifier les boucles de retravail comme les étapes d'approbation multiples, et mesurer la fréquence et la durée de chaque étape. Tous les tableaux de bord et les KPI reposent sur cet attribut pour comprendre le flux de processus.

Cet attribut définit les étapes de la carte des processus, rendant possible de visualiser, d'analyser et d'identifier les inefficacités dans le workflow de facturation.

Cette information est dérivée de diverses tables et changements de statut au sein d'Oracle Fusion Financials, tels que les tables d'historique de workflow (par ex., liées aux approbations) et les champs de statut de transaction.

La date d'échéance est un attribut de date critique qui définit la date limite de paiement d'une facture, telle que déterminée par les conditions de paiement.

Cet attribut est essentiel pour le suivi des recouvrements et la santé financière. C'est la référence pour le calcul du KPI du Taux de Paiement à Temps et pour la création de rapports d'ancienneté des paiements. Dans les tableaux de bord, il est utilisé pour prévoir la trésorerie en montrant quand les paiements sont attendus et pour identifier les factures impayées qui nécessitent des activités de recouvrement.

C'est la référence principale pour mesurer la ponctualité des paiements, calculer le DSO et gérer l'ancienneté des comptes clients.

Situé dans la table AR_PAYMENT_SCHEDULES_ALL, généralement dans le champ DUE_DATE.

Cet attribut représente le montant total dû sur la facture. C'est une métrique financière critique pour comprendre la valeur monétaire qui transite par le processus de facturation.

En analyse, le Montant de la Facture est utilisé pour prioriser les transactions à forte valeur, calculer la valeur totale des créances impayées, et pondérer les KPI comme les Jours de Ventes en Suspens (DSO). Il permet de segmenter le processus en fonction de l'impact financier, par exemple, d'analyser si les factures à forte valeur suivent un chemin d'approbation différent ou prennent plus de temps à être payées.

Fournit le contexte financier pour chaque cas, permettant une analyse basée sur la valeur, la priorisation des factures à forte valeur et le calcul des KPI financiers clés.

Trouvé dans la table RA_CUSTOMER_TRX_ALL, probablement dans un champ tel que INVOICE_AMOUNT ou un champ connexe représentant le total de la transaction.

Cet attribut identifie le client associé à la facture. C'est une dimension primaire pour segmenter et filtrer les données de processus.

L'analyse du processus par nom de client aide à identifier quels clients ont les cycles de paiement les plus longs, lesquels sont les plus susceptibles de contester les factures, et lesquels paient constamment à temps. C'est crucial pour le dashboard (tableau de bord) 'Tendance DSO' et pour adapter les stratégies de recouvrement aux comportements spécifiques des clients.

Permet de segmenter le processus par client, révélant différents comportements, schémas de paiement et problèmes relationnels potentiels qui affectent la trésorerie.

Dérivé en joignant la table de transactions (RA_CUSTOMER_TRX_ALL) avec des tables de données de base client comme HZ_PARTIES.

Le statut de la facture fournit un aperçu de l'état d'avancement d'une facture dans le processus. Les statuts courants incluent ouvert (impayé), clôturé (payé), contesté ou annulé.

Cet attribut est utile pour une surveillance et un filtrage de haut niveau. Par exemple, le tableau de bord des prévisions de trésorerie en temps réel utilise ce statut pour catégoriser les montants en suspens. Il aide à identifier rapidement la population de factures en retard, en litige ou entièrement réglées.

Fournit une compréhension rapide et globale de l'état actuel d'une facture, permettant un filtrage et une catégorisation efficaces pour le reporting financier et la gestion opérationnelle.

Dérivé des champs de statut dans des tables comme RA_CUSTOMER_TRX_ALL ou AR_PAYMENT_SCHEDULES_ALL (par exemple, le champ STATUS).

L'unité commerciale représente l'entité organisationnelle responsable de la transaction. C'est un élément de données clé pour la segmentation financière et le reporting dans les grandes entreprises.

Cet attribut permet de comparer la performance des processus entre les différentes parties de l'entreprise. Par exemple, vous pouvez analyser si le DSO varie de manière significative entre les unités commerciales ou si une unité a un taux de retravail de facturation beaucoup plus élevé. Cela aide à cibler les initiatives d'amélioration là où elles sont le plus nécessaires.

Permet la comparaison des performances entre différentes unités organisationnelles, aidant à identifier les meilleures pratiques et les domaines nécessitant des améliorations à un niveau granulaire.

Disponible dans les tables de transactions comme RA_CUSTOMER_TRX_ALL, souvent sous forme d'ORG_ID, qui renvoie aux définitions des unités commerciales.

Les conditions de paiement définissent les règles régissant quand et comment une facture doit être payée, y compris les éventuels escomptes pour paiement anticipé. Cette information est essentielle pour la gestion des créances et de la trésorerie.

Cet attribut est crucial pour calculer la date d'échéance correcte et pour identifier les opportunités d'escompte pour paiement anticipé. L'indicateur clé de performance (KPI) du Taux de capture d'escomptes pour paiement anticipé dépend directement de ces données pour déterminer quelles factures étaient éligibles à un escompte.

Définit les règles de paiement d'une facture, impactant directement les calculs de date d'échéance et la capacité à suivre et optimiser la saisie des escomptes pour paiement anticipé.

Situé dans la table RA_TERMS et lié à la transaction via un term_id dans RA_CUSTOMER_TRX_ALL.

La Date de Facture, également appelée date de transaction, est la date enregistrée sur le document de facture. Elle sert de point de départ pour le calcul des conditions de paiement.

Cette date est un composant critique pour le calcul des Jours de Ventes en Suspens (DSO), car le DSO mesure le temps entre la Date de Facture et la date de paiement. Elle est distincte de la date de création dans le système et représente le début officiel du cycle de paiement du point de vue du client.

Sert de date de début officielle pour le cycle de vie d'une facture et constitue la référence pour le calcul du KPI des Jours de Ventes en Suspens (DSO).

Situé dans la table RA_CUSTOMER_TRX_ALL, dans le champ TRX_DATE.

Cet attribut mesure la durée de bout en bout de l'intégralité du cycle de vie de la facture pour un seul cas. Il est calculé comme la différence de temps entre la toute première activité, typiquement « Facture créée », et l'activité finale, « Facture clôturée ».

Cette métrique offre une vue d'ensemble de l'efficacité globale du processus. C'est la mesure principale pour le dashboard (tableau de bord) « Temps de cycle de facture de bout en bout ». En analysant cet attribut selon différentes dimensions comme le client ou l'unité commerciale, les organisations peuvent identifier quels types de factures prennent le plus de temps à traiter et investiguer les causes profondes.

Fournit une mesure unique et cruciale de la vélocité globale du processus, aidant à identifier rapidement quelles factures prennent le plus de temps à être traitées de bout en bout.

C'est une métrique calculée, dérivée en prenant la différence entre l'EventTimestamp (Horodatage de l'événement) maximum et minimum pour chaque numéro de facture unique.

Le Days Sales Outstanding (DSO) est une métrique financière essentielle qui mesure le temps moyen nécessaire pour encaisser un paiement après l'émission d'une facture. Cet attribut le calcule pour chaque facture individuelle.

Bien que le DSO global soit un KPI clé, son calcul au niveau de chaque facture permet une analyse beaucoup plus approfondie. Il peut être utilisé pour créer des tableaux de bord de tendances, identifier les caractéristiques des factures à DSO élevé et mesurer l'impact financier des retards de processus. Ce calcul granulaire fournit les données nécessaires pour comprendre les facteurs à l'origine du KPI DSO agrégé.

Calcule une métrique de trésorerie critique au niveau de chaque facture, permettant une analyse détaillée des facteurs qui influencent les délais de recouvrement et la performance financière.

Ceci est calculé en trouvant la différence entre l'horodatage de l'activité « Paiement client reçu » et l'attribut « Date de facture ».

Cet attribut fournit l'horodatage de l'extraction de données la plus récente. C'est un champ de métadonnées essentiel pour comprendre la fraîcheur des données analysées.

Les analystes utilisent cette information pour confirmer qu'ils travaillent avec des informations à jour et pour comprendre la récence des données. C'est particulièrement important pour les dashboards (tableaux de bord) qui se disent « en temps réel » ou quasi temps réel, car il offre une transparence sur les éventuels retards de données.

Informe les utilisateurs sur la fraîcheur des données, garantissant que les analyses et les conclusions sont basées sur des informations avec un niveau de récence connu et acceptable.

C'est un champ de métadonnées généré pendant le processus d'extraction, de transformation et de chargement (ETL) des données. Il correspond généralement au temps d'exécution du pipeline de données.

Cet attribut calculé fournit un simple indicateur vrai ou faux de la ponctualité des paiements. Il est dérivé en comparant la date de l'activité « Paiement client reçu » avec l'attribut « Date d'échéance » de la facture.

Cet indicateur simplifie l'analyse et le reporting pour le KPI du Taux de Paiement à Temps. Il permet un filtrage et une segmentation faciles pour comprendre quels facteurs, tels que le client, la région ou le montant de la facture, sont corrélés avec les retards de paiement. C'est une métrique clé pour évaluer l'efficacité des recouvrements.

Simplifie la mesure de la performance des recouvrements et permet une analyse facile des facteurs qui contribuent aux paiements à temps ou en retard.

Calculé en comparant l'horodatage de l'activité de paiement final avec l'attribut DueDate. La logique est : PaymentTimestamp <= DueDate.

Cet attribut calculé signale les activités qui représentent un travail inutile ou redondant. Des exemples incluent une facture rejetée puis soumise à nouveau pour approbation, ou une correction effectuée après la création initiale.

En signalant le retravail, il devient facile de quantifier son impact sur le processus. Le KPI du Taux de Retravail de Facturation est calculé directement à partir de cet attribut. Les dashboards (tableaux de bord) peuvent visualiser la fréquence du retravail et mesurer le temps de cycle supplémentaire qu'il ajoute, aidant à identifier les sources d'inefficacité et d'erreurs.

Quantifie directement l'inefficacité des processus en signalant le travail inutile ou répété, ce qui simplifie la mesure de l'impact des problèmes de qualité en termes de coûts et de temps.

Ceci est calculé pendant la transformation des données en fonction de la séquence des activités. Par exemple, si une activité « Facture approuvée » est précédée d'une activité « Facture rejetée » pour le même cas, elle est signalée comme retravail.

L'heure de fin de l'événement enregistre le moment où une activité a été terminée. Alors que de nombreux événements sont instantanés, certaines activités comme « Approbation de la facture » peuvent avoir une durée, commençant au moment de la soumission et se terminant lorsqu'une décision est prise.

Avoir une heure de fin permet un calcul précis du temps de traitement de l'activité. C'est utile pour analyser combien de temps les utilisateurs passent sur des tâches spécifiques. Cela améliore la précision de l'analyse des bottleneck (goulots d'étranglement) en distinguant le temps d'attente du temps de traitement réel.

Permet le calcul précis des temps de traitement des activités, distinguant le temps de travail actif du temps d'attente inactif, ce qui est essentiel pour une analyse détaillée des goulots d'étranglement.

Ceci est souvent dérivé en prenant l'heure de début de l'activité suivante dans le processus. Pour certaines activités, un champ d'heure de fin dédié peut exister dans les workflow logs (journaux de workflow).

Cet attribut spécifie comment un client a payé sa facture. Cette information peut être utile pour analyser les tendances de paiement et les coûts.

Différentes méthodes de paiement peuvent avoir des temps de traitement et des coûts de transaction différents. L'analyse par méthode de paiement peut aider à comprendre si certaines méthodes sont sujettes à des erreurs de rapprochement ou à des retards. Elle peut également éclairer les stratégies visant à encourager les clients à utiliser des canaux de paiement plus efficaces.

Aide à analyser l'efficacité du traitement des paiements, les coûts de transaction et les taux d'erreur de rapprochement associés aux différents canaux de paiement.

Trouvé dans les tables d'encaissement, telles que AR_CASH_RECEIPTS_ALL, qui contiendrait un champ indiquant la méthode de paiement.

Lorsqu'un client conteste une facture, la raison du litige est enregistrée. Cela peut concerner le prix, la quantité, la qualité du service ou d'autres problèmes.

L'analyse des raisons des litiges est un moyen puissant d'effectuer une analyse des causes profondes. En comprenant les raisons les plus courantes des litiges, l'entreprise peut aborder les problèmes sous-jacents de prix, d'exécution des commandes ou de qualité des données. Cela aide à réduire le temps moyen de résolution des litiges de factures et améliore la satisfaction client.

Offre un aperçu direct des causes profondes des retards de paiement et de l'insatisfaction client, permettant à l'entreprise de résoudre les problèmes systémiques.

Cette information peut être stockée dans Oracle Collections ou un module de gestion des litiges connexe. Elle pourrait se trouver dans une table de litiges dédiée ou comme code de raison sur la transaction elle-même.

La région fournit le contexte géographique de la facture, généralement basé sur l'emplacement du client. Cela permet une analyse spatiale de la performance du processus.

L'analyse par région peut révéler des variations causées par les réglementations locales, les conditions du marché ou la performance des équipes régionales. Des tableaux de bord comme DSO Trend (Tendance DSO) et Invoice End-to-End Cycle Time (Temps de Cycle de Facturation de Bout en Bout) peuvent être segmentés par région pour voir si certaines zones sont confrontées à des défis uniques pour le paiement des factures.

Permet une segmentation géographique du processus, ce qui peut mettre en évidence les différences régionales de performance, de comportement client ou de conformité.

Ceci est généralement dérivé des informations d'adresse du client stockées dans le TCA (HZ_LOCATIONS, HZ_PARTY_SITES). Ce n'est pas un champ direct sur la facture elle-même.

Cet attribut identifie l'équipe ou le service spécifique au sein de l'organisation qui a géré le processus de facturation. Il fournit une autre couche de contexte organisationnel pour l'analyse.

En segmentant le processus par service de facturation, une entreprise peut comparer l'efficacité et la précision de différentes équipes. Il peut aider à identifier quels services ont des taux de retravail plus élevés, des cycles d'approbation plus longs, ou contribuent davantage à un DSO élevé, soulignant les opportunités de formation ciblée ou de standardisation des processus.

Permet la comparaison des performances entre les équipes internes, aidant à identifier les meilleures pratiques, les besoins en ressources ou les domaines nécessitant une amélioration des processus.

Cette information pourrait être dérivée de l'utilisateur qui a créé la facture, en liant l'utilisateur à son service assigné dans le système RH (par ex., via PER_ALL_ASSIGNMENTS_F).

Cet attribut identifie l'application source d'où proviennent les données. Pour ce processus, il s'agira généralement d'Oracle Fusion Financials, mais il pourrait aussi spécifier un module particulier au sein de celui-ci, comme Oracle Receivables (AR).

Dans les environnements avec plusieurs systèmes intégrés, ce champ aide à différencier les sources de données et est crucial pour la validation et la gouvernance des données. Il garantit que l'analyse est basée sur l'ensemble de données correct et prévu.

Identifie l'origine des données, ce qui est essentiel pour la gouvernance des données, le dépannage et la garantie que l'analyse est basée sur le bon système d'enregistrement.

C'est généralement une valeur statique (« Oracle Fusion Financials ») ajoutée pendant le processus d'extraction et de transformation des données.

L'attribut Utilisateur identifie la personne ou l'agent automatisé responsable de l'exécution d'une étape du processus. Il peut s'agir de l'utilisateur qui a créé la facture, du gestionnaire qui l'a approuvée, ou de l'agent de recouvrement qui a émis un rappel.

L'analyse par utilisateur aide à identifier les opportunités de formation, la répartition de la charge de travail et les différences de performance entre individus ou équipes. Elle peut révéler si certains utilisateurs sont associés à des taux d'erreur élevés ou si des approbateurs spécifiques sont des bottleneck (goulots d'étranglement) constants.

Attribue la responsabilité des étapes du processus, permettant l'analyse des performances des utilisateurs, l'équilibrage de la charge de travail et l'identification des besoins en formation.

Provient des champs d'ID utilisateur comme CREATED_BY ou LAST_UPDATED_BY dans diverses tables de transactions et de workflow. Cet ID est ensuite joint aux tables d'annuaire d'utilisateurs (par ex., PER_ALL_PEOPLE_F) pour obtenir le nom de l'utilisateur.