简介：一份Oracle EBS各模块流程图Word完整版，面向EBS实施顾问、财务/分销/制造模块关键用户及项目新人。内容按财务、分销、制造、其他系统四大模块系统梳理，逐一说明总账、应付、固定资产、应收、现金管理、项目会计、库存、采购、销售订单、销售市场、销售补偿、售后服务、销售分析、计划管理、能力计划、制造数据、车间生产、成本管理、项目制造、流程制造、质量管理，以及设备、人事、薪金、预警、商业智能等核心组件的职责与边界。同时覆盖设计到发布、预测到计划、采购到支付、订单到收款、库存到履约等主要业务流程，并配有Inventory、BOM、WIP、Planning、Cost Management、Purchasing、Order Entry、总账、应付、应收、固定资产等关键模块的流程图，直观展示数据流转与作业逻辑，有助于在方案设计时厘清模块间依赖关系。资源为单份DOC文档，包体1.15MB，可配合文字说明按图索骥，适用于方案沟通、模块接口设计或新员工培训。目前已有164人学习，是快速了解Oracle EBS整体架构的低成本入门资料。
1. 流程图比功能清单更值钱：EBS 的骨架是“事件-单据-分录”链路
EBS 有二十多个模块，互联网上功能清单一抓一大把，可真正上线时翻车的，几乎都不是某个功能不会用，而是单据跨模块走不通：销售订单确认了，库存没减；采购单接收了，应付没暂估；库存发料了，成本没归集。问题都出在“模块之间的那根线”上。这份资源把每个模块的核心流程图和端到端流程整理成一份完整文档，价值不在图多，而在它把“业务事件→单据流转→财务分录”这条三级链路画清楚了。看明白这条链路，你才算从“会用某个表单”进阶到“能看懂 EBS 为什么这么设计”。值得搞懂，因为几乎所有实施顾问的看家功夫，都是对着这种流程图练出来的。
2. 端到端业务流：Order to Cash 与 Procure to Pay 如何串起六个模块
EBS 的模块清单列出来有几十项，但真正让这些模块产生价值的，是两条最经典的闭环流程：采购到支付（Procure to Pay）和订单到收款（Order to Cash）。前者把采购、库存、应付、总账串成一条线，后者把销售、库存、应收、总账串成另一条线。资源里单独画的 Oracle Purchasing、Oracle Order Entry、Oracle Inventory、Oracle Payables、Oracle Receivables、Oracle General Ledger 这几张图，本质上都是这两条主链上的分段放大。先看主链，再看分段，才不会迷失在表单里。
2.1 订单到收款：一张销售订单如何变成总账贷方分录
订单到收款（O2C）的起点是 Oracle Order Entry 里录一张销售订单，终点是总账里多出一笔收入分录。中间隔着库存发运和应收开票，每一步都靠状态字段推动。
订单行录入后，系统先做可用量检查（ATP），判断库存能不能满足承诺交期。这一步在流程图里常常画成一个判断菱形，但底层是库存模块的现有量、在途量、保留量在算账。订单确认后，库存模块按发运指令做挑库和发运，产生物料事务处理，库存数量减少，同时产生发运成本。发运完成后，应收模块依据发运事务生成应收发票，确认收入和应收款。客户付款后做核销，最后过账到总账。整条链路里，订单行状态从 Entered 走到 Booked，再走到 Shipped、Invoiced，最后 Closed。每一个状态迁移都对应一次跨模块的数据写入。
想要验证一张订单当前走到哪一步，最直接的办法是顺着订单号把各模块的状态字段拼起来看。实际环境里可以跑这样一段追踪 SQL：
-- 以订单号为入口，串联订单、发运、应收、总账各环节状态 SELECT oha.order_number, ola.flow_status_code AS order_line_status, wd.wsh_delivery_status AS delivery_status, ctt.trx_number AS ar_invoice_number, gjh.je_header_id AS gl_je_header_id, gjh.je_batch_id AS gl_je_batch_id FROM oe_order_headers_all oha JOIN oe_order_lines_all ola ON oha.header_id = ola.header_id LEFT JOIN wsh_delivery_details wdd ON ola.line_id = wdd.source_line_id LEFT JOIN wsh_deliveries wd ON wdd.delivery_id = wd.delivery_id LEFT JOIN ra_customer_trx_all ctt ON ola.line_id = TO_NUMBER(ctt.interface_line_attribute1) LEFT JOIN ra_cust_trx_lines_all ctl ON ctt.customer_trx_id = ctl.customer_trx_id LEFT JOIN gl_je_lines gjl ON ctl.customer_trx_line_id = gjl.source_je_line_id LEFT JOIN gl_je_headers gjh ON gjl.je_header_id = gjh.je_header_id WHERE oha.order_number = '&订单号';这段 SQL 的关键在于每个 JOIN 都对应流程图里的一条跨模块箭头：发运明细表通过 source_line_id 回联订单行，应收发票通过接口属性带回订单行号，总账分录通过 source_je_line_id 回联应收行。任何一个 JOIN 查不出数据，就说明链路在那一环断了——要么没发运、要么没开票、要么没过账。这比在界面上逐个表单翻要快得多，也是流程图最实在的用法：把图上的箭头翻译成表之间的外键关系。
2.2 采购到支付：接收三步走与应付暂估的由来
采购到支付（P2P）的起点往往不是采购单，而是请购。计划模块跑出物料需求后自动生成请购单，采购模块把请购转成采购单，审批后发给供应商。供应商到货后，在库存模块做接收，这一步是整个流程的支点：接收动作同时影响库存数量、成本和应付暂估。
接收为什么这么关键？因为在 EBS 里，接收不是简单地点一下“收到”，而是要区分三种接收类型：接收（Receipt）、验收（Acceptance）、最终入库（Deliver）。流程图上通常把三步画成三个框，实际对应库存模块里三种不同的事务处理类型。第一次接收代表货物到达企业，数量计入在途；验收代表质量检查通过；最终入库代表货物进入可用库存。每一步都可能触发不同的会计科目。
接收产生的关键会计影响是应付暂估（Accrual）。货物到了但发票还没来，账上不能没有负债，所以系统按采购单价格生成一笔暂估应付：借库存或费用，贷应付暂估。等供应商发票录入并完成匹配后，再把暂估冲掉，转入正式应付账款。这一借一贷之间，就是流程图里“接收”和“匹配”两个框之间真正的业务含义。不看懂这一步，月结时存货与应付对不平都不知道去哪查。
把 P2P 和 O2C 放一起看，会发现两套流程的骨架完全对称，都是“业务事件在业务模块产生单据，单据在财务模块产生分录，分录过账到总账”。区别只在方向：一个是花钱，一个是收钱。所以很多实施团队会把这两条链画在同一张流程总图上，共用中间的主数据层和底部的总账层。
2.3 主数据在流程中的角色：校验是流程里隐形的岔路口
流程图画到最后，会发现真正决定流程走不走得通的，不是模块功能，而是主数据。一张销售订单能不能确认，要看客户是否有信用额度、物料是否允许销售、发运组织是否有效；一张采购单能不能审批，要看供应商地点是否有效、采购员是否有权限。这些校验在流程图里往往只被画成一个简单的判断框，但在系统里，每一次校验背后都是主数据的读取和比对。
这也是为什么资源里 Oracle ERP 模块清单里把 HR、System Admin 也列了进来。流程里每一笔业务都要知道“谁做的、属于哪个组织”，HR 提供职责和权限，System Admin 提供配置文件和控制选项。某公司实施时如果把主数据清洗放在上线前最后两周，流程图画得再漂亮也救不回来——主数据错了，流程图上每个箭头指向的表都会查出脏数据。
3. 制造三角底层联动：INV、BOM、WIP 与成本卷积谁是龙头
离散制造型企业在 EBS 里的核心是四个模块的配合：BOM 定义产品“由什么组成”，WIP 记录车间“正在做什么”，INV 记录库存“还剩什么”，CST 回答这一切“值多少钱”。资源里这几张流程图单独看都清楚，难的是理解它们之间的依赖顺序。计划模块 MPS/MRP 是发令枪，BOM 是配方，WIP 是执行现场，INV 是结果的落点，成本模块则是在整条链走完后做价值归集。
3.1 物料事务处理：库存变化的原子事件
库存模块里，任何数量或价值的变动都以“物料事务处理”为单位。发料是一次事务、完工入库是一次事务、采购接收是一次事务、销售发运也是一次事务。每个事务都带事务类型、来源类型、数量和关联会计科目。源文档 Oracle Inventory 那张图的核心，就是这张“事务类型-来源-科目”的对应关系。
事务处理记录表是制造数据查询时最重要的表之一，它保存了每一笔移动的来龙去脉。一次发料事务，来源类型指向工单；一次采购接收，来源类型指向采购单行；一次销售发运，来源指向发运行。这就像给库存的每一次呼吸都做了日志。做成本分析时，如果发现库存金额和总账对不上，第一件事就是查事务处理的关联科目字段是不是配错了——很多对账差异根本不是算错，而是事务挂错了科目。
3.2 BOM 展开与 WIP 完工：物料清单怎么算出来的
BOM 模块在流程里的角色是做“展开”。计划模块发出的计划单经过 BOM 展开，算出父项下的所有子项需求，再转成生产工单。这个过程在制造系统里叫“计划单到工单”的自动转单，资源里“Demand to Build”的流程图画的正是这一条线。
工单进入 WIP 后，按工艺路线进行工序流转。完工时，系统依据 BOM 和完工数量反算组件消耗，做完工入库事务。这里有一个常见误解：完工入库不是简单地把成品数量加进库存，它同时要做组件反冲（Backflush），扣减已耗用的子项库存。如果 BOM 配错了单位换算或者损耗率，完工入库后子项库存会出现负数——查到最后往往是流程图里“BOM 展开”这个框后漏了单位换算的校验。
3.3 成本卷积：WIP 完成后金额怎么爬上去
成本管理模块是制造流程的收口。标准成本法下，一个成品的成本不是等工单结束才算的，而是在 BOM 和工艺路线上逐层卷积出来的：材料成本来自子项价格，资源成本来自工时费率，制造成本来自工序和费率。Oracle Cost Management 那张图的精髓，就是“成本卷积（Cost Rollup）”这条路径——从底层采购件开始，一层一层向上汇总。
做完成本更新后，工单完工时系统会按标准成本结转，实际成本与标准成本的差额单独记录为差异：采购价格差异、用量差异、效率差异，全部过账到总账。这也是为什么制造企业月结时总在强调“先关 WIP，再关成本，最后关总账”——顺序一乱，差异分录的日期和批次就会错位。资源里把 Cost 和 Quality 列为主要业务流程，质量模块在制造业里往往是在工序检验时产生质量事务，再反写回 WIP，这一步也是流程图里极易被忽略的分支。
4. 财务收敛机制：为什么所有子模块的终点都是总账
把 EBS 里二十多个模块按“数据流向”排一遍，会发现它们最终都指向同一个终点：总账。应收、应付、固定资产、现金、库存、成本、项目会计，各有各的明细账，但每一笔明细都要通过过账程序汇总到总账里。Oracle General Ledger 那张图看起来只是财务模块的其中一张，实际上它是整个 EBS 数据流的汇聚点。理解这张图，才能真正理解“为什么 ERP 是一套集成系统”。
4.1 子账到总账的映射：弹性域、账套与过账程序
总账里的一笔分录，不是业务人员手工敲进去的，而是子模块过账程序自动生成的。每个子模块先产生自己的会计条目，比如应收模块产生应收款分录、应付模块产生应付款分录、固定资产模块产生折旧分录，这些条目称为子账。过账程序读取子账里尚未过账的行，按科目弹性域和账套定义组合成完整的科目段，写入总账日记账批次。
常见的实现思路是：每个子模块的事件都对应一组科目规则，规则里写死科目段各段的值或取数来源。比如库存模块的采购接收事务，规则是“借：物料/费用科目，贷：应付暂估科目”；应收模块的发票事务，规则是“借：应收账款，贷：收入科目”。流程图里接收框和发票框下面的“生成会计科目”这个动作，实际就是这张规则表在起作用。
这里的难点在于科目弹性域的多段结构。总账科目不是一串简单的数字，而是由公司段、成本中心段、科目段、子段等多个段拼成的。子模块业务事件发生时只知道其中几个段的值，其余段要靠规则补充。所以核对子账与总账时，不要只看金额，要连科目段一起核对——很多差异是某个段取错了来源，导致分录进错了成本中心。
4.2 AR/AP/FA/CE 的过账时机与数据来源
四个主要子模块的过账时机各有讲究。应收模块在发票创建和收款核销时产生会计条目，应付模块在发票审批和付款时产生会计条目，固定资产模块在每个月运行折旧时产生折旧条目，现金管理模块在银行对账单匹配后产生条目。每个模块都有独立的“未过账分录表”，过账程序扫描这些表，按账套和期间进行汇总。
月结时最常见的对账动作，就是检查这些未过账表里是不是有残留。如果 AR 模块有一批发票因为没有完成过账而滞留在子账表里，总账里就少了对应的收入；AP 模块如果有发票还在“已批准未过账”状态，总账里的应付就少一笔。实施团队每月关账的第一道检查清单，永远是“各子模块未过账行 = 0”，这个动作在流程图里对应的就是每个子模块到总账之间的那根连线。
4.3 月结硬顺序：为什么关账先子账后总账
资源里 Oracle 整合企业日常作业流程这张图，把月结的顺序画得很清楚：库存先关账，然后成本模块关账，接着 AR/AP/FA/CE 关账，最后总账关账。这个顺序不是随便定的，而是因为后关的模块要从先关的模块取数。
假如总账先关了，成本模块后一批完工差异分录过进来，总账期间已经关闭，要么强行回开期间，要么把分录塞进下期——两种做法都会让总账与子账的余额对不上。所以 EBS 实施规范里有一条铁律：子账不过完账，总账不许关账。这个顺序在流程图上只是几个小字，实际操作中却是月结团队每个月的关键路径。任何一次月结拖延，十有八九是某个子模块的未过账数据卡住了整条链路。
5. 流程图学习与实施避坑：五个最常见的翻车现场
流程图画得漂亮，和上线后能跑通，是两回事。这些年看过不少项目，也踩过不少坑，EBS 流程图在学习和实施中最容易出问题的，集中在五个场景。每一条都是真实发生过的“血泪经验”。
5.1 流程边界画错：只到审批不落账
现象：顾问交付的流程图到“审批完成”就画上句号了，上线后第一个月月结，总账和子账怎么都对不平。
原因：审批完成只是单据状态变了，并没有产生任何会计条目。审批是管理动作，过账才是财务动作，两者在流程图里隔着一条“产生分录”的暗线。
解决：每一张流程图画完后，都要多问一句：这笔业务产生什么会计科目？由哪个模块生成分录？哪个过账程序把它送进总账？把这三个问题写进流程图说明里，比多画十条箭头都有用。
5.2 忽略多组织上下文
现象：一套 O2C 流程在 A 组织跑得通，复制到 B 组织就走不通，订单确认按钮点了没反应。
原因：EBS 有业务实体、库存组织、HR 组织等多层组织概念，流程图如果不标注组织维度，会出现“流程看起来一样、实际归属不同”的错位。B 组织的库存组织没挂在同一个业务实体下，可用量检查自然查不到库存。
解决：画流程前先画组织矩阵，明确每个节点归属哪个业务实体、哪个库存组织、哪个职责。流程图里每个框上都标注组织属性，宁可图面复杂一点，不要上线后一脸茫然。
5.3 库存事务不联动成本
现象：物料发出去了，库存数量变了，但存货金额纹丝不动，总账里成本科目和库存模块对不上。
原因：物料事务处理有数量事务和价值事务两种，价值事务是否产生取决于事务类型是否关联了会计科目。配置事务类型时漏了科目关联，或者没跑成本更新程序，就会出现“有量无值”的情况。
解决：做库存相关配置时，逐条检查事务类型对应的会计科目。测完一笔采购接收后立刻去看总账，确认借库存贷暂估的分录真实入账了，再继续往下测。
5.4 把流程图当操作手册
现象：新人照着端到端流程图点屏幕，每一步都点了，工单却一直开不出来，最后发现漏了“计划单转工单”的并发请求。
原因：流程图表达的是业务事件之间的依赖关系，不是点击顺序。图上一个“转工单”动作，实际可能要跑一个并发程序、设一堆参数，图里根本不会画出来。
解决：把流程图转成测试脚本时，要把每个节点拆成“前置条件、操作步骤、并发请求、预期结果”四栏。图用来讲逻辑，脚本用来教操作，两者不能互相替代。
5.5 拿旧版图对上线环境
现象：流程图里画的审批链在系统里找不到，配置文件的值对不上，以为系统坏了，其实是拿上一个项目的老图在比新环境。
原因：EBS 的流程会随配置和版本变化，组织结构、审批组、科目规则都可能被后人改过。流程图一旦脱离实际环境，就成了“历史上曾经存在过的流程”。
解决：每次项目上线或升级后，挑几个关键流程做一次“流程图复核”，对照实际环境的配置文件、职责权限、数据字典走一遍。图是死的，环境是活的。
6. 把流程图当接口设计读：一张图后面藏着什么
流程图看到最后，它不只是业务文档，更是一张接口地图。EBS 的价值从来不在单个模块的功能，而在模块之间的集成。每一条跨模块的数据流，都对应一组接口表和一次数据转换。看懂了图上的箭头，就能反推出一套系统的集成设计。
比如 O2C 流程里“订单到发运”那根箭头，底层是库存模块的接口表在接收订单行数据；“发运到开票”那根箭头，底层是应收模块的接口表在等待发运确认消息。实施人员拿到一张流程图，第一件事就是把每条跨模块的箭头标上对应的表名或接口名，这样将来的接口开发、数据迁移、问题排查就都有了坐标。这也解释了为什么资源里的流程图大多以模块为单位画——每个模块的边界，也就是接口的边界。
我一般会建议用“四个一”的方法去消化一份 EBS 流程图：一条主流程走到底（O2C 或 P2P），一张组织矩阵框定范围，一套主数据清单核对校验点，一张接口对照表落地实现。把图上的节点对应到表、把箭头对应到外键关系，这本流程图就不再是纸面文章，而是能直接用来排查问题的索引。
从那以后，我拿到任何一份 EBS 流程图，第一件事就是找跨模块的那根箭头，用 SQL 去验证箭头两端的数据能不能连上。连不上，图再漂亮也是摆设；连上了，业务逻辑才真正落地。希望帮到你。
本文还有配套的精品资源，点击获取
