本体Ontology建模在华为 MetaERP 语境里就是给 PTPProcure-to-Pay采购到付款里的应付子域建一套“机器可读的业务语义底座”不是画传统 ER 图而是定义类 / 属性 / 关系 / 公理规则让系统能推理“什么情况下允许生成应付、什么情况下禁止付款”。下面用“供应商送货→开票→三单匹配→应付入账→付款核销”一个完整例子讲透。一、应付模块本体的分层思路MetaERP 风格层作用应付模块举例主数据类 MasterData全局复用实体Supplier供应商、Material物料、CostCenter成本中心单据类 Document业务凭证名词PurchaseOrder、GoodsReceiptNote、SupplierInvoice、AccountPayable、PaymentOrder事务类 BusinessTransaction跨单据动作动词ThreeWayMatch三单匹配、SupplierPayment付款核销公理 Axiom业务强约束未匹配通过禁止生成应付、付款不能超应付余额 关键区别传统表设计存“字段”本体存“语义规则”比如“发票必须关联PO且匹配通过才能产生应付”是一条公理不是代码 if-else。二、定义应付域核心类ClassThing ├─ MasterData │ ├─ Supplier (供应商 S007) │ ├─ Material (物料 M1001) │ └─ CostCenter (成本中心 CC202) ├─ ProcurementDocument │ ├─ PurchaseOrder (PO1005) │ ├─ GoodsReceiptNote (GRN023) │ └─ SupplierInvoice (INV0098) ├─ FinancialDocument │ └─ AccountPayable (AP3076) ├─ PaymentDocument │ └─ PaymentOrder (PAY6012) └─ BusinessTransaction ├─ ThreeWayMatch (Match001) └─ SupplierPayment (PayTrans01)三、定义属性Property1对象属性实体间关系属性名域值域含义hasSupplier单据类SupplierPO/发票/付款单都挂同一供应商referencesPOSupplierInvoicePurchaseOrder发票引用采购单matchWithPOThreeWayMatchPurchaseOrder匹配绑定POmatchWithGRNThreeWayMatchGoodsReceiptNote匹配绑定收货单matchWithInvoiceThreeWayMatchSupplierInvoice匹配绑定发票produceAPThreeWayMatchAccountPayable匹配通过后产出应付sourceInvoiceAccountPayableSupplierInvoice应付来源发票clearAPSupplierPaymentAccountPayable付款核销应付usePaymentOrderSupplierPaymentPaymentOrder付款事务关联付款单2数据属性字段值SupplierInvoice : invoiceNo(xsd:string), invoiceDate(xsd:date), amount(xsd:decimal), currency(xsd:string) AccountPayable : remainAmount(xsd:decimal), status(未付|部分付|已清) ThreeWayMatch : matchStatus(通过|差异|异常)四、写公理这是本体建模的灵魂公理1三单匹配完整性ThreeWayMatch subClassOf (matchWithPO exactly 1 PurchaseOrder) and (matchWithGRN min 1 GoodsReceiptNote) and (matchWithInvoice exactly 1 SupplierInvoice)公理2只有匹配通过才允许生成应付ThreeWayMatch subClassOf (matchStatus value 通过) only (produceAP some AccountPayable)推理效果若Match001缺 GRN或匹配状态差异推理机直接禁止produceAP关系存在前端不能点“生成应付”。公理3付款只能核销“已匹配通过”的应付且不能超余额SupplierPayment subClassOf (clearAP only (AccountPayable and sourceInvoice some (matchStatus value 通过)))再加一条数值约束可用 SWRL 表达AccountPayable(?ap) ∧ hasRemain(?ap, ?r) ∧ SupplierPayment(?p) ∧ payAmount(?p, ?amt) ∧ swrlb:greaterThan(?amt, ?r) → IllegalOverPayment(?p)五、具体实例走一遍含三元组业务场景向供应商「华芯电子 S007」采购服务器 10 台PO1005 单价 5万收货 GRN023 实收 10 台供应商开票 INV0098 金额 50万含税系统做三单匹配后入应付到期付 50万。实例化三元组RDF 风格PO1005 rdf:type PurchaseOrder . PO1005 hasSupplier S007 . PO1005 totalAmount 500000^^xsd:decimal . GRN023 rdf:type GoodsReceiptNote . GRN023 referencesPO PO1005 . GRN023 receivedQty 10^^xsd:int . INV0098 rdf:type SupplierInvoice . INV0098 referencesPO PO1005 . INV0098 hasSupplier S007 . INV0098 amount 500000^^xsd:decimal . INV0098 matchStatus 通过 . Match001 rdf:type ThreeWayMatch . Match001 matchWithPO PO1005 . Match001 matchWithGRN GRN023 . Match001 matchWithInvoice INV0098 . Match001 matchStatus 通过 . Match001 produceAP AP3076 . AP3076 rdf:type AccountPayable . AP3076 sourceInvoice INV0098 . AP3076 remainAmount 500000^^xsd:decimal . AP3076 status 未付 . PAY6012 rdf:type PaymentOrder . PAY6012 hasSupplier S007 . PAY6012 amount 500000^^xsd:decimal . PayTrans01 rdf:type SupplierPayment . PayTrans01 usePaymentOrder PAY6012 . PayTrans01 clearAP AP3076 . # 推理后AP3076.remainAmount 0status - 已清反例看推理拦截假如GRN023只收了 8 台匹配状态差异Match002 matchStatus 差异 → 公理2触发 → 不允许 produceAP → 前端“生成应付”按钮置灰 → 若强行调接口本体校验抛 422六、和传统数据模型对照帮你落地时不跑偏传统 AP 表设计本体建模做法ap_invoice表加字段match_flagThreeWayMatch是独立事务类用关系绑定三张单据代码里写“if 匹配通过 then 入应付”写成 OWL 公理推理机统一兜底视图关联 PO/GR/INV对象属性matchWithPO/GRN/Invoice显式语义化付款超付靠后台校验脚本SWRL 规则 余额公理实时推理多系统叫法不一供应商/客商/乙方统一映射到Supplier类消除语义歧义七、在 MetaERP 里的落地建议先建 PTP 顶层本体应付模块挂在FinancialDocumentBusinessTransaction下别单独造孤岛。单据类实例动作事务类三单匹配、核销必须抽成事务类不要塞进发票表里。规则外置成本体公理三单匹配、暂挂、超付、税差分摊、PPV 都进公理层。知识图谱存实例PO1005 这种本体存模型大模型基于本体做问答/异常诊断。迁移老 EBS/Oracle 模型时发票头/分配行用part-of付款批用聚合而非组合。一句话总结应付模块本体建模 把“PO、收货、发票、应付、付款”定义成类把“谁关联谁”定义成对象属性把“三单通过才入应付、付款不超余额”写成公理再用具体业务单据灌成实例让推理机跑校验。