目次
この記事のポイント
- SD→TMの連携は受注ベース（OTR）と納品ベース（DTR）の2型。実務は併用が多い
- 受注をTMに送らなくても納品だけは連携できるため、既存SD運用を変えずにTMを後付けできる
- 輸送所要時間（TRS）をSDの納期計算に反映でき、納期の妥当性を輸送の実力で裏付けられる
- 運賃はキャリアへの支払（精算伝票→MM/FI）と顧客への請求（納品明細へ按分→SD請求）の2方向に流れる
01WHAT 連携はどこで起きるのか——SDとTMの役割分担
SDとTMは、Order-to-Cash（受注から入金まで）のなかで担当が分かれます。SDが持つのは受注・納品・出荷・請求という商流の伝票、TMが持つのは輸送要求・計画・実行・運賃という物流の実行と費用です。どちらかが他方を置き換える関係ではなく、同じ「出荷」という事象を別の角度から管理しています。
連携の接点は4つです。第1に輸送需要の受け渡し（受注または納品から輸送要求を作る）、第2に納期の裏付け（輸送所要時間をSDの納期計算に使う）、第3に計画結果のフィードバック（TMから納品の起票を提案する、納品分割を要求する）、第4に運賃の受け渡し（運賃をキャリアへの支払と顧客への請求の両方に使う）です。
SAPのドキュメントでは、これらは「Internal TM Component Integration（TM内部コンポーネント統合）」としてまとめられ、受注・納品・JITコールの3種類を統合する枠組みとして説明されています。統合できる伝票は販売伝票・返品・購買発注・在庫転送依頼、加えて販売／購買／在庫転送の日程契約です。対象を「全部」にする必要はなく、輸送関連性の設定で絞り込めます。
SD側で決めること、TM側で決めること
設計を進めると、判断がSD側とTM側に分かれていることが見えてきます。SD側で決めるのは、輸送関連性（どの販売伝票タイプ・納品タイプをTMに送るか）、出荷ポイントとルート、納品分割の可否、そして請求時の運賃の扱いです。TM側で決めるのは、統合モード（内部TMコンポーネントか外部TMシステムか）、フレイトユニット構築ルール（FUBルール）、計画プロファイル、運賃契約と計算プロファイルです。
とくに効くのが統合モードの選択です。S/4HANAに内蔵された内部TMコンポーネントを使うか、外部のTMシステムに接続するかで、設定の置き場所も連携の方式も変わります。顧客への運賃請求（運賃をSDの請求書に載せる）を行う場合は、内部TMコンポーネントとの統合が必要である点も、SAPのドキュメントに明記されています。
02PATTERN 受注ベースと納品ベース、2つの連携パターン
SAPのドキュメントは、受注の統合と納品の統合を別々のプロセスとして説明しています。受注ベースでは、受注・返品・購買発注・在庫転送依頼から受注ベース輸送要求（OTR）を作り、納品前に輸送需要を可視化します。納品ベースでは、LEで作成された出荷納品・入荷納品から納品ベース輸送要求（DTR）を作ります。
受注がTMにとって非関連（＝輸送関連性の設定で送っていない）場合のプロセスは明快です。①SD／MMで受注を作成（TM非関連）→②LEで納品を作成→③TMがFUBルールに従ってフレイトユニットを新規作成→④輸送計画→⑤輸送実行。この順序なら、既存のSD運用に手を入れずにTMを導入できます。
受注ベースを使うと、それ以外の利点も出てきます。輸送計画の結果を踏まえて納品の起票をTMから提案できること、リソースの空きや輸送時間といった制約を織り込んで納品日・数量を決められることです。さらにTRS（輸送要求ルーティングとスケジューリング）を使えば、積込・輸送・荷下ろしの所要時間を決定し、SDの受注や日程契約の納期計算に反映できます。
| 観点 | 受注ベース（OTR） | 納品ベース（DTR） |
|---|---|---|
| 起点伝票 | 販売伝票・購買発注・在庫転送依頼・日程契約 | 出荷納品・入荷納品 |
| 輸送需要の見え方 | 納品前から見える（能力の先押さえが可能） | 確定した納品内容（正確だが手配が後ろ倒し） |
| 梱包・荷姿の反映 | 限定的 | ハンドリングユニットなど梱包情報を引き継げる |
| 更新時の挙動 | 数量・納期変更のたびに輸送要求を更新 | 納品の変更・削除・分割に追随して更新・取消 |
| 向くケース | 輸送能力が逼迫する、納期約束を精度よく出したい | SD運用を変えずに段階導入したい、荷姿が重要 |
OTRとDTRは「消費」でつながる
DTRはOTRの輸送需要を消費します。1件のOTRを複数のDTRで分割して消費できるため、部分納品や分割出荷をそのまま表現できます。OTR側には消費状況（未消費／一部消費／全量消費）が残るので、立てた需要が実出荷で消化されたかを追跡できます。
03POINTS 連携設計の実践ステップ6つ
SD×TMの連携は、設定項目が多く見えますが、決めるべき順序はほぼ決まっています。「どの伝票を送るか」「どの粒度で計画するか」「運賃をどこへ流すか」の3つを先に固めると、残りは機械的に決まります。
- 統合モードを決める内部TMコンポーネント（S/4HANA内蔵）か、外部TMシステムかを選択します。顧客への運賃請求まで行うなら内部統合が前提になります。
- 輸送関連性を定義する売上伝票と納品のそれぞれについて、TMに連携する条件を定義します。全伝票を対象にせず、対象タイプを絞ることで連携量と保守コストを抑えます。
- 統合の制御キーを決める伝票統合用の制御キーを定義し、TRSプロファイル（輸送所要時間決定プロファイルまたは要件ルーティングプロファイル）を紐づけます。ここで納期計算の精度が決まります。
- フレイトユニット構築ルール（FUBルール）を設計する納品のどの単位でフレイトユニットを作るかを決めます。伝票単位か明細単位か、品目や重量で分けるかで、計画の自由度と積載効率が変わります。
- 納品分割と更新の扱いを設計するTM起点でERPの納品分割を要求する場合、分割・更新タイプを定義してDTRに割り当てます。納品の変更・削除・分割が発生したときの更新ルールもここで決まります。
- 運賃の出口を2方向とも設計するキャリアへの支払（フレイト精算伝票→MM・FI）と、顧客への請求（納品明細へのコスト按分→SD請求）を、同じ運賃から作れる状態にします。
更新連携の遅延が計画を壊す
受注や納品の数量・納期が変更されると、輸送要求とフレイトユニットも更新が必要です。更新が遅れると、すでに計画済みの便に古い数量が残り、積載超過や空車が発生します。変更系の連携は「いつ、どの頻度で流すか」を運用ルールとして決めておきましょう。
04FREIGHT 運賃は2方向に流れる——支払と請求
SD×TM連携で最も設計価値が高いのが、運賃の出口です。フレイトオーダーで計算された運賃は、キャリアへ支払う費用としての顔と、顧客から回収する収益としての顔を持ちます。この2方向を最初から設計しておくと、後から「運賃が回収できていない」「請求根拠が説明できない」という問題を避けられます。
支払側はこう流れます。運賃を確定したフレイト精算伝票を転記すると、MMにサービスの購買発注とサービスエントリーシート（SES）が自動生成され、SESの確認と同時に運賃相当の会計仕訳が作られます。キャリアから請求書が届いたら請求書照合（ロジスティクス請求書検証）で突合し、差額があればクレジットメモや異議申し立てで処理します。評価入庫精算（ERS）を使う場合は、この請求までを自動で進められます。
請求側はこう流れます。フレイトオーダーの運賃を納品明細の単位に按分し、その金額をSDの請求書（請求伝票）に運賃条件として載せます。按分は重量比など基準を指定して配賦する方法と、特定の費用を特定の明細へ直接割り当てる方法を組み合わせられます。この請求連携には前提条件があり、1つの納品に対して1つのフレイトオーダーであること、そしてフレイトオーダー内の通貨が1つであることが必要です。
按分の例で動きを確認する
SAPのドキュメントには具体例があります。2つの納品（2,250kg と 2,750kg）を1つのフレイトオーダーで運び、基本運賃1,000＋燃料サーチャージ250＋梱包料150の合計1,400だった場合、基本運賃と燃料サーチャージは重量比で按分し（612.50 と 787.50）、梱包料は品目に直接割り当てます。按分後は各納品明細の請求金額に加算されます。
05INSIGHT よくある失敗と、その予防線
当社がSAPの物流領域の設計を支援するなかで、SD×TM連携で繰り返し見る失敗は3つです。1つ目は受注ベースと納品ベースの二重計画です。両方を有効にすると、同じ荷物がOTRとDTRの両方から計画対象になり得ます。消費関係のステータス（未消費・一部消費・全量消費）を監視項目として運用に組み込み、二重計上を検知できるようにしておきましょう。
2つ目は納品分割後の追跡断絶です。TM起点で納品を分割すると、新しい分割後の納品とフレイトユニットの対応が変わり、変更・削除の連携が複雑になります。分割・更新タイプの定義と、分割後の数量差異の扱いを先に決めておくことが予防線になります。
3つ目は運賃の按分ができない条件の見落としです。複数のフレイトオーダーにまたがる納品や、通貨が混在するフレイトオーダーでは、そのままでは按分・請求連携が成立しません。運賃を顧客へ転嫁する商流（運賃込みの売価で販売している場合など）では、この制約が利益に直結します。連携の前提はSAP TMとは？輸送要求・計画・実行・運賃精算の4プロセスで扱った4プロセスのどこに位置するかを意識しながら、SD側の設計（SAP SDとは？受注から出荷・請求までの販売プロセス）と突き合わせて確認するのが確実です。当社では、この突き合わせを設計初期に行うことで、稼働後の手戻りを減らす支援を行っています。
輸送所要時間だけで納期精度は上がる
SDの納期計算は、まず顧客の希望納期から逆算（後方スケジューリング）します。この逆算に使う輸送時間を、勘や経験ではなくTRSの決定結果に置き換える——TMを本格稼働させる前でも、この一部分だけを先に導入して納期精度を改善する進め方があります。
まとめ
- SDとTMの接点は「需要の受け渡し」「納期の裏付け」「計画結果の返却」「運賃の受け渡し」の4つ
- 受注ベース（OTR）は納品前に需要を可視化し、納品ベース（DTR）は現実の荷姿で計画できる。実務は併用が多い
- 受注をTMに送らなくても納品は連携でき、既存SD運用を変えずに段階導入できる
- TRSで輸送所要時間を決め、SDの納期計算（後方スケジューリング）に反映できる
- 運賃はフレイト精算伝票からMM・FIへ（支払）、納品明細へのコスト按分からSD請求へ（回収）の2方向に流れる
- 顧客請求の連携は「1納品＝1フレイトオーダー」「通貨は1つ」が前提条件になる
出典・参考
- Internal TM Component Integration（SAP Help Portal / SAP S/4HANA） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/.../04474a8485384e3fbfcb346d943b3217.html
- Integration of Deliveries（SAP Help Portal / SAP S/4HANA） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/.../7858bc3f5ff540d998277cb31fd09083.html
- Delivery-Based Transportation Requirement（SAP Help Portal / SAP S/4HANA） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/.../29b3aa3c47dc4cfb84456d6ece7c7e2a.html
- Integration of Sales Document Scheduling（SAP Help Portal / SAP S/4HANA） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/.../94b155b3c1524164add6b448dc3186dc.html
- Billing the Freight Cost in TM to a Customer in SD（SAP Help Portal / SAP S/4HANA） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/.../af6321d71d82402faf215eb44572b832.html
- Freight Settlement Document（SAP Help Portal / SAP S/4HANA） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/.../2f90ba3c7a8540e59f5ca0959d82e994.html
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-17）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。
06FAQ よくある質問
受注ベースと納品ベースはどちらを選ぶべきですか？
輸送能力の先押さえと納期精度が必要なら受注ベース、既存SD運用を変えずに段階導入したいなら納品ベースです。実務では受注ベースで予測し納品ベースで確定する併用が多く、その場合は消費関係の監視が必須になります。
受注をTMに連携せず、納品だけ連携できますか？
できます。SAPのドキュメントでも、関連する受注がTMに送られていなくても納品を統合できると明記されています。輸送関連性の設定で、対象となる納品タイプを指定します。
運賃を顧客の請求書に載せるのに条件はありますか？
内部TMコンポーネントとの統合が必要で、1つの納品に対して1つのフレイトオーダーであること、そのフレイトオーダーの通貨が1つであることが条件です。
納品をTMから分割することはできますか？
できます。TM起点でERP側の納品分割を要求する仕組みがあり、分割・更新タイプを定義して輸送要求に割り当てます。分割後の数量差異をどう扱うかを先に決めておくことが重要です。