余额模型在供应链库存及核算等业务中使用越来越广泛，但因为客户实际应用场景千差万别，对于余额模型的扩展需求大量存在于实际业务中，那如何进行规范的扩展，有效规避开发中各种异常情况？

该案例以采用余额模型开发的即时库存余额表为例，深入介绍了余额模型扩展的具体步骤及相应规范和注意事项，相信有了此案例宝典，余额模型的二开扩展将更加丝滑顺畅。

撰稿人：金蝶-古乃亮

【温馨提示：因企业业务场景存在不同程度的差异，此案例仅供参考，请根据现场实际业务情况探讨最优解决方案，并在上线前进行充分验证。】

一、业务背景

业务现状

目前供应链库存及核算，所有余额表都是采用余额模型来实现的，但是标品发布的余额表的管理维度是固定的，到了实际客户场景中，因为行业不同，管理方式不同，余额表要管理的维度差异非常大，这就需要余额模型来支撑这个扩展。

说明：余额模型是一个抽象的模型框架，即时库存余额表则是采用余额模型开发出来的一个具体的余额表，其关系类似单据模型与采购入库单的关系，通过模型来开发才能让具体的余额表具备模型自带的各种能力，如：扩展能力。

客户诉求

基于以上业务现状，大约80%以上客户需要对标品预置的维度进行调整，标准产品余额表需要增加额外的管理维度。

需求场景描述

采用余额模型开发的余额表，能够很好支撑并实现这种扩展需求，因此，现选择以即时库存余额表为例进行具体需求场景的介绍。

某集团为快销品行业，其库存需要管理到门店、供应商等维度，此集团因其产品特点，其物料需要按箱号管理等各种差异化的需求，虽然标品余额表中已有20多个管理维度（组织、物料、保管者、仓库、仓位、生产日期……），但也无法直接满足客户的这种特殊场景需求，则需要二开增加库存管理维度来适配客户实际场景。因此就需要采用余额模型开发余额表，来实现类似此客户差异化的扩展需求，如下面所示：

二、解决方案

下面以即时库存余额表增加箱号为例进行介绍：

整体思路

即时库存余额表只是一个用于记录实时库存数量的账表，其数据全部来源于出入库单据本身，在单据操作时发起余额的更新，按什么规则进行更新余额则要在余额更新规则中进行配置，因此需要扩展的内容主要包括即时库存余额表、库存出入库单据、余额更新规则。

详细步骤

1、 扩展余额表

1）打开【开发平台】-【供应链云】-【库存管理】扩展的应用，在余额模型页签下，找到【即时库存余额表】元数据，点击扩展，生成扩展元数据，如下图操作。

图1 即时库存余额表原厂元数据

图2 即时库存余额表扩展页面

图3 即时库存余额表扩展后元数据

2）进入元数据设计界面后，在普通维度面板中，添加箱号字段，这里以文本字段为例，添加字段后，并设置字段必要的属性即可，最后点击保存即可。

注意：在扩展字段过程中，字段类型要按实际需求确定，一般文本、基础资料居多。

图4 元数据界面设计步骤

图5 元数据界面设计步骤

图6 元数据界面设计保存

2、 扩展单据

通过余额更新规则，找到所有要更新即时库存余额表的单据，在对应的单据（如：采购入库单、销售出库单等）上采用相同的扩展方式，添加箱号字段即可。这里不做重复演示，一般项目中，由于单据本身的需求，往往已经扩展好了相关字段。

注意：单据上扩展的字段要和余额表上扩展的字段，字段类型，物理表字段类型，长度要保持一致，否则可以出现更新余额时类型不匹配。

3、扩展余额更新规则

1）在应用下打开【余额模型】-【更新规则】列表界面，筛选余额表=即时库存余额表的余额更新规则，逐条扩展，修改扩展的余额更新规则。下面以领料出库单为例演示：

图 7 余额更新规则列表

图 8 余额更新规则列表

图 9 余额更新规则配置界面

2）最后点击保存即可，其他余额更新规则，操作方式一样。

注意：扩展要启用，原厂的规则是不能禁用的。在运行时启用的扩展会与原厂规则合并。

4、 设计物理表，增加KSQL二开字段脚本

余额表新增了二开字段，示例中物理表字段为：fk_kdtest_boxno，找到即时库存余额表的物理表：t_im_inv_realbalance，新增字段的KSQL语句如下：

在实际二开中，数据库类型是确定的，也可以使用数据库方言语法，单据的字段脚本原理一样，不重复演示。

5、构建输出二开补丁包

方式1：开发界面导出二开扩展安装包的方式

1）先添加扩展的即时余额表元数据，有单据一同扩展时也要添加进来。

图 10 应用导出向导

2）添加2.4步骤中的SQL脚本

图 11 应用导出向导

图 12 补丁包内容

图 13 补丁包内容

各包路径作用参考下面说明

图14 包路径说明

3）导出扩展的余额规则，zip包中的余额更新规则元数据，加入到安装包的detamodel/*/metadata/路径下即可。

图 15 余额更新规则导出

图 16 补丁包内容

方式2：使用GIT+集成工具构建输出的情况

只需要将上述余额更新规则导出文件里面的元数据文件，迁入到二开GIT仓库中扩展应用的detamodel/*/metadata/下即可，随构建工具输出即可。

注意：采用哪种方式，要结合项目实际情况，及生态伙伴有关部门支持情况，研发内部则是方式2。建议也是用方式2，能有效的进行开发产物版本管理，修改记录追踪，自动化构建输出。

6、更新环境

使用MC安装二开补丁包即可（运维的内容）。

三、方案的推广价值

普适程度

该方案是最典型的扩展需求场景，适用于所有行业，尤其是私有云上线的客户。

客户价值

该方案介绍了扩展的具体步骤，还推荐了规范的构建输出方案，可以有效的规避开发管理不当导致的各种异常情况，同时还给出了规范注意事项，能够规避绝大部分实施过程、上线后可以避免的业务操作问题。

四、注意事项

1、开发扩展内容，无论是单据还是余额模型的扩展，都应由二开开发人员完成。

这里面涉及到开发基本常识，设计规范相关内容（如：字段名规范，默认值，字段类型，长度等），实施要关注的是业务场景本身正确性、落地结果的验证。

2、所有扩展事项是系统上线前完成的，上线后发生业务数据后，则不允许对余额模型扩展内容再次进行变更调整（包括启用禁用）。

否则引起系统库存数据异常，在结账、对数及报表查询时发现各种数据异常，影响月结，数据异常分析成本、修复成本非常高。

3、所有扩展内容必须在开发环境开发好，验证好，通过二开补丁发布到各个环境，走正规的发布流程。

尤其生产环境，禁止直接做配置的调整，相关配置的修改权限应该集中管控好。开发过程中确定好相同开发商标识，避免多个开发商标识交叉开发，导致扩展混乱。

4、余额表数据二开不能在代码中、元数据中添加任何修改的动作（如：代码直接load、save、update等），包括数据库直接修改数据，这类操作导致的结果和第2点一样。

5、已审核的单据，与库存更新相关的基础资料设置，不能直接后台代码修改、元数据扩展绕开标准产品限制进行修改，及数据库直接删除或修改。

如：单据已审核，业务发现批号做错了，实施或二开出方案，直接扩展改数据，简单认为把单搞对就可以、某个库存事务已经发生业务，原来设置的是要更新库存，业务发现设置错了，直接调整为不更新库存了，这类操作，都会导致单据数据与余额数据不一致，后果和第2点一样。

针对以上第2、4、5点，业务数据确实做错的情况，建议做法如下：

1）尽量采用系统已有业务流程处理数据，如：单做错了，反审核在做，或做其他单据正向弥补数据；

2）业务过程中要加维度，应咨询研发能否实现，哪些数据需要联合升级处理；

3）找产品需求人员，了解相关业务设计，有没有类似案例参考处理方案；

4）提单到支持部，看是否有响应的解决方案。

五、相关资料

1、余额模型原理、配置、开发、二开、常见问题相关内容，建议实施、开发必看下面链接：

https://developer.kingdee.com/knowledge/specialDetail/478963441080748032?category=478963632894658560&id=479658112748874496&productLineId=29

2、余额表数据基本是为报表查询服务，在余额表做了相关扩展后，报表需求往往也会做响应的扩展调整，关于中台报表原理、配置、开发、二开、常见问题，建议实施、开发必看下面链接：

https://vip.kingdee.com/knowledge/specialDetail/223398297334212352?category=467716512497954048&id=464015614391139840&productLineId=2

附：案例评论有奖活动

我们将每月挑选优质案例评论发放精美奖品，以下形式的评论中奖概率更高哟：

1、分享案例给您带来的启发：这个案例为您当前、进行中或即将开展的项目带来了哪些启发？若您成功将案例中的策略或方法应用到实际项目中，可在评论区分享您的具体应用情况，我们将为您准备额外的奖励。

2、提出案例优化的建议：您认为案例在哪些方面还有改进的空间？您有哪些更好的替代方案或建议？

期待您的案例留言，您的反馈是我们前进的动力~