2.1维度

使用场景

包括不同合并场景，如实际数合并、预算合并、滚动预测合并等。

属性

资产负债类科目存储：当期发生额/累计余额

损益类科目存储：当期发生额/累计余额

⚠️目前合并2.5只支持资产负债类科目存储按累计余额存储，损益类科目存储按累计余额存储。

标准方案建议

维度成员编码规则

• 使用具体场景英文

• 首字母大写

维度成员参考建议

• Actual-实际数

项目实施经验

一般合并项目多集中在实际数据的合并报表出具，一般来说Scenario维度设置一个Actual即可。

也有一些项目会有预算合并需求，建议顾问视客户情况添加预算场景，如 AOP Budget Forecast 等等。

使用场景

合并场景多版本使用，如预算第一稿合并/第二稿合并、草稿/对外披露版等。

属性

自上而下：仅版本类维度成员具有该属性值，当该属性不勾选时，在财务数据模型中该版本上的数据不允许存储在通用类维度的父级节点上，而在显示数据时，通用类维度的父级成员的数据会自动从其子级成员根据比重汇总上来。而当该属性勾选时，则该版本的数据可以填写在通用类维度的父级节点上，并且在读取的时候直接从父级节点成员上读取，不再从子级做汇总计算

⚠️合并2.5不得使用自上而下功能

标准方案建议

维度成员编码规则

• 使用具体版本英文

• 首字母大写

  维度成员参考建议：

• Working - 工作版

使用场景

区分合并报表披露的不同年份，一般代表财年。一般常规合并应用初始化创建10年的成员，不建议过多，后续可以随系统使用情况酌情添加。

标准方案建议

维度成员编码规则

• 使用纯数字

• 成员可自定义

维度成员参考建议

一般常规合并应用初始化创建10年的成员，不建议过多，后续可以随系统使用情况酌情添加。

使用场景

合并报表披露相关的不同月份、审计调整期间、季度、半年、年度等。允许创建一个审计调整期，放在系统标准的第12期之后。

期间层级设置

View版本包括：未启用变动维、启用变动维

属性

层级：根据期间层级配置自动生成

⚠️合并2.5最小层级必须为月

标准方案建议

在需要增加单独审计调整期的情况下，项目组自行在Period维度的Q4下面增加

• 13 - 调整期

使用场景

参与合并计算的实体，包括法定/管理合并范围内各控股公司、子公司、分公司；也可以包括要在合并系统里做权益法调整的合联营公司等。

属性

本位币：

实体类维度的属性栏 > 本位币 可选择其他通用类维度，作为关联的本位币维度并显示所关联维度的路径；

实体类维度成员的 本位币 值，即可从关联的本位币维度成员中选择；

实体激活表配置

标准方案建议

遇到多架构或者同控合并的情况时，采用共享成员的方式来实现以上需求。一般来说，entity成员一旦建立不做删除处理（保留历史数据），不想让它出现在法定/管理架构时，通过实体激活表来控制，或者建立一个废弃entity的架构，将弃之不用的entity成员放在其下面。

使用场景

一般用于区分内部关联方数据所属的关联方，如内部往来交易数据、长期股权投资数据等。

标准方案建议

建议设置总的父级节点TotalPartner，在其下面设置NoPartner代表不区分关联方数据，Internal代表内部关联方合计,External代表外部客商合计。

其中，标准方案中上述成员编码不可更改，否则会影响到后续合并算法的正常运行。其别名、父子层级结构、比重等信息可以自行更改。

项目实施经验

Partner结构可依据客户的具体情况和顾问实施习惯酌情变通。

如：将NoPartner不区分关联方数据；Internal代表内部关联方数据

如：除内部关联方外，披露相关的供应商/客户信息也放在Partner维度中等等

如遇到客户ERP总账模块中就有客商字段的，这边建议将External也放在TotalParner下面，保持合并科目余额表与客户总账科目余额表颗粒度一致。

以上情况系统不做限制，但需要顾问注意对应Partner的不同设计需要同时对合并算法的一些细节调整，方可实现客户最终需求。

使用场景

记录合并主要过程，包括单体报表、单体调整、折算、公允价值调整、权益法调整、抵销等全流程数据。成员值根据多版本实体维度关联的本位币维度自动生成，不允许手工增减。

使用场景

审计线索，记录ERP账数据、重分类、折算、公允价值调整、权益法调整、各种类型抵销、未实现利润等合并全过程明细记录。通常搭配Value维度一起使用，共同组成合并审计工作底稿的调整明细。除审计线索外，还具备一些表外信息记录功能：如购买日数据等。

标准方案建议

注意audittrail在工作底稿和合并算法的适配性，具体见：

3.3Value和AuditTrail的关系

使用场景

科目维度，包括COA，各种主表、附注报表项，其他计算过程所需科目。

属性

数据类型：文本、数字、比率

科目类型：资产、负债、权益、收入、费用、时点数、期间数、标签。不同的科目类型在具体应用时的主要不同点，下表供参考：

是否允许在父级节点输入：当该属性勾选时，在财务数据模型中，该科目可以在其他通用维度的父级节点上直接录入数值，而在取数时，会直接从父级节点上读取，而不会根据其子节点做自动汇总。

比重：该属性决定向父级节点汇总的比重，<比如，下面科目余额示例中<BS20400000-固定资产=BS20401000-固定资产原价比重(1)+BS20402000-减：累计折旧比重(-1)+BS20403000-减：固定资产减值准备比重(-1)=1,000,000.001+100,000.00*(-1)+50,000.00*(-1)=850,000.00

<科目余额示例：

使用场景

变动项，包括系统预置余额、期初、增加、减少、汇兑差异、期末等；也包括为了所有者权益变动表、附注披露等其他功能自定义增加的一系列变动明细项。

属性

变动类型：OPN/INC/DEC/BAL

对应期末余额：变动类型为OPN的成员必须填写对应结转的期末成员

Movement对财务模型逻辑影响

movement类型会影响财务模型在不同的view之间的切换逻辑。

具体逻辑举例可参见

2.3Period+Movement+View逻辑

标准方案建议

对于附表披露或管报需求，根据客户需求酌情增加movement的对应成员和相关合并逻辑。

对于OPN成员，一般来说各种不同报表OPN金额应该相同，可以用共将OPN多次共享的方式，来实现各种报表期初数据的披露功能。

使用场景

计量合并报表中Periodic（期间发生数） YTD MTD QTD HYTD 等不同视角的各种累计数、发生数等信息。成员值根据Period维度自动生成，不允许手工增减。

标准方案建议

根据Period结构自动生成以下成员：

• Periodic

• YTD

• MTD

• QTD

• HYTD