在货代行业里，你听到的 “托书”，通常就是 订舱委托书 / 货物托运委托书，英文常见叫 Booking Note、Booking Instruction、Shipping Order。它本质上是：客户把这一票货的运输需求正式告诉货代。行业资料也把它定义为进出口方通过船公司或货代申请订舱的文件。
谁提供给谁？
最常见的链路是：
发货人 / 出口商 / 客户 → 货代 → 船公司 / 订舱代理
更具体一点：
客户：“我要出 2×40HQ，深圳盐田到洛杉矶，预计 9 月 20 日出货，这是托书。”
↓
货代业务/操作收到托书
↓
检查货物、港口、柜型、船期、价格等
↓
向船公司/庄家订舱
↓
船公司放舱，返回 SO / Booking Confirmation
实际业务中，往往是货代先把自己公司的空白托书模板发给客户，客户填写后再发回来；也有一些大客户直接用自己的固定 Excel/PDF 模板。(SZXSL56)
所以要注意一个概念：
托书通常不是船公司给客户的，而是客户给货代的“委托指令”。
托书大概长这样
下面这些就是比较典型的货代海运订舱委托书：
虽然不同公司模板差异很大，没有全国统一格式，但核心字段基本类似。(连连国际官网)
例如一张典型的 海运 FCL 托书 可以理解成：
订 舱 委 托 书
BOOKING INSTRUCTION
业务编号：SPS20260910001
Shipper / 发货人：
SHENZHEN ABC TECHNOLOGY CO., LTD.
深圳市XXXXXX
Consignee / 收货人：
ABC USA INC.
LOS ANGELES, CA, USA
Notify Party / 通知人：
SAME AS CONSIGNEE
--------------------------------------------
起运港 POL：
YANTIAN, SHENZHEN
目的港 POD：
LOS ANGELES
最终目的地：
LOS ANGELES, CA
运输方式：
☑ FCL □ LCL
箱型箱量：
2 × 40HQ
预计出运：
2026-09-20
贸易条款：
FOB SHENZHEN
运费条款：
☑ FREIGHT PREPAID
□ FREIGHT COLLECT
--------------------------------------------
货物信息：
品名：
FURNITURE / 家具
HS CODE：
9403.XXXX
包装：
560 CARTONS
毛重：
18,500 KGS
体积：
62 CBM
唛头：
ABC / LA / NO.1-560
--------------------------------------------
特殊要求：
□ 直航
☑ 可中转
□ 指定船公司
□ 指定船期
□ 危险品
□ 超重
□ 特种柜
要求船期：
ETD：2026-09-20
联系人：张三
电话：138XXXXXXXX
邮箱：xxxx@abc.com
委托单位：深圳ABC有限公司
日期：2026-09-10
你会发现它主要是在回答几个问题：
谁的货 → 运什么 → 从哪里走 → 运到哪里 → 什么时候走 → 多少货 → 用什么柜 → 有什么特殊要求。
通常至少会包含 Shipper、Consignee、Notify Party、POL、POD、柜型柜量、品名、件数、毛重、体积、预计出运日期以及特殊要求等。(中国音乐文学学会)
在你们货代系统里，可以把“托书”理解成什么？
如果你现在是在梳理货代 OMS / 客户工作台，我建议把它理解成：
托书 = 一票订单最早期的“运输需求输入单”。
典型业务链路可以设计成：
询价 → 报价 → 客户确认 → 提交托书 → 创建业务单 → 订舱 → 放舱 → 拖柜/入仓 → 报关 → 补料 → 出提单 → 到港/签收 → 结算
这里特别容易混淆的是：
托书 ≠ 补料 ≠ SO ≠ 提单。
简单记：
托书：客户告诉货代“我要怎么运”。 SO / 放舱单：船公司告诉货代/客户“舱位给你了，按这个去提柜/进仓”。 补料 SI：客户告诉货代“最终提单请按这些资料制作”。 提单 B/L：最终正式运输单证。
所以从系统设计角度，托书的数据很多是“计划值/初始值”，后续补料才可能变成最终提单数据。这点对你们以后设计货代 OMS 数据模型非常重要。