MIGOトランザクションの概要
MIGOは、SAP ERPやSAP S/4HANAなどの環境で、在庫の入出庫や移動、棚卸差異の処理などを総合的に行うトランザクションです。従来はMB1A・MB1B・MB1Cなどの複数のトランザクションを使用していましたが、MIGOで一元管理が可能になりました。部品の受入・払い出し、返品処理、在庫移動といった多様な処理を単一の画面で統合し、ユーザビリティを高める役割を担っています。
- 画面構成
- 上部にあるドキュメントタイプ、入出庫種別、参照ドキュメント(購買発注・生産オーダーなど)の指定
- 中央部に表示される明細情報(マテリアル番号、数量、プラント、保管場所など)
- 下部もしくはサイドに表示される詳細タブ(転送先情報や在庫区分、バッチ番号など追加情報の入力欄)
このMIGOは通常、ユーザーが画面から操作することを想定しています。しかし、大量データを扱う際には操作効率に課題が生じるため、バッチインプットを活用した自動化のニーズが高まります。
バッチインプットの概要
SAPにおけるバッチインプットは、BDC(Batch Data Communication)と呼ばれる仕組みの一部であり、画面遷移をプログラム的に模擬してデータ登録を行う方法です。コーディングやツール(SHDBやLSMWなど)を活用して、画面入力を自動化し、指定のトランザクションに必要なデータを一括投入します。
- メリット
- 大量データの一括処理が可能
- 画面入力で必要なチェックロジックをそのまま利用できる
- 既存のトランザクションを再利用するため、二重開発の手間を軽減できる
- デメリット
- 画面ごとの処理フローが変更されると、バッチインプットロジックの修正が必要
- BAPIなどの直接登録手段に比べると、速度面・柔軟性で劣る場合がある
- 例外処理のハンドリングが複雑になる可能性がある
SAP公式ドキュメント(SAP Help Portal)によれば、バッチインプットの設計時には画面フィールドの構成や遷移を正確に把握し、エラー検出やリトライの仕組みを整備しておくことが重要だとされています。
SAP MIGO バッチインプットのシナリオと注意点
バッチインプットを選択するシチュエーション
日々の業務でMIGOを使い、大量の受入処理や移動在庫の更新をしなければならない場合、単純な画面操作だけでは処理に時間がかかり、生産性が低下します。たとえば、購買オーダーが1日に数百件発行され、その受入をMIGOで登録するようなケースでは、作業者が都度手入力するとミスの発生リスクが増大するほか、入力時間が膨れ上がります。
以下のような条件に該当するとき、バッチインプットによる自動化が有効です。
- 毎日膨大な伝票を登録する必要がある
- 伝票1件あたりの明細が多数(例:数十行以上)
- 入力値の大半がマスタから自動補完できる
- 画面登録中のバリデーションを活かしたい
SAP標準BAPIとの比較
在庫移動の登録という観点では、バッチインプット以外にもBAPI_GOODSMVT_CREATEなどのBAPIを利用する方法があります。BAPIを活用すれば、画面を経由せずに直接データを登録できるため、高速かつ画面変更の影響を受けにくいメリットがあります。しかし、BAPIの利用には追加のカスタマイズやエラー処理の設計が必要で、画面上での入力チェックと完全に一致させるには工夫を要することがあります。
バッチインプットの場合、既存のMIGOトランザクションが行う画面レベルのチェックロジックや関連テーブルへの書き込みフローをそのまま利用可能です。例えば、バッチ番号の存在チェック、プラント・保管場所の照合、在庫区分の整合性確認などがシームレスに行われます。したがって、MIGO画面に依存した形で開発が許容されるなら、バッチインプットは依然として有効な手段です。
注意すべきポイント
- 画面遷移の変更
システムアップグレードやSAP Noteの適用でMIGOの画面レイアウトやフィールド名が変更された場合、バッチインプットロジックが通らなくなる可能性があるため、定期的なメンテナンスが必要です。 - 処理速度
画面シミュレーションのためBAPI方式より遅くなる傾向があります。大量データを短時間で処理する場合は、可能な限り夜間バッチにするか、または複数ワークプロセスを活用するなどの対策を検討します。 - エラー時のリトライ
バッチインプットセッションは画面投入と同様のエラーを発生させます。たとえば、マテリアル番号が存在しない、在庫区分に矛盾がある、すでに同じ伝票が登録済みなどのエラーが起こり得ます。自動リトライの仕組みやエラー検出後の処理フローを設計段階で考慮しておく必要があります。 - 数量や金額の単位
計量単位や通貨単位などが正しく設定されていないと、伝票作成時にエラーや不正な値が入力される恐れがあります。
バッチインプットの具体的な作成手順
ステップ1:対象画面の分析
最初のステップは、MIGOの画面遷移を正確に把握することです。MIGOでは、画面上部の入出庫種別設定、明細入力、チェック、伝票参照、転送先などのステップが複数存在します。これらをSHDBトランザクションやデバッグを通じて確認し、どういった画面要素(プログラムID、ダイナプロ番号、フィールド名)が要求されるのか洗い出します。
画面情報サンプル
画面番号 | フィールド名 (プログラム上) | 説明 |
---|---|---|
1000 | SAPLMIGO-S_GM-Code | 入出庫種別 |
1000 | SAPLMIGO-HeaderRefDoc | 参照伝票タイプ (PO等) |
2000 | MIGO_ITEM-MATNR | マテリアル番号 |
2000 | MIGO_ITEM-WERKS | プラント |
2000 | MIGO_ITEM-LGORT | 保管場所 |
3000 | MIGO_ITEM-BATCH | バッチ番号 |
3000 | MIGO_ITEM-ERFMG | 数量 |
以上はあくまで一例です。実際の画面番号やフィールド名はSAPのバージョンやカスタマイズ状況により異なりますので、SHDBの録画結果を必ず参照してください。
ステップ2:SHDBでの録画
SHDBトランザクションを使うと、バッチインプットシナリオの録画ができます。MIGOに限らず、SAP標準トランザクションをバッチインプットで処理する際によく利用される方法です。SHDBは、実際の画面操作を記録し、その操作に対応するBDC用のプログラムステップ(ダイナプロ番号、フィールド名、入力値)を出力してくれます。
- 録画手順
- SHDBを起動し、新規録画を開始
- トランザクションコードに「MIGO」を入力し、実行
- MIGO画面で必要な操作(入出庫種別選択、明細入力など)を行う
- 伝票を保存して、録画終了
- 生成された録画結果を確認し、BDCコードやフィールド情報を保管
ステップ3:BDCプログラムの作成または編集
SHDBの録画結果を利用して、BDCプログラムやLSMWオブジェクトを作成します。以下はBDCプログラムをABAPで作成する際のイメージです(簡略化しています)。
abapコピーする編集するDATA: lt_bdctab TYPE TABLE OF bdctab,
ls_bdctab TYPE bdctab.
* 画面 1000 の設定例
ls_bdctab-program = 'SAPLMIGO'.
ls_bdctab-dynpro = '1000'.
ls_bdctab-dynbegin = 'X'.
APPEND ls_bdctab TO lt_bdctab.
ls_bdctab-fnam = 'SAPLMIGO-S_GM-Code'.
ls_bdctab-fval = '01'." 例: Goods Receipt
APPEND ls_bdctab TO lt_bdctab.
* 画面 2000 の設定例
ls_bdctab-program = 'SAPLMIGO'.
ls_bdctab-dynpro = '2000'.
ls_bdctab-dynbegin = 'X'.
APPEND ls_bdctab TO lt_bdctab.
ls_bdctab-fnam = 'MIGO_ITEM-MATNR'.
ls_bdctab-fval = '000000000100123456'.
APPEND ls_bdctab TO lt_bdctab.
* (中略)
CALL TRANSACTION 'MIGO' USING lt_bdctab
MODE 'N'
UPDATE 'S'.
実際には、複数の画面や明細行入力のロジックを組み込み、エラー処理を加味する必要があります。ABAPのLOOP構文を活用して入力データをループしながらBDCデータを作り込み、都度CALL TRANSACTIONまたはBDC_OPEN_GROUP/BDC_INSERT/BDC_CLOSE_GROUPを組み合わせて処理するケースが多いです。
ステップ4:LSMWでのアプローチ
プログラミングが難しい場合や、より標準的なツールを活用したい場合はLSMW (Legacy System Migration Workbench)を使う方法があります。LSMWではGUIベースでステップを設定し、ソース構造(ExcelやCSVファイルなど)とターゲット構造(BDCのフィールドやBAPIのフィールドなど)をマッピングできます。プロジェクトごとのオブジェクト管理も容易で、エラーの解析がしやすいという特長があります。
- LSMWでの主な手順
- プロジェクト、サブプロジェクト、オブジェクトを作成
- ソース構造の定義(外部ファイルのレイアウト設定)
- ターゲット構造の定義(MIGOのBDC対応フィールド)
- マッピングと変換ルールの設定(文字列整形、条件分岐など)
- データ読み込み、変換、インポートテスト
- 実行本番
「LSMWは、標準機能を使って実装しやすい点が非常に強力だ」という趣旨の言及が、SAP Community Blogsの複数記事や、SAP Mentorとして有名な数名のエンジニアからもよくされています。公式ドキュメントにもサンプルプロジェクトの紹介があり、参考になるでしょう。
ステップ5:テストデータでの試行
MIGOバッチインプットは、実際に本番環境のデータを投入する前にテストを重ねることが重要です。テストの際は以下の点を確認します。
- 明細行数が多い場合でも正しく入力されるか
- エラー発生時にログが出力されるか
- バッチインプットセッションでのステップモード(画面を一つずつ確認するモード)でも期待通りの画面遷移をするか
- 数量や単位の扱いに間違いはないか
特に数量単位の変換や在庫区分(Unrestricted、Quality Inspection、Blockedなど)の指定ミスが多いため、注意深くチェックします。
ステップ6:パフォーマンスチューニング
大量データを処理する場合、バッチインプットの速度が問題になることがあります。そこで、可能な対策としては次のようなものがあります。
- 高速入力モード(背景実行)
バッチインプットセッションの実行モードを「A(Display All Screens)」ではなく「N(Background)」に設定し、画面表示を抑制することで処理を高速化します。 - コミット単位の調整
大量データの場合、セッション内の明細をある程度の単位(例:100件ごと)でコミットし、ロールバックセグメントの肥大化を避けます。 - 並行実行
複数のバッチインプットセッションを並行して処理できるようにし、複数ワークプロセスを活用します。SAPシステムの負荷状況と相談しながら、適切なタイミングを設定します。
SAP Noteにも「大規模バッチインプットでパフォーマンス問題が発生する場合、内部テーブルのサイズやコミット頻度を調整すること」という旨の記載があり、システムリソースを鑑みて最適化する必要があります。
ステップ7:例外エラー処理の設計
バッチインプットでも、画面経由の手入力と同じエラーが起こり得ます。マテリアル在庫がロックされている、既に移動済みなどの理由でエラーになる可能性があります。こうしたエラーをどのように扱うかは運用設計で明確にしておくことが重要です。
- エラーセッションの残し方
バッチインプット実行後、エラーセッションを残す設定にしておくと、ステップモードで画面を確認しながら再実行できます。 - ログファイルの活用
伝票番号ごとの成功・失敗をファイル出力しておき、リカバリー処理を容易にする方法があります。 - 再実行とロック管理
エラー後の再実行では、在庫ロックやドキュメントロックが解除されていない可能性を考慮し、一定時間を置く、または別のタイミングで処理する仕組みを整える必要があります。
ステップ8:安定稼働までの検証
バッチインプット開発完了後は、すぐに本番移行せず、品質テスト・結合テスト・ユーザ受け入れテストを経て運用に乗せるのが一般的です。要件によっては、夜間バッチでの定期実行か、ユーザーの手動トリガーかを検討し、ジョブ管理やアラート通知の設定を行います。
- 定期ジョブの登録
SM36などでジョブを作成し、必要な変数(インプットファイルのパスや日付など)を動的に設定する。 - ジョブ監視
SM37などでジョブのステータスを確認し、失敗時にすぐ対応できるようアラートメールを飛ばす。 - 継続的なメンテナンス
画面変更やバージョンアップ時にロジックが壊れないかを定期的にチェックする。
ステップ9:運用後の改善サイクル
一度導入したバッチインプットが、ビジネス要件の変更により運用に合わなくなる場合があります。例として、伝票の承認プロセスが挟まる、追加のフィールド入力が必要になるなどです。その際は、シャドー環境(テスト環境)で修正・検証を行ったうえで本番適用する手順を踏むことが望ましいです。
- バッチインプットの柔軟性
画面依存の自動化であるため、画面にフィールドが増えればプログラム修正が必須になる。 - 標準拡張への移行検討
新しい要件が発生するたびにバッチインプットを修正するより、BAPIやRFCなどのより柔軟な仕組みに移行する選択肢も検討する。 - ライフサイクル管理
バッチインプットで登録したドキュメントの後処理や保守性を考慮し、ドキュメントナンバーの取り扱い方、バックアップ方針などを定める。
BAPIの具体的な例
SAPのMIGO(Goods Movement)で使用できるBAPIとして、主に以下のものがあります:
1. BAPI_GOODSMVT_CREATE
- 目的: 物品移動(入庫、出庫、振替、取り消しなど)を登録
- 主な使用シナリオ:
- 仕入先からの入庫(GR – 101)
- 生産オーダーへの出庫(GI – 261)
- 保管場所間の振替(311)
- 入庫取り消し(102)
- 物理在庫差異の登録(701, 702)
使用例(入庫処理のサンプルコード):
DATA: lv_matdoc TYPE bapi2017_gm_head_ret-materialdocument,
lv_matyear TYPE bapi2017_gm_head_ret-matdocumentyear,
ls_goodsmvt_header TYPE bapi2017_gm_head_01,
ls_goodsmvt_code TYPE bapi2017_gm_code,
lt_goodsmvt_item TYPE TABLE OF bapi2017_gm_item_create,
ls_goodsmvt_item TYPE bapi2017_gm_item_create,
lt_return TYPE TABLE OF bapiret2,
ls_return TYPE bapiret2.
* 転記日や伝票日を設定
ls_goodsmvt_header-pstng_date = '20250126'.
ls_goodsmvt_header-doc_date = '20250126'.
* 伝票タイプの設定(例:入庫)
ls_goodsmvt_code-gm_code = '01'. " 01 = 入庫(GR)
* 明細の設定
CLEAR ls_goodsmvt_item.
ls_goodsmvt_item-move_type = '101'. " 入庫タイプ
ls_goodsmvt_item-material = 'MAT00123456'. " マテリアル番号
ls_goodsmvt_item-plant = '1000'. " プラント
ls_goodsmvt_item-stge_loc = '0001'. " 保管場所
ls_goodsmvt_item-entry_qnt = '50'. " 数量
ls_goodsmvt_item-entry_uom = 'PC'. " 単位
APPEND ls_goodsmvt_item TO lt_goodsmvt_item.
* BAPIを実行
CALL FUNCTION 'BAPI_GOODSMVT_CREATE'
EXPORTING
goodsmvt_header = ls_goodsmvt_header
goodsmvt_code = ls_goodsmvt_code
IMPORTING
materialdocument = lv_matdoc
matdocumentyear = lv_matyear
TABLES
goodsmvt_item = lt_goodsmvt_item
return = lt_return.
* 結果の確認
LOOP AT lt_return INTO ls_return.
WRITE: / ls_return-message.
ENDLOOP.
IF sy-subrc = 0.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = 'X'.
WRITE: / '入庫伝票:', lv_matdoc, ' 年:', lv_matyear.
ELSE.
CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
WRITE: / 'エラー発生、ロールバックしました。'.
ENDIF.
2. BAPI_GOODSMVT_GETDETAIL
- 目的: 既存の物品移動データを取得(MIGO で作成済みの入庫・出庫の詳細情報を取得)
- 使用例:
- 伝票番号を指定して移動明細を取得
使用例:
DATA: lt_goodsmvt_item TYPE TABLE OF bapi2017_gm_item_detail,
ls_goodsmvt_head TYPE bapi2017_gm_head_ret,
lt_return TYPE TABLE OF bapiret2.
CALL FUNCTION 'BAPI_GOODSMVT_GETDETAIL'
EXPORTING
materialdocument = '5000001234' " 伝票番号
matdocumentyear = '2024' " 伝票年度
IMPORTING
goodsmvt_header = ls_goodsmvt_head
TABLES
goodsmvt_item = lt_goodsmvt_item
return = lt_return.
LOOP AT lt_goodsmvt_item INTO DATA(ls_item).
WRITE: / 'マテリアル:', ls_item-material, ' 数量:', ls_item-entry_qnt.
ENDLOOP.
3. BAPI_TRANSACTION_COMMIT / BAPI_TRANSACTION_ROLLBACK
- 目的: BAPIの実行結果を確定またはキャンセル
- 説明:
BAPI_GOODSMVT_CREATE
実行後に、BAPI_TRANSACTION_COMMIT
を呼び出すことで確定- エラーが発生した場合は
BAPI_TRANSACTION_ROLLBACK
を実行して処理を取り消す
例:
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' EXPORTING wait = 'X'.
または
CALL FUNCTION 'BAPI_TRANSACTION_ROLLBACK'.
4. BAPI_MATERIAL_AVAILABILITY
- 目的: 在庫の可用性をチェック(MIGOの事前確認として)
- 使用例:
- 指定したマテリアルが、プラント・保管場所に在庫があるか確認
使用例:
DATA: lt_return TYPE TABLE OF bapiret2,
lv_availability TYPE bapiwhse_stock.
CALL FUNCTION 'BAPI_MATERIAL_AVAILABILITY'
EXPORTING
material = 'MAT00123456'
plant = '1000'
stge_loc = '0001'
unit = 'PC'
IMPORTING
whse_stock = lv_availability
TABLES
return = lt_return.
WRITE: / '利用可能在庫:', lv_availability-unrestricted_use.
5. BAPI_INCOMINGINVOICE_CREATE
- 目的: MIGOで入庫した後、請求書(MIRO相当)を登録
- 使用例:
- MIGO で入庫した GR をもとに請求書を作成する
使用例:
DATA: lt_invoice_items TYPE TABLE OF bapi_incinv_create_item,
ls_invoice_items TYPE bapi_incinv_create_item.
ls_invoice_items-doc_type = 'RE'. " 仕入先請求書
ls_invoice_items-ref_doc_no = '5000001234'. " 入庫伝票
ls_invoice_items-amount = '1000'. " 金額
APPEND ls_invoice_items TO lt_invoice_items.
CALL FUNCTION 'BAPI_INCOMINGINVOICE_CREATE'
EXPORTING
invoiceheaderdata = VALUE bapi_incinv_create_header( inv_doc_date = '20250126'
companycode = '1000' )
TABLES
invoiceitemdata = lt_invoice_items.
6. BAPI_PO_CREATE1
- 目的: 購買発注(PO)作成
- 使用例:
- MIGO前に購買発注(PO)を登録し、後続で入庫処理を行う
使用例:
DATA: lt_po_items TYPE TABLE OF bapimepoitem,
ls_po_items TYPE bapimepoitem.
ls_po_items-material = 'MAT00123456'.
ls_po_items-plant = '1000'.
ls_po_items-quantity = '100'.
ls_po_items-po_unit = 'PC'.
APPEND ls_po_items TO lt_po_items.
CALL FUNCTION 'BAPI_PO_CREATE1'
TABLES
poitem = lt_po_items.
まとめ
BAPI名 | 説明 | 用途例 |
---|---|---|
BAPI_GOODSMVT_CREATE | 物品移動登録 | MIGOの入庫・出庫処理 |
BAPI_GOODSMVT_GETDETAIL | 物品移動の詳細取得 | 伝票内容の確認 |
BAPI_MATERIAL_AVAILABILITY | 在庫可用性チェック | 在庫の確認 |
BAPI_TRANSACTION_COMMIT | トランザクションの確定 | MIGO後の確定処理 |
BAPI_INCOMINGINVOICE_CREATE | 請求書の作成 | MIROプロセス |
MIGOの処理をBAPIで自動化することで、より効率的な在庫管理や入庫プロセスの最適化が可能になります。