律所业务平台总体设计方案（全面版）

1. 目标与背景

当前系统最初面向“保安/物业公司”场景，已有项目管理、员工执行、租户管理、到期提醒等能力。现业务主体转向“律师事务所/法务公司”，需要将原能力升级为适配律所经营的全流程平台。

本方案目标：

• 将“项目管理”升级为“法律业务项目（案件/顾问/破产管理等）”管理中枢；
• 将现有能力同步到 PC 商家后台，形成统一运营入口；
• 在员工权限基础上引入“部门”维度，建立可扩展 RBAC 权限体系；
• 打通市场获客、案件收发、执行、财务、归档、到期提醒完整链路；
• 先补齐 schema（数据结构）与迁移机制，解决环境一致性风险。

---

2. 产品定位与模块边界

2.1 新定位

• 平台性质：律所/法务公司内部运营系统
• 核心对象：客户、案件（项目）、律师/法务人员、部门、流程节点、财务结算
• 核心价值：统一“接案 -> 办案 -> 协作 -> 收款 -> 归档 -> 复盘”

2.2 核心模块（一级）

• 组织与权限中心
• 法律业务项目中心（替代原物业项目中心）
• 案件收发与立案中心
• 执行协作中心（任务、工时、日志、文书、审批）
• 财务结算中心（应收、回款、分账、开票）
• 客户与市场中心（线索、商机、转化、回访）
• 风险与提醒中心（期限、庭期、回款、合同到期）
• 统计与报表中心

---

3. “项目管理”升级方案（业务模型）

3.1 统一概念

将原 project 定义升级为“法律业务项目”，统一承载：

• 案件型项目（刑事、民事、行政、仲裁、执行等）
• 顾问型项目（常年法律顾问、专项合规）
• 破产型项目（与现有破产管理逻辑兼容扩展）
• 非诉专项（尽调、合同审查、并购、劳动争议专项）

3.2 项目类型与子类型（建议标准字典）

• LITIGATION 诉讼类

- CIVIL 民事案件

- CRIMINAL 刑事案件

- ADMIN 行政案件

- ENFORCEMENT 执行案件

- ARBITRATION 仲裁案件

• BANKRUPTCY 破产重整类

- BANKRUPTCY_ADMIN 破产管理人

- REORGANIZATION 重整

- LIQUIDATION 清算

• LEGAL_COUNSEL 法律顾问类

- ANNUAL_COUNSEL 常年顾问

- SPECIAL_COUNSEL 专项顾问

• NON_LITIGATION 非诉专项

- CONTRACT_REVIEW 合同审查

- COMPLIANCE 合规

- DUE_DILIGENCE 尽调

- MNA_SUPPORT 并购支持

3.3 项目状态机（统一）

• DRAFT 草稿
• INTAKE 收案中
• ACTIVE 执行中
• ON_HOLD 暂停
• CLOSED_SUCCESS 结案（成功）
• CLOSED_FAIL 结案（失败/终止）
• ARCHIVED 归档

说明：所有子业务（任务、费用、文书、提醒）均挂接在统一项目状态机上，避免模块间状态冲突。

---

4. PC 商家后台同步方案

4.1 目标

• 保持移动端/旧端入口不变；
• 在 PC 商家后台新增“法律项目管理”完整菜单；
• 统一使用同一套核心表与服务，不做双系统数据分叉。

4.2 菜单结构建议（PC）

• 法律项目

- 项目列表

- 新建项目

- 案件收发

- 任务协作

- 文书与证据

- 费用与回款

- 庭期与提醒

- 项目报表

• 组织与权限

- 部门管理

- 角色管理

- 人员管理

- 权限配置

• 市场与客户

- 线索池

- 商机跟进

- 客户档案

4.3 技术原则

• 前后端页面可分步改造，但 API/Action 层先统一；
• 原 project 能力可兼容过渡，不一次性推倒；
• 菜单权限通过 RBAC+部门策略统一控制。

---

5. 组织与权限：员工 + 部门 + 角色（核心）

你提出“员工权限已有，新增部门后部门也可控制后台版块权限”，建议采用三层权限模型：

5.1 三层模型

• 用户（User/Worker/Lawyer）：具体账号主体
• 部门（Department）：组织归属、流程归口、默认权限模板
• 角色（Role）：功能权限集合（菜单、按钮、数据范围）

5.2 权限计算规则（建议）

最终权限 = 用户直授权限 + 角色权限 + 部门模板权限 - 显式拒绝权限

优先级：

1. 显式拒绝（最高）
2. 用户直授
3. 角色
4. 部门模板

5.3 数据范围（必须）

除“功能权限”外，增加数据权限范围：

• ALL 全部数据
• DEPT 本部门
• DEPT_AND_CHILD 本部门及子部门
• SELF 本人
• PROJECT_MEMBER 参与项目

5.4 是否需要“部门”？

结论：需要。

原因：后续要接市场部、案件管理、财务、顾问组等跨职能流程，没有部门维度很难实现“流程归口、预算归口、权限归口、绩效归口”。

---

6. 新增部门后的业务流程编排（全流程）

6.1 角色与部门建议

• 市场部：线索获取、客户初筛、商机移交
• 案件中心/业务部：立项、分案、推进、结案
• 律师团队：办案执行、文书、庭审、沟通
• 风控合规：冲突审查、流程合规
• 财务部：合同款项、回款、开票、分账
• 行政档案：归档、材料保管、借阅

6.2 主流程（建议 BPM）

1. 市场部录入线索
2. 线索转商机（评估、报价）
3. 客户签约 -> 立项（生成法律项目）
4. 分配主办律师 + 协办 + 负责人
5. 执行过程（任务、日志、文书、节点）
6. 财务跟踪（应收、分期、回款、开票）
7. 到期与庭期提醒（多角色通知）
8. 结案审批
9. 归档与复盘

---

7. 数据库重构方案（重点：先补 schema 资产）

7.1 总体原则

• 先“补齐与冻结”当前线上核心表结构；
• 在兼容基础上新增律所字段，不直接破坏旧字段；
• 提供版本化迁移脚本（up/down 或至少 up + 幂等）；
• 所有金额统一分（int），时间统一时间戳+日期字段并行策略。

7.2 建议核心表（新/改）

A. 项目主域

• legal_project（或沿用 project 并扩展）

- 基础：项目编码、名称、类型、子类型、状态、优先级

- 业务：案号、受理法院/仲裁机构、主办律师、客户、标的额

- 生命周期：立项时间、开案时间、结案时间、归档时间

- 归属：shop_id、dept_id、owner_user_id

• legal_project_member

- 项目成员关系（主办/协办/助理/财务对接）

• legal_project_stage

- 项目阶段与节点（可配置）

B. 案件/任务执行

• legal_task
• legal_task_log
• legal_document
• legal_evidence
• legal_hearing_schedule（庭期）

C. 客户与商机

• crm_lead
• crm_opportunity
• crm_customer
• crm_contact

D. 财务

• legal_fee_plan（应收计划）
• legal_receipt（回款）
• legal_invoice（开票）
• legal_split_rule（提成/分账规则）

E. 组织权限

• org_department
• org_role
• org_permission
• org_role_permission
• org_user_role
• org_department_permission_template
• org_user_permission_override
• org_data_scope

F. 提醒与消息

• legal_reminder_rule
• legal_reminder_task
• 复用现有 message 发送站内信

7.3 与现有 project* 关系建议

• Phase1：保留现有 project*（兼容运行）
• Phase2：引入 legal_* 并建立映射/双写（关键表）
• Phase3：切换读路径到 legal_*，保留历史只读

---

8. 与“破产企业管理”兼容方案

你提到“破产企业管理和原来的破产管理差不多”，建议：

• 将“破产管理”作为 project_type = BANKRUPTCY 的一级场景；
• 保留现有已跑通字段/流程（团队、日志、提醒）；
• 增加破产专项字段（债权人会议、管理人节点、债权申报截止、法院节点）；
• 通过“专项扩展表”承载差异，避免污染所有项目。

建议扩展表：

• legal_bankruptcy_case_ext

- project_id

- court_name

- administrator_org

- creditor_deadline

- reorganization_plan_due_date

- key_milestones_json

---

9. 提醒体系升级（从“到期提醒”到“规则中心”）

当前提醒已具备租金/水电到期基础能力。建议升级为统一规则引擎：

• 提醒对象：项目负责人、项目成员、所属部门、财务、管理员
• 提醒事件：

- 合同到期

- 庭期临近

- 付款逾期

- 节点超时

- 证据/材料补正截止

• 提醒渠道：

- 站内消息（现有）

- 短信/企业微信（后续可插拔）

---

10. 实施路线图（分阶段）

P0（4-6 周）

• 冻结并补齐现有 project* 全量建表 SQL 与索引；
• 建立迁移机制（版本号、幂等执行、回滚策略）；
• 完成“项目类型/子类型”律所化改造（前后端字典统一）；
• PC 商家后台接入项目模块（列表/新建/详情/基础设置）；
• 权限补洞：关键接口统一 shop_id + 数据范围 校验。

P1（6-10 周）

• 引入部门模型与 RBAC（用户-角色-部门模板）；
• 抽离 ProjectService/ProjectTenantService；
• 接入案件收发与任务协作；
• 财务应收与回款闭环。

P2（10-16 周）

• 建立全流程工作台（市场->案件->财务->归档）；
• 上线规则化提醒中心；
• 审计日志与风控报表；
• 数据字典平台化与运营看板。

---

11. 风险与控制

11.1 关键风险

• 历史表结构不一致（已在现网出现迹象）
• 旧逻辑与新逻辑并行期间的数据一致性
• 权限扩展后的越权边界复杂度提升

11.2 控制策略

• 所有结构变更必须走迁移脚本与灰度环境验证；
• 核心写入采用事务；
• 增加权限回归测试矩阵（跨 shop / 跨部门 / 跨项目 / 跨角色）；
• 关键表建立审计字段：created_by, updated_by, source_ip。

---

12. 你当前提出的 3 点需求映射

1) 项目管理同步到 PC 商家后台

-> 已在本方案第 4 节给出菜单、技术原则与实施路径。

2) 项目类型改为适配律所（破产、刑事、民事、顾问等）

-> 已在第 3 节给出完整类型与子类型标准字典，并在第 8 节给出破产兼容方案。

3) 员工权限升级为“员工 + 部门 + 角色 + 流程”完整体系

-> 已在第 5/6 节给出完整权限与流程设计，并在第 7/10 节给出落库与落地路线。

---

13. 最终结论

正确的顺序是：

1. 先补 schema 与迁移体系（P0），解决环境一致性风险；
2. 再做项目类型律所化 + PC 同步；
3. 再做部门/RBAC 与跨模块流程打通；
4. 最后完成市场、案件、财务、提醒、审计的全链路平台化。

这样可以在不打断现有业务的前提下，逐步演进成“律所公司后台全功能平台”。