4. 谈判记录数据结构：谈判记录实体设计

谈判记录是工期索赔审批路径中最重要的原始凭证之一。一个结构严谨的谈判记录实体，能够确保每次谈判的关键信息被完整捕获、可追溯、可审计。本节将围绕谈判记录的核心字段展开设计，并给出实体关系与数据规范。

4.1 核心字段定义

谈判记录实体包含以下五个必填字段与两个可选扩展字段，覆盖了谈判的参与主体、时间、内容与结论四个维度：

4.2 实体关系与数据结构图

下图展示了谈判记录实体在工期索赔审批路径中的位置，以及与关联实体（索赔申请、审批节点、结算单）之间的数据流向：

4.3 字段设计要点与避坑指南

• 谈判ID 的生成策略： 推荐使用 UUID v4 或雪花算法（Snowflake），避免使用自增 ID，防止在分布式审批系统中出现 ID 冲突或暴露业务量。
• 参与方 JSON 结构示例：

[
  {"role": "甲方代表", "name": "张明", "org": "建设管理部"},
  {"role": "乙方项目经理", "name": "李强", "org": "施工总包"},
  {"role": "监理工程师", "name": "王磊", "org": "监理公司"}
]

• 时间戳的时区处理： 所有时间戳统一存储为 UTC 时间，前端展示时根据用户时区转换。避免因项目跨时区导致工期索赔时效计算错误。
• 议题与结论的结构化： 建议在应用层对议题和结论进行标签化处理，例如使用 [工期延误] [费用分摊] [责任认定] 等前缀，便于后续按标签检索与统计分析。

4.4 谈判记录与审批路径的关联设计

在工期索赔驱动开发中，谈判记录并非孤立存在，而是审批路径中的一个关键节点。下图展示了谈判记录如何嵌入审批流程：

4.5 数据库建表语句（MySQL 示例）

CREATE TABLE negotiation_record (
    negotiation_id   VARCHAR(36)     NOT NULL PRIMARY KEY COMMENT '谈判ID (UUID)',
    participants     JSON            NOT NULL COMMENT '参与方列表 [{role, name, org}]',
    occurred_at      DATETIME        NOT NULL COMMENT '谈判发生时间 (UTC)',
    topic            TEXT            NOT NULL COMMENT '议题内容，建议加标签前缀',
    conclusion       TEXT            NOT NULL COMMENT '结论内容，含共识/分歧状态',
    attachment_url   VARCHAR(500)    DEFAULT NULL COMMENT '附件链接（可选）',
    approval_node_id VARCHAR(36)     DEFAULT NULL COMMENT '关联审批节点ID（可选）',
    created_at       DATETIME        NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at       DATETIME        NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    INDEX idx_occurred_at (occurred_at),
    INDEX idx_approval_node (approval_node_id),
    INDEX idx_participants ((CAST(participants->>'$[*].role' AS CHAR(64) ARRAY)))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='谈判记录表';