0 Fork 0

Files

T

oneao 9217b3fa42 20260930172855

2026-09-30 17:28:55 +08:00

55 KiB

Raw Blame History

ERP 动态配置、多租户、多公司与多语言需求分析

文档版本：V1.1
编制日期：2026-09-30
修订日期：2026-09-30
适用范围：FMS/ERP 新系统规划、产品设计、数据库设计、接口设计和开发验收
文档状态：需求基线草案（多语言与配置版本方案已修订）

V1.1 修订范围：第 10 章（引入变更集、无状态/有状态配置、类型注册表）、第 11 章（三层存储模型、角色能力边界、双重循环回退链、可覆盖白名单）、以及 3.5 / 9.4 / 13.2 / 19.4 / 22 / 23 章的配套修订。其余章节保持 V1.0 原文。

1. 文档说明

本文档用于明确 ERP 系统在以下方面的总体需求和设计边界：

一个租户一个数据库的物理隔离模式；
一个租户包含多个公司、子公司和组织；
动态字段、动态表单、动态流程和动态权限；
简体中文、繁体中文、英文等多语言能力；
公司级业务、集团级共享资料和集团汇总报表；
与现有 FMS SQL 驱动、模块配置和工作流设计保持一致。

本文档是系统级需求分析，不替代各业务模块的详细需求、接口协议、数据库字段设计和页面原型。后续销售、采购、库存、财务等模块应以本文档的边界和基础模型为前提继续细化。

2. 建设目标

2.1 总体目标

建设一个面向企业集团和内部业务团队的 ERP/FMS 系统，通过稳定的业务内核和可版本化的配置能力，支持不同租户在不复制代码的情况下适配不同的组织结构、字段、流程、权限和语言。

系统不是通用低代码平台，不要求所有页面、业务规则和复杂业务组件都由用户拖拽生成。系统采用以下原则：

固定核心业务能力，配置变化部分，代码承载复杂业务逻辑，插件承载专业差异。

2.2 具体目标

每个租户拥有独立数据库，方便备份、迁移、恢复和维护。
一个租户可以包含多个公司、子公司、分公司和组织机构。
公司之间可以共享基础资料，也可以保持独立的业务和财务数据。
支持字段、表单、查询、编号、流程、权限、打印模板等动态配置。
支持用户界面、配置项、基础资料和业务快照的多语言处理。
核心业务数据可通过 SQL 高效查询、统计、导出和扩展。
所有配置均支持草稿、校验、发布、生效、停用和回滚。
支持单租户备份、恢复、复制到测试环境和迁移到其他数据库。
支持公司级报表、集团汇总报表和后续合并分析能力。

3. 设计原则

3.1 租户隔离原则

一个租户对应一个业务数据库。租户业务表不再依赖 tenant_id 实现日常数据隔离，数据库边界本身就是租户隔离边界。

租户注册信息与数据库连接信息由租户注册表维护。首期可以使用配置文件，后续在租户数量、部署实例或平台运维需求增加时再切换为可选平台库；租户自己的用户、组织、配置和业务数据始终放在租户数据库。

3.2 公司隔离原则

租户数据库内部允许多个公司共存，但所有公司级业务和财务数据必须带有 company_id。公司是业务、库存、结算、账簿和报表的主要归属边界。

3.3 配置与代码边界

以下内容优先配置化：

字段定义、字段标签和字段分组；
列表和表单布局；
查询条件、排序、显示格式和导出字段；
编号规则、字典和枚举；
审批节点、审批人和审批条件；
角色、字段权限和数据范围；
打印模板、通知模板和简单校验。

以下内容必须由代码保证：

库存扣减、锁定、释放和成本计算；
财务过账、反过账和账簿一致性；
单据状态的关键流转约束；
并发控制、幂等处理和跨模块数据一致性；
复杂税务、结算、汇率和合并抵销逻辑。

3.4 数据模型原则

核心业务数据使用关系表，不使用全量 EAV 模型。
高频查询和关键业务字段使用正式列。
变化频繁的扩展字段可使用 JSON 或扩展值表。
需要筛选、排序、统计的扩展字段应具备可索引方案。
历史单据保存名称、规格、地址、税率、价格等业务快照。
配置、元数据和业务数据分离存储。

3.5 现有 FMS 规范兼容

系统实现应延续现有 FMS 规范：

使用 SQL 驱动的查询和数据处理方式；
系统配置、元数据和权限表使用 s_ 前缀；
业务表沿用现有 b_ 或业务域前缀；
字段采用小写 snake_case；
JSON 仅承载布局、查询和用户偏好等适合 JSON 的结构；
多语言采用三层存储：系统默认层与租户覆盖层使用租户库关系表，硬编码兜底层使用代码资源文件，历史单据使用业务快照（详见 11.1）；
权限过滤必须落实到后端查询或写入逻辑；
不使用触发器代替业务层规则。

4. 业务概念模型

平台
└── 租户 Tenant：一个客户集团或客户账号，对应一个数据库
    ├── 公司 Company：集团总部、子公司、分公司、法人实体
    │   ├── 组织 Organization：部门、岗位、成本中心
    │   ├── 仓库 Warehouse
    │   └── 账簿 Ledger
    ├── 集团共享基础资料
    └── 公司专属基础资料

4.1 租户

租户是平台级概念，代表一个独立客户或集团客户。租户具备：

独立数据库；
独立的配置和业务数据；
独立的备份和恢复周期；
独立的模块授权和版本状态；
独立的默认语言、时区和区域设置。

4.2 公司

公司是租户内部的法人实体、经营主体或业务主体。公司至少需要维护：

公司编码和名称；
上级公司；
公司类型；
法人、税号和注册地址；
默认币种和默认语言；
时区和会计日历；
默认账簿和财务期间；
银行账户、开票主体和税务信息；
启停用状态。

4.3 组织

组织是公司的内部管理单元，包括部门、业务部、采购部、仓储部、财务部、成本中心等。组织支持树形层级，可用于审批、权限、负责人、费用归属和数据范围。

4.4 共享范围

基础资料应支持集团共享和公司专属两种范围：

GROUP    集团内公司均可使用
COMPANY  仅指定公司可使用
ORG      仅指定组织或组织范围可使用

共享不代表可以跨公司直接交易。业务单据仍必须指定实际业务公司、结算公司和相关组织。

5. 系统总体架构

前端应用层
├── 平台管理
├── 基础资料
├── 销售管理
├── 采购管理
├── 库存管理
├── 费用与结算
├── 财务管理
├── 报表中心
└── 系统配置

通用能力层
├── 业务对象与元数据
├── 动态表单与列表
├── 工作流与审批
├── 权限与数据范围
├── 多语言与区域化
├── 编号与字典
├── 附件与打印
├── 审计日志
└── 通知消息

租户运行层
├── 租户识别
├── 数据库路由
├── 数据源连接池
├── 配置版本管理
├── 租户数据库迁移
├── 备份恢复
└── 租户健康检查

数据层
├── 租户连接注册（文件/平台库）
├── 租户数据库
├── 消息队列
└── 分析库/数仓

5.1 租户注册表与平台库（可选）

系统必须能够根据租户标识找到对应数据库。租户注册信息不强制要求使用平台库，首期可以使用按租户维护的配置文件：

config/tenants/tenant-a.json
config/tenants/tenant-b.json

注册表至少维护：

租户编码和状态；
数据库标识和部署模式；
当前数据库版本；
数据库健康状态；
域名或登录入口映射；
模块授权和启用功能；
迁移、备份和恢复任务状态。

当需要在线开通租户、多实例部署、统一运维或集中查看所有租户状态时，可将同一套注册信息迁移到平台库。平台库只负责控制平面，不保存租户业务明细。

5.2 租户数据库

每个租户数据库保存本租户的完整业务数据，包括：

用户成员和组织架构；
公司、账簿、仓库和基础资料；
系统模块、字段、流程、权限和语言配置；
销售、采购、库存、费用和财务数据；
租户级审计日志和业务操作记录。

6. 功能需求总览

编号	功能域	主要内容	优先级
FR-001	平台与租户	租户开通、数据库登记、状态管理	P0
FR-002	公司与组织	多公司、子公司、组织树、仓库和账簿	P0
FR-003	用户与权限	用户、角色、公司范围、组织范围、字段权限	P0
FR-004	元数据配置	模块、字段、对象和关系配置	P0
FR-005	动态页面	列表、表单、详情、查询和导出配置	P0
FR-006	工作流	状态、节点、条件、审批人和动作	P0
FR-007	多语言	界面、配置、主数据和单据快照多语言	P0
FR-008	基础资料	客户、供应商、产品、分类、价格和税率	P0
FR-009	销售采购	订单、审批、收发货、结算和对账	P1
FR-010	库存	仓库、库存、批次、序列号、调拨和盘点	P1
FR-011	财务	账簿、期间、应收应付、凭证和报表	P1
FR-012	报表	公司报表、集团汇总、导出和分析	P1
FR-013	运维	迁移、备份、恢复、监控和审计	P0

7. 平台与租户管理需求

7.1 租户开通

租户开通可以由部署工具、运维人员或平台管理员完成：

创建租户基本资料；
创建或绑定租户数据库；
执行数据库初始化脚本；
写入基础语言、时区和默认参数；
创建首个租户管理员；
分配默认模块和权限；
写入租户注册文件或平台库；
记录初始化结果和数据库版本。

租户注册表应抽象为统一的 TenantRegistry 接口。首期使用文件实现，后续可以替换为平台库实现，不改变业务模块代码。

7.2 租户数据库模式

系统应支持以下数据库部署模式：

shared_instance：同一数据库实例中的独立数据库；
dedicated_instance：独立数据库实例；
external_database：外部托管或私有化数据库。

默认采用独立数据库，是否独立实例由租户规模、性能和部署要求决定。

7.3 租户状态

租户状态至少包括：

CREATING       初始化中
ACTIVE         正常使用
READ_ONLY      只读维护
SUSPENDED      暂停访问
MIGRATING      数据迁移中
ARCHIVED       已归档

不同状态下，登录、查询、保存、审批、导出和后台任务应有明确限制。

8. 公司、组织和账簿需求

8.1 公司管理

系统支持在一个租户数据库内维护多个公司，并支持公司树：

集团总部
├── 上海子公司
├── 苏州子公司
└── 香港子公司

公司管理功能包括：

新增、编辑、停用公司；
设置上级公司和公司类型；
设置默认语言、时区和币种；
设置会计日历和财务期间；
维护税务、银行和开票资料；
配置公司级编号规则、审批规则和权限；
查看公司数据量、业务状态和启用模块。

8.2 组织管理

组织树使用父子关系维护，支持：

部门、岗位、成本中心等组织类型；
组织移动和层级调整；
负责人和分管人员；
组织有效期；
用户多组织任职；
审批节点按组织、岗位或负责人取值。

8.3 仓库和账簿

仓库必须归属公司，可进一步归属组织。账簿必须归属公司，并明确：

本位币；
会计年度；
会计期间；
科目体系；
是否允许过账；
结账状态。

9. 用户、角色和权限需求

9.1 权限层次

系统权限至少分为：

平台权限
租户权限
公司权限
组织权限
仓库权限
模块权限
按钮权限
字段权限
数据权限
业务动作权限

9.2 用户业务上下文

用户登录后形成统一的业务上下文：

tenant_id       当前租户标识
company_id      当前公司
organization_id 当前组织
ledger_id       当前账簿
language        当前语言
timezone        当前时区
currency        当前显示或业务币种
user_id         当前用户

用户可以切换的范围由权限决定。普通用户可能只能切换组织，集团财务可以切换公司和账簿。

9.3 数据权限

数据权限支持：

仅本人创建的数据；
所属组织数据；
所属组织及下级组织数据；
指定公司数据；
指定仓库数据；
指定客户、供应商或业务负责人数据；
自定义条件数据。

数据权限必须在后端 SQL 或数据访问层执行，前端隐藏不能代替后端权限过滤。

9.4 超级管理员与租户用户

V1.1 新增。本章是第 10 章配置版本与第 11 章多语言的能力边界前提。

系统区分两类角色，其能力差异是全局性的，不只作用于多语言：

角色	持有方	是否交付客户	主要能力
超级管理员	运维或开发团队	否，不交付租户	新增/删除语言、配置语言默认值、修改任意配置与文案、对租户白名单做例外放行、平台级运维操作
租户用户	客户方	是	在授权范围内修改文案取值与配置，不能新增语言、不能语言级配置、不能修改锁定文本

租户用户对文案的修改结果对整个租户生效，不是每个登录账号各改各的。租户内所有用户看到同一份文案；个人语言偏好只决定"使用哪一门语言"，不决定"某个词如何翻译"。

这条约束的实操价值在于：用户报障时会复述屏幕上的文案，若同一租户内不同人看到不同叫法，运维无法据此定位问题。

10. 动态配置需求

10.1 配置对象

系统至少支持以下配置对象：

业务模块；
数据对象；
字段定义；
主子表关系；
列表布局；
表单布局；
查询方案；
编号规则；
字典和枚举；
工作流；
权限和数据范围；
打印模板；
通知模板；
公式和简单规则。

10.2 动态字段

支持以下字段类型：

文本、多行文本；
整数、数值、金额；
日期、时间、日期时间；
单选、多选、下拉树；
用户、部门、公司、仓库、客户等关联字段；
附件、图片；
公式字段；
子表和明细字段。

字段配置包括：

编码、名称和数据类型；
是否启用；
是否必填；
默认值；
可见、只读和禁用条件；
查询、排序和导出能力；
权限级别；
公司作用域；
多语言标签；
校验和格式化规则。

10.3 动态表单和列表

表单支持：

分组、选项卡和折叠面板；
字段栅格和列宽；
条件显示、条件只读和条件必填；
主表与子表；
自定义组件；
用户个性化布局；
根据公司、角色或单据状态使用不同布局。

列表支持：

动态列；
固定列和排序；
多条件查询；
条件组和逻辑组合；
汇总、分组和统计；
导出字段控制；
用户保存查询方案。

10.4 配置生命周期与元模型

配置发布必须经过：

草稿 → 校验 → 测试 → 发布 → 生效 → 停用/回滚

发布前校验包括：

字段和编码重复检查；
关联对象存在性检查；
流程节点可达性检查；
必填字段可填写检查；
公式字段引用检查；
权限是否造成无人审批检查；
删除或停用字段对历史数据的影响检查。

配置版本必须保留发布人、发布时间、变更说明和前一版本引用。

V1.1 修订：上述生命周期是完整链路，适用于结构型与行为型配置。展示型、内容型（含翻译）按 10.7 的类型注册表跳过"测试"环节，直接发布。

统一元模型。 10.1 列举的全部配置对象共用一套版本机制，不为每类各造一套：

配置对象 config_object  —— 一个可版本化的单元（字段定义、列表布局、工作流、打印模板……）
   ├── 工作副本   —— 唯一一份，可反复编辑
   ├── 版本快照   —— 发布时整体冻结，发布后不可变
   └── 指针       —— 当前版本 + 上一版本

变更集 change_set        —— 打包多个配置对象的工作单元，见 10.5

参考表结构（沿用 s_ 前缀与 snake_case 命名）：

s_config_object    (tenant_id, object_type, object_code)
s_config_version   (object_id, version_no, status, content_json)
s_config_release   (object_id, current_version_id, previous_version_id, released_by, released_at)
s_change_set       (tenant_id, set_code, status, released_by, released_at)
s_change_set_item  (change_set_id, object_id, before_version_id, after_version_id)

整包快照，不做行级 diff。 单个配置对象通常为几百行 JSON，整体冻结最简单、最不易出错，回滚即移动指针。版本比对通过两个版本的 JSON 并排展示实现，不实现三方合并。

配置作用域：租户级默认 + 公司级稀疏覆盖。（V1.1 补充）

本节新增的公司级覆盖机制只作用于「表现与行为」类配置对象；结构性定义仍由租户统一，详见下方「配置对象的作用域划分」。三层结构与第 11 章多语言的「覆盖层 → 默认层 → 兜底层」一致，表述与之对齐：

多语言：租户覆盖层  →  系统默认层  →  硬编码兜底层
配置：  公司级覆盖  →  租户级默认  →  系统内置

原 s_config_object / s_config_version / s_config_release 定义保持不变；公司级覆盖通过新增两张表实现，不改变对象的租户级定义：

s_config_override          (object_id, company_id, current_version_id, previous_version_id)
s_config_override_version  (object_id, company_id, version_no, content_json, status, released_by, released_at)

解析规则：

最终生效配置 =
    公司级覆盖(company_id) 存在  →  取公司级已发布版本
    否则                        →  取租户级已发布版本

覆盖粒度为「对象级整包覆盖」，不做字段级合并。 理由：字段级合并会产生"字段 A 来自公司版、字段 B 来自租户版"的组合，租户升级后可能出现公司版与租户版字段结构不一致的诡异状态，且无法预测。整包覆盖语义清晰、可预期。

稀疏覆盖，不做全量复制。 公司级覆盖必须是稀疏的：

公司创建时，覆盖表为空，零初始化；
租户级默认值变更后，自动传播到所有未做覆盖的公司；
公司删除覆盖，即回退到租户级默认。

为什么不做「创建公司时复制全量租户配置」。 该做法下，租户后续优化无法传播到已有公司，N 个公司产生 N 份副本，改一次通用规则要改 N 次，与多语言全量复制的缺陷完全相同。

配套要求：租户版与公司版差异比对。 系统提供「查看租户版与本公司版差异」的比对功能（两个 JSON 并排展示即可），使公司管理员能判断是否需要同步租户级更新。

配置对象的作用域划分。

配置对象	租户级	公司级覆盖	说明
业务模块、数据对象、主子表关系	定义	❌	结构型，租户统一
字段定义（编码、名称、数据类型）	定义	❌	结构性定义租户统一
字段使用属性（必填、显隐、只读、默认值、标签）	默认	✅	10.2 已有「公司作用域」
列表布局、表单布局、查询方案	默认	✅	10.3 已支持按公司
编号规则	默认	✅	8.1 明确要求
工作流、审批规则	默认	✅	8.1 明确要求
权限和数据范围	默认	✅	9.1 已有公司权限层
打印模板、通知模板	默认	✅	抬头、税号、logo 常为公司专属
字典和枚举	默认	✅ 有限	允许公司增改项文案，不允许改编码
公式和简单规则	默认	❌	逻辑一致性优先

原则：结构性定义租户统一，表现与行为规则允许公司覆盖。

作用域止于公司：组织级、仓库级不设配置作用域（仅权限可下沉到组织/仓库）。配置继续下沉会导致配置量爆炸且无法维护。

作用域边界规则。

删除公司级覆盖 = 回退到租户级默认，不等同于停用或删除该配置。
孤儿覆盖校验：租户级对象被停用或删除后，其下的公司级覆盖应被标记为孤儿覆盖，纳入发布前校验清单与运维巡检，不得静默失效。
公司停用或归档时，其覆盖随之失效，不进入解析链。
权限、编号规则、打印模板复用同一套覆盖机制，不得各造一套。

共享内核（建议）。「租户级默认 + 公司级稀疏覆盖 + 优先级解析」是本文档中反复出现的结构，至少四处复用同一模式——多语言（11.4 公司级 overlay）、配置（本次新增）、权限（9.1 公司权限层）、编号规则（8.1 公司级编号规则）。建议抽象为共享内核统一实现，避免四处各造一套导致行为不一致。

10.5 变更集

V1.1 新增。V1.1 补充：支持租户级与公司级混合作用域。

ERP 中最常见的操作是"加字段 → 改表单 → 改列表列 → 改打印模板"的组合修改。若只能单对象独立发布，会产生"字段已加但表单未放置"的中间态不一致。因此配置以变更集为发布单元：

变更集包含 N 个配置对象的草稿变更；
提交时执行跨对象一致性校验；
原子发布：全部成功或全部不生效，不得出现半发布状态（呼应 19.4）；
回滚以变更集为最小单位。

跨对象校验是相比单对象发布的最大增量价值：可校验"表单引用的字段是否存在""列表列引用的字段是否已停用""打印模板引用的字段是否仍可见"这类约束，而这些在分开发布时无法校验。

变更集项的作用域。（V1.1 补充）s_change_set_item 增加 scope 与 company_id：

s_change_set_item  (change_set_id, object_id, before_version_id, after_version_id, scope, company_id)

scope 取 TENANT 或 COMPANY；
scope = COMPANY 时 company_id 必填，指向公司级覆盖（见 10.4）；
scope = TENANT 时 company_id 为空。

允许同一变更集混合租户级与公司级项。 典型场景：「加字段（租户级）+ 改 A 公司表单（公司级）」必须能一起发，否则又会退回"字段已加但公司表单未更新"的中间态。

原子发布与原子回滚仍以变更集为单位，跨作用域一并回退，不因作用域不同而拆分。

��对象校验需具备作用域意识：例如校验"表单引用的字段在该公司是否可见/启用"，而非仅校验租户级。校验清单增加「孤儿覆盖检查」（见 10.4 作用域边界规则）。

占用锁：配置对象进入某个变更集后，其他变更集不得再将其加入，系统应提示"该对象已在 XXX 变更集中"。占用锁的键扩展为 (object, scope, company_id) 组合，避免同一公司级对象被两个变更集同时占用。采用占用锁而非三方合并。

10.6 无状态配置与有状态配置

V1.1 新增。本节决定配置变更对在途业务单据的影响方式。

配置按是否持有运行时状态分为两类：

类型	典型例子	生效规则
无状态配置	必填、显隐、只读、校验规则、显示格式、打印模板、翻译、编号规则的格式定义（前缀、日期格式、位数、补位规则）	实时求值，永远以最新为准。发布后立刻对所有单据生效
有状态配置	工作流、审批节点、审批规则	实例创建时绑定 `config_version`，按绑定版本执行完毕，不受后续发布影响

为什么有状态配置必须绑定版本。 审批流原为 A→B→C 三级，改为 A→C 两级后回滚：若按"最新为准"，已走完 C 的单据在回滚后缺失 B 级审批，已发生的业务动作无法处理；仍卡在 C 的单据则无法确定 B 级算通过还是未通过。审批流改版时，在途单据必然被此类问题撞上。

编号规则不属于有状态配置。 编号规则需拆为两部分理解：

编号格式的规则部分（前缀、日期格式、位数、补位方式等）是无状态配置，修改后实时求值、立即生效，与必填、显隐等同类，无需版本绑定；
计数器本身不是配置，而是运行时数据。它需要解决的是并发安全问题（数据库序列、独立计数表或乐观锁），与配置版本机制无关，不进入 s_config_version 版本体系。

因此，需要版本绑定的配置仅包括工作流与审批流实例。不应为编号计数器生成版本快照。

影响面：版本绑定仅作用于"改版那一刻正在审批中的少数单据"，新单据照常走最新版本。

配套硬约束：

字段只能停用，不能物理删除。10.4 校验清单中"删除或停用字段对历史数据的影响检查"升级为硬约束。
保存与提交的校验强度不同。新规则将某字段设为必填后，审批中的历史单据该字段可能为空，若保存时强制校验，该单据将既无法编辑也无法提交，形成死单。规则：保存时降级为警告，提交/审核时强制校验，使老单据可补填后继续流转。
运行时与发布分离。运行时永远读取已发布版本，草稿修改不影响线上。单据与流程实例记录其绑定的 config_version；打印模板同理，历史单据打印使用开单时的模板版本。

10.7 类型注册表与校验器

V1.1 新增。

使用声明式类型注册表替代散落的 if-else 判断。新增一类配置对象时，只需增加一条注册记录与一个校验器，不改引擎。

类型	例子	变更频率 / 风险	是否审批	生命周期
展示型	列表布局、查询方案、打印模板	高 / 低	否	跳过测试环节，直接发布
内容型	翻译、字典、枚举文案	高 / 低	否（轻量档）	轻量发布，见 11.10
结构型	字段定义、对象关系	低 / 高	是	校验 + 审批
行为型	工作流、审批规则、编号规则	中 / 高	是	校验 + 审批

10.8 回滚语义

V1.1 新增。

回滚 = 指针拨回上一版本，物理上不删除任何数据。

无状态配置：回滚后立即按旧版本求值。
有状态配置：新实例按旧版本执行，在途实例按绑定版本执行完毕。
存在在途实例时给出强提示，但不硬性禁止。管理员在回滚时具备判断力，强行拦截导致卡单才是更严重的事故。

10.9 设计边界

V1.1 新增。以下内容明确不在本期范围内，避免后续被误加：

不新建通用审批流引擎承载"配置审批"，复用第 15 章已有的工作流能力。
不自动生成配置变更的数据迁移脚本或 DDL。结构型变更走"影响评估 + 只停用不删除"。
不做行级 diff，不做冲突三方合并。

11. 多语言与区域化需求

11.1 多语言存储策略

V1.1 整节重写。原"混合存储（代码资源 + 租户库）"改为三层模型，并明确角色能力边界。

多语言文本分三层存储。注意：系统默认层（第 2 层）走数据库而非代码资源文件，原因是"超级管理员新增语言、配置语言默认值"是运行时的、不发版的动作，代码资源文件无法承载。

层级	内容	存储位置	可修改方	生效方式
第 3 层租户覆盖层 overlay	该租户改过的 key，只存差异	租户数据库 `s_i18n_overlay`	租户（白名单内）、超级管理员（全部）	保存即生效
第 2 层系统默认层	系统默认翻译值，全量	租户数据库 `s_i18n_resource` / `s_i18n_translation`	仅超级管理员	保存即生效，不发版
第 1 层硬编码兜底层	系统能跑起来的最小文案集	代码资源文件	开发（随版本发布）	仅在第 2 层不可用时生效

关键约束：

第 1 层不是全量翻译，只放错误提示、语言名称本身等最小集，其唯一职责是"数据库不可用时界面仍能渲染、不白屏"。
租户 overlay 只存差异，大部分租户该表是空的——空表即零初始化、租户秒级可用。
动态字段标签、流程节点名、字典文案等天生没有代码默认值的内容直接归入第 2 层，不属于 overlay 概念。overlay 仅指"第 2 层已有默认值、租户要覆盖"的部分。
平台库不负责保存租户业务翻译。

按内容性质归类：

内容类型	归属层级	示例
系统默认文案	第 2 层	菜单、按钮、系统提示、固定错误码
租户改写文案	第 3 层	菜单显示名、按钮文案、业务校验提示
租户动态配置	第 2 层	动态字段标题、表单分组、流程名称、字典翻译
租户业务主数据	主表 + 翻译表	产品、分类、客户类型、供应商类型
可编辑模板	第 2 层 / 租户数据库	打印模板、邮件模板、通知模板
用户语言偏好	租户数据库用户配置，可辅以本地缓存	当前语言、日期格式、数字格式
历史单据内容	业务单据快照字段	产品名称、客户名称、税率、单位名称

11.2 角色能力边界

V1.1 新增，承接 9.4。

本文档中的"租户"实质上是受限的普通用户，不是可以自由定制的独立租户。多语言能力边界如下：

能力	超级管理员	租户用户
新增语言	✅ 运行时配置，不发版	❌
删除/停用语言	✅	❌
配置语言默认值（第 2 层）	✅	❌
修改具体文案取值	✅ 全部	✅ 白名单内
修改结果的生效范围	全局	整个租户，非账号级

租户用户不能新增语言、不能删除语言、不能配置语言包的默认值，只能修改已有语言中某些文案的取值。修改结果对整个租户生效，租户内所有用户看到同一份文案；个人语言偏好只决定"使用哪一门语言"，不决定"某个词如何翻译"。

11.3 支持范围

系统设计上支持：

简体中文 zh-CN；
繁体中文 zh-TW；
英文 en-US；
日文 ja-JP；
后续扩展其他语言。

首期实际启用语言由项目范围确定，但数据模型和接口不得写死单一语言。新增语言由超级管理员在运行时配置，不需要发版。

11.4 读取与回退规则

V1.1 修订：删除原 11.2 与 11.5 两处互相冲突的回退链，合并为唯一一条，并改为双重循环模型。

原 V1.0 的 11.2 与 11.5 对回退链描述不一致（一处写"系统代码资源"、一处写"系统基础语言"），且把"语言"和"来源"两个正交维度压成了一维。统一模型如下：

语言候选 L = [用户语言, 当前公司默认语言, 租户默认语言, 系统基础语言]   （去重）
来源优先 S = [租户 overlay, 公司级 overlay, 系统默认层, 硬编码兜底层, 原始 key 末段]

遍历顺序：先遍历语言，后遍历来源
  for l in L:
      for s in S:
          命中即返回

为什么要先语言后来源。 若先遍历来源，会出现同一页面上半部分日文、下半部分中文（overlay 只有中文则出中文、默认层有日文则出日文）。ERP 中语言混屏会被当作缺陷上报，比缺翻译更严重。先遍历语言可保证整屏语言一致，全部未命中才整体降级。

语言候选受"系统已启用语言"约束：候选列表 = 系统已启用语言 ∩ 用户语言偏好。系统未启用某语言时，即使用户浏览器语言匹配也不得采用，应回退到系统基础语言。

代码资源与数据库资源应使用统一的语言编码和资源键。系统文案使用资源键，例如 common.save；动态配置和业务主数据使用对象编码、字段编码或资源 ID 关联翻译表。

缺少翻译时不得导致页面报错，应显示回退语言，并允许超级管理员查看缺失翻译清单。

11.5 多语言内容类型与可覆盖白名单

V1.1 修订：原 11.1 与 11.4 冲突（11.1 将菜单、按钮归入代码资源，隐含租户不可改；11.4 又写两者"共同覆盖"）。此处统一拆分。

数据库与代码资源共同覆盖以下内容：

菜单、按钮、提示和系统消息；
动态字段、表单分组和流程节点；
字典、分类和枚举项；
产品、物料、客户分类和供应商分类；
打印模板标题和固定文本；
通知、邮件和消息模板；
单据打印时使用的历史名称快照。

其中允许租户覆盖与锁死不给改的划分如下：

允许租户覆盖	不允许租户覆盖（锁死）
菜单显示名	技术错误码、异常堆栈文案
按钮文案	日志关键字、审计术语
表单/字段标签、分组名	权限拒绝的标准文案
业务校验提示、业务消息	升级提示、系统状态提示
打印模板抬头

锁死理由：用户报障时会复述屏幕上的错误文案，若该文案可被租户改写，运维无法用它检索日志与工单，问题定位链路会断。

白名单授予方式：按模块 + 类别批量授予，不逐 key 配置；超级管理员可对单个 key 做例外放行。

11.6 业务主数据翻译

产品、分类等主数据采用主表加翻译表的方式：

product
product_translation
dictionary_item
dictionary_item_translation

不建议把所有翻译内容拼接在单个 JSON 字段中，以便后续查询、导入、导出、校验和维护。

11.7 单据快照

单据创建或审核时，需要根据业务要求保存以下快照：

产品编码和名称；
规格型号；
客户或供应商名称；
公司名称、地址和税号；
银行信息；
币种和汇率；
税率和税额；
付款条件；
单位名称。

历史单据展示和打印优先使用快照，不能因主数据后续改名而改变历史事实。

V1.1 补充：快照需区分两类，名称类快照的语言维度待业务方确认（见第 22 章待确认项 14）。

事实性快照：金额、税率、数量、编码、税号、地址等与语言无关的信息，必须原样存储，不因主数据后续变更而改变。
名称类快照：产品名称、客户名称、单位名称等。原 11.7 只要求存快照，未说明存哪个语言。实际场景：去年以中文开单，今年客户要求补打英文版发票，快照中只有中文名。

名称类快照提供三个选项供业务方决策：

选项	做法	评价
a	仅存开单时的那一种语言	补打其他语言无法输出，财务与合规场景常不满足
b	带 `lang` 维度存多份	最稳妥，存储量翻倍
c	仅存主数据 ID + 当前翻译	违反"历史事实不可变"原则

建议折中：按开单语言存一份，同时保留主数据 ID，允许按当前翻译补打，但单据上须标注"依据当前资料翻译"。

11.8 区域化

系统分别配置语言、时区、日期格式、数字格式和币种，不将这些概念混为一谈。配置优先级为：

用户设置 → 公司设置 → 租户设置 → 系统默认

11.9 缓存与资源治理

V1.1 新增。以下条目为原 V1.0 缺失项，缺失会导致上线后返工。

缓存：多语言是每次渲染都读取的高频数据，必须缓存。按 lang 整包加载进内存（通常几十 KB），超级管理员修改默认值或租户修改 overlay 时发送缓存失效事件。
单一数据源：避免前端与后端各维护一份资源文件导致不同步。以 key 为中心单一维护，构建期分发，或由后端统一提供 i18n 接口。
key 命名规范：使用语义化 key，如 sales.order.status.pending。禁止使用英文原文作为 key——以原文为 key 时，修改一次英文就要改动所有语言包。
Excel 导入导出：超级管理员批量配置翻译、批量查找替换的刚需。缺失此能力，翻译运营最终会退化为直接改数据库。
zh-TW 独立维护：不得依赖简体自动转繁体。打印/列印、软件/軟體、文件/檔案等用词差异必须独立维护。
废弃 key 治理：废弃 key 标记为 deprecated 后静默保留，版本升级时不得硬删除，由清理工具另行处理。
占位符与复数：至少支持 ICU MessageFormat（如 {count, plural, ...}）。中文无复数变化，但英文、俄文有，后期补齐成本高。

11.10 翻译与配置版本体系的关系

V1.1 新增。本节落定"翻译是否纳入配置版本体系"。

结论：翻译纳入同一套版本模型（10.4 元模型、10.5 变更集），但发布门槛设为最低档（轻量档）。

排除理由：

❌ 不走严格审批（同结构型）：修改错别字也要等审批，运营会绕过系统直接改数据库。
❌ 不独立于版本体系之外：否则没有发布/回滚、没有审计、没有批量导入导出；且翻译与配置存在联动（新增字段时，字段标签翻译需与字段定义一同发布），两套体系无法实现原子发布，与 10.5 的变更集机制直接冲突。

轻量档的具体形态：

能力	翻译是否具备
版本快照、一键回滚	✅
变更审计（谁改的、什么时候改的）	✅
可进入变更集、与配置原子发布	✅
走审批才能生效	❌
必须走「草稿→校验→测试→发布」全链路	❌

热修复通道：翻译属于高频、低风险、改错字类的操作，必须支持"改完立刻生效"的快速通道，10.4 的完整生命周期对其过重。翻译与「展示型」配置同属轻量档。

12. 核心业务需求

12.1 基础资料

基础资料包括：

客户、供应商和其他往来单位；
产品、物料、服务和分类；
单位、仓库、库位和批次规则；
价格表、付款条件和结算方式；
税率、币种和汇率；
银行账户和开票信息；
业务员、部门和负责人。

每项资料需要明确：

集团共享还是公司专属；
谁可以查看和使用；
是否允许停用；
是否允许被历史单据引用；
是否支持多语言；
是否需要版本或有效期。

12.2 销售管理

销售流程至少支持：

报价 → 销售订单 → 审批 → 发货/出库 → 开票 → 收款/结算

销售单据必须记录销售公司、销售组织、客户、仓库、币种、价格和税务信息。

12.3 采购管理

采购流程至少支持：

采购申请 → 采购订单 → 审批 → 收货/入库 → 发票 → 付款/结算

采购公司、采购组织、收货仓库、供应商和结算主体可以按业务规则分别指定。

12.4 库存管理

库存管理至少支持：

入库、出库、调拨和退货；
库存锁定和释放；
盘点和库存调整；
批次、保质期和序列号；
公司间调拨；
委托、寄售和其他库存所有权；
库存成本和库存余额。

库存数据必须明确公司、仓库、货主、产品和计量单位。

12.5 财务和结算

财务能力至少包括：

公司独立账簿；
会计年度和期间；
应收、应付和往来核销；
费用、收款、付款和预收预付；
汇率和币种处理；
单据结算状态；
记账和反记账；
公司级财务报表。

财务单据必须归属公司和账簿。已过账数据不得通过普通编辑直接修改。

12.6 公司间交易

系统预留公司间交易能力，支持：

公司间销售和采购；
公司间调拨；
代收代付；
内部往来；
公司间应收应付；
集团内部抵销标识。

公司间交易应记录：

source_company_id
target_company_id
intercompany_transaction_id

13. 数据模型要求

13.1 租户注册信息

首期可以使用配置文件维护以下信息，后续也可以将其迁移到平台库：

tenant_registry
tenant_database
tenant_module_license
tenant_migration_task
tenant_backup_task
tenant_domain_mapping

平台管理员、授权和运维任务是否进入平台库，根据部署模式决定；不影响租户数据库内的用户、公司和业务数据。

13.2 租户数据库核心对象

s_user
s_role
s_user_role
s_company
s_organization
s_warehouse
s_ledger
s_user_company
s_user_organization
s_module
s_field
s_module_schema
s_workflow
s_permission
s_i18n_resource
s_i18n_translation
s_i18n_overlay
s_audit_log

V1.1 新增以下配置版本与多语言对象（对应 10.4、10.5、11.1）：

s_config_object
s_config_version
s_config_release
s_change_set
s_change_set_item
s_i18n_release

其中 s_i18n_overlay 只保存租户改过的 key（11.1 第 3 层），s_i18n_release 保存翻译版本快照（11.10）。

13.3 业务表通用字段

公司级业务表原则上包括：

company_id
organization_id       可选
created_by
created_at
updated_by
updated_at
status

库存业务根据场景增加：

warehouse_id
owner_type
owner_id

财务业务根据场景增加：

ledger_id
fiscal_year
fiscal_period
currency_code
exchange_rate

13.4 数据库设计边界

核心字段使用关系列；动态字段根据访问频率采用 JSON 或扩展值表。不得为了追求绝对动态而将所有字段转换为 entity_id + field_name + field_value 的全量 EAV 结构。

14. 数据库路由和运行时需求

14.1 请求路由

请求处理流程：

请求进入
→ 解析域名、登录信息或令牌
→ 识别租户
→ 读取租户注册表（配置文件或平台库）
→ 获取租户数据库标识
→ 选择数据源和连接池
→ 设置公司和组织上下文
→ 执行业务查询或写入
→ 清理上下文

14.2 数据源管理

系统应支持：

按租户动态创建数据源；
连接池复用和空闲释放；
租户数据库健康检查；
连接失败重试和熔断；
数据库只读状态；
租户迁移期间禁止普通写入；
日志记录租户、数据库和请求编号。

14.3 注册表实现和跨租户限制

TenantRegistry 至少支持文件实现和平台库实现两种方式。文件更新应具备格式校验、版本号和原子替换能力；平台库更新应具备事务和审计能力。

日常业务接口禁止跨租户查询和跨租户事务。平台级统计通过事件、CDC 或分析库实现，不在业务请求中遍历全部租户数据库。

15. 工作流与审批需求

15.1 流程模型

工作流采用状态机模型，包括：

草稿；
提交；
审批中；
已通过；
已驳回；
已取消；
已完成；
已关闭。

15.2 审批节点

审批人来源支持：

指定用户；
指定角色；
部门负责人；
公司负责人；
业务负责人；
发起人上级；
按金额、公司、组织或字段条件计算。

15.3 业务动作

流程节点可以触发：

状态变更；
发送通知；
写入审计记录；
生成下一张业务单据；
锁定或释放库存；
触发打印或导出；
调用受控的业务处理器。

库存、财务和结算等关键动作必须经过业务处理器，不允许只依赖通用配置执行任意写入。

16. 审计、日志和可追溯性

系统应记录：

登录、退出和租户切换；
公司和组织切换；
配置创建、发布和回滚；
权限授予、撤销和变更；
单据创建、修改、提交、审批和作废；
库存和财务关键动作；
导出、打印、备份和恢复；
平台管理员跨租户操作。

审计记录至少包含：

operator_id
tenant_code
company_id
operation_type
object_type
object_id
request_id
before_value
after_value
created_at

17. 备份、恢复和迁移需求

17.1 租户级备份

系统支持单个租户执行：

全量备份；
增量备份；
指定时间点恢复；
备份文件校验；
备份保留策略；
备份下载或转移；
恢复到临时数据库。

17.2 租户迁移

迁移流程：

申请迁移
→ 检查租户状态
→ 创建迁移前备份
→ 切换只读
→ 导出或复制数据库
→ 校验数据和版本
→ 更新租户连接文件或注册表记录
→ 健康检查
→ 恢复正常访问

17.3 数据库版本

每个租户数据库必须维护当前结构版本。升级任务支持：

版本扫描；
分批升级；
失败重试；
单租户暂停升级；
升级前备份；
执行记录和耗时；
失败原因和人工处理标记。

18. 报表和分析需求

18.1 公司级报表

首期支持：

销售明细和汇总；
采购明细和汇总；
库存余额和收发存；
应收应付；
费用和结算；
公司利润和经营分析。

18.2 集团级报表

支持按公司、公司树、组织、区域、币种和期间汇总。集团报表需要考虑：

不同公司的本位币；
汇率折算；
公司间交易识别；
内部往来抵销；
集团科目映射；
合并范围和有效期。

18.3 分析数据来源

日常交易查询使用租户数据库。跨公司和大数据量分析可通过事件或 CDC 同步到分析库，避免报表查询影响交易库。

19. 非功能需求

19.1 性能

常用列表查询应支持分页、排序和条件下推；
查询和数据权限尽量在 SQL 层完成；
不能在应用层加载全量数据后再过滤；
大型报表支持异步生成；
导入导出支持分批处理和进度反馈；
租户数据源应具备连接池上限和空闲回收机制。

19.2 可维护性

配置和业务逻辑分离；
租户数据库支持独立升级和恢复；
数据库迁移脚本可重复执行或具备明确版本记录；
核心业务规则集中实现；
动态模块不复制大量相同接口和页面代码。

19.3 可扩展性

支持新增公司和子公司；
支持新增语言（由超级管理员运行时配置，不需要发版）；
支持新增模块、字段和流程；
支持独立数据库实例和外部数据库；
支持后续拆分库存、财务和分析服务；
支持公司级数据导出和迁移。

19.4 一致性

关键业务操作必须幂等；
库存和财务更新必须有明确事务边界；
已审核、已过账和已结算单据不能普通修改；
失败操作必须可重试或进入人工处理队列；
配置发布不能产生半发布状态（由 10.5 变更集的原子发布保证）。

20. 实施阶段建议

阶段一：平台基础和租户底座

租户连接配置或注册表；
租户开通和数据库路由；
数据库初始化和版本迁移；
用户、角色、公司和组织；
多语言基础资源；
审计日志；
备份和健康检查。

阶段二：动态配置底座

模块和字段元数据；
动态列表和查询；
动态表单；
字典和编号规则；
配置版本、发布和回滚；
基础权限和数据范围。

阶段三：核心业务

客户、供应商和产品；
销售和采购；
仓库、库存和调拨；
基础结算；
工作流和审批。

阶段四：财务和集团能力

账簿和期间；
应收应付；
费用和付款；
公司间交易；
集团汇总报表；
汇率和合并分析。

阶段五：增强能力

分析库和数据同步；
高级打印模板；
规则引擎；
外部系统接口；
独立数据库实例；
私有化部署和租户迁移工具。

21. 验收标准

21.1 租户隔离

新建两个租户并分别初始化数据库；
租户 A 的业务查询不能读取租户 B 的数据；
平台管理员切换租户有审计记录；
单个租户可以独立备份和恢复；
单个租户数据库可以迁移而不影响其他租户。

21.2 多公司

同一租户可以创建总部、子公司和分公司；
用户可被授权一个或多个公司；
公司级单据必须带 company_id；
基础资料可设置集团共享或公司专属；
公司级库存、账簿和报表相互隔离；
集团管理员可查看授权范围内的汇总数据。

21.3 动态配置

可新增自定义字段并在列表、表单和详情中使用；
可配置字段显隐、只读、必填和权限；
可配置流程并完成提交、审批、驳回和完成；
配置发布后可回滚到上一版本；
配置变更不会破坏历史单据展示。

21.4 多语言

用户可切换界面语言；
动态字段、字典和流程名称可翻译；
产品和基础资料支持多语言名称；
缺少翻译时按规则回退；
历史单据使用名称和税率快照；
打印模板可按语言输出。

21.5 运行维护

可查看每个租户数据库版本；
可执行租户级升级和失败重试；
可查看迁移、备份和恢复任务状态；
连接异常和数据库不可用时有明确错误提示；
大型跨公司报表不会阻塞日常单据操作。

22. 待确认事项

以下内容在进入详细设计前需要由业务方确认：

首期实际支持哪些语言；
公司是否需要独立财务账簿和独立税务主体；
是否首期实现公司间销售、采购和内部结算；
首期支持哪些库存所有权类型；
是否需要批次、序列号和保质期管理；
租户数据库使用同一实例还是按规模分级部署；
数据库备份保留周期和恢复时间目标；
集团报表是否需要汇率折算和内部抵销；
是否需要外部财务、税务、OA、CRM 或电商接口；
哪些动态字段需要进入正式列或统计索引；
业务配置是否需要测试环境和审批发布（V1.1 已按 10.7 类型注册表给出分类门槛，仍需业务方确认接受度）；
私有化部署是否作为首期交付范围；
租户可覆盖的系统文本白名单范围是否完整（见 11.5，需确认锁死清单）；
历史单据名称快照是否需要支持多语言补打（见 11.7，选项 a/b/c 需业务方拍板）；
有状态配置（审批流、工作流）在途单据采用"实例绑定版本"的接受度（见 10.6）；
翻译变更纳入配置发布流程后，运营流程是否可配合（见 11.10）；
硬编码兜底层（11.1 第 1 层）最小文案集的具体范围。

23. 结论

平台库不是业务运行的硬性前提。对于租户数量较少、每个客户独立部署或由运维维护配置文件的场景，使用租户注册文件即可；当需要在线租户管理、集中运维、多实例同步或统一平台权限时，再启用平台库。无论采用哪种注册方式，业务代码保持一套，租户业务数据库保持独立。

系统采用以下总体方案：

代码 = 一套，租户差异通过配置、元数据和受控插件实现
一个租户 = 一个独立数据库
一个租户 = 多个公司、子公司和组织
公司 = 业务、库存和财务归属边界
组织 = 权限、审批和经营管理边界
基础资料 = 支持集团共享或公司独立
配置能力 = 动态字段、表单、流程、权限和打印
多语言 = 界面、配置、主数据和历史单据快照（三层存储：租户覆盖 / 系统默认 / 硬编码兜底）
租户 = 受限用户，可改文案取值，不可新增语言
超级管理员 = 运维持有，不交付客户，负责语言新增与默认值配置
配置发布 = 以变更集为单元，跨对象校验，原子发布与原子回滚
配置变更 = 无状态实时生效，有状态绑定版本跑完
集团分析 = 公司维度汇总，必要时同步到分析库
核心业务 = 由代码保证，不完全交给低代码配置

最终目标不是把 ERP 做成一个万能低代码工具，而是建设一个具有稳定业务内核、清晰数据边界、可配置扩展能力和可独立运维能力的企业业务平台。

55 KiB Raw Blame History Unescape Escape