docs: simplify ERP requirements design skill

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

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