供应商交付清单把外部团队、供应商或软硬件伙伴的成果接口逐行写清楚：交付什么、按什么标准验收、由谁接收、当前处于什么状态。本文先给一张可直接复制到表格工具中的空白模板，再逐字段说明填写口径、区分必填与选填，并用一条完整记录示范如何形成可验收的交付条目，最后说明清单在项目推进中的更新与维护方法。如果清单需要在多人之间流转，也可以放到 ONES 这类协作平台中随工作项跟踪状态。
要点总览（TL;DR）
- 供应商交付清单按交付物逐行登记，核心字段覆盖交付物名称、供应商、交付类型、验收标准、计划与实际交付日期、接收人、验收状态、遗留问题与下一步。
- 交付物名称、供应商、交付类型、验收标准、计划交付日期、接收人和验收状态建议设为必填，合同编号、存放位置、供应商责任人可按交付类型升为必填。
- 验收标准要写成可对照的证据，例如接口数量、字段完整率、样机实测结果，接收人才能给出明确结论。
- 清单在提交、验收、结论形成和每周例会四个时点更新，状态按待交付到已通过流转，有条件通过须写明遗留项关闭时间与责任人。
- 字段增删先小范围试用，删除前归档历史数据，修改取值保留旧值，清单可作为交接评审的输入材料。
可复制空白供应商交付清单模板
下表可直接复制到 Excel、在线表格或协作平台的工作项表格中使用。列顺序按“身份信息—交付内容—验收口径—时间与责任人—状态与遗留”排列，便于从左到右阅读和筛选。每行只登记一个交付物，同一供应商交付多个成果时拆成多行，不要在一行内合并多个交付物，否则验收状态无法独立记录。
| 序号 | 交付物名称 | 供应商/外部团队 | 合同或工作包编号 | 交付类型 | 规格与验收标准 | 交付形式与存放位置 | 计划交付日期 | 实际交付日期 | 供应商责任人 | 接收人 | 验收状态 | 遗留问题 | 下一步与负责人 | 变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | ||||||||||||||
| 2 | ||||||||||||||
| 3 |
填写约定有三条：一是“序号”仅用于行定位，交付物名称才是识别依据；二是“交付类型”建议限定为文档、软件版本、硬件样件、数据、服务报告等固定取值，便于筛选统计；三是“验收状态”统一使用“待交付、已交付待验收、验收中、已通过、有条件通过、退回整改”六个取值，避免出现“差不多了”“基本完成”这类无法判断的表述。验收结论只在“已通过”“有条件通过”“退回整改”三种状态下填写，并同步写明依据。
每个字段记录什么：交付清单字段说明
字段说明解决的是口径一致问题：同一张清单由不同人填写时，对“验收标准”“存放位置”的理解要相同，否则后续交接会出现争议。下表按四类字段逐项说明含义与填写口径。
| 字段 | 类别 | 记录什么 | 填写口径 |
|---|---|---|---|
| 交付物名称 | 交付物与供应商身份 | 本次要交接的具体成果 | 用名词性短语写清对象和版本，如“订单服务接口说明 v1.2”，避免只写“文档”“接口” |
| 供应商/外部团队 | 交付物与供应商身份 | 成果来源方 | 写到具体团队或公司名称，同一供应商多个团队时注明团队 |
| 合同或工作包编号 | 交付物与供应商身份 | 该交付物对应的约定来源 | 填写合同号、采购单号或工作包编号，便于回溯约定范围 |
| 交付类型 | 验收标准与交付形式 | 成果的形态分类 | 从固定取值中选择，用于筛选和确定验收方式 |
| 规格与验收标准 | 验收标准与交付形式 | 判断合格的具体条件 | 写可核验的条件，如字段完整率、缺陷等级上限、样件数量与检测项 |
| 交付形式与存放位置 | 验收标准与交付形式 | 成果以什么形式提交、放在哪里 | 写明文件库路径、代码仓库分支、样件签收地点或系统入口 |
| 计划交付日期 | 时间、状态与责任人 | 约定的交付时间 | 与合同或工作包保持一致，精确到日 |
| 实际交付日期 | 时间、状态与责任人 | 成果实际到达时间 | 以接收人确认收到为准，未收到时留空 |
| 供应商责任人 | 时间、状态与责任人 | 供应商侧对接人 | 填写姓名与联系方式，便于催办和澄清 |
| 接收人 | 时间、状态与责任人 | 内部负责验收的人 | 写到具体岗位或姓名，避免只写部门 |
| 验收状态 | 时间、状态与责任人 | 当前所处环节 | 使用统一取值，状态变化时更新并记录日期 |
| 遗留问题 | 遗留问题与变更记录 | 验收中发现的待处理事项 | 逐条编号，写明问题描述、影响范围和期望解决时间 |
| 下一步与负责人 | 遗留问题与变更记录 | 当前状态之后的动作 | 写清动作、责任人和完成时间，如“补充接口异常码说明，供应商张工，3 个工作日内” |
| 变更记录 | 遗留问题与变更记录 | 交付范围或时间的调整 | 记录变更内容、提出方、确认日期，原计划保留不覆盖 |
“规格与验收标准”是最容易写空的一列。有效写法是把验收动作落到可观察的证据上，例如“接口文档覆盖全部 32 个接口，每个接口含请求参数、返回码和异常说明，抽查 5 个接口与测试环境一致”。这样的标准在验收时可以直接对照，不需要再开会解释。
必填与选填：哪些字段不能空
必填项的作用是保证每条记录都能被独立追溯和验收。缺少交付物名称，清单无法定位对象；缺少验收标准，接收人无法判断是否合格；缺少接收人，成果到达后无人负责确认。以下对照表给出建议的必填范围。
| 字段 | 建议 | 理由或适用场景 |
|---|---|---|
| 交付物名称 | 必填 | 清单的识别主键，缺失则整行无法使用 |
| 供应商/外部团队 | 必填 | 明确成果来源，便于责任追溯 |
| 交付类型 | 必填 | 决定验收方式和后续归档位置 |
| 规格与验收标准 | 必填 | 没有标准就无法形成验收结论 |
| 计划交付日期 | 必填 | 用于判断是否延期，支撑进度跟踪 |
| 接收人 | 必填 | 明确验收责任，避免成果无人认领 |
| 验收状态 | 必填 | 反映当前环节，是清单的核心跟踪字段 |
| 合同或工作包编号 | 建议必填 | 涉及多合同并行时必填；单一工作包场景可简化为备注 |
| 交付形式与存放位置 | 建议必填 | 文档、软件类交付必填；现场服务类可写服务记录入口 |
| 供应商责任人 | 建议必填 | 需要频繁澄清和催办时必填 |
| 实际交付日期 | 选填 | 成果到达后填写，未交付时留空 |
| 遗留问题 | 选填 | 验收发现问题时填写，无问题时留空或写“无” |
| 下一步与负责人 | 选填 | 存在待办动作时填写，已关闭条目可留空 |
| 变更记录 | 选填 | 发生范围或时间调整时填写 |
必填项可以按交付类型调整。文档类交付应把“交付形式与存放位置”升为必填，因为文件版本和路径直接影响验收；硬件样件类交付应把“供应商责任人”升为必填，便于安排物流和签收；服务类交付可以把“规格与验收标准”写成服务完成清单和签字确认方式。调整规则应在清单启用时写进表头说明，避免不同项目各自解释。
填写示例：一条完整交付记录
以下为演示情景，用于说明各字段如何配合形成可验收条目，非真实项目案例。假设某制造企业的外部软件团队按工作包交付一套设备数据采集接口。
| 字段 | 填写内容 |
|---|---|
| 序号 | 7 |
| 交付物名称 | 设备数据采集接口说明及联调记录 v1.0 |
| 供应商/外部团队 | 某工业软件供应商 集成开发组 |
| 合同或工作包编号 | WP-2024-03 数据采集模块 |
| 交付类型 | 文档 + 软件版本 |
| 规格与验收标准 | 覆盖 12 类设备协议，每类含字段定义、采样频率和异常码；联调记录包含 3 台样机实测结果，通信成功率不低于 99%；文档与测试环境版本号一致 |
| 交付形式与存放位置 | 文档存放于项目知识库“外部交付/数据采集”目录；软件包存放于内部制品库 release 分支 tag v1.0 |
| 计划交付日期 | 2024-06-14 |
| 实际交付日期 | 2024-06-17 |
| 供应商责任人 | 张工（集成开发组） |
| 接收人 | 内部平台组 李工 |
| 验收状态 | 有条件通过 |
| 遗留问题 | ① 2 类老旧设备协议缺少异常码说明；② 样机实测仅覆盖 2 台，第 3 台待补测 |
| 下一步与负责人 | 供应商张工 3 个工作日内补充异常码说明；李工安排第 3 台样机补测，完成后更新状态 |
| 变更记录 | 2024-06-10 双方确认交付日期由 06-14 顺延至 06-17，原因：样机到位延迟 |
这条记录体现了三个配合关系。验收标准写成可对照的条件，接收人才能给出“有条件通过”而不是模糊结论；遗留问题逐条编号，并与“下一步与负责人”一一对应，关闭条件清晰；变更记录保留原计划并写明原因，后续复盘延期时不需要再翻聊天记录。实际交付日期晚于计划日期，清单本身不做评价，延期原因由变更记录承载。
清单的调整与维护方法
清单在项目启动时建立，在交付推进中持续更新。维护的重点是让状态变化有明确触发点、关闭有可核验条件、字段调整有统一入口。
更新时点与责任人
建议设置四个固定更新时点：供应商提交成果当天，由供应商责任人更新实际交付日期和存放位置；接收人开始验收时，更新验收状态为“验收中”；验收结论形成当天，由接收人填写状态和遗留问题；每周例会上，由清单维护人核对全部未关闭条目。清单维护人通常由项目经理或交付协调人担任，负责检查必填项是否为空、状态是否与遗留问题匹配。
状态流转与关闭条件
状态按“待交付→已交付待验收→验收中→已通过/有条件通过/退回整改”流转。“已通过”的关闭条件是验收标准逐条核对无遗留问题；“有条件通过”允许存在不影响使用的遗留项，但必须写明关闭时间和责任人，遗留项全部关闭后改为“已通过”；“退回整改”需要写明退回原因和重新提交时间。任何状态变化都应留下日期，便于统计交付周期。
字段增删的维护原则
字段调整遵循三条原则：新增字段先在小范围试用一个交付周期，确认填写成本可接受后再推广；删除字段前确认历史数据已归档，避免追溯断档；修改取值集合时保留旧值，用新增取值替代，不直接覆盖已有记录。字段数量以能支撑验收和追溯为限，过多的选填项会降低填写意愿。
与交接评审的衔接
交付清单可以作为交接评审的输入材料：评审前由维护人导出未关闭条目和“有条件通过”条目，评审中逐条确认遗留问题的处理安排，评审后把结论回写到清单。对于涉及多角色、多专业和外部供应商协作的研发场景，ONES 支持把需求分解、任务执行、测试反馈和变更处理放在同一平台推进，交付物模板和过程数据也可以沉淀为可复用资产，清单中的状态与遗留问题能够随工作项持续跟踪，减少表格在多方之间反复传递造成的版本不一致。具体的工作项类型与字段配置需按实际方案确认。
常见问题
供应商只交付一个综合成果包，清单还需要拆成多行吗？
建议按可独立验收的最小单元拆行。一个成果包如果包含文档、软件版本和培训服务，三者的验收标准、接收人和完成时间通常不同，合并成一行会导致状态只能整体推进，部分完成时无法记录。若确实无法拆分，可在“规格与验收标准”中列出分项条件，并在“遗留问题”中逐条编号，但仍建议在条件允许时拆行。
交付物在验收中被退回整改，原来的记录要保留还是新建一行？
保留原行，在原行上更新验收状态为“退回整改”，并在“遗留问题”中写明退回原因和重新提交时间。重新提交后更新实际交付日期，状态回到“已交付待验收”。同一交付物反复整改时，用变更记录或遗留问题编号区分轮次，避免新建多行造成同一交付物重复统计。
清单里的验收标准由供应商写还是由接收人写？
建议由接收人主导起草、与供应商确认后写入。接收人清楚内部使用场景和验收方式，供应商了解成果细节，双方确认后的标准才能同时具备可核验性和可执行性。标准写入清单后，后续验收以清单文字为准，口头补充的约定应回写到清单，避免验收时各执一词。
多个供应商并行交付时，清单如何避免混乱？
可以共用一张清单，通过“供应商/外部团队”和“合同或工作包编号”两列筛选，按供应商分别导出视图。若供应商数量多、交付节奏差异大，也可以按供应商拆分为多张清单，但表头字段和状态取值保持一致，便于汇总。清单维护人负责每周核对各供应商未关闭条目，防止某一家长期停留在“验收中”。
清单需要和合同或采购流程对接吗？
清单只记录交付物与约定来源的对应关系，填写合同号或工作包编号用于回溯约定范围。合同条款审查、付款节点和采购招标流程不在清单范围内，由相应流程负责。清单中的验收结论可以作为内部交接依据，涉及合同履约的正式确认仍按合同约定执行。
