174 lines
8.9 KiB
Markdown
174 lines
8.9 KiB
Markdown
# 需求文档：管理人多维财务核算系统 (M-FAS)
|
||
**版本**：v1.0 | **优先级**：P0 | **受众**：后端架构师、数据工程师
|
||
|
||
## 1. 核心设计理念
|
||
本系统旨在构建一个介于**前端业务数据（灵活、多维）** 与 **传统会计系统（合规、刚性）** 之间的独立** “会计引擎（Accounting Engine）” **。
|
||
核心理念是：“去科目化、重维度化”。摒弃传统金蝶/用友的“多级会计科目”挂账模式（如 `6601.01.05 销售费用-家办-张三`），采用**“扁平科目 + 必须维度标签”**的数据库结构。
|
||
|
||
**系统行为逻辑：**
|
||
任何一笔收入或支出（Journal Entry Line），在入库时**必须**携带维度标签。所谓的“剩余/中后台”，在系统底层不应通过“减法”计算存储，而应作为**“默认兜底标签（Default Bucket）”**进行归集，报表展示时再按层级聚合。
|
||
|
||
---
|
||
|
||
## 2. 维度架构定义 (Database Dimensions)
|
||
|
||
我们需要在凭证行表（`finance_journal_lines`）中扩展以下字段。
|
||
|
||
### Level 1：核心业务板块 (`dim_segment`)
|
||
对应需求中的第一层级。该字段为**必填项**。
|
||
|
||
| 枚举值 (Value) | 业务含义 (Description) | 逻辑定义/自动化规则 |
|
||
| :--- | :--- | :--- |
|
||
| **PM_Strategy** | PM/策略团队 | 凡是直接归属于特定PM管理的基金产生的收入、直接发生的策略研发成本（服务器/数据/人员）。 |
|
||
| **Marketing** | 市场部 | 纯品牌推广、非家办渠道的机构募资费用。 |
|
||
| **Family_Office** | 家办整体 | 对应家办业务线的所有收支（将触发Level 2必填校验）。 |
|
||
| **Corp_BackOffice** | 基金中后台 (剩余) | **默认值**。既不属于PM，也不属于市场和家办的通用行政、合规、房租、核心管理层成本。 |
|
||
|
||
### Level 2：业务子维度 (`dim_sub_segment`)
|
||
不再局限于家办，所有 Level 1 业务线均可定义自己的子维度。
|
||
|
||
| Level 1 | 枚举值 (Value) | 业务含义 (Description) |
|
||
| :--- | :--- | :--- |
|
||
| **Family_Office** | **FO_Sales** | 家办员工 (销售) |
|
||
| **Family_Office** | **FO_Channel** | 家办渠道 |
|
||
| **Family_Office** | **FO_Admin** | 家办中后台 (默认) |
|
||
| **Marketing** | **MKT_Online** | 线上投放 |
|
||
| **Marketing** | **MKT_Offline** | 线下活动 |
|
||
| **PM_Strategy** | **Strat_Equity** | 股票策略 |
|
||
| **PM_Strategy** | **Strat_CTA** | 期货策略 |
|
||
|
||
### Level 3：精细化对象 (Specific Objects)
|
||
为了避免“多态ID”带来的外键约束缺失问题，**严禁**使用单一的 `dim_object_id`。
|
||
数据库应设计分离的可空列（Nullable Foreign Keys）：
|
||
|
||
* **`dim_product_id`**: 关联产品表 (Product Table)
|
||
* **`dim_employee_id`**: 关联员工表 (Employee Table)
|
||
* **`dim_vendor_id`**: 关联客商表 (Vendor Table)
|
||
|
||
**填值规则**：根据业务场景填充对应列，其余列留空。例如支付阿里云费用，填充 `dim_vendor_id`，而 `dim_employee_id` 为空。
|
||
|
||
---
|
||
|
||
## 3. 自动化记账规则引擎 (Automation Logic)
|
||
|
||
为了实现“自动化”，需开发一个**预处理中间件**，在银行流水或业务单据生成凭证前，进行标签清洗。
|
||
|
||
### 规则 1：基于“人员/客商”的自动打标
|
||
建立一张全局映射表（Mapping Table），系统根据收付款对象自动填充维度。
|
||
|
||
* **IF** 报销人/收款人 = "张三" **AND** 张三在HR表属性 = "家办销售"
|
||
* **THEN** `dim_segment` = **Family_Office**, `dim_sub_segment` = **FO_Sales**
|
||
* **IF** 收款人 = "招商证券" (托管费) **AND** 备注包含 "产品A"
|
||
* **THEN** `dim_segment` = **PM_Strategy**, `dim_object_id` = **Product_A**
|
||
* **IF** 收款人 = "阿里云"
|
||
* **THEN** 触发 **Split Transaction (拆单)** 逻辑，按预设比例分摊至不同PM，生成多行凭证。
|
||
|
||
### 规则 2：基于“默认兜底”的减法逻辑实现
|
||
需求中提到的“剩余”概念，在系统录入时体现为**默认值**。
|
||
|
||
* **场景**：支付公司整体房租 100,000元。
|
||
* **处理**：
|
||
* 系统无法判断房租属于哪个PM或家办。
|
||
* **Action**：直接打标 `dim_segment` = **Corp_BackOffice**。
|
||
* **报表逻辑**：
|
||
* 用户看到的“基金中后台” = `Sum(Corp_BackOffice)`。
|
||
* 用户看到的“家办中后台” = `Sum(Family_Office) WHERE dim_sub_segment = FO_Admin`。
|
||
|
||
---
|
||
|
||
## 4. 报表视图需求 (Output Requirements)
|
||
|
||
系统需前端需支持动态透视表（Pivot Table）展示，逻辑如下：
|
||
|
||
### 视图 A：公司整体损益 (Level 1 View)
|
||
* **收入/成本/费用 总额**
|
||
* **PM板块** (聚合所有 `PM_Strategy`)
|
||
* *点击展开可看具体 PM1, PM2, PM3*
|
||
* **市场部** (`Marketing`)
|
||
* **家办整体** (聚合所有 `Family_Office`)
|
||
* **基金中后台** (`Corp_BackOffice`)
|
||
* *(备注：此处即为需求中的“剩余”部分)*
|
||
|
||
### 视图 B：家办专项损益 (Level 2 Deep Dive)
|
||
* **筛选条件**：`dim_segment` = **Family_Office**
|
||
* **家办员工** (`FO_Sales`)
|
||
* *点击展开可看具体 Sales_A, Sales_B*
|
||
* **家办渠道** (`FO_Channel`)
|
||
* **家办中后台** (`FO_Admin`)
|
||
* *(备注：此处即为需求中的“家办剩余”部分)*
|
||
|
||
---
|
||
|
||
### 给技术团队的特别备注 (CFO Notes)
|
||
1. **数据清洗优先**：请优先开发“客商/人员”与“维度标签”的绑定配置页面，这是自动化的基础。没有这个，财务还是得手工录入。
|
||
2. **必须支持一拆多 (Split Transaction)**：不要仅仅“预留接口”。在 V1.0 的数据库设计中，必须直接支持 **1行银行流水 $\rightarrow$ N行财务凭证** 的父子表结构。这是高频刚需。
|
||
3. **PM与产品的关系**：建议建立明确的 Product 表和 Employee 表，处理好 managed_by 的时间维度关系。
|
||
|
||
---
|
||
|
||
## 5. 技术架构总体设计 (Technical Architecture)
|
||
|
||
### 5.1 整体架构逻辑：财务数据中台模式
|
||
|
||
系统架构分为三层：**数据接入层（Input）**、**核心处理层（Process）**、**合规输出层（Output）**。
|
||
|
||
#### 1. 数据接入层 (Data Ingestion)
|
||
负责将非标准的业务数据统一为系统可读的格式。
|
||
* **资金流数据**：银行对账单（Excel/API）、第三方支付流水。
|
||
* **业务流数据**：外部估值表、应收台账（管理费/业绩报酬）、应付台账（渠道佣金）。
|
||
* **核心动作**：清洗（Cleaning）、去重（De-duplication）、标准化（Normalization）。
|
||
|
||
#### 2. 核心处理层 (The Core Engine)
|
||
系统的核心逻辑层，包含以下模块：
|
||
|
||
* **智能打标 (Dimension Injection)**：
|
||
* **规则引擎**：基于关键词、账号、金额等规则自动匹配维度。
|
||
* **人工补录**：对于置信度低的数据，提供界面供财务人员手动打标。
|
||
* **产出**：带有完整业务维度（PM、家办、渠道、员工）的宽表数据。
|
||
|
||
* **业务对账 (Reconciliation)**：
|
||
* 自动匹配运营台账与银行流水，实现应收/应付的自动核销。
|
||
|
||
* **会计引擎 (Accounting Engine)**：
|
||
* 基于预设的“场景-分录映射表”，将业务动作转化为标准化凭证数据（借：销售费用 / 贷：银行存款）。
|
||
|
||
#### 3. 合规输出层 (Output Adapter)
|
||
* **目标**：传统会计软件（金蝶/用友）。
|
||
* **实现**：通过API对接或生成标准导入模版（Excel/XML），实现凭证自动推送。
|
||
|
||
### 5.2 系统运作流程图 (Data Flow)
|
||
|
||
```mermaid
|
||
graph TD
|
||
A[数据源] -->|Excel/API| B(数据清洗模块 ETL)
|
||
B --> C{规则引擎 + AI辅助}
|
||
|
||
C -->|高置信度| D[已打标中间表]
|
||
C -->|低置信度| E[人工审核界面 UI]
|
||
E -->|人工确认| D
|
||
|
||
D --> F{会计分录生成器}
|
||
F -->|读取映射配置| G[标准凭证数据]
|
||
|
||
G --> H[传统会计系统适配器]
|
||
H -->|API/Excel| I[最终会计软件 (Kingdee/Yonyou)]
|
||
|
||
subgraph 核心中台
|
||
B
|
||
C
|
||
D
|
||
E
|
||
F
|
||
G
|
||
H
|
||
end
|
||
```
|
||
|
||
### 5.3 关键实施要素 (Critical Success Factors)
|
||
|
||
1. **权责发生制支持**：系统需从设计之初考虑“挂账”与“核销”逻辑，以兼容运营台账（权责发生制）与银行流水（收付实现制）的差异。
|
||
2. **数据唯一性保障 (Advanced Deduplication)**：
|
||
* 简单的MD5(日期+金额)不足以防重（如同日同给同一人的两笔相同报销）。
|
||
* **改进方案**：引入 **“期末余额 (Ending Balance)”** 校验，或在哈希因子中加入“流水号/Sequence ID”。
|
||
* **兜底机制**：对于完全相同的疑似重复交易，系统应标记为 `Duplicate_Suspect`，强制要求人工审核确认是“重复记账”还是“真实发生的第二笔交易”。
|
||
3. **人工介入机制 (Human-in-the-Loop)**：系统必须遵循“机器预处理 -> 人工确认 -> 正式过账”的流程。在推送到金蝶/用友之前，必须保留人工审核的节点，确保财务数据的绝对准确性。 |