做金蝶U9实施这些年“生产领料非整件”这个问题我至少碰到过七八回而且每次都赶在车间等料的节骨眼上。领料员在U9里做生产领料单数量填好一点保存或审核系统直接弹一句“件数必须为整数不允许录入非整件数量”单子死活过不去。产线等着开工仓库说系统不让发IT和顾问的电话从下午响到晚上。这篇文章就把这个问题从头到尾讲透非整件到底触发了U9的什么规则、为什么会有这种规则、正规排查应该查哪几个地方以及当配置走不通时怎么用二次开发在生产领料单上做放行。只要你的U9也出现类似提示跟着后面的链路走一遍基本都能定位到根因。最后还整理了放行之后的批次尾差、成本偏差、倒冲异常等连锁问题别以为绕过去就完事了。1. 生产领料被“非整件”卡住一次让车间停线的报错现场1.1 不同版本两套提示但本质是同一个校验最典型的一次是在一家做电子元器件的工厂下午三点车间领料员做生产领料单数量输好一按保存金蝶U9直接弹提示件数必须为整数不允许录入非整件数量。换到另一个U9 Cloud环境提示变成了“辅助数量不能为非整数请检查换算率”。还有的客户在审核环节才报错提示“不允许按散装数量出库”。同一个业务不同版本、不同单据状态下给用户的感觉完全不一样。很多用户以为这是U9出bug了实际上只是校验被触发的位置不同保存校验在表单插件层审核校验在库存事务层。这也解释了为什么有时候单子能保存却审核不过去我排查时最怕的就是这种“半路拦截”它比统一报错更难定位。1.2 先别急着报故障把问题定义清楚在带人排查之前我通常会先问业务一句话你们现在领料是按“件”领还是按“个”领车间报需求的单位和仓库发货的单位是不是同一个口径这个问题看着简单但能筛掉一半的假故障。如果车间按个领、仓库按件发系统中物料又设置了“1件12个”这种固定换算率那么领50个的时候件数就是4.1667。系统把它判定为“非整件”完全符合设计逻辑不是故障。反过来如果车间的需求本身就是按件领、按件发那就要检查为什么还有小数件数出现——通常是BOM用量或生产订单数量换算出来的属于配置或数据问题。所以“非整件”这个报错本身不重要重要的是业务到底想要什么样的数量口径。把口径对齐了再去看系统设不设防才有意义。1.3 波及范围绝对不止生产领料单这个问题如果只出现在生产领料单处理起来反倒简单。实际项目里同一个物料如果被委外领料、调拨出库、其他出库、倒冲领料共用只要它在物料档案里挂了辅助单位其他单据大概率也会陆续报错。我就见过一个客户生产领料单找我们放开后第二天委外加工领料单又报同样的问题原因就是当初物料档案复制时把辅助单位一起复制过去了。所以这篇文章后面的排查链路不只是解决一张生产领料单而是把所有涉及该物料的出库单据统一查一遍。否则你永远在灭火今天救生产明天救委外后天可能轮到销售发货拆箱。2. 拆解“整件逻辑”U9为什么要把数量分成件数和散装数2.1 基本单位、辅助单位与换算率的三角关系U9里一个物料可以有两个计量单位维度基本单位管核算和库存辅助单位管业务习惯。基本单位通常是“个、千克、米、张”这样的物理单位辅助单位通常是“件、箱、卷、包”这样的业务单位。两者靠“换算率”连接1件12个1箱50千克等等。单据上最常见的设计是数量列存基本单位数量件数列存辅助单位数量。用久了你会发现件数其实就是一个派生值它等于基本数量除以换算率。只要换算率是固定值基本数量一确定件数就是确定的。U9在很多单据上把件数和数量做成联动改数量件数自动变改件数数量也跟着变。这个机制的初衷是方便仓库我收到100个按整数箱入箱数好数好记。但问题也恰恰出在这里——系统默认你只对“整件”感兴趣一旦出现非整数件它就拿不准了。拿去买奶茶打个比方店里按杯卖你想点半杯店员可以给你少倒点但收银系统分成“杯”来算最后总会出现一个半杯的残数。2.2 固定换算率下的必然冲突1件3个带来的麻烦最容易踩坑的是换算率不是十进制的场景。比如某螺栓1件3个。生产订单要10个换算成件数就是3.3333件。你要是只按件数去发料根本不知道发几件你要是按个数去发系统又盯着件数不放。另一种很常见的情况是包装规格浮动。同一个物料供应商有时候一箱装12个有时候一箱装10个。如果你在物料档案里把换算率硬编码成12那10个一箱到货的时候仓库入库单据上的件数问题马上爆发。这类物料就不适合用固定换算率的辅助单位管理更不适合在生产领料单上做整件校验。我在项目里经常跟客户说一句话在U9里“件”不是中文里那个“件”它是“第二计量单位”的语义。你把它理解成“包装规格”还是“计量单位”决定了后面所有单据怎么设计也决定了今天这个问题到底能不能解。2.3 这个“件”到底该不该存在判断标准我认为就两条。第一条实物是不是真的按一个固定包装在发料、存放如果是可以保留辅助单位如果车间和仓库日常都是按零散数量沟通辅助单位只会添乱。第二条仓库和车间日常沟通是否都以这个包装为单位如果车间问的是“还有几个”而不是“还有几件”那辅助单位只适合做参考展示不适合做单据的校验依据。很多企业上U9之前用的老系统没有这么严格的整件概念仓库凭感觉发车间凭经验领上了U9才发现“原来系统管得这么细”。这种转变不是技术问题是管理口径问题。你需要在蓝图阶段就和业务明确否则后面只能靠配置和二开去补。3. 完整排查链路从物料档案一路查到单据模板这一章我不直接讲答案专门讲排查过程。遇到非整件报错按这个顺序走基本不会漏。顺序乱了容易绕远路。3.1 第一步翻开物料档案的单位页签先在基础数据里找到报错的物料打开档案重点看三个地方基本单位是什么辅助单位是什么换算率是固定还是浮动换算率数值是多少。然后用今天领料数量除以换算率手算一下件数。如果结果是无限小数或位数超过单据允许的小数位问题基本就在这个地方。再检查一下BOM里这个子件的单位用的是基本单位还是辅助单位。如果BOM用量是辅助单位生产订单展开后系统会先把生产数量换算成子件数量换算过程一旦出现小数后面领料单基本必报“非整件”。这种情况我遇到过很多次排查时不要只盯着领料单本身源头往往在BOM。3.2 第二步检查库存组织参数与批次管理物料库存页签的批次管理、辅单位是否参与库存会决定后面的校验强度。如果物料按批次管理U9会把批次结存数量也分成基本数量和辅助数量。当你领料领出一个小数件批次账面上就出现了一个不整的结存系统在审核时会认为这是“拆批”或“散装出库”于是二次拦截。另外有些库存组织参数里会有“出库必须按整件”或“允许拆零出库”之类的选项不同版本叫法不一样。我遇到过一个项目所有排查点都是正常的最后发现是库存组织参数里勾了一个“整件发料控制”去掉之后就通了。所以参数设置一定要翻别只盯着物料档案不然在物料档案和单据模板之间绕半天问题原封不动。3.3 第三步检查单据类型、单据模板与字段精度打开生产领料单的单据类型和模板设置看“件数”字段是否可见、可编辑看它的数据精度支持几位小数。有一种情况特别坑件数字段在界面上只显示0位小数。你输入1.5时界面失焦后直接四舍五入成2用户以为保存了1.5件实际上系统里已经变成2件。这种不是校验问题是字段精度问题但用户反馈过来往往就是“非整件报错”。再就是超领比例。如果领料单允许超领5%业务上可以接受把19.2个向上取整到20个来领这就不需要动整件校验了。但很多企业没有设置超领比例导致必须精确领料非整件问题才暴露得那么频繁。所以看单据模板的时候超领比例、允许超量、件数千分位这几个字段都要一起看。3.4 第四步确认有没有二开插件在中间做校验最后一定要确认这个环境有没有二次开发。U9最常见的二开位置就是单据插件和服务端插件。如果以前有人为了管控写了一个“保存时校验件数必须为整数”的插件即使系统标准功能不拦你插件也会拦。这种隐藏校验最难查因为它不在标准菜单里。排查方法看单据类型上挂的插件列表看代码仓库里最近改过哪些服务端事件或者直接在生产环境打开单据操作日志看报错来源是系统校验还是自定义插件。我在客户现场碰到过最离谱的情况一套系统里有两批顾问做过二开前一批写了个强制取整后一批以为没这功能反反复复查了一周才发现是两个插件在打架。排查二开插件时建议把近半年动过生产的开发清单都拉出来别只信“我们没做过定制”这句话。3.5 排查点速查表排查顺序检查位置关键字段/选项常见问题1物料档案-单位页签基本单位、辅助单位、换算率固定换算率无法整除2物料档案-库存页签批次管理、辅单位库存批次结存小数件3库存组织参数整件发料控制、拆零出库出库强制整件4单据类型/模板件数字段精度、超领比例字段精度为0位小数5二开插件保存校验、服务端事件自定义整件校验4. 三类解决思路改配置、改流程、改系统定位到根因之后就是方案选择的问题了。我按优先级来聊先说配置再说流程最后才是二次开发。4.1 改配置浮动换算率、关闭整件校验、调整精度先说最简单的情况物料本身不应该用固定换算率管。那就把固定换算率改成浮动换算率件数由每次单据上传入的辅助数量决定。这样生产领料单上你可以输1.5件系统按1.5件乘当前批次的实际换算率去回算基本数量。代价是库存报表里的辅助数量统计没有统一口径因为每一批的换算率都可能不同后续做分析报表时需要注意。如果业务根本不需要按件管理那就更直接去掉物料上“辅助单位参与库存”“按辅助数量出库”之类的勾选单据上只保留基本单位。车间领多少就按基本数量领件数只是显示字段不参与校验。这是我最推荐的做法因为它最干净也是最容易说服业务的方案。很多工厂的物料档案是从老系统导入的辅助单位当时随手填的实际业务里根本没人按件管这种历史包袱该摘就摘。如果只是件数字段精度问题直接在单据模板里把件数的小数位数调大。比如调到6位基本数量除以换算率的结果基本都能放得下。注意改了之后要清一下旧模板缓存否则不生效这是U9环境里很常见的“改完没反应”原因。4.2 改流程让领料单回归基本单位很多工厂实际上并不需要“按件领料”这个动作只是车间和仓库习惯了这么说话。流程上完全可以统一BOM用量用基本单位生产订单展开数量用基本单位领料单保存后件数自动显示、不让人工修改。仓库发料时以基本数量为准件数只用来辅助看整箱数量。另一个流程层面的技巧是用超领比例吸收小数。比如理论用量是1.25件设置允许超领5%以后直接按1.3件领或者按1.5件领了再做生产退料。只要成本核算和车间实际能接受这比二开省事得多。不过这个办法要事前跟业务和财务说清楚不然财务在后面查超领原因时还是会找你。流程调整的成本最低但它最依赖管理层的推动。如果车间和仓库习惯了“件”这个口径让他们改习惯比改系统难多了。所以我在项目上一向的做法是先跟车间主管聊半小时如果对方坚决要按件领料那就别硬推流程直接看配置和二开方案。4.3 改系统二次开发在生产领料单上做“非整件”放行改配置和改流程都走不通时才动二次开发。我见过不少企业真正的要求是既按件领又允许散装也就是要保留辅助单位同时允许非整数件数存在并在系统里正确核算。U9在这类需求下一般通过二开解决方式大概有三种。第一种是服务端插件放行。在领料单保存或审核的服务端事件里先取物料档案的换算率将表体基本数量和件数做一次重算保证“件数基本数量/换算率”并且不抛整数校验。如果物料有扩展字段标记“允许非整件”就跳过标准校验逻辑没有标记的物料保持原规则。这种方案最稳因为它是在系统标准校验之前把数量处理干净。第二种是界面交互处理。通过表单插件在用户输入非整件时给出提示并自动按最小领料粒度换算成基本数量。比如物料最小发料粒度是1个你输入1.5件系统提示后将基本数量写成18个件数显示为1.5。这样单据能过账也平。这种方案用户体验好但要注意不同入口的行为一致性。第三种是接口层处理。如果客户的生产领料单是通过API或批量导入工具生成的二开还需要在导入服务里做同样的换算和校验处理。很多项目只处理了Web界面结果客户在移动端领料时又报非整件就是这个原因。排查的时候把接口清单拉出来一条条过别漏。下面给一段思路示意代码注意这是二开方案里面最常见的服务端插件处理思路具体接口和模型不同版本不一样不要直接复制到项目里。public override void BeforeSave(IBeforeSaveContext context) { // 伪代码获取生产领料单表体行集合 var lines GetCurrentDocument().Lines; foreach (var line in lines) { var material GetMaterial(line.MaterialId); // 扩展字段是否允许非整件领料 if (!material.AllowNonIntegralQty) continue; decimal basicQty line.Quantity; // 基本数量 decimal rate material.UnitConvertRate; // 换算率 line.AssistQty Math.Round(basicQty / rate, 6); // 件数保留6位 // 其他整件校验字段同步置为有效或跳过 } }二开的时候必须注意只动件数不行必须保证基本数量、件数、换算率三者之间的关系始终成立。如果你只是为了绕过校验把件数改成整数实际基本数量对不上后面成本核算和库存会一起乱。这个连锁问题下一章专门说。4.4 三种方案的适用场景对照方案适用场景工作量风险改配置浮动换算率/关闭辅单位管控物料不需要严格按件管理小历史数据需配套调整改流程统一基本单位领料/超领取整业务上能接受按基本单位发料小需要业务和财务认可二开插件放行换算重算必须保留件数且允许拆零大需考虑所有单据入口和升级回归我的建议顺序是先说清楚业务本质能用配置就用配置流程上如果能统一口径成本最低二开只做最后一层兜底不要一上来就开发。5. 绕过拦截后的连锁反应批次尾差、成本偏差、倒冲异常放行只是一瞬间的事麻烦往往在后面。这个部分是用钱换来的教训也是很多顾问只做前半段、不管后半段造成的烂尾工程。5.1 批次库存出现“0.5件”之后会发生什么物料只要开了批次管理放行非整件领料之后批次结存表里就会出现类似“1件零6个”的结存。做月度盘点时仓库实物数整箱很容易尾箱很麻烦对应系统账面则是“基本数量是整数件数是小数”。两边一对账始终差一点最后只能靠盘点调整单去平。所以建议在放行的同时建立一份“尾差台账”每周或每月把件数为小数的物料清单导出来核对一次而不是等年底盘点了再抓狂。特别是那种既有批次又有保质期的物料尾差还会影响效期库存报表容易被质量部盯上。我在一个食品客户那里就经历过一个批次结存0.4箱仓库实物是4个系统报表自动按0.4箱折算质检部门看了半天不知道算什么。5.2 倒冲领料与工序领料自动生成单据时的尾差倒冲领料是按完工汇报数量乘以BOM单位用量自动生成领料单并归集成本。只要BOM用量是小数件自动生成出来的领料单就一定是非整件。以前整件校验开着的时候后台任务会卡住或者报错放开之后这些非整件单据会直接进入库存和成本数量口径如果不一致在制品核算就会出问题。我在一个机械加工客户那里遇到过产品BOM里的焊条用量是按“根”算的但物料档案辅助单位是“箱”1箱100根。一次汇报完工235件系统自动生成领料单235乘0.4等于94根换算成件数0.94件。如果按“整件取整”处理系统会把0.94件当成1件来领结果多领6根如果直接放行0.94件仓库又没法从实物角度理解“0.94箱”。最后我们统一改成在BOM里把焊条单位改成“根”件数只显示不参与倒冲问题才算根治。所以倒冲物料的计量单位最好用基本单位不要用辅助单位。BOM设计阶段就定下这个规矩后面会省掉一大半的非整件麻烦。5.3 成本核算只有一个口径基本数量U9的成本核算在领料这一环节始终以基本数量为准不是以件数为准。很多二开在绕过校验时只把件数强行改成整数却忘了同步基本数量结果一张领料单上基本数量与实际不符成本要么多摊要么少摊。这个错误非常隐蔽单看单据根本看不出来要等到月末成本结账才会暴露而且查起来非常费劲。正确的做法是在二开中始终维护“基本数量件数×换算率”这个恒等式。如果规则要求整件领那就把基本数量取整到整数件对应的基本数量比如多领的部分做生产退料或者计入材料差异而不是在件数上造假。这一点无论是顾问还是开发的同事都必须记住。成本结账前的单据检查脚本里我把这个恒等式作为第一条校验规则写了进去基本能拦截掉90%的尾差问题。6. 实操避坑清单与二次开发实测建议6.1 七个容易踩的坑第一个坑只改物料档案不管历史存量。换算率改了以后已存在的库存基本数量不会自动换算必须在验证环境先模拟一遍再安排计量单位调整或盘点调整。第二个坑把测试数据直接做在生产库。我见过顾问在正式环境改了一堆换算率最后影响当月成本报表只能加班回滚。验证环境里建一个“9999测试料品”所有参数改动先在测试料上跑一遍再上生产。第三个坑只放开生产领料单。同一个物料可能还走委外领料、调拨、其他出库标准校验和插件校验如果只看生产领料单第二天一定爆下一个卡点。第四个坑只测试保存不测试审核。保存能过、审核报错的案例太常见了因为审核时会再次触发库存事务校验。测试用例里必须包含保存、审核、发料确认、退料这几个完整动作。第五个坑只处理Web端入口忽略接口和移动端。客户的生产领料如果还有接口导入和移动扫码领料这几个入口的校验逻辑可能完全不同不改完等于白改。第六个坑二开逻辑写成“所有物料全部放行”。正确做法是用扩展字段控制白名单只有允许非整件的物料才跳过校验其他物料保持原来的整件管理避免把整个系统的管控强度拉下来。第七个坑上线后不回归。U9产品升级或者打补丁时二开插件可能失效或行为变化。每次版本更新至少把“物料档案-单位换算-领料单保存-审核-库存结存”这条路径再走一遍。6.2 二次开发中的实测建议如果在二开方案里走到了写插件这一步建议按下面几条做。第一在服务端插件里把换算前、换算后的基本数量和件数都写入日志至少保留单据号、物料编码、操作人。这样即使后面出了尾差也能快速找到是哪一笔单子引入的。第二插件要同时处理“保存前”和“审核前”两个事件因为不同版本的U9对校验节点的分配不一样不能只拦一个。第三代码编写遵循“窄放行”原则判断字段先看物料扩展标记再看单据业务类型最后再放行不要写一个无差别的处理器。另外有条件的话把二开插件做成可以被配置文件启停的形式。用数据库的一个开关表控制某张单据、某个物料出现问题时先关掉插件排查再决定是否恢复。这个操作看似简单在运维阶段能省掉你半夜被叫起来的次数。我在几个长期运维的客户项目里都是这么做的效果很好。具体代码层面我建议在抛异常前先做一次完整事务回滚测试确认不会把“单据保存了一半、库存却扣了一半”的脏数据留在库里。U9的事务机制在不同版本各有差异二开时最好有一份针对性的开发规范文档别靠记忆也别靠上一个顾问留下的口头承诺。最后再分享一个我自己的体会非整件这个问题表面上是U9的校验规则在挡业务实质上是企业在计量单位设计阶段没有把“包装规格”和“计量单位”分开。上系统之前花半天时间梳理一遍所有常用物料的单位口径比后面写多少个二开插件都管用。如果你已经在坑里了也别慌按物料档案、库存组织参数、单据模板、二开插件这个顺序查下去通常一两天内就能定位到根因。解决了生产领料这一单别忘了把委外领料、销售出库这些场景一起收网免得下次换个单据再炸一次。