3. 采购合同的核心字段与数据结构：合同编号、供应商、金额、起止日期、续约条款
采购合同是企业与供应商之间法律关系的核心载体，也是触发续约提醒与商机联动的数据基础。在系统设计中，合同数据结构的完整性与字段定义的准确性，直接决定了后续流程自动化的可靠性。本章将围绕五个核心字段组，解析其业务含义、数据结构规范及在续约场景中的关键作用。
3.1 核心字段全景
一份标准的采购合同数据表通常包含数十个字段，但从续约提醒与商机联动的视角出发，以下五个字段组构成了最小可行数据集（MVD）：
| 字段组 | 核心字段 | 数据类型 | 续约场景关键作用 |
|---|---|---|---|
| 合同编号 | Contract_ID, Contract_Code | VARCHAR(50), 唯一索引 | 作为主键关联订单、付款、续约记录；系统自动生成，不可重复 |
| 供应商 | Supplier_ID, Supplier_Name, Tax_ID | VARCHAR(20), VARCHAR(100), VARCHAR(30) | 识别续约对象；关联供应商评级、历史履约数据 |
| 金额 | Contract_Amount, Currency, Tax_Rate | DECIMAL(18,2), CHAR(3), DECIMAL(5,2) | 评估续约价值；触发不同审批层级（如超百万需总监审批） |
| 起止日期 | Start_Date, End_Date, Notice_Period_Days | DATE, DATE, INT | 计算到期日与提醒时间点；决定续约窗口期 |
| 续约条款 | Renewal_Type, Auto_Renewal, Renewal_Terms_Text | VARCHAR(20), BOOLEAN, TEXT | 决定续约流程类型（自动/手动）；存储特殊续约条件 |
实践建议：在数据库设计中，建议将合同编号设为聚集索引主键，供应商ID设为外键关联供应商主表。起止日期字段应建立非聚集索引，以加速到期合同查询。
3.2 字段详解与数据结构规范
3.2.1 合同编号（Contract ID）
合同编号是合同的唯一身份标识，通常采用“前缀+年份+流水号”的编码规则。例如：PO-2025-001234。在续约场景中，原合同编号与续约合同编号应建立关联关系，常见做法是在合同表中增加 Parent_Contract_ID 字段。
-- 合同编号生成示例（PostgreSQL）
CREATE SEQUENCE contract_seq START 1;
SELECT 'PO-' || TO_CHAR(NOW(), 'YYYY') || '-' || LPAD(NEXTVAL('contract_seq')::TEXT, 6, '0') AS contract_code;
-- 输出: PO-2025-0000013.2.2 供应商（Supplier）
供应商字段不应仅存储名称，而应通过供应商ID建立外键关联。推荐的数据结构包含：
- Supplier_ID：内部唯一标识，如
SUP-10086 - Supplier_Name：法定全称，用于合同正文
- Tax_ID：纳税人识别号，用于财务校验
- Contact_Info：续约联系人、邮箱、电话（JSON格式存储）
3.2.3 金额（Amount）
金额字段需注意精度与币种处理。在续约场景中，系统需要对比原合同金额与续约报价，因此建议同时存储 原合同金额 与 续约报价金额，并计算差异百分比。
| 字段名 | 类型 | 说明 |
|---|---|---|
| Contract_Amount | DECIMAL(18,2) | 合同总金额（含税） |
| Currency | CHAR(3) | ISO 货币代码，如 CNY、USD |
| Tax_Rate | DECIMAL(5,2) | 税率，如 13.00 |
| Amount_Without_Tax | DECIMAL(18,2) | 计算字段：Contract_Amount / (1 + Tax_Rate/100) |
3.2.4 起止日期（Start & End Date）
日期字段是续约提醒的核心驱动。关键设计要点：
- Start_Date：合同生效日期，用于计算服务周期
- End_Date：合同到期日期，触发续约提醒的基准点
- Notice_Period_Days：提前通知天数，如
90表示提前90天触发提醒 - 提醒计算规则：
提醒日期 = End_Date - Notice_Period_Days
常见陷阱：部分合同存在“自动续约”条款，但系统仅根据 End_Date 触发提醒，导致在自动续约生效后仍发送续约提醒，造成业务干扰。建议在续约条款字段中明确标识自动续约状态，并在提醒逻辑中增加判断。
3.2.5 续约条款（Renewal Terms）
续约条款字段决定了续约流程的自动化程度。推荐使用枚举类型 + 文本备注的组合：
-- 续约类型枚举定义
CREATE TYPE renewal_type_enum AS ENUM (
'auto_renew', -- 自动续约（无需人工确认）
'manual_renew', -- 手动续约（需销售发起流程）
'non_renew', -- 不续约（合同到期终止）
'renegotiate' -- 重新谈判（条款变更后续约）
);
-- 续约条款表结构示例
CREATE TABLE contract_renewal_terms (
contract_id VARCHAR(50) PRIMARY KEY,
renewal_type renewal_type_enum NOT NULL,
auto_renewal BOOLEAN DEFAULT FALSE,
renewal_term_months INT, -- 续约期限（月）
price_adjustment_rate DECIMAL(5,2),-- 价格调整百分比
renewal_notice_days INT, -- 续约通知期（天）
special_terms TEXT, -- 特殊续约条件（JSON格式）
created_at TIMESTAMP DEFAULT NOW()
);3.3 数据结构关系图
下图展示了采购合同核心字段之间的数据关系，以及它们如何支撑续约提醒与商机联动流程：
3.4 续约场景下的字段联动逻辑
在合同到期前，系统需要根据上述字段的组合状态，自动判断并触发相应的销售流程。以下是一个典型的字段联动判断逻辑：
-- 续约流程触发伪代码
IF End_Date - CURRENT_DATE <= Notice_Period_Days THEN
IF Auto_Renewal = TRUE THEN
-- 自动续约：系统自动生成续约合同，发送通知给采购与财务
CALL AutoRenewalProcess(Contract_ID);
ELSE IF Renewal_Type = 'manual_renew' THEN
-- 手动续约：创建续约商机，分配给对应销售负责人
CALL CreateRenewalOpportunity(Contract_ID, Sales_Owner);
ELSE IF Renewal_Type = 'non_renew' THEN
-- 不续约：触发合同终止流程，通知相关方
CALL ContractTerminationProcess(Contract_ID);
ELSE IF Renewal_Type = 'renegotiate' THEN
-- 重新谈判：创建谈判任务，发送给采购经理
CALL CreateNegotiationTask(Contract_ID, Procurement_Manager);
END IF;
END IF;
关键设计原则：续约条款字段应作为“决策主数据”，而非“备注信息”。建议在合同录入阶段强制填写续约类型，否则系统应阻止合同生效或发出警告。这能有效避免因数据缺失导致的续约流程中断。
3.5 字段数据质量要求
为确保续约提醒与商机联动的准确性，核心字段必须满足以下数据质量规则：
- 完整性：合同编号、供应商ID、起止日期、续约类型为必填项，不允许为空
- 唯一性：合同编号全局唯一，不允许重复
- 一致性：供应商ID必须在供应商主表中存在对应记录
- 时效性：End_Date 必须大于 Start_Date，且 Notice_Period_Days 必须为正整数
- 准确性：金额字段保留两位小数，币种使用ISO标准代码
通过以上字段定义与数据结构设计，企业可以构建一个可靠的合同数据底座，为后续的续约提醒自动化与商机联动提供坚实的数据支撑。