财务管理/README.md

@@ -1,7 +1,7 @@
 # 财务管理闭环盘点与范围建议
 
 > 盘点日期：2026-08-10  
-> 当前状态：需求分析，未进入开发  
+> 当前状态：开发前详细设计，未进入业务开发
 > 盘点范围：二期入库计费现状、平台后台财务原型、Admin/Client/Firstleg 当前实现  
 > 结论口径：本文区分“代码已实现”“原型展示”和“建议范围”；原型功能不自动成为开发范围。
 
@@ -13,9 +13,13 @@
 
 详细设计材料：
 
+- [财务来源接入现状](财务来源接入现状.md)
 - [财务领域模型与数据字典](财务领域模型与数据字典.md)
 - [Firstleg-Finance跨服务契约](Firstleg-Finance跨服务契约.md)
 - [财务历史迁移与上线验收方案](财务历史迁移与上线验收方案.md)
+- [财务F0实施任务拆分](财务F0实施任务拆分.md)
+
+历史合并稿：[财务领域模型与跨服务契约](财务领域模型与跨服务契约.md) 已由“领域模型与数据字典”和“Firstleg-Finance 跨服务契约”两份文档替代，不作为后续实施依据。
 
 ## 一、结论
 
@@ -318,6 +322,6 @@ DRAFT -> REVIEWED -> SENT -> CONFIRMED -> CLOSED
 1. 由产品/业务填写 F1-F12，冻结首期范围。
 2. 形成《客户应收闭环需求确认表》，明确页面、角色、状态和异常处理。
 3. 使用《财务管理产品确认表》完成 S1-S8、F0-F4 的产品确认。
-4. 服务边界已经技术确认；下一步形成《财务领域模型与跨服务契约》，细化 Finance 与 Firstleg 的事件、内部查询、版本和错误处理，不再重复讨论是否拆服务。
+4. 服务边界、领域模型草案和跨服务契约草案已经形成；下一步由产品填写 XLSX，按《财务开工门禁与 F0/F1 任务清单》放行 G1/G2，不再重复讨论是否拆服务。
 5. 形成《客户应收接口与权限契约》，包括错误码、幂等、数据范围和审计事件。
 6. 形成《历史费用迁移与上线方案》，避免已有线下结算数据被重复出账。

财务管理/财务F0实施任务拆分.md

@@ -1,5 +1,8 @@
 # 财务 F0 实施任务拆分与验收门禁
 
+> 当前状态：开发任务草案；《财务开工门禁与 F0/F1 任务清单》G1 放行前不得据此启动业务开发。  
+> 总控门禁：[财务开工门禁与 F0/F1 任务清单](财务开工门禁与F0-F1任务清单.md)。  
+>
 > 本文只拆分技术实施任务，不定义新的业务规则，也不修改现有规划。范围依据《财务服务边界设计》《财务管理产品确认表》和后端仓库现行 Maven、Nacos、Gateway、Docker Compose、Jenkins 约定。
 >
 > F0 目标：建立可独立构建、部署、回滚的 `finance-service` 与 `baiyue_finance`，冻结后续财务共同底座（主体/账套、往来单位快照、币种与精度、期间、编号、来源入池、幂等、权限和审计）的技术承载方式。F0 不交付应收、应付、收付款、核销、发票或利润业务闭环。

财务管理/财务服务边界设计.md

@@ -9,6 +9,17 @@
 
 财务域新增独立 `finance-service`，拥有独立财务数据库。不得把应收、应付、对账单、收付款、核销、客户账户、发票、费用分析或利润继续放入 `firstleg-service`。
 
+身份与主体边界补充确认：产品层只有“平台、客户”两种身份。平台可以管理平台角色和平台用户；客户可以在本客户范围内管理客户角色和客户用户。客户用户是财务操作人，不因创建或操作财务单据而成为新的财务主体。
+
+Finance 中必须分开建模：
+
+- **客户企业/客户范围**：业务数据归属和客户侧结算对象，服务端从登录授权上下文确定，不能由前端任意切换；
+- **平台财务主体/账套**：平台收款、付款、开票和核算的法律/账务主体；即使当前只有一个，也保留独立对象；
+- **客户用户/成员**：制单、复核、确认、收款登记等操作人，保存 `userId/memberId` 和当时的姓名快照；
+- **角色与权限**：平台角色由平台维护，客户角色由客户在允许的权限目录内维护，任何角色都不能越过客户范围。
+
+若业务口语中的“客户就是主体”是指“客户是业务数据主体/结算对象”，可以采用；若指“财务法律主体/账套”，则不能直接等同，需由 F0-02 单独确认。
+
 `firstleg-service` 保持现有业务边界，只负责：
 
 - 入库单、测量、称重和审核；
@@ -110,30 +121,31 @@ Firstleg 通过本地 Outbox 发布：
 - `FIRSTLEG_FEE_ADJUSTED`
 - `FIRSTLEG_FEE_VOIDED`
 
-事件至少包含：
+以上是目标事件名。当前 Firstleg 已存在 `FIRSTLEG_FEE_SENT` 和 `FIRSTLEG_FEE_ADJUSTED`；实施时将 `FIRSTLEG_FEE_SENT` 兼容映射为 `FIRSTLEG_FEE_PUBLISHED`，并补充明确的作废事件，不能把规划事件误写成当前已上线能力。
+
+事件采用“统一信封 + 轻量来源引用”，不直接承载完整金额和计费明细。至少包含：
 
 ```text
 eventId
 eventType
+eventVersion
 occurredAt
-customerId
+producer
+tenantId
 inboundId
 sourceFeeId
 sourceFeeVersion
-sourceFeeNo
-feeDetailId
-direction
-businessDate
-currency
-amount
-sourceHash
+sequence
+idempotencyKey
+payloadHash
+traceId
 ```
 
-Finance 使用 `eventId + sourceType + sourceId + sourceVersion` 幂等消费。重复相同事件返回第一次处理结果；同一幂等键对应不同内容时拒绝处理并记录冲突。
+Finance 以 `eventId` 做投递幂等，并以 `sourceType + sourceFeeId + sourceFeeVersion` 做业务唯一约束。重复相同事件返回第一次处理结果；同一业务键对应不同哈希时拒绝处理并记录冲突。金额、币种、方向、业务日期、费用明细和业务快照必须通过内部快照接口核验后保存，不能只信任事件载荷。
 
 ### 5.2 内部查询
 
-Finance 接收事件后，通过服务令牌调用 Firstleg 内部接口核验完整来源快照。内部接口返回 DTO，不返回或共享 Entity。
+Finance 接收事件后，通过服务令牌调用 Firstleg 内部接口核验完整来源快照。内部接口返回 DTO，不返回或共享 Entity。接口路径、信封字段、重试和兼容规则以《Firstleg-Finance 跨服务契约》为准。
 
 Finance 保存来源快照后，不依赖 Firstleg 当前表数据实时计算历史账单。已出账来源发生调整时，Finance 生成补差或冲销来源，不覆盖原账单明细。
 

财务管理/财务管理产品确认表.md

@@ -33,6 +33,21 @@
 
 ## 三、F0 财务底座确认
 
+### 3.1 平台、客户、角色与用户边界补充
+
+以下事实已由当前对话确认：产品层只有平台、客户两种身份；平台管理平台角色/用户，客户管理本客户角色/用户。子用户属于客户成员，是操作人，不自动成为财务主体。
+
+仍需产品确认的是“客户企业”与“财务法律主体/账套”的关系，以及客户子用户可以看到和执行哪些财务动作。对应会议条目已补充至 XLSX 的“待确认事项”页。
+
+| 编号 | 需要确认的事项 | 建议结论 | 最终结论 | 状态 |
+|---|---|---|---|---|
+| F0-11 | 客户与财务主体关系 | 客户企业作为客户数据归属和结算对象；平台财务主体/账套单独建模；首版一个客户对应一个有效结算档案，客户子用户不成为新主体 | 待填写 | 待确认 |
+| F0-12 | 客户子用户数据范围 | 具有财务权限的客户子用户默认查看本客户全部账单，不按“本人创建”切分；部门范围另行定义 | 待填写 | 待确认 |
+| F0-13 | 客户财务权限分配 | 平台定义权限目录和越界规则；客户管理员仅能在本客户内创建角色并分配允许的客户侧权限 | 待填写 | 待确认 |
+| F0-14 | 平台与客户财务动作边界 | 客户侧查看、确认/争议和发票申请；收付款登记、核销/反核销、关账、应付、成本和利润属于平台财务权限 | 待填写 | 待确认 |
+| F0-15 | 职责分离与高风险操作 | 制单、复核、高风险执行使用独立权限；付款/退款、反核销、关账必须原因+审计；双人/金额分级审批待确认 | 待填写 | 待确认 |
+| F0-16 | 成员停用与历史追溯 | 停用立即撤销访问；历史保留 userId/memberId、操作时姓名快照；未完成待办显式转交 | 待填写 | 待确认 |
+
 | 编号 | 需要确认的事项 | 建议结论 | 最终结论 | 状态 |
 |---|---|---|---|---|
 | F0-01 | 财务服务边界 | 新增独立 Finance 服务和财务数据库；Firstleg 只提供不可变业务费用来源，不承载应收应付余额 | 按当前架构采用独立 Finance 服务/财务库 | 技术已确认 |
@@ -136,7 +151,7 @@ Firstleg 已发布费用
 
 ## 九、进入设计与开发的门槛
 
-- S1-S8、F0-01 至 F0-10 全部形成结论，或明确暂缓处理方式。
+- S1-S8、F0-01 至 F0-16 全部形成结论，或明确暂缓处理方式。
 - F1/F2 的账单、应收应付、收付款和核销对象关系冻结。
 - F2 供应商成本来源不能继续使用没有供应商和凭证的人工 PAYABLE 明细替代。
 - 财务服务与 Firstleg 的事件、查询接口、来源版本和幂等契约完成书面确认。

财务管理/财务领域模型与数据字典.md

@@ -29,13 +29,21 @@
 - **建议默认值**：所有主键使用 `BIGINT UNSIGNED`（雪花/号段 ID）；API、JSON 和前端 TypeScript 均按字符串传输。
 - **技术已确认**：往来单位只保存 `party_id` 引用、`party_type` 和当时的名称/编码快照，不复制客户或供应商实体。
 
-### 2.3 金额、币种和精度
+### 2.3 平台、客户与子用户
+
+- **当前对话已确认**：产品只有平台、客户两种身份；平台维护平台角色/用户，客户维护本客户角色/用户。
+- **技术已确认**：客户用户的财务操作上下文必须来自服务端当前客户成员关系和权限快照；不能信任前端传入的 `customerId/tenantId`，也不能让客户用户切换到其他客户范围。
+- **技术已确认**：财务单据保存操作人的 `userId/memberId`、角色/权限快照标识和操作时姓名快照；成员停用只撤销后续访问，不改历史单据。
+- **产品待确认**：客户用户默认查看本客户全部财务数据，还是继续按部门/业务线细分；客户管理员可分配哪些客户侧财务权限；付款、退款、反核销和关账是否强制职责分离。
+- **术语约束**：客户企业是客户数据归属/结算对象；平台收付款、开票和核算的法律主体仍以 Finance 的 `FinancialEntity`/账套表达。客户子用户永远不是新的财务主体。
+
+### 2.4 金额、币种和精度
 
 - **技术已确认**：币种保存 ISO 4217 三位码；原币金额不可覆盖；不同币种不能直接合并或核销。
 - **建议默认值**：金额 `DECIMAL(20,6)` 保存原始计算值，展示/结算精度和舍入模式另设字段；数量/重量/体积 `DECIMAL(20,6)`。具体精度需与产品确认的计费规则复核。
 - 所有金额字段成对保存 `*_amount` 与 `currency_code`（或由单据头统一币种且明细校验一致），不得用浮点数。
 
-### 2.4 通用字段与审计
+### 2.5 通用字段与审计
 
 所有业务表建议具备：`id`、`tenant_id`、`version`（乐观锁）、`created_at`、`created_by`、`updated_at`、`updated_by`、`deleted`（仅允许非财务事实草稿使用）。已出账、收款、核销、冲销、开票和期间记录禁止物理删除；更正使用反向/调整记录。
 

财务管理/财务领域模型与跨服务契约.md

@@ -1,8 +1,9 @@
-# 财务领域模型与跨服务契约
+# 财务领域模型与跨服务契约（历史合并稿）
 
-> 版本：F0-V1.0（设计冻结稿）  
+> 文档状态：已被拆分替代，仅保留历史设计过程，不作为后续实施依据  
+> 替代文档：[财务领域模型与数据字典](财务领域模型与数据字典.md)、[Firstleg-Finance 跨服务契约](Firstleg-Finance跨服务契约.md)  
+> 原版本：F0-V1.0（历史稿）  
 > 日期：2026-08-10  
-> 状态：技术契约已确认；产品门禁项见第十节  
 > 适用：`finance-service` F0，以及 Firstleg → Finance 的费用来源接入
 
 本文只定义财务 F0 的领域对象、来源快照和服务间契约，不创建服务、数据库或业务代码。范围和服务边界以[财务服务边界设计](财务服务边界设计.md)为准；财务全量产品项仍以[财务管理产品确认表](财务管理产品确认表.md)为准。