不灭的焱

货代业务系统——多运输方式详细功能规格版

一、系统总体设计原则

你们目前存在三种主要运输方式：

运输方式	整票模式	拼载模式
海运	FCL 整箱	LCL 拼箱
铁运	FCL 铁路整箱	LCL 铁路拼箱
卡航	FTL 整车	LTL 拼车

系统不建议分别建设“海运系统、铁运系统、卡航系统”。

更适合采用：

统一业务主流程 + 运输方式模板 + 装载模式模板 + 动态作业节点

统一主流程为：

客户 → 询价 → 产品方案 → 报价 → 订单 → 采购资源 → 运输执行 → 应收/应付 → 签收 → 结算 → 关闭

其中订单根据不同业务类型自动加载不同节点。

例如：

海运FCL

客户下单 → 订舱 → 提空箱 → 装箱 → 进港 → 报关 → 装船 → 开航 → 到港 → 清关 → 提柜 → 派送 → 还空箱

海运LCL

客户下单 → 送仓/提货 → 入仓 → 称重量方 → 拼箱 → 报关 → 装船 → 开航 → 到港 → 拆箱 → 清关 → 派送

铁运FCL

客户下单 → 提箱 → 装箱 → 进站 → 报关 → 班列发运 → 口岸换装/换轨 → 在途 → 到站 → 清关 → 提箱 → 派送 → 还箱

铁运LCL

客户下单 → 入仓 → 称重量方 → 集货 → 拼箱 → 进站 → 报关 → 班列发运 → 到站 → 拆箱 → 清关 → 派送

卡航FTL

客户下单 → 车辆安排 → 装车 → 出境报关 → 口岸 → 跨境运输 → 进口清关 → 目的国运输 → 签收

卡航LTL

客户下单 → 提货/送仓 → 入仓 → 称重量方 → 集货拼车 → 装车 → 出境报关 → 跨境运输 → 目的国分拨 → 派送 → 签收

所以系统底层必须区分四个概念：

概念	示例
Transport Mode 运输方式	海运 / 铁运 / 卡航
Load Mode 装载模式	FCL / LCL / FTL / LTL
Service Scope 服务范围	Door-Door、Door-CY、CY-CY、Warehouse-Door
Transport Leg 运输段	国内提货、国际干线、目的国运输

1. 客户开发到签约

1.1 市场与客户基础登记

1.1.1 目标市场与客户画像

功能描述

建立适合货代业务的客户画像体系，对潜在客户和正式客户进行分类，为销售开发、产品推荐、线路营销和客户经营提供依据。

系统实现

客户画像不能只维护“客户类型”，还需要维护客户实际物流特征。

建议包括：

维度	示例
客户类型	国内直客、国内同行、海外直客、海外同行
行业	汽配、机械、电商、家具、化工
主要贸易国家	俄罗斯、德国、波兰、美国
主要运输方式	海运、铁运、卡航
装载模式	FCL、LCL、FTL、LTL
主营线路	上海→Hamburg、西安→莫斯科、义乌→莫斯科
月均货量	20柜、300CBM、10车
货物属性	普货、带电、机械、食品等
服务需求	港到港、门到门、清关、仓储、派送
客户价值	A/B/C/D
客户潜力	高、中、低

系统可以根据历史询价及订单自动形成画像。

例如某客户过去6个月：

铁运占70%，卡航占25%，俄罗斯方向占90%。

系统自动标记：

俄罗斯线路 / 铁运核心客户 / 卡航潜力客户

1.1.2 线索获取、客户基础登记与查重

功能描述

将通过市场推广、展会、转介绍、互联网、销售自主开发等渠道获取的客户统一进入线索池，并防止同一家公司被多名销售重复开发。

系统实现

创建线索时录入：

企业名称、统一社会信用代码、英文名称、联系人、电话、邮箱、国家地区、来源、潜在运输需求。

系统进行自动查重：

公司名称查重、统一社会信用代码查重、手机号查重、邮箱域名查重。

发现类似客户时提示：

系统已存在“上海ABC国际贸易有限公司”，负责人：销售王某。

避免销售撞单。

货代特色信息

在线索阶段即可记录：

预计海运柜量、预计铁路柜量、卡航车量、LCL月均CBM、主要线路。

1.1.3 潜客培育与商机识别

功能描述

持续记录客户沟通情况，当客户产生明确运输计划或采购意向时形成正式商机。

系统实现

例如客户表示：

11月份预计有20个40HQ从上海出口德国。

系统创建商机：

运输方式：海运
装载方式：FCL
POL：Shanghai
POD：Hamburg
预计箱量：20×40HQ
预计成交日期：2026-11
预计业务收入：40万元

如果客户说：

每个月大约有80CBM散货从义乌到莫斯科。

则系统识别为：

卡航 + LTL。

商机阶段统一：

需求确认 → 方案设计 → 报价 → 商务谈判 → 待成交 → 赢单/输单

1.2 需求与准入条件

1.2.1 客户需求与询价受理

这是货代系统非常重要的入口。

不能只有一个通用“询价备注”。

系统需要根据运输方式和装载模式动态显示询价字段。

海运FCL询价

核心字段：

起运地、POL、POD、最终目的地、船期要求、箱型、箱量、货物名称、重量、是否危险品、是否需要拖车、报关、清关、派送。

例如：

上海 → Hamburg
2×40HQ
18吨/柜
10月25日前开船。

海运LCL询价

核心字段增加：

件数、包装类型、毛重、体积CBM、单件尺寸、计费吨RT。

例如：

120箱
8.6CBM
2.3吨。

系统自动计算：

W/M计费吨。

铁运FCL

记录：

始发站、目的站、箱型、箱量、班列要求、预计装箱时间、境外目的地。

铁运LCL

增加：

件数、CBM、重量、拼箱仓、预计送仓日期。

卡航FTL

记录：

起运地、目的地、车辆类型、整车数量、货重、装车时间、口岸要求。

卡航LTL

重点记录：

件数、重量、CBM、托盘数量、单件尺寸及是否需要提货。

系统根据：

运输方式 + 装载模式

加载对应询价模板。

1.2.2 客户准入检查

功能描述

在正式承接业务前，对客户是否具备合作资格进行检查。

系统检查：

企业主体是否有效、是否已完成实名认证、是否处于黑名单、是否存在严重逾期、是否涉及制裁或高风险国家、是否允许当前货物类型。

例如：

客户要求运输危险化学品。

系统发现：

当前产品只支持普通货物。

自动提示：

该货物不符合当前产品承接条件。

1.2.3 信用、账期与额度审批

系统给客户建立：

付款方式、账期、信用额度、币种及额度使用情况。

例如：

账期：月结30天
信用额度：500,000元
当前未收：380,000元
剩余额度：120,000元

新订单预计应收：

180,000元。

系统提示：

预计超信用额度60,000元，需要信用审批。

对于同行客户、长期客户、大客户可以设置不同信用策略。

1.3 方案报价与客户确认

1.3.1 方案设计与成本测算

这是整个系统的核心能力之一。

系统中的“运输方案”建议设计成多个 Transport Leg。

例如：

苏州 → Munich 海运FCL：

运输段	服务
Leg 1	苏州工厂→上海港拖车
Leg 2	上海出口报关
Leg 3	Shanghai→Hamburg海运
Leg 4	Hamburg进口清关
Leg 5	Hamburg→Munich卡车派送

每个运输段都对应：

供应商、成本、时效、费用项目。

海运FCL成本

例如：

Ocean Freight
THC
DOC
Seal Fee
拖车费
报关费
目的港费用
清关费
派送费。

LCL成本

需要支持：

按CBM、RT、公斤、票计费。

例如：

海运费：

USD 40 / RT。

仓库操作：

RMB 80 / CBM。

报关：

RMB 500 / 票。

卡航FTL

通常可能按：

车 / 趟

报价。

卡航LTL

可能按：

KG、CBM、托盘或者取大计费。

系统必须具备统一计费引擎。

不能把费用全部写成：

“金额”。

费用至少需要：

计费单位 + 数量 + 单价 + 最低收费 + 币种

1.3.2 客户报价编制与审核

报价单支持多个运输方案。

例如客户询：

上海 → 莫斯科。

可以同时返回：

方案A：铁运FCL，18天。

方案B：卡航FTL，12天。

方案C：海运+卡车，35天。

销售可以在一个报价中提供多个方案。

报价显示：

运输方式、线路、时效、班期、服务范围、Free Time、费用明细、报价有效期及特别说明。

系统自动计算：

销售收入、预计成本、预计毛利、毛利率。

按照公司规则控制价格。

例如：

毛利率≥15%：自动通过。

10%-15%：销售经理审批。

<10%：业务总监审批。

1.3.3 报价沟通、修订与客户确认

报价不能覆盖原版本。

系统应保存：

V1、V2、V3……

例如：

V1：USD 2,500。

客户议价后：

V2：USD 2,400。

系统保留完整报价历史。

客户确认后，将：

客户、线路、货物、服务、销售价格、运输方案

直接带入订单。

1.4 合作确认与正式启用

1.4.1 合同或委托评审与确认

支持两种合作模式：

长期框架合同以及单票业务委托。

系统维护：

服务范围、运输责任、价格规则、账期、保险责任、赔偿上限、有效期等。

订单创建时自动读取有效合同。

1.4.2 客户资料完善与正式启用

将潜在客户转为正式客户主数据。

完成：

结算主体、开票主体、账期、额度、联系人、默认币种、销售负责人等资料。

客户状态：

潜在 → 待准入 → 已启用 → 暂停 → 冻结 → 终止

1.4.3 成交交接与转订单

销售成交后不是简单“结束商机”。

系统执行：

商机 → 客户确认报价 → 订单草稿

自动带入：

运输方式、装载模式、服务范围、货物、线路、报价以及特殊要求。

操作人员只补充真正执行所需的数据。

2. 供应商寻源到合作

2.1 资源需求与候选登记

2.1.1 采购需求与资源缺口识别

系统根据业务需要发现资源缺口。

例如：

缺上海→Hamburg海运舱位。

缺西安→莫斯科铁路舱位。

缺义乌→莫斯科LTL卡航资源。

缺德国Hamburg目的港拖车资源。

需求可以来源于：

客户询价、产品建设、订单执行以及供应商退出。

2.1.2 供应商寻源与接洽

根据服务能力寻找供应商。

系统供应商能力应采用多标签设计。

例如：

某供应商拥有：

海运订舱、德国清关、德国拖车。

另一个供应商：

卡航FTL、卡航LTL、俄罗斯清关。

以后询价时系统根据能力自动筛选。

2.1.3 候选供应商登记与查重

记录：

企业信息、服务国家、运输方式、装载模式、优势线路、联系人、资质。

同样通过：

企业名称、税号、银行账户

进行查重。

2.2 评估准入与合作确认

2.2.1 初步询价与能力评估

评估不能只看价格。

例如卡航供应商：

同时记录：

车辆资源、车型、口岸能力、俄罗斯境内运输能力、FTL/LTL能力、时效、保险。

海运供应商则记录：

船东资源、优势航线、舱位稳定性、Free Time以及目的港代理。

2.2.2 供应商尽调与准入

系统建立供应商准入清单：

资质、信用、保险、服务能力、价格能力、历史案例和风险。

审核通过才允许进入正式供应商池。

2.2.3 综合比选与合作谈判

同一个产品可以存在多个供应商。

例如：

上海→Hamburg 40HQ：

A供应商：USD1800，31天。

B供应商：USD1900，27天。

C供应商：USD1750，35天。

系统同时展示：

价格、时效、账期、Free Time、历史准点率、异常率。

2.2.4 合同或合作条款评审与确认

合同中不能只维护一个“合作价格”。

应支持关联：

运输方式、线路、装载模式、费用项目、计费单位、账期及有效期。

2.3 启用与持续评价

2.3.1 供应商资料完善与正式启用

供应商启用后成为可采购资源。

系统控制：

只有“已启用”的供应商才能：

进入产品成本、订单采购及应付费用。

2.3.2 供应商绩效评价与关系维护

自动从订单产生绩效：

报价响应速度、准时率、取消率、异常率、投诉率、索赔率。

还可以分别统计：

海运业务表现、铁路业务表现、卡航业务表现。

避免一个供应商某条线路表现不好影响所有业务判断。

2.3.3 供应商续约、限用与退出

供应商状态：

候选 → 已准入 → 合作中 → 限制使用 → 暂停 → 退出

例如：

某卡航供应商整体可以继续合作，但：

俄罗斯某条线路暂停使用。

因此建议支持：

供应商级限制以及线路级限制。

3. 产品与价格管理

这是你们系统中非常核心的一块。

建议把“产品”理解成：

公司能够标准化销售的一套运输服务方案。

3.1 产品设计与资源成本

3.1.1 产品体系与基础规则设置

建议产品编码至少关联：

运输方式 + 装载模式 + 线路 + 服务范围

例如：

SEA-FCL-SHA-HAM-CYCY
SEA-LCL-SHA-HAM-CFS-CFS
RAIL-FCL-XIAN-MOW
ROAD-FTL-YIWU-MOW
ROAD-LTL-YIWU-MOW

产品基础规则维护：

货物限制、最大重量、最小计费、适用箱型、适用车型、计费单位、默认节点。

3.1.2 产品草稿与服务方案设计

创建产品时系统自动加载对应模板。

海运FCL产品

需要：

POL、POD、船司、航线、箱型、班期、航程、Free Time。

海运LCL产品

增加：

起运仓、目的仓、截仓时间、最低计费、CBM/RT计费规则。

铁运FCL

需要：

始发站、目的站、班列、箱型、班期、运输时效、口岸。

铁运LCL

增加：

集货仓、截仓日、拼箱周期和最小计费重量/体积。

卡航FTL

需要：

起点、目的地、口岸、车辆类型、最大载重、整车时效。

卡航LTL

需要：

集货仓、班期、截货时间、KG/CBM计费规则、目的国分拨区域。

3.1.3 供应资源确认与成本采集

一个产品可以组合多个供应商。

例如海运Door-Door：

国内车队 + 报关行 + 订舱代理 + 德国代理 + 德国车队。

系统维护每一段成本。

形成：

Product Cost Sheet 产品成本表

3.2 定价发布与生命周期

3.2.1 售价、加价及销售规则设置

不同产品允许不同定价方法。

例如：

FCL：

每柜成本 + 每柜固定毛利。

LCL：

每RT成本 + 每RT加价。

FTL：

每车成本 + 每车毛利。

LTL：

每KG/CBM销售价格。

还应支持：

最低收费。

例如：

EUR 80/CBM，最低3CBM。

即：

1CBM也按3CBM计费。

3.2.2 产品与价格审核及可售发布

产品经过：

资源确认 → 成本确认 → 售价确认 → 审批 → 发布。

只有发布产品才能被销售搜索。

3.2.3 资源、成本及产品版本维护

价格不能直接覆盖。

例如：

October Rate V1。

November Rate V2。

历史订单继续使用历史价格。

新订单自动采用当前有效价格。

3.2.4 产品暂停、失效与下架

支持：

正常销售、临时停卖、舱位紧张、价格待确认、已过期、已下架。

例如：

某铁路班列临时暂停。

产品立即变成：

暂停销售

防止销售继续报价。

3.3 标准与非标询报价支持

3.3.1 标准产品查询与内部报价支持

销售输入：

运输方式、装载模式、起点、终点、出货日期以及货量。

例如：

卡航
LTL
义乌→莫斯科
8CBM
1.2吨

系统返回：

产品A：10-12天，¥X/CBM。

产品B：12-15天，¥X/KG。

并自动计算预计总价。

3.3.2 非标询价与方案成本支持

如果标准产品不存在：

自动转非标询价。

例如：

俄罗斯某偏远城市。

系统拆成：

标准卡航干线 + 非标俄罗斯境内派送。

产品部门询价后重新组合运输方案。

4. 订单到交付

这是整个货代系统最重要的业务域。

4.1 订单承接与履约准备

4.1.1 客户订单接收与草稿登记

订单统一采用主订单模型。

核心字段：

订单号、客户、运输方式、装载模式、贸易条款、服务范围、货物、起点、终点、预计时间。

然后根据业务类型加载扩展字段。

FCL订单

增加：

箱型、箱量。

LCL订单

增加：

件数、毛重、体积、包装方式。

FTL订单

增加：

车型、车辆数量、重量。

LTL订单

增加：

件数、托盘、重量、CBM。

4.1.2 承接评审与初步资源核验

系统检查：

客户信用、产品有效性、价格有效期、货物是否可承运、供应商资源以及预计毛利。

例如：

40HQ货重30吨。

产品最大允许：

26吨。

系统自动提示：

超重，不符合产品承运条件。

4.1.3 承接确认与履约计划

订单确认后根据业务类型生成履约节点。

例如海运FCL自动生成：

订舱、提箱、装箱、进港、报关、开航、到港、清关、提柜、派送、还柜。

卡航LTL自动生成：

提货、入仓、称重量方、集货、拼车、发车、口岸、清关、分拨、派送。

4.1.4 订舱、订车及服务采购委托确认

统一建立：

Service Booking / Purchase Booking

不同业务表现不同。

海运：

Booking订舱。

铁路：

班列舱位预订。

卡航FTL：

订车。

卡航LTL：

订舱位/配载空间。

同时还可能采购：

拖车、报关、仓库、清关、末端派送。

一个订单允许存在多个采购委托。

4.1.5 保险需求确认与承保核实

记录：

是否投保、保额、货值、保险费、保险公司及保单。

系统可根据：

货值、货物类型、线路

提示是否建议保险。

4.1.6 作业启动条件确认

系统在实际作业前检查关键条件。

例如：

客户是否确认订单。

预付款是否到账。

订舱是否成功。

报关资料是否齐全。

箱号/车辆是否确定。

未满足必要条件不能进入下一环节。

4.2 国内实物作业分支

4.2.1 提货或客户送仓安排

支持两种方式：

客户送仓。

上门提货。

系统创建提货任务：

地址、联系人、时间、车辆、供应商。

对于LCL/LTL尤其重要，因为多个客户货物可能进入同一个集货仓。

4.2.2 入仓核验与收货登记

仓库收货记录：

实际件数、重量、CBM、包装状态、唛头。

并与订单申报数据比较。

例如：

客户申报：

8CBM。

仓库实测：

9.6CBM。

系统自动标记：

计费数据发生变化

并通知销售/计费人员。

4.2.3 提货、装车与装箱作业

根据不同模式处理。

FCL：

提空箱 → 客户装箱 → 封箱 → 记录箱号/封号。

FTL：

车辆到厂 → 装车 → 记录车辆/司机。

系统记录：

实际装货时间、箱号、封号、车牌、司机及照片。

4.2.4 仓内处理、打托与拼载作业

这是LCL/LTL的核心功能。

系统需要支持：

多个订单货物 → 一个拼载批次。

例如：

订单A：3CBM。

订单B：8CBM。

订单C：12CBM。

组合成：

Consolidation CONS-001

再装入：

1×40HQ

或者：

1辆卡车。

所以系统必须增加：

拼载批次 Consolidation

这个业务对象。

关系为：

多个客户订单
↓
多个货物批次
↓
一个拼载批次
↓
一个集装箱 / 一辆卡车 / 一个铁路箱。

这是拼箱和拼车系统区别于简单订单系统的关键。

4.2.5 国内运输与口岸交接

管理：

工厂→仓库。

仓库→港口。

仓库→铁路站。

仓库→口岸。

记录：

承运商、车辆、司机、计划到达以及实际到达。

4.2.6 出口申报、查验与放行跟踪

建立统一关务任务。

一个订单可以：

单独报关。

也可能多个拼箱订单分别报关后共同拼载。

记录：

报关单号、报关状态、查验状态以及放行时间。

4.3 单证与截点管理

4.3.1 单证资料收集与审核

建立订单单证中心。

例如：

Invoice、Packing List、报关资料、合同、提单补料、铁路运单资料、CMR等。

不同运输方式配置不同资料清单。

系统显示：

已齐全 / 缺失 / 待审核 / 已审核。

4.3.2 补料提交与截点跟踪

海运尤其需要管理：

SI Cut-off
VGM Cut-off
CY Cut-off
Customs Cut-off。

铁路和卡航也可以统一成：

业务截点 Cut-off

例如：

铁路截仓时间。

卡航截货时间。

系统倒计时提醒：

还有24小时截单。

还有6小时截仓。

避免错过班期。

4.3.3 提单或运单确认、签发与放单

不同运输方式加载不同单据。

海运：

MBL / HBL。

铁路：

铁路运单。

卡航：

CMR或运输单据。

系统管理：

草稿 → 客户确认 → 正式签发 → 放单。

海运进一步支持：

正本提单、电放、Sea Waybill。

4.4 国际运输与目的地提货

4.4.1 国际干线装运与在途跟踪

统一建立：

Transport Leg + Milestone

不同运输方式采用不同节点模板。

海运节点

Booking Confirmed
Container Picked Up
Gate In
Customs Released
Loaded on Vessel
Departed
Transshipment
Arrived
Discharged。

铁运节点

进站
报关放行
装列
发车
口岸到达
换装/换轨
出境
境外在途
到达目的站。

卡航节点

装车完成
出发
到达口岸
出口放行
出境
境外运输
进口清关
目的国在途。

这样客户前端都可以统一显示：

当前节点 + 最新更新时间 + ETA

4.4.2 到达前准备与进口清关跟踪

货物即将到达目的国时：

自动生成到港/到站准备任务。

例如：

提前向客户索取清关资料。

通知海外代理。

确认进口税费。

确认派送地址。

4.4.3 目的地放货与提货条件核验

正式放货前检查：

客户是否满足放货条件。

例如：

运费是否支付。

正本提单是否收回。

电放是否完成。

进口清关是否放行。

如不满足：

系统显示：

Hold 禁止放货。

4.4.4 海外提货与末端运输

FCL：

码头提柜 → 派送。

LCL：

CFS拆箱 → 提货 → 派送。

铁路：

目的站提箱/提货。

卡航：

进口清关后车辆继续运输或目的国重新分拨。

统一形成：

Delivery Task。

4.5 交付验收与履约关闭

4.5.1 海外仓收货、拆托分拣及库存作业

如果目的地进入海外仓：

支持：

入库、拆柜、拆托、分拣、上架、库存。

一个国际运输订单可以拆成多个海外仓库存批次。

4.5.2 海外仓出库订单执行

支持：

整托出库、整箱出库、拆零出库、FBA转运等。

库存货物可以继续产生多个派送订单。

4.5.3 交付预约、派送与凭证回传

记录：

预约号、预约时间、目的地、司机、车辆。

签收后上传：

POD、签收单、照片。

系统将订单状态更新：

Delivered 已交付。

4.5.4 设备归还与凭证核验

这一节点对FCL尤其重要。

例如：

海运集装箱还空箱。

铁路箱还箱。

记录：

还箱地点、还箱时间、设备交接单。

并计算：

Detention是否产生。

4.5.5 履约验收、资料归档与关闭

业务关闭需要满足：

运输完成、签收完成、单证齐全、异常处理完成、应收确认、应付确认。

完成后：

Operational Closed

财务最终结算完成：

Financial Closed

4.6 订单变更与取消

4.6.1 订单变更评估与再次确认

订单变更必须保留版本。

例如：

2×40HQ改成3×40HQ。

海运改铁路。

目的地Hamburg改Rotterdam。

系统自动重新检查：

价格、成本、供应商、时效和毛利。

必要时重新报价。

4.6.2 订单取消与已发生成本处理

订单取消不能直接删除。

系统检查已经发生：

订舱取消费、拖车空驶费、仓储费、报关费等。

确认：

哪些由客户承担，哪些由公司承担。

之后关闭订单。

5. 计费到收款

5.1 结算条件与预收分支

5.1.1 客户结算条件与计费依据确认

订单自动继承：

客户账期、报价、合同、币种及税率。

计费依据应支持：

箱、车、票、CBM、RT、KG、托盘、天。

5.1.2 预收或阶段收款通知

部分客户可以要求：

订舱前付款。

出运前付款。

放货前付款。

系统根据付款条件生成：

阶段收款任务。

5.1.3 预收到账登记与可用金额确认

财务登记预收款后：

系统更新客户可用预收余额。

订单可以使用预收余额抵扣应收。

5.2 应收归集与客户对账

5.2.1 应收费用生成、补录与审核

订单费用来源：

报价自动生成、实际重量体积重新计算、额外服务费用、异常费用。

例如LCL：

申报8CBM。

实际9.6CBM。

系统根据实际数据重新计算：

应收运费。

但不能自动直接覆盖，需要形成：

费用变化待确认。

5.2.2 应收费用确认

费用状态：

草稿 → 待审核 → 已确认 → 已对账 → 已开票 → 已核销。

已确认费用原则上不允许直接修改。

调整需使用费用调整单。

5.2.3 账单生成与客户对账

支持：

单票对账。

月度对账。

项目对账。

多个运输方式可以进入同一个客户账单。

5.3 开票收款与核销

5.3.1 开票申请、校验与交付

从已确认账单选择费用开票。

发票关联：

订单、费用、客户以及结算主体。

5.3.2 收款登记与款项认领

银行到账后：

财务登记收款。

如果付款信息无法自动识别客户：

进入“待认领款项”。

销售或财务认领后再核销。

5.3.3 应收核销与预收冲抵

支持：

一笔收款核销多个订单。

多笔收款核销一个账单。

预收款冲应收。

5.4 信用监控与结算例外

5.4.1 信用额度与交易条件监控

信用额度占用建议根据：

已确认未收应收 + 在途订单预计应收

计算。

而不是只看已经开票金额。

这样才能更早发现风险。

5.4.2 到期提醒与逾期催收

系统形成：

应收账龄。

并根据：

销售、客户、公司主体

形成催收任务。

5.4.3 应收差异、退款与坏账处理

通过：

费用调整、退款、坏账审批

处理差异。

禁止财务人员直接修改历史订单金额。

6. 采购结算到付款

6.1 采购依据与预付分支

6.1.1 采购委托与结算条件记录

采购不能只关联供应商。

必须关联：

订单、运输段、供应商、采购服务及费用依据。

例如：

ORD001
国际海运段
供应商A
40HQ×2
USD1800/柜。

6.1.2 预付款申请、审批与执行

例如：

铁路舱位需要提前付款。

船公司要求预付。

卡航供应商要求发车前支付50%。

系统支持：

预付申请 → 审批 → 付款 → 预付余额。

6.2 成本应付与供应商对账

6.2.1 服务发生与履约凭证核验

成本确认前检查：

服务是否真实发生。

例如：

拖车是否完成。

仓库是否完成入库。

卡航是否发车。

海运是否开航。

降低虚假应付风险。

6.2.2 成本归集与按规则暂估

如果实际账单未到：

根据采购价或者历史成本暂估。

订单利润同时显示：

预计毛利

和：

实际毛利

这是货代系统非常重要的功能。

6.2.3 应付费用审核与确认

供应商应付状态：

草稿 → 待审核 → 已确认 → 已对账 → 待付款 → 已付款。

6.2.4 供应商对账与差异核实

例如某车队月度100票业务：

系统自动汇总。

发现供应商账单比系统多：

等待费2,000元。

产生：

对账差异

业务人员确认是否真实发生。

6.3 单据付款与核销

6.3.1 发票或结算单据接收与校验

校验：

发票主体、金额、税率及对应订单。

国外供应商没有中国发票时：

允许使用国外Invoice等结算凭证。

6.3.2 付款申请与审批

自动带出：

供应商、账期、到期金额、发票、订单、费用。

避免人工重复填表。

6.3.3 付款执行、应付核销与预付冲抵

付款完成后：

核销AP。

如果之前预付：

自动冲减预付余额。

6.4 结算差异与退款

6.4.1 应付争议、调整与供应商退款

处理：

多收费、重复收费、取消费争议、价格不一致、供应商退款。

所有调整均保留原记录。

7. 异常到关闭

异常中心应与订单节点高度结合。

7.1 异常处置与事件关闭

7.1.1 异常或客诉识别与登记

系统既支持人工登记，也支持自动产生异常。

例如：

海运：

甩柜、延船、查验、Detention。

铁路：

班列延误、口岸拥堵、换装延迟。

卡航：

车辆故障、口岸堵塞、司机异常。

LCL/LTL：

少货、多货、破损、错装、漏装。

7.1.2 影响评估、分级与处理负责人分派

系统根据：

客户等级、延误时间、预计损失、货值

自动建议异常等级。

例如：

P1 / P2 / P3 / P4。

7.1.3 紧急处置与相关方通知

重大异常自动通知：

操作负责人、销售、客服、主管。

可以生成：

客户通知模板。

7.1.4 协同处置与进度跟踪

一个异常允许拆多个任务。

例如：

海运甩柜：

产品重新订舱。

操作协调新船期。

销售通知客户。

财务确认是否增加费用。

7.1.5 处理结果验收与事件关闭

关闭前检查：

解决方案完成、客户已通知、费用已确认、相关任务已完成。

7.2 调查取证与索赔赔付

7.2.1 证据保全、原因调查与责任认定

附件支持：

照片、POD、邮件、运输单据、仓库记录。

责任对象：

内部部门、员工、供应商、客户、不可抗力。

7.2.2 保险报案与责任方索赔跟踪

如果投保：

直接从异常转保险理赔。

如果供应商责任：

建立供应商索赔。

7.2.3 客户赔付、追偿及结算处理

例如：

赔客户10,000元。

供应商最终承担8,000元。

公司承担2,000元。

系统分别形成：

客户赔付和供应商追偿。

最终准确影响订单利润。

7.3 根因改进与效果验证

7.3.1 根因分析与改进措施制定

系统要求重大异常填写：

直接原因、根本原因及改进措施。

例如：

LCL货物漏装。

直接原因：

仓库装柜遗漏。

根因：

拼载清单没有扫描复核。

改进措施：

装柜时必须逐票扫码确认。

7.3.2 改进实施、效果验证与任务关闭

改进不是填写一段说明就结束。

系统生成：

责任人、完成时间、验证人。

验证完成后才真正关闭改善事项。

8. 经营管理与决策

8.1 治理与经营目标

8.1.1 主数据与指标口径治理

需要统一管理：

客户、供应商、港口、铁路站、口岸、仓库、城市、国家、船公司、箱型、车型、费用项、币种、运输方式、装载模式。

特别建议建立统一地点 Location 模型。

因为你们同时存在：

港口、铁路站、仓库、城市、口岸。

不要分别用大量文本字段。

统一形成：

Location Master

例如：

Hamburg Port
Hamburg City
Hamburg CFS

分别作为独立地点。

8.1.2 经营目标与预算制定

预算支持按：

公司、部门、销售、运输方式、产品、线路。

例如：

2027年目标：

海运FCL 3,000TEU。

海运LCL 20,000CBM。

铁路FCL 1,500柜。

卡航FTL 2,000车。

卡航LTL 15,000CBM。

8.2 数据质量与持续预警

8.2.1 业务数据采集与质量检查

系统自动检查：

订单是否缺箱号。

FCL是否缺柜号。

海运是否缺船名航次。

LCL是否缺实际CBM。

卡航是否缺车辆信息。

应收是否缺结算对象。

避免垃圾数据进入BI。

8.2.2 滚动预测与经营偏差预警

结合：

商机 + 已报价 + 在手订单 + 历史数据

预测未来货量。

例如：

11月份预计俄罗斯方向：

铁路FCL 320柜。

现有舱位：

250柜。

系统提示：

预计缺口70柜。

8.3 多维经营分析

8.3.1 客户经营分析

客户维度展示：

询价数、成交率、订单数、TEU、CBM、车数、收入、毛利、应收以及异常。

这样不同业务可以同时分析。

8.3.2 产品与线路经营分析

线路不仅分析收入。

还要分析：

询价量、成交率、货量、采购成本、毛利率、运输时效和异常率。

例如：

义乌→莫斯科卡航LTL

可能：

销售额高，但毛利低且异常多。

系统可以判断是否值得继续重点推广。

8.3.3 供应商绩效汇总分析

按照：

供应商 + 线路 + 服务类型

分析。

例如同一家供应商：

俄罗斯卡航很好。

欧洲卡航很差。

因此不能只给供应商一个总分。

8.3.4 履约与服务质量分析

统一采用：

计划时间 vs 实际时间

计算。

例如：

准时提货率。

准时开航率。

铁路准时发车率。

卡航准时到口岸率。

准时签收率。

8.3.5 收入、成本、毛利与现金流分析

支持按：

海运/铁运/卡航。

FCL/LCL/FTL/LTL。

客户。

线路。

销售。

公司。

产品。

分别统计：

收入、成本、毛利、毛利率。

8.4 决策执行与复盘

8.4.1 经营决策与行动分派

管理层从报表发现问题后可以直接生成任务。

例如：

上海-Hamburg FCL毛利率连续3个月下降。

创建：

“重新谈判海运采购价格”。

负责人：

采购经理。

完成时间：

10月31日。

8.4.2 效果复盘与计划调整

任务完成后继续跟踪指标。

例如供应商重新议价后：

平均成本：

USD1900 → USD1750。

系统显示：

毛利率：

12% → 17%。

形成真正的：

数据发现问题 → 决策 → 执行 → 再验证

闭环。

九、货代系统建议增加的核心业务对象

为了真正支持你们的多业务场景，系统底层建议至少存在以下核心对象。

业务对象	作用
Customer	客户
Lead	线索
Opportunity	商机
RFQ	客户询价
Product	标准运输产品
Rate	运价/成本
Quotation	客户报价
Order	客户订单
Shipment	一次实际运输
Transport Leg	运输段
Cargo	货物
Container	集装箱
Vehicle	车辆
Consolidation	拼箱/拼车批次
Booking	订舱/订车
Milestone	运输节点
Document	单证
Supplier	供应商
Purchase Order	采购委托
AR	应收
AP	应付
Statement	对账单
Receipt	收款
Payment	付款
Exception	异常
Claim	索赔

其中尤其重要的是：

Order ≠ Shipment ≠ Consolidation。

例如海运LCL：

客户A订单
客户B订单
客户C订单
↓
进入同一个 Consolidation 拼箱批次
↓
装进一个40HQ
↓
形成一次国际 Shipment。

卡航LTL同理：

多个客户订单
↓
拼车批次
↓
一辆跨境卡车。

这个模型如果一开始没有设计好，后面做拼箱、拼车业务时会非常痛苦。

十、最终推荐的系统业务架构

从用户操作角度，系统建议最终形成：

系统模块	主要能力
工作台	待办、预警、今日业务
CRM	线索、客户、商机、跟进
询报价	RFQ、方案、报价、审批
产品中心	海运/铁路/卡航产品
运价中心	FCL/LCL/FTL/LTL价格
订单中心	客户订单
拼载中心	拼箱、拼车、集货
运输执行	提货、仓储、报关、干线、清关、派送
节点跟踪	Shipment与Milestone
单证中心	提单、运单、报关及业务单证
供应商中心	寻源、准入、合同、绩效
费用中心	应收、应付、利润
结算中心	对账、发票、收付款、核销
异常中心	异常、客诉、索赔
BI经营中心	客户、线路、产品、供应商、利润分析
基础资料	地点、港口、站点、箱型、车型、费用项
系统配置	权限、审批流、节点模板、计费规则

整个系统最关键的三个技术/产品设计思想是：

第一，统一主订单。
海运、铁路、卡航共用 Order 主模型，差异信息通过业务扩展模型处理，而不是建立三张完全不同的订单表。

第二，节点模板化。
根据“运输方式 + 装载模式 + 服务范围”自动产生履约节点。例如 SEA+FCL+Door-Door 和 ROAD+LTL+Door-Door 使用完全不同的节点模板。

第三，引入拼载批次。
FCL/FTL通常是“一票订单对应一个或多个柜/车”；而LCL/LTL本质是“多票订单 → 拼载批次 → 柜/车 → 国际运输”。因此 Consolidation 应成为独立的核心业务对象，而不能只在订单里增加一个“是否拼箱”的字段。

这三个基础模型设计正确以后，你们的 海运FCL/LCL、铁路FCL/LCL、卡航FTL/LTL 就可以在一套系统里统一管理，同时又保留每种业务自己的专业操作流程。