ERP for FDE（FDE 的企业资源计划系统入门）

知识库位置：FDE Knowledge Base/03 Engineering/Enterprise Integration/ERP/ERP-for-FDE.md 定位：Enterprise Field Primer（企业环境入门页）术语不确定时，请查阅 Glossary（中英文术语表）。

1. What It Is（它是什么）

ERP，全称 Enterprise Resource Planning（企业资源计划）。

它通常是企业核心业务数据和交易流程的重要系统之一。

常见覆盖：

Finance（财务）
Procurement（采购）
Inventory（库存）
Orders（订单）
Manufacturing（制造）
Supply Chain（供应链）
Master Data（主数据）

不同企业的 ERP 范围差异可能非常大。

2. Why FDE Cares（FDE 为什么关心）

很多 FDE 项目最终都需要读取或写入 ERP。

例如：

Invoice Automation（发票自动化）
Procurement Assistant（采购助手）
Inventory Intelligence（库存智能）
Customer 360（客户 360 视图）
Manufacturing Integration（制造集成）
Finance Operations（财务运营）
Order Status（订单状态）
Approval Workflow（审批工作流）

因此 FDE 不需要成为 ERP 实施专家，但必须知道：

ERP 往往不是“普通数据库”，而是承载业务规则、权限和交易一致性的核心系统。

3. Core Mental Model（核心心智模型）

可以简单理解：

Business Transaction（业务交易）
↓
ERP Business Logic（ERP 业务逻辑）
↓
ERP Record（ERP 记录）
↓
Accounting / Inventory / Procurement Impact（财务/库存/采购影响）

例如采购：

Purchase Request（采购申请）
↓
Purchase Order（采购订单）
↓
Goods Receipt（收货单）
↓
Invoice（发票）
↓
Payment（付款）

这些对象之间通常存在严格业务关系。

4. ERP Is Often a System of Record（ERP 常是权威记录系统）

FDE 进入项目后必须确认：

哪个系统才是 Source of Truth（唯一事实来源）？

例如：

Customer name（客户名称）
→ CRM?

Invoice（发票）
→ ERP?

Inventory（库存）
→ ERP or WMS（仓库管理系统）?

Production order（生产工单）
→ ERP or MES（制造执行系统）?

不要默认 ERP 对所有字段都是 Source of Truth。

5. Common ERP Data Domains（常见 ERP 数据域）

FDE 经常遇到：

Master Data（主数据）

例如：

Customer（客户）
Vendor（供应商）
Product（产品）
Material（物料）
Cost Center（成本中心）
Account（会计科目）

Transaction Data（交易数据）

例如：

Purchase Order（采购订单）
Sales Order（销售订单）
Invoice（发票）
Payment（付款）
Goods Receipt（收货单）

Reference Data（参考数据）

例如：

Currency（币种）
Country（国家）
Tax Code（税码）
Payment Terms（付款条款）

6. ERP Integration Methods（ERP 集成方式）

客户环境中常见：

REST / SOAP API（REST/SOAP 接口）
Vendor-specific APIs（厂商专用接口）
File Exchange（文件交换）
Batch Export（批量导出）
Database Views（数据库视图）
Event / Message（事件/消息）
Middleware（中间件）

Legacy ERP（遗留 ERP）甚至可能主要依赖：

CSV（逗号分隔文件）
SFTP（安全文件传输协议）
Scheduled Batch（定时批处理）

7. Read vs Write Is a Major Boundary（读与写是重大边界）

读取 ERP 数据和修改 ERP 数据风险差异很大。

例如：

Read invoice status（读取发票状态）

风险通常相对较低。

但：

Create payment（创建付款）
Change vendor bank account（修改供应商银行账户）
Post journal entry（过账日记账分录）

可能属于高风险动作。

因此：

ERP Read（读）
≠
ERP Write（写）

FDE 在设计 Tool Calling（工具调用）时必须明确区分。

8. Transaction Boundaries（事务边界）

ERP 写操作常有严格业务规则。

例如创建 Invoice（发票）可能要求：

vendor exists（供应商存在）
purchase order valid（采购订单有效）
amount consistent（金额一致）
currency valid（币种有效）
accounting period open（会计期间开放）

因此不要：

LLM（大语言模型）
→ Direct DB Update（直接改数据库）

绕过 ERP application layer（应用层）。

优先：

Application（应用）
→ Approved ERP API（经批准的 ERP 接口）
→ ERP Business Rules（ERP 业务规则）

9. ERP Customization（ERP 定制化）

真实企业 ERP 往往高度定制。

客户可能有：

custom fields（自定义字段）
custom workflows（自定义工作流）
custom modules（自定义模块）
custom approval rules（自定义审批规则）
local extensions（本地扩展）

所以即使两家公司使用同一 ERP 产品：

集成行为也可能完全不同。

10. ERP Questions FDE Should Ask（FDE 应问的 ERP 问题）

Business（业务）

哪个业务流程涉及 ERP？
哪个 ERP object（对象）是核心对象？
谁是 Process Owner（流程责任人）？

Data（数据）

哪个字段是 Source of Truth（唯一事实来源）？
是否有自定义字段？
数据多久更新？

Integration（集成）

官方 API 是否可用？
Sandbox（沙箱环境）是否存在？
Rate limit（速率限制）？
Batch（批量）还是 real-time（实时）？

Security（安全）

使用 User identity（用户身份）还是 Service account（服务账号）？
Read / write（读/写）权限如何分离？
哪些动作需要审批？

11. Typical FDE Scenario（典型 FDE 场景）

客户说：

我们要让 Agent（智能体）自动处理 Invoice。

FDE 不应该直接设计：

Invoice PDF（发票 PDF）
↓
LLM（大语言模型）
↓
ERP

而应拆成：

Invoice（发票）
↓
Document Extraction（文档抽取）
↓
Schema Validation（结构校验）
↓
Vendor Lookup（供应商查找）
↓
PO Lookup（采购订单查找）
↓
Business Rules（业务规则）
↓
Human Review if Needed（必要时人工复核）
↓
ERP API（ERP 接口）
↓
Audit（审计）

12. Common Failure Modes（常见失败模式）

Failure 1 — Treat ERP as Generic Database（把 ERP 当普通数据库）

直接写数据库，绕过业务逻辑。

Failure 2 — Wrong Source of Truth（事实来源搞错）

例如 Customer 数据实际上 CRM 才是主要 Owner（所有者）。

Failure 3 — Ignore Customization（忽略定制化）

Sandbox 与 Production schema（生产结构）不一致。

Failure 4 — Service Account Too Powerful（服务账号权限过大）

一个 Integration Account（集成账号）拥有过宽写权限。

Failure 5 — No Idempotency（无幂等性）

重复请求创建两次交易。

13. Troubleshooting Signals（排障信号）

ERP Integration（集成）出问题时检查：

Object ID（对象编号）
Environment（环境）
User / Service Account（用户/服务账号）
Business Validation（业务校验）
Custom Field（自定义字段）
API Version（接口版本）
Transaction State（事务状态）
Duplicate Request（重复请求）

14. How Deep Should an FDE Go?（FDE 应掌握到多深？）

目标：

Level A/B — Recognize + Operate（A 级认知 + B 级操作）

FDE 应能：

理解 ERP 在业务中的角色
找到 Source of Truth
理解主要业务对象
设计安全读写集成
与 ERP Specialist（ERP 专家）对话

不要求：

独立完成大型 ERP 实施或财务配置。