4. 寻源物品与需求清单

在RFQ寻源事件中，需求清单是采购方与供应商之间最核心的数据交换载体。它定义了“买什么、买多少、何时要、预期成本是多少”，并附带技术或商务证明文件。需求清单的准确性与结构化程度，直接决定了后续报价对比、订单转换和履约跟踪的效率。

4.1 需求清单的核心字段与业务含义

每一行寻源物品（Line Item）必须包含以下标准化字段，缺一不可：

4.2 需求清单的创建流程与数据来源

需求清单通常通过以下三种方式进入RFQ事件：

1. 手动录入：采购员在SRM界面逐行添加物料编码、数量、日期等字段。适用于小批量、非标或紧急寻源。
2. 从采购申请（PR）导入：PR经审批后，系统自动将PR行项目转换为RFQ行项目。这是最规范、最常用的方式，可避免重复录入。
3. 从Excel批量导入：使用系统提供的标准导入模板，一次性上传数百行物料。系统需做字段校验（如编码存在性、日期格式、单位合法性）。

4.3 需求清单的数据结构（SRM系统视图）

以下为SRM系统中需求清单的典型数据库表结构（简化示意），供系统实施参考：

-- RFQ行项目表（rfq_line_item）
CREATE TABLE rfq_line_item (
    line_id            INT PRIMARY KEY AUTO_INCREMENT,
    rfq_id             INT NOT NULL,               -- 关联RFQ事件头
    line_number        INT NOT NULL,               -- 行号（排序用）
    material_code      VARCHAR(50) NOT NULL,       -- 物料编码
    material_desc      VARCHAR(200),               -- 物料描述（冗余字段）
    quantity           DECIMAL(18,2) NOT NULL,     -- 需求数量
    unit               VARCHAR(10) NOT NULL,       -- 单位
    expected_unit_price DECIMAL(18,2),             -- 期望单价
    currency           VARCHAR(3) DEFAULT 'CNY',   -- 币种
    delivery_date      DATE NOT NULL,              -- 交货日期
    attachment_count   INT DEFAULT 0,              -- 附件数量
    status             VARCHAR(20) DEFAULT 'ACTIVE',-- 行状态
    created_by         VARCHAR(50),
    created_date       DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- 需求附件表（rfq_line_attachment）
CREATE TABLE rfq_line_attachment (
    attachment_id      INT PRIMARY KEY AUTO_INCREMENT,
    line_id            INT NOT NULL,               -- 关联行项目
    file_name          VARCHAR(200) NOT NULL,       -- 原始文件名
    file_path          VARCHAR(500) NOT NULL,       -- 存储路径
    file_size          INT,                        -- 文件大小（字节）
    file_type          VARCHAR(50),                -- MIME类型
    upload_date        DATETIME DEFAULT CURRENT_TIMESTAMP
);

4.4 需求清单与供应商报价的映射关系

供应商在报价时，必须针对RFQ中的每一行需求清单进行响应。系统需要确保报价行与需求行严格一一对应，避免漏报或错报。以下SVG展示了从需求清单到报价清单的映射流程：

4.5 需求附件上传的最佳实践

附件是需求清单中容易被忽视但极其重要的组成部分。技术图纸、检测标准、包装规范等文件，如果缺失或格式混乱，将直接导致供应商报价偏差甚至废标。

• 文件命名规范：建议采用“物料编码_文件类型_版本号”格式，如“MTR-001_图纸_V2.1.pdf”。避免使用“新建文件夹(1).zip”等无意义名称。
• 批量上传与预览：SRM系统应支持多文件同时上传，并在界面上提供缩略图预览（针对PDF和图片），方便采购员确认附件内容是否正确。
• 附件与行项目的关联：每个附件必须明确关联到具体的行项目（Line Item），而非仅挂在RFQ头层级。供应商在报价时，系统应自动展示该行对应的所有附件。
• 版本管理：如果采购方在寻源过程中更新了图纸或规格书，系统应保留历史版本，并通知所有已受邀供应商重新下载。

4.6 需求清单的变更与版本控制

在RFQ事件处于“报价中”状态时，采购方可能需要对需求清单进行修改（如增加物料、调整数量、推迟交货日期）。系统必须支持受控变更：

1. 采购方发起“需求清单变更”操作，系统生成一个新的版本号（如V1.0 → V1.1）。
2. 系统自动向所有已受邀供应商发送变更通知（邮件+站内消息）。
3. 供应商在报价界面看到变更标记，并可查看变更前后的差异对比（Diff）。
4. 供应商已提交的报价行，如果对应的需求行未变更，则保留原报价；如果需求行已变更，则标记为“需重新报价”。

以下SVG展示了需求清单变更时的版本控制流程：

4.7 需求清单的校验与提交

在RFQ事件发布前，系统必须对需求清单进行最终校验，确保数据完整且符合业务规则：