From 8705381e914ccf96f1036d46c60ed5ab9b7a27f8 Mon Sep 17 00:00:00 2001 From: wenhuadian Date: Tue, 27 Oct 2026 19:29:36 +0800 Subject: [PATCH] feat: add ERP requirements design skill --- README.md | 13 +- skills/erp-requirements-design/SKILL.md | 107 +++++++++++ .../agents/openai.yaml | 4 + .../assets/product-requirements-template.md | 172 ++++++++++++++++++ .../references/business-checklist.md | 104 +++++++++++ .../references/delivery.md | 48 +++++ .../references/erp-site-observations.md | 104 +++++++++++ .../references/open-source-notes.md | 25 +++ .../references/prd-style.md | 76 ++++++++ .../references/procurement-example.md | 71 ++++++++ .../references/project-context.md | 53 ++++++ 11 files changed, 775 insertions(+), 2 deletions(-) create mode 100644 skills/erp-requirements-design/SKILL.md create mode 100644 skills/erp-requirements-design/agents/openai.yaml create mode 100644 skills/erp-requirements-design/assets/product-requirements-template.md create mode 100644 skills/erp-requirements-design/references/business-checklist.md create mode 100644 skills/erp-requirements-design/references/delivery.md create mode 100644 skills/erp-requirements-design/references/erp-site-observations.md create mode 100644 skills/erp-requirements-design/references/open-source-notes.md create mode 100644 skills/erp-requirements-design/references/prd-style.md create mode 100644 skills/erp-requirements-design/references/procurement-example.md create mode 100644 skills/erp-requirements-design/references/project-context.md diff --git a/README.md b/README.md index 18b8587..ed510f6 100644 --- a/README.md +++ b/README.md @@ -15,6 +15,7 @@ | 名称 | 用途 | 额外依赖 | | --- | --- | --- | | [xas-skill-review](skills/xas-skill-review/SKILL.md) | 检查待共享技能的元数据、引用文件、路径可移植性和依赖说明，给出位置、证据与修改建议 | 无 | +| [erp-requirements-design](skills/erp-requirements-design/SKILL.md) | 将 ERP 业务诉求整理为产品需求文档，覆盖流程、页面、字段、权限、状态和验收，默认交付 Word 与 Markdown | Markdown 无额外依赖；Word 需文档生成与渲染工具，现有页面核对需已授权的浏览器环境；详见技能入口 | `skills/` 只包含正式技能；`templates/` 用于创建新技能，不会出现在安装清单中。 @@ -35,10 +36,18 @@ cd xas-skills .\skills install xas-skill-review ``` -以后有多个正式技能时，将名称用空格分隔；下面的名称只是示例，需要替换为清单中真实存在的名称： +安装 ERP 产品需求设计技能： ```powershell -.\skills install skill-one skill-two +.\skills install erp-requirements-design +``` + +调用时说明业务项目或资料位置，例如：`使用 $erp-requirements-design，根据当前业务项目中的材料编写供应商准入产品需求文档。` 原始业务资料不随技能分发；Word 生成与页面观察工具按技能入口的依赖说明准备。 + +同时安装多个正式技能时，将名称用空格分隔： + +```powershell +.\skills install xas-skill-review erp-requirements-design ``` 安装全部正式技能： diff --git a/skills/erp-requirements-design/SKILL.md b/skills/erp-requirements-design/SKILL.md new file mode 100644 index 0000000..0bb409d --- /dev/null +++ b/skills/erp-requirements-design/SKILL.md @@ -0,0 +1,107 @@ +--- +name: erp-requirements-design +description: Use when a user describes a new ERP business process or requests a product-side requirements document, PRD, module onboarding specification, or revision to an existing ERP requirement. 适用于新爱算 ERP 新业务接入和存量模块需求迭代；不用于技术设计、编码或上线验收报告。 +--- + +# ERP 产品需求设计 + +将业务诉求整理为供业务评审、开发设计和测试使用的产品需求文档。默认中文，交付同版本 Word 与 Markdown。以正式、具体的业务表述说明角色、入口、条件、操作及结果，技术方案由开发另行设计。 + +## 工作边界 + +- 输出业务流程、页面行为、字段、权限、状态、模块衔接及验收要求，不默认输出数据库、SQL、接口报文、类名、技术选型或编码任务。 +- 网站观察默认只读，不提交单据、执行审批、调整权限或发送通知。凭据按当前授权使用，不进入文档。 +- 产品建议、已确认需求、已实现能力和验收通过分别表述。文档成稿不等于业务定稿或获准上线。 + +## 开始时 + +1. 确认业务项目根目录、适用指令和当前维护文件。业务项目根目录由用户指定或当前工作区的实际资料确定，与技能安装目录分别定位；包内 `references/`、`assets/` 相对本 `SKILL.md` 解析，业务产物放对应模块目录，不写入技能包。 +2. 处理新爱算 ERP 时读取 [项目资料索引](references/project-context.md)，从已确认的业务项目根目录按需定位原始材料；涉及现有页面时按主题参考 [页面观察记录](references/erp-site-observations.md)。原始材料不随技能分发，缺失时说明未核实并继续独立的需求工作；其他 ERP 使用其自身资料。历史记录只代表其日期和观察范围，不替代本轮验证。 +3. 梳理业务目标、角色、主流程、完成标准、范围及现有模块关系；用户已说明或资料已回答的事项不重复提问。 +4. 创建或整体修订文档时，使用 [结构与表达规范](references/prd-style.md) 和 [产品需求模板](assets/product-requirements-template.md)。局部修订只读取和修改受影响内容，不机械重写全文。 + +## 使用条件与外部依赖 + +本包提供需求设计流程、参考和模板，不包含一键生成程序；由支持 Skills 的助手结合用户输入执行。安装本包不会自动安装下列工具或复制业务原始资料。 + +| 任务 | 所需能力及准备方式 | +|---|---| +| 编写 Markdown 需求稿 | 文件读写能力及用户业务输入；无额外脚本运行时依赖 | +| 默认交付 Word 与 Markdown | 在当前环境启用 `documents` 文档技能及其声明的生成、渲染依赖，按该技能发现工作区运行时；也可使用已有、获准的等效 DOCX 生成与渲染工具。参见 [交付要求](references/delivery.md) | +| 读取 Word、表格或 PDF 原始资料 | 按实际文件格式使用已配置的文档、表格或 PDF 读取工具；未能读取的内容保留未核实状态 | +| 核对 ERP 现有页面（按需） | 用户指定或已确认的目标环境、可用浏览器工具或连接器，以及正常授权的账号或登录会话；历史网址不代表本轮访问授权 | + +开始任务时按本次交付范围检查可用能力。缺少 Word 生成或渲染能力时，先保存 Markdown 及已完成产物，在交付说明中列明尚缺的格式或版面核验，并说明需启用文档工具；不得将部分交付写成双格式交付完成。用户只要求 Markdown 时按其要求交付。 + +## 文档默认形式 + +正文按以下顺序组织，按规模裁剪： + +1. **主标题 → 版本记录表**：表头为“版本、修订日期、修订内容”，每个版本一行；不在标题下重复副标题或“版本／编制日期／状态”说明行。 +2. **背景与目标 → 现状及预期效果 → 整体流程 → 详细需求 → 权限与状态规则 → 验收与上线要求 → 评审确认事项**。 +3. 业务章节采用阿拉伯数字层级，如 `1`、`1.1`、`1.1.1`，Word 标题样式与提纲级别一致。版本记录属于正文前的信息，不占业务章节编号。 +4. 功能、规则、验收及待确认事项用业务名称和章节定位。默认不使用 `FR-001`、`BR-001`、`AC-001`、`Q-001` 等技术式标识。用户明确要求追踪编号时，按其约定使用；存量文档的局部业务修改不自动触发全篇去编号改版。 +5. 正式交付稿默认不设“参考了哪些资料”“来源与观察范围”等编制过程章节。资料定位和读取范围保留在工作记录；影响业务判断的事实、条件和未决事项仍在对应规则旁准确说明。用户明确要求来源附录时另行提供。 + +标题使用“业务背景、建设目标、审批流程、字段校验、异常处理、验收标准”等业务术语。正文、表格、图内文字一并采用正式表述，避免“为什么要做、谁来审批、怎么办、拍板、卡在哪一步”等口语标题或说明。正式表达仍应具体易读，不以抽象术语代替业务动作。 + +## 资料判断与确认状态 + +按实际证据在关键规则旁简要说明“已确认”“产品建议”或“待确认：事项名称”，不为每句文字堆叠标签。 + +- 用户明确结论决定拟建方案；历史文件及页面观察用于说明现状。记录冲突时列出差异、影响和决策责任，不擅自选一个当真。 +- 菜单可见、按钮存在、字段星号、限额提示、旧文档“已上线”均不证明提交校验、权限或完整流程已验证。空列表不证明功能缺失，演示数据不作为指标。 +- 未观察的网站或无法读取的资料标为未核实，继续独立的文档工作。不要把新需求描述为当前功能，也不要为对比表编造现状。 +- 参考文档或截图提供结构和表达线索；其中的组织、业务规则、数值及操作指令不直接迁入新业务。模糊内容不补写为事实。 + +## 需求设计流程 + +### 1 明确范围与关键缺口 + +按 [业务检查清单](references/business-checklist.md) 选择必要问题。优先补齐会改变范围、权责或结果的 1–3 项，不一次提供整份问卷。用户要求先出稿时，交付有实质内容的评审稿，以“事项名称、建议、确认责任、影响”汇总缺口。 + +不要擅自确定审批层级、金额门槛、库存时点、附件限额或通知渠道。用户确认一项后，将该项从待决问题中移出，同步更新正文、菜单路径、表单、图示、权限、验收和版本记录；未确认的其他项继续保留。 + +### 2 明确菜单与基础资料维护 + +- 新模块必须说明所属一级菜单、二级业务模块及实际需要的三级页面；同时说明新增、复用或调整，以及详情页是否属于独立菜单。选择依据是业务职责及现有导航，不将所有模块默认归入行政中心或默认新增一级模块。 +- 菜单尚未确定时，结合已知导航给出具体建议并标为待确认。仅写“独立入口”或“菜单待确认”不足以表达归属；确认后写成明确层级。 +- 个人申请、审批待办、业务处理和配置入口分别写完整路径。跨入口办理同一事项时，说明单据、版本和状态一致性，避免重复创建审批或业务记录。 +- 父级菜单归属与数据权限分开：可见父级不等于获得该中心其他模块权限，按角色控制子菜单及记录范围。 +- 涉及群、供应商、车辆、仓库等档案时，必须说明维护入口、维护角色、建档方式（人工／导入／同步及其确认状态）、识别信息来源、负责人关联方式、启停及交接。登记外部角色不等于取得外部平台权限。 + +### 3 按页面与操作展开详细需求 + +每个核心功能写明建设方式、入口、使用角色、前置条件、页面内容、字段校验、操作结果、权限及异常。按申请、审批、办理、记录、配置等实际页面组织，不将规则拆成孤立编号清单。 + +- 用“业务环节、现状或管理诉求、预期效果”说明变化；另列新增、复用、调整和待核实能力。 +- 字段说明业务含义、来源、必填条件、编辑时点、选项或范围及错误反馈。多组明细、条件附件及数值边界按实际业务展开；未知上限保持待确认。 +- 保存草稿、提交、批准、生成后续任务、实际办理及结果登记分别定义责任人和完成标志。审批完成、业务完成、消息送达或已读不得混为同一结果。 +- 说明退回、撤回、取消、内容变更、人员交接、部分完成、失败及结果不明的处理；重复操作或迟到结果不得重复办理或恢复已结束事项。 +- 跨模块只写来源、触发条件、带入信息、目标结果、追溯入口及异常责任，以可观察业务要求表达，不指定技术机制。 + +### 4 配合流程图与业务示例 + +跨角色主流程用泳道图，判断分支或异常用流程图，复杂页面用低保真示意辅助。图文共同解释规则，数量按信息需要确定；简单局部修订不强制增加图。 + +Word 中嵌入可见图形，Markdown 保留可用图片引用或可渲染流程图；不把图源码当作 Word 图示。新增页面示意标注“拟建页面／非现有界面”，不能冒充实站截图。图中角色、入口、状态和条件与正文一致。 + +复杂规则可给具体业务示例，注明虚构数据，不能借示例确定未经确认的门槛或流程。数值及时间运算使用确定性代码核对。 + +### 5 评审与交付核对 + +按角色贯通入口、信息、操作和结果。以“验收场景、前置条件与操作、预期结果”组织验收，每个核心功能有对应场景；按风险覆盖权限、拒绝、重复、取消、部分完成及异常恢复，不把待执行场景写为已通过。 + +核对正文、图、字段、菜单、状态和验收口径一致；确认事项不再与待定表冲突。未定规则明确影响和责任人，不宣称可直接开发定稿。缺少资料附录不影响保留必要的业务限制及证据边界。 + +按 [文档交付要求](references/delivery.md) 同步生成 Word 和 Markdown，核对内容并渲染检查。局部删除或改写须在两种格式及相关图示中生效，后续生成不得恢复已删除内容。 + +## 按需参考 + +- [结构与表达规范](references/prd-style.md)：新建、整体重排、参照样例或正式化修订。 +- [业务检查清单](references/business-checklist.md)：按业务选取需要补齐的规则。 +- [采销需求片段](references/procurement-example.md)：分批履约、退货及数量口径的虚构示例。 +- [文档交付要求](references/delivery.md)：版本维护、双格式、排版及预览一致性。 +- [开源参考说明](references/open-source-notes.md)：仅在维护来源时使用，正常写 PRD 无须重新调研。 + +此包可由共享仓库安装到技能目录后通过 `$erp-requirements-design` 调用，也可直接读取实际位置的 `SKILL.md` 使用。安装位置不改变业务项目根目录或产物归属；技能调用不包含发送给开发、自动发布或创建 Git 历史的授权。 diff --git a/skills/erp-requirements-design/agents/openai.yaml b/skills/erp-requirements-design/agents/openai.yaml new file mode 100644 index 0000000..92f4680 --- /dev/null +++ b/skills/erp-requirements-design/agents/openai.yaml @@ -0,0 +1,4 @@ +interface: + display_name: "ERP 产品需求设计" + short_description: "将业务流程整理为面向开发评审的产品需求文档，交付 Word 与 Markdown" + default_prompt: "请使用 $erp-requirements-design，根据我描述的业务流程编写 ERP 产品需求文档，补齐关键业务问题并生成 Word 与 Markdown，技术方案由开发另行设计。" diff --git a/skills/erp-requirements-design/assets/product-requirements-template.md b/skills/erp-requirements-design/assets/product-requirements-template.md new file mode 100644 index 0000000..89e7da4 --- /dev/null +++ b/skills/erp-requirements-design/assets/product-requirements-template.md @@ -0,0 +1,172 @@ +# {{业务名称}}产品需求文档 + +**版本记录** + +| 版本 | 修订日期 | 修订内容 | +|---|---|---| +| {{实际版本}} | {{用户时区日期}} | {{本版本实际新增、调整和确认内容}} | + + + +## 1 背景与目标 + +### 1.1 业务背景 + +说明背景、问题及需求起点，区分已确认事实与尚未核实的现状。采用正式业务表述，不写编制过程。 + +### 1.2 建设目标 + +说明期望改变的结果及完成标准。未确认的量化指标不自行设定；需要说明待评审状态时放在必要的业务说明中，不在标题下重复设状态行。 + +### 1.3 需求范围 + +| 范围 | 本期要求 | +|---|---| +| 本期必备能力 | 根据实际业务填写 | +| 后续评估范围 | 仅列实际存在的后续需求 | +| 本期不纳入 | 明确容易混淆的边界 | + +说明已确认或建议的模块归属和关键依赖。未知决策以事项名称标明，纳入文末评审表。 + +## 2 现状及预期效果 + +| 业务环节 | 当前方式或已明确的管理诉求 | 本期预期效果 | +|---|---|---| + +现状未核实时采用管理诉求对照，不编造现行流程或已验证缺陷。 + +### 2.1 功能建设清单 + +| 功能 | 新增 复用 调整或待核实 | 本期变化 | +|---|---|---| + +用业务名称定位功能，不默认增加技术式编号。 + +## 3 整体流程 + +### 3.1 主流程 + +说明起点、角色、关键动作和完成标志。跨角色流程使用可见泳道图；判断分支标明条件，图后保留简短文字。建议规则与正文保持一致。 + +### 3.2 分支与业务示例 + +按实际风险说明退回、取消、部分完成及异常恢复。复杂规则可用示例表，注明虚构数据，不作为业务默认值。 + +| 场景 | 输入或操作 | 预期处理 | +|---|---|---| + +## 4 详细需求 + +### 4.1 菜单与页面入口 + +#### 4.1.1 菜单归属及层级 + +明确归属现有一级菜单还是新增一级模块，给出依据及确认状态。不得只写“独立入口”。 + +| 一级菜单 | 二级模块 | 三级菜单或页面 | 使用角色 | +|---|---|---|---| + +说明与既有功能的关系，分别标识详情页、申请类型及导航菜单；父级菜单可见不等于获得其余模块权限。 + +#### 4.1.2 跨模块入口衔接 + +分别写申请、审批待办、办理、查询及配置的完整路径。同一事项有多个入口时，说明单据、版本及状态一致性。 + +#### 4.1.3 页面功能与交互 + +| 页面 | 默认信息与筛选 | 主要操作及权限范围 | +|---|---|---| + +覆盖加载、空状态、失败、重试、结果不明、重复操作及筛选恢复；明确 PC 与移动端范围。 + +### 4.2 基础资料维护 + +适用于业务依赖档案或配置的情况；无独立维护需求时并入对应功能，不保留空节。 + +**建设方式**：新增、复用或调整；人工建档、导入或同步及其确认状态。 + +**入口与角色**：完整维护路径、维护权限及负责岗位。 + +| 资料字段 | 来源及关联方式 | 校验与维护规则 | +|---|---|---| + +明确识别信息、负责人及账号关联、启用条件、停用与交接、在途事项及历史记录影响。外部资格需单独核对，登记资料不自动授予外部权限。 + +### 4.3 核心业务页面 + +将本节替换为实际功能名，如“供应商准入申请”。其他核心页面依次续写，不照搬不存在的功能。 + +#### 4.3.1 页面与操作 + +说明建设方式、完整入口、使用角色及前置条件。复杂页面配拟建示意或已核实截图，注明其性质及适用范围。 + +| 操作 | 前置条件 | 处理结果及异常反馈 | +|---|---|---| + +#### 4.3.2 字段与校验 + +| 字段 | 来源与必填条件 | 编辑时点 格式范围及错误反馈 | +|---|---|---| + +说明条件必填、选项来源、附件权限和限额依据。多组明细、条件附件需明确逐组规则、增删影响、门槛边界及缺失反馈；未知数值列为具名待确认事项。 + +#### 4.3.3 变更与异常处理 + +说明提交后修改、重审、撤回、取消、人员变更、重复处理、部分完成及结果不明的条件和后续路径，仅保留适用分支。 + +### 4.4 现有模块衔接与通知 + +| 来源模块 | 触发条件及带入信息 | 目标结果 追溯入口及异常责任 | +|---|---|---| + +审批通过、产生后续任务、实际办理、消息送达和已读分别表达；重复或迟到结果不得重复办理或恢复已结束事项。 + +| 通知事件 | 接收角色与渠道 | 内容 时机及跳转入口 | +|---|---|---| + +说明提醒失败与业务失败的区别，以及重复提醒和人工恢复规则；不自行确定未确认的渠道或定时规则。 + +### 4.5 查询统计与操作记录 + +| 指标或记录 | 业务口径与时间 | 可见范围及缺失值处理 | +|---|---|---| + +明确操作记录、关联单号、办理人及时间、历史变更、纠错和保留期限。数值用确定性计算核对，不以零代替缺失，不指定日志框架或数据表。 + +## 5 权限与状态规则 + +### 5.1 角色权限 + +| 角色 | 可见范围 | 允许操作 | 权限限制 | +|---|---|---|---| + +覆盖菜单、操作、记录、字段及附件权限；说明本人审批、兼任角色、停用及交接，服务端及直接访问遵守相同边界。 + +### 5.2 状态与关键规则 + +采用状态图、简洁文字或必要的状态表，避免重复叙述。 + +| 当前状态 | 操作及角色 | 条件与下一状态 | 关联影响及恢复限制 | +|---|---|---|---| + +区分草稿、提交、审批、建单和实际办理的完成标志；有明细时说明总单汇总规则。金额、数量、时区及舍入按实际业务展开。 + +## 6 验收与上线要求 + +### 6.1 验收场景 + +| 验收场景 | 前置条件与操作 | 预期结果 | +|---|---|---| + +采用业务场景名称，覆盖核心功能和适用的权限、拒绝、边界、重复、取消、部分完成、异常恢复及跨入口一致性。此处为待执行标准，不填写“已通过”。 + +### 6.2 上线衔接 + +说明责任人、资料准备、外部权限核对、真实角色验收、存量与在途事项、切换及故障期间处理。产品评审、业务验收及部署结果分别记录。 + +## 7 评审确认事项 + +| 确认事项 | 建议方案及理由 | 确认责任及业务影响 | +|---|---|---| + +仅保留未决事项。已确认内容写回对应章节，同步菜单、图、字段、权限、验收和版本记录，不得一处已确认而另一处仍待定。 diff --git a/skills/erp-requirements-design/references/business-checklist.md b/skills/erp-requirements-design/references/business-checklist.md new file mode 100644 index 0000000..6041837 --- /dev/null +++ b/skills/erp-requirements-design/references/business-checklist.md @@ -0,0 +1,104 @@ +# 业务访谈与产品检查清单 + +按业务选择使用；这是分析辅助，不是一次性发给用户的问卷。流程已清楚时直接写稿，未知项放回受影响的需求处。 + +## 从一句话提炼可讨论的业务 + +优先明确业务背景、目标、使用角色、触发条件、完成标准和本期边界。用户提供流程时沿着“输入 → 处理 → 输出 → 下一位处理人”补齐断点，不先讨论技术。 + +例：“销售填单，采购处理，仓库收发货。”先区分现货销售与销售带动采购，问是否需要独立备货。不要直接假设每张销售单必然生成一张采购单。 + +每个重要缺口按业务名称记录：`确认事项 / 业务影响 / 可选方案或建议 / 决策角色 / 相关功能或章节 / 是否影响定稿`。建议不是默认批准；用户不回答时保留待确认。确认后同步正文、菜单、图示、权限、验收及版本表，不继续在待决表中保留该项。 + +## 角色与权限 + +- 业务操作者、审核人、管理人、只读查看人分别是谁；组织/岗位变化后如何交接未完成事项。 +- 能否看本人、本部门、负责范围或全部记录；能否查看金额、成本、利润、附件、导出结果。 +- 可见不等于可编辑，可编辑不等于可审批。本人能否审批本人单据、离职人员待办怎么处理，按需要确认。 +- 产品写可验证的权限结果，如“销售不能通过列表、详情、导出或直接访问查看其他销售的订单”；具体实现由开发设计。 + +## 流程与状态 + +- 起点、提交条件、接手角色、完成标准和最后一个业务动作。 +- 草稿、待处理、进行中、部分完成、完成、关闭等状态按实际需要采用，不强套统一名称。 +- 审批中允许改哪些内容；退回、驳回、撤回是否不同；修改后是否重审，原记录如何查看。 +- 一单多明细时，部分完成、部分退回、部分关闭如何显示总单状态和剩余工作。 +- 作废、删除、关闭、归档各自代表什么；发生后能否恢复、谁能看历史、关联单据怎么处理。 +- 超时、无人接单、人员停用、处理中断后的责任人和下一步入口。 +- 保存草稿、提交申请、提交业务单据、完成实际办理各自意味着什么；哪些字段允许草稿暂缺、提交前必须补全，用户从哪里继续未完成事项。 + +## 页面与字段 + +- 写清一级菜单、二级模块及实际需要的三级页面，区分导航菜单、详情页和申请类型；明确新增、复用或调整。不能仅写“独立入口”。 +- 未确定菜单时依据业务职责和现有导航提出具体建议，标明待确认。确认后给出完整路径；不因内部群管理属于行政中心而将其他模块一律归入行政中心。 +- 申请、审批、办理、查询和基础资料维护分别从哪里进入；多个入口如何关联同一单据、版本和状态；PC 与移动端分别覆盖哪些任务。 +- 父级菜单可见性不应扩大该中心其他功能的权限，子菜单、记录、字段及附件范围分别控制。 +- 基础档案的维护入口、维护角色、建档方式、标识来源、负责人及系统账号关联是否明确；变更、停用、交接与历史记录如何处理。外部角色登记不自动授予平台资格。 +- 接入已有页面时分别记录当前入口、页面标题和拟使用的产品名称。旧菜单规划与实站不一致、标签疑似复制错误时先列差异，不直接照搬。 +- 列表默认视图、筛选、排序、分页、关键列、进度、待办提示；筛选清空后应恢复什么。 +- 新建、编辑、详情、审批、处理、历史记录页之间的关系。 +- 字段含义、来源、选项、单位、是否必填、条件必填、带出/填写、编辑时点、合法范围及错误文案。 +- 查询无结果、无权限、加载失败、处理中、成功、结果不明分别怎么显示；重复点击后的业务结果。 +- 导入、导出、打印、附件只在本期需要时展开。说明导入预览、错误行、重复判断、部分成功是否允许和结果反馈，不设计文件服务实现。 +- 多组明细：每组对应什么对象，允许多少组，逐组必填与整单必填的区别，增删明细如何影响合计、附件和审批条件。 +- 条件附件：何种单价/总额/类型触发，等于门槛如何处理，每组还是整单上传，文件数量和大小、缺失提示、金额修改后是否重新判断。现有行政采购页面的门槛只是该流程的观察值，不自动套给采销。 +- 星号、限额提示、空列表和演示数据分别标注观察层级；没有实际操作验证时，不写成校验已通过或业务已完成。 + +## 审批与通知 + +- 哪些单据需要审批、触发条件、节点顺序、审批人来源、多人如何算通过、抄送与通知区别。 +- 无可用审批人时如何提示和处理；人员名单变更对在途单据是否生效。 +- 申请表预览的审批节点、通过方式和抄送信息如何展示；业务要求优先使用岗位/组的职责表述，当前测试账号姓名不作为长期审批规则。 +- 申请人在哪看进度，审批人在哪接待办，办理人从哪里接后续工作；“我发起的、我的待办、我的已办、抄送我的”和全局管理视角按业务分别说明，不仅列一个总菜单。 +- 审批通过后是否生成待办/业务单据，谁继续办理；审批通过不等于业务执行完毕。 +- 相同审批结果被重复处理时，业务单据和待办不应重复；联动失败时显示待处理/异常、由谁核对并恢复。这里只定义用户可观察的结果。 +- 通知渠道、触发事件、接收角色、简要内容、跳转目标、重复或失败时是否重发；不能把“已提交”写成“已通知到所有人”。 + +## 跨模块接入 + +每项联动写六件事：来源模块和单据、触发业务动作、带入的业务信息、目标单据或待办、双方可追溯入口、失败时的状态和责任人。 + +确定已有数据从哪里来、谁维护、修改是否影响历史记录；需要保留成交时名称/价格等历史信息时，用业务语义说明，不指定数据存储结构。 + +分清“计划生成入库单”“仓库确认收货”“库存已增加”三个结果。若上游可修改或取消，说明下游尚未办理、部分办理、全部办理三种情况下怎么办。 + +来源单号、目标单号、经办人、审批完成/建单/办理时间分别代表哪个阶段；关联信息为空时显示什么、是否仍允许继续、谁核对补齐。看见已完成状态但关联单号为空，只能记为该记录现象，不能推断关联不需要或功能必然异常。 + +## 数量与金额 + +只对涉及它们的业务展开： + +- 数量单位、可否小数、最小/最大值、换算、是否允许超量、数量分配到单据或明细的口径。 +- 币种、含税/未税、折扣、运费、税额、金额汇总与舍入位置；客户和供应商价格是否分别管理。 +- 已执行、已退、剩余、可用、占用等名称逐一定义，不能把净数量当累计履约数量。 +- 规则未确认时以具名待确认事项保留；不要把其他系统的税率、审批金额门槛、精度或负库存策略带入本项目。 +- 有示例时标注虚构测试数据，并使用明确公式复核结果；公式和示例必须同一口径。 + +## 采销业务追加检查 + +先确认业务模式：现货销售、以销定采、独立备货、代采中的哪些属于本期。 + +再按已选范围检查： + +- 销售与采购是否一对一、多对多；拆单、合单、分仓、分批及未分配数量。 +- 云库分类/品牌/系列/SKU、行政资产分类与实物唯一码分别是什么；新业务选择现有 SKU 还是允许自由填写，历史商品信息如何保留。 +- 有唯一码的商品是否逐件登记，码与数量怎样对应，重复、缺码、错码、换货怎么处理，退货如何核对原件；无唯一码商品按数量还是批次管理。页面有“是否有唯一码”并不证明这些环节已实现。 +- 库存出库现有“销售、寄出、借出”是否与本期场景相关；不同用途是否需要返回、结算或不同责任人，不把所有出库都当销售完成。 +- 库存是否预留、何时预留/释放；无货、可用量不足、多个订单同时申请同一批货时的用户结果。 +- 订单审核、收发货计划、实际收发货各自时点；入出库单生成是否需要人工确认。 +- 部分到货、少货、多货、错货、不良品、剩余取消；历史手工入出库单是否与新单关联，防止重复处理。 +- 客户退货与供应商退货分别关联哪笔原收发货，数量上限和质检/可用状态，是否补发补采。 +- 退货对库存、订单进度和结算的影响分别说明；不要默认退货自动恢复订单未交数量。 +- 合同、付款、收款、发票、物流和财务是否在本期；不因系统叫 ERP 自动纳入全部范围。 + +## 验收与评审 + +用“验收场景 / 前置条件与操作 / 预期结果”组织验收，按业务名称或章节关联功能，不默认使用技术式编号，不用“正常”“准确”“友好”代替具体结果。 + +按风险覆盖主流程、权限拒绝、字段边界、退回修改、取消、部分完成、重复处理、关联失败和存量衔接；不适用的项说明原因即可。 + +若产品采纳条件附件、多组明细或唯一码规则，对应增加门槛下/等于/超过、明细增删后重新判断、缺失/重复唯一码等验收场景。测试数据来自已确认规则，不能靠测试样例暗定未知规则。 + +性能、容量、文件上限等指标来源必须可追溯。业务未提出数值时，问可接受的等待时间或使用规模，或列为待确认；不自行写 2 秒、50 并发等数字。 + +交付前核对：业务词汇一致、角色与动作相容、关键规则有验收场景，图与正文同义；待确认项未被写成定论，已确认内容不再被列为待定。产品评审通过与实际开发测试通过分开记录。 diff --git a/skills/erp-requirements-design/references/delivery.md b/skills/erp-requirements-design/references/delivery.md new file mode 100644 index 0000000..9604f63 --- /dev/null +++ b/skills/erp-requirements-design/references/delivery.md @@ -0,0 +1,48 @@ +# Word 与 Markdown 交付要求 + +最终产物是业务 PRD，不是技术设计或验收报告。用户指定的格式、模板和位置优先。 + +## 文件与版本维护 + +1. 在对应业务目录保存同名 `.md` 和 `.docx`，默认文件名为 `业务名称产品需求文档-v0.1-YYYY-MM-DD`。日期用用户时区，版本取真实修订记录，不以“终稿”表示未确认稿件。 +2. 新建稿件采用“主标题 → 版本记录表 → 业务正文”。版本表为“版本、修订日期、修订内容”，每个版本一行，初稿不虚构上一版。标题下不再重复副标题或版本、日期、状态行。 +3. 持续编辑同一评审稿时保留维护入口。局部措辞、格式和删节一般更新当前版本并保留可恢复备份，不每次小改动都复制一套竞争版本。明确发布新基线、重要业务版本变化或用户要求留新版本时，按版本规则新建并指明最新文件。 +4. 同一版本更新该行修订摘要，不把每次对话视为新版本或生成多行同名版本；未确认决策保持待评审。 +5. Markdown 为维护源稿，Word 为排版版本。定点修改 Word 后同步源稿，核对章节、字段、权限、状态、图示和验收，避免两套内容分歧。 +6. 删除或改写须在两种格式及相关引用中生效。后续生成基于最新源稿，不恢复已删除的资料说明、旧标题或元数据。 + +## Word 与图表制作 + +- 优先使用当前可用的 `documents` 技能及其声明的生成、渲染依赖，按该技能发现工作区运行时；没有该技能时，可使用已有、获准的等效 DOCX 生成与渲染工具。安装本技能不会安装这些依赖，不临时安装未知来源程序，不将作者机器路径写入可复用生成逻辑。 +- 缺少生成或渲染能力时保留成果并说明限制，不以改扩展名代替 DOCX，不声称未执行的版面检查已通过。 +- 使用 Word 标题样式，业务章节按 `1`、`1.1`、`1.1.1` 编号并对应提纲级别；文首版本记录不占业务章号。 +- 中文字体和页码清晰，表格按内容设置列宽，允许换行并重复跨页表头；长段规则放正文。 +- Word 嵌入可见流程图、泳道图和页面示意，保留文字说明；Markdown 图片引用有效，需要维护时保留图源。 +- 示意与真实截图明确区分。图片段落不得因固定行高被裁切；检查图中文字、箭头、说明及页面位置。 +- 图示及例子的数量按解释需要确定，不强制每份 PRD 使用固定张数，不新增无依据的业务页面。 + +## 内容与版面核对 + +内容核对涵盖两种格式的版本表、标题层级、菜单路径、字段、规则、状态、未决事项和验收。交叉引用用名称或章节；用户明确要求编号时再核对编号集合。图中角色、条件及入口与正文一致。 + +重点检查： + +- 已确认菜单是否仍在待确认表内，图中是否存在旧路径。 +- 删除技术式编号后，功能和验收覆盖是否仍然保留。 +- 文首是否仍有重复副标题或版本日期状态行，版本表是否一版本一行。 +- 已删除资料说明或旧标题是否被旧脚本、模板及副本恢复。 +- 业务完成、人工登记及系统回执是否区分，虚构示例是否被误作证据。 + +版面核对需生成渲染页，检查字体、表格、图片、跨页表头、标题衔接、页码、空白与溢出。新文档及整体重排逐页检查；局部修改检查受影响页。文件能打开不等于版面已核验。 + +## 预览与保存内容不一致 + +用户反馈旧内容时，先读取实际保存的 Word 和 Markdown，核对路径、版本、修改时间及关键文字，按需核对当前预览文件。不能直接归咎于缓存，也不重复改写已经正确的内容。 + +保存内容正确时说明已核实的版本，提示刷新或重新打开。用户确认只是未刷新后停止排查，不清理应用缓存或修改无关设置。文件确实仍旧时，修改真实维护入口并重新核对。 + +## 交付说明 + +提供两个产物的可点击绝对路径，概括改动、关键未决事项及实际核对范围。小改动简短说明，不重复整份目录。文档确认、页面观察、业务验收和部署验证分开表达。 + +渲染图片、临时 PDF、备份及调试脚本留在独立工作目录。用户未要求时不追加 PDF、演示文稿、测试台账或技术设计。 diff --git a/skills/erp-requirements-design/references/erp-site-observations.md b/skills/erp-requirements-design/references/erp-site-observations.md new file mode 100644 index 0000000..b428fed --- /dev/null +++ b/skills/erp-requirements-design/references/erp-site-observations.md @@ -0,0 +1,104 @@ +# ERP 测试站产品页面观察 + +观察日期：2026-10-27，Asia/Shanghai。入口：`https://erp-test.it.aisuan.cn/pc/`。本记录为同日重试成功后的页面证据，供后续产品需求分析按主题读取；不代替未来复核或业务验收。 + +## 观察范围和证据强度 + +- 使用已有登录会话，未切换账户，未核对角色授权名称；观察仅代表该会话可见范围。没有访问生产环境或移动端。 +- 通过浏览器读取实际渲染页面的菜单、列表、表单和一条已入库采购详情。下列路径来自页面导航链接，是页面定位信息，不是要求开发采用的接口设计。 +- 打开过出库新增、行政采购申请、SKU 新增表单；在采购申请里展开一组空白明细以查看字段，随后关闭。没有保存草稿、提交申请、保存业务数据、上传文件、审批、刷新缓存或执行入出库。 +- “页面标必填”“页面提示上限”“筛选提供某状态”不代表已验证提交校验、状态迁移或数据一致性。没有完成端到端业务流程测试。 +- 记录只保留结构与业务语义，不复制人员名单、具体单号、金额、附件内容或其他测试业务数据。 + +## SITE-01 首页与菜单 + +入口：`/pc/`。 + +首页明确显示“当前页面为演示界面，数据仅供参考”。销售额、订单数、活动动态等不能用作真实业务指标、使用量或验收证据。 + +当前会话可见云库管理、行政中心、个人中心、运营中心、服务号管理、审批中心、人事中心、财务中心、生产管理、代采管理、库存管理、报价管理、企微客户群等一级入口。未见独立“采销管理”一级入口；不能据此判断全系统未实现、已停用或没有权限，原因待核实。 + +当前入口与本地《菜单调整方案》有差别：仍为“生产管理”，发起申请及个人审批相关入口仍在审批中心；行政资产仍位于“行政中心 → 资产管理”。新需求需分别写现状入口和拟调整入口，不将方案当已上线布局。 + +## SITE-02 库存入库单 + +入口：库存管理 → 入库单，`/pc/ERP/Inventory/InStockBill/List`。 + +- 列表标题为“ERP入库单列表”；状态筛选有全部、待入库、部分入库、入库完成、已作废。 +- 列有入库单号、入库类型、业务描述、入库信息、附加信息、备注、操作。 +- 本次列表显示无匹配记录，未查看入库详情或办理表单，不能证明实际分批入库流程已验证。 + +产品启示：入库可见状态已细分到部分完成和作废。新模块应明确明细与整单完成口径、剩余数量和作废影响；具体迁移条件仍需核实。 + +## SITE-03 库存出库单 + +入口：库存管理 → 出库单，`/pc/ERP/Inventory/OutStockBill/List`。 + +- 列表标题为“ERP出库单列表”，有“新增ERP出库单”按钮；类型选项为销售、寄出、借出，状态选项为已提交、已出库。 +- 列有出库单号、出库类型、业务描述、出库信息、附加信息、备注、提交出库、操作。本次列表为空，没有核对真实行上的办理动作。 +- 两个筛选标签分别显示“入库类型”“入库状态”，与当前出库页面不一致；这是页面文案差异，不能直接沿用为需求术语。 +- 新增弹窗在当前默认“销售”类型下，出库部门、出库类型、业务数据、销售人、出库日期、合同编号带必填标记；运单号、备注没有显示该标记。 +- “业务数据”和“销售人”各有选择入口；本次未打开选择器，业务数据来源及可选范围未核实。没有切换寄出/借出类型，不推断其他类型表单相同。 + +产品启示：出库用途不等于销售类型；新业务需说明何时选择销售、寄出或借出，以及是否有返还、结算或后续跟踪。现有出库状态与入库状态不对称，不能直接假设已支持相同的分批规则。 + +## SITE-04 行政采购列表与已入库详情 + +入口：行政中心 → 资产管理 → 采购管理，`/pc/Operation/AssetPurchase`。 + +- 页面标题是“采购申请列表”。可按采购单号/标题/申请人姓名、申请部门、状态、发起时间筛选；状态为待采购、已入库。 +- 列有采购单号、申请人、部门、明细数、数量、金额、状态、发起时间、操作。本次看到待采购行有“入库、详情”，已入库行有“详情”；未点击办理入库。 +- 一条已入库详情显示采购申请信息和明细两部分。头部包含期望交付、明细条数、合计数量/金额、单据状态、关联申请单、入库单号、入库经办人、入库时间、用途、审批完成时间、建单时间和审批意见等。 +- 明细列有物品名称、资产类型、分类、物品类型、品牌、型号、数量、单价、金额、是否含税、备注。 +- 所看记录为已入库，能看到入库经办人与时间，但关联申请单及入库单号显示“-”。这是单条测试记录现象，不能判定全系统关联缺失，也不能认为关联字段无需填写。 + +产品启示：审批完成、创建采购业务记录、实际入库是不同业务阶段。行政资产分类与商品云库的分类/SKU不要混同；展示关联信息缺失时，应明确用户如何追溯和由谁核对。 + +## SITE-05 审批入口与行政采购表单 + +入口：审批中心 → 发起申请，`/pc/Approval/Submit`。 + +审批中心菜单分为发起申请、我的待办、我的已办、抄送我的、我发起的、审批单管理、流程定义、通知发送记录、回调发送记录、分类配置、通知模板。菜单可见不代表本次验证了其查询、操作或管理权限。 + +发起页按人事、行政、财务分组。本次展开行政组，看见采购、发货、访客、合同审核、物品归还、物品借用、物资领用、用车、纸质盖章申请；只打开采购申请表单。 + +采购申请页面声明： + +| 层次 | 所见字段或交互 | 本轮证据边界 | +|---|---|---| +| 申请头 | 期望交付日期、申请事由标必填；事由显示 0/500 | 没有触发空值或超长提交校验 | +| 明细容器 | 采购明细标必填，已填组数按“当前数/20”显示，支持添加和删除组 | 仅展开一组空白明细，未测试数量上限 | +| 每组明细 | 物品名称、数量、单价、是否含税标必填；含税选项为是/否 | 数量精度、单价范围及提交校验未核实 | +| 购买链接 | 可填写，显示 0/2000 | 没有测试链接格式或长度限制 | +| 比价单 | 文案说明“单价超过 300 元须上传比价单” | 只确认页面提示；等于 300、修改价格后是否重校验等未验证 | +| 合同附件 | 盖章版采购或相关合同，提示上传相关文件 | 是否在所有场景强制必填未核实 | +| 两类附件 | 均提示单个文件不超过 50MB、最多 10 个 | 没有选择或上传文件，没有验证实际拦截 | +| 结尾动作 | 关闭、保存草稿、提交申请 | 只执行关闭，未验证草稿保存、必填差异及提交结果 | + +当前表单没有显示资产类型、资产分类或价格区间字段。它不同于历史交接中的价格区间描述，也不同于已入库详情中展示最终资产类型的阶段。 + +表单还展示审批流程预览，按界面顺序为：总经办终审（或签，一人同意）→ 行政部负责人审批（单人审批）→ 资金执行审批（或签，一人同意）→ 抄送。显示了当前配置的人员，本记录不保留姓名。节点排列及适用对象只代表这张表单的当前预览，未实际提交验证，不作为其他模块固定流程。 + +产品启示：描述申请人、审批人、后续办理人各自入口；区分审批与抄送；写明草稿和提交的字段要求、多组明细的规则、条件附件口径。300 元、20 组、50MB、10 个等不能默认带入商品采销或其他新业务。 + +## SITE-06 云库 SKU + +入口：云库管理 → SKU，`/pc/IT/SKU`。云库另有分类、品牌、系列入口。 + +- SKU 页有分类、品牌、系列三个选择控件；本次未切换筛选值，不宣称级联清空或其他联动已验证。 +- 列表展示图片、中文名称、英文名称、唯一码及操作，提供新增、修改、删除和刷新缓存入口；未执行保存、删除或刷新缓存。 +- 新增弹窗显示中文名称、英文名称、是否有唯一码（是/否）、图片选择等必填标记。本次未填写或上传。 +- 弹窗标题写“在【分类】下的【品牌】下的【系列】新增云库系列”，与“新增云库SKU”入口不一致；应记录标题差异，不将它当作实际新增对象发生改变的证据。 + +产品启示：SKU 表示商品规格，唯一码涉及单件实物身份。新业务应确认是否逐件管理、码与数量如何对应、退换货如何对应原件；当前开关不证明收发货及退货追踪已完整实现。 + +## 后续需求应保留的待核实项 + +- 独立采销模块的实际入口、可用角色及已有功能边界。 +- 入出库真实记录及分批、作废、重复办理的实际行为；新单据与现有手工单据的承接。 +- 出库“业务数据”选择来源、不同出库类型的字段差异及合同要求。 +- 行政采购表单提示的强制执行情况、已入库关联字段为空的原因。 +- 唯一码在入出库和退换货中的完整处理规则。 +- 跨角色权限、审批在途变化、通知与后续业务联动、移动端与生产环境。 + +写产品方案时可以针对上述缺口提出建议和 AC 草案，但需要标明来源与未决项，不能把本次只读观察写成“业务全流程测试通过”。 diff --git a/skills/erp-requirements-design/references/open-source-notes.md b/skills/erp-requirements-design/references/open-source-notes.md new file mode 100644 index 0000000..ee2691b --- /dev/null +++ b/skills/erp-requirements-design/references/open-source-notes.md @@ -0,0 +1,25 @@ +# 开源参考与适配范围 + +检索与原始文件核对日期：2026-10-27。链接指向上游分支，后续可能变化；这里记录本次查看到的内容，不代表未来版本承诺。本 skill 的中文产品流程与模板为面向本项目编写，未整包复制或安装第三方 skill，也不执行其脚本。 + +## 采用的方法参考 + +| 来源 | 本次核对许可 | 借鉴的通用方法 | 本项目的适配 | +|---|---|---|---| +| [Ralph PRD skill](https://github.com/snarktank/ralph/blob/main/skills/prd/SKILL.md) | [MIT](https://github.com/snarktank/ralph/blob/main/LICENSE) | 澄清关键缺口、需求可追溯、可验证验收、本期范围和非目标 | 面向业务用户提问；以业务名称和章节定位需求，增加字段、状态、权限、审批及衔接；不沿用其技术式编号、编码任务式故事和固定输出路径 | +| [GitHub Spec Kit specification template](https://github.com/github/spec-kit/blob/main/templates/spec-template.md) | [MIT](https://github.com/github/spec-kit/blob/main/LICENSE) | 按业务场景组织需求、明确未决问题、区分假设与可测结果 | 将这些方法组织为中文产品需求与评审流程，不引入分支创建、代码实施或技术方案流程 | + +以上均为方法借鉴及自主表述，没有复制上游模板正文或代码。若未来引入实质原文或脚本，应重新核对许可并保留相应版权和许可声明。 + +## 调研后未纳入的候选 + +[Product-Manager-Skills 的 prd-development](https://github.com/deanpeters/Product-Manager-Skills/blob/main/skills/prd-development/SKILL.md) 提供完整产品需求工作流，但本次核对的仓库 [LICENSE](https://github.com/deanpeters/Product-Manager-Skills/blob/main/LICENSE) 为 CC BY-NC-SA 4.0。本项目用于公司内部业务工作，因此未复制、改编或打包其中内容，也未将其作为运行依赖。这里只保留调研来源记录。 + +## 本项目独立补充 + +- 产品侧文档边界：说明业务行为和可观察结果，将技术设计交给开发。 +- 区分商品采销、行政采购、代采；关联 SKU、库存、审批、个人与管理入口。 +- 区分历史材料、本轮观察、用户确认、建议与待决问题。 +- Word 和 Markdown 双格式、业务名称及章节定位、文首版本表和内容一致性核对。 +- 正式 PRD 结构、阿拉伯数字提纲、可见流程图及拟建页面示意；明确菜单层级与基础档案维护入口。 +- 分批履约、退货数量口径与存量单据衔接的产品检查。 diff --git a/skills/erp-requirements-design/references/prd-style.md b/skills/erp-requirements-design/references/prd-style.md new file mode 100644 index 0000000..b80cdbe --- /dev/null +++ b/skills/erp-requirements-design/references/prd-style.md @@ -0,0 +1,76 @@ +# PRD 结构与表达规范 + +本规范适用于本技能生成的中文业务评审稿。用户提供模板或提出其他明确格式要求时优先；局部修订不自动扩大为整篇改版。 + +## 文档结构 + +从“主标题、版本记录表、业务正文”开始。版本记录位于最前，不在标题下重复副标题及版本、日期、状态说明行。版本表为“版本、修订日期、修订内容”，每个版本一行，版本及日期取真实记录。 + +| 章节 | 核心内容 | 适合的表达方式 | +|---|---|---| +| 背景与目标 | 背景、目标、本期边界及完成标准 | 简洁段落，必要时列范围表 | +| 现状及预期效果 | 业务环节的变化与预期改善 | 环节对照表、功能建设清单 | +| 整体流程 | 角色衔接及关键分支 | 泳道图或流程图及文字说明 | +| 详细需求 | 页面、字段、操作及异常 | 按页面展开，结合示意、字段及操作表 | +| 权限与状态规则 | 角色范围、状态及关键规则 | 权限矩阵、状态图或必要的状态表 | +| 验收与上线要求 | 完成标准、异常及切换验证 | 场景、前置条件与操作、预期结果 | +| 评审确认事项 | 未决事项、责任与影响 | 事项名称、建议方案、确认责任及影响 | + +现状尚未核实时采用“已明确的管理诉求”对照，不为填表编造现行流程。新增功能标明“本期新增”，未复核的既有能力写“拟复用，适配范围待核实”。 + +## 标题与正文 + +业务章节采用 `1`、`1.1`、`1.1.1`，不与中文序号混排，不为凑三级标题机械拆分。Word 使用对应标题样式和提纲级别，不只加粗普通段落。 + +| 口语表述 | 正式表述示例 | +|---|---| +| 为什么要做 | 业务背景、建设目标 | +| 这个功能要解决什么问题 | 项目概述、背景与目标 | +| 谁来审批 | 审批人员与节点配置 | +| 怎么填写、从哪里申请 | 表单字段与校验、申请入口与提交规则 | +| 出问题怎么办 | 异常处理、失败恢复 | +| 需要谁拍板 | 待确认事项、确认责任 | +| 看看有没有办完 | 办理状态、完成标准、验收要求 | + +正文及表格也使用正式而具体的表述，例如“审批通过后生成待办，由有权限的管理员领取；登记实际办理结果后记为已完成”。不要只替换标题而保留口语，也不要用空泛术语代替业务动作。 + +功能用业务名称，如“供应商准入申请”；验收用场景名称，如“审批人员失效”“取消与办理并发”。交叉定位使用名称或章节号，默认不引入技术式标识及编号追踪矩阵。 + +## 页面需求的写法 + +按“建设方式、入口与角色、页面内容、操作与结果、异常与权限”展开。例： + +**4.3 资格核对** + +建设方式：本期新增，审批结果拟复用审批中心。入口：采购中心下的业务模块，具体层级须根据该业务确认。使用角色：获授权的资格核对人员。 + +审批通过后形成核对待办。核对人员查看批准版本及允许访问的附件，登记核对结果；核对通过并执行启用后，供应商状态变为已启用。审批通过本身不构成启用完成。处理结果不明时先核实原记录，不重复创建供应商。 + +此例仅说明描述粒度，不是其他模块的默认菜单或确认规则。实际文档应将已确认入口写成完整路径，并补齐字段和异常要求。 + +## 图表与示例 + +- 跨角色主流程使用泳道图，判断节点标明条件和结果，动作与对应角色一致。 +- 新建页面用低保真示意展示信息分区、关键字段和按钮，标注“拟建页面／非现有界面”。正文保留字段和操作条件。 +- 现有截图注明环境、日期和观察范围；只参考表达风格时，不移用其中的业务规则、数据、人员或链接。 +- 状态或异常图承担必要解释，不重复制作同义图。保留文字流程，便于图片无法显示时理解。 +- 对比、字段、状态和验收等重复结构使用表格；长段规则使用正文，避免挤入窄列。设置合理列宽和跨页表头。 +- 示例注明虚构，覆盖关键判断；时间、金额、数量与正文一致，不以示例暗定限制。 + +## 评审稿与工作记录 + +交付稿围绕业务背景、目标、规则及待决事项，不默认附带“参考了哪些资料”、工具过程或“本轮未访问哪些页面”等编制过程章节。资料路径、读取时间和观察证据留在工作记录，按需可追溯。 + +仍须准确表达业务事实：拟建图标为示意，未确认权限和审批层级保留待定，未验证能力不写成已支持，验收条件不写成已通过。用户要求来源说明时另行添加，不能为精简隐瞒影响业务判断的限制。 + +## 菜单与档案检查 + +成稿前应能明确回答： + +1. 一级菜单、二级模块和三级页面分别是什么；哪些属于详情页或申请类型而非导航菜单。 +2. 申请、审批、办理和资料维护各从哪个完整路径进入；不同入口是否对应同一单据。 +3. 父级和子菜单可见性如何授予，是否会扩大其他功能或数据权限。 +4. 基础档案由谁建立、从哪里维护，人工录入、导入或同步的方式是否已确认。 +5. 识别信息、负责人和系统账号如何关联，变更、停用及历史记录如何处理。 + +内部群管理归属行政中心是该模块的已确认决策，不是其他业务的默认归属。未决菜单需给出有依据的建议及影响；确认后同步所有引用，移除相应的“归属待确认”表述。 diff --git a/skills/erp-requirements-design/references/procurement-example.md b/skills/erp-requirements-design/references/procurement-example.md new file mode 100644 index 0000000..a470f10 --- /dev/null +++ b/skills/erp-requirements-design/references/procurement-example.md @@ -0,0 +1,71 @@ +# 采销产品需求片段 + +下面是**虚构演示**，用来展示产品描述的粒度，不是公司当前规则、已确认需求或完整采销设计。不得把示例的数量和审批选择直接用于真实业务。 + +## 模拟输入 + +“销售建订单，主管审核后仓库可以分批发货。暂不做财务结算。已发货的部分不能删除，客户可以申请退货。” + +可直接记录的用户要求：销售建单、主管审核、分批发货、不含本期财务结算、保留已发货记录、支持客户退货。 + +先问影响最大的缺口： + +- 退货后的补发规则：客户退货确认后，原订单是否需要补发？这决定订单待交付数量是否恢复。 +- 审批后的业务衔接：主管审核通过时，是通知仓库准备，还是立即产生待发货单？这决定衔接时点，不能直接等同库存已减少。 +- 订单及字段权限：销售和仓库分别能看哪些订单，销售能否看成本？这决定记录和字段的可见范围。 + +用户未回答时，可以先写稿，但上述规则保持待确认。以下“分批发货方案”是产品建议。 + +## 分批发货 + +目的：仓库按实际发出的数量逐次登记，销售可查看每次发货记录及尚未交付数量。 + +操作者：仓库处理人员；数据范围需确认“订单及字段权限”。 + +入口建议：库存管理（一级）→ 销售出库（二级）→ 待发货（三级），由列表进入订单详情并选择本次发货明细。此为示例菜单，实际导航及模块归属需另行确认；订单详情不新增为独立菜单。 + +前置条件：订单审批已通过，且当前仍有待交付数量。待发货单生成时点需确认“审批后的业务衔接”。 + +| 业务字段 | 来源 | 规则与提示 | +|---|---|---| +| 商品 SKU | 从原订单带入 | 本次发货不允许换成其他商品 | +| 本次发货数量 | 仓库填写 | 产品建议为大于零且不超过该行剩余可发量；单位、小数规则另按实际商品确认 | +| 发货仓库 | 选择可操作仓库 | 可选范围及库存不足处理待业务确认 | +| 发货说明 | 仓库填写 | 是否必填及长度上限待确认，不随意指定数值 | + +处理结果：保存成功后形成一笔可查看的发货记录，销售可看到数量和办理人；订单显示部分完成或全部完成。实际库存变动应在业务确认的发货节点体现，具体节点和现有库存能力需核实。 + +异常反馈：重复点击或结果不明后再次办理，不应出现同一次发货被重复记账；页面应能查询本次是否已完成。数量超出剩余时提示“本次发货数量超过剩余可发数量”，不改变原记录。 + +## 未发生退货时的履约计算 + +产品建议：累计发货量按有效发货记录累计；剩余待交付量 = 原订单数量 − 累计有效发货量。已发货历史不得直接删除，纠正方式需业务确认。 + +仅演示“无退货、无作废、无改量”场景：订购 10 件，首次发出 4 件，再发出 3 件，累计发货 7 件，剩余 3 件。 + +若随后退回 2 件，可展示累计发货 7 件、累计退货 2 件、净交付 5 件；**剩余待交付量是否从 3 变为 5 取决于“退货后的补发规则”，不能用净交付量直接推定需要补发。** + +## 状态与验收 + +| 当前状态 | 动作 | 条件 | 建议结果 | +|---|---|---|---| +| 待交付 | 仓库确认首次发货 | 发货量大于零且小于待交付量 | 部分交付，可查看本次发货记录 | +| 部分交付 | 仓库确认后续发货 | 本次发货等于剩余量 | 全部交付，保留全部分批记录 | +| 部分交付 | 客户退货处理 | 需先明确退货后的补发规则及退货确认流程 | 不提前规定原订单是否重新变为待交付 | + +| 验收场景 | 前置条件与操作 | 预期结果 | +|---|---|---| +| 分批发货与剩余量计算 | 无退货订单 10 件，仓库先发 4 件再发 3 件 | 两笔发货记录，累计 7 件，剩余 3 件，状态部分交付 | +| 超量提交 | 剩余 3 件时填写 4 件并提交 | 提示超量，订单和发货记录不变 | +| 重复发货操作 | 同一次发货操作重复提交 | 只有一次有效发货结果；用户可确认办理结果 | + +这三个场景是针对建议方案的验收草案，不是已执行测试结果。权限与退货验收须在“订单及字段权限”“退货后的补发规则”确认后补齐；分批发货需求不能据此直接宣布定稿。 + +## 结合现有页面时如何调整提问 + +真实页面证据单独见 [ERP 页面观察记录](erp-site-observations.md)，不要混入上面的虚构示例作为已确认规则。例如： + +- 现有出库筛选只显示“已提交、已出库”，入库则显示“部分入库”等状态。新业务需要分批发货时，应补问“每批对应独立出库单，还是一张单逐次办理；整单进度在哪里看”，而不是声称现有出库已支持部分完成。 +- 出库表单有“业务数据、销售人、合同编号”，应确认拟接入的销售订单如何供选择、合同是否是办理前提，不直接指定实现或认为旧表单完全满足需求。 +- 云库有“是否有唯一码”，应确认本次商品是否逐件登记、退货是否核对原件；不要自行把所有商品改成必须有码。 +- 行政采购表单的比价单门槛、附件限制和审批节点属于另一个业务。采销是否沿用需要单独确认。 diff --git a/skills/erp-requirements-design/references/project-context.md b/skills/erp-requirements-design/references/project-context.md new file mode 100644 index 0000000..82301d2 --- /dev/null +++ b/skills/erp-requirements-design/references/project-context.md @@ -0,0 +1,53 @@ +# 新爱算 ERP 资料索引 + +编制日期：2026-10-27。以下是新爱算 ERP 的需求调研入口与历史材料摘要，不是现网能力清单。表中路径相对用户指定或当前工作区确认的业务项目根目录，不相对技能安装目录；每次按业务读取原文，不把本文件当作实时事实。 + +这些 Word、表格及业务文档是外部输入，不随技能包分发，也不是安装前置条件。文件名或目录不同，先根据当前项目资料定位；找不到时记录未核实，继续依据用户输入与包内模板编写需求，不虚构已读取内容。只有缺失资料会改变关键范围、权责或结果时，再集中说明所需输入。其他 ERP 项目使用自己的材料，不继承本索引中的业务规则或历史结论。 + +同日第二轮已读取测试站实际页面，见 [ERP 页面观察记录](erp-site-observations.md)。该记录补充界面证据，不代表完成业务办理测试；下列原始文档仍保留各自历史日期。 + +## 来源与用途 + +| 相对路径 | 适合读取的内容 | 使用限制 | +|---|---|---| +| `ERP系统模块全景交接文档.md` | 模块归属、业务衔接、测试与生产环境区别 | 全文更新 2026-08-26，资产采购局部更新 2026-09-09；其他模块状态未同步刷新 | +| `业务系统上线进度表.xlsx` | 分期计划与上线推进口径 | 按记录日期读取，不把计划日期当实际完成日期 | +| `采销系统/note.docx` | 采销与库存的原始简要诉求 | 仅记载采购自动生成入库单、销售自动生成出库单；没有规定生成时点、执行时点或异常规则 | +| `审批系统/审批流程维护手册-行政版.md` | 审批分组、用户分组、名单与流程维护边界 | 手册中的当前/以后表述需分别识别；版本、生效范围和现状需要核对 | +| `审批系统/审批流程变更申请表(模板).xlsx` | 审批节点、表单字段与新流程信息的收集方式 | 模板用于补充业务输入，不代表已提交或已批准的流程 | +| `菜单权限/菜单调整方案.md` | 入口归属、个人入口与管理入口的规划 | 是调整方案，不能直接称为测试站当前菜单 | +| `设计需求系统/新爱算-设计需求ERP系统开发文档.docx` | 背景、角色、需求到工单、审核交付等写法 | 含未经本轮核实的技术选型和数值指标，不能照搬到新模块 | +| `运营中心-商机管理/客户线索管理模块-开发设计文档.md` | 复杂角色、分配粒度、状态和终态的业务线索 | 文内标题为客户商机管理；V1.3 日期 2026-09-01，技术设计不是新需求模板 | +| `运营中心-商机管理/商机管理系统业务测试与上线梳理.xlsx` | 测试场景、状态与权限设计、未决问题 | 2026-09-08 整理说明明确实际开发、部署和验收待证据确认 | +| `行政中心-资产管理/固定资产系统测试上线推进台账.xlsx` | 统一采购、入库分类和业务回归场景 | 读取到的记录更新至 2026-09-09，不推断本轮状态 | +| `行政中心-资产管理/采购领用审批流 20260912.xlsx` | 相关采购领用审批流程材料 | 使用时读取实际单元格内容和修订信息 | +| `访客管理制度/`、`用车管理系统/` | 管理制度、岗位流程和产品操作说明 | 仅在对应业务或有明确可复用规则时读取；本轮未全面核对这些目录内容 | + +## 需要优先检查的模块边界 + +以下来自交接文档，均属历史描述： + +- 云库：分类、品牌、系列、SKU，为报价、库存、采销提供商品基础信息。新模块应先确认能否沿用，避免另建同义商品库。 +- 库存：入库、出库、库存查询、流水、盘库。历史资料记载库管手工建入出库单，上游采购销售自动触发属于后续规划；不是已验证能力。 +- 采销：采购单、销售单及库存联动；完整业务需求待确认。不能从两句 note 推断先款后货、自动扣库存或一单只能一个仓库。 +- 行政资产：统一采购申请，行政在入库时区分资产类型；与商品采销采购、财务代采分别说明归属。 +- 审批：审批通过后联动业务。需要产品侧明确“通过后产生什么、重复到达/失败时用户看到什么”，技术机制由开发设计。 +- 消息：站内信、企业微信等能力可能被其他模块使用；新业务要明确是否通知、通知谁、何时通知、点开到哪里，而不是默认群发。 +- 权限：菜单组织、操作权限和数据可见范围是不同问题；员工自己的入口与管理人员全局入口要分别说明。 + +## 已发现的材料差异 + +1. 设计需求 Word 中写 MySQL、删除标记和软删除；商机技术文档写 PostgreSQL、物理删除与全量日志。两份材料不能共同证明全系统技术规范。产品需求只描述删除/作废后业务记录的可见性、追溯和恢复要求，技术方案交开发核实。 +2. 商机技术文档引用同目录《客户商机管理模块-需求文档.md》，本轮文件清单未见该文件；不能假称已与它核对。 +3. 商机技术文档中的部分状态代码片段与表格说明不一致，验收梳理也要求统一状态名称与编码。产品文档应给清晰的业务状态和迁移，不复制有冲突的枚举代码。 +4. 菜单调整方案含新建、迁移、重命名标记，只能用作规划线索。2026-10-27 页面仍可见“生产管理”“行政中心 → 资产管理”及“审批中心 → 发起申请”等原入口；并未完整呈现方案中的新布局。 +5. 2026-09-09 交接说明记载采购申请保留价格区间；2026-10-27 打开的行政采购明细显示“单价、是否含税、购买链接、比价单、盖章版采购或相关合同”，本次所见表单未显示价格区间。写新需求时注明日期和差异，不混合成同一版本字段。 + +## 网站观察边界 + +- 用户指定测试入口：`https://erp-test.it.aisuan.cn/pc/`。 +- 首轮观察：2026-10-27 浏览器绑定超时，随后电脑工具因无法可靠识别当前 URL 停止操作；首轮只识别到标签标题和地址，没有读取业务页面。 +- 同日第二轮：在用户要求重试后，成功使用既有登录会话读取 PC 首页、库存入出库列表、出库新增表单、行政采购列表和一条已入库详情、审批入口和采购申请表单、云库 SKU 列表及新增表单。具体证据和路径见页面观察记录。 +- 第二轮只做页面观察，新增表单均已关闭，未保存、提交、上传或审批。没有完成新单据的端到端办理、状态变迁、库存数量变化及跨角色权限验证。 +- 后续写需求时仍需按当次业务做相关只读复核；历史观察不能永久代表当前系统。当前会话未见独立“采销管理”一级菜单，原因尚未确认，不推断全系统缺失该模块。 +- 本文件不包含账号、密码或凭据值。需要登录时按既有授权和正常认证流程处理。