报价与定价
报得快不难，报得住才难
LTL 的钱大多不是在报价那一刻丢的，是在 class 报错、尺寸没进位、住宅没判出来之后，由承运商 rebill 拿走的。
两层加成
// 承运商维度与客户维度分开配置
第一层：承运商加成
按承运商与运输模式分别设定，用于抹平各家的成本口径差异。
第二层：客户等级
定价模板 + 客户专属规则，按 LTL / 整车 / 拖柜 / 小包裹分模式生效。
卖价硬地板
无论规则怎么配，卖价不会低于成本 —— 保底逻辑写在定价服务里，不靠人工复核。
把 rebill 挡在提交之前
每一项都对应一类真实发生过的重开账单
① 品名 · 尺寸 · 重量 · 件数
厘米/公斤自动换算并向上取整，与承运商计费口径一致
② 算密度 → 定 class
缺件数就算不出真实密度 —— 缺了会拦住，不猜一个
③ NMFC 校验
只认真实编码库里的码；同一品名分组码由客户挑，挑完锁定 class
④ 附加费与限制
住宅 · 预约 · 尾板 · 超长超重 · 可否堆叠 —— 该传的一个不漏
⑤ 多承运商并发询价
同一份货件描述发给每一家，回来的价才可比
⑥ 报出去的价
两层加成后的售价；客户只看到这一个数
// 前四步都是为了不返工：分类或附加费漏了，承运商会在提货之后重新计费，那张账单是事后来的 —— 那时价格已经报给客户了。
NMFC 与 freight class
内置 8,256 条 NMFC 条目与注释库，密度换算按标准档位取值。查不到就留空，绝不生成一个看起来像真的编码 —— 编造出来的码最终一定变成 rebill。
尺寸与重量归一
公制换算后统一向上取整到英寸与磅，前后端同一套逻辑，入库值与承运商计费口径一致。
可堆叠与 linear feet
是否可堆叠直接决定货物占多少位，进而决定计费。这个字段必须原样传到承运商 —— 漏传就是静默低估，等 rebill 回来才发现。系统在提交前把它校验掉。
住宅与附加费
地址分类先于报价完成，住宅、预约、尾板等按承运商各自规则决定是必带还是可选，而不是统一处理。
可追溯
事后要能说清"当时为什么是这个价"
每次报价保存承运商原始返回与定价快照：用了哪家、哪条规则、加成多少、当时的燃油与附加费。对账出现分歧时，翻的是记录而不是记忆。
或者，直接问
微信扫码聊
不用留资料，先问一句也行
想先自己试算一下： 工具台 →