口岸换装不丢柜：TMS柜号与车号绑定建模

在中俄TIR运输里，柜子很少真的「丢」在路上，更多是丢在系统里。二连浩特、满洲里、霍尔果斯这些口岸，中方车辆与俄方（蒙方）车辆不能直达，集装箱必须在监管场所卸下、再装到另一辆车上。就在这一次换装里，柜号与车号的对应关系发生断点：如果TMS只在运单上留一个「车牌号」字段，操作员把车牌改掉，旧关系被覆盖，这个柜在系统里就再也追不回来。

一、先纠正一个建模误区

很多TMS把「柜号」和「车号」当成同一条运单记录上的两个字段。这种设计的隐含假设是：一票货、一个柜、一辆车、从头到尾不变。而跨境换装恰恰打破了这个假设——一车可能装两柜，一柜可能换三次车，牵引车与挂车会分离，俄方牌照与中方牌照是两套体系，封志还要在换装时更换。

正确的认知是：柜是主档，车是资源，二者的关系是一段有起点、有终点、有凭证的记录，也就是「事件」。

二、三层模型：主档、单据、事件

• 主数据层：集装箱主档（柜号、箱型箱量、自重、箱属方、封志号历史），车辆主档（牵引车号、挂车号、VIN、境外牌照、TIR证号、承运商、司机、核载）。
• 业务单据层：运单、TIR证登记单、换装作业单、出境申报关联单。单据承接商务与合规信息，不直接持有「当前车号」。
• 事件流水层：柜车绑定事件表，字段包括柜ID、车ID、绑定时间、解绑时间、事件类型（装车、卸车、换装、甩挂、临时移箱）、作业地点、操作人、新老封志号、换装单号、现场照片。这张表只增不改。

有了事件流，「这个柜现在在哪辆车上」是算出来的，不是填出来的。任何时候都能回答：3月14日06:20，这个柜在中方挂车上还是已转到俄方车上。责任界定、保险理赔、滞留费分摊，靠的都是这句话。

三、三条硬约束，缺一条就会漏柜

• 唯一性：同一柜同一时刻只能存在一条有效绑定（以「解绑时间为空」建唯一索引）；同一车可绑多柜，但系统要按轴载与容积做超限提示。
• 原子性：一次换装必须在一个事务里完成「解绑旧车+绑定新车」，不允许出现只解不绑的中间态。
• 禁止直改：严禁在运单上直接修改车牌号。换装动作只能通过换装作业单发起，这是杜绝丢柜成本最低的一条规则。

四、换装作业单：把一次换装做成可审的事务

换装作业单是现场与系统之间唯一的入口。单头记录作业场地、作业时间、作业班组、承运商；明细行记录柜号、原车号、新车号、原封志、新封志、异常码。单据经场站负责人审核通过后，系统才生成绑定与解绑事件，并同步刷新柜与车的状态。这样每一次关系变更都有单据号、有操作人、有审核痕迹，事后复盘不用再翻微信群。

五、采集与校验：让柜号不可能输错

• 柜号强制按ISO 6346校验：4位箱主码、6位序号、1位校验码，输错一位系统当场拦截，杜绝「看着像」的错号。
• 手持PDA扫码、闸口OCR、地磅联动、电子铅封多源交叉，扫码为主、人工为辅，关键节点双人复核。
• 不具备扫码条件的场地，最低要求是换装单必填柜号与新老封志号，照片留档。

六、状态机与预警：把丢柜变成可预警的异常

柜的状态（在场、换装中、在途、已出境、已交付）与车的状态（空闲、在途、在场、维修）都必须由事件驱动跳转。基于状态可配置这些预警：有柜无车、有车无柜、换装超过设定时长未闭环、封志变更未登记、TIR证登记车辆与当前绑定车辆不一致、口岸滞留超过阈值。预警按票推送到具体责任人，而不是群发。

七、与单证、计费联动，避免重复劳动

TIR证、CMR、报关单、装箱单统一以柜号作为主键关联，车号只作为运输资源维度存在于事件中。换车不影响单证主体，单证不用重做；换装费、滞留费、二次装卸费按柜维度自动归集，对账时每一笔费用都能追到具体的换装事件。

八、落地顺序与验收指标

建议顺序是：先建柜与车的主档并清洗存量柜号，再上线换装作业单与绑定事件，然后接扫码与OCR，最后做预警与计费联动。验收盯四个指标：柜车绑定完整率（目标99%以上）、换装单据当日闭环率、异常柜平均找回时长、口岸平均滞留小时数。

换装环节的信息断点，用Excel台账是盖不住的——旺季日均几十柜、又有甩挂和二次换装时，人脑和表格都会失灵。把柜与车的关系做成只增不改的事件流，才是TMS在口岸不丢货的真正底座。