采购管理

01 概览

Foundation 状态：Draft。Authority：Draft。 PHITE Procurement 管理从已识别采购需求，经商业寻源与商业承诺，到供应/收货及供应商发票关系的受控业务链，并与 Engineering、Finance 和 Inventory 保持明确责任边界。

Engineering Requirement → Procurement Demand → Sourcing → Commercial Commitment
→ Supply / Receipt → Supplier Invoice → Finance: Payment / Inventory: Stock and Issue

本页描述已接受的持久业务语义，不声称当前 ERP 已完整实现这条链。

证据基础： 当前业务语义来自 HANYI-20 Owner Acceptance 与 merged AOS PR #5；Repository 和 live-system evidence 只证明各自限定范围内的实施或运行状态。

02 业务边界

Procurement 消费 Engineering 提供的需求与规格，管理采购需求、寻源、供应商商业交互、商业承诺及运营收货关系。Finance 负责付款、现金及正式会计政策；Inventory 负责库存、仓储与领用；Engineering 负责技术要求。Procurement 可以向相邻领域提供事件与证据，但不拥有这些领域的规则。

Project procurement 与 non-project procurement 均为一等业务场景。备件、办公、差旅、展会、服务、物流、代垫、特殊采购、固定资产与耗材只是代表性示例，不是冻结枚举；非项目需求不得被强制放入虚假 Project。

03 核心概念

• PR：采购需求或请购意图。PR 获批本身不形成供应商承诺；其最终 lifecycle、编号与变更模型仍待决。
• PL：存在于 PHITE 当前模型/历史中，但 canonical 定义与角色仍为 PROC-OD-001: OPEN；不得按行业惯例猜测其展开或含义。
• RFQ：向一个或多个供应商开展商业寻源/询价的活动。RFQ 不是 PO，报价也不是商业承诺。
• Supplier quotation / commercial comparison evidence：适用时应保留；是否成为独立 canonical object 及其 lifecycle 仍为 PROC-OD-003: OPEN。
• PO：面向供应商的主要商业承诺对象之一。PO 不是最终实际成本或付款，本页也不声称 PO 是 PHITE 唯一采购合同对象。
• PC：与商业承诺/合同侧有关，但 canonical 含义及其与 PO 的关系仍为 PROC-OD-002: OPEN。
• GR：适用时的货物或服务运营收货事件。PO 表示 committed，GR 表示 received；GR 不自动形成法定会计应计。
• PIV：当前模型中的供应商发票侧对象，与实物收货和付款不同。其 canonical expansion、税务语义、lifecycle 与会计过账行为尚未冻结。

04 核心对象

本 Foundation 关注两类知识：表示持续业务含义的对象（如 PR、RFQ、PO/PC、PIV），以及改变业务视图的事件（如商业承诺、GR、供应商发票关系）。对象名称存在不代表其全部定义、状态或实现已经确认。

任何页面、数据表或当前记录都不得反向冻结 PL、PC、PIV 的含义，也不得从 NocoBase collection、field、relation 或 UI 推导 durable business meaning。

05 生命周期与工作流

以下视图必须保持可区分：

视图	业务含义
Budget	计划或获授权的支出
Commitment	已形成的商业采购义务
Receipt	货物或服务的运营收货
Accrual	与收货或履约相关的管理/会计含义；正式映射取决于 Finance policy
Supplier Invoice	供应商发票或应付申请视图
Payment	由 Finance/Treasury 语义治理的实际现金流事件
Inventory Consumption	库存物料向 Project 或 cost object 的领用

因此：Budget ≠ Commitment；Commitment ≠ Receipt；Receipt ≠ Invoice；Invoice ≠ Payment；Payment 也不自动定义 Cost。正式管理与会计映射仍为 PROC-OD-005: OPEN，PIV 不得被长期当作 final cost 的简写。

商业承诺可以包含与合同触发条件相关的多个付款阶段。Advance、Shipment、Arrival、Acceptance、Warranty 是代表性词汇，不是强制 enum 或必需的五阶段模型。

06 跨 Foundation 关系

PHITE 支持跨多个 requirement、多个 Project，或 Project 与非项目需求组合的集中寻源/采购。采购交易的商业聚合边界可以不同于 Project、requirement 或 cost-attribution 边界；因此一个 PO 或商业承诺不限于一个 Project。

STRONG INFERENCE（强推断，不是 canonical rule）： 归属应保留足够粒度，以区分采购行或需求在多个 Project 和/或 cost object 间的归属：

Purchase Line → Allocation → Project / Requirement / Cost Object

这不是冻结的 table、schema、object lifecycle 或 implementation；具体模型、粒度与 lifecycle 均为 PROC-OD-004: OPEN。

07 编号与编码

持久 Material Master 模型由以下语义组成：

Material / Item Identity + Classification + Type-aware Specification + Unit
+ Search / Matching Identity

Free-text description 不是 Material Identity。文本相似不能证明是同一受治理 identity；AI 可以提取属性、规范化文本和建议候选匹配，但不得静默合并受治理的 Material Master identity。

合法 Engineering demand 不得仅因尚无标准 material code 而被阻止。操作路径应为：需求描述与规格 → 搜索已有 governed item → 匹配则复用；不匹配则形成 candidate/new item → human governance。候选创建、匹配、合并、去重及晋升机制仍为 PROC-OD-006: OPEN。

STRONG INFERENCE： engineered procurement 需要随 item/material type 变化的结构化规格，以支持搜索、比较与采购；这不是冻结字段名或 database schema。

08 角色与职责

Engineering procurement 通常行项目密集且批量操作频繁。实际系统应优先支持多行录入、逐行追加、搜索/复用既有 item、复制既有 requisition、候选匹配、批量粘贴或 spreadsheet import、提交前复核，并减少上下文切换。

这是强 operating requirement，不是已批准的 page layout、按钮设计或 current capability 声明。

09 业务规则

适用 DEC-AGT-001：AI 可以提取、规范化、分类、匹配、比较、提出建议、标记异常与起草内容；不得自主批准、创建不受控商业承诺、修改受控金额、授权付款、删除历史或静默合并受治理的 master identity。

Supplier selection、commercial acceptance 与其他具有 authority 的动作，不会因为 AI 推荐而生效。PR approval、供应商选择、商业承诺、受控金额变更及付款相关商业决定的正式 authority matrix 仍为 PROC-OD-007: OPEN。

10 数据模型

本页确认业务语义，不确认当前 ERP 已具备完整端到端能力。NocoBase collection、field、relation、index、plugin version、ACL、workflow、page implementation 与 record count 都是易变 implementation state 或 evidence；需要能力判断时必须回到 live Source of Truth 验证。

当前 schema 或 UI 的存在不能证明流程已批准、权限有效、数据完整或业务已接受。

11 NocoBase 映射

• Engineering → Procurement：受控需求、description、specification 与必要 deliverable。
• Procurement → Finance：商业承诺、收货/履约与供应商发票关系所需证据；Finance 决定正式会计与付款语义。
• Procurement → Inventory：适用物料的 GR 交接；之后的 stock、warehouse 与 issue lifecycle 归 Inventory。
• Procurement ↔ Quality：inspection、condition、acceptance/release 与 supplier issue 的职责必须由对应领域治理；GR 不自动等于 Quality release。

相邻关系可以表达为 GR → Inventory → Inventory Issue → Project / Cost Object，但本页不定义 Inventory 的 canonical model。

12 UI / UX 原则

采购界面应让人看清需求来源、行项目与规格、寻源/报价证据、商业承诺、交付/收货，以及跨 Project 或 cost object 的归属；不得把整条链压缩成一个模糊 status。

界面不得暗示集中采购 header 必然属于单一 Project，也不得把 Draft/Open 业务规则伪装为已实施选择项。

13 AI 机会与边界

适合 AI 辅助的工作包括：需求与规格提取、existing item 候选匹配、报价差异比较、缺项检查、数量/归属异常提示、跨事件证据摘要与草稿生成。

AI 输出必须保留来源与不确定性，并交由具有相应 authority 的人处理。任何建议、测试成功或自动化执行都不是人类批准。

14 审计与可追溯

适用时，采购链应能够回答：需求从何而来、由谁在何时形成或变更、使用了哪个版本/证据、形成了什么商业承诺、收到什么、供应商发票关系是什么，以及其 Project/requirement/cost object/stock 归属。

可追溯性要求不等于本页批准了具体 relation、field、numbering 或 retention schema。

15 待决事项

以下事项全部保持 OPEN，不得由 Handbook、Agent 或 implementation evidence 补全：

ID	待决问题
PROC-OD-001	PL 的 canonical 定义与角色
PROC-OD-002	PC 的 canonical 定义及其与 PO 的关系
PROC-OD-003	Supplier quotation / commercial comparison 是否为 standalone canonical object 及其 lifecycle
PROC-OD-004	集中采购 allocation 的 object model、粒度与 lifecycle
PROC-OD-005	Budget / Commitment / Receipt-Accrual / Supplier Invoice / Payment / Inventory Consumption 的管理与正式会计映射
PROC-OD-006	Candidate item 的创建、匹配、合并、去重及晋升治理
PROC-OD-007	PR、供应商选择、商业承诺、受控金额与付款相关商业决定的 authority matrix

16 实施状态

Durable context：已接受。Handbook 表示：Draft。Current capability：未由本页验证。 HANYI-20 与 merged AOS PR #5 是本页业务语义的当前 accepted baseline；它优先于旧 Handbook 文本与 ERP implementation evidence。

本次更新不修改 ERP、NocoBase、schema、workflow 或 Context Pack，也不把 Draft Handbook 提升为 Frozen/Approved。

17 后续改进

阅读或设计采购能力时，先识别对象/事件及其 authority class，再检查是否涉及七项 Open Decisions。涉及易变能力时验证 live system；涉及新 durable meaning 时回到正式 Context/Decision 流程，不从当前实现倒推规则。

18 决策历史

• HANYI-20 / AOS PR #5：Owner-accepted Procurement 与 Material Master Context baseline，已于 2026-08-31 合并。
• DEC-AGT-001：Agent 不得自主批准、改变关键业务金额、删除历史或执行未授权生产迁移。
• PROC-OD-001–PROC-OD-007：截至本页复核日全部为 OPEN。

GBrain Strategic Memory 仅用于检索交付模式与 Authority Boundary 背景；本页的 PHITE Procurement 业务事实回溯到上述正式 Context 与 Decision sources。