企业版要想做账套拆分是不是有点不可思议呢？拆分后跨组织业务咋办呢？基础资料怎么同步呢？合并报表咋合并呢？要查别的账套的组织的库存怎么查询呢？
现在越来越多的大型企业，随着公司规模的快速发展，业务量暴增，随着时间的推移，数据量也可能达到几个T的规模，再加上组织过多，公司业态也很多，因此性能将面临巨大考验，同时会因为版本太早，由于大量定制化开发造成不敢升级，不能享受到高版本的性能优化及新功能带来的好处，因此会有很多企业想先做账套拆分，然后针对每个账套单独做升级，那大家的疑问就来了：“星空企业版到底能不能做拆分？如果要拆分到底怎么拆分？有没有拆分过的案例可参考的？”下面就分享一下到目前为止星空首家做账套拆分的项目的项目拆分经验，希望可以帮助到更多有类似拆分需求的项目做参考。
（一） 项目背景
（1） 项目使用星空系统，上线时间为2017年，2019年做过一次升级，目前版本为7.1版本
（2） 未拆分前1个账套，共47个组织，注册用户3500+，并发用户1300+，业务数据达到4.5T左右。
（3） 客户使用了30多个第三方系统，其中有接近20个第三方系统与星空有做集成
（4） 客户拆分需求是：需要先将一个账套拆分为2个账套，然后再继续拆分，计划拆分为4个账套，拆分需要做成灵活可配置，能满足多次账套拆分，第三方系统能动态根据拆分前一样动态根据组织能进入不通账套处理业务，
（二） 拆分前期评估
前期评估很重要，客户需要关注拆分是否能达到自己的效果，拆分后客户的一些跨组织业务、合并报表、第三方系统要能像拆分前一样能使用，BI报表抓数据也能像一个账套一样能抓取数据，这些对后期方案构成很大的影响。
调查项包括：
（1） 跨组织业务有哪些？需要理清跨组织业务的关系，还有财务是否有资金调拨
（2） 拆分后哪些基础资料必须同步（分配型和共享型）
（3） 拆分合并报表的问题
（4） 通过第三方与星空集成的情况，有哪些第三方有跨组织业务
（5） 有哪些单据或者二开单据需要做同步的，比如即时库存跨账套查询、报价表跨账套同步
（6） 角色和权限是否需要同步
需要根据调查的情况做工作量评估：
工作量评估项包括：
开发工作评估量（占比最大）：
（1） 需要同步基础资料的开发时间（评估时该项目200个左右，拆分工作的主要工作量）
（2） 跨账套业务（包括联查、历史数据支持联查）登需要的工作量
（3） 跨账套资金调拨需要开发的工作量
（4） 跨账套库存查询开发的工作量（实现起来有难度，工作量评估较多）
（5） 第三方系统与星空业务集成需要配合的工作量
（6） 有需要同步的单据需要开发的工作量
（7） 整体开发方案设计需要的工作量评估
测试工作评估量：
（1） 包括用拆分工具拆分后的整个系统性能测试对比
（2） 拆分后在不开发的情况下哪些业务不能满足跨账套业务
（3） 开发完成后跨账套的基础资料同步、跨账套业务测试、导入功能测试、资金调拨测试、合并报表测试、权限同步测试、整个系统拉通测试等
（4） 上线前模拟测试（至少2轮模拟正式上线演练），由于上线需要停机，但能停机的时间是有限的，必须模拟上线来确定每个环节包括账套备份、还原、拆分、拆分二开补丁更新、相关配置和设置、第三方配置和验证等必须在有限时间内完成
项目难点和挑战：
（1） 本身是星空首家进行账套拆分的客户，没有参考方案，全靠自己探索，具有很
多不确定因素风险
（2） 很多地方需要动态，比如组织在哪个账套是不确定的，因为需要多次拆分，集成根据组织获取账套信息也是动态的，可变化的，并且多次拆分只需通过配置完成，不需要修改任何代码，包括第三方集成
（3） 同步的基础资料多并且同步复杂（180+基础资料需同步）
（4） 系统改造及开发点较多，同时涉及30+异构系统集成
（5） 开发周期短，从开发启动到开发完成不足2个月的开发和测试时间
（因为客户要求上线的时间是必须是5.1，原计划是10.1上线）
（6） 技术瓶颈多：
ü 会存在WEB API不支持的接口方法，需要研发出补丁
ü 会存在复杂的不能增量同步（批量授权）
ü 会存在数据量大无法调WEB API（报价表）
ü 同步时需要接口支持同步单据头主键、单据体主键、MasterID等
（7） 客户允许停机时间总共36个小时，其中由于数据量大，备份和还原就需要接近10个小时，后面还需拆分、二开补丁、配置（包括第三方）、权限清理、
（三） 拆分方案
1. 设计思路和策略：
（1） 做好顶层动态设计和规划
ü 数据中心可以动态配置：每增加账套时配置账套相关信息
ü 组织绑定账套信息：多次拆分时只需要修改选择对应的账套即可
ü 所有第三方和ERP系统账套之家交互时可以根据组织定位对应需要访问的账套，包括获取数据和写入数据，且任何一个数据中心都可以根据组织获取到对应的数据中心
ü 基础资料同步可以改成界面可配置，同步插件写成通用组件来进行同步处理，这样就可以减少同步的开发工作量，同时便于维护，也便于后续新增基础资料同步，实现动态扩展
ü 对于批量授权系统接口无法体现增量数据，对于报价表每次同步数据量超大调用接口会超过WEB API允许的范围，这2种情况都必须使用DBLINK进行同步，设计时同步时同样考虑动态性，也是动态根据数据中心动态链接对应的DBLINK
（2） 建立与研发的专项沟通渠道
ü 对于版本不支持的主键同步临时补丁解决
ü WEB API接口不支持的需要研发出临时补丁解决
ü 对于当前版本的企业微信工作流审批的，需总部出临时补丁解决
ü 当前版本不支持批量修改触发保存的临时补丁解决
2. 开发方案：
（1） 方案设计的三大原则：
（2） 具体开发方案
动态寻址方案
1） 数据中心配置（基础资料）
字段说明：
• 字段包括：账套名称、账套ID、站点地址、APPSECRET、APPID，账套类型、数据库登录，其中数据库登录字段是特指Oracle数据库登录时需要制定是哪个用户，用于DBLINK 访问时动态指定，SQL SERVER 数据库不需要这个字段，APPSECRET、APPID 是WEB API访问时使用密钥访问方式时需动态指定的，账套类型字段主要设置在基础资料同步是主账套还是同步的账套，
特别说明：由于同步时需要同步包括主键一起同步，所以基础资料只能在一个账套维护，同步到其他账套
• 数据中心配置为一基础资料，用于组织这个基础资料动态指定数据中心使用
对外接口：
如果需要获取所有账套清单，则可以调用数据中心配置这个基础资料接口，这个接口对外开放
2） “组织机构”绑定数据中心
字段说明：
（1） 只需要选择“账套ID”,则可以带出相关账套相关信息，其他字段不可编辑，都是通过基础资料带出相关信息
对外接口：
（1） “组织机构”这个基础资料需要对外开放接口，也是WEB API调用时供第三方系统调用的主要接口，可以根据组织ID动态获取数据账套地址和相关账套信息进行登录验证，也是动态寻址的主要接口方法
同步配置档案（基础资料）
设计说明：
（1） 这个是数据账套拆分非常核心的设计，主要是通过配置就可以完成对应的基础资料在保存、提交、审核、反审核、删除、分配等各种操作时即时进行触发和同步，同步时只需要挂一个通用插件则可以，既可以节省大量的集成工作，又便于后期维护，需要增加一个基础资料同步时只需要做配置则可以完成
（2） 配置时只需要输入对应的基础资料名称，系统会根据对应的基础资料对象动态加载所有的字段和字段映射，不用手动添加，如果想取消时删除默认的即可，配置也非常方便，配置时需要设置时公有型基础资料还是分配型基础资料，处理方式会不一样的。
（3） 操作类型也是所有的类型，可以动态设置哪些操作类型触发
第三方系统与星空集成
跨组织采购集成实现方案
特别说明：
（1） 拆分前也是通过二开实现跨组织业务，非标准），这为后面拆分带来了挺多好处，否则历史数据处理起来很麻烦
（2） 跨数据中心需要能跨账套联查，需要在每个账套记录上下游的关系和账套信息，及单号信息，可以通过单号连接打开跨账套单据
资金调拨集成实现方案
拆分工具
（1） 拆分时需要使用拆分工具，拆分工具需要找金蝶中国服务产品与交付管理部提供，这个是收费产品，需要跟客户报拆分工具的人天，并且签署服务合同
（2） 拆分工具的逻辑是连需拆分账套，获取对应的需要拆分做删掉的脚本，然后执行脚本进行删除，可以删除一些主要的业务单据，其他需要删掉的可以在上线后删除历史的。但一定要做好权限控制。
（四） 拆分后使用效果
（1） 第一次拆分：将1个账套拆分为2个账套，项目于5.1正式上线了，距离目前已经稳定运行了半年时间了，运行稳定，同步也正常，多个账套业务跟过去一样能满足所有的业务和财务需求
（2） 第二次拆分：将其中一个已拆分账套进一步拆分，拆分后的第三个账套于10月中旬完成并上线（这次拆分总共进10多天完成并上线），这次拆分仅做了拆分为三个账套的测试验证没问题后则进行正式拆分，整个过程不用做任何开发调整，仅配置完成，实现了多次拆分的目标，第二次拆分上线后到现在也是比较稳定。
赞 136
打赏推荐阅读