WMS规则引擎：图书仓的规则，为什么版次印次少册都卡在分配前？

WMS规则引擎图书仓的规则为什么版次印次少册都卡在分配前规则引擎说到底就是让“什么条件走什么动作”能不写代码、自己在后台配、自己生效——这是 WMS 里管“货怎么走”的那层配置。这个系列一路在问三件事一条规则能不能自己配、改完多久算数、改坏了怎么兜底。上一篇说的是同样一套系统给图书仓配一遍、给电商仓再配一遍两边配出来的规则几乎不重叠。做图书仓很多规则不是“配”出来的是分配逻辑里拦出来的。你拿自己仓里那几条最硬的规则对一遍大概也是这样。下面把图书仓摊开看。不给模板——规则一家一变给不出来。一、规则是配出来的还是分配逻辑拦出来的先把版次印次说清楚不然后面全是空话。图书定身份常见做法是书号ISBN加版次加印次。同一本书换了版次或者印次在系统里就是另一个货品不是同一件货改了个属性。版次错了发出去就是客诉——订的第二版收到第一版退货、投诉还可能是批量事故。版次这条你甚至配不出一条“允许错版”的规则——拣货单批次分配时强校验版次不对直接拦在前面。印次更特别。它不是系统自己算出来的是随单从上游带进来的。后面有没有按它分摊得看环节。你那边是不是这样得自己去核。还有个前提得先确认上游给不给印次。有的采购单只到书号印次要等入库时补录。源头没这个字段仓里的校验再强也拦不住这事儿得先在入库那头解决。这类字段看着像属性其实更像一套账的坐标。坐标错了后面跟着错。每个行业都有自己的那个“坐标字段”。找出来后面的规则就好办找不到配再多也白配。另一条麻烦是套装按册分量。一套书十二册有的出版社按单册管有的按组套管管法不同后面出不出问题完全不同。判断信号就一句这两条规则是结构化、可读、业务能自配的还是写在脚本和分配逻辑里、靠人记的。能不能改得动就看它写在哪。想验证这一点不难把规则表的名字丢进代码里搜一遍看有多少地方是绕过引擎、直接读表的。你搜一遍多半会不止一处——真只有一处那算运气好。查下去多半不是当年写代码的人不规范是引擎表达不了那些判断区间匹配、按列排序、跟业务表联查。图书这边常见的是先版次后库位的排序、同书号多印次按区间选、套装拆册的映射。这几种用决策表都不好表达才容易落到脚本里。表达不了怎么办多半只能在代码里手搓。手搓会带出一个后果同一套判断很可能被写好几遍写法还不统一。一处改了、别处没跟着改同一张规则表就可能同时给出一个正确结果和几个错误结果。所以“能配”和“改得动”不是一回事。改一条版次规则还得找研发——那就是能配不等于改得动。印次这条更细。有的出版社严格按印次有的不太区分仓库还有“主印次”的概念。主印次下拣货单印次和订单对上就行。主印次是什么、你们仓有没有回头评论区可以聊。这里先记住一句印次能不能配、配了谁改得先看这家出版社归哪类。二、规则改完多久算数还看分配这步过不过得去图书订单批次绑在出版社的“集中发布日”这个主时钟上——新书不是均匀来的是到点成批放出来。教材季、爆品档到点砸下来的就是洪峰。订单批次按路由分走几条通道比如常规入库、快速出货、印厂直发、预打包。一条路由规则改错波及的不止一个仓。这种节奏下发布日前夕改一条路由规则风险比平时高得多。你要判断的是那条规则改完是全量立即生效还是能先小范围灰度、没问题再全量。图书这边按渠道灰度往往比按仓更贴——教材、电商、馆配这几条渠道规则本来就不一样。只能全量立即生效发布日当天改规则就是赌——赌对了没事赌错了整批货走错路。灰度看着是个发布方式其实前提是“版本”。没有版本退回就无从谈起——你退到哪一版去还有一层容易被忽略图书的拣货单能不能“生效下发”还卡在分配这步。库存不足时拣货单批次分配会拦住发不下去。拦在这一步比等拣货员走到货位才发现强得多。代价是可用量得算准——实物扣掉已分配、再扣掉冻结的那部分才算数。这时候有两种走法。订单上标了“允许不足单发货”拣货单就能放行没标就等库存补足再发或者把订单取消、重新下发有货的订单。但“允许不足单发货”不是哪儿都能用。客户指定的是某一版某一印次缺货放行别的版次那不是“不优”是“错”。所以不足单默认只适用于不挑版次的零售单。指定版、教辅、渠道定制版该等补就等补该取消就取消别拿它兜底。图书的“生效”一半是规则发布的时机一半是分配过不过得去。后一半不看清光看规则有没有生效容易以为发了其实没发出去。三、规则兜底在图书仓版次硬拦、印次分情况改坏了往哪退先把“错”和“不优”分开。图书的每条边界还不一样。版次是硬拦。订单版次绝不可错拣货单批次分配时强校验版次不对直接拦在前面不是发出去再退。这条根本不该流到下游谈不上“兜底”。印次是分情况。严格印次的出版社印次不对也拦不太区分印次的印次对不上可能只是“不优”。发的是另一印次客户未必在意那是不优不是“错”。所以印次这条错还是不优得看这家出版社归哪类。一条印次规则配反了是下游客户先发现还是系统在出库前先拦住——这就是判断信号。库存不足那条也一样兜底不要求最优只要求不是错的。“允许不足单发货”就是个有风险的默认——标了拣货单放行但发出去就是缺了不标就等补货或取消重发。它不是最优但在等不起时至少不是错的。套装不成套不是兜底能解决的是出版社的管理模型决定的。不过按单册管不必然少册。少册多半出在“订单按套、库存按册、拣货不分托”或者套装拆了箱没绑回原套。要落到系统里主要靠两条订单整套下发拣货时绑定套号。这两条做到少册会在分配或拣货之前就被拦住。真漏到后面拣货单批次分配直接拦住发不下去——靠的还是硬拦不是底层兜底救。退这件事前面第四篇讲兜底那篇给过通用框架。落到图书仓要多问一句改坏了往哪退。退的前提是有版本而且退的时候得把生效期一起退掉。退货这件事有几个坑你可以照着对一遍。一种是读规则的地方只按“启用”状态过滤、不判生效期——那版本到期了数据还留在那儿起作用你以为退回去了其实没退干净。另一种是规则退回去了可它引用的那张表没跟着退两边对不上。版次这块尤其明显生效期、印次映射、套装册的映射得当一个整体来退。只退规则那一行退不干净。所以“能不能退”别只看后台有没有回退按钮。去看读规则那段代码判了几个条件再看它引用的数据有没有跟着一起退。判断信号汇成一句一条规则配反了是下游先发现还是系统先拦拦不住的那部分它的“错”和“不优”边界在哪。四、规则的三问串起来看图书三问过完图书仓的规则难在哪就清楚了。难的不是“能不能配”是版次印次这层身份。而且版次和印次还不是一个粒度版次是铁律印次看出版社。少册又是第三种它压根不是规则问题是出版社的管理模型决定的。三件事三种粒度三种管法版次靠硬校验印次靠分社配置少册靠管理模型。这才是图书仓真正的硬骨头。它不光内容不同连判断顺序都变图书先看版次再看库位不是先看库存。顺序一变配规则就变成了定顺序——先看版次还是先看库位得先定。这个顺序怎么抽去看每次配一个新仓都要重填的那几栏——版次、印次、套号谁该排前面就是从那几栏来的。具体怎么排每家社、每条渠道都可以覆盖抄不来。所以把规则做成对象、做成模板对图书特别值钱——版次印次这层值得沉淀成结构而不是散在脚本里。还有一件事那些“散在脚本里”的判断有一部分是可以收回来的。区间匹配、按列排序这类引擎补上能力就能配不必一直手搓。收不回来的多半是“收回来也没人知道它原先是什么”的。那批判断里装的是当年踩过的坑。五、图书仓这趟带走了什么把三问摊在图书仓上走一遍最该带走的不是“图书该怎么配”是一件更底层的事规则引擎好不好用不看功能清单列了多少条看行业 Know-How 有没有沉淀成结构。前几篇讲的都是判据能不能配、多久生效、改坏了怎么兜、行业差异渗到第几层。这一篇把它们放到一个具体的仓里走了一遍。判据没变落地时多出来的就是行业那一层。版次印次这层是踩过坑才长出来的——哪家出版社严、哪家松单册管还是组套管都得在系统里落成一格一格的判断不是每次重写脚本。模板从哪来答案就在这它是行业踩坑的结晶不是引擎自带的。图书仓这趟的价值是让“行业差异”真的落了地别人的场景未必和你一样我讲不清你的也没法替你定。规矩没有标准答案场景才决定长相。能照见自己仓里那几块硬骨头这篇就值了。下一篇把这一路的三问收成一张能带走的卡再说说这个系列接下来往哪走。延伸阅读《WMS规则引擎到底是什么别再和优化求解器搞混了》《WMS 规则引擎一条规则在后台怎么配》《WMS 规则引擎能自己配规则为什么还是改不动》《WMS规则引擎改完保存为什么还没生效》《WMS规则引擎规则改坏了兜底求最优还是求不出事》《WMS规则引擎图书和电商的规则为什么配出来天差地别》