多组织系统的设计思路

一、什么是多组织系统

多组织这个概念是一般多用于企业信息化系统。通常是指一个集团分拆了多个子公司进行运营，每家子公司负责集团业务的一个到多个部分，多家子公司共同支撑集团的全部业务。

子公司内部，在业务执行过程中相对独立， 甚至有自己的财务归集口径和运营管理模式，但最终数据需要归集到集团。

这类集团在上企业信息化系统时，需要系统有在子公司内独立运行的能力，也要求有组织间数据共享、协作、整合的能力。

常见的场景有：

1. 产销分离：一家公司负责销售，另一家公司负责生产。

2. 集采分收：集团公司负责采购计划，分子公司收货入库。

3. 集采集收：集团公司负责采购计划并采购入库，分子公司通过组织间调拨方式领料收货。

4. 内部购销：不同组织间，原材料、半成品、成品 通过买卖关系进行调货。

等等

二、多组织系统要达到的目标

1. 档案

使用一种或多种方式：

a. 档案共享：集团总公司制定部门、料品、人员 等等 编码规则，统一对部门、物料等各类档案进行定义和编码，然后各子公司读取集团公司的档案信息。

b. 档案下发：集团总公司制定的档案,可以按档案类型、档案编码下发到分子公司，并授与分子公司修改部分属性的权利。

c. 档案隔离：每家子公司除可以引用集团下发或共享的档案外，同时可以自己编制内部自用的档案案。

2. 业务往来

常见的业务往来：跨组织领料、跨组织发货、上游组织接单下游组织生产、

三、系统实现思路

限于篇幅仅从数据流层面讲讲实现原因

1.档案

a. 档案隔离：每个档案添加一个组织字段，代表档案由哪个组织制定，可以由哪个组织使用；

如果需要多个组织共同使用，通过下发或者共享方式实现。

b. 档案共享：即将组织字段清空，代表所有组织都可以全用。

c. 档案下发：即档案复制一份，在新数据里填上要下发的组织。

2. 业务往来

多组织内业务往来在系统中主要体现为：

• 能够查看业务上下游的报表、单据
• 能够参照上游组织的单据制订本组织的单据
• 能够对下游组织的下达任务，即推送下游组织的单据

实现方式通常有两种：

• 职能拆解法，常见于大型的ERP产品 
• 业务协同法，常见于MES、WMS等现场执行系统。限于篇幅，下面仅从软件如何做数据控制的层面做一下介绍。

【职能拆解方式】

a. 职能梳理

整合全集团的全部业务，整理出集团的职能。 常见的职能划分：开票组织、库存组织、生产组织、采购组织 等等，具体职能划分 可参考大型ERP产品。

将上述职能提炼为 组织档案的 属性。

b.组织职能

在系统的组织档案上，给对应的组织启用 对应的职能。

c.职能字段定义

相比于单组织系统的单据，多组织系统的单据上需要预留这些职能组织对应的字段。每类职能预留留一个字段。   

固定职能编码 OR  使用职能自定义项 两种方式均可。

下面以职能自定义项来介绍实现原理，假设我们预置 16个职能自定义项， 在“系统管理-自定义项” 管理页面，设置整个系统启用多少个自定义项。

假设字段名叫 cBusOrgCode1、cBusOrgCode2、cBusOrgCode3... cBusOrgCode16，

字段对应的标题在自定义项设置里可以设置，例如：cBusOrgCode1 叫 开票组织，cBusOrgCode2 叫库存组织。  

组织信息  这个档案 有显示属性可以勾选，就看 自定义项里 启用了哪些自定义项，名称 跟着 自定义项的 项目名称 走。

d. 定义单据启用职能

单据头中数据表中预置 cBusOrgCode1、cBusOrgCode2。。。到 cBusOrgCode16   共16个自定义项。

每类单据启用哪些职能组织，只需要在原来的功能档案中，添加启用字段，bBusOrgCode1、bBusgOrgCode2...到cBusOrgCode16, 用这16个字段标识该类单据分别启用哪些职能字段。当然能够启用的范围 要受到 第c步 总体启用情况的限制，只能启用 “自定义项”管理中 已启用的职能字段。

e. 数据权限

用户登录系统后，可以看见哪些单据、参照哪些单据、操作哪些单据，按照上述划分的职能进行控制。

系统实现概述：

• 考虑到用户在单据界面上翻页的情况，不能拿着 当前单据的信息（制单组织、单据类型、单据号）去调用平台接口，判断是否有权查看。而是应该提供一个方法，这个方法给到业务开发组，业务开发组在查询单据的代码上，把它作为附加的查询条件。这样在单据翻页和单据列表中查询时，都能控制住单据的可见范围
• 由平台提供统一的方法，控制登录系统的人员 能够看到 哪些组织、哪些类型、哪些编号的单据。传入参数：当前人员、当前组织、当前单据类型；返回参数 是一个过滤条件，类似cBusOrgCode1 in ('xxx') AND cBusOrgCode2 in ('yyy') 。  业务组开发拿到它后，对数据进行过滤。
• 基于跨组织往来的改造: 

       伪代码=>

                    原组织隔离在查询数据时有限制“单据.制单组织 = (登录人.当前登录组织)”   

                    现在修改为                                                                                     

                  业务单据.表头. 制单组织 = （ 登录人.所在组织)    or ( 平台方法返回的过滤条件 )

• 原来单组织模式下的功能权限和权限数据保持不变

【业务协同方式】

a. 提炼集团业务，制定协同路线

如下图是产销分离的协同路线设置，总公司组织编码是001，负责销售；生产子公司编码是 002，负责生产；

还可以设置不同的协同路径，定义不同的组织间传递规则。

b. 单据按协同路线传递

单据的单据头添加 协同路线，需要做跨组织业务的单据，在制单过程中录入协同路线。

单据在单据的保存后或审核后事件中，按照上面的单据规则，触发生成下游组织的单据。实现上下游组织业务协同。

协同路线仅定义多组织间单据类型的传递规则，并不记录 具体单据的上下游关联。

c.数据权限

• 上游组织在制单或审核单据后，自动触发生成下游组织单据的方式，我们称为推式生单；

（如上图中的“发起组织”，审核完“采购订单”后，系统自动生成“接收组织”的采购订单。）

• 同时也支持下游组织查看上游单据，并拉取上游单据的信息，生成下游单据，我们称为拉式生单；（ 如上图中的“接收组织”，主动查看“发起组织”的采购订单。）
• 除组织隔离需要改造外，原单组织系统下的功能权限和数据权限保持不变。
• 跨组织业务相关的单据，可以由两种方式实现数据权限：
• 一是在每类单据表头 添加一个来源组织字段，查询数据时过滤条件为：单据.单据头.来源组织 = 用户.当前组织， 这种方式简单粗暴，甚至可以不用顾及  协同路线。
• 二是通过平台提供一个方法，这个方法用于获取 当前类型的单据 该用户 能够查看的单据ID（基础数据来源于参照生单记录）。  传入参数：  单据类型、当前用户、当前组织。  返回参数：单据ID。   业务组开发 拿到这个返回参数，作为查询条件 过滤数据。

以上是个人的一些分享与总结，欢迎交流碰撞。 Q304418200.