供应商交付清单要覆盖七类信息：交付对象、数量与规格、交付时间与地点、验收标准与方式、随附文件、对接人与状态、问题与变更记录。其中交付对象、数量规格、交付时间、验收标准、对接人和状态为必填，其余按交付类型选填。本文给出一张可直接复制的空白表格，并逐字段说明填写口径、必填判断和一条完整示例，方便对接人拿到就用。
要点总览（TL;DR）
- 供应商交付清单按七类信息组织：交付对象、数量与规格、交付时间与地点、验收标准与方式、随附文件、对接人与状态、问题与变更记录。
- 交付对象、规格/型号、数量与单位、交付时间、验收标准、双方对接人、状态构成最小可追踪集合，其余字段按货物类或服务类交付取舍。
- 清单按一个交付批次一行填写，验收标准写可检查的条件，验收方式写检查动作，问题记录写到处理结论，状态才有依据变更。
- 字段随项目阶段调整，判断依据是它是否影响判断交付是否完成；更新按交付节点驱动，我方对接人负责状态与验收结论。
- 交付批次多、双方需同时更新时，可把清单落到协作工具中维护，ONES Wiki 支持模板库创建文档、关联项目任务并保留版本记录。
可复制空白模板：供应商交付清单表
下表按“一个交付批次一行”组织。复制到表格工具后，保留表头，删除示例行中的占位内容即可开始填写。空白单元格表示待填，不要用“无”“待定”等字样提前占位，避免后续筛选时混淆。
| 序号 | 交付对象 | 规格/型号 | 数量 | 单位 | 交付时间 | 交付地点 | 验收标准 | 验收方式 | 随附文件 | 供应商对接人 | 我方对接人 | 状态 | 问题与变更记录 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | （填写交付物名称） | （填写规格或版本） | （填写数量） | （填写单位） | （YYYY-MM-DD 或时间段） | （填写地点或交付方式） | （填写可判定的验收条件） | （填写抽检、全检、演示等） | （填写随附文件名称） | （姓名/联系方式） | （姓名/联系方式） | （待交付/部分交付/待验收/已验收/异常） | （记录问题、变更及处理结果） |
精简版字段清单，便于在聊天工具或邮件中快速传递：序号、交付对象、规格/型号、数量、单位、交付时间、交付地点、验收标准、验收方式、随附文件、供应商对接人、我方对接人、状态、问题与变更记录。字段顺序与上表一致，复制时整行带走，避免漏项。
字段说明：每个字段填什么、怎么填
字段填写的共同原则是“让没参与沟通的人也能判断这一行是否完成”。描述要落到可核对的对象和条件上，避免使用“按要求”“合格即可”这类无法验证的表述。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 交付对象 | 本次交付的具体物品、服务或文档 | 写名称加用途或所属模块，如“控制柜A型”“接口联调服务” | 只写“设备”“资料”，无法对应到具体批次 |
| 规格/型号 | 区分同一对象不同版本的关键属性 | 写型号、版本号、材质或关键参数 | 把规格写进交付对象，导致两列重复 |
| 数量与单位 | 计量交付规模 | 数量写数字，单位写件、套、台、人天、份等；服务类写清计量方式 | 数量写“一批”，单位留空 |
| 交付时间 | 约定完成交付的时点或区间 | 用YYYY-MM-DD；分批交付写清每批时间 | 写“月底前”，跨月时产生歧义 |
| 交付地点 | 实物送达地或服务/文档的交付渠道 | 写具体地址、仓库或系统/共享目录名称 | 只写“公司”，无法安排接收 |
| 验收标准 | 判断交付是否合格的依据 | 写可检查的条件，如尺寸公差、功能项、文档章节完整性 | 写“符合要求”，没有可核对内容 |
| 验收方式 | 用什么动作完成验收 | 写抽检比例、全检、现场演示、文档评审等 | 与验收标准混写在同一格 |
| 随附文件 | 交付时必须一并提供的材料 | 写文件名称，如合格证、检测报告、操作手册、发票 | 写“相关文件”，接收方无法核对 |
| 供应商对接人 / 我方对接人 | 双方执行与确认的责任人 | 写姓名加联系方式，一方一人为主 | 只写部门，出问题时找不到人 |
| 状态 | 当前所处环节 | 从待交付、部分交付、待验收、已验收、异常中选一个 | 同一行出现两个状态描述 |
| 问题与变更记录 | 交付过程中的偏差与处理 | 写日期、问题、处理动作、结论，按时间追加 | 只写“有问题”，没有处理结果 |
验收标准与验收方式要分开填：标准回答“达到什么算合格”，方式回答“谁来、用什么方法检查”。例如标准写“外壳无划痕、接口功能全部通过”，方式写“到货全检外观，接口由我方测试人员逐项验证”。两者分开后，验收争议可以定位到是条件不清还是方法未执行。
必填与选填：哪些字段不能空
必填字段的作用是保证每一行都能被追踪和关闭。交付对象、规格/型号、数量与单位、交付时间、验收标准、双方对接人、状态构成最小可追踪集合；交付地点、验收方式、随附文件、问题与变更记录按交付类型取舍。
| 字段 | 货物类交付 | 服务类交付 | 说明 |
|---|---|---|---|
| 交付对象 | 必填 | 必填 | 两类都需明确交付内容 |
| 规格/型号 | 必填 | 建议填写 | 服务类可写服务等级或版本 |
| 数量与单位 | 必填 | 必填 | 服务类用人天、次、份计量 |
| 交付时间 | 必填 | 必填 | 服务类可写起止时间 |
| 交付地点 | 必填 | 选填 | 服务类可写线上会议或系统名称 |
| 验收标准 | 必填 | 必填 | 服务类侧重成果物与完成条件 |
| 验收方式 | 建议填写 | 必填 | 服务类常需评审或演示 |
| 随附文件 | 建议填写 | 建议填写 | 货物类多为合格证、检测报告 |
| 双方对接人 | 必填 | 必填 | 明确执行与确认责任 |
| 状态 | 必填 | 必填 | 用于跟踪闭环 |
| 问题与变更记录 | 选填 | 选填 | 发生偏差时必填 |
字段留空要区分两种情况：尚未到填写时点，保持空白并在状态中体现“待交付”；确认不适用，在单元格写“不适用”并注明原因，例如服务类交付在交付地点写“线上交付，不涉及物流”。两种处理方式不要混用，否则统计未完成项时会把不适用项算进去。
填写示例：一条完整交付记录
以下为演示情景，用于说明字段如何配合，不代表真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 序号 | 3 |
| 交付对象 | 产线控制柜 |
| 规格/型号 | KC-200，含主控模块与接线端子 |
| 数量 / 单位 | 2 / 台 |
| 交付时间 | 2025-06-18 |
| 交付地点 | 某厂区二号仓库收货口 |
| 验收标准 | 外观无变形划伤；上电后主控模块自检通过；端子标识与图纸一致 |
| 验收方式 | 到货全检外观，上电抽检1台，端子对照图纸逐项核对 |
| 随附文件 | 出厂检测报告、接线图、合格证 |
| 供应商对接人 | 供应商项目经理（联系方式略） |
| 我方对接人 | 设备工程师（联系方式略） |
| 状态 | 已验收 |
| 问题与变更记录 | 2025-06-18 到货，1台端子标识缺失；当日补发标识贴并复核，6-19确认补齐，验收通过 |
这条记录的填写依据是：交付对象与规格分开写，便于按型号统计；数量用数字加单位，避免“两台左右”这类模糊表述；验收标准写成三条可检查的条件，验收方式对应说明检查范围；问题记录按日期、现象、处理动作、结论的顺序追加，最后把状态改为“已验收”，形成同一行内的闭环。
从示例可以提炼三条规律：第一，验收标准里的每一条都能在验收方式中找到对应的检查动作；第二，问题记录写处理结果而不只是现象，状态才有依据变更；第三，对接人写具体角色，交接时不需要再回头查沟通记录。
调整与维护：按项目改字段、按节奏更新
清单的字段应随项目阶段和交付类型调整，判断依据是“这个字段是否影响判断交付是否完成”。影响验收、交接或追责的字段保留；仅用于内部统计且能从其他系统取得的字段可以删减，避免表格过宽导致填写意愿下降。
新增字段的常见情形包括：多批次交付需要增加“批次号”，涉及安装调试需要增加“安装条件”，跨境或跨区域交付需要增加“物流单号”。删减字段时先确认历史数据是否还需要按该字段检索，若需要，保留列但标注停用，不要直接删除历史记录。
更新节奏建议按交付节点驱动：交付前确认时间和对接人，到货或服务完成当天更新状态，验收完成后当天填写结论和问题处理结果。责任人按行划分，由我方对接人负责更新状态与验收结论，供应商对接人负责提供随附文件和问题说明。每周固定一次核对未关闭行，重点看状态停留在“待验收”超过约定时间的记录。
归档时按项目或供应商分别保存版本，保留每次状态变更的日期。清单与项目计划、验收记录的衔接边界要清楚：清单记录单个交付批次的对象、数量、验收结论和问题闭环；整体排期、里程碑调整放在项目计划中；验收报告、检测报告等正式文件放在文档库中，清单只写文件名称和存放位置，不复制全文。
当交付批次较多、双方需要同时更新状态和问题时，可以把这张表落到协作工具中维护。ONES Wiki 支持使用模板库创建文档，并可将文档关联项目任务，适合把交付清单作为项目文档持续更新；其版本记录支持查看与回滚，便于追溯每次状态和问题记录的修改。若交付涉及研发、测试与供应商多角色协同，ONES ALM 方案可将交付物模板和评审节点沉淀为可复用资产，让清单中的验收结论与变更处理在同一平台推进。具体采用哪种承载方式，取决于团队已有的协作习惯和交付批次规模。
常见问题
供应商分批交付时，清单是一批一行还是一份合同一行？
按交付批次一行填写。同一份合同下分三次到货，就写三行，每行有自己的交付时间、数量、验收结论和问题记录。这样状态可以逐批推进，不会出现“部分交付”长期挂在同一行、无法判断哪一批已验收的情况。若需要按合同汇总，可在表格外另加一列合同编号，用筛选或透视汇总，不必把多批合并成一行。
服务类交付没有实物，数量和交付地点怎么填？
数量按服务的计量方式填写，例如人天、次、份、场，单位与数量成对出现；交付地点可写线上会议、共享目录或系统名称，确认不涉及物流时注明“线上交付，不涉及物流”。服务类交付的重点应放在验收标准与验收方式上，把成果物名称、完成条件和评审或演示方式写清楚，比补齐地点字段更有价值。
验收标准写多细才算够用？
判断标准是：没参与前期沟通的人拿着这一行，能否独立判断交付是否合格。可检查的条件包括尺寸公差、功能项清单、文档章节完整性、接口测试通过项等。写完标准后，对照验收方式检查每条标准是否都有对应的检查动作；如果某条标准找不到检查动作，说明它还不够具体，需要继续拆解。
清单里的问题记录和项目计划中的风险登记是什么关系？
清单记录单个交付批次内发生的偏差、变更及处理结果，随该行一起关闭；项目计划关注整体排期、里程碑和跨批次的资源安排。同一件事可能两边都出现：清单写“某批端子标识缺失，已补发并复核”，项目计划写“该批次延期一天，是否影响后续安装节点”。清单负责批次闭环，计划负责整体节奏，两者通过批次号和日期对应，不需要互相复制全文。
把清单放到协作工具里维护，需要额外注意什么？
先确认双方都能访问并更新同一份清单，再约定状态字段的取值和更新责任人，避免出现两套口径。ONES Wiki 支持使用模板库创建文档、将文档关联项目任务，并记录页面版本、支持查看与回滚，适合把交付清单作为项目文档持续维护；涉及研发、测试与供应商多角色协同时，ONES ALM 方案可将交付物模板和评审节点沉淀为可复用资产。具体承载方式取决于团队已有协作习惯和交付批次规模。
