# xy-db-design

**Repository Path**: Stress1/xy-db-design

## Basic Information

- **Project Name**: xy-db-design
- **Description**: 海事信用建表语句及业务逻辑
- **Primary Language**: SQL
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2025-11-08
- **Last Updated**: 2025-11-10

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 海事监管信用管理系统 - 业务流程说明

## 文档说明

本文档详细说明海事监管信用管理系统的核心业务流程，每个流程都标注了涉及的数据表和处理逻辑，便于开发人员理解系统运作机制。

---

## 一、数据采集与整合类流程

### 流程1：处罚数据采集与整合

**流程目标**：从外部系统采集行政处罚数据并整合到统一数据表中

**触发方式**：
- 定时任务（每日凌晨2点）
- 手动触发采集

**执行步骤**：

1. **数据采集**
   - 从源数据库读取5张表数据：
     - `biz_ap_case_register`（案件登记表）
     - `biz_ap_case_reason`（案由表）
     - `biz_ap_illegal_parties`（违法当事人表）
     - `biz_ap_ship_info`（船舶信息表）
     - `biz_ap_punish_decision`（处罚决定书表）

2. **数据清洗与关联**
   - 以处罚决定书为主表进行多表JOIN
   - 过滤已删除和已撤销记录
   - 统一日期格式，转换金额单位（元→分）
   - 提取处罚类型、金额、暂扣月数等结构化信息

3. **写入统一表**
   - 插入 `credit_punishment_records`（表1）
   - 设置 `data_source = 'auto_collect'`
   - 设置 `process_status = 0`（待处理）
   - 记录 `collect_time`（采集时间）

**涉及数据表**：
- **输入**：5张源数据表（xy_ap_punish_data数据库）
- **输出**：`credit_punishment_records`（表1）

**脚本参考**：
- `scripts/02_data_cleaning_and_integration.sql`

**异常处理**：
- 采集失败：记录错误日志，下次重试
- 数据冲突：按 `case_no + party_id` 去重，保留最新记录

---

### 流程2：处罚数据人工录入

**流程目标**：工作人员手动录入处罚数据（通常用于系统未覆盖的历史数据或特殊案件）

**触发方式**：工作人员在前端页面点击"新增处罚记录"

**执行步骤**：

1. **填写表单**
   - 必填字段：案件编号、当事人名称、证件号码、案由、处罚结果
   - 可选字段：船舶信息、处罚机关、处罚日期等

2. **上传附件**
   - 支持上传处罚决定书PDF、现场照片等
   - 附件存入 `credit_attachment`（附件表）
   - 关联方式：`related_type='punishment'`, `related_id=处罚记录ID`

3. **提交保存**
   - 插入 `credit_punishment_records`（表1）
   - 设置 `data_source = 'manual_input'`
   - 设置 `process_status = 0`（待处理）
   - 附件记录同时保存到 `credit_attachment`

**涉及数据表**：
- **输出**：
  - `credit_punishment_records`（表1）
  - `credit_attachment`（附件表）


---

### 流程3：表彰数据采集与录入

**流程目标**：录入良好守信的依据数据（表彰、救援、安全诚信评选等）

**触发方式**：工作人员手动录入

**执行步骤**：

1. **选择表彰类型**
   - 参与重大抢险救灾
   - 参与水上搜救行动
   - 获省部级及以上表彰
   - 获评"安全诚信航运公司"
   - 获评"安全诚信船舶"
   - 获评"安全诚信船长"
   - 其他良好行为

2. **填写表彰信息**
   - 表彰主体信息（企业/个人/船舶）
   - 表彰机关、文号、日期
   - 表彰事由、等级

3. **上传附件**
   - 表彰证书、文件扫描件等
   - 存入 `credit_attachment`
   - 关联方式：`related_type='commendation'`, `related_id=表彰记录ID`

4. **提交审核**
   - 插入 `credit_commendation_records`（表彰记录表）
   - 设置 `audit_status = 0`（待审核）

**涉及数据表**：
- **输出**：
  - `credit_commendation_records`（表彰记录表）
  - `credit_attachment`（附件表）

---

### 流程4：处罚撤销与修正

**流程目标**：处理行政复议撤销或处罚决定修正的情况，并触发重新计算

**法律依据**：《实施办法》第六条："海事行政决定行为被撤销的，作出行政处罚决定的省级海事管理机构应在撤销当日撤下相关公示信息"

**触发方式**：
- 收到行政复议撤销决定
- 处罚决定金额/内容修正

**执行步骤**：

1. **标记撤销/修正**
   - 更新 `credit_punishment_records`（表1）
   - **完全撤销**：
     - `is_revoked = 1`
     - `revoke_type = 1`（完全撤销）
     - `revoke_date`、`revoke_reason`、`revoke_doc_no`
   - **处罚修正**：
     - `is_modified = 1`
     - `modified_fields`（JSON记录修改字段）
     - 更新修正后的处罚金额、类型等

2. **查找关联主体**
   - 查询 `credit_subject_mapping`（表2）
   - 找到该处罚影响的所有信用主体

3. **触发重新评定**
   - 对每个关联主体，调用"多重情形综合评价"流程
   - 重新计算信用等级

4. **生成变更审批**
   - 如果等级需要调整，生成新的审批事项
   - 插入 `credit_level_approval`（表4）
   - 变更原因：`change_reason='处罚撤销/修正导致等级重算'`

5. **撤下公示信息**
   - 如果该处罚已公示，立即撤下
   - 更新公示系统状态

**涉及数据表**：
- **更新**：`credit_punishment_records`（表1）
- **查询**：`credit_subject_mapping`（表2）
- **触发**：流程9（多重情形综合评价）
- **生成**：`credit_level_approval`（表4）

---

## 二、主体匹配类流程

### 流程5：信用主体自动匹配

**流程目标**：将处罚/表彰记录与系统内的信用主体建立关联

**触发方式**：定时任务（每小时执行一次）

**执行步骤**：

1. **获取待匹配记录**
   - 从 `credit_punishment_records` 查询 `process_status = 0` 的记录
   - 从 `credit_commendation_records` 查询 `process_status = 0` 的记录

2. **精确匹配（match_type = 1）**
   
   **法人/非法人组织匹配：**
   \`\`\`sql
   SELECT * FROM EntityManagementLegalPerson 
   WHERE creditCode = party_cert_no
   \`\`\`
   - 匹配成功 → 插入 `credit_subject_mapping`（表2）
   - `match_type = 1`, `match_confidence = 100.00`

   **自然人匹配：**
   \`\`\`sql
   SELECT * FROM EntityManagementNaturalPerson
   WHERE idType = party_cert_type AND idNumber = party_cert_no
   \`\`\`

   **船舶匹配：**
   \`\`\`sql
   SELECT * FROM EntityManagementShip
   WHERE cnNumber = ship_id OR imoNumber = ship_imo
   \`\`\`

3. **辅助匹配（match_type = 3）**
   
   如果精确匹配失败，尝试模糊匹配：
   - 计算名称相似度（Levenshtein算法）
   - 计算证件号相似度
   - 综合置信度 = 名称相似度 × 0.4 + 证件号相似度 × 0.5
   - 如果 `match_confidence >= 60.00`，生成辅助匹配记录
   - `match_type = 3`，需要人工复核

4. **更新处理状态**
   - 精确匹配成功：`process_status = 1`（已匹配）
   - 辅助匹配待复核：`process_status = 0`（待处理）
   - 无法匹配：记录日志，转人工处理

**涉及数据表**：
- **输入**：
  - `credit_punishment_records`（表1）
  - `credit_commendation_records`（表彰记录表）
  - `EntityManagementLegalPerson`（法人主体表）
  - `EntityManagementNaturalPerson`（自然人主体表）
  - `EntityManagementShip`（船舶主体表）
- **输出**：`credit_subject_mapping`（表2）

**脚本位置**：待开发（定时匹配任务）

---

### 流程6：人工复核匹配

**流程目标**：人工确认辅助匹配结果或手动匹配无法自动匹配的记录

**触发方式**：工作人员进入"待复核队列"页面

**执行步骤**：

1. **查看待复核列表**
   \`\`\`sql
   SELECT * FROM credit_subject_mapping 
   WHERE match_type = 3 AND process_status = 0
   ORDER BY match_confidence DESC
   \`\`\`
   - 高置信度优先展示

2. **人工判断**
   - **确认匹配**：
     - 更新 `match_type = 2`（人工匹配）
     - 更新 `match_confidence = 100.00`
     - 更新 `process_status = 1`（已确认）
     - 记录 `match_operator`（操作员）
   
   - **拒绝匹配**：
     - 删除该条匹配记录
     - 重新手动选择正确主体
   
   - **新增主体后匹配**：
     - 在主体管理中新增主体
     - 返回重新匹配

3. **触发后续流程**
   - 匹配确认后，自动触发"行为清单匹配"流程

**涉及数据表**：
- **操作**：`credit_subject_mapping`（表2）

**前端页面**：待开发（匹配复核界面）

---

## 三、信用评价类流程

### 流程7：行为清单智能匹配

**流程目标**：将处罚/表彰行为与失信/守信行为清单进行匹配，判定行为类型

**触发方式**：
- 主体匹配完成后自动触发
- 手动触发重新匹配

**执行步骤**：

#### A. 处罚行为匹配

1. **提取案由和违法程度**
   - 从 `credit_punishment_records` 获取：
     - `case_reason`（案由，如"超载运输"）
     - `illegal_level`（违法程度代码，如"1"/"2"/"3"/"NO_PUNISH"）
     - `illegal_fact`（违法事实）
     - `punish_result`（处罚结果）

2. **匹配严重失信清单**
   
   **匹配规则**：`case_reason` + `illegal_level` 组合匹配，必须 100% 匹配清单
   
   \`\`\`sql
   SELECT * FROM credit_behavior_catalog
   WHERE catalog_type = 2  -- 严重失信
     AND is_enabled = 1
     AND case_reason = ?  -- 案由完全匹配
     AND JSON_CONTAINS(applicable_illegal_levels, ?)  -- 违法程度在适用范围内
   \`\`\`
   
   **示例**：
   \`\`\`
   处罚记录:
   - case_reason = "超载运输"
   - illegal_level = "3"
   
   清单记录:
   - case_reason = "超载运输"
   - applicable_illegal_levels = ["2", "3"]  # 适用于违法程度2和3
   
   匹配结果: ✅ 成功匹配（案由相同且违法程度3在适用范围内）
   → behavior_level = '严重失信'
   \`\`\`
   
   **不匹配示例**：
   \`\`\`
   处罚记录:
   - case_reason = "超载运输"  
   - illegal_level = "1"
   
   清单记录:
   - case_reason = "超载运输"
   - applicable_illegal_levels = ["2", "3"]
   
   匹配结果: ❌ 不匹配（违法程度1不在适用范围内）
   → 继续匹配一般失信清单
   \`\`\`

3. **匹配一般失信清单**
   
   如果未匹配严重失信，继续匹配一般失信清单（规则相同）：
   
   \`\`\`sql
   SELECT * FROM credit_behavior_catalog
   WHERE catalog_type = 1  -- 一般失信
     AND is_enabled = 1
     AND case_reason = ?
     AND JSON_CONTAINS(applicable_illegal_levels, ?)
   \`\`\`
   
   匹配成功 → `behavior_level = '一般失信'`

4. **兜底规则：轻微失信**
   - 如果有处罚记录但不在两个清单中
   - 自动判定为 `behavior_level = '轻微失信'`
   - 注意：轻微失信**不生成名单**，只记录行为

5. **写入匹配结果**
   - 插入 `credit_behavior_matching`（表3）
   - 记录字段：
     - `behavior_level`（行为层级）
     - `matched_list_id`（匹配到的清单ID，如匹配成功）
     - `match_basis`（匹配依据，如"案由:超载运输+违法程度:3"）
     - `calculated_valid_start`（计算的有效期起始 = 处罚日期）
     - `calculated_valid_end`（计算的有效期结束）
       - 严重失信：24个月
       - 一般失信：6个月
       - 轻微失信：3个月

#### B. 表彰行为匹配

1. **识别表彰类型**
   - 从 `credit_commendation_records` 获取表彰类型
   - 根据表彰机关等级判定是否符合良好守信条件

2. **写入匹配结果**
   - 插入 `credit_behavior_matching`（表3）
   - `behavior_level = '良好守信'`
   - 有效期：表彰日期 + 24个月

**涉及数据表**：
- **输入**：
  - `credit_punishment_records`（表1）
  - `credit_commendation_records`（表彰记录表）
  - `credit_subject_mapping`（表2）
  - `credit_behavior_catalog`（行为清单配置表）
- **输出**：`credit_behavior_matching`（表3）

**关键点**：
- 该表记录的是**单个行为**的匹配结果
- 不代表主体的最终信用等级
- 最终等级需要通过"多重情形综合评价"计算

---

### 流程8：失信行为清单配置管理

**流程目标**：维护严重失信和一般失信行为清单数据

**触发方式**：管理员在后台管理页面操作

**执行步骤**：

1. **导入清单数据**
   - 从Excel导入失信行为清单
   - 解析字段：产生失信情形、一类失信事实、案由（备注）、适用说明

2. **存入配置表**
   - 插入 `credit_behavior_catalog`
   - 字段映射：
     - `catalog_type`：严重失信/一般失信
     - `behavior_category`：产生失信情形
     - `behavior_description`：一类失信事实
     - `case_reason`：案由关键词
     - `applicable_illegal_levels`：适用违法程度代码
     - `applicable_subject`：适用对象

3. **版本管理**
   - `version_no`：清单版本号
   - `effective_date`：生效日期
   - 支持清单更新后的版本追溯

**涉及数据表**：
- **输出**：`credit_behavior_catalog`（行为清单配置表）

**前端页面**：待开发（清单配置管理）

---

### 流程9：多重情形综合评价

**流程目标**：根据主体的所有信用行为，综合评价其最终信用等级

**触发方式**：
- 新的处罚/表彰行为匹配完成后自动触发
- 定时任务检查等级变化（每日一次）

**执行步骤**：

1. **获取主体所有信用行为**
   \`\`\`sql
   SELECT * FROM credit_behavior_matching cbm
   JOIN credit_subject_mapping csm ON cbm.subject_mapping_id = csm.id
   WHERE csm.subject_type = ? AND csm.subject_id = ?
     AND cbm.calculated_valid_end >= CURRENT_DATE  -- 有效期内
   ORDER BY cbm.create_time DESC
   \`\`\`

2. **查询主体当前等级**
   - 从主体表（`EntityManagementLegalPerson` 等）查询 `creditLevel`
   - 初始等级：`一般守信`（无失信记录且非良好守信）

3. **应用多重情形评价规则**

   **规则1：良好守信被失信行为打断**
   \`\`\`
   IF 当前等级 = '良好守信'
      AND 新增行为 IN ('轻微失信', '一般失信', '严重失信')
   THEN
      目标等级 = 根据新增失信行为确定
      变更原因 = '良好守信期内发生失信行为，移出良好守信名单'
   \`\`\`

   **规则2：严重失信和一般失信互斥**
   \`\`\`
   IF 存在有效期内的严重失信行为
   THEN
      目标等级 = '严重失信'
      # 同时存在的一般失信行为不影响判定
   \`\`\`

   **规则3：一般失信叠加（有效期重算）**
   \`\`\`
   IF 当前等级 = '一般失信'
      AND 新增行为 = '一般失信'
   THEN
      目标等级 = '一般失信'  # 等级不变
      有效期重算 = 新行为的处罚日期 + 6个月
   \`\`\`

   **规则4：严重失信叠加（有效期重算）**
   \`\`\`
   IF 当前等级 = '严重失信'
      AND 新增行为 = '严重失信'
   THEN
      目标等级 = '严重失信'  # 等级不变
      有效期重算 = 新行为的处罚日期 + 24个月
   \`\`\`

   **规则5：延迟转换（严重失信→一般失信）**
   \`\`\`
   IF 当前等级 = '严重失信'
      AND 严重失信有效期届满前6个月内
      AND 新增行为 = '一般失信'
   THEN
      目标等级 = '严重失信'  # 当前仍为严重失信
      延迟转换标记 = TRUE
      转换目标等级 = '一般失信'
      转换生效时间 = 严重失信有效期结束日期
      一般失信有效期起始 = 一般失信行为的处罚日期
   \`\`\`

   **规则6：良好守信申请**
   \`\`\`
   IF 存在表彰行为
      AND 无有效期内的失信行为
   THEN
      目标等级 = '良好守信'
      需人工审批 = TRUE
   \`\`\`

4. **写入综合评定结果**
   - 插入 `credit_level_evaluation`（表综合评定表）
   - 记录字段：
     - `evaluation_result`（评定结果等级）
     - `current_level`（当前等级）
     - `related_behavior_ids`（关联的所有行为匹配ID，JSON数组）
     - `evaluation_basis`（评定依据文本）
     - `need_delayed_transition`（是否需要延迟转换）
     - `delayed_target_level`（延迟转换目标等级）
     - `delayed_effective_time`（延迟生效时间）

5. **判断是否需要审批**
   
   **需要审批的情况**：
   - 降级为一般失信或严重失信
   - 从良好守信降级
   - 升级为良好守信
   - 等级发生任何变化

   **无需审批的情况**：
   - 轻微失信（只记录，不上名单）
   - 等级无变化（如一般失信叠加）

6. **触发后续流程**
   - 如需审批 → 触发"生成信用等级变更审批"流程
   - 如需延迟转换 → 生成监控任务

**涉及数据表**：
- **输入**：
  - `credit_behavior_matching`（表3）
  - `credit_subject_mapping`（表2）
  - 主体表（查询当前等级）
- **输出**：`credit_level_evaluation`（综合评定表）

**关键设计**：
- 综合评定表记录每次评价的**完整快照**
- 通过 `related_behavior_ids` 可追溯评定依据
- 支持延迟转换场景，确保符合"严重失信期满前6个月"规则

---

## 四、审批流程类

### 流程10：生成信用等级变更审批

**流程目标**：根据综合评定结果，生成信用等级变更审批事项

**触发方式**：多重情形综合评价完成后自动触发

**执行步骤**：

1. **判断是否需要生成审批**
   
   **需要审批的情况（核心）：**
   - 所有**一般失信行为清单**中的行为 → 必须审批
   - 所有**严重失信行为清单**中的行为 → 必须审批
   - 所有**良好守信行为**（表彰） → 必须审批
   - **信用修复申请** → 必须审批
   - **异议申诉** → 必须审批

   **无需审批的情况：**
   - **轻微失信行为**：只记录，不上名单，不审批
   - **系统自动监控**的有效期届满移出（非人为行为）

   **重要说明**：
   即使主体当前已经是"一般失信"，新增一个一般失信行为，虽然等级不变（还是一般失信），但因为是**新的失信行为需要认定**，仍然必须走审批流程。

   **判断逻辑**：
   \`\`\`python
   # 查询综合评定记录
   evaluation = SELECT * FROM credit_level_evaluation WHERE id = ?
   
   # 查询触发的行为匹配记录
   behavior = SELECT * FROM credit_behavior_matching 
              WHERE id = evaluation.trigger_behavior_id
   
   # 判断是否需要审批
   if behavior.behavior_level IN ('严重失信', '一般失信'):
       需要审批 = TRUE
       审批原因 = '认定失信行为'
   
   elif behavior.behavior_level == '良好守信':
       需要审批 = TRUE
       审批原因 = '认定良好守信行为'
   
   elif behavior.behavior_level == '轻微失信':
       需要审批 = FALSE
       直接记录，不生成审批单
   \`\`\`

2. **生成审批单**
   - 插入 `credit_level_approval`（表4）
   - 关键字段：
     - `evaluation_id`（关联综合评定ID）
     - `subject_type`、`subject_id`（主体信息）
     - `current_level`（当前等级）
     - `target_level`（目标等级）
       - **注意**：target_level 可能与 current_level 相同！
       - 例如：当前"一般失信"，新增一般失信行为，目标等级仍是"一般失信"
     - `change_type`（变更类型）
       - 1-初次评定
       - 2-升级
       - 3-降级
       - 4-同级行为叠加（新增）
     - `change_reason`（变更原因）
       - 例如："新增一般失信行为（超载运输），有效期重新计算"
     - `approval_status = 0`（待提交）
     - `calculated_valid_start`（计算的有效期起始）
     - `calculated_valid_end`（计算的有效期结束）

3. **关联附件**
   - 查询处罚/表彰记录的附件
   \`\`\`sql
   SELECT * FROM credit_attachment
   WHERE related_type IN ('punishment', 'commendation')
     AND related_id IN (相关记录IDs)
   \`\`\`
   - 作为审批依据材料

4. **提交审批**
   - 更新 `approval_status = 1`（审批中）
   - 记录 `submit_time`、`submit_user`
   - 进入三级审批流程

**涉及数据表**：
- **输入**：`credit_level_evaluation`（综合评定表）
- **输出**：`credit_level_approval`（表4）
- **关联**：`credit_attachment`（附件表）

---

### 流程11：三级审批流转

**流程目标**：完成一审、二审、三审的审批流转

**触发方式**：
- 一审：审批单提交后自动分配
- 二审：一审通过后流转
- 三审：二审通过后流转

**执行步骤**：

1. **一审审批**
   - 审批人员进入待审批列表
   - 查看审批单详情：
     - 主体基本信息
     - 当前等级、目标等级
     - 变更原因（综合评定依据）
     - 关联的处罚/表彰记录
     - 附件材料
   
   - 审批操作：
     - **通过**：
       - 更新 `approval_node_1_status = 1`
       - 记录 `approval_node_1_user`、`approval_node_1_time`
       - 流转到二审
     - **驳回**：
       - 更新 `approval_status = 3`（已驳回）
       - 记录驳回意见
       - 结束流程
     - **要求补充材料**：
       - 上传补充材料附件
       - `related_type='approval'`
       - `approval_node=1`
       - `approval_action='supplement'`

2. **二审审批**（同一审流程）
   - 查看一审意见
   - 进行二审审批
   - 更新 `approval_node_2_*` 字段

3. **三审审批**（同一审流程）
   - 查看一审、二审意见
   - 进行三审审批（最终审批）
   - 更新 `approval_node_3_*` 字段
   - 如果三审通过：
     - 更新 `approval_status = 2`（已通过）
     - 记录 `approval_time`
     - 触发"公示流程"

**涉及数据表**：
- **操作**：`credit_level_approval`（表4）
- **关联**：`credit_attachment`（附件表，查看和上传）

**前端页面**：
- 待审批列表（按审批节点分类）
- 审批详情页（展示所有信息和历史意见）
- 审批操作（通过/驳回/补充材料）

---

### 流程12：审批通过后处理

**流程目标**：审批通过后更新主体信用等级，并进入公示流程

**触发方式**：三审通过后自动触发

**执行步骤**：

1. **标记审批生效准备**
   - 更新 `credit_level_approval`
   - `is_effective = 0`（尚未生效，等待公示）

2. **进入公示流程**
   - 调用"流程13：信用等级公示"
   - 公示期为10个工作日

3. **公示结束后生效**
   - 更新主体表的 `creditLevel` 字段
   - 更新 `credit_level_approval`
     - `is_effective = 1`（已生效）
     - `effective_time`（生效时间 = 公示结束日期）
     - `actual_valid_start`（实际有效期起始 = 公布日期）
     - `actual_valid_end`（实际有效期结束 = 公布日期 + 有效期月数）

4. **记录等级变更历史**
   - 插入 `credit_level_change_history`（表5）
   - 记录完整的等级变更信息

5. **生成监控任务**
   - 插入 `credit_level_monitor_task`（表6）
   - 任务类型：
     - 有效期届满提醒（提前30天）
     - 有效期届满自动移出
     - 延迟转换任务（如需要）

**涉及数据表**：
- **操作**：`credit_level_approval`（表4）
- **更新**：主体表（`EntityManagementLegalPerson` 等）
- **生成**：
  - `credit_level_change_history`（表5）
  - `credit_level_monitor_task`（表6）

---

## 五、公示公布类流程

### 流程13：信用等级公示

**流程目标**：在正式公布前进行10个工作日公示，接受异议

**法律依据**：《管理规定》要求公示期不少于10个工作日

**触发方式**：审批通过后自动进入公示

**执行步骤**：

1. **生成公示公告**
   - 从 `credit_level_approval` 获取审批信息
   - 生成公示内容：
     - 主体名称、统一社会信用代码/证件号
     - 拟认定信用等级
     - 认定依据（失信/守信行为概述）
     - 公示期限
     - 异议受理方式

2. **发布公示**
   - 在系统公示栏目发布
   - 在海事局官网同步发布
   - 记录公示开始时间、结束时间

3. **接受异议**
   - 公示期内，当事人可提出异议
   - 触发"异议处理流程"

4. **公示期满处理**
   
   **无异议**：
   - 自动转为正式公布
   - 更新主体信用等级
   - 触发"审批通过后处理"流程

   **有异议**：
   - 暂停公示
   - 等待异议处理结果
   - 根据异议处理结果决定是否继续

**涉及数据表**：
- **输入**：`credit_level_approval`（表4）
- **状态跟踪**：公示系统表（待设计）

---

### 流程14：信用等级正式公布

**流程目标**：公示期满无异议后，正式公布信用等级

**触发方式**：公示期满且无异议

**执行步骤**：

1. **更新主体信用等级**
   - 更新主体表的 `creditLevel` 字段
   - 更新 `creditLevelValidStart`（有效期起始 = 公布日期）
   - 更新 `creditLevelValidEnd`（有效期结束）

2. **生成公布公告**
   - 发布正式公告
   - 在信用信息公示系统展示

3. **记录等级变更历史**
   - 插入 `credit_level_change_history`（表5）
   - `is_current = 1`（当前有效）
   - 历史记录设为 `is_current = 0`

4. **更新审批单状态**
   - `credit_level_approval.is_effective = 1`
   - `effective_time = CURRENT_TIMESTAMP`

**涉及数据表**：
- **更新**：
  - 主体表（`creditLevel` 等字段）
  - `credit_level_approval`（表4）
- **生成**：`credit_level_change_history`（表5）

**法律依据**：《管理规定》第二十二条："有效期均自公布之日起计算"

---

## 六、异议处理类流程

### 流程15：异议申请与受理

**流程目标**：当事人对信用评价结果有异议时，可申请复核

**触发方式**：
- 当事人在公示期内提出异议
- 当事人在公布后发现错误提出异议

**执行步骤**：

1. **提交异议申请**
   - 当事人填写异议申请表
   - 上传证明材料
   - 异议理由说明

2. **异议受理**
   - 工作人员审查异议材料
   - 判断是否受理
   - 受理后分配处理人员

3. **异议调查**
   - 核实异议内容
   - 调取原始处罚/表彰记录
   - 重新审查证据材料

4. **异议处理结果**
   
   **异议成立**：
   - 撤销或调整信用等级认定
   - 重新进行综合评价
   - 生成新的审批流程

   **异议不成立**：
   - 维持原认定结果
   - 继续公示或公布流程
   - 向当事人说明理由

**涉及数据表**：
- **生成**：异议处理表（待设计）
- **关联**：
  - `credit_level_approval`（表4）
  - `credit_attachment`（附件表，存储异议材料）

---

## 七、信用修复类流程

### 流程16：信用修复申请

**流程目标**：符合条件的失信主体可申请提前移出失信名单

**法律依据**：《管理规定》规定的信用修复条件

**触发方式**：当事人主动申请

**执行步骤**：

1. **申请资格判断**
   - 查询主体当前等级
   - 判断是否在失信名单中
   - 判断失信行为是否可修复

2. **提交修复申请**
   - 填写申请表
   - 上传整改证明材料
   - 说明整改措施和效果

3. **修复审核**
   - 审核整改材料
   - 实地核查（如需要）
   - 判断是否符合修复条件

4. **修复结果**
   
   **修复成功**：
   - 从失信名单移出
   - 恢复为"一般守信"
   - 记录修复历史

   **修复失败**：
   - 维持失信状态
   - 说明未通过原因

**涉及数据表**：
- **生成**：信用修复表（待设计）
- **更新**：主体表（`creditLevel`）
- **记录**：`credit_level_change_history`（表5）

---

## 八、监控运维类流程

### 流程17：信用等级有效期监控

**流程目标**：自动监控信用等级有效期，到期提醒和自动移出

**触发方式**：定时任务（每日凌晨执行）

**执行步骤**：

1. **扫描有效期即将到期的记录**
   \`\`\`sql
   SELECT * FROM credit_level_monitor_task
   WHERE task_status = 0  -- 待执行
     AND scheduled_time <= CURRENT_TIMESTAMP + INTERVAL 1 DAY
   \`\`\`

2. **执行监控任务**

   **任务类型1：到期提醒**
   - 提前30天提醒
   - 向主体发送通知
   - 向工作人员发送待办提醒

   **任务类型2：自动移出**
   - 有效期届满日
   - 从失信名单自动移出
   - 恢复为"一般守信"
   - 记录等级变更历史

   **任务类型3：延迟转换**
   - 严重失信期满，转为一般失信
   - 更新主体信用等级
   - 计算一般失信有效期
   - 生成新的监控任务（一般失信到期）

3. **任务完成标记**
   - 更新 `task_status = 2`（已完成）
   - 记录 `execute_time`

**涉及数据表**：
- **操作**：`credit_level_monitor_task`（表6）
- **更新**：主体表（`creditLevel`）
- **生成**：`credit_level_change_history`（表5）

---

### 流程18：延迟转换任务执行

**流程目标**：处理"严重失信期满前6个月内的一般失信"延迟转换场景

**触发方式**：定时任务检测到延迟转换时间点

**执行步骤**：

1. **查询延迟转换任务**
   \`\`\`sql
   SELECT * FROM credit_level_monitor_task
   WHERE task_type = 3  -- 延迟转换
     AND task_status = 0
     AND scheduled_time <= CURRENT_TIMESTAMP
   \`\`\`

2. **获取关联评定记录**
   - 查询 `credit_level_evaluation`
   - 确认 `need_delayed_transition = 1`
   - 获取 `delayed_target_level`（通常是"一般失信"）

3. **执行等级转换**
   - 更新主体表 `creditLevel = '一般失信'`
   - 计算一般失信有效期：
     - `valid_start` = 一般失信行为的处罚日期
     - `valid_end` = valid_start + 6个月

4. **生成新的监控任务**
   - 生成一般失信到期监控任务
   - `scheduled_time` = 一般失信有效期结束日期

5. **记录等级变更**
   - 插入 `credit_level_change_history`
   - `change_type = 4`（转换）
   - `change_reason = '严重失信期满，转入一般失信'`

**涉及数据表**：
- **输入**：
  - `credit_level_monitor_task`（表6）
  - `credit_level_evaluation`（综合评定表）
- **更新**：主体表
- **生成**：
  - `credit_level_change_history`（表5）
  - 新的监控任务

---

## 九、流程总览与优先级

### 流程分类统计

| 类别 | 流程数量 | 关键等级 |
|-----|---------|----------|
| 数据采集与整合 | 4个 | 高 |
| 主体匹配 | 2个 | 高 |
| 信用评价 | 4个 | 核心 |
| 审批流程 | 3个 | 核心 |
| 公示公布 | 2个 | 中 |
| 异议处理 | 1个 | 中 |
| 信用修复 | 1个 | 低 |
| 监控运维 | 2个 | 高 |

### 开发优先级建议

**第一阶段（核心功能）：**
1. 流程1：处罚数据采集与整合
2. 流程2：处罚数据人工录入
3. 流程5：信用主体自动匹配
4. 流程7：行为清单智能匹配
5. 流程9：多重情形综合评价
6. 流程10：生成信用等级变更审批
7. 流程11：三级审批流转

**第二阶段（完善功能）：**
8. 流程3：表彰数据采集与录入
9. 流程6：人工复核匹配
10. 流程12：审批通过后处理
11. 流程13：信用等级公示
12. 流程14：信用等级正式公布
13. 流程17：信用等级有效期监控
14. 流程18：延迟转换任务执行

**第三阶段（扩展功能）：**
15. 流程4：处罚撤销与修正
16. 流程15：异议申请与受理
17. 流程16：信用修复申请

---

## 十、流程关联矩阵

| 流程 | 触发后续流程 | 涉及核心表 |
|-----|-------------|-----------|
| 流程1/2 | → 流程5 | 表1 |
| 流程3 | → 流程5 | 表彰记录表 |
| 流程4 | → 流程9 | 表1, 表2 |
| 流程5 | → 流程7 | 表2 |
| 流程6 | → 流程7 | 表2 |
| 流程7 | → 流程9 | 表3 |
| 流程8 | 支持流程7 | 行为清单配置表 |
| 流程9 | → 流程10 | 综合评定表 |
| 流程10 | → 流程11 | 表4 |
| 流程11 | → 流程12 | 表4 |
| 流程12 | → 流程13 | 表4, 表5, 表6 |
| 流程13 | → 流程14 | 表4 |
| 流程14 | 完成 | 主体表, 表5 |
| 流程15 | → 流程9（重算） | 异议表 |
| 流程16 | → 流程12 | 修复表 |
| 流程17 | 自动执行 | 表6 |
| 流程18 | 自动执行 | 表6, 综合评定表 |

---

## 附录：关键业务规则速查

### 信用等级分类
- **良好守信**：有表彰、无失信，需审批
- **一般守信**：无失信、无表彰，默认等级
- **轻微失信**：有处罚但不在失信清单，不上名单，只记录
- **一般失信**：匹配一般失信清单，有效期6个月
- **严重失信**：匹配严重失信清单，有效期24个月

### 多重情形关键规则
1. 良好守信 + 任何失信 → 移出良好守信
2. 严重失信 + 一般失信 → 仍为严重失信
3. 一般失信叠加 → 有效期重算
4. 严重失信叠加 → 有效期重算
5. 严重失信期满前6个月内的一般失信 → 等严重失信期满后转入一般失信

### 有效期计算
- **计算有效期**：从处罚/表彰日期起算（存于表3）
- **实际有效期**：从公布日期起算（存于表4、主体表）
- **法律依据**：《管理规定》第二十二条

### 审批必要性
- **需要审批**：等级变更（升级/降级）
- **无需审批**：轻微失信（只记录）
- **审批级别**：三级审批

### 公示要求
- **公示期**：10个工作日
- **公示内容**：主体信息、拟认定等级、认定依据
- **异议受理**：公示期内可提出异议

---

**文档版本**：v1.0  
**最后更新**：2025-11-09  
**维护人员**：系统开发组