搜索

文档中心预算预算建模维度管理

维度管理

维度管理是预算应用的口径基础，决定了预算数据”按什么分、怎么汇、如何比”。维度设计是否稳定、一致，直接影响填报、汇总、分析和对比的准确性。

预算应用的维度能力建立在平台维度组件之上。维度组件提供了 11 种维度类型和完整的成员管理、表达式查询、权限控制等基础设施；预算应用在此基础上，按业务角色对维度进行组合使用，形成组织、科目、时间、场景、版本和通用业务分析等预算口径。下文按预算业务视角介绍各类维度的用途，同时说明其在系统中对应的维度类型和配置要点。

如需了解维度组件的完整功能，请参考维度概览。

预算维度配置示例

预算应用通常通过资源管理统一组织维度、财务模型、表单、流程等配置元素。下图以预算 demo 应用为例，展示维度资源如何按业务用途分组；实际项目可根据客户模型、主数据来源和实施规范调整目录结构。

预算模型通常会集中使用组织、科目、数据线索、类型等核心维度；如存在多币种预算需求，可再增加币别口径。实施时应先完成这些维度的成员、层级和属性维护，再创建或调整财务模型和预算表单。

组织维度的编辑页提供 树形视图、表格视图、时效性视图 三种维护方式。树形视图适合维护组织上下级关系；表格视图适合批量维护成员属性；时效性视图适合处理不同版本、年度或期间下的组织有效性。

表格视图用于按行维护成员，适合批量新增、删除、导入、导出和全量编辑成员属性。相比树形视图，表格视图更适合处理大量成员的标准化维护动作。

时效性视图按行展示组织成员、按列展示年份和期间等管控维组合，通过 Y / N 标记成员在对应组合下是否有效。该视图适合处理组织架构随预算年度、版本或期间变化的场景。

特殊维度类型说明

除组织、科目、时间、场景、版本等常规预算口径外，预算模型中还可能使用一些平台维度组件提供的特殊维度类型。应用文档中不需要逐项展开组件能力，但应说明这些维度在预算模型中的业务角色。

通用类 是预算模型中最灵活的维度类型，可用于产品、客户、项目、渠道等业务分析口径，也可以用于组织类型、科目类型、数据来源等辅助分类。设计时应先判断该口径是否需要长期参与模板填报、模型汇总和分析对比，避免把临时口径都做成模型维度。

备注：维度组件中的 Value 值类 主要用于合并场景，表示本位币数、上级币种数、抵销数等值口径。组件文档说明 Value 维不单独创建，而是在实体维关联本位币后由系统自动生成；多版本实体维的基础配置与实体维一致，因此如果启用了本位币关联，也会沿用这套生成机制。常规预算模型通常不需要把 Value 维作为业务维度来设计。

预算常用维度总览

预算模型的维度设计可以参考 Oracle Planning 等预算系统的惯用口径：用组织承载责任主体，用科目承载指标口径，用 年/期间 承载时间，用 场景/版本 区分数据用途和编制阶段，再按业务需要增加产品、客户、项目等自定义分析维度。这样的设计便于模板填报、自动汇总、版本对比和预实分析在同一套口径下运行。

预算口径	系统维度类型	业务作用
组织	实体类 / 多版本实体类	确定预算责任主体、权限范围和组织汇总路径
科目 / 指标	科目类	定义收入、成本、费用、利润、数量、单价等预算指标
年	年份类	区分预算所属财年
期间	期间类	区分月、季、半年、全年等期间粒度
场景	场景类	区分预算、实际、预测、测算等不同数据用途
版本	版本类	区分同一场景下的不同编制阶段或数据状态
币别（如需）	通用类	区分交易币、预算币种等金额口径
数据线索 / 数据来源	通用类	区分录入、导入、计算、调整等数据来源或审计线索
通用维（产品、客户、项目、渠道等）	通用类	支撑销售、人力、项目、资本支出等业务维度分析

维度设计应优先保证核心预算口径稳定，再扩展通用业务分析维度。组织、科目、年、期间、场景、版本通常是预算主模型的基础口径；产品、客户、项目等通用维应根据模板和分析需要选择使用，避免模型维度过多导致模板配置、权限配置和查询分析复杂化。

组织维管理

组织维用于确定预算编制的责任主体和数据汇总路径。在系统中，组织维通过 实体类 维度实现——维度组件中的”实体维”在预算业务中扮演的就是组织维的角色。

组织维成员与层级

系统支持按集团管理架构维护组织维（实体维）的成员及其层级关系。典型的组织层级包括集团总部、区域/板块、子公司、部门等。组织层级定义了数据的汇总路径——下级组织填报的数据会沿层级自动汇总到上级组织。

组织维支持维护多套组织架构并行。例如，企业可以同时维护法人架构和管理架构，用于不同的预算编制和分析场景。如果不同架构共享部分组织成员，可以使用维度层级中的 共享节点 能力，让同一成员挂在多个父级下，无需重复创建。共享节点不是实体维独有能力，其他支持层级管理的维度也可以按业务需要使用。

科目维管理

科目维（指标维）

科目维用于区分预算数据的业务含义和口径，是预算系统中最核心的分类维度。在系统中对应 科目类 维度。科目维成员通常对应预算项目或财务科目，如收入、成本、费用、利润等。

科目维支持多层级管理，可以按”大类—中类—明细”的层级结构组织科目，支持按层级自动汇总。预算项目中通常会把科目维设计成一套“预算指标树”，既包含收入、成本、费用、利润等财务指标，也可以包含数量、单价、人数、面积等业务指标。这样做的好处是：模板可以按科目范围展开，模型可以沿科目层级汇总，分析报表也可以按同一套指标口径钻取。

科目类成员关键配置项

科目类成员比通用维成员多一些专属配置，主要用于控制数据类型、汇总方向和是否允许在通用维父级节点直接录入。

配置项	作用	预算场景建议
数据类型	控制该科目存储的数据形态，支持数字、文本、比率、日期、维度等；在电子表格模板中会影响单元格的录入方式、展示格式和基础校验	金额、数量、单价、人数通常使用数字；毛利率、费用率等比例指标可使用比率；说明类指标可使用文本
科目类型	控制科目的财务方向、是否存储数据以及部分模型汇总口径；常见类型包括资产、负债、权益、费用、收入、期间数、时点数、标签、无科目类型	常规预算先按实际指标口径选择，不必为了简单月度预算强行使用所有科目类型；率类、单价、占比等派生指标通常不要当作金额科目直接汇总
允许在父级节点输入	开启后，该科目可以在通用维父级节点直接录入数值，读取时直接从父级取数，不再按通用维子级汇总	仅适合不要求按通用维末级拆分、但需要在汇总层级直接填报的指标；不建议对所有科目默认开启

数据类型

数据类型决定科目成员能存什么值，也会在电子表格预算模板中体现出来。模板按科目展开后，系统可以根据科目的数据类型控制单元格的录入方式、展示格式和基础校验，例如数值类单元格适合配置千分位、小数位和金额格式，比率类单元格适合展示为百分比，文本类单元格适合录入说明性内容。

预算模型中不要把所有指标都简单处理成金额类数字，建议按指标用途区分：

金额类指标：收入、成本、费用、利润、资本支出金额等，通常使用数字。
数量类指标：销量、人数、工时、面积、台数等，也使用数字，但在模板中应通过单位、格式或说明区分。
比率类指标：毛利率、费用率、增长率、完成率等，适合使用比率类型，避免与金额类指标混用。
说明类指标：预算说明、调整原因、审批备注等，如果确实需要进入模型，可使用文本类型；如果只是表单辅助信息，也可以通过单元格备注或附件承载。

科目类型

科目类型不是单纯的展示分类。维度组件文档中明确：资产、费用为借方科目，负债、权益、收入为贷方科目；标签类成员不存储数据；科目类型会影响模型中的汇总逻辑。涉及当期、累计、期初、期末等期间口径时，统一在后文“是否启用累计数/View”中判断。

常规预算通常以月度填报、季度/年度汇总为主，不会用到所有科目类型。销售预算、费用预算、人力预算等场景里，用户更多录入的是销量、人数、工时、单价、金额等当期发生类指标，科目类型不应被设计得过重。

常规预算可以按下面的方式简化处理：

指标类型	常见例子	建议
经营发生类指标	销量、收入、费用、工时、服务次数、订单数	按月填报、按期间汇总即可；金额类可按收入或费用设置，非财务业务量可统一使用期间数或无科目类型
分组或标题节点	收入类指标、费用类指标、经营指标	使用标签类成员，不存储数据，只用于组织科目树
派生指标	毛利率、费用率、完成率、单价、占比	不直接汇总，通常通过计算规则倒算；需要时可使用无科目类型，避免套用收入/费用等财务方向

资产、负债、权益等科目类型更多用于资产负债表预算、现金流预算、营运资本预算等复杂财务口径。普通经营预算如果只是填当期销量、人数、费用、收入，不需要为了“完整”使用这些类型。

比率类科目的设置

利润率、毛利率、费用率、完成率、占比、单价等指标不能简单按子级比率求和，也通常不应直接平均。标准做法是 先汇总基础量，再计算比率。例如毛利率应按汇总后的收入和成本倒算：

Copy

毛利率 = (营业收入 - 营业成本) / 营业收入

这类科目建议按以下方式配置：

数据类型：设置为比率，这样电子表格和透视展示可以按百分比、小数位等比率格式处理。
科目类型：如果该科目不需要资产/负债/权益/收入/费用的财务方向，通常设置为 无科目类型；不要把利润率配置成收入或费用。
计算方式：通过计算规则写入结果，公式中用基础科目倒算。例如先得到收入、成本、利润等基础量，再计算毛利率或利润率；分母为 0 时应在规则中处理为空或 0，避免除零。
父级节点取数：如果需要在组织、产品、项目等通用维父级查看率类结果，应在父级口径上按汇总后的基础量重新计算并写回，不要依赖子级比率自动汇总。需要直接读取父级写回结果时，可以配合 允许在父级节点输入。
比重：如果率类科目挂在科目树的分类节点下，且不希望参与父级求和，应避免让它按普通金额科目参与上卷；实施时可通过标签类分组、比重控制或计算规则单独处理。

允许在父级节点输入

该配置解决的是“某个科目是否允许在通用维父级节点直接录入”的问题。默认情况下，通用维父级节点的数据通常由子级按比重汇总；开启后，系统读取该科目在通用维父级节点的数据时，会优先使用父级直接录入值，不再强制从子级汇总。

适合开启的场景：

目标下发类指标：总部先按产品大类、项目大类或区域大区录入收入目标、费用额度，再由下级继续分解。
不需要末级拆分的指标：例如某些管理指标只要求在产品大类或项目大类层面填报，不要求拆到每个末级产品或项目。
汇总层人工调整项：例如集团层面对某类费用预留统一调整金额，不希望被末级明细自动覆盖。

不建议开启的场景：

必须由末级明细汇总的指标：如按产品明细汇总的销量、按项目明细汇总的资本支出、按人员明细汇总的人力成本。
需要严格穿透到明细的分析指标：如果管理层需要从父级金额下钻到子级构成，父级直接录入会削弱明细解释能力。
所有科目一刀切开启：这样容易让同一张表里部分父级数来自汇总、部分父级数来自录入，造成用户难以判断数据来源。

该配置与版本维的 自上而下 属性需要区分：版本维的自上而下更偏向“某个版本是否允许在通用维父级录入”的整体编制方式；科目维的“允许在父级节点输入”更偏向“某个指标是否允许这么录”。在财务模型取数逻辑中，版本维开启自上而下，或科目维开启允许在父级节点输入，满足任意一种情况时，通用维父级数据都会直接从父级节点读取，而不是继续按子级汇总。

在不同模板或分析场景中，可以通过维度表达式定义科目成员的动态范围，精确控制可用科目。例如，用 Descendant(费用合计,0) 表示费用合计节点下的全部后代科目，无需手动枚举。

时间维与场景维管理

时间维

时间维定义预算数据的期间粒度和时间范围。在系统中，时间维由 年份类 和 期间类 两个维度组合构成——年份类定义财年，期间类定义会计期间层级（年/季/月等），两者配合使用共同构成完整的会计时间轴。

期间维的成员无需手动逐条创建：配置期间层级后，系统自动生成对应的期间成员。常规预算一般按月填报，季度、年度可以通过期间层级、报表汇总或计算规则得到。

是否启用累计数/View

累计数/View 不是预算模型的默认必选项，应按实际业务是否需要统一期间口径来判断。

通常 不需要启用 的场景：

常规经营预算：销售预算、费用预算、人力预算等按月填报销量、人数、费用、收入，季度或年度只是月份合计。
少量累计展示：只是在某几张报表中展示截至当前月累计，可以由报表公式或计算规则处理。
没有期初/期末滚动关系：业务只关心“本月发生多少、全年合计多少”，不需要系统理解 Opening、Closing 等口径。

建议 启用累计数/View 的场景：

资产负债表预算：应收、应付、存货、现金、固定资产、借款等余额类指标，需要管理期初、本期变化和期末。
现金流预算和营运资本预算：需要从期初现金或期初余额滚动到期末余额，并在不同期间口径下复用。
库存、应收应付、固定资产等余额预算：业务需要稳定查看当期、累计、期初、期末等口径，而不是每张表单单独写公式。
预算和实际口径对齐：实际数已经按 Periodic、YTD、Opening、Closing 等 View 口径管理，预算需要用同一口径做预实对比。

简化判断：如果只是“各月填报、季度/年度汇总”，通常不开；如果业务要求模型统一管理 当期、累计、期初、期末，并且这些口径会被多个模板、报表或计算规则反复使用，就应考虑启用。

场景维

场景维用于区分不同业务目的下的数据集合，最常见的场景包括预算、实际、预测三类。在系统中对应 场景类 维度。通过场景维，同一套维度和模型可以承载不同来源的数据，并支持预实对比、预测偏差分析等业务场景。

场景类维度可以关联年份维和期间维，为每个场景成员配置 生效的年份和期间范围。这在滚动预测中尤为重要——不同轮次的预测可以有各自的时间范围，避免误写历史数据。

版本维

场景维与 版本维（版本类维度）配合使用，定义数据的有效组合。例如，”2025年预算-Working””2025年预算-定稿版””2025年实际-月结版”分别代表不同场景和版本的数据切片。

类似 Planning 系统的常见用法是：场景表示数据用途，版本表示数据状态。例如，Budget 场景下可以有 Working、Submitted、Approved、Final 等版本；Forecast 场景下可以有 3+9预测、6+6预测、9+3预测 等版本。这样既能保持预算、实际、预测之间的用途边界，也能保留同一用途下的多轮编制和审批轨迹。

建议至少设置一个 Working 版本作为编制和试算版本。Working 版本用于业务用户录入、反复调整和测算，不直接代表正式下达口径；审批通过或管理层确认后，再复制或发布到定稿版、下达版或调整版。这样可以避免用户在正式版本上直接试算，同时保留草稿、评审、定稿之间的数据演进过程。

版本维的成员支持设置”自上而下”属性：开启后，通用维度的父级节点可以直接录入数据，不再由子级汇总，适用于自上而下分解目标的编制场景。例如总部先在父级组织或父级产品上录入目标，再由下级组织继续分解。

场景	常见版本	典型用途
Budget	Working、Submitted、Approved、Final	年度预算编制、上报、审批、定稿
Forecast	Working、3+9预测、6+6预测、9+3预测	滚动预测和月度/季度经营预估
Actual	Actual、月结版	实际数导入、预实对比和执行分析
What-if	Working、方案A、方案B	临时测算、经营假设比较和管理层决策支持

通用维（业务维）管理

预算业务中常说的业务维，在系统中通常通过 通用类维度 实现。通用维是最灵活的分析维度，可以按需承载产品、客户、项目、区域、渠道、岗位、资产类别等业务分类口径。

通用维的成员和层级配置方式与普通层级维度一致。通过在不同模板中选用不同通用维和维度表达式，可以控制填报颗粒度和分析视角。例如销售预算可以选择产品、客户、渠道等通用维；资本支出预算可以选择项目、资产类别等通用维；人力预算可以选择岗位、人员类别等通用维。

通用维的父级数据通常由子级按比重自动汇总。版本维开启”自上而下”属性后，也可以允许在通用维父级节点直接录入数据，用于目标下发和分解场景。设计通用维时应避免把所有业务口径都放入同一个主模型；只有需要长期分析、汇总或参与跨表单对比的业务口径，才建议作为模型维度。

不同预算主题的维度组合

不同预算模板不一定使用完全相同的通用维。预算主模型可以提供统一的数据底座，但每张表单应按业务主题选择必要维度和成员范围，避免用户在填报界面看到无关口径。

预算主题	常用维度组合	说明
销售预算	组织、产品、客户、期间、场景、版本；如需多币种再增加币别口径	适合按产品、客户、区域等口径编制收入、销量、单价
费用预算	组织、费用科目、费用项目、期间、场景、版本	适合按责任中心和费用类型编制管理费用、销售费用、研发费用
人力预算	组织、岗位/人员类别、期间、场景、版本	适合编制编制人数、薪酬、社保、公积金和人力成本
资本支出预算	组织、项目、资产类别、期间、场景、版本	适合编制新增资产、投资项目和资本性支出计划
三大表预算	组织、科目、期间、场景、版本；如需多币种再增加币别口径	适合输出利润表、资产负债表、现金流量表等固定格式报表
预实分析	组织、科目、期间、场景、版本、通用维	适合在预算、实际、预测之间做差异、完成率和趋势分析

表单设计时，可以通过维度表达式限制每张表的成员范围。例如销售预算只展开收入类科目和销售产品，费用预算只展开费用类科目，人力预算只展开人力相关指标。这样既能复用同一套维度和模型，也能让每个业务用户只看到与自己填报相关的口径。

维度成员与层级维护

成员维护

系统支持对维度成员进行新增、编辑和停用操作。停用的成员不会出现在新建的编制任务中，但已有的历史数据仍然保留。维度成员支持通过表格视图批量维护，也可以通过数据流或 DeepModel 从外部系统同步，适用于大规模主数据初始化或跨系统同步场景。

详见维度组件文档：配置维度、维度数据集成。

层级调整

维度层级支持灵活调整，包括成员的上下级关系变更、层级节点的新增与合并。层级调整后，系统自动更新汇总路径和下钻路径，确保数据在新层级下仍然可以正确汇总和穿透。维度层级最多支持 20 层，设计层级结构时应按实际业务需要规划，避免不必要的深层级。

成员范围控制

在模板、模型和分析场景中，通常需要精确控制可用的维度范围。系统通过 维度表达式 实现成员范围的动态定义，支持 Descendant（后代）、Children（直接子级）、Base（末级节点）、Level（指定层级）等函数，以及按条件组合过滤。例如，为费用预算模板定义 Base(费用合计,0) 即可精确选中费用合计下的全部末级科目，无需手动维护成员清单，维度成员增减后表达式结果自动更新。

维度范围不仅影响模型查询，也会影响预算模板中的筛选器、动态表展开范围和分析报表可查看范围。例如，某编制人只负责华东区费用预算时，组织维权限和模板筛选器应只开放华东区相关组织；费用预算模板中的科目范围应只展开费用类科目，避免误填收入、资产或其他无关指标。

如需进一步控制不同角色对维度成员的可见范围，可配置 维度权限方案。维度权限方案通常与预算流程配合使用，用于确定谁能填哪些组织、看哪些科目、审批哪些范围。

详见维度组件文档：维度表达式参考、配置维度权限方案。

使用建议

维度编码一旦保存不可修改，创建前应统一制定编码规范
维度基数类型（低基/普通/高基）保存后不可修改，创建前需根据预期成员规模选择。低基和普通维度使用 ClickHouse 字典表，全量成员加载进内存，查询速度极快，但受服务器内存上限制约；当成员量超出内存承载范围时，字典表可能加载失败或导致服务不稳定。高基维度使用普通磁盘表，查询性能略有降低但差异很小，核心价值是突破内存限制、保障大规模成员下的服务稳定性
维度成员数量建议控制在 50,000 以内；超过此规模需在创建时选择高基维度
自定义属性（UD）最多 60 列，层级最多 20 层；成员数量、层级深度、UD 列数三者叠加会影响保存性能