Votre modèle de données Record to Report - Écriture de journal
Microsoft Dynamics 365Votre modèle de données Record to Report - Écriture de journal
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction pour Microsoft Dynamics 365
Record to Report - Attributs d'écriture de journal
| Nom | Description | ||
|---|---|---|---|
|
Heure de l'événement
EventTime
|
Le `timestamp` précis indiquant quand une `activité` ou un `event` s'est produit. | ||
|
Description
L'heure de l'événement (Event Time) enregistre la date et l'heure auxquelles une activité spécifique du processus d'écriture de journal a eu lieu. Ces données chronologiques sont essentielles pour ordonner les événements et calculer la durée entre eux.\n\nEn analyse, ce timestamp est utilisé pour construire la chronologie de chaque cas, ce qui est critique pour calculer toutes les métriques basées sur le temps, telles que les temps de cycle, les temps de traitement et les temps d'attente. Il permet d'identifier les retards entre les étapes et prend en charge les tableaux de bord liés aux goulots d'étranglement et à la conformité des SLA.
Pourquoi c'est important
Ce timestamp est essentiel pour ordonner correctement les événements et calculer tous les KPI basés sur la durée, tels que le temps de cycle et les retards de traitement.
Où obtenir
Les horodatages des événements se trouvent généralement dans les journaux d'historique de workflow, les tables de piste d'audit (par exemple, SysDatabaseLog), ou comme horodatages de création/modification sur les enregistrements associés comme LedgerJournalTable et LedgerJournalTrans.
Exemples
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:10Z
|
|||
|
ID de l'écriture de journal
JournalEntryId
|
L'identifiant unique d'une écriture de journal, servant d'identifiant principal de cas. | ||
|
Description
L'ID d'écriture de journal (Journal Entry ID) relie de manière unique toutes les activités et points de données liés à une seule transaction d'écriture de journal. Il permet le suivi complet de bout en bout du cycle de vie d'un journal, de sa création et révision jusqu'à son enregistrement final dans le grand livre général.\n\nDans l'analyse Process Mining, cet attribut est fondamental pour reconstituer le flux de processus. Chaque ID d'écriture de journal unique représente une seule instance du processus, permettant un examen détaillé des variantes de processus, des temps de cycle et de la conformité pour les transactions financières individuelles.
Pourquoi c'est important
C'est la clé essentielle pour suivre une écriture de journal du début à la fin, permettant d'analyser le flux de processus complet pour chaque cas.
Où obtenir
Cet identifiant se trouve généralement dans la table d'en-tête de journal, telle que LedgerJournalTable, souvent dans un champ nommé JournalNum.
Exemples
JRN-0012345JV-2023-08-156GENJ0000891
|
|||
|
Nom de l'activité
ActivityName
|
Le nom de l'étape ou de l'événement de processus métier spécifique qui s'est produit. | ||
|
Description
Cet attribut décrit un événement ou une tâche unique au sein du cycle de vie de l'écriture de journal, tel que 'Écriture de journal créée', 'Journal soumis pour approbation' ou 'Écriture de journal enregistrée'. Ces activités constituent les nœuds de la carte de processus découverte.\n\nL'analyse de la séquence et de la fréquence de ces activités est au cœur du Process Mining. Elle révèle le flux de processus réel, aide à identifier les écarts par rapport à la procédure standard et met en évidence les goulots d'étranglement où les activités prennent plus de temps que prévu ou sont répétées.
Pourquoi c'est important
Cet attribut définit les étapes du processus, constituant l'épine dorsale de la carte des processus et permettant l'analyse du flux et des variations du processus.
Où obtenir
Ceci est un attribut conceptuel dérivé des événements système, des changements de statut ou des journaux de workflow au sein de Microsoft Dynamics 365.
Exemples
Écriture de journal crééeJournal soumis pour approbationJournal approuvéÉcriture de journal validée
|
|||
|
Entité juridique
LegalEntity
|
L'entité juridique ou le code de société pour lequel l'écriture de journal est enregistrée. | ||
|
Description
L'entité juridique représente l'entreprise ou l'unité commerciale spécifique au sein d'une organisation pour laquelle la transaction financière est enregistrée. Il s'agit d'une dimension organisationnelle fondamentale dans les systèmes financiers.\n\nDans le Process Mining, cet attribut permet de comparer le processus d'écriture de journal entre les différentes parties de l'organisation. Il peut révéler si certaines entités juridiques ont des processus plus efficaces, des taux de rejet plus élevés ou des temps de cycle plus longs, aidant à identifier et à partager les meilleures pratiques.
Pourquoi c'est important
Permet de comparer les performances des processus entre différentes entreprises ou unités commerciales, mettant en évidence les variations et les opportunités d'amélioration.
Où obtenir
Ceci est un champ central dans Dynamics 365, souvent disponible dans des tables de transactions comme LedgerJournalTable, généralement lié à la DataAreaId.
Exemples
USMFDEMFGBSI
|
|||
|
Heure de fin de l'événement
EventEndTime
|
Le 'timestamp' indiquant quand une activité ou un 'event' a été complété. | ||
|
Description
L'heure de fin d'événement (Event End Time) marque l'achèvement d'une activité spécifique. Alors que l'heure de début (StartTime) indique le moment où un événement commence, l'heure de fin (EndTime) fournit l'autre limite, permettant le calcul précis de la durée des tâches individuelles.\n\nEn Process Mining, disposer à la fois d'une heure de début et de fin permet le calcul du temps de traitement des activités, qui est distinct du temps d'attente. Ceci est crucial pour les tableaux de bord analysant la performance des utilisateurs et identifiant quelles tâches spécifiques, et pas seulement les intervalles entre elles, consomment le plus de temps.
Pourquoi c'est important
Permet le calcul précis du temps que prend chaque activité, ce qui est essentiel pour analyser la performance des utilisateurs et identifier les tâches gourmandes en ressources.
Où obtenir
Ces données peuvent être explicitement stockées dans les journaux de workflow ou peuvent devoir être dérivées en utilisant l'heure de début (StartTime) de l'activité suivante dans la séquence.
Exemples
2023-10-26T10:05:15Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
|
|||
|
Montant total du journal
JournalTotalAmount
|
La valeur monétaire totale de l'écriture de journal, généralement la somme des débits. | ||
|
Description
Cet attribut représente la valeur financière totale de l'écriture de journal. Il peut être utilisé pour classer les écritures en tranches de valeur, telles que faible, moyenne et élevée.\n\nL'analyse du processus basée sur la valeur financière peut révéler des schémas importants. Par exemple, les écritures de journal de grande valeur pourraient suivre un processus d'approbation plus rigoureux avec plus d'étapes et des temps de cycle plus longs. Cet attribut est essentiel pour l'analyse de matérialité et la compréhension de l'impact financier des inefficacités du processus.
Pourquoi c'est important
Permet de segmenter le processus par valeur financière, ce qui est souvent corrélé avec la complexité du processus, le risque et les workflows d'approbation.
Où obtenir
Cette valeur peut devoir être calculée en additionnant les montants de débit de la table des lignes de journal, LedgerJournalTrans, pour chaque écriture de journal.
Exemples
1500.75125000.0050.25
|
|||
|
Motif de refus
RejectionReason
|
La raison fournie lorsqu'une écriture de journal est rejetée pendant le processus d'approbation. | ||
|
Description
Lorsqu'une écriture de journal est rejetée, l'approbateur fournit souvent une raison pour ce rejet. Cet attribut capture cette information, qui est inestimable pour l'analyse des causes profondes.\n\nC'est l'attribut principal pour le tableau de bord 'Analyse du taux de rejet des écritures de journal'. En catégorisant et en analysant les raisons de rejet, les organisations peuvent identifier les problèmes courants, tels que des documents incorrects, des violations de politique ou des erreurs de saisie de données, puis mettre en œuvre des formations ciblées ou des améliorations de processus.
Pourquoi c'est important
Explique pourquoi les reprises se produisent, fournissant les informations directes nécessaires pour réduire les taux de rejet et améliorer les approbations "justes du premier coup".
Où obtenir
Ces informations sont généralement stockées dans l'historique du workflow ou la section des commentaires associée à l'étape de rejet.
Exemples
Documentation justificative insuffisanteCompte incorrect utiliséDépasse le seuil d'approbationEntrée en double
|
|||
|
Nom d'utilisateur
UserName
|
Le `nom de l'utilisateur` qui a effectué l'`activité`. | ||
|
Description
Cet attribut identifie l'employé ou l'utilisateur système responsable de l'exécution d'une activité spécifique, telle que la création, l'approbation ou l'enregistrement d'une écriture de journal. Il relie les étapes du processus aux ressources humaines.\n\nL'analyse de la performance par utilisateur est une capacité clé du Process Mining. Elle aide à construire le tableau de bord 'Performance utilisateur des écritures de journal' pour comparer les durées d'activité et le débit entre différents utilisateurs ou équipes. Cela peut mettre en évidence les meilleurs performeurs, identifier les besoins de formation et aider à l'équilibrage de la charge de travail.
Pourquoi c'est important
Associe les activités du processus à des individus spécifiques, permettant l'analyse de la performance des utilisateurs, de la répartition de la charge de travail et de l'allocation des ressources.
Où obtenir
Les informations utilisateur se trouvent généralement dans les champs createdBy ou modifiedBy des tables comme LedgerJournalTable ou dans les journaux d'historique de workflow associés.
Exemples
Alice SmithBob Johnsonsystem.batch
|
|||
|
Statut du journal
JournalStatus
|
Le statut actuel ou final de l'écriture de journal. | ||
|
Description
Cet attribut indique l'état de l'écriture de journal à un moment donné, tel que 'Brouillon', 'En révision', 'Approuvé', 'Rejeté' ou 'Enregistré'. Il fournit un aperçu de l'emplacement de l'écriture dans son cycle de vie.\n\nL'analyse du statut est utile pour comprendre les résultats des cas. Elle peut être utilisée pour filtrer tous les journaux rejetés ou pour suivre le volume de journaux à une étape spécifique. Cet attribut prend en charge plusieurs tableaux de bord en fournissant un contexte à l'analyse du débit et du statut.
Pourquoi c'est important
Fournit un résultat clair pour chaque écriture de journal, permettant l'analyse des taux de succès, des taux de rejet et du volume de travail à différentes étapes.
Où obtenir
Le statut se trouve souvent dans la table d'en-tête de journal, LedgerJournalTable, ou est dérivé du statut du workflow.
Exemples
BrouillonSoumisApprouvéComptabiliséRejeté
|
|||
|
Type de journal
JournalType
|
La classification de l'écriture de journal, telle que Journal général ou Charge à payer. | ||
|
Description
Le type de journal classe les écritures en fonction de leur objectif métier, par exemple, écritures quotidiennes, charges à payer, allocations ou éliminations. Cette segmentation est essentielle pour comprendre les différents chemins et comportements des processus.\n\nCet attribut permet de filtrer et de comparer le processus selon différents types de journaux. Il est indispensable pour le tableau de bord 'Volume de traitement des écritures de journal par type', aidant à analyser si certains types de journaux sont plus sujets aux retards, aux rejets ou aux retouches.
Pourquoi c'est important
Permet de segmenter l'analyse pour comparer les processus à des fins commerciales différentes, qui peuvent avoir des chemins, des temps de cycle et des exigences d'approbation distincts.
Où obtenir
Ceci est généralement stocké dans la table d'en-tête de journal, LedgerJournalTable, dans un champ lié aux noms ou types de journaux (par exemple, JournalName).
Exemples
Journal généralAjustement des provisionsTransfert inter-sociétésPaie
|
|||
|
Code de devise
CurrencyCode
|
La devise du montant de l'écriture de journal. | ||
|
Description
Cet attribut spécifie la devise dans laquelle l'écriture de journal est libellée, telle que USD, EUR ou GBP. Il fournit un contexte essentiel pour le montant total du journal.\n\nBien qu'elle ne soit pas toujours utilisée pour analyser le flux de processus lui-même, la devise est vitale pour tout rapport financier ou analyse basée sur les montants du journal. Elle permet une agrégation et une comparaison correctes des valeurs, en particulier dans les organisations multinationales.
Pourquoi c'est important
Fournit le contexte nécessaire à toute analyse financière, garantissant que les valeurs monétaires sont interprétées correctement, en particulier dans les environnements multi-devises.
Où obtenir
Le code de devise est généralement disponible dans la table des lignes de journal, LedgerJournalTrans.
Exemples
USDEURGBPJPY
|
|||
|
Date de comptabilisation
PostingDate
|
La date à laquelle l'écriture de journal est enregistrée dans le grand livre général. | ||
|
Description
La date d'enregistrement (Posting Date) est la date officielle à laquelle la transaction affecte les soldes du grand livre général. Cette date est critique pour les rapports financiers et les périodes de clôture.\n\nCet attribut est utilisé pour analyser le décalage entre l'approbation et l'enregistrement, ce qui est le focus du KPI 'Délai d'enregistrement des écritures de journal'. Réduire ce décalage est souvent un objectif clé pour accélérer le processus de clôture financière. Il peut également être utilisé pour analyser les volumes d'enregistrement au fil du temps.
Pourquoi c'est important
Crucial pour le calcul du KPI du délai de validation et pour la compréhension des retards entre l'approbation et le moment où une transaction devient officielle dans le grand livre.
Où obtenir
Cette date est généralement stockée dans la table d'en-tête de journal (LedgerJournalTable) ou dans les tables de transactions enregistrées associées.
Exemples
2023-10-282023-11-012023-10-31
|
|||
|
Département
DepartmentName
|
Le département ou centre de coûts associé à l'écriture de journal. | ||
|
Description
Le département ou centre de coûts identifie l'unité commerciale interne responsable ou affectée par la transaction financière. C'est une dimension clé pour le reporting de gestion interne.\n\nCet attribut permet d'analyser le processus d'écriture de journal par département. Il peut aider à répondre à des questions telles que : Quels départements soumettent le plus de journaux ? Certains départements ont-ils des taux de rejet plus élevés ou des temps d'approbation plus longs ? Cela est utile pour des efforts d'amélioration de processus ciblés.
Pourquoi c'est important
Offre un moyen d'analyser la performance du processus par fonction métier, aidant à identifier les goulots d'étranglement ou les besoins de formation spécifiques aux départements.
Où obtenir
Ces informations se trouvent généralement au niveau de la ligne de journal (LedgerJournalTrans) en tant que dimension financière.
Exemples
VentesFinanceMarketingOpérations
|
|||
|
Dernière mise à jour des données
LastDataUpdate
|
Le `timestamp` des dernières `données` actualisées depuis le système source. | ||
|
Description
Cet attribut indique la date et l'heure de la dernière extraction de données du système source. Il fournit un contexte sur la fraîcheur de l'analyse et des données incluses.\n\nL'affichage de ces informations dans les tableaux de bord assure aux utilisateurs la pertinence des données et les aide à comprendre la période couverte par l'analyse de processus actuelle. C'est un élément clé des métadonnées pour tout projet de Process Mining.
Pourquoi c'est important
Fournit un contexte critique sur la fraîcheur des données, garantissant que les utilisateurs comprennent l'actualité de l'analyse du processus.
Où obtenir
Ce timestamp est généré et stocké pendant le processus d'extraction, de transformation et de chargement (ETL) des données.
Exemples
2023-10-27T02:00:00Z
|
|||
|
Est Du Premier Coup
IsFirstTimeRight
|
Un indicateur indiquant si le journal a été approuvé sans aucun rejet préalable. | ||
|
Description
Cet attribut booléen au niveau du cas est vrai si une écriture de journal passe de la soumission à l'approbation sans aucune activité intermédiaire 'Journal rejeté' ou 'Écriture de journal corrigée'. C'est une mesure clé de la qualité du processus.\n\nLe KPI 'Taux d'approbation du premier coup' est directement calculé à partir de cet attribut. Un taux élevé indique un processus efficace et de haute qualité, tandis qu'un taux faible signale des problèmes systémiques liés à la qualité initiale des données, à la clarté des exigences ou aux procédures de soumission.
Pourquoi c'est important
C'est une mesure critique de la qualité du processus, mettant en évidence le nombre de journaux qui traversent le processus d'approbation sans accroc ni retravail.
Où obtenir
Ceci est un attribut calculé dérivé au niveau du cas en analysant la séquence d'activités pour chaque ID d'écriture de journal.
Exemples
truefaux
|
|||
|
Est un retravail
IsRework
|
Un indicateur qui identifie les activités faisant partie d'une boucle de reprise ou de correction. | ||
|
Description
Cet attribut booléen calculé est défini à vrai pour les activités qui se produisent après un rejet, telles que 'Écriture de journal corrigée' ou une 'Soumission de journal pour approbation' répétée. Il aide à isoler et à quantifier les retouches.\n\nCet attribut est essentiel pour le tableau de bord 'Boucles de retravail et de correction des écritures de journal' et l'indicateur clé de performance (KPI) 'Taux de retravail'. En signalant les retouches, il devient facile de visualiser et de mesurer la fréquence et l'impact des cycles de correction, qui sont une source majeure d'inefficacité dans le processus.
Pourquoi c'est important
Signale directement les boucles de reprise inefficaces, facilitant la quantification de l'impact des rejets et des corrections sur le temps de cycle global et les coûts.
Où obtenir
Ceci est un attribut calculé dérivé lors de la transformation des données en analysant la séquence des activités au sein d'un cas.
Exemples
truefaux
|
|||
|
Niveau d'approbation
ApprovalLevel
|
Indique l'étape actuelle ou terminée dans un workflow d'approbation multi-niveaux. | ||
|
Description
Pour les écritures de journal qui nécessitent plusieurs approbations, cet attribut indique le niveau de la hiérarchie que l'écriture a atteint, par exemple, 'Approbation du responsable' ou 'Approbation du directeur'. Cet attribut est utile pour analyser plus en détail les goulots d'étranglement d'approbation. Il peut aider à déterminer si les retards se produisent systématiquement à un niveau spécifique de la chaîne d'approbation, suggérant un besoin de refonte du processus ou de réaffectation des ressources à ce stade.
Pourquoi c'est important
Offre une visibilité sur les workflows d'approbation à plusieurs étapes, aidant à identifier les goulots d'étranglement à des niveaux d'approbation spécifiques.
Où obtenir
Ces informations seraient dérivées du journal d'historique du workflow, en suivant l'achèvement des différentes étapes d'approbation.
Exemples
Niveau 1 : ManagerNiveau 2 : DirecteurNiveau 3 : VP Finances
|
|||
|
Statut SLA d'approbation
ApprovalSlaState
|
Indique si l'approbation de l'écriture de journal a respecté son accord de niveau de service. | ||
|
Description
Cet attribut catégorise le cycle d'approbation de chaque écriture de journal selon qu'il a été complété dans le délai cible défini par un accord de niveau de service (SLA). Les valeurs possibles sont généralement 'Atteint' ou 'Violé'.\n\nC'est la métrique centrale pour le tableau de bord 'Conformité SLA des approbations d'écritures de journal'. Il offre une vue claire et orientée métier de la performance par rapport aux objectifs, aidant à surveiller et gérer la ponctualité du processus d'approbation et à stimuler les améliorations là où les SLA sont fréquemment manqués.
Pourquoi c'est important
Transforme les données brutes de temps de cycle en un résultat commercial clair (atteint ou violé), facilitant le suivi des performances par rapport aux objectifs clés.
Où obtenir
Ceci est un attribut calculé. La logique nécessite de comparer le KPI 'Temps de cycle d'approbation' calculé à une cible SLA prédéfinie.
Exemples
AtteintDépassé
|
|||
|
Système source
SourceSystem
|
Le système d'enregistrement à partir duquel les données ont été extraites. | ||
|
Description
Cet attribut identifie l'application source d'où proviennent les données d'écriture de journal. Pour ce processus, la valeur est généralement une constante, telle que 'Microsoft Dynamics 365'.\n\nDans un contexte d'analyse plus large, en particulier dans les environnements avec plusieurs ERP ou systèmes intégrés, ce champ aide à différencier les processus et les sources de données. Il assure la clarté sur la provenance des données et est important pour la gouvernance et la validation des données.
Pourquoi c'est important
Identifie l'origine des données, ce qui est crucial pour la gouvernance des données et pour les analyses pouvant s'étendre sur plusieurs systèmes d'entreprise.
Où obtenir
Ceci est une valeur statique ajoutée lors du processus d'extraction, de transformation et de chargement (ETL) des données pour étiqueter l'origine du jeu de données.
Exemples
`Microsoft Dynamics 365`D365 F&O
|
|||
|
Temps de traitement
ProcessingTime
|
Le temps passé à travailler activement sur une activité. | ||
|
Description
Le temps de traitement mesure la durée entre le début et la fin d'une activité, représentant la durée réelle du travail. Il se distingue du temps de cycle, qui inclut le temps d'attente entre les activités.\n\nCette métrique calculée est essentielle pour le tableau de bord 'Performance utilisateur des écritures de journal'. Elle aide à comprendre combien de temps les utilisateurs ou les équipes mettent pour accomplir des tâches spécifiques, en éliminant l'influence des temps d'attente. Cela permet une évaluation plus juste et précise de l'efficacité des ressources.
Pourquoi c'est important
Mesure le temps de travail actif pour une activité, permettant l'analyse de l'efficacité des utilisateurs et des équipes sans le bruit des périodes d'attente.
Où obtenir
Ceci est calculé en prenant la différence entre l'heure de fin d'événement (EventEndTime) et l'heure d'événement (StartTime) pour chaque activité.
Exemples
PT5M15SPT1H15MP1DT2H
|
|||
|
Validation automatisée
IsAutomatedPosting
|
Un indicateur indiquant si l'écriture de journal a été créée ou validée automatiquement. | ||
|
Description
Cet attribut booléen distingue les écritures de journal créées manuellement par un utilisateur de celles générées automatiquement par le système ou un sous-système, tel qu'une intégration système ou un processus d'affectation automatisé.\n\nL'analyse de cet attribut aide à comparer l'efficacité et les taux d'erreur des processus automatisés par rapport aux processus manuels. Elle peut mettre en évidence des opportunités d'automatisation supplémentaire en montrant si les écritures manuelles sont plus sujettes aux erreurs, aux retouches ou aux retards.
Pourquoi c'est important
Sépare les processus manuels des processus automatisés, permettant une comparaison de leur efficacité, de leur précision et de leur conformité.
Où obtenir
Ceci peut être indiqué par l'utilisateur 'Créé par' (par exemple, un utilisateur système ou de lot) ou un indicateur spécifique sur l'en-tête du journal ou la configuration du type.
Exemples
truefaux
|
|||
Record to Report - Activités d'écriture de journal
| Activité | Description | ||
|---|---|---|---|
|
Écriture de journal créée
|
Cette activité marque l'initiation d'une nouvelle écriture de journal. Elle est capturée lorsqu'un utilisateur crée un nouvel enregistrement d'en-tête de journal dans le système, établissant un ID d'écriture de journal unique qui sert d'identifiant de cas pour l'analyse de processus. | ||
|
Pourquoi c'est important
C'est l'événement de début principal du processus. L'analyse du temps écoulé entre ce point et l'enregistrement est cruciale pour mesurer le temps de cycle de bout en bout et identifier les retards initiaux de saisie des données.
Où obtenir
Cet événement est capturé à partir du timestamp de création de l'en-tête du journal dans l'entité GeneralJournalEntry ou LedgerJournalTable. C'est généralement un événement explicite de création d'enregistrement.
Capture
Utilisez le champ 'createdDateTime' sur GeneralJournalEntry ou LedgerJournalTable.
Type d'événement
explicit
|
|||
|
Écriture de journal validée
|
Cette activité marque l'enregistrement réussi de l'écriture de journal dans le grand livre général, en faisant un enregistrement financier officiel. C'est un événement critique, capturé lorsque le statut de l'en-tête du journal est mis à jour en 'Enregistré'. | ||
|
Pourquoi c'est important
C'est l'événement de fin de succès principal du processus. Il est utilisé pour calculer le temps de cycle de bout en bout et le délai d'enregistrement, qui sont des indicateurs clés de l'efficacité de la clôture financière.
Où obtenir
Capturé à partir d'un changement de champ de statut (par exemple, JournalStatus passant à 'Validé') sur la LedgerJournalTable et de la création d'entrées correspondantes dans la GeneralJournalAccountEntry table.
Capture
Identifiez l'horodatage lorsque le statut du journal devient 'Validé'.
Type d'événement
inferred
|
|||
|
Journal approuvé
|
L'écriture de journal a été approuvée par l'autorité désignée, achevant la dernière étape du workflow d'approbation. Cela est généralement capturé à partir d'un changement de statut sur l'en-tête du journal, comme le passage à 'Approuvé'. | ||
|
Pourquoi c'est important
C'est une étape cruciale qui conclut le processus d'approbation et permet l'enregistrement. C'est essentiel pour calculer le temps de cycle d'approbation, le délai d'enregistrement et le taux d'approbation du premier coup.
Où obtenir
Déduit d'un changement de champ de statut (par exemple, ApprovalStatus passant à 'Approuvé') sur la LedgerJournalTable ou de la table d'historique de workflow indiquant un état d'approbation final.
Capture
Identifiez l'horodatage lorsque le statut du journal passe à 'Approuvé'.
Type d'événement
inferred
|
|||
|
Journal rejeté
|
L'écriture de journal a été rejetée par un réviseur ou un approbateur et nécessite une correction. Cet événement est capturé à partir d'un changement de statut sur le journal, tel que le passage à l'état 'Rejeté' ou 'Nécessite une correction'. | ||
|
Pourquoi c'est important
Le suivi des rejets est fondamental pour calculer le taux de rejet et identifier les causes profondes du retravail. Il met en évidence les problèmes de qualité des données, de conformité ou de formation des utilisateurs.
Où obtenir
Déduit d'un changement de champ de statut (par exemple, ApprovalStatus passant à 'Rejeté') sur la LedgerJournalTable ou du journal d'historique du workflow.
Capture
Identifiez l'horodatage lorsque le statut du journal passe à 'Rejeté'.
Type d'événement
inferred
|
|||
|
Journal soumis pour approbation
|
Représente la soumission formelle d'une écriture de journal complétée dans un workflow de revue et d'approbation. Cela est généralement déduit d'un changement de statut sur l'en-tête du journal, comme de 'Brouillon' à 'En Révision' ou 'Soumis'. | ||
|
Pourquoi c'est important
C'est une étape clé qui initie le cycle d'approbation. Mesurer le temps entre la soumission et l'approbation finale est essentiel pour identifier les goulots d'étranglement dans le processus de révision et surveiller la conformité aux SLA.
Où obtenir
Déduit d'un changement de champ de statut (par exemple, ApprovalStatus passant à 'EnRévision') sur la LedgerJournalTable ou des journaux d'historique de workflow associés au journal.
Capture
Identifiez l'horodatage lorsque le statut du journal passe à un état 'soumis' ou 'en révision'.
Type d'événement
inferred
|
|||
|
Annulation de l'écriture de journal initiée
|
Cet événement représente le début d'un processus pour annuler une écriture de journal précédemment enregistrée. Il est capturé lorsqu'un utilisateur initie l'action d'annulation dans le système. | ||
|
Pourquoi c'est important
Le suivi des annulations aide à identifier la fréquence et les raisons des corrections d'écritures enregistrées. Cela peut indiquer des problèmes sous-jacents lors des étapes initiales de saisie des données ou d'approbation.
Où obtenir
C'est généralement une action utilisateur explicite qui peut être capturée à partir des pistes d'audit ou en identifiant la création d'un nouveau journal d'annulation lié à l'original.
Capture
Utilisez l'événement de création d'une nouvelle écriture de journal qui est marquée comme une annulation d'un journal enregistré.
Type d'événement
explicit
|
|||
|
Écriture de journal annulée
|
Marque l'achèvement du processus d'annulation d'écriture de journal, où une écriture d'annulation est enregistrée avec succès. Cela constitue un point de fin alternatif pour le cycle de vie d'un journal incorrect. | ||
|
Pourquoi c'est important
Cette activité assure la clôture des écritures corrigées et aide à analyser l'effort total consacré aux ajustements post-enregistrement, ce qui a un impact sur l'efficacité globale du processus.
Où obtenir
Capturé lorsque la nouvelle écriture de journal d'annulation passe elle-même à un statut 'Validé'. Le lien vers le journal original est maintenu via un champ de référence.
Capture
Identifiez l'événement de statut 'Validé' pour l'écriture de journal d'annulation associée.
Type d'événement
inferred
|
|||
|
Écriture de journal corrigée
|
Cette activité indique qu'une écriture de journal précédemment rejetée a été modifiée par un utilisateur. Cela est généralement déduit en détectant une modification de l'en-tête du journal ou de ses lignes après l'enregistrement d'un statut 'Rejeté'. | ||
|
Pourquoi c'est important
Cette activité identifie explicitement les retouches. L'analyse de la fréquence et de la durée des boucles de correction aide à rationaliser le processus et à réduire l'effort manuel.
Où obtenir
Déduit en suivant les champs 'modifiedDateTime' et 'modifiedBy' sur les tables LedgerJournalTable ou LedgerJournalTrans après qu'un événement 'Journal Rejeté' s'est produit.
Capture
Comparez l'horodatage d'un statut 'Rejeté' avec les horodatages de modification ultérieurs par le créateur.
Type d'événement
inferred
|
|||
|
Journal soumis de nouveau pour approbation
|
Une écriture de journal corrigée est renvoyée dans le workflow d'approbation pour un nouveau cycle de révision. Cela est déduit d'un changement de statut de 'Rejeté' ou 'Brouillon' à 'En révision' ou 'Soumis'. | ||
|
Pourquoi c'est important
Cette activité marque le début d'une boucle de retravail. Le comptage de ces événements aide à quantifier le taux de retravail et le nombre moyen de boucles d'approbation par écriture de journal.
Où obtenir
Déduit de l'historique du workflow ou en suivant les changements de statut sur la LedgerJournalTable où le statut passe d'un état rejeté à un état soumis.
Capture
Identifiez un événement de statut 'Soumis' qui se produit après un événement de statut 'Rejeté' pour le même journal.
Type d'événement
inferred
|
|||
|
Ligne de journal ajoutée
|
Cet événement signifie qu'une ligne de débit ou de crédit a été ajoutée à l'écriture de journal. Il est capturé chaque fois qu'une nouvelle ligne de transaction est créée et associée à l'en-tête du journal. | ||
|
Pourquoi c'est important
Le suivi de la création des lignes d'écriture aide à comprendre la complexité et l'effort de saisie des données pour différents types de journaux. Il peut également mettre en évidence les retards entre la création de l'en-tête et la complétion des lignes.
Où obtenir
Capturé à partir de l'horodatage de création des enregistrements dans l'entité LedgerJournalTrans, lié à l'en-tête du journal. Chaque création de ligne est un événement discret.
Capture
Utilisez le champ 'createdDateTime' pour chaque enregistrement de la table LedgerJournalTrans.
Type d'événement
explicit
|
|||
|
Révision du journal commencée
|
Cette activité marque le moment où un réviseur commence à travailler activement sur un journal soumis. Cela peut être déduit lorsque le journal est assigné à un réviseur ou lorsque le réviseur ouvre pour la première fois l'enregistrement pour examen. | ||
|
Pourquoi c'est important
Cette activité aide à mesurer le temps de transfert du réviseur, qui est le délai entre la soumission et le début de la révision. Elle peut révéler des problèmes d'allocation des ressources ou de notification.
Où obtenir
Ceci n'est souvent pas explicitement enregistré. Cela peut être déduit des journaux d'attribution du workflow ou nécessite de comparer le timestamp de soumission au premier timestamp de modification par un utilisateur réviseur.
Capture
Nécessite l'analyse des journaux d'attribution des utilisateurs de workflow ou des journaux d'activité des utilisateurs, qui peuvent ne pas être standards.
Type d'événement
inferred
|
|||
|
Tentative de validation du journal
|
Cette activité signifie qu'un utilisateur a initié le processus d'enregistrement pour un journal approuvé. Cela peut être capturé explicitement si le système enregistre le début de la tâche d'enregistrement. | ||
|
Pourquoi c'est important
Distinguer la tentative de validation de la validation réussie peut aider à diagnostiquer les problèmes de performance du système ou les retards des tâches par lots qui affectent la clôture financière.
Où obtenir
Ceci peut être un événement explicite enregistré dans une table d'historique de tâche par lots ou déduit d'un changement de statut à 'Enregistrement en cours' sur la LedgerJournalTable.
Capture
Nécessite l'analyse des journaux de travaux par lots ou des journaux système liés à la routine d'enregistrement du Grand Livre.
Type d'événement
explicit
|
|||