データテンプレート: 受注から入金まで - 受注処理
受注から入金までの受注処理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- SAP ECCの抽出ガイダンス
受注から現金化までの受注処理属性
| 名前 | 説明 | ||
|---|---|---|---|
受注伝票 SalesOrder | 受注伝票ドキュメントの一意識別子。Order to Cash(受注から入金まで)全体を追跡する主たるケースとして機能します。 | ||
説明 受注伝票は販売プロセスの中心となるドキュメントで、顧客からの製品・サービスの依頼を表します。開始から完了までの処理に必要な情報がすべて含まれます。 プロセスマイニングでは、この属性を Case ID として用います。固有の受注番号1件が、エンドツーエンドのプロセス実行(ケース)1件に対応します。受注単位で分析することで、ライフサイクル全体の追跡、サイクルタイムの測定、各注文ごとのばらつきの把握が可能になります。 その重要性 これは、すべての関連するアクティビティやイベントを連携させ、個々の顧客オーダーのプロセス全体をエンドツーエンドで分析するための不可欠なキーとなります。 取得元 販売伝票ヘッダーデータテーブル(VBAK)のVBELNフィールドにあります。 例 900001234590000123469000012347 | |||
アクティビティ Activity | 受注プロセス内で発生した特定の業務ステップまたはイベントの名称。 | ||
説明 この属性は、Order to Cash プロセスにおける1ステップを表します(例:「Sales Order Created」「Delivery Created」「Payment Received」)。これらのアクティビティは、受注ごとのプロセスフローを再構成するための基本要素です。 これらのアクティビティの順序とタイミングを分析することが、プロセスマイニングの中核です。プロセスマップの可視化、ボトルネックの特定、プロセスバリアントの発見、標準モデルに対するコンプライアンスチェックに役立ちます。アクティビティは通常、ドキュメント作成のイベント、ステータス変更、システムに記録された特定のトランザクションコードの組み合わせから導出されます。 その重要性 アクティビティはプロセスマップの根幹をなし、プロセスフロー、逸脱、そしてボトルネックの可視化と分析を可能にします。 取得元 これは導出属性であり、通常、data(データ)抽出時にSAPtransaction code(トランザクションコード)(Tcode)や伝票status(ステータス)変更(例:VBUK、VBUPテーブルにおける)、または変更伝票log(ログ)(CDHDR、CDPOSテーブル)をuser-friendly(ユーザーフレンドリー)なactivity名にmapping(マッピング)することによって生成されます。 例 販売注文作成済み出荷伝票作成済商品出庫済み請求書作成支払い受領済み | |||
ソースシステム SourceSystem | データが抽出されたソースシステムを特定します。 | ||
説明 この属性は、発生元のsystem(システム)を指定します。例えば、特定のSAP ECCインスタンス名やクライアント番号などです。複数の本番systemやlegacy system(レガシーシステム)からのdata(データ)が存在する環境において、dataにcontext(コンテキスト)を提供します。 analysis(分析)においては、dataの発生元に基づいてdataをfilter(フィルタリング)したりsegment(セグメント化)したりするために用いられます。これは、異なるsystem間でのプロセス比較やsystem移行プロジェクトにおいて、dataの整合性と一貫性を確保する上で特に役立ちます。 その重要性 特に複数システムが連携する環境において重要なコンテキストを提供し、プロセス比較を可能にするとともに、データのトレーサビリティを明確に確保します。 取得元 この値は通常、データ抽出プロセス中に追加され、多くの場合、SAPシステム ID (SAPSID) やクライアント (MANDT) を表す静的な値です。 例 ECC_PROD_800SAP_ERP_EU1ECC_QAS_300 | |||
最終データ更新 LastDataUpdate | このレコードのデータがソースシステムから最後に更新されたタイムスタンプです。 | ||
説明 この属性は、特定のイベントまたはケースに対して、直近のデータ抽出や更新が行われた日時を記録します。分析対象のデータの鮮度を明確にします。 ダッシュボードやレポートでは、インサイトのタイムリーさを理解するために重要な情報です。分析が最新の業務状態を反映しているのか、過去のデータに基づいているのかを確認でき、データの新しさに関するユーザーの期待値を適切に管理できます。 その重要性 プロセスマイニング分析に基づいてタイムリーで情報に基づいた意思決定を行うために不可欠な、データの鮮度をユーザーが認識できるようにします。 取得元 これはmetadata(メタデータ)属性であり、data(データ)取り込み時にdata抽出tool(ツール)またはプロセスによってpopulate(入力)されます。ソースSAPテーブルには保存されません。 例 2024-06-10T05:00:00Z2024-06-11T05:00:00Z2024-06-12T05:00:00Z | |||
開始時刻 StartTime | アクティビティまたはイベントの開始時点を示すタイムスタンプ。 | ||
説明 「Start Time」(別名イベントタイムスタンプ)は、特定のアクティビティが発生した正確な日時を記録します。例えば、受注の作成、出庫(出荷)の計上、請求書の計上などのタイミングです。 このタイムスタンプは、時間ベースのあらゆる分析の基礎です。アクティビティ間のサイクルタイム計算、ケースの総所要時間の測定、遅延やボトルネックの把握に用います。納期遵守やフルフィルメントのリードタイムを監視するダッシュボードなど、性能分析には正確なタイムスタンプが不可欠です。 その重要性 これは、cycle time(サイクルタイム)や期間といったすべてのパフォーマンスmetric(指標)を計算するための重要な属性であり、bottleneck(ボトルネック)を特定する上で不可欠です。 取得元 これは複合属性であり、通常、VBAK(受注)、LIKP(出荷)、VBRK(請求書)といった様々なSAPテーブルから、日付field(例:ERDAT)と時間field(例:ERZET)を組み合わせて導出されます。 例 2023-04-15T09:00:12Z2023-04-16T14:30:00Z2023-04-20T11:22:45Z | |||
ユーザー User | 伝票を作成または最終更新した、あるいはアクティビティを実行した従業員のユーザーID。 | ||
説明 この属性は、プロセス内の特定のイベントに責任を持つ SAP のユーザーIDを保持します。例えば、受注を作成した営業担当や、出庫(出荷)計上を行った倉庫担当者を識別できます。 ユーザー別にプロセスを分析すると、業務負荷の分散、教育ニーズ、同一業務における実行方法のばらつきが見えてきます。リソースパフォーマンス、コンプライアンス、手動対応の特定に焦点を当てたダッシュボードに不可欠です。 その重要性 リソースのパフォーマンスと作業負荷を可視化し、ユーザー固有のプロセス逸脱を特定するのに役立ちます。これは、コンプライアンスや自動化の分析において非常に重要です。 取得元 VBAK、LIKP、VBRKなどの多くのSAPヘッダーテーブルにおいて、「登録者」フィールド(ERNAM)または「変更者」フィールド(AENAM)として見られます。 例 CBURKEJSMITHRWILLIAMS | |||
出荷ブロック DeliveryBlock | 販売オーダーが出荷ブロックされ、出荷伝票の作成ができない状態を示すコードです。 | ||
説明 「出荷ブロック」は、納品ステップの前で処理を一時停止するために受注伝票(ヘッダ/明細)に設定されるステータスです。ブロックは、ユーザーが手動で設定する場合と、与信限度超過や情報不備などの理由でシステムが自動設定する場合があります。 この属性は「受注ブロックと手戻り分析」ダッシュボードに不可欠です。ブロックの発生頻度・滞留期間・原因を分析することで、フルフィルメントの主要なボトルネックを特定できます。ブロックの削減は、納期遵守と全体のサイクルタイム改善の近道です。 その重要性 履行プロセスにおけるボトルネックを直接特定します。受注がブロックされる理由と頻度を分析することは、フロー効率を向上させる上で極めて重要です。 取得元 販売伝票ヘッダーデータテーブル(VBAK)のLIFSKフィールドにあります。 例 0102Z1 | |||
却下理由 RejectionReason | 販売オーダーの品目が拒否された、またはキャンセルされた理由を示すコードです。 | ||
説明 「拒否理由」は、受注全体または特定の明細が出荷・完了に至らなかった理由を示します。顧客都合のキャンセル、在庫不足、その他の業務上の理由などが該当します。 この属性は「受注キャンセル動向」ダッシュボードに不可欠です。よくある拒否理由を分析することで、失注の根本原因を特定できます。その示唆をもとに、在庫管理、価格戦略、顧客コミュニケーションを見直し、キャンセル率の低減につなげられます。 その重要性 受注キャンセルが発生する「理由」を明確にし、真因分析を通じて販売機会損失の削減と予測精度の向上を支援します。 取得元 販売伝票明細データテーブル(VBAP)のABGRUフィールドにあります。 例 0215Z5 | |||
受注サイクルタイム SalesOrderCycleTime | 受注の作成から最終クローズまたは入金までの総所要時間。 | ||
説明 この計算metric(指標)は、個々の販売注文のend-to-end(エンドツーエンド)の処理時間を測定します。通常、最初のactivity(「受注作成」)のtimestampと、最後のactivity(例:「入金完了」または「注文品目クローズ」)のtimestampの差として計算されます。 この属性は、「受注end-to-end cycle time(エンドツーエンドサイクルタイム)ダッシュボード」および「受注fulfillment(履行)cycle time KPI」の主要な測定基準です。プロセス効率の全体像を提供し、長期滞留している注文やプロセスの全体的な健全性を特定する上で重要なmetricです。このmetricの分布をanalysis(分析)することで、benchmark(ベンチマーク)を設定し、改善活動の効果を経時的に追跡するのに役立ちます。 その重要性 これはプロセス全体の速度と効率を測定するための主要なKPIであり、改善活動の重要なベースラインとなります。 取得元 これは、特定のSalesOrder(受注)における最大StartTimeと最小StartTimeの差を算出することにより、event log(イベントログ)から導出される計算metric(指標)です。 例 10日4時間25日11時間5日2時間 | |||
品目コード MaterialNumber | 販売する製品またはサービスを一意に識別するID。 | ||
説明 品目番号は、受注明細に記載された特定の品目を識別します。1件の受注に複数の品目が含まれるため、この属性は通常、明細単位で分析します。 品目番号別にプロセスを分析すると、製品特有の課題が見えてきます。例えば、特定の製品でフルフィルメントに時間がかかる、出荷ブロックの発生率が高い、請求書の不一致が多いといった傾向を把握できます。サプライチェーンやプロダクトマネジメントが製品ラインごとにプロセスを最適化するうえで重要な視点です。 その重要性 製品ベースのプロセス分析を可能にし、どの製品が遅延、ブロック、手戻りといったプロセスの非効率性に関連しているかを明らかにします。 取得元 販売伝票明細データテーブル(VBAP)のMATNRフィールドにあります。 例 FG-1001-ARAW-205BSERV-INSTALL | |||
純額 NetAmount | ヘッダレベルで設定された税金・値引きを除いた受注伝票の合計金額。 | ||
説明 Net Amountは、販売オーダーの金銭的価値を表します。これは、各プロセスインスタンスに関連付けられた主要な財務指標です。\n\nこの属性は、価値ベースのプロセスマイニングに不可欠です。高額オーダーに焦点を当てることで、プロセス改善の取り組みを優先させることができます。アナリストは、遅延や手戻りといったプロセス上の問題を財務的影響と関連付け、変更に対するより強力なビジネスケースを構築するのに役立てることができます。例えば、高額オーダーが低額オーダーと比較して、より効率的に処理されているかどうかを分析するために使用できます。 その重要性 価値ベースの分析を可能にし、会社に最も重要な財務的影響を与える受注に対する改善努力の優先順位付けに役立ちます。 取得元 販売伝票ヘッダーデータテーブル(VBAK)のNETWRフィールドにあります。 例 1500.0012550.75850.50 | |||
販売組織 SalesOrganization | 製品やサービスの販売を担当する組織単位。 | ||
説明 販売組織とは、SAPにおける主要な組織単位であり、企業の販売要件に基づいて組織構造を定めます。販売条件の交渉や、商品・サービスの流通を担います。 プロセスマイニングにおいて、このアトリビュートは、分析において重要な軸となります。異なる販売単位、地域、部門間でプロセスパフォーマンス、効率、コンプライアンスを比較することが可能です。これにより、高実績組織におけるベストプラクティスを特定し、他組織での改善点を洗い出すのに役立ちます。 その重要性 組織間のベンチマーキングを可能にし、異なる事業部門や地域間でのプロセス効率性やコンプライアンスの比較を実現します。 取得元 販売伝票ヘッダーデータテーブル(VBAK)のVKORGフィールドにあります。 例 100025003100 | |||
顧客番号 CustomerNumber | 受注を行った顧客の一意識別子。 | ||
説明 この属性は、販売注文に関連付けられた主要な顧客口座である「Sold-to Party」(得意先)を表します。これは、取引をmaster data(マスタデータ)内の特定の顧客にリンクさせます。 顧客番号でanalysis(分析)することで、プロセスをsegment(セグメント化)し、顧客固有の行動とパフォーマンスを理解できます。どの顧客にcycle time(サイクルタイム)の長期化、手戻り率の高さ、あるいは注文変更の頻発といった傾向があるのかを把握するのに役立ちます。これは、顧客関係管理(CRM)とservice level(サービスレベル)を向上させる上で不可欠です。 その重要性 顧客中心の分析を可能にし、特定の顧客に影響を与えるプロセス問題の特定や、顧客固有のパフォーマンス測定に役立ちます。 取得元 販売伝票ヘッダーデータテーブル(VBAK)のKUNNRフィールドにあります。 例 100234100567200112 | |||
与信チェックステータス CreditCheckStatus | 販売伝票のクレジットチェックのステータスを示します。 | ||
説明 この属性は、販売注文に対して行われる自動または手動のcredit check(与信チェック)の結果を示します。一般的なstatus(ステータス)は、「承認済み」、「却下」、「保留中」などです。 これは「与信チェック処理時間analysis(分析)ダッシュボード」にとって重要な属性です。credit check段階での遅延や停止は、全体の受注処理cycle time(サイクルタイム)に大きな影響を与える可能性があります。このstatusをanalysis(分析)することで、与信管理プロセス(credit management process)の効率と販売速度への影響を理解するのに役立ちます。 その重要性 受注処理速度に直接影響します。このステータスを分析することで、受注履行を遅らせる信用管理におけるボトルネックの特定に役立ちます。 取得元 販売伝票ヘッダーステータステーブル(VBUK)またはVBAKに直接、クレジットステータスフィールド(例:CMGST)として見られます。 例 ABD | |||
出荷条件 ShippingConditions | 顧客への商品の配送に関する一般的な出荷戦略を定義します。 | ||
説明 出荷条件は、受注がどのように出荷されるかを決定します(例:「標準」、「速達」、「店舗受け取り」など)。これは顧客との間で合意され、ロジスティクス計画に影響を与えます。 この属性は、「出荷方法の効率とコスト」分析で使用されます。出荷条件によってプロセスをセグメント化することで、特定のメソッドが遅延を起こしやすいか、またはサイクルタイムが長いかを企業が分析できます。このデータは、ロジスティクスを最適化し、配送時間に関する顧客の期待を管理するのに役立ちます。 その重要性 ロジスティクスパフォーマンスの分析を可能にし、特定の配送方法が遅延と相関しているか、あるいはより高い効率性をもたらすかを判断するのに役立ちます。 取得元 販売伝票ヘッダーデータテーブル(VBAK)のVSBEDフィールドにあります。 例 011020 | |||
定時配送 IsOnTimeDelivery | 商品が確定納期通り、またはそれ以前に出荷されたかどうかを示すブール値フラグです。 | ||
説明 この計算属性は、販売注文の実際の出庫日と「ConfirmedDeliveryDate(確定納期)」を比較します。もし出庫日が確定納期以前である場合、「true」とマークされ、そうでなければ「false」とされます。 この属性は、「納期遵守パフォーマンスダッシュボード」の作成と「納期遵守率KPI」の計算を簡素化します。これにより、すべてのanalysis(分析)やchart(チャート)でreal-time(リアルタイム)での日付比較を行うことなく、パフォーマンスのaggregation(集計)とvisualization(可視化)を容易に行えるようになります。その結果、配送の信頼性を一目で明確に測定できます。 その重要性 配送パフォーマンスを明確かつシンプルに測定することで、全体的なオンタイム配送率 KPIの算出を容易にします。 取得元 これは計算属性です。ロジックは、「出庫activity」のtimestampを「ConfirmedDeliveryDate」属性の値と比較します。 例 truefalse | |||
手戻り IsRework | 販売オーダーが初回作成以降に大幅な変更や手直し作業が行われたかどうかを示すブール値フラグです。 | ||
説明 この計算属性は、「受注変更activity」の発生など、rework(手戻り)が発生したprocess instance(プロセスインスタンス)を識別します。例えば、価格、数量、納期といった変更がrework(手戻り)に該当するかどうかは、プロジェクト設定時に定義されます。 この属性は、「受注手戻りおよび変更頻度ダッシュボード」と「受注手戻り率KPI」にとって不可欠です。これにより、straight-through(直行)パスを辿った注文と、手動での変更が必要だった注文とを直接filter(フィルタリング)して比較することが容易になり、analysis(分析)を簡素化します。これは、reworkがcycle time(サイクルタイム)とcost(コスト)に与える影響を定量化するのに役立ちます。 その重要性 手戻りの頻度を直接定量化し、その原因と、プロセス全体の効率およびサイクルタイムへの影響を分析することができます。 取得元 これは、event log(イベントログ)から導出される計算属性です。ロジックは、「受注変更activity」またはCDHDR/CDPOSテーブルからの特定の変更event(イベント)の存在をチェックします。 例 truefalse | |||
確認済納品日 ConfirmedDeliveryDate | 商品の納品またはサービス提供が確定し、顧客に通知した日付。 | ||
説明 これは、材料の供給状況と生産計画に基づいて顧客に確約された納期です。納期実績を測定するためのベースラインとなります。 この属性は、オンタイムデリバリーパフォーマンスダッシュボードとオンタイムデリバリーレート KPI の基礎となります。確定納期と実際の出荷日を比較することで、注文が予定通りに配送されたか、早期だったか、遅延したかを分析できます。これはサプライチェーンの信頼性と顧客満足度を測る上で、主要な指標となります。 その重要性 これは、納期遵守パフォーマンスを測定する上でのbenchmark(ベンチマーク)であり、顧客満足度とsupply chain(サプライチェーン)の効率性にとって重要なKPIです。 取得元 販売伝票日程行テーブル(VBEP)のEDATUフィールドにあります。 例 2023-05-102023-06-202023-07-01 | |||
受注から現金化までの受注処理活動
| アクティビティ | 説明 | ||
|---|---|---|---|
オーダー明細クローズ | このアクティビティは受注明細の最終クローズを示し、納品・請求が完了し、処理済みであることを意味します。明細の全体ステータスから推定されます。 | ||
その重要性 プロセスの成功した終了イベントとして機能します。明細がいつクローズされるかを分析することで、エンドツーエンドのプロセス期間を理解し、不必要に未処理のままになっている受注を特定するのに役立ちます。 取得元 明細に対するVBUPテーブルの全体ステータスフィールド (販売伝票: 明細状態) から推測されます。VBUP-GBSTAが「C」(処理完了) の場合、明細はクローズされます。 取得 明細ステータス (VBUP-GBSTA) が「C」(処理完了) に変更されたことから推測されます。 イベントタイプ inferred | |||
商品出庫済み | 商品の所有権が移転し、正式に倉庫から出荷される重要なイベントです。これは、品目伝票の作成と在庫の更新を伴う、財務会計上の明確な転記処理です。 | ||
その重要性 これは「shipping(出荷)」event(イベント)であり、納期遵守とfulfillmentリードタイムを測定する上で重要なmilestone(マイルストーン)です。財務update(更新)をtrigger(トリガー)し、物理的なfulfillmentプロセスにおけるpoint of no return(後戻りできない点)となります。 取得元 出荷伝票にリンクされた出庫移動タイプ(例:601)の在庫移動伝票(MKPF/MSEG)の作成。 取得 出荷にリンクされた出庫移動タイプの在庫移動伝票(MKPF/MSEG)の作成。 イベントタイプ explicit | |||
支払い受領済み | このevent(イベント)は、顧客からの入金が確認され、請求書に適用されたことにより、未決済の売掛金item(品目)が消し込まれたことを示します。これは、財務伝票の消込から推測される会計eventです。 | ||
その重要性 これは売上を現金化する最終ステップです。「請求から支払いまでのサイクルタイム」(Invoice to Payment Cycle Time)と全体の「受注履行サイクルタイム」(Sales Order Fulfillment Cycle Time)を測定する上での終点となります。 取得元 顧客明細に対するBSEGテーブルの消込伝票情報から推測されます。BSEG-AUGBL (消込伝票) およびBSEG-AUGDT (消込日付) が入力されている場合、支払が受領されたと判断されます。 取得 売掛金明細のBSEGテーブルにおける消込日付 (AUGDT) の入力から推測されます。 イベントタイプ inferred | |||
注文確定済み | このアクティビティは、受注が初期チェックをすべて通過し、フルフィルメントに進める状態になったことを示します。ブロックが解除され、スケジュール行で数量が確定している場合に推定されます。 | ||
その重要性 これは、受注入力とfulfillment(履行)を区別する主要なmilestone(マイルストーン)となります。fulfillmentリードタイムと納期遵守パフォーマンスを測定するための開始点となります。 取得元 VBEPの出荷日程行に確認済数量(BMENG > 0)があり、注文が出荷のためにブロックされていない(例:VBUK-LIFSKが空である)場合に推測できます。 取得 スケジュール行の確認 (VBEP-BMENG > 0) およびヘッダーレベルのブロック解除から推測されます。 イベントタイプ inferred | |||
請求書作成 | 顧客請求書または請求伝票が作成されたことを示します。これは、システムに新しい伝票を生成し、プロセスの支払い部分を開始する明示的なイベントです。 | ||
その重要性 これは、「請求書発行から入金までのcycle time(サイクルタイム)」の計測を開始する重要なmilestone(マイルストーン)となります。請求処理の遅延は、cash flow(キャッシュフロー)に直接影響を与えます。 取得元 VBRKテーブル(請求伝票:ヘッダーデータ)に、その登録日付(ERDAT)に基づいて記録されます。受注または出荷伝票へのリンクはVBFAテーブルにあります。 取得 VBRKテーブルの作成タイムスタンプ (ERDAT) に基づくイベント。 イベントタイプ explicit | |||
販売注文作成済み | 新しい販売オーダー伝票が作成されたことを示します。これは、ユーザーが通常SAPのトランザクションVA01を介して新しいオーダーを保存した際に捕捉される明示的なイベントです。 | ||
その重要性 これは受注から現金化(Order to Cash)プロセスの主要な開始イベントです。そのタイミングを分析することは、全体のサイクルタイムと受注の発生頻度を測定するために不可欠です。 取得元 登録日付(ERDAT)と時刻(ERZET)を用いて、VBAKテーブル(受注伝票ヘッダーデータ)に記録されます。トランザクションコードはVBAK-TCODEに格納されています。 取得 VBAKテーブルの作成タイムスタンプ (ERDAT, ERZET) に基づくイベント。 イベントタイプ explicit | |||
ピッキング完了 | 出荷のための全ての明細が倉庫から物理的にピッキングされたことを示します。倉庫管理 (WM) が使用されている場合、これは転送オーダーのステータスから推測できます。 | ||
その重要性 ピッキング時間を分析することは、倉庫業務を最適化する上で役立ちます。ここでの遅延は、全体の出荷タイムラインとフルフィルメントサイクルに直接影響を与えます。 取得元 LIPS-KOSTAテーブルの出荷明細のピッキングステータスが「C」(完全ピッキング済み) に変更されたことから推測されます。WMが有効な場合は、転送オーダー確認 (LTAK/LTAPテーブル) から推測できます。 取得 ピッキングステータス (LIPS-KOSTA) の変更、またはWM転送オーダーの確認から推測されます。 イベントタイプ inferred | |||
与信審査実施 | 受注の顧客に対する自動または手動のクレジットチェックが完了したことを示します。これは通常、伝票全体のクレジットステータスの変更から推測されます。 | ||
その重要性 与信チェックはしばしば重要なボトルネックとなります。このステップにかかる時間を測定することは、「与信チェック処理時間分析」にとって不可欠であり、受注処理を加速するために重要です。 取得元 VBUKテーブルの与信ステータスフィールド (販売伝票: ヘッダー状態) から推測されます。VBUK-CMGSTがブロックから解除に変更されることで、このアクティビティが示されます。 取得 全体与信ステータスフィールド (VBUK-CMGST) の変更から推測されます。 イベントタイプ inferred | |||
出荷ブロック設定済 | 受注伝票に出荷ブロックが適用されるアクションを表し、出荷伝票の作成を阻止します。これは、変更ログから明示的に取得するか、ステータステーブルから推測することができます。 | ||
その重要性 このアクティビティは「受注ブロック率」KPIに直結します。ブロックの理由と発生頻度を把握することで、フルフィルメント遅延の要因を明らかにできます。 取得元 VBAK-LIFSKフィールドの変更ログ(CDHDR/CDPOS)で見つけることができます。あるいは、VBAK-LIFSKフィールドが入力されたときを観察することで推測されます。 取得 VBAK-LIFSKまたはVBAP-LIFSPフィールドの変更伝票からのイベント。 イベントタイプ explicit | |||
出荷伝票作成済 | このevent(イベント)は、出荷伝票の作成を示します。これは、倉庫に対してpicking(ピッキング)およびshipping(出荷)activityを開始するよう指示するものです。これは、伝票flow(フロー)から捕捉される明示的なeventです。 | ||
その重要性 これは物理的な履行プロセスにおける最初のステップです。注文確認から出荷伝票作成までの時間は、物流プロセスがどれだけ迅速に開始されたかを示します。 取得元 LIKPテーブル(SD伝票:出荷ヘッダーデータ)にレコードが作成されます。受注伝票へのリンクは伝票フローテーブルVBFAに保持されます。 取得 LIKPテーブルの作成タイムスタンプに基づくイベントで、VBFAテーブルを介してリンクされています。 イベントタイプ explicit | |||
注文キャンセル済み | 受注が履行前にキャンセルされたことを示します。これは通常、受注の関連するすべての明細に「却下理由」を適用することで捕捉されます。 | ||
その重要性 これは、「受注キャンセル率KPI」を直接support(サポート)する重要な失敗endpoint(終了点)となります。注文がいつ、なぜキャンセルされるのかを理解することは、販売プロセスにおける課題へのinsight(洞察)をもたらします。 取得元 販売オーダーのすべての有効な明細に対して、VBAP-ABGRU (却下理由) フィールドが入力されたことから推測されます。変更日はCDHDR/CDPOSで確認できます。 取得 全明細の「却下理由」フィールド (VBAP-ABGRU) への入力から推測されます。 イベントタイプ inferred | |||
納品確認済み | このアクティビティは、顧客が商品を受領したことの確認を表します。システムに納品証明(POD)が登録された時点で記録され、納品伝票のステータスが更新されます。 | ||
その重要性 このevent(イベント)は、実際の納期を提供します。これは、約束納期に対する「納期遵守率」を正確に測定するために不可欠です。 取得元 納品証明ステータス (VBUK-PODAT) が「C」(確認済み) に設定されたことから推測されます。確認日はVLPOD-PODATに保存されます。ただし、これは常に実装されているとは限りません。 取得 出荷伝票のPODステータス更新 (VBUK-PODAT) またはVLPODテーブルのエントリから推測されます。 イベントタイプ inferred | |||
請求書取消し済み | 以前に作成された請求伝票の取り消しを表します。これは、元の請求伝票を相殺するための新しいキャンセル伝票を作成する明示的なトランザクションです。 | ||
その重要性 請求書のキャンセルを追跡することで、価格設定、出荷差異、またはデータエラーに関する問題を特定できます。これは請求差異率 KPIをサポートします。 取得元 キャンセル請求伝票(VBRK-VBTYP = 'N' または 'O')の作成によって捕捉される明示的なイベントです。元の請求書はVBRK-SFAKNで参照されます。 取得 VBRKで元の請求書を参照するキャンセル伝票が作成されます。 イベントタイプ explicit | |||
販売注文変更済み | 既存の受注伝票が最初に作成された後に加えられた変更を表します。これらの変更は、数量、価格、日付などのフィールドが変更された際に、専用の変更ログテーブル(CDHDR、CDPOS)に記録されます。 | ||
その重要性 変更を追跡することで、手戻り、プロセスの不安定性、データ品質の問題を特定できます。変更の頻度が高い場合、初期の受注入力プロセスに問題があることを示唆し、遅延につながる可能性があります。 取得元 OBJECTCLAS = 'VERKBELEG'の場合、変更伝票テーブルCDHDR(ヘッダー)およびCDPOS(明細)から取得されます。タイムスタンプと変更されたフィールドを特定できます。 取得 販売伝票オブジェクトの変更伝票テーブル(CDHDR, CDPOS)からのイベント。 イベントタイプ explicit | |||
抽出ガイド
ステップ
- プログラム開発: トランザクションSE38またはSE80を使用して、新しい実行可能ABAPプログラムを作成します。このプログラムは、抽出ロジック全体を実装します。
- 選択画面の定義: プログラム内で、データをフィルタリングするための選択画面を作成します。販売伝票作成日 (VBAK-ERDAT)、販売組織 (VBAK-VKORG)、および販売伝票タイプ (VBAK-AUART) のパラメータを含めます。これにより、抽出が再利用可能で管理しやすくなります。
- データ宣言: さまざまなSAPテーブル(例: VBAK、VBAP、VBFA、CDHDR、CDPOS、VBRK、BSAD)からデータを保持するために必要な内部テーブルと構造を定義します。また、必須アトリビュートと一致するよう、イベントログの最終出力構造も定義します。
- 基本販売オーダーの選択: ユーザーの選択画面入力に基づいて、販売オーダーヘッダー (VBAK) と明細 (VBAP) を取得する最初のSELECTステートメントを記述します。これは、分析対象となるケースのコアデータセットとなります。
- 「作成」イベントの抽出: 選択したVBAKレコードをループします。各レコードについて、VBAK-ERDATとVBAK-ERZETをStartTimeとして使用し、「販売オーダー作成」アクティビティをイベントログ構造に格納します。
- 変更ログイベントの抽出: 選択した販売オーダーについて、OBJECTCLASが「VERKBELEG」であるCDHDRおよびCDPOSからレコードを選択します。結果をループして、特定のフィールド変更を特定します。例えば、VBAK-LIFSKの変更は「出荷ブロック設定済み」を示し、VBUK-CMGSTの変更は「与信チェック実行済み」を示します。その他の関連する変更は、「販売オーダー変更済み」としてログに記録できます。
- ドキュメントフローデータの抽出: 選択した販売オーダーについて、ドキュメントフローテーブル (VBFA) をクエリします。このテーブルは、販売オーダーを出荷、在庫移動、請求書などの後続ドキュメントにリンクします。さらに処理するため、すべての関連ドキュメントを選択します。
- 出荷およびフルフィルメントイベントの抽出: VBFAからの出荷伝票番号を使用して、LIKPとLIPSを「出荷伝票作成済み」イベントをクエリします。MKPFとMSEGを、出庫伝票(移動タイプ「601」)についてクエリし、「出庫済み」イベントをキャプチャします。倉庫管理が有効な場合、LTAKとLTAPをクエリし、最後の転送オーダー明細の確認時間を見つけて「ピッキング完了」を特定します。出荷ヘッダーのステータスVBUK-PODATで「配送証明確認済み」をチェックします。
- 請求および支払イベントの抽出: VBFAからの請求伝票番号を使用して、VBRKとVBRPをクエリし、「請求書作成済み」と「請求書キャンセル済み」(VBRK-FKSTO = 'X'の場合)イベントをキャプチャします。「支払い受領済み」を見つけるには、VBRKからの請求書をBKPFの会計伝票にリンクし、BSADで消込伝票と消込日を見つけます。
- ステータスベースのイベントの抽出: ステータステーブルVBUP(明細ステータス)とVBUK(ヘッダー・ステータス)からビジネスイベントを推測します。例えば、VBUP-GBSTAが「C」の場合、明細は「オーダー明細クローズ済み」と見なされます。関連するすべての明細に「拒否理由」(VBAP-ABGRU)が設定されている場合、オーダーは「オーダーキャンセル済み」となります。
- 統合とフォーマット: キャプチャされたすべてのイベントを単一の最終内部テーブルに結合します。各イベントレコードの必須アトリビュート(SalesOrder、Activity、StartTime、Userなど)がすべて正しく入力されていることを確認します。SourceSystemとLastDataUpdateのタイムスタンプを追加します。
- 出力ファイルの生成: GUI_DOWNLOAD汎用モジュールまたはcl_gui_frontend_services=>gui_downloadメソッドを使用して、最終内部テーブルをユーザーのローカルマシンにCSVファイルとしてエクスポートします。ファイルがUTF-8エンコーディングで保存されていることを確認します。
設定
- 前提条件: ABAP開発者権限(例: トランザクションSE38へのアクセス)と、VBAK、VBAP、CDHDR、CDPOS、VBFA、LIKP、LIPS、VBRK、VBRP、MKPF、MSEG、BSADを含むすべての必要な SAP テーブルに対する読み取り権限が付与されている必要があります。
- 選択パラメータ: プログラムには、フィルタリング用のパラメータを持つ選択画面を含める必要があります。主要なパラメータは次のとおりです。
- 日付範囲: 受注作成日 (VBAK-ERDAT) を指定する必須の日付範囲です。データセットを扱いやすく保つため、直近3~6ヶ月の期間から開始することを推奨します。
- 販売組織: 特定のビジネスユニットに分析の焦点を絞るため、VBAK-VKORGでフィルタリングします。
- 販売伝票タイプ: 関連する受注タイプ(例: 標準受注)のみを対象とし、見積や返品といった他のタイプを除外するため、VBAK-AUARTでフィルタリングします。
- パフォーマンスに関する考慮事項: 変更ログテーブル (CDHDR、CDPOS) および伝票フロー (VBFA) からの抽出は、データ量が多い場合に非常に遅くなる可能性があります。プログラムは、WHERE句でインデックスフィールドを使用するように最適化してください。非常に大規模な抽出の場合、トランザクションSM36を使用して、ピーク時間外にプログラムをバックグラウンドジョブとして実行するようスケジュールしてください。
- 変更ログの有効化: この方法は、SAPの変更伝票機能を利用しています。主要なデータ要素(例: LIFSK、CMGST、ABGRU)で変更ログが有効になっていることを確認してください。これは、オブジェクトVERKBELEGに対してトランザクションSCDOを介して確認できます。
a クエリ例 abap
REPORT Z_O2C_PM_EXTRACTOR.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
TABLES: vbak.
TYPES: BEGIN OF ty_event_log,
salesorder TYPE vbeln_va,
activity TYPE string,
starttime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
user TYPE ernam,
customernumber TYPE kunnr,
salesorganization TYPE vkorg,
netamount TYPE netwr,
materialnumber TYPE matnr,
deliveryblock TYPE lifsk,
rejectionreason TYPE abgru,
salesordercycletime TYPE string, " Placeholder for calculation
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gs_event_log TYPE ty_event_log.
DATA: gv_sysid TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbak-erdat OBLIGATORY,
s_vkorg FOR vbak-vkorg,
s_auart FOR vbak-auart.
PARAMETERS: p_file TYPE rlgrap-filename OBLIGATORY DEFAULT 'C:\temp\o2c_event_log.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_sysid.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
PERFORM get_base_data.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form get_base_data
*&---------------------------------------------------------------------*
FORM get_base_data.
TYPES: BEGIN OF ty_order_item,
vbeln TYPE vbeln_va,
posnr TYPE posnr_va,
erdat TYPE erdat,
erzet TYPE erzet,
ernam TYPE ernam,
kunnr TYPE kunnr,
vkorg TYPE vkorg,
netwr TYPE netwr_ak,
matnr TYPE matnr,
lifsk TYPE lifsk,
abgru TYPE abgru,
END OF ty_order_item.
DATA: lt_order_items TYPE TABLE OF ty_order_item.
SELECT h~vbeln i~posnr h~erdat h~erzet h~ernam h~kunnr h~vkorg h~netwr i~matnr h~lifsk i~abgru
INTO TABLE lt_order_items
FROM vbak AS h
INNER JOIN vbap AS i ON h~vbeln = i~vbeln
WHERE h~erdat IN s_erdat
AND h~vkorg IN s_vkorg
AND h~auart IN s_auart.
CHECK sy-subrc = 0.
DATA(lt_vbeln_range) = VALUE rsdsselopt_t(
FOR <fs_item> IN lt_order_items WHERE ( vbeln = <fs_item>-vbeln )
( sign = 'I' option = 'EQ' low = <fs_item>-vbeln ) ).
SORT lt_vbeln_range BY low.
DELETE ADJACENT DUPLICATES FROM lt_vbeln_range COMPARING low.
PERFORM extract_order_created USING lt_order_items.
PERFORM extract_changes USING lt_vbeln_range lt_order_items.
PERFORM extract_doc_flow_events USING lt_vbeln_range lt_order_items.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_order_created
*&---------------------------------------------------------------------*
FORM extract_order_created USING it_order_items TYPE ANY TABLE.
FIELD-SYMBOLS: <fs_item> TYPE any.
DATA: lt_unique_orders TYPE HASHED TABLE OF vbeln_va WITH UNIQUE KEY table_line.
lt_unique_orders = VALUE #( FOR <order> IN it_order_items ( CONV vbeln_va( <order>-vbeln ) ) ).
LOOP AT it_order_items ASSIGNING <fs_item> WHERE table_line IN lt_unique_orders.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Sales Order Created'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
gs_event_log-salesorganization = <fs_item>-vkorg.
gs_event_log-netamount = <fs_item>-netwr.
APPEND gs_event_log TO gt_event_log.
DELETE lt_unique_orders WHERE table_line = <fs_item>-vbeln.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_changes
*&---------------------------------------------------------------------*
FORM extract_changes USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_cdhdr TYPE TABLE OF cdhdr,
lt_cdpos TYPE TABLE OF cdpos.
SELECT * INTO TABLE lt_cdhdr FROM cdhdr
WHERE objectclas = 'VERKBELEG'
AND objectid IN it_vbeln_range
AND tcode = 'VA02'.
IF sy-subrc = 0.
SELECT * INTO TABLE lt_cdpos FROM cdpos
FOR ALL ENTRIES IN lt_cdhdr
WHERE objectclas = lt_cdhdr-objectclas
AND objectid = lt_cdhdr-objectid
AND changenr = lt_cdhdr-changenr.
ENDIF.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_cdhdr>-objectid ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_cdhdr>-objectid.
gs_event_log-user = <fs_cdhdr>-username.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO gs_event_log-starttime.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
" Generic Change Event
gs_event_log-activity = 'Sales Order Changed'.
APPEND gs_event_log TO gt_event_log.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>)
WHERE objectclas = <fs_cdhdr>-objectclas
AND objectid = <fs_cdhdr>-objectid
AND changenr = <fs_cdhdr>-changenr.
CASE <fs_cdpos>-fname.
WHEN 'LIFSK'. " Delivery Block
gs_event_log-activity = 'Delivery Block Set'.
gs_event_log-deliveryblock = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
WHEN 'CMGST'. " Credit Status
IF <fs_cdpos>-value_new = 'B'. " B = Credit Check OK
gs_event_log-activity = 'Credit Check Performed'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'ABGRU'. " Rejection Reason
IF <fs_cdpos>-value_new IS NOT INITIAL.
gs_event_log-activity = 'Order Cancelled'.
gs_event_log-rejectionreason = <fs_cdpos>-value_new.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form extract_doc_flow_events
*&---------------------------------------------------------------------*
FORM extract_doc_flow_events USING it_vbeln_range TYPE rsdsselopt_t it_order_items TYPE ANY TABLE.
DATA: lt_vbfa TYPE TABLE OF vbfa,
lt_vbrk TYPE TABLE OF vbrk,
lt_likp TYPE TABLE OF likp,
lt_mseg TYPE TABLE OF mseg,
lt_bsad TYPE TABLE OF bsad,
lt_vbup TYPE TABLE OF vbup.
SELECT * INTO TABLE lt_vbfa FROM vbfa
WHERE vbelv IN it_vbeln_range
AND ( vbtyp_n = 'J' " Delivery
OR vbtyp_n = 'M' " Invoice
OR vbtyp_n = 'N' " Invoice Cancellation
OR vbtyp_n = 'R' ). " Goods Movement
IF lt_vbfa IS INITIAL. RETURN. ENDIF.
SELECT vbeln, erdat, erzet, ernam, fksto, belnr FROM vbrk INTO TABLE lt_vbrk
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln
AND ( lt_vbfa-vbtyp_n = 'M' OR lt_vbfa-vbtyp_n = 'N' ).
SELECT vbeln, erdat, erzet, ernam, podat FROM likp INTO TABLE lt_likp
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbeln AND lt_vbfa-vbtyp_n = 'J'.
SELECT mblnr, mjahr, zeile, bwart, budat, cpuzt, usnam FROM mseg INTO TABLE lt_mseg
FOR ALL ENTRIES IN lt_vbfa
WHERE mblnr = lt_vbfa-vbeln AND mjahr = lt_vbfa-mjahr AND zeile = lt_vbfa-posnn AND lt_vbfa-vbtyp_n = 'R' AND bwart = '601'.
SELECT augdt, belnr, gjahr, kunnr FROM bsad INTO TABLE lt_bsad
FOR ALL ENTRIES IN lt_vbrk
WHERE belnr = lt_vbrk-belnr AND gjahr = SUBSTRING( val = lt_vbrk-erdat len = 4 ).
SELECT vbeln, posnr, gbsta FROM vbup INTO TABLE lt_vbup
FOR ALL ENTRIES IN lt_vbfa
WHERE vbeln = lt_vbfa-vbelv AND posnr = lt_vbfa-posnv.
LOOP AT lt_vbfa ASSIGNING FIELD-SYMBOL(<fs_vbfa>).
DATA(lv_order_info) = REF #( it_order_items[ vbeln = <fs_vbfa>-vbelv ] ).
IF lv_order_info IS NOT BOUND. CONTINUE. ENDIF.
CLEAR gs_event_log.
gs_event_log-salesorder = <fs_vbfa>-vbelv.
gs_event_log-customernumber = lv_order_info->kunnr.
gs_event_log-salesorganization = lv_order_info->vkorg.
gs_event_log-netamount = lv_order_info->netwr.
gs_event_log-materialnumber = lv_order_info->matnr.
CASE <fs_vbfa>-vbtyp_n.
WHEN 'J'. " Delivery
READ TABLE lt_likp ASSIGNING FIELD-SYMBOL(<fs_likp>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Delivery Created'.
CONCATENATE <fs_likp>-erdat <fs_likp>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_likp>-ernam.
APPEND gs_event_log TO gt_event_log.
" Picking Completed - simplified logic, check status
gs_event_log-activity = 'Picking Completed'. APPEND gs_event_log TO gt_event_log.
" POD Confirmed
IF <fs_likp>-podat IS NOT INITIAL.
gs_event_log-activity = 'Proof Of Delivery Confirmed'.
gs_event_log-starttime = <fs_likp>-podat.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'R'. " Goods Issue
READ TABLE lt_mseg ASSIGNING FIELD-SYMBOL(<fs_mseg>) WITH KEY mblnr = <fs_vbfa>-vbeln mjahr = <fs_vbfa>-mjahr zeile = <fs_vbfa>-posnn.
IF sy-subrc = 0.
gs_event_log-activity = 'Goods Issued'.
CONCATENATE <fs_mseg>-budat <fs_mseg>-cpuzt INTO gs_event_log-starttime.
gs_event_log-user = <fs_mseg>-usnam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
WHEN 'M'. " Invoice
READ TABLE lt_vbrk ASSIGNING FIELD-SYMBOL(<fs_vbrk>) WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0.
gs_event_log-activity = 'Invoice Created'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
" Payment Received
READ TABLE lt_bsad ASSIGNING FIELD-SYMBOL(<fs_bsad>) WITH KEY belnr = <fs_vbrk>-belnr.
IF sy-subrc = 0 AND <fs_bsad>-augdt IS NOT INITIAL.
gs_event_log-activity = 'Payment Received'.
gs_event_log-starttime = <fs_bsad>-augdt.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
WHEN 'N'. " Invoice Cancellation
READ TABLE lt_vbrk ASSIGNING <fs_vbrk> WITH KEY vbeln = <fs_vbfa>-vbeln.
IF sy-subrc = 0 AND <fs_vbrk>-fksto = 'X'.
gs_event_log-activity = 'Invoice Cancelled'.
CONCATENATE <fs_vbrk>-erdat <fs_vbrk>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_vbrk>-ernam.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDCASE.
ENDLOOP.
" Infer other events from status
LOOP AT lt_vbup ASSIGNING FIELD-SYMBOL(<fs_vbup>).
IF <fs_vbup>-gbsta = 'C'.
DATA(lv_order_info_stat) = REF #( it_order_items[ vbeln = <fs_vbup>-vbeln ] ).
IF lv_order_info_stat IS NOT BOUND. CONTINUE. ENDIF.
gs_event_log-salesorder = <fs_vbup>-vbeln.
gs_event_log-activity = 'Order Item Closed'.
" Timestamp for closed is harder, using current time as placeholder
CONCATENATE sy-datum sy-uzeit INTO gs_event_log-starttime.
gs_event_log-user = sy-uname.
gs_event_log-customernumber = lv_order_info_stat->kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
" Order Confirmed (Simplified - assumes if not blocked it's confirmed)
LOOP AT it_order_items ASSIGNING FIELD-SYMBOL(<fs_item>).
IF <fs_item>-lifsk IS INITIAL.
gs_event_log-salesorder = <fs_item>-vbeln.
gs_event_log-activity = 'Order Confirmed'.
CONCATENATE <fs_item>-erdat <fs_item>-erzet INTO gs_event_log-starttime.
gs_event_log-user = <fs_item>-ernam.
gs_event_log-customernumber = <fs_item>-kunnr.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form write_output_file
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lt_final_output TYPE TABLE OF ty_event_log.
" Add common fields
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
<fs_event>-sourcesystem = gv_sysid.
<fs_event>-lastdataupdate = gv_last_update.
ENDLOOP.
SORT gt_event_log BY salesorder starttime.
DELETE ADJACENT DUPLICATES FROM gt_event_log COMPARING ALL FIELDS.
lt_final_output = gt_event_log.
DATA: lt_fieldnames TYPE TABLE OF string.
APPEND 'SalesOrder' TO lt_fieldnames.
APPEND 'Activity' TO lt_fieldnames.
APPEND 'StartTime' TO lt_fieldnames.
APPEND 'SourceSystem' TO lt_fieldnames.
APPEND 'LastDataUpdate' TO lt_fieldnames.
APPEND 'User' TO lt_fieldnames.
APPEND 'CustomerNumber' TO lt_fieldnames.
APPEND 'SalesOrganization' TO lt_fieldnames.
APPEND 'NetAmount' TO lt_fieldnames.
APPEND 'MaterialNumber' TO lt_fieldnames.
APPEND 'DeliveryBlock' TO lt_fieldnames.
APPEND 'RejectionReason' TO lt_fieldnames.
APPEND 'SalesOrderCycleTime' TO lt_fieldnames.
DATA(lv_header) = REDUCE string(
INIT s = ''
FOR field IN lt_fieldnames
NEXT s = s && COND #( WHEN s = '' THEN field ELSE |,{ field }| ) ).
DATA: lt_file_content TYPE TABLE OF string.
APPEND lv_header TO lt_file_content.
LOOP AT lt_final_output INTO DATA(ls_output).
DATA(lv_line) = |"{ ls_output-salesorder }","{ ls_output-activity }","{ ls_output-starttime }","{ ls_output-sourcesystem }","{ ls_output-lastdataupdate }","{ ls_output-user }","{ ls_output-customernumber }","{ ls_output-salesorganization }",{ ls_output-netamount },"{ ls_output-materialnumber }","{ ls_output-deliveryblock }","{ ls_output-rejectionreason }","{ ls_output-salesordercycletime }"|.
APPEND lv_line TO lt_file_content.
ENDLOOP.
cl_gui_frontend_services=>gui_download(
EXPORTING
filename = p_file
filetype = 'ASC'
CHANGING
data_tab = lt_file_content ).
ENDFORM.ステップ
- 前提条件: 基盤となるSAP ECCデータベースへの直接的な読み取り専用アクセスがあることを確認してください。クエリの接続と実行には、DBeaver、SQL Server Management Studio、Oracle SQL Developerなどのデータベースクライアントツールが必要です。
- SQLスクリプトの取得: このドキュメントの「query」セクションに記載されている完全なSQLクエリをコピーしてください。
- データベースへの接続: データベースクライアントを開き、SAP ECCデータベースインスタンスに接続します。サーバーアドレス、ポート、データベース名、および適切なログイン認証情報が必要になります。
- クエリの構成: 新しいクエリエディタウィンドウにSQLスクリプトを貼り付けてください。SalesOrdersというメインの共通テーブル式(CTE)内の構成セクションを見つけてください。開始日 ('{StartDate}')、終了日 ('{EndDate}')、販売組織 ('{SalesOrgs}')、およびドキュメントタイプ ('{DocTypes}') のプレースホルダー値を、分析の実際の値に置き換えてください。
- クエリの実行: 構成されたSQLスクリプトを実行してください。日付範囲とSAPデータベースのサイズによっては、このクエリの完了までに数分かかることがあります。
- 結果の確認: クエリの完了後、結果セットが表示されます。データに期待される列(SalesOrder、Activity、StartTimeなど)が含まれていること、および様々なアクティビティの行が返されていることを確認してください。
- データのエクスポート: データベースクライアントのエクスポート機能を使用して、結果セットをCSVファイルとして保存してください。例えばSAP_O2C_Event_Log.csvのように、内容がわかるファイル名を付けて保存してください。
- ProcessMind用のフォーマット: スプレッドシートエディタでCSVファイルを開いてください。列ヘッダーが必須アトリビュート(SalesOrder、Activity、StartTimeなど)と正確に一致していることを確認してください。StartTimeおよびLastDataUpdateの日付と時刻のフォーマットが、YYYY-MM-DD HH:MI:SSのようなProcessMindでサポートされる一貫した形式であることを確認してください。
- ProcessMindへのアップロード: 最終的に整形されたCSVファイルをProcessMindプロジェクトにアップロードして分析します。
設定
- 日付範囲: クエリは、受注の作成日 (VBAK.ERDAT) に基づいて受注をフィルタリングするために、プレースホルダー ('{StartDate}' および '{EndDate}') を使用します。一般的な分析期間としては、データベースに過度な負荷をかけることなく代表的なサンプルを確保するため、3~6ヶ月分のデータが目安となります。
- 販売組織フィルター: 特定の販売組織(例: '1000', '2000')に抽出を限定するには、'{SalesOrgs}' プレースホルダーを使用します。これは分析の焦点を絞り、クエリのパフォーマンスを向上させるために不可欠です。
- 伝票タイプフィルター: 特定の受注タイプ(例: 標準受注を示す'OR')を選択するには、'{DocTypes}' プレースホルダーを使用します。これにより、無償出荷や返品といった、主要なプロセスフローと無関係な伝票を除外できます。
- ソースシステム識別子: ハードコードされたプレースホルダー'{SourceSystemName}'は、すべてのレコードにその発生元システムをタグ付けするために使用されます。これは、ご使用の SAP ECC インスタンスを識別できる、意味のある名称(例: SAP_ECC_PRD)に設定してください。
- データベース互換性: 日付と時刻のフィールドを結合するために使用される関数 [Your DB-specific timestamp function] はプレースホルダーです。ご利用のデータベースに応じた適切な関数(例: SAP HANA の場合は TO_TIMESTAMP(CONCAT(CDHDR.UDATE, CDHDR.UZEIT), 'YYYYMMDDHH24MISS')、SQL Server の場合は CAST(CDHDR.UDATE AS DATETIME) + CAST(CDHDR.UZEIT AS DATETIME)) に置き換えてください。
- 前提条件: この方法を使用するには、データベースへの直接的な読み取り専用アクセス権が必要です。データベースユーザーは、クエリで参照されるすべてのテーブル(VBAK、VBAP、VBFA、CDHDR、CDPOS、LIKP、VBRK、BSADを含む)へのアクセス権限を付与されている必要があります。
a クエリ例 sql
WITH SalesOrders AS (
SELECT VBELN
FROM VBAK
WHERE ERDAT BETWEEN '{StartDate}' AND '{EndDate}' -- Filter by creation date
AND VKORG IN ('{SalesOrgs}') -- Filter by Sales Organization(s)
AND AUART IN ('{DocTypes}') -- Filter by Sales Document Type(s)
)
-- 1. Sales Order Created
SELECT
vbak.VBELN AS "SalesOrder",
'Sales Order Created' AS "Activity",
[Your DB-specific timestamp function](vbak.ERDAT, vbak.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbak.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBAK vbak
JOIN SalesOrders so ON vbak.VBELN = so.VBELN
UNION ALL
-- 2. Sales Order Changed
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Sales Order Changed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG' AND cdhdr.TCODE IN ('VA02')
UNION ALL
-- 3. Credit Check Performed (Release)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Credit Check Performed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'CMGST'
AND cdpos.VALUE_NEW = 'B' -- Credit status 'Released'
UNION ALL
-- 4. Order Confirmed (Overall status not blocked)
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Order Confirmed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'GBSTK'
AND cdpos.VALUE_OLD <> 'A' AND cdpos.VALUE_NEW = 'A' -- Status changes to 'Not yet processed'
UNION ALL
-- 5. Delivery Block Set
SELECT
cdhdr.OBJECTID AS "SalesOrder",
'Delivery Block Set' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
cdpos.VALUE_NEW AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAK'
AND cdpos.FNAME = 'LIFSK'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> ''
UNION ALL
-- 6. Delivery Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Delivery Created' AS "Activity",
[Your DB-specific timestamp function](likp.ERDAT, likp.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
vbak.LIFSK AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
UNION ALL
-- 7. Picking Completed
SELECT
vbfa.VBELV AS "SalesOrder",
'Picking Completed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN CDHDR cdhdr ON vbfa.VBELN = cdhdr.OBJECTID
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J'
AND cdhdr.OBJECTCLASS = 'LIEFERUNG'
AND cdpos.TABNAME = 'VBUK'
AND cdpos.FNAME = 'PKSTK'
AND cdpos.VALUE_NEW = 'C'
UNION ALL
-- 8. Goods Issued
SELECT
vbfa_gi.VBELV AS "SalesOrder",
'Goods Issued' AS "Activity",
[Your DB-specific timestamp function](mkpf.BUDAT, mkpf.CPUTM) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
mkpf.USNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa_gi
JOIN SalesOrders so ON vbfa_gi.VBELV = so.VBELN
JOIN MKPF mkpf ON vbfa_gi.VBELN = mkpf.XBLNR -- XBLNR is Reference Document Number
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa_gi.VBTYP_V = 'J' AND vbfa_gi.VBTYP_N = 'R'
UNION ALL
-- 9. Proof Of Delivery Confirmed
SELECT
vbfa.VBELV AS "SalesOrder",
'Proof Of Delivery Confirmed' AS "Activity",
[Your DB-specific timestamp function](likp.PODAT, '000000') AS "StartTime", -- PODAT is only a date
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
likp.AENAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN LIKP likp ON vbfa.VBELN = likp.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'J' AND likp.PODAT IS NOT NULL AND likp.PODAT <> '00000000'
UNION ALL
-- 10. Invoice Created
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Created' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
UNION ALL
-- 11. Invoice Cancelled
SELECT
vbfa.VBELV AS "SalesOrder",
'Invoice Cancelled' AS "Activity",
[Your DB-specific timestamp function](vbrk.ERDAT, vbrk.ERZET) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
vbrk.ERNAM AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'M' AND vbfa.VBTYP_N = 'N'
UNION ALL
-- 12. Payment Received
SELECT
vbfa.VBELV AS "SalesOrder",
'Payment Received' AS "Activity",
[Your DB-specific timestamp function](bsad.AUGDT, '000000') AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
NULL AS "User", -- Clearing user not readily available here
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
NULL AS "MaterialNumber",
NULL AS "DeliveryBlock",
NULL AS "RejectionReason"
FROM VBFA vbfa
JOIN SalesOrders so ON vbfa.VBELV = so.VBELN
JOIN VBRK vbrk ON vbfa.VBELN = vbrk.VBELN
JOIN BSAD bsad ON vbrk.VBELN = bsad.VBLNR
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE vbfa.VBTYP_V = 'C' AND vbfa.VBTYP_N = 'M'
AND bsad.AUGDT IS NOT NULL AND bsad.AUGDT <> '00000000'
UNION ALL
-- 13. Order Item Closed
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Item Closed' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
vbap.ABGRU AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBUP'
AND cdpos.FNAME = 'GBSTA'
AND cdpos.VALUE_NEW = 'C' -- Item is completely processed
UNION ALL
-- 14. Order Cancelled
SELECT DISTINCT
cdhdr.OBJECTID AS "SalesOrder",
'Order Cancelled' AS "Activity",
[Your DB-specific timestamp function](cdhdr.UDATE, cdhdr.UZEIT) AS "StartTime",
'{SourceSystemName}' AS "SourceSystem",
CURRENT_TIMESTAMP AS "LastDataUpdate",
cdhdr.USERNAME AS "User",
vbak.KUNNR AS "CustomerNumber",
vbak.VKORG AS "SalesOrganization",
vbak.NETWR AS "NetAmount",
vbap.MATNR AS "MaterialNumber",
NULL AS "DeliveryBlock",
cdpos.VALUE_NEW AS "RejectionReason"
FROM CDHDR cdhdr
JOIN CDPOS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
JOIN VBAP vbap ON cdhdr.OBJECTID = vbap.VBELN AND SUBSTRING(cdpos.TABKEY, 4, 6) = vbap.POSNR
JOIN SalesOrders so ON cdhdr.OBJECTID = so.VBELN
JOIN VBAK vbak ON so.VBELN = vbak.VBELN
WHERE cdhdr.OBJECTCLASS = 'VERKBELEG'
AND cdpos.TABNAME = 'VBAP'
AND cdpos.FNAME = 'ABGRU'
AND cdpos.VALUE_NEW IS NOT NULL AND cdpos.VALUE_NEW <> '';