目次
この記事のポイント
- SAP TMの業務は輸送要求 → 輸送計画 → 輸送実行 → 運賃精算の4プロセスに整理できる
- 輸送要求には受注ベース（OTR）と納品ベース（DTR）の2種類があり、需要の見え方が変わる
- 計画の最小単位はフレイトユニット（FU）、手配の単位はフレイトオーダー／フレイトブッキング
- 運賃は運賃契約 → 計算シート → レート表の3階層で自動計算され、フレイト精算伝票からMM・FIへ渡る
01WHAT SAP TMとは——「輸送」を管理対象にするモジュール
SAP TM（Transportation Management）は、輸送の計画・実行・精算を専用に扱うコンポーネントです。SAP S/4HANAに内蔵された「埋め込み型（embedded）」として動かすことも、独立したスタンドアロン製品として接続することもできます。ERPの標準機能である出荷（SD）や入荷（MM）だけで足りていた会社が、TMを検討し始める典型は「運ぶ量と便が増え、運賃の根拠を説明できなくなった」ときです。
TMが扱うのは、伝票の起票そのものではなく、輸送需要の集約・最適化・実績・費用です。同じトラックに載せられる注文をまとめる、積載率を上げる、キャリアへ手配する、実績を集める、運賃を計算して支払と請求につなげる——この一連の流れに責任を持ちます。
4つの業務プロセスと、それぞれの成果物
TMの機能は、成果物で区切ると理解しやすくなります。第1の「輸送要求（Transportation Requirement）」では、受注や納品といった業務伝票を輸送需要に変換し、フレイトユニット（Freight Unit）という計画単位を作ります。第2の「輸送計画（Planning）」では、ルート・積載・車両を決めてフレイトオーダー（陸上）やフレイトブッキング（海上・航空）を生成します。
第3の「輸送実行（Execution）」では、キャリアへの手配（テンダリング）、出発・到着・積込・荷下ろしといった実績イベントの収集、納品完了の証明（POD）を扱います。第4の「運賃精算（Settlement）」で運賃を確定し、フレイト精算伝票としてMM・FIへ渡します。計画は業務部門、精算は経理部門という担当の違いが、そのままプロセスの境界になります。
フレイトオーダーとフレイトブッキングの使い分け
輸送モードで伝票が変わります。道路・鉄道はフレイトオーダー、海上・航空はフレイトブッキングです。ブッキングは船腹やスペースの予約が主目的で、実行は同じ伝票上で進みます。陸上と国際輸送を両方持つ会社では、この2つを別々の設計として扱うのが安全です。
輸送需要はどこから来るのか
輸送需要の発生源は、SDの受注・返品、MMの購買発注、在庫転送依頼（STO）、そしてLogistics Execution（LE）の出荷納品・入荷納品です。SAPのドキュメントでは、これらをまとめて「Internal TM Component Integration（TM内部コンポーネント統合）」として整理しています。統合できる伝票には、販売伝票・返品・購買発注・在庫転送依頼に加え、販売／購買／在庫転送の日程契約（スケジューリングアグリーメント）も含まれます。
重要なのは、受注をTMに送らなくても、納品だけをTMに連携できるという点です。これは既存のSD運用を大きく変えずにTMを後付けできることを意味します。逆に、輸送能力を早い段階で押さえたい場合は受注の時点から連携し、需要を先に見える化します。どちらを選ぶかが、後述する「OTR／DTR」の設計判断になります。
02SCENARIO 6つの輸送シナリオと、業務プロセスの分岐
TMの導入検討では、まず「自社の輸送はどのシナリオか」を切り分けます。シナリオが決まれば、必要なマスタデータ、統合設定、運賃契約の作り方がほぼ決まります。
| シナリオ | 起点となる伝票 | 設計上の要点 |
|---|---|---|
| 出荷輸送（国内配送） | SD受注／出荷納品 | 配送便のまとめ方、積載率、配送時間帯の指定 |
| 入荷輸送（調達物流） | MM購買発注 | 仕入先引取か自社手配か、購買組織との連携 |
| 在庫転送（STO） | 在庫転送依頼 | 社内輸送の費用をどこに計上するか |
| 輸出（輸出物流） | SD受注／輸出納品 | インコタームズ、通関、船腹予約（ブッキング） |
| 輸入（輸入物流） | MM購買発注 | 到着地の費用負担、通関業者との連携 |
| 復路・回送・ラストマイル | 各種（または輸送ユニット） | 車両・コンテナなど物理単位での管理 |
シナリオを分ける際に最も差が出るのが、輸送要求の作り方です。受注ベースの輸送要求（Order-Based Transportation Requirement、以下OTR）は受注や購買発注から生成され、納品前でも輸送需要を可視化できます。納品ベースの輸送要求（Delivery-Based Transportation Requirement、以下DTR）は実際の納品から生成され、梱包単位まで含めた現実的な計画ができます。
両者は独立ではなく、DTRがOTRの輸送需要を「消費」する関係にあります。1件のOTRを複数のDTRで分割して消費できるため、部分納品や分割出荷を表現できます。OTRには消費状況（未消費／一部消費／全量消費）がステータスとして保持されるので、「予測として立てた需要が、実際の出荷で消化されたか」を追跡できます。
ブロックは輸送の「停止信号」
輸送要求には計画ブロックと実行ブロックがあります。ERP側の納品ブロック理由や出荷計画ブロックをTMのブロックにマッピングでき、与信チェックが未承認の場合はブロック理由「01（与信限度）」として輸送も止まります。与信と輸送のどちらを優先するかは、業務ルールとして先に決めておく必要があります。
03POINTS 導入・運用の実践ステップ6つ
TMは「機能が多い」ことが導入難易度に見られがちですが、実際の難所はマスタデータと運賃契約の整備です。ここが曖昧なまま計画だけを動かすと、計算された運賃の根拠を説明できなくなります。以下は、公式ドキュメントの構成に沿った着手順序です。
- 対象シナリオを1〜2本に絞る出荷輸送か入荷輸送か、国内か国際か。全シナリオ同時立ち上げは、マスタの量と運賃契約の複雑さが掛け算で増えるため避けます。
- ロケーションと輸送レーンを整備する出荷先・納入先・倉庫・港・駅をロケーションとして登録し、どの区間をどの輸送手段でどれだけかかるかを輸送レーンで定義します。ここがルーティングと輸送時間の事実上の正本になります。
- リソースとビジネスパートナーを登録する車両・トレーラ・コンテナなどのリソースに積載能力とカレンダーを持たせ、キャリアはビジネスパートナーとして登録します。キャリアプロファイルで運賃コードやサービスコードを保持します。
- 運賃契約を3階層で作る運賃契約（Freight Agreement）→計算シート→レート表・スケールの順に組み立てます。顧客へ課金する側はフォワーディング契約として分けて作ります。
- 統合設定を決める統合モード（内部TMコンポーネントか外部TMシステムか）、売上伝票と納品の輸送関連性、統合の制御キーを定義します。「どの伝票をTMに送るか」を決めるのがこの段階です。
- 計画から精算まで1件通す代表的な1案件で、輸送要求→計画→実行→精算までを最初から最後まで通します。運賃計算の結果と、MMに転送された購買発注・サービスエントリーシートの金額が一致するかまで確認します。
運賃が決まる仕組み——契約・計算シート・レート表
SAPのドキュメントでは、運賃計算は「契約と料金管理マスタに保存されたデータに基づいて行われる」と説明されています。運賃契約が「誰と、どの区間で、いつからいつまで」という枠を決め、計算シートが「どの費用項目をどの条件で計算するか」を並べ、レート表とスケールが重量帯・距離帯ごとの単価を持ちます。
実務でつまずきやすいのは、契約の決定順序です。同じ区間・同じキャリアに対して複数の契約が該当し得るため、決定タイプの設定を誤ると意図しない契約で運賃が計算されます。また、契約内に持つローカル計算シートと、共通利用するスタンドアロンの計算シートが混在しやすいので、どちらを正とするかを決めておくことが重要です。料金の変更はレート表の差し替えで表現でき、履歴も追えます。
最初に「運賃の説明責任」を設計する
「なぜこの金額なのか」を画面と帳票で説明できる状態を作るのが、TM導入の実質的なゴールです。契約・計算シート・レート表のどこから値が来たかを追えるようにしておくと、キャリアからの請求差異の調査が格段に速くなります。
04INSIGHT SD・MM・EWMとの役割分担をどう決めるか
TMの検討で必ず出る論点が「SDの出荷機能（VT01Nなど）で足りるのでは」という問いです。判断の目安は明確で、便をまとめる最適化・キャリアへの手配・運賃の計算と精算のいずれかが必要なら、それはTMの領域です。逆に、1受注＝1出荷で固定的なルート・固定的な運賃であれば、標準の出荷機能と条件レコードで運用できます。
倉庫側の業務が複雑な場合は、EWM（Extended Warehouse Management）との分担も論点になります。倉庫内の入出庫・棚卸・荷役はEWM、その前後の輸送計画と運賃はTMという切り分けが基本です。両者を連携する場合は、輸送ユニットを起点にした統合や、TM起点の納品分割（Delivery Split）の扱いを先に設計しておく必要があります。関連する基礎はSAP SDとは？受注から出荷・請求までの販売プロセスとSAP MMとは？購買から支払までのProcure-to-Payで解説しています。
もう1つ見落とされがちなのが、TMがSDの納期計算に効くという点です。輸送要求ルーティングとスケジューリング（TRS）は、輸送レーンなどのマスタデータから積込・輸送・荷下ろしの所要時間を決定し、SDの受注や日程契約の納期計算に渡します。「受注時に約束した納期を、輸送の実力で裏付ける」ことができるわけです。当社では、この納期精度の改善と、運賃の説明責任の両面からTM導入を支援しています。TMとSDの具体的な連携設計はSAP TMとSDの連携——受注から運賃請求までの業務プロセスで詳しく解説しています。
TRSは「輸送時間の辞書」
TRS（Transportation Requirement Routing and Scheduling）は、ルート決定・輸送時間決定・スケジューリングを担う基盤モジュールです。TMを本格導入していない段階でも、この輸送時間の決定だけを使ってSDの納期精度を上げる、という段階的な使い方ができます。
まとめ
- SAP TMは「運ぶ」業務を管理するモジュールで、計画は業務部門・精算は経理部門が担当する
- 業務は輸送要求 → 輸送計画 → 輸送実行 → 運賃精算の4プロセスに整理できる
- 輸送要求は受注ベース（OTR）と納品ベース（DTR）の2種類。DTRはOTRの需要を消費する関係にある
- 計画の粒度はフレイトユニット構築ルール（FUBルール）で決まり、ここが計画の自由度を左右する
- 運賃は運賃契約 → 計算シート → レート表の3階層で自動計算され、契約の決定順序の設計が重要
- 運賃の確定後はフレイト精算伝票としてMM・FIへ渡り、購買発注とサービスエントリーシートが生成される
出典・参考
- SAP Transportation Management（SAP Help Portal） https://help.sap.com/docs/SAP_TRANSPORTATION_MANAGEMENT
- Freight Order Management（SAP Help Portal / SAP S/4HANA） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/.../ff8bbbea9bd0421b9f833793d8d52b3d.html
- Freight Settlement Document（SAP Help Portal / SAP S/4HANA） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/.../2f90ba3c7a8540e59f5ca0959d82e994.html
- Order-Based / Delivery-Based Transportation Requirement（SAP Help Portal / SAP S/4HANA） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/.../ea229f34c04a4fbb9b5557c190f8b35d.html
- Transportation Requirement Routing and Scheduling（SAP Help Portal / SAP S/4HANA） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/.../7d80f89b99d84876b4ebac46f339500d.html
- Master Data（SAP Help Portal / SAP S/4HANA） https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/.../5b2dd77075064051999b153603ad1f41.html
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-17）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。
05FAQ よくある質問
SAP TMはS/4HANAに含まれていますか？
S/4HANAに内蔵された埋め込み型（embedded）として利用できます。独立したスタンドアロン製品として接続する構成も可能で、統合モードは導入時に選択します。
SDの出荷機能（VT01Nなど）との違いは何ですか？
標準の出荷機能は1受注＝1出荷の固定的な輸送に向きます。便のまとめ・積載最適化・キャリア手配・運賃の計算と精算まで必要になったらTMの領域です。
EWMとの役割分担はどう考えますか？
倉庫内の入出庫・棚卸・荷役はEWM、その前後の輸送計画と運賃はTMが基本の切り分けです。連携する場合は輸送ユニットの扱いと納品分割の設計を先に決めます。
導入期間の目安はどれくらいですか？
シナリオを1本に絞り、マスタと運賃契約を整えて計画〜精算を1件通す範囲なら、数か月単位から着手できます。対象拠点数と運賃契約の複雑さが期間を最も左右します。