在华为 MetaERP 语境下“采购模块本体论建模”不是画 ER 图而是把PTPProcure-to-Pay 采购到付款 做成一套机器可读的业务语义底座TBox本体层定义类、关系、公理规则相当于“业务宪法”ABox实例层具体 PO、供应商、发票数据由 MetaERP 同步进来不写进本体文件下面用一个“服务器采购 三单匹配”的完整例子走一遍。1. 先定顶层本体划分MetaERP PTP 风格PTP_Ontology ├─ MasterData 主数据Supplier / Material / Org / Project ├─ ProcurementDoc 采购单据PR / PO / GRN / SupplierInvoice ├─ FinancialDoc 财务单据AccountPayable / GRIR暂估 ├─ PaymentDoc 付款单据PaymentOrder └─ BusinessTransaction 事务动作ThreeWayMatch / PaymentClearing关键原则单据是类动作是事务类。比如“三单匹配”不是一张表是一个事务类实例。2. 定义核心类TBox 片段OWL 风格prefix erp: http://huawei.metaerp/ptp/v1# . prefix xsd: http://www.w3.org/2001/XMLSchema# . erp:Supplier a owl:Class ; rdfs:label 供应商zh . erp:Material a owl:Class ; rdfs:label 物料zh . erp:PurchaseRequest a owl:Class ; rdfs:subClassOf erp:ProcurementDoc ; rdfs:label 采购申请PRzh . erp:PurchaseOrder a owl:Class ; rdfs:subClassOf erp:ProcurementDoc ; rdfs:label 采购订单POzh . erp:POLine a owl:Class ; rdfs:label 采购订单行zh . erp:GoodsReceipt a owl:Class ; rdfs:subClassOf erp:ProcurementDoc ; rdfs:label 收货单GRNzh . erp:SupplierInvoice a owl:Class ; rdfs:subClassOf erp:ProcurementDoc ; rdfs:label 供应商发票zh . erp:AccountPayable a owl:Class ; rdfs:subClassOf erp:FinancialDoc ; rdfs:label 应付账款zh . erp:ThreeWayMatch a owl:Class ; rdfs:subClassOf erp:BusinessTransaction ; rdfs:label 三单匹配zh .3. 定义关系对象属性 数据属性对象属性类与类之间属性domain → range含义hasSupplierPO → SupplierPO 关联供应商derivedFromPO → PRPO 由哪张 PR 生成hasPOLinePO → POLine订单头含行refersMaterialPOLine → Material行对应物料receivesAgainstGRN → POLine收货对应订单行invoicesAgainstSupplierInvoice → PO发票挂账到 POmatchWithThreeWayMatch → (PO, GRN, Invoice)三单匹配绑定数据属性自身字段erp:poNo a owl:DatatypeProperty ; rdfs:domain erp:PurchaseOrder ; rdfs:range xsd:string . erp:orderQty a owl:DatatypeProperty ; rdfs:domain erp:POLine ; rdfs:range xsd:decimal . erp:unitPrice a owl:DatatypeProperty ; rdfs:domain erp:POLine ; rdfs:range xsd:decimal . erp:matchStatus a owl:DatatypeProperty ; rdfs:domain erp:ThreeWayMatch ; rdfs:range xsd:string . 供应商名称/税号不塞进 PO而是通过hasSupplier跳到 Supplier 对象读变更只改一处。4. 加业务公理这是本体区别于 ER 图的核心# 1) PO 必须挂一个已准入供应商 erp:PurchaseOrder owl:equivalentClass [ a owl:Restriction ; owl:onProperty erp:hasSupplier ; owl:minQualifiedCardinality 1^^xsd:nonNegativeInteger ; owl:onClass erp:ApprovedSupplier ] . # 2) 三单匹配要求同时关联 PO GRN Invoice erp:ThreeWayMatch rdfs:subClassOf [ owl:intersectionOf ( [ owl:onProperty erp:matchPO ; owl:someValuesFrom erp:PurchaseOrder ] [ owl:onProperty erp:matchGRN ; owl:someValuesFrom erp:GoodsReceipt ] [ owl:onProperty erp:matchInvoice ; owl:someValuesFrom erp:SupplierInvoice ] ) ] . # 3) 收货数量不得超过 PO 行数量 允差 # 用 SWRL 规则表达 # POLine(?l), hasOrderedQty(?l,?q1), hasReceivedQty(?l,?q2), greaterThan(?q2, add(?q1,0.03*?q1)) - reject(GRN)对应 MetaERP 里的业务约束就是未审批 PO 不允许发货超收 3% 自动拦截三单不匹配不允许生成 AP付款金额 ≤ AP 余额5. 具体实例示例ABox由系统同步业务场景研发部门申请 50 台鲲鹏服务器 → 采购部向“华鲲振宇”下 PO → 到货 50 台质检合格 → 收到专票 → 三单匹配 → 生成 AP → 付款核销# 主数据实例 :Sup_HKZY a erp:ApprovedSupplier ; erp:supplierCode S10086 ; erp:taxNo 91510100XXXX . :Mat_Kunpeng a erp:Material ; erp:materialCode MAT-SRV-2288 ; erp:materialName 鲲鹏服务器2288H . # PR :PR_20260901 a erp:PurchaseRequest ; erp:prNo PR20260901007 ; erp:requestOrg :Org_RDCenter . # PO :PO_20260915 a erp:PurchaseOrder ; erp:poNo PO20260915033 ; erp:hasSupplier :Sup_HKZY ; erp:derivedFrom :PR_20260901 ; erp:currency CNY . :PO_Line_1 a erp:POLine ; erp:belongsTo :PO_20260915 ; erp:refersMaterial :Mat_Kunpeng ; erp:orderQty 50 ; erp:unitPrice 38500.00 . # 收货 :GRN_0921 a erp:GoodsReceipt ; erp:receivesAgainst :PO_Line_1 ; erp:receivedQty 50 ; erp:qcResult PASS . # 发票 :INV_0925 a erp:SupplierInvoice ; erp:invoicesAgainst :PO_20260915 ; erp:invoiceAmount 1925000.00 ; erp:vatAmount 221681.42 . # 三单匹配事务 :Match_001 a erp:ThreeWayMatch ; erp:matchPO :PO_20260915 ; erp:matchGRN :GRN_0921 ; erp:matchInvoice :INV_0925 ; erp:matchStatus MATCHED . # 生成应付 :AP_001 a erp:AccountPayable ; erp:generatedBy :Match_001 ; erp:apAmount 2146681.42 .6. 用本体能做什么对比传统表模型诉求传统 SQL本体建模后查“某供应商所有未匹配发票”多表 join 状态位判断?inv erp:invoicesAgainst ?po . FILTER NOT EXISTS { ?m erp:matchInvoice ?inv }判断“战略供应商”代码写死字段StrategicSupplier ≡ Supplier and hasAnnualSpend ≥ 1e8自动推理改三单匹配规则改 Java 代码改 SWRL/SHACL 规则无需动 MetaERP 核心大模型问答“这批服务器为什么还没付款”拼不出链路沿 PO→GRN→Match→AP→Payment 图谱回溯可解释7. 落地到 MetaERP 的推荐步骤先抽 PTP 业务对象PR / PO(头-行-发运-分配) / GRN / Invoice / AP本体层只放类属性公理不放业务记录映射 MetaERP 物理对象PO_HEADERS_ALL →PurchaseOrderPO_LINES_ALL →POLineCDC 同步实例到图库知识图谱层规则层用 SHACL 做校验SWRL 做推理接盘古/元宝类模型做自然语言查询状态机独立建模PO 状态DRAFT→APPROVED→SENT→PARTIAL_RECEIPT→CLOSED作为本体数据属性事务事件不用 UPDATE 覆盖历史一句话记住本体建模 把“PO 是什么、跟谁有关、什么条件下能付款”写成机器可推理的语义规则MetaERP 负责跑流程和数据本体负责定义“业务说得对不对”。