xas-skills/skills/erp-requirements-design/references/business-checklist.md

业务访谈与产品检查清单

本文件用于内部查漏，不是文档目录、必写清单或一次发给用户的问卷。先用已有资料贯通主流程，只对影响范围、权责或完成标准的缺口提问；已明确的内容直接写稿。

所有业务先检查

关注点	需要明确的业务结论
目标与范围	解决什么问题，本期做到哪一步，哪些事项未纳入
角色与入口	谁申请、审批、办理和管理，各从哪里进入
必要信息	办理必须填写什么、哪些可从已有资料带出
完成标准	审批、实际办理和登记分别何时完成
权限与变更	谁能查看及处理，修改或取消如何影响已办理事项
验收与未决	核心结果如何检查，哪些问题确需业务确认

检查不等于全部展开。一个明确的短句可以承载结论，无需将每项再拆成字段、状态、权限和异常表。

页面与基础资料

确认菜单所属中心、模块和实际页面；共同父级路径集中写一次，跨模块入口单独补充。不同入口处理同一事项时，说明共用单据。菜单归属不能直接套用其他模块。

基础档案通常只需维护入口、维护人、建档方式及业务必要字段。用户已确定字段清单时按清单执行，不从通用检查项自动补入平台、系统标识、账号绑定、用途或凭据管理。

列表保留业务需要的查询、进度及操作，通用排序、分页、加载提示和每个错误文案不用逐项写。只有用户提出专项交互要求，或这些行为直接影响办理判断时再展开。

审批与通知

涉及审批时检查申请人、有效审批人、通过后的接手人和完成标志；退回、撤回及批准后修改按实际流程简述。审批层级、金额门槛和多人通过规则未确认时保留待定，不从示例推断。

涉及通知时写明何时提醒、提醒谁、通过什么渠道、进入何处办理。提醒成功和业务完成分开表达；失败处理合并为业务原则，不扩写发送机制与重试时序。

按业务条件追加检查

以下只检查本期实际涉及的部分。结果写回对应功能，不新建一套“完整性附录”。

业务条件	必须保留的判断
多明细或部分办理	明细粒度、整单进度、剩余工作；部分完成不能显示全部完成
已执行后变更或取消	保留已发生事实，明确未办理部分及后续补充、重审方式
外部执行结果未知	先核实再处理，不把未知当失败而直接重复执行；明确跟进人
跨部门或组织权限	查看和办理范围、敏感字段的必要隔离，不能只靠菜单名称表达
跨模块联动	来源、触发动作、目标结果及可追溯关系；失败由谁核对，避免重复业务单据
金额和数量	单位、币种、精度、合计及上下界；关键口径和舍入规则不得为简洁而省略
条件附件或门槛	触发条件、等于门槛如何处理及修改后的影响；未知上限待确认
存量或在途记录	历史与新流程如何衔接，避免覆盖事实或重复办理

金额、人数、容量和时限没有依据时不虚构数值。缺少页面或操作证据时标为未核实，不把标签、星号、空列表当作行为验证。

采销业务追加检查

先确认现货销售、以销定采、独立备货、代采中的哪些属于本期，不因系统名为 ERP 自动加入合同、收付款、发票和财务。

涉及分批履约、退货或库存时，再核对：

• 销售、采购与收发货的关联关系，分批数量、已执行与剩余口径。
• 商品来源、单位及有无实物唯一码；实际收发货时点和库存变动时点。
• 部分到货、剩余取消、客户或供应商退货的责任及数量边界。
• 退货对库存、进度和结算的影响，是否补发或补采，不默认恢复原单未交数量。

需要例子时参考 采销需求片段，不把示例规则或数字直接套为本项目要求。

验收与评审

默认按核心业务合并为“验收场景｜预期结果”，用具体结果代替“正常、准确、友好”。需要前置条件才能判断结果时再补条件；用户要求测试用例时另行展开边界组合。

只记录影响业务定稿的未决事项及责任人，不把被用户删去的字段或通用技术参数重新列为待确认。已确认内容写回正文并移出待定表。

交付前核对主流程、关键权限、已发生事实和进度口径仍然完整，Word、Markdown、图示同步；需求稿的验收要求不表示系统已验收通过。