优化
This commit is contained in:
+1
-1
@@ -18,7 +18,7 @@ Finance 中必须分开建模：
|
||||
- **客户用户/成员**：制单、复核、确认、收款登记等操作人，保存 `userId/memberId` 和当时的姓名快照；
|
||||
- **角色与权限**：平台角色由平台维护，客户角色由客户在允许的权限目录内维护，任何角色都不能越过客户范围。
|
||||
|
||||
若业务口语中的“客户就是主体”是指“客户是业务数据主体/结算对象”，可以采用；若指“财务法律主体/账套”，则不能直接等同，需由 F0-02 单独确认。
|
||||
已确认首期采用“一客户企业＝一个对客结算对象”。这里的客户是业务数据归属和应收结算对象，不等同于平台收付款、开票和核算的法律主体；平台财务主体/账套仍单独建模。首期不支持一个客户配置多个对客结算对象或独立账套。
|
||||
|
||||
`firstleg-service` 保持现有业务边界，只负责：
|
||||
|
||||
|
||||
+1
-1
@@ -41,7 +41,7 @@
|
||||
|
||||
| 编号 | 需要确认的事项 | 建议结论 | 最终结论 | 状态 |
|
||||
|---|---|---|---|---|
|
||||
| F0-11 | 客户与财务主体关系 | 客户企业作为客户数据归属和结算对象；平台财务主体/账套单独建模；首版一个客户对应一个有效结算档案，客户子用户不成为新主体 | 待填写 | 待确认 |
|
||||
| F0-11 | 客户与财务主体关系 | 客户企业作为客户数据归属和对客结算对象；首期一客户一结算对象；平台财务主体/账套单独建模，客户子用户不成为新主体 | 一客户企业对应一个对客结算对象；客户子用户共享本客户财务范围；平台收付款/开票主体独立 | 已确认 |
|
||||
| F0-12 | 客户子用户数据范围 | 具有财务权限的客户子用户默认查看本客户全部账单，不按“本人创建”切分；部门范围另行定义 | 待填写 | 待确认 |
|
||||
| F0-13 | 客户财务权限分配 | 平台定义权限目录和越界规则；客户管理员仅能在本客户内创建角色并分配允许的客户侧权限 | 待填写 | 待确认 |
|
||||
| F0-14 | 平台与客户财务动作边界 | 客户侧查看、确认/争议和发票申请；收付款登记、核销/反核销、关账、应付、成本和利润属于平台财务权限 | 待填写 | 待确认 |
|
||||
|
||||
+2
-1
@@ -34,7 +34,8 @@
|
||||
- **当前对话已确认**：产品只有平台、客户两种身份；平台维护平台角色/用户，客户维护本客户角色/用户。
|
||||
- **技术已确认**：客户用户的财务操作上下文必须来自服务端当前客户成员关系和权限快照；不能信任前端传入的 `customerId/tenantId`，也不能让客户用户切换到其他客户范围。
|
||||
- **技术已确认**：财务单据保存操作人的 `userId/memberId`、角色/权限快照标识和操作时姓名快照；成员停用只撤销后续访问，不改历史单据。
|
||||
- **产品待确认**：客户用户默认查看本客户全部财务数据，还是继续按部门/业务线细分；客户管理员可分配哪些客户侧财务权限；付款、退款、反核销和关账是否强制职责分离。
|
||||
- **当前对话已确认**：首期一个客户企业唯一对应一个对客结算对象；不支持一个客户多个对客结算对象或独立账套。客户用户默认仍共享本客户财务数据边界，具体动作由角色权限控制。
|
||||
- **产品待确认**：客户用户是否继续按部门/业务线细分数据范围；客户管理员可分配哪些客户侧财务权限；付款、退款、反核销和关账是否强制职责分离。
|
||||
- **术语约束**：客户企业是客户数据归属/结算对象；平台收付款、开票和核算的法律主体仍以 Finance 的 `FinancialEntity`/账套表达。客户子用户永远不是新的财务主体。
|
||||
|
||||
### 2.4 金额、币种和精度
|
||||
|
||||
Reference in New Issue
Block a user