よくある質問

品目タイプは画面構成・番号範囲・勘定カテゴリ参照など品目マスタの振る舞いを決める基本分類です。マテリアルグループは購買発注の既定値や購買レポートの集計に使う、より広い分類です。
出典：品目マスタの設定：品目タイプ（OMS2）・マテリアルグループ（OMSF）・番号範囲（MMNR）

既存の品目コードをそのまま使いたい移行案件は外部採番、新規導入でコード体系を作り直せる場合は内部採番が向きます。外部採番は英数字が使える一方、表記ゆれ対策と番号範囲チェックの設計が必要です。
出典：品目マスタの設定：品目タイプ（OMS2）・マテリアルグループ（OMSF）・番号範囲（MMNR）

採番済みの番号と重複しない区間を追加・拡張することはできます。ただし既存の区間を狭めるとエラーになるため、区間は最初から広めに確保しておくのが安全です。採番済みの番号そのものは変更できません。
出典：品目マスタの設定：品目タイプ（OMS2）・マテリアルグループ（OMSF）・番号範囲（MMNR）

まず標準品目タイプで足りるかを検討してください。品目タイプを増やすと番号範囲・画面構成・勘定カテゴリ参照・移送の管理対象が増えます。標準で表現できない業務要件がある場合に限り、既存タイプをコピーして追加するのが基本です。
出典：品目マスタの設定：品目タイプ（OMS2）・マテリアルグループ（OMSF）・番号範囲（MMNR）

OX18はプラントを会社コードへ割り当てます。OX17は購買組織をプラントへ割り当てます。階層のつなぎ方が異なります。
出典：S/4HANAのMM設定②：MRPコントローラ（OMD0）と組織割当（OX18・OX01・OX17）

品目の所要量計画（MRP）を担当する担当者（またはグループ）で、品目マスタに割り当てて計画の責任範囲を管理します。
出典：S/4HANAのMM設定②：MRPコントローラ（OMD0）と組織割当（OX18・OX01・OX17）

技術的には可能ですが、既存の購買文書やマスタデータへの影響調査が必要です。導入時に確定させるのが原則です。
出典：S/4HANAのMM設定②：MRPコントローラ（OMD0）と組織割当（OX18・OX01・OX17）

購買レポートの集計や見積依頼・発注書の分類に使います。品目タイプより広い分類です。
出典：S/4HANAのMM設定③：マテリアルグループ（OMSF）・プランニングマージン（OMDC）・工場パラメータ

発注から入荷までのリードタイムに加える余裕日数です。MRPはこの余裕を見込んで発注日を計算します。
出典：S/4HANAのMM設定③：マテリアルグループ（OMSF）・プランニングマージン（OMDC）・工場パラメータ

発注書・入荷・請求書照合などで使用する税コードのデフォルト値を設定します。
出典：S/4HANAのMM設定③：マテリアルグループ（OMSF）・プランニングマージン（OMDC）・工場パラメータ

会社コードでMMの転記を開始できる期間です。導入時は過去数期間を解放しておくと、移行データの遡及転記ができます。
出典：S/4HANAのMM設定④：MM初期期間（OMSY）・MRP工場パラメータ（OMI8）・MRPの活性化（OMDU）

MD03（MRP実行）が実行できません。プラント単位で活性化（OMDU）が必要です。
出典：S/4HANAのMM設定④：MM初期期間（OMSY）・MRP工場パラメータ（OMI8）・MRPの活性化（OMDU）

MRP実行で生成される計画オーダーに番号を振るためです。未設定だと発番エラーになります。
出典：S/4HANAのMM設定④：MM初期期間（OMSY）・MRP工場パラメータ（OMI8）・MRPの活性化（OMDU）

品目タイプは品目の属性（番号範囲・画面構成）を決め、評価クラスは品目がどの勘定科目に転記されるかを決めます。品目マスタで評価クラスを指定します。
出典：S/4HANAのMM設定⑤：品目タイプ（OMS2）・評価コントロール（OMWM）・評価クラス（OMSK）

在庫評価を行う単位（通常はプラント単位）です。評価範囲ごとに評価方法や勘定を設定できます。
出典：S/4HANAのMM設定⑤：品目タイプ（OMS2）・評価コントロール（OMWM）・評価クラス（OMSK）

在庫が存在する状態での評価クラス変更は影響が大きいため、導入時に確定させることが重要です。
出典：S/4HANAのMM設定⑤：品目タイプ（OMS2）・評価コントロール（OMWM）・評価クラス（OMSK）

はい、S/4HANA でも SAP Query は標準アドオンとして引き続き利用可能です。ただし S/4HANA では CDS View + Fiori Elements でのレポート実装が推奨されており、SAP Query は短命な現場レポートや PoC 用途に留めるのが現実解です。3 か月以内に廃止が決まるレポートなら SAP Query、半期を超える保守が要るなら CDS View に投資するのが経験則です。
出典：SAP Query（ABAP Query）入門：SQ01・SQ02・SQ03で作る簡易レポートの作り方

QuickViewer（SQVI）はテーブルを直接指定して即席レポートを作る簡易機能で、1 回限りの確認作業に向きます。ただし移送できない、権限管理が弱く SQ02/SQ03 のような User Group 機能がない、ALV のレイアウト保存が個人単位に閉じるといった制約があります。定型運用レポートは SQ01/SQ02/SQ03 の SAP Query で作成するのが原則です。
出典：SAP Query（ABAP Query）入門：SQ01・SQ02・SQ03で作る簡易レポートの作り方

Selection criteria に主キー・外部キーなど索引が効く項目を含める、結合するテーブルを絞る、InfoSet に必要な項目だけ公開する、の 3 点が基本です。MM 系では購買伝票番号・仕入先コード・プラント・品目コードあたりが索引が効く代表例。100 万件を超える大規模データでは CDS View + Fiori のほうが圧倒的に高速です。
出典：SAP Query（ABAP Query）入門：SQ01・SQ02・SQ03で作る簡易レポートの作り方

InfoSet レベルでは不可です。InfoSet に登録した項目は同じ User Group 内のユーザー全員が参照できます。項目単位の権限制御が必要な場合は、CDS View に Data Control Language（DCL）を付けて権限制御し、Fiori Elements のアプリとして公開します。SAP Query は「同じ User Group 内で同じデータを見せる」前提の設計です。
出典：SAP Query（ABAP Query）入門：SQ01・SQ02・SQ03で作る簡易レポートの作り方

購買組織は「モノを買う権限」＝交渉と契約を担う組織の単位で、会社コード・プラントと並ぶ組織レベルです。購買グループはその中で実際に発注業務を担うバイヤー（人）の単位で、購買発注書に担当として記録されます。
出典：購買組織・購買グループの定義方法：OX08・OME4の設定手順

価格交渉力を最大化したいなら集中購買、拠点ごとの調達先や相場に合わせて機動的に動きたいならプラント固有購買です。実際は「共通品目は集中、現地調達品はプラント固有」という併用が最も多くなります。
出典：購買組織・購買グループの定義方法：OX08・OME4の設定手順

購買発注書（ME21N）のヘッダには購買グループの入力が必要なため、実質必須です。担当者・担当課の単位で登録しておくと、承認ワークフロー・照会・レポートの絞り込みに使えます。
出典：購買組織・購買グループの定義方法：OX08・OME4の設定手順

設定変更自体は可能ですが、購買情報レコード（購買組織＋品目＋仕入先）や既存の購買文書、勘定設定に影響します。導入時に確定させ、稼働後は影響調査なしに変更しないのが原則です。
出典：購買組織・購買グループの定義方法：OX08・OME4の設定手順

OX18はプラントを会社コードに割り当てる設定で、会計と在庫評価の帰属が決まります。1つのプラントは必ず1つの会社コードに属します。OX17は購買組織をプラントに割り当てる設定で、そのプラントで発注できる購買組織が決まります。1つのプラントには1つ以上の購買組織が必要です。
出典：組織単位の割当方法：OX18・OX01・OX17で階層をつなぐ

できます。会社コードに割り当てていない購買組織は、プラント側の割当（OX17）があれば全社のプラントで調達できます。逆に会社コードに割り当てると、その会社コードに属するプラントでしか購買できません。集中購買と会社固有購買のどちらを採るかを決めるのがOX01です。
出典：組織単位の割当方法：OX18・OX01・OX17で階層をつなぐ

必須ではありませんが設定を推奨します。1つのプラントに複数の購買組織が発注できる場合、標準購買組織は購買伝票やパイプライン調達・預託・在庫転送で既定値として使われます。未設定だと発注ごとに購買組織を手で選ぶ運用になり、選択ミスの原因になります。
出典：組織単位の割当方法：OX18・OX01・OX17で階層をつなぐ

設定変更自体は可能ですが、既存の購買文書・購買情報レコード・在庫評価の帰属に影響します。OX18の変更は在庫評価と会計の帰属が変わるため、稼働後は実質的に行いません。プラント追加時にOX17・OMKIを足す運用が中心で、削除や振替は影響調査と移行計画をセットで行います。
出典：組織単位の割当方法：OX18・OX01・OX17で階層をつなぐ

標準のF5・F8では計上されません。FI会計伝票が作られないため、売掛金・売上・消費税は発生しません。売掛金が立つのは、出庫後のF2など実際請求の請求タイプです。
出典：SAP Proforma Invoiceはなぜ売掛・買掛を作らないのか——F5・F8・F2とMIROを1枚でつなぐ

参照する伝票で選びます。受注（Sales Order）を参照するならF5、納品（Delivery）を参照するならF8です。納品前の前払依頼や価格提示はF5、通関・船積み書類はF8が向きます。
出典：SAP Proforma Invoiceはなぜ売掛・買掛を作らないのか——F5・F8・F2とMIROを1枚でつなぐ

原則として登録しません。MIROはCommercial InvoiceやFinal Invoiceを登録して買掛金を計上する画面です。Proforma Invoiceは前払い・通関・社内承認の根拠資料として管理します。
出典：SAP Proforma Invoiceはなぜ売掛・買掛を作らないのか——F5・F8・F2とMIROを1枚でつなぐ

買い手側は、購買発注に前払条件を持たせて前払請求（F-47）を作成し、前払実行（F-48）で会計を動かします。残高はME2DP（ダウンペイメント・モニタ）で発注単位に追跡し、MIROまたは支払時に控除します。
出典：SAP Proforma Invoiceはなぜ売掛・買掛を作らないのか——F5・F8・F2とMIROを1枚でつなぐ

1つのプラントは必ず1つの会社コードに属し、OX18で割り当てます。1つの会社コードには複数のプラントを持てます。会社コードは会計単位（貸借対照表・損益計算書）、プラントは在庫評価と物流の単位という役割の違いがあります。
出典：プラントの定義方法：OX10の手順と保管場所（OX09）の作り方を図解

「現場で在庫を分けて数えたい単位」ごとに作ります。原料倉・完成品倉・検品エリア・廃棄置き場のように、棚卸や在庫レポートで区別したい置き場所が目安です。金額評価には影響せず、会計設定を変えずに追加できるため、プラントよりは柔軟に増やせます。
出典：プラントの定義方法：OX10の手順と保管場所（OX09）の作り方を図解

設定側ではOX10→OX18（会社コード）→OX17（購買組織）→OX09（保管場所）の順に整えます。マスタ側では在庫・発注対象の品目にプラントビューを展開し、仕入先と購買情報レコードを整備します。さらに評価クラス・在庫勘定の自動転記、権限ロール、棚卸計画の確認が必要です。
出典：プラントの定義方法：OX10の手順と保管場所（OX09）の作り方を図解

在庫金額（評価額）はプラントで決まります。数量はプラント＋保管場所で管理されます。そのため保管場所を細かく分けても会計上の在庫金額は変わらず、「評価方法を変えたい場合はプラントを分ける」という原則になります。
出典：プラントの定義方法：OX10の手順と保管場所（OX09）の作り方を図解

会社コードは必須ですが、会社（Company）は任意です。単一法人で連結決算をSAP上で行わない場合は、会社を定義しなくてもMM・FIの運用は可能です。ただし、複数会社コードの財務諸表をまとめて見たい場合やグループ決算を行う場合は、会社を定義して束ねます。
出典：会社・会社コードの定義方法：OX15・OX02の設定手順を解説

通貨は転記（会計伝票）が発生した後は原則変更できません。言語や国も、既存マスタ・帳票・テキストとの整合性の面で変更は大きな影響を伴います。「後から直せる」と思わず、導入設計の段階で法人ごとに確定させてください。多通貨対応が必要なら並行通貨（Parallel Currencies）の導入を検討します。
出典：会社・会社コードの定義方法：OX15・OX02の設定手順を解説

OX02は会社コードの「定義」、OX01は購買組織を会社コードに「割り当てる」設定、OX18はプラントを会社コードに割り当てる設定です。SAPの組織設定は「定義（Define）→割当（Assign）」の順で進むため、OX02で定義してからOX01・OX18で紐づけます。
出典：会社・会社コードの定義方法：OX15・OX02の設定手順を解説

会社コードは4桁以内の英数字（先頭に0は不可）で設定します。実務では「日本法人＝1000、中国法人＝2000、米国法人＝3000」のように、法人単位で10の倍数を割り振る例が多いです。番号は伝票やマスタに残るため、将来の増設（買収・新会社）を見越した体系を最初に決めましょう。
出典：会社・会社コードの定義方法：OX15・OX02の設定手順を解説

SPROは設定メニュー（IMG）を開くためのTコードの名前です。現場では「SPRO＝カスタマイズ作業」を指す言葉としても使われます。「IMG＝設定画面の総称」「SPRO＝その画面を開くコマンド」と覚えると混乱しません。Tコード「SPRO」を実行すれば、プロジェクトの選択画面（SAP Reference IMGを含む）が開きます。
出典：IMG（SPRO）入門：SAP MMの設定画面への行き方とメニューパス

学習・調査・単発の確認はSAP Reference IMG、実際の導入作業はプロジェクトIMGがおすすめです。両者のツリー構造は同じですが、プロジェクトIMGは自社プロジェクトで変更する活動だけを絞って表示し、担当者やトランスポート要求（TR）との紐づけができます。本番稼働後の変更管理（誰が・いつ・何を変えたか）を残すうえでも、実装中はプロジェクトIMGを使うのが定石です。
出典：IMG（SPRO）入門：SAP MMの設定画面への行き方とメニューパス

大半は次の3つのどれかです。①別クライアントで業務画面を開いている（設定はクライアント単位で有効）、②トランスポート要求（TR）をリリースしていないため他クライアントへ未移送、③設定自体は正しいが、マスタデータや既存データとの組み合わせで期待どおりに見えない。まず「どのクライアントで設定したか」と「TRの状態」を確認してください。
出典：IMG（SPRO）入門：SAP MMの設定画面への行き方とメニューパス

会社コード・プラント・購買組織などの組織は「Enterprise Structure → Definition／Assignment」、品目タイプ・番号範囲などは「Logistics - General → Material Master」、購買・在庫・請求書照合などの業務設定は「Materials Management」配下です（図2のパス表が早見表になります）。まずは開発クライアントでSPROを開き、Enterprise Structureを展開して眺めるだけでも、導入プロジェクトの流れがつかめます。
出典：IMG（SPRO）入門：SAP MMの設定画面への行き方とメニューパス

会社コードは会計上の単位（自前のBS・PLを持つ）、プラントは操業・在庫評価の単位です。プラントは必ず1つの会社コードに帰属し、1つの会社コードに複数のプラントを持てます。在庫金額はプラント（評価領域）で管理されます。
出典：SAP MMのエンタープライズ構造とは？6つの組織レベル（会社コード・プラント・購買組織）の役割を図解

プラントは在庫金額の評価単位、保管場所はその中で在庫を物理的に区別する単位です。同じプラント内に複数の保管場所（原料倉・完成品倉など）を持てます。保管場所の増設は会計設定に影響しないため比較的柔軟です。
出典：SAP MMのエンタープライズ構造とは？6つの組織レベル（会社コード・プラント・購買組織）の役割を図解

「同じものを大量に買う」共通部品・間接材は集中購買（1つの購買組織）で量を集約し、価格交渉力と標準化を高めます。工場ごとに仕入先や仕様が異なる現場依存品は、会社固有・プラント固有の購買組織で機動的に調達するのが一般的です。
出典：SAP MMのエンタープライズ構造とは？6つの組織レベル（会社コード・プラント・購買組織）の役割を図解

購買組織は仕入先との価格交渉・契約を担う組織単位で、外部の購買取引に法的な責任を持ちます。購買グループはその内部で日々の発注業務を担当するバイヤーのグループです。1つの購買グループを複数の購買組織に割り当てることもできます。
出典：SAP MMのエンタープライズ構造とは？6つの組織レベル（会社コード・プラント・購買組織）の役割を図解

預託在庫は自社敷地内にあっても所有権は仕入先にあります。消費（払出・移動タイプ411）した時点で支払義務が発生し、在庫評価の対象になります。通常在庫は購入時点で所有権が自社に移り、在庫金額に計上されます。
出典：特殊調達・特殊在庫とは？預託・外注・パイプライン・在庫転送の仕組み

通常発注は完成品を購入するだけですが、外注は自社の部品を仕入先に支給して加工してもらい、完成品を受け取ります。発注書（アイテムカテゴリL）に支給部品のリストを含めるのが特徴です。
出典：特殊調達・特殊在庫とは？預託・外注・パイプライン・在庫転送の仕組み

同一企業内で、受入プラントが供給プラントに対して発注する特殊な発注書（タイプU）です。社内取引として在庫転送され、外部の仕入先は登場しません。プラント間の在庫移動を一元管理できます。
出典：特殊調達・特殊在庫とは？預託・外注・パイプライン・在庫転送の仕組み

水道・電力・ガスなど、パイプライン経由で継続供給される品目です。在庫を持たず使用量を定期精算するため、保管コストがかからず棚卸も不要です。
出典：特殊調達・特殊在庫とは？預託・外注・パイプライン・在庫転送の仕組み

顧客・仕入先の番号範囲設定はそのまま引き継げますが、BP関連の設定（BUC2・BUCFでのBP番号範囲、ロール、フィールド属性、アカウントグループ関連付け）はすべて実行し直す必要があります。BPを顧客と同じ番号で作成したい場合は、「BPから顧客／仕入先への番号割当」で同番号を設定します（資料のFAQ・設定パス参照）。
出典：SAP S4HANA BP后台配置及前台操作详解 共61页 2020年编著 PDF版

トランザクションFLBPC1／FLBPD1で顧客・仕入先からBPを作成できます。大量件数はMDS_LOAD_COCKPIT（マスタデータ同期ロードコックピット）で一括変換するのが効率的です。変換前に番号範囲の3者一致・外部採番を済ませておくことが成功の前提です。
出典：SAP S4HANA BP后台配置及前台操作详解 共61页 2020年编著 PDF版

使えません。S/4HANAでは顧客・仕入先マスタの作成・変更・表示はすべてトランザクションコードBPで行います（資料では非対応Tコードとして10種類以上のグループが列挙されています）。運用マニュアルと教育をBP操作に切り替えましょう。
出典：SAP S4HANA BP后台配置及前台操作详解 共61页 2020年编著 PDF版

システム上は「同じにするのが推奨・強制ではない」とされています。ただし実務では3者を一致させて運用するのが標準で、一致させるには番号範囲の3者一致＋外部採番＋「同番号」設定が必要です。一致していないとBPからマスタを作成するたびに番号を手入力する運用になり、ミスの温床になります。
出典：SAP S4HANA BP后台配置及前台操作详解 共61页 2020年编著 PDF版

入荷（Goods Receipt）と請求（Invoice Receipt）のタイミングのズレを一時的に調整する勘定科目です。品物が先に届いた時点では在庫を増やしてGR/IR勘定を立て、請求書が届いた時点でGR/IR勘定を消して買掛金を計上します。
出典：SAP MMのGR/IR勘定とは？発注・入荷・請求の「ズレ」を解消する仕組みを図解アニメーションで解説

GRは入荷・入庫（Goods Receipt）、IRは請求書受領（Invoice Receipt）です。GRで在庫とGR/IR勘定が発生し、IRでGR/IR勘定の消込と買掛金の計上が発生します。この2つを別々に記録するのが、SAPの設計上の特徴です。
出典：SAP MMのGR/IR勘定とは？発注・入荷・請求の「ズレ」を解消する仕組みを図解アニメーションで解説

3ウェイマッチ（発注数量・入庫数量・請求数量と単価の突き合わせ）で、どの明細が食い違っているかを特定します。数量差異・単価差異に分類し、受入超過は承認を得て請求書を修正するなど、会社の業務ルールに沿って対応します。
出典：SAP MMのGR/IR勘定とは？発注・入荷・請求の「ズレ」を解消する仕組みを図解アニメーションで解説

GR/IR勘定に残った残高は「未着品（IR待ち）」「未請求（GR待ち）」のサインです。滞留を放置すると在庫・原価・買掛金のいずれかに不整合が残るため、MB5SやMRBRで定期的に確認し、原因（納品書未処理・請求遅延など）をプロセス側で解消します。
出典：SAP MMのGR/IR勘定とは？発注・入荷・請求の「ズレ」を解消する仕組みを図解アニメーションで解説

ME53Nは購買依頼（PR）を照会・確認するトランザクション、ME9Fは発注書（PO）の出力メッセージを一覧処理して印刷・送信するトランザクションです。PRをまとめて出力したい場合はME9Aを使います。
出典：SAPの購買依頼・発注書の印刷をME53NとME9Fで解決：出力メッセージ・スプール・再出力まで解説

出力メッセージ未送信のみにチェックが入っている場合は、対象がすべて送信済みの可能性があります。チェックを外すか、出力タイプ・発注日の条件を広げて再実行してください。
出典：SAPの購買依頼・発注書の印刷をME53NとME9Fで解決：出力メッセージ・スプール・再出力まで解説

ME9Fで出力したスプール要求をSP01で開き、プレビューからPDFとして保存するか、プリンタ定義にPDFプリンタ（例：PDF出力用デバイス）を設定して出力します。
出典：SAPの購買依頼・発注書の印刷をME53NとME9Fで解決：出力メッセージ・スプール・再出力まで解説

SP01で該当スプールを選んで再印刷するのが基本です。スプールが残っていない場合は、ME9Fの一覧で該当行を選択し［再出力］で出力メッセージを再生成します。
出典：SAPの購買依頼・発注書の印刷をME53NとME9Fで解決：出力メッセージ・スプール・再出力まで解説

まずME53Nで購買依頼の照会に慣れ、次にME9Fで「出力メッセージ未送信のみ」の条件で実行してみるのがおすすめです。変式（バリアント）を保存すると毎日の運用が格段に楽になります。
出典：SAPの購買依頼・発注書の印刷をME53NとME9Fで解決：出力メッセージ・スプール・再出力まで解説

MMは社外から「買う」調達・在庫管理を、SDは社外へ「売る」受注・出荷・請求を担当します。同じ在庫マスタ・在庫数量を参照し合うため、在庫引当や払出のタイミングで両モジュールが連携します。
出典：SAP MMとは？購買から入庫・支払までのProcure-to-Payプロセスを解説

仕入価格が変動しやすい原材料は移動平均価格、生産計画の原価管理を重視する完成品や半製品は標準価格を使う企業が多いです。どちらも品目マスタの会計ビューで設定します。
出典：SAP MMとは？購買から入庫・支払までのProcure-to-Payプロセスを解説

発注（Purchase Order）・入庫（Goods Receipt）・請求書（Invoice）の3つのデータを突き合わせて、数量と金額が一致しているかを確認する仕組みです。差異があると請求書がブロックされ、支払前に確認が入ります。
出典：SAP MMとは？購買から入庫・支払までのProcure-to-Payプロセスを解説

まずはME51N（購買依頼）からME21N（発注）、MIGO（入庫）、MIRO（請求書照合）までを実際に流してみて、3点照合でどう数量・金額がチェックされるかを体感するのが近道です。次に品目マスタの評価クラス・価格決定方式を追うと理解が深まります。
出典：SAP MMとは？購買から入庫・支払までのProcure-to-Payプロセスを解説

貸与Issueです。受注タイプLNで受注を作成し、出荷伝票を作成してPGIすると、移動タイプ623で顧客特殊在庫Vと自社評価在庫から該当数量が減り、請求伝票が作成されます。貸与契約の残数量はIssue数量だけ自動的に減ります。
出典：貸与品の一部売却は「代表品目のマイナス」ではない——SAP SDでLN受注とPGI 623が生成する理由

貸与出荷（PGI 621）が完了しているため、受注明細の注文数量を出荷数量より小さくすると、メッセージV4 083（注文数量が出荷数量を下回る）で警告されます。さらにKBA 2163207の設定でこれをエラーにすることもできます。契約そのものを差し引くのではなく、Issue伝票を別の取引として起票するのが標準です。
出典：貸与品の一部売却は「代表品目のマイナス」ではない——SAP SDでLN受注とPGI 623が生成する理由

所有権が移転しているかどうかが本質です。無償品（TANN）は購入の対価が存在しない状態で渡るため所有権が移転済みで請求対象。貸与品（LEIH）は自社所有のまま顧客に置くため通常は請求対象外です。この2つを取り違えると、貸与品側で請求が発生しない前提が崩れ、Issue時の請求設計が成立しなくなります。
出典：貸与品の一部売却は「代表品目のマイナス」ではない——SAP SDでLN受注とPGI 623が生成する理由

冪等性（2回生成させない）、残数再計算（返却済との競合）、承認取消時の取消連鎖、個体（シリアル）単位の確定、残数の整合検証、そして最重要の「貸与出荷が請求済みか」の事前判定です。とくに最後の判定を飛ばすと、二重課上が起きます。
出典：貸与品の一部売却は「代表品目のマイナス」ではない——SAP SDでLN受注とPGI 623が生成する理由

LNは受注タイプ（貸与Issueの受注区分）で、LNNは明細カテゴリ（貸与Issue向けの明細区分）です。SAP標準にはLNNの事例があります。環境によってZ明細カテゴリを新設している会社もあり、個別の貸与実装ではZカテゴリを新設することもあります。
出典：貸与品の一部売却は「代表品目のマイナス」ではない——SAP SDでLN受注とPGI 623が生成する理由

SDは受注から出荷・請求までの「売る」プロセスを、MMは購買から入庫・在庫管理までの「買う・保管する」プロセスを担当します。出荷時の在庫引当や生産部品の払出など、両モジュールは在庫データを介して密接に連携します。
出典：SAP SDとは？受注から出荷・請求までの販売プロセスを解説

「プライシング手続き（Pricing Procedure）」に条件タイプ（基本価格・割引・税など）が順序付けて登録されており、各条件タイプは「条件テーブル」と「アクセスシーケンス」にもとづいて、得意先・品目・数量などの条件でマスタから値を取得します。
出典：SAP SDとは？受注から出荷・請求までの販売プロセスを解説

得意先ごとに設定した与信枠（信用限度額）を、未決済の受注・請求残高が超えないかをチェックする仕組みです。FD32で与信枠を設定し、超過すると受注がブロックされ、承認者の解除待ちになります。
出典：SAP SDとは？受注から出荷・請求までの販売プロセスを解説

まずはVA01（受注作成）からVL01N（出荷）、VF01（請求）までを実際にシステム上で流してみて、コピー統制でデータがどう引き継がれるかを体感するのが近道です。次にプライシング手続きと与信管理の設定を追うと、応用が利くようになります。
出典：SAP SDとは？受注から出荷・請求までの販売プロセスを解説

SAP Business Suite 7（ECC 6.0 など）の通常保守が2027年末で終了し、以降は有償の延長保守が2030年末まで提供される予定であることから、期限までの移行判断を迫られる問題を指します。期限は2段階で捉えるのが実務的です。
出典：S/4HANA 2027年問題とは？保守期限までの逆算ロードマップ

アドオンが少なく現行業務を維持したい場合はシステムコンバージョン型、業務プロセスを見直したい場合やアドオンが多い場合は新規導入型が候補になります。判断軸はアドオン量・標準適合度・変革の許容度の3点です。
出典：S/4HANA 2027年問題とは？保守期限までの逆算ロードマップ

延長保守は有償であり、単純な先延ばしはコスト増になります。移行期間を確保するための計画的利用や、段階移行の受け皿として設計する使い方が現実的です。
出典：S/4HANA 2027年問題とは？保守期限までの逆算ロードマップ

現行システムの棚卸し（アドオン・帳票・インターフェース・利用頻度）です。ここで「廃止できるもの」を確定できると、その後の移行範囲・工数・テスト計画が具体的になります。
出典：S/4HANA 2027年問題とは？保守期限までの逆算ロードマップ

記録はできますが、優先度・SLA・構成情報（CMDB）・変更承認が連動しないため、重大障害の判断や影響範囲の特定が属人的になります。運用の再現性が必要になった段階が導入の目安です。
出典：ServiceNowとは？ITSM導入で何が変わるかを図解で整理

ITSM の基本プロセス（インシデント・要求・変更・ナレッジ）を1部門で運用開始するまでに数か月、全社展開と CMDB 整備を含めると半年〜1年以上を見込みます。範囲の切り方で大きく変わります。
出典：ServiceNowとは？ITSM導入で何が変わるかを図解で整理

多くの場合、ITSM（特にインシデントとサービス要求）から始めるのが効果的です。利用者との接点が多く効果が見えやすく、CMDB や ITOM の整備はその後段階的に進められます。
出典：ServiceNowとは？ITSM導入で何が変わるかを図解で整理

カテゴリ追加・フロー修正・レポート整備を継続するため、プラットフォーム管理者とプロセスオーナーの設置を推奨します。特にプロセスオーナー（運用責任者）が不在だと、設計が現場の実態と乖離します。
出典：ServiceNowとは？ITSM導入で何が変わるかを図解で整理

ITSM は「利用者からの依頼や障害にどう対応するか」というプロセスを扱い、ITOM は「監視・検知・自動復旧」といった運用そのものを扱います。ITSM で窓口とルールを整え、ITOM で検知と自動化を強化する順序が現実的です。
出典：ServiceNowとは？ITSM導入で何が変わるかを図解で整理

影響を受けるシステム、利用者数、業務停止時間、財務影響などの数値で定義します。あわせて、宣言者・連絡先・更新頻度・収束後の振り返り実施条件まで決めておくことで、初動が属人的にならなくなります。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

いいえ。同一原因の再発、重大障害、ベンダー対応が必要な事象など、昇格条件を決めて該当するものだけを問題として管理します。すべてを問題化すると管理不能になります。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

定型度の高い作業を標準変更として事前承認し、承認フローから外すのが有効です。また承認に必要な情報（影響範囲・ロールバック手順・検証方法）をテンプレート化すると、判断が速くなります。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

復旧時間（MTTR）と緊急変更の比率の2つから始めることを推奨します。前者は対応力、後者は統制の効き具合を示し、どちらも改善テーマが具体的に見つかります。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

重大障害（影響度の高い停止）は必ず発生後 1 週間以内に行い、それ以外は月次にまとめて振り返るのが現実的です。重要なのは頻度より、振り返りで決めた改善策を変更として起票し、実施まで追跡することです。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

インシデントは「サービスが止まっている・品質が落ちている」状態への対応、サービス要求は「標準的な作業（アカウント追加等）の依頼」です。優先度の付け方が異なるため、カテゴリを分けて別のフローで処理します。
出典：ServiceNow運用設計：インシデント→問題→変更の流れを作る

影響の大きい基幹系（SAP、認証基盤、ネットワーク）と、その上の業務サービスから始めることを推奨します。全資産を一括で登録する進め方は、更新が追いつかず形骸化しがちです。
出典：ServiceNow CMDBとSAP連携：構成管理を起点にした運用高度化

自動検出（Discovery 等）を「正」とし、人手管理は業務サービス定義と例外に限定します。あわせて重複・未更新・孤立 CI の件数を月次で確認する運用を入れると維持できます。
出典：ServiceNow CMDBとSAP連携：構成管理を起点にした運用高度化

障害や変更の影響を「業務の言葉」で説明できるようになります。たとえば「このサーバ停止で受注登録が止まる」と即座に判断でき、連絡先・影響範囲・過去の類似障害を同じ画面で確認できます。
出典：ServiceNow CMDBとSAP連携：構成管理を起点にした運用高度化

機能自体は早期に使えますが、効果はデータ品質に依存します。まずインシデント要約やナレッジ候補提示から始め、カテゴリ・CMDB・解決記録が整ってから判断の自動化へ進む段階設計を推奨します。
出典：ServiceNow CMDBとSAP連携：構成管理を起点にした運用高度化

作業の指示が明確で時間管理が必要な案件は派遣、業務の進め方ごと委ねる案件は準委任（SES）、明確な成果物を求める場合は請負が適します。単価ではなく、業務の性質と責任の所在で選んでください。
出典：SESと派遣の違い：契約形態・指揮命令・向く案件を整理

準委任では指揮命令権は受託元にあります。発注者は業務の目的・要件を示し、進め方の判断は受託元が行う形にします。実態として直接指示が常態化すると偽装請負と判断される可能性があります。
出典：SESと派遣の違い：契約形態・指揮命令・向く案件を整理

契約が準委任・請負でも、発注者が受託元のエンジニアへ直接業務指示を行い、勤怠や配置を管理し、受託元に業務遂行としての実体（指揮・検収・責任）がない場合です。指示系統と管理体制の両面で判断されます。
出典：SESと派遣の違い：契約形態・指揮命令・向く案件を整理

派遣は労働時間に対する精算として精算幅を設定することが一般的です。準委任では業務遂行の対価として月額・精算幅を定める運用が多く、請負では成果単位の対価となるため精算幅という考え方は用いません。
出典：SESと派遣の違い：契約形態・指揮命令・向く案件を整理

案件の性質によります。作業範囲を特定して指示する定型業務は派遣、設計や進め方ごと任せる開発・運用案件は準委任（SES）が選ばれる傾向があります。単価ではなく業務の性質で判断するのが基本です。
出典：SESと派遣の違い：契約形態・指揮命令・向く案件を整理

S/4HANAに内蔵された埋め込み型（embedded）として利用できます。独立したスタンドアロン製品として接続する構成も可能で、統合モードは導入時に選択します。
出典：SAP TMとは？輸送要求・計画・実行・運賃精算の4プロセスを図解

標準の出荷機能は1受注＝1出荷の固定的な輸送に向きます。便のまとめ・積載最適化・キャリア手配・運賃の計算と精算まで必要になったらTMの領域です。
出典：SAP TMとは？輸送要求・計画・実行・運賃精算の4プロセスを図解

倉庫内の入出庫・棚卸・荷役はEWM、その前後の輸送計画と運賃はTMが基本の切り分けです。連携する場合は輸送ユニットの扱いと納品分割の設計を先に決めます。
出典：SAP TMとは？輸送要求・計画・実行・運賃精算の4プロセスを図解

シナリオを1本に絞り、マスタと運賃契約を整えて計画〜精算を1件通す範囲なら、数か月単位から着手できます。対象拠点数と運賃契約の複雑さが期間を最も左右します。
出典：SAP TMとは？輸送要求・計画・実行・運賃精算の4プロセスを図解

輸送能力の先押さえと納期精度が必要なら受注ベース、既存SD運用を変えずに段階導入したいなら納品ベースです。実務では受注ベースで予測し納品ベースで確定する併用が多く、その場合は消費関係の監視が必須になります。
出典：SAP TMとSDの連携——受注から出荷・運賃請求までの業務プロセスを図解

できます。SAPのドキュメントでも、関連する受注がTMに送られていなくても納品を統合できると明記されています。輸送関連性の設定で、対象となる納品タイプを指定します。
出典：SAP TMとSDの連携——受注から出荷・運賃請求までの業務プロセスを図解

内部TMコンポーネントとの統合が必要で、1つの納品に対して1つのフレイトオーダーであること、そのフレイトオーダーの通貨が1つであることが条件です。
出典：SAP TMとSDの連携——受注から出荷・運賃請求までの業務プロセスを図解

できます。TM起点でERP側の納品分割を要求する仕組みがあり、分割・更新タイプを定義して輸送要求に割り当てます。分割後の数量差異をどう扱うかを先に決めておくことが重要です。
出典：SAP TMとSDの連携——受注から出荷・運賃請求までの業務プロセスを図解