Record to Report - 仕訳データテンプレート
Record to Report - 仕訳データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- Oracle Fusion Financials 向け抽出ガイド
決算報告(Record to Report)- 仕訳属性
| 名前 | 説明 | ||
|---|---|---|---|
|
アクティビティ
ActivityName
|
仕訳プロセスのある時点で発生した特定のビジネスイベントまたはタスクの名前。 | ||
|
説明
活動名とは、「仕訳作成」や「仕訳承認」など、仕訳ライフサイクルにおける個々のステップを指します。このデータは、プロセスマップを構築し、一連のイベントを理解するために不可欠です。 活動を分析することで、標準パス、逸脱、手戻りループを含むプロセスフローを特定できます。さまざまな活動を追跡することで、承認などの特定の段階で費やされた時間を測定し、どのステップが最も時間のかかる、またはエラーが発生しやすいかを特定できます。
その重要性
プロセスのステップを定義し、プロセスマップの基盤を形成し、フロー、ボトルネック、およびバリエーションの分析を可能にします。
取得元
この属性は通常、総勘定元帳モジュールの仕訳オブジェクトに関連付けられたステータス変更、イベントログ、または監査証跡テーブルから導出されます。
例
仕訳を作成承認のために仕訳提出済み仕訳入力承認済み仕訳入力転記済み
|
|||
|
仕訳入力ID
JournalEntryId
|
単一の仕訳に対する一意の識別子。関連するすべての財務取引活動をリンクします。 | ||
|
説明
仕訳IDは、特定の財務取引に関連するすべての活動を一意にリンクする主要なケース識別子として機能します。これにより、単一の仕訳のライフサイクル全体(開始から最終転記まで)を追跡し、すべての借方と貸方が正確に記録されていることを保証します。 プロセスマイニングにおいて、このIDは各仕訳のEnd-to-Endジャーニーを再構築するために不可欠です。「仕訳作成」、「承認のために提出された仕訳」、および「仕訳転記」のような異なるイベントを一貫したプロセスフローに接続し、サイクルタイム、ボトルネック、およびプロセスバリエーションの分析を可能にします。
その重要性
これは、仕訳を最初から最後まで追跡するための基本的なキーであり、各固有のケースのプロセスフロー全体を分析することを可能にします。
取得元
これは、GL_JE_HEADERSやGL_JE_LINESなどの主要な総勘定元帳テーブルに見られるプライマリキーです。
例
JE100523JE202311001882019
|
|||
|
開始時刻
EventTime
|
特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。 | ||
|
説明
このタイムスタンプは、活動が実行された正確な日付と時刻を示します。これは、プロセスマイニングでイベントの順序を決定し、それらの間の期間を計算するために使用される主要な時間要素です。 イベント時刻の正確性は、サイクルタイムの計算、ボトルネックの特定、サービスレベル契約に対するパフォーマンス監視など、すべての時間ベースの分析にとって重要です。それは、プロセスフローがどのように発生したかを再構築するために必要な時間順序を提供します。
その重要性
このタイムスタンプは、イベントの順序付け、すべてのプロセス期間の計算、およびあらゆる時間ベースの分析を実行するために不可欠です。
取得元
この情報は通常、特定のイベントについて、監査証跡テーブル、またはGL_JE_HEADERSやGL_JE_LINESなどのトランザクションテーブルの「最終更新日」や「作成日」として保存されます。
例
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
|
|||
|
ソースシステム
SourceSystem
|
データが生成されたシステムまたはモジュール。 | ||
|
説明
この属性は、プロセスデータが抽出されたソースシステムを識別します。複雑なIT環境では、データは複数の統合システムから取得される可能性があり、このフィールドはそれらを区別するのに役立ちます。 プロセス分析において、ソースシステムを知ることは、異なるシステム動作によって引き起こされる可能性のあるプロセスバリエーションを理解するために不可欠です。また、データの出所をたどることで、データ検証やトラブルシューティングにも役立ちます。
その重要性
データの出所を特定します。これは、データガバナンス、検証、および異なるシステム間でのプロセス変動を理解するために不可欠です。
取得元
これは、データ抽出中に設定される静的な値である場合が多く、またはエントリシステムを識別するソーステーブルのフィールドである場合もあります。
例
Oracle Fusion Financials CloudOracle EBS R12Fusion GL
|
|||
|
最終データ更新
LastDataUpdate
|
ソースシステムからの最新のデータ更新/抽出時点を示すタイムスタンプ。 | ||
|
説明
この属性は、データセットが最後に更新された日時を記録します。これは、分析対象データの鮮度に関するコンテキストを提供し、得られた洞察の関連性を理解するために重要です。 あらゆる分析、特に運用ダッシュボードにおいて、最終データ更新時刻を知ることは、ユーザーがデータを信頼し、情報に基づいた意思決定を行う上で不可欠です。これにより、プロセスマイニングモデルに含まれるデータの締め切りが明確に伝わります。
その重要性
データの鮮度を示し、ユーザーがプロセス分析の現在性を理解し、洞察を信頼できるようにします。
取得元
この値は、データ抽出および変換プロセス中に生成および保存されます。通常、ETL/ELTジョブが完了したときのタイムスタンプです。
例
2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
|
|||
|
`ユーザー部署`
UserDepartment
|
アクティビティを実行したユーザーが所属する部門またはチーム。 | ||
|
説明
この属性は、「財務」、「経理業務」、「内部監査」などの特定の部門に活動をリンクさせることで、組織的なコンテキストを提供します。通常、ユーザーマスターデータから導出されます。 ユーザー部門別に分析することで、部門横断的なボトルネックを特定し、チームのパフォーマンスを比較し、組織全体でプロセス実行がどのように異なるかを理解するのに役立ちます。これは、リソース配分や的を絞ったプロセス改善イニシアチブにとって価値があります。
その重要性
組織的なコンテキストを提供し、チームや部門ごとのパフォーマンス分析を可能にし、部門横断的な非効率性を浮き彫りにします。
取得元
これは通常、トランザクションテーブルにはありません。ユーザー名をユーザーマスターデータテーブルまたは人事システムデータと結合することで取得する必要があります。
例
一般会計財務報告買掛金
|
|||
|
ユーザー
UserName
|
活動を実行したユーザー(例:仕訳の作成、承認、転記など)。 | ||
|
説明
この属性は、活動の実行を担当する特定の従業員またはシステムユーザーを識別します。これは、ワークロードの分散、パフォーマンスの理解、および個々のボトルネックの特定に不可欠です。 分析において、ユーザー名(UserName)は、ユーザーによるプロセスのフィルタリング、ユーザー効率の比較、および遅延やエラーの原因調査を可能にします。これは、「チーム全体のユーザーワークロードと効率性」のようなダッシュボードや、「ユーザー仕訳ボトルネック指数」のようなKPIを直接サポートします。
その重要性
プロセスステップの責任を属性として割り当てることで、ユーザーの作業負荷、個々のパフォーマンス、およびトレーニングの必要性の分析を可能にします。
取得元
GL_JE_HEADERS(例: CREATED_BY、LAST_UPDATED_BY)などのトランザクションテーブルや関連する監査証跡テーブルにあります。
例
john.doesusan.smithautoprocess_user
|
|||
|
仕訳カテゴリ
JournalCategory
|
仕訳のカテゴリ(例:「未払金計上」、「調整」、「再分類」など)。 | ||
|
説明
仕訳カテゴリは、ビジネス目的に基づいて仕訳入力を分類します。この分類により、異なるカテゴリがそれぞれ独自のプロセスフロー、承認ルール、またはサイクルタイムを持つ可能性があるため、プロセスのより詳細な分析が可能になります。 例えば、月末調整仕訳は、通常の発生主義仕訳よりも複雑で緊急性の高いプロセスを持つ場合があります。カテゴリ別にプロセスを分析することで、これらのバリエーションを明らかにし、特定の種類の仕訳入力に合わせた改善策を策定するのに役立ちます。
その重要性
仕訳のビジネス目的によってプロセスをセグメント化することで、異なる入力タイプに対する異なる動作とパフォーマンスを明らかにすることができます。
取得元
GL_JE_HEADERSテーブルにあり、通常はJE_CATEGORYというフィールドにあります。
例
発生主義会計手動調整再評価
|
|||
|
仕訳元
JournalSource
|
仕訳を生成した補助元帳またはソース(例:「買掛金」、「売掛金」、「手動」など)。 | ||
|
説明
この属性は、ERPシステム内での仕訳の起源を示します。仕訳は総勘定元帳で手動で作成することも、買掛金、売掛金、固定資産などの補助元帳から自動的に生成することもできます。 仕訳ソースは、自動化分析のための重要な属性です。手動で作成された仕訳とシステム生成された仕訳を区別するのに役立ち、「自動仕訳入力率」KPIをサポートします。異なるソースからの仕訳のプロセスは、複雑性と効率性の点で大きく異なることがよくあります。
その重要性
手動入力と自動入力を区別します。これは、自動化率の測定とプロセス差の分析にとって重要です。
取得元
GL_JE_HEADERSテーブルにあり、通常はJE_SOURCEというフィールドにあります。
例
手動買掛金資産売掛金
|
|||
|
仕訳金額
JournalAmount
|
仕訳の総金額、通常は借方の合計。 | ||
|
説明
この属性は、仕訳で取引されている総財務価値を表します。金額はプロセスに影響を与える重要な要因となり得ます。例えば、高額な仕訳は追加の承認ステップやより徹底したレビューを必要とする場合があります。 仕訳金額を分析することで、財務的影響に基づいてケースをセグメント化できます。「高額な仕訳は承認に時間がかかりますか?」や「特定のしきい値を超える仕訳で却下が多いですか?」といった疑問に答えるのに役立ちます。これにより、プロセスフローに重要なビジネスコンテキストが提供されます。
その重要性
財務的影響に基づいた分析を可能にする重要なビジネスコンテキストを提供し、高額な仕訳が異なるプロセスをたどっているかどうかを特定するのに役立ちます。
取得元
この値は通常、特定の仕訳のGL_JE_LINESテーブルからの借方または貸方の合計として計算されます。
例
5000.00125000.75750.50
|
|||
|
却下理由
RejectionReason
|
仕訳入力が却下された理由を説明するテキスト記述またはコードです。 | ||
|
説明
仕訳が承認プロセス中に却下された場合、この属性は却下理由を捕捉します。これは事前に定義されたコードであるか、承認者からの自由記述コメントである場合があります。 これは、プロセス非効率性の根本原因分析にとって最も重要な属性の1つです。最も一般的な却下理由を分析することで、組織は作成者へのより良いトレーニング、より明確なガイドライン、またはシステム制御の強化など、改善の領域を特定できます。これは「仕訳却下率分析」ダッシュボードを直接サポートします。
その重要性
手戻りやプロセス遅延の根本原因を直接的に洞察し、承認却下率を削減するための的を絞った改善を可能にします。
取得元
この情報は、承認プロセスに関連するワークフローまたは監査証跡テーブルに保存されるか、仕訳ヘッダーのメモフィールドに保存される場合があります。
例
誤った勘定科目組み合わせ証拠書類不足予算超過
|
|||
|
エンドツーエンドサイクルタイム
EndToEndCycleTime
|
仕訳の作成から最終照合までの総計算期間。 | ||
|
説明
このメトリックは、最初の「仕訳作成」イベントから最終的な「仕訳照合済み」イベントまで、仕訳がプロセス全体に費やす総時間を表します。これはプロセスパフォーマンスの全体像を提供します。 これは、プロセス全体の効率性を測定するための主要なKPIです。トレンドダッシュボードで時間の経過に伴う改善イニシアチブの影響を追跡するために使用され、すべてのプロセス変更を測定するためのベースラインを提供します。
その重要性
プロセス全体の健全性と効率性を高レベルで測定し、経営層への報告における主要な指標とします。
取得元
このメトリックは、プロセスマイニングプラットフォームによって、各ケースの最初と最後のイベントタイムスタンプ間の時間差として計算されます。
例
P10DT5HP4DT12HP22D
|
|||
|
仕訳承認時間
JournalApprovalTime
|
仕訳提出から最終承認または却下決定までの計算された期間。 | ||
|
説明
このメトリックは、仕訳が承認のために提出されてから、承認または却下されるまでの経過時間を測定します。これは、承認ワークフローの効率性を測る重要な指標です。 仕訳承認時間(Journal Approval Time)は、「平均仕訳承認時間」KPIや「仕訳承認ボトルネック」ダッシュボードへの直接的な入力となります。この期間を分析することで、特定の承認者、部門、または仕訳タイプによって引き起こされるかどうかに関わらず、承認チェーンにおける遅延を特定するのに役立ちます。
その重要性
承認ワークフローの効率を直接測定します。これは、プロセス遅延の主要な原因となることがよくあります。
取得元
これはプロセスマイニングツール内で計算されるメトリックです。「承認のために提出された仕訳」イベントと「承認された仕訳」または「却下された仕訳」イベントの間の時間差です。
例
P2DT4H30MPT8HP5D
|
|||
|
会計期間
AccountingPeriod
|
仕訳が転記される会計期間(例:「24年1月」など)。 | ||
|
説明
会計期間は、取引が認識される財務期間を指定します。これは、すべての財務報告および分析の基本です。 プロセスマイニングにおいて、この属性はトレンド分析に不可欠です。月ごとまたは四半期ごとに、サイクルタイムや却下率などのプロセスパフォーマンスを比較できます。これにより、月末締めのワークロード増加のような季節性の影響を特定し、時間の経過に伴うプロセス改善の効果を測定するのに役立ちます。
その重要性
KPIの時系列トレンド分析を可能にし、プロセス改善の測定や、月末のプレッシャーのような季節的パターンの特定に役立ちます。
取得元
GL_JE_HEADERSテーブルにあり、通常はPERIOD_NAMEというフィールドにあります。
例
2024年1月2024年2月2024年3月
|
|||
|
元帳名
LedgerName
|
仕訳が記録される総勘定元帳の名前。 | ||
|
説明
元帳名(Ledger Name)は、仕訳が属する特定の元帳を識別します。複数の法的主体や報告要件を持つ組織では、企業会計用の主要元帳や、地域の法定報告用の補助元帳など、複数の元帳が存在する場合があります。 この属性は、異なる法的主体や事業単位間でプロセスをフィルタリングし、比較するために不可欠です。分析が正しい組織コンテキスト内で実施されることを保証し、これは財務コンプライアンスと報告にとって特に重要です。
その重要性
異なる法務実体や会計フレームワーク間でプロセス分析をフィルタリングおよび比較することを可能にし、大規模組織にとって不可欠です。
取得元
GL_JE_HEADERSテーブルにあり、通常はLEDGER_IDを介してリンクされ、GL_LEDGERSと結合して名前を取得できます。
例
米国主要元帳英国法定元帳グローバル連結元帳
|
|||
|
取り消しフラグ
ReversalIndicator
|
仕訳入力が別の入力の取り消しであるかどうかを示すフラグです。 | ||
|
説明
このブール型属性は、以前転記された仕訳を取り消すために作成された仕訳を識別します。取り消しは特定の種類の仕訳であり、しばしば独特で、時には問題のあるプロセスをたどります。 この指標を分析することは、「仕訳取り消しプロセスパフォーマンス」ダッシュボードをサポートする上で重要です。取り消しプロセスを分離して、その頻度、原因、サイクルタイムを測定し、取り消しが必要となる元の仕訳における根本的な問題を特定するのに役立ちます。
その重要性
振替プロセスを分離して分析するのに役立ちます。これは、元の取引におけるエラーや問題を示す指標となることがよくあります。
取得元
これは、GL_JE_HEADERSテーブル上のACCRUAL_REV_FLAGのような特定のフラグであるか、または取り消される元の仕訳へのリンクを介して識別できます。
例
truefalse
|
|||
|
定時転記であるか
IsOnTimePosting
|
仕訳が目標日までに転記された場合に真となる計算済みフラグです。 | ||
|
説明
このブール型属性は、「仕訳転記済み」活動のタイムスタンプを「目標転記日」と比較して導出されます。転記が目標日またはそれ以前に発生した場合、値は「true」となり、それ以外の場合は「false」となります。 この属性は、計算を簡素化することで「期限内仕訳転記率」KPIを直接サポートします。遅延した仕訳を簡単にフィルタリングして分析し、特定の仕訳カテゴリや承認者など、遅延の一般的な原因を特定できます。
その重要性
仕訳処理のパフォーマンスについて明確な二者択一の結果を提供し、期限内処理率の分析や遅延の根本原因特定を簡素化します。
取得元
この属性はプロセスマイニングツールによって計算されます。これには「TargetPostingDate」属性と「仕訳転記済み」活動のタイムスタンプが必要です。
例
truefalse
|
|||
|
手戻り
IsRework
|
仕訳入力が却下および修正サイクルを経た場合に真となる計算済みフラグです。 | ||
|
説明
このブール型属性は、手戻りが発生したケースを識別するために計算されます。通常、「仕訳却下」イベントに続く活動(例:「修正・再提出された仕訳」など)に対して「true」とフラグが立てられます。 「手戻り」は、手戻りループの量と影響を簡単に定量化できるため、分析にとって強力な属性です。「平均仕訳手戻り率」KPIを直接サポートし、手戻りが発生したケースと初回で正しく処理されたケースのプロセスフローと期間を比較するのに役立ちます。
その重要性
非効率な再作業ループを経たケースを直接フラグ付けすることで、プロセスの失敗の頻度と影響を容易に定量化できます。
取得元
これはソースシステムにはありません。各ケースの活動のシーケンスを分析することで、プロセスマイニングツール内で計算されます。
例
truefalse
|
|||
|
目標転記日
TargetPostingDate
|
仕訳が転記される予定の、事前に決定された日付。 | ||
|
説明
目標転記日(Target Posting Date)は、仕訳を総勘定元帳に転記する期限を表し、多くの場合、サービスレベル契約(SLA)や月末締めスケジュールによって決定されます。これはパフォーマンス測定のベンチマークとして機能します。 この属性は、「期限内仕訳転記率」KPIを計算するために不可欠です。実際の転記日とこの目標を比較することで、システムは自動的に仕訳を期限内または遅延としてフラグ付けし、スケジュールへのプロセス遵守度を明確に測定します。
その重要性
転記に関するサービスレベル契約または期限を定義し、定時実行KPIの計算を可能にします。
取得元
これは標準フィールドではない可能性があります。作成日、会計期間、または仕訳カテゴリに基づいてビジネスルールから導出される場合があります。
例
2023-10-312023-11-302024-01-05
|
|||
|
終了日時
EndTime
|
特定のアクティビティが完了した時点を示すタイムスタンプ。 | ||
|
説明
終了時刻は活動の完了を示します。開始時刻が始まりを記録するのに対し、終了時刻は終了点を提供し、特定のステップの処理時間を正確に計算することを可能にします。 これは、ボトルネックを特定し、リソース効率を測定するための主要な指標である活動処理時間を計算するために不可欠です。例えば、「仕訳レビュー済み」活動の終了時刻と開始時刻の差は、レビュー担当者がそのタスクに費やした実際の時間を示します。
その重要性
個々のアクティビティの実際の期間または処理時間の計算を可能にし、効率性の問題を特定する鍵となります。
取得元
開始時刻と同様に、これは監査証跡テーブルによく見られるか、プロセスの後続アクティビティの開始時刻から推測できます。
例
2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
|
|||
|
転記ステータス
PostingStatus
|
仕訳の現在の転記ステータス(例:「未転記」または「転記済み」)。 | ||
|
説明
この属性は、総勘定元帳への転記に関する仕訳の現在の状態を反映します。これは、特に進行中の仕訳において、仕訳がライフサイクルのどの段階にあるかを示す主要な指標です。 転記ステータスは、「リアルタイム仕訳ステータストラッカー」ダッシュボードにとって不可欠であり、すべてのアクティブな仕訳のスナップショットを提供します。これにより、未転記仕訳のバックログを監視し、プロセスの最終段階での遅延を特定するのに役立ちます。
その重要性
仕訳の現在の状態を示します。これは、バックログの監視や進行中の仕訳のステータス追跡に不可欠です。
取得元
GL_JE_HEADERSテーブルにあり、通常はSTATUSまたはPOSTING_STATUSのような列にあります。
例
転記済み未転記エラー
|
|||
|
通貨
CurrencyCode
|
仕訳金額の通貨コード(例:USD、EUR、GBPなど)。 | ||
|
説明
通貨コードは、仕訳における財務金額の通貨を指定します。これは、複数の通貨で取引を行う多国籍企業にとって不可欠です。 この属性は、財務価値が正確に解釈されることを保証します。通貨によるフィルタリングを可能にし、異なる地域間で金額を比較または集計するすべての分析を実行する際に必要なフィールドです。
その重要性
あらゆる財務金額に必要なコンテキストを提供し、正確な解釈を保証し、異なる通貨に特化した分析を可能にします。
取得元
GL_JE_HEADERSテーブルにあり、通常はCURRENCY_CODEというフィールドにあります。
例
USDEURGBPJPY
|
|||
決算報告(Record to Report)- 仕訳活動
| アクティビティ | 説明 | ||
|---|---|---|---|
|
仕訳を作成
|
この活動は、仕訳プロセスの開始を示します。ユーザーが新しい仕訳ヘッダーを作成し、データの入力を開始する時点を表しますが、これはまだレビューや承認のために提出される前の段階です。 | ||
|
その重要性
これはプロセスの主要な開始イベントです。この活動から後続ステップまでの時間を分析することで、初期データ入力の効率とプロセスサイクルタイム全体を測定するのに役立ちます。
取得元
このイベントは通常、特定の仕訳IDのGL_JE_HEADERSテーブルの作成日タイムスタンプから推測されます。レコードを作成したユーザーもこのテーブルで利用可能です。
取得
GL_JE_HEADERSテーブルのCREATION_DATEを使用します。
イベントタイプ
inferred
|
|||
|
仕訳入力承認済み
|
指定された承認者が仕訳を正式に承認し、その正確性と有効性を確認しました。これは承認ワークフローの最終ステップであり、転記への道を開きます。 | ||
|
その重要性
このマイルストーンは承認プロセスの終了を示します。提出から承認までの時間は、ワークフロー効率を測定し、承認ボトルネックを特定するための主要なKPIです。
取得元
このイベントは、GL_JE_HEADERSテーブルのステータス変更、具体的にはAPPROVAL_STATUS_CODEが「APPROVED」に更新されたことから推測されます。ワークフローテーブルには、承認者のIDとタイムスタンプが含まれます。
取得
GL_JE_HEADERSのAPPROVAL_STATUS_CODEが「APPROVED」に変更された際のタイムスタンプを追跡します。
イベントタイプ
inferred
|
|||
|
仕訳入力調整済み
|
会計期間末の勘定照合プロセス中に、仕訳が照合され、消し込まれました。これにより、取引が銀行取引明細書などの他の財務データと一致することが確認されます。 | ||
|
その重要性
この活動は、仕訳のライフサイクルにおける真の終点として機能します。転記から照合までの時間を測定することは、決算プロセスの効率性を評価するための主要なKPIです。
取得元
このイベントは通常、総勘定元帳自体ではなく、Oracle Financial Consolidation and Close Cloud Service (FCCS) または Account Reconciliation Cloud Service (ARCS) で捕捉されます。これは、仕訳にリンクされた照合レコードのステータス変更から推測されます。
取得
仕訳データをARCSまたはFCCSテーブルからの調整ステータス更新と相関付けます。
イベントタイプ
inferred
|
|||
|
仕訳入力転記済み
|
仕訳の財務データは総勘定元帳に正常に記録されました。借方と貸方は現在、勘定残高に反映されています。 | ||
|
その重要性
これは、仕訳が公式な財務記録に記録されることを示す重要なマイルストーンです。期限内転記率と、作成から転記までの総時間を測定するために不可欠です。
取得元
これは、GL_JE_HEADERSテーブルでSTATUSフィールドが「P」(転記済み)に変わった際のステータス変更から推測されます。GL_JE_BATCHESテーブルにも転記ステータスがあります。
取得
GL_JE_HEADERSのSTATUSが「P」に変更された際のタイムスタンプを追跡します。
イベントタイプ
inferred
|
|||
|
承認のために仕訳提出済み
|
この活動は、ユーザーが完成した仕訳を正式に承認ワークフローに提出する際に発生します。仕訳を下書きまたは未完了の状態から承認待ちの状態に移行させます。 | ||
|
その重要性
これは、承認サイクル時間を測定し、ボトルネックを特定するための計時を開始する重要なマイルストーンです。データ入力フェーズをレビューおよび承認フェーズから分離します。
取得元
このイベントは、GL_JE_HEADERSテーブルのステータス変更、特にAPPROVAL_STATUS_CODEが「REQUIRED」または「INITIATED」のような値に変わったときに推測されます。提出日のタイムスタンプも記録される場合があります。
取得
GL_JE_HEADERSのAPPROVAL_STATUS_CODEが提出を示す値に変更された際のタイムスタンプを追跡します。
イベントタイプ
inferred
|
|||
|
仕訳修正および再提出
|
仕訳入力が却下された後、作成者は必要な修正を行い、承認のために再提出します。このアクティビティは、同じ仕訳に対する新しい承認サイクルの開始を表します。 | ||
|
その重要性
手戻りの追跡は、プロセスの非効率性を理解するために不可欠です。この活動は、「仕訳却下」と組み合わせることで、手戻りの時間と頻度を測定することを可能にします。
取得元
これは、以前「REJECTED」状態であった仕訳に対する後続の「承認のために提出された仕訳」イベントです。単一の仕訳IDのステータス変更のシーケンスを分析することで識別されます。
取得
同じケースIDの却下イベントの後に発生する提出イベントのタイムスタンプを特定します。
イベントタイプ
inferred
|
|||
|
仕訳入力レビュー済み
|
正式な承認プロセスの前またはその一部として発生する可能性のあるレビュー段階です。これは、最終承認者に移行する前に、正確性とコンプライアンスを確認するための同僚またはマネージャーによるチェックを表します。 | ||
|
その重要性
このアクティビティを分離することで、予備レビュー時間と最終承認時間を区別するのに役立ちます。レビュー段階が非公式であっても時間がかかる場合、隠れたボトルネックを明らかにすることができます。
取得元
これは、多段階承認ワークフローにおける明示的なステップであり、ワークフロー履歴テーブルに捕捉される場合があります。非公式な場合は捕捉されません。最終承認決定の前に特定のユーザーアクションがログに記録されていれば推測できます。
取得
最終的な「承認済み」ステータスになる前の中間承認またはレビューのステップについて、ワークフロー履歴テーブルを分析します。
イベントタイプ
inferred
|
|||
|
仕訳入力却下済み
|
承認者が仕訳入力を確認し、エラー、証拠書類の不足、またはポリシー違反により却下しました。このアクションにより、仕訳は修正のために作成者に戻されます。 | ||
|
その重要性
この活動は、手戻りループ、却下率、初回正しい処理率の分析に不可欠です。却下の頻度が高い場合は、データ品質やトレーニングに問題があることを示しています。
取得元
これは、GL_JE_HEADERSテーブルでAPPROVAL_STATUS_CODEが「REJECTED」に更新された際のステータス変更から推測されます。ワークフロー履歴には、このアクションのユーザーとタイムスタンプが記録されます。
取得
GL_JE_HEADERSのAPPROVAL_STATUS_CODEが「REJECTED」に設定された際のタイムスタンプを追跡します。
イベントタイプ
inferred
|
|||
|
仕訳振替処理済み
|
元の仕訳の財務上の影響を後続期間で相殺するために、振替仕訳が作成され、転記されました。これは、発生主義会計でよく行われる処理です。 | ||
|
その重要性
取り消しを追跡することは、頻繁に取り消されるエントリの種類を特定し、取り消しプロセス自体の効率性を分析するのに役立ちます。これは、発生主義管理における問題を示唆する可能性があります。
取得元
これは、新しい仕訳エントリが元の仕訳エントリの取り消しとして明示的にリンクされていることを識別することによって推測されます。GL_JE_HEADERSテーブルには、これらのエントリを識別してリンクするためのREVERSAL_PERIODやREVERSAL_FLAGなどのフィールドがあります。
取得
元の仕訳が振替されたことをヘッダーが参照する新しい仕訳の作成日と転記日を特定します。
イベントタイプ
inferred
|
|||
|
仕訳転記開始
|
承認された仕訳を総勘定元帳に転記するプロセスが開始されました。これは、仕訳を転記プログラムによる処理のためにキューに入れる自動または手動のステップであり得ます。 | ||
|
その重要性
この活動は、承認と技術的な転記プロセスを分離します。承認と転記開始の間の遅延は、転記エンジンにおけるスケジューリングの問題やリソースの制約を示す可能性があります。
取得元
これは、GL_JE_BATCHESテーブルのステータス変更から、または仕訳バッチに関連付けられた転記コンカレントリクエストの提出時刻から推測できます。
取得
特定の仕訳バッチに対する総勘定元帳転記プログラムのリクエスト提出時間を特定します。
イベントタイプ
inferred
|
|||
|
証拠書類が添付された
|
仕訳に請求書やスプレッドシートなどの補足資料を添付する行為を表します。これは、監査人や承認者に対してコンテキストや証拠を提供するためによく行われます。 | ||
|
その重要性
この活動を追跡することで、遅延が書類不足によって引き起こされているかどうかを理解するのに役立ちます。また、承認ワークフローに入る前の仕訳のコンプライアンスと完全性に関する洞察も提供します。
取得元
これを個別のイベントとして追跡するのは難しい場合があります。GL_JE_HEADERSの仕訳レコードにリンクされたFND_ATTACHED_DOCUMENTSなどの添付ファイルテーブルのタイムスタンプから推測できる可能性があります。
取得
仕訳にリンクされたFND_ATTACHED_DOCUMENTSのレコードの作成日から推測します。
イベントタイプ
inferred
|
|||
|
転記検証済み
|
転記後に、ユーザーまたはシステムが仕訳が正しく転記され、残高が期待どおりであることを確認する検証ステップです。これは多くの場合、手動による統制ステップです。 | ||
|
その重要性
このアクティビティを分析することで、転記後の手動による統制と品質保証に費やされた時間を理解するのに役立ちます。これは、検証プロセスを自動化する機会を浮き彫りにすることができます。
取得元
これはOracle Fusionにおいて明示的なイベントである可能性は低いです。ユーザーが特定のレポートを実行したり、カスタムステータスフィールドが更新されたりするなど、標準的ではない他のアクションから推測する必要があります。
取得
検証レポートの実行時間追跡や記述フレックスフィールドの更新など、カスタムロジックが必要です。
イベントタイプ
inferred
|
|||