feat: add ERP requirements design skill

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

@@ -0,0 +1,104 @@
+# 业务访谈与产品检查清单
+
+按业务选择使用；这是分析辅助，不是一次性发给用户的问卷。流程已清楚时直接写稿，未知项放回受影响的需求处。
+
+## 从一句话提炼可讨论的业务
+
+优先明确业务背景、目标、使用角色、触发条件、完成标准和本期边界。用户提供流程时沿着“输入 → 处理 → 输出 → 下一位处理人”补齐断点，不先讨论技术。
+
+例：“销售填单，采购处理，仓库收发货。”先区分现货销售与销售带动采购，问是否需要独立备货。不要直接假设每张销售单必然生成一张采购单。
+
+每个重要缺口按业务名称记录：`确认事项 / 业务影响 / 可选方案或建议 / 决策角色 / 相关功能或章节 / 是否影响定稿`。建议不是默认批准；用户不回答时保留待确认。确认后同步正文、菜单、图示、权限、验收及版本表，不继续在待决表中保留该项。
+
+## 角色与权限
+
+- 业务操作者、审核人、管理人、只读查看人分别是谁；组织/岗位变化后如何交接未完成事项。
+- 能否看本人、本部门、负责范围或全部记录；能否查看金额、成本、利润、附件、导出结果。
+- 可见不等于可编辑，可编辑不等于可审批。本人能否审批本人单据、离职人员待办怎么处理，按需要确认。
+- 产品写可验证的权限结果，如“销售不能通过列表、详情、导出或直接访问查看其他销售的订单”；具体实现由开发设计。
+
+## 流程与状态
+
+- 起点、提交条件、接手角色、完成标准和最后一个业务动作。
+- 草稿、待处理、进行中、部分完成、完成、关闭等状态按实际需要采用，不强套统一名称。
+- 审批中允许改哪些内容；退回、驳回、撤回是否不同；修改后是否重审，原记录如何查看。
+- 一单多明细时，部分完成、部分退回、部分关闭如何显示总单状态和剩余工作。
+- 作废、删除、关闭、归档各自代表什么；发生后能否恢复、谁能看历史、关联单据怎么处理。
+- 超时、无人接单、人员停用、处理中断后的责任人和下一步入口。
+- 保存草稿、提交申请、提交业务单据、完成实际办理各自意味着什么；哪些字段允许草稿暂缺、提交前必须补全，用户从哪里继续未完成事项。
+
+## 页面与字段
+
+- 写清一级菜单、二级模块及实际需要的三级页面，区分导航菜单、详情页和申请类型；明确新增、复用或调整。不能仅写“独立入口”。
+- 未确定菜单时依据业务职责和现有导航提出具体建议，标明待确认。确认后给出完整路径；不因内部群管理属于行政中心而将其他模块一律归入行政中心。
+- 申请、审批、办理、查询和基础资料维护分别从哪里进入；多个入口如何关联同一单据、版本和状态；PC 与移动端分别覆盖哪些任务。
+- 父级菜单可见性不应扩大该中心其他功能的权限，子菜单、记录、字段及附件范围分别控制。
+- 基础档案的维护入口、维护角色、建档方式、标识来源、负责人及系统账号关联是否明确；变更、停用、交接与历史记录如何处理。外部角色登记不自动授予平台资格。
+- 接入已有页面时分别记录当前入口、页面标题和拟使用的产品名称。旧菜单规划与实站不一致、标签疑似复制错误时先列差异，不直接照搬。
+- 列表默认视图、筛选、排序、分页、关键列、进度、待办提示；筛选清空后应恢复什么。
+- 新建、编辑、详情、审批、处理、历史记录页之间的关系。
+- 字段含义、来源、选项、单位、是否必填、条件必填、带出/填写、编辑时点、合法范围及错误文案。
+- 查询无结果、无权限、加载失败、处理中、成功、结果不明分别怎么显示；重复点击后的业务结果。
+- 导入、导出、打印、附件只在本期需要时展开。说明导入预览、错误行、重复判断、部分成功是否允许和结果反馈，不设计文件服务实现。
+- 多组明细：每组对应什么对象，允许多少组，逐组必填与整单必填的区别，增删明细如何影响合计、附件和审批条件。
+- 条件附件：何种单价/总额/类型触发，等于门槛如何处理，每组还是整单上传，文件数量和大小、缺失提示、金额修改后是否重新判断。现有行政采购页面的门槛只是该流程的观察值，不自动套给采销。
+- 星号、限额提示、空列表和演示数据分别标注观察层级；没有实际操作验证时，不写成校验已通过或业务已完成。
+
+## 审批与通知
+
+- 哪些单据需要审批、触发条件、节点顺序、审批人来源、多人如何算通过、抄送与通知区别。
+- 无可用审批人时如何提示和处理；人员名单变更对在途单据是否生效。
+- 申请表预览的审批节点、通过方式和抄送信息如何展示；业务要求优先使用岗位/组的职责表述，当前测试账号姓名不作为长期审批规则。
+- 申请人在哪看进度，审批人在哪接待办，办理人从哪里接后续工作；“我发起的、我的待办、我的已办、抄送我的”和全局管理视角按业务分别说明，不仅列一个总菜单。
+- 审批通过后是否生成待办/业务单据，谁继续办理；审批通过不等于业务执行完毕。
+- 相同审批结果被重复处理时，业务单据和待办不应重复；联动失败时显示待处理/异常、由谁核对并恢复。这里只定义用户可观察的结果。
+- 通知渠道、触发事件、接收角色、简要内容、跳转目标、重复或失败时是否重发；不能把“已提交”写成“已通知到所有人”。
+
+## 跨模块接入
+
+每项联动写六件事：来源模块和单据、触发业务动作、带入的业务信息、目标单据或待办、双方可追溯入口、失败时的状态和责任人。
+
+确定已有数据从哪里来、谁维护、修改是否影响历史记录；需要保留成交时名称/价格等历史信息时，用业务语义说明，不指定数据存储结构。
+
+分清“计划生成入库单”“仓库确认收货”“库存已增加”三个结果。若上游可修改或取消，说明下游尚未办理、部分办理、全部办理三种情况下怎么办。
+
+来源单号、目标单号、经办人、审批完成/建单/办理时间分别代表哪个阶段；关联信息为空时显示什么、是否仍允许继续、谁核对补齐。看见已完成状态但关联单号为空，只能记为该记录现象，不能推断关联不需要或功能必然异常。
+
+## 数量与金额
+
+只对涉及它们的业务展开：
+
+- 数量单位、可否小数、最小/最大值、换算、是否允许超量、数量分配到单据或明细的口径。
+- 币种、含税/未税、折扣、运费、税额、金额汇总与舍入位置；客户和供应商价格是否分别管理。
+- 已执行、已退、剩余、可用、占用等名称逐一定义，不能把净数量当累计履约数量。
+- 规则未确认时以具名待确认事项保留；不要把其他系统的税率、审批金额门槛、精度或负库存策略带入本项目。
+- 有示例时标注虚构测试数据，并使用明确公式复核结果；公式和示例必须同一口径。
+
+## 采销业务追加检查
+
+先确认业务模式：现货销售、以销定采、独立备货、代采中的哪些属于本期。
+
+再按已选范围检查：
+
+- 销售与采购是否一对一、多对多；拆单、合单、分仓、分批及未分配数量。
+- 云库分类/品牌/系列/SKU、行政资产分类与实物唯一码分别是什么；新业务选择现有 SKU 还是允许自由填写，历史商品信息如何保留。
+- 有唯一码的商品是否逐件登记，码与数量怎样对应，重复、缺码、错码、换货怎么处理，退货如何核对原件；无唯一码商品按数量还是批次管理。页面有“是否有唯一码”并不证明这些环节已实现。
+- 库存出库现有“销售、寄出、借出”是否与本期场景相关；不同用途是否需要返回、结算或不同责任人，不把所有出库都当销售完成。
+- 库存是否预留、何时预留/释放；无货、可用量不足、多个订单同时申请同一批货时的用户结果。
+- 订单审核、收发货计划、实际收发货各自时点；入出库单生成是否需要人工确认。
+- 部分到货、少货、多货、错货、不良品、剩余取消；历史手工入出库单是否与新单关联，防止重复处理。
+- 客户退货与供应商退货分别关联哪笔原收发货，数量上限和质检/可用状态，是否补发补采。
+- 退货对库存、订单进度和结算的影响分别说明；不要默认退货自动恢复订单未交数量。
+- 合同、付款、收款、发票、物流和财务是否在本期；不因系统叫 ERP 自动纳入全部范围。
+
+## 验收与评审
+
+用“验收场景 / 前置条件与操作 / 预期结果”组织验收，按业务名称或章节关联功能，不默认使用技术式编号，不用“正常”“准确”“友好”代替具体结果。
+
+按风险覆盖主流程、权限拒绝、字段边界、退回修改、取消、部分完成、重复处理、关联失败和存量衔接；不适用的项说明原因即可。
+
+若产品采纳条件附件、多组明细或唯一码规则，对应增加门槛下/等于/超过、明细增删后重新判断、缺失/重复唯一码等验收场景。测试数据来自已确认规则，不能靠测试样例暗定未知规则。
+
+性能、容量、文件上限等指标来源必须可追溯。业务未提出数值时，问可接受的等待时间或使用规模，或列为待确认；不自行写 2 秒、50 并发等数字。
+
+交付前核对：业务词汇一致、角色与动作相容、关键规则有验收场景，图与正文同义；待确认项未被写成定论，已确认内容不再被列为待定。产品评审通过与实际开发测试通过分开记录。