简介：这份 Oracle 财务模块 AP-AR-FA-GL 培训教材面向财务信息化人员、Oracle EBS 实施顾问及企业财务管理者，用于系统梳理应付、应收、固定资产与总账四大核心模块的业务流程与系统操作。资源包内含 1 个 pptx 演示文档，压缩包约 624KB，以图文课件形式呈现，便于课堂培训与自学查阅。内容围绕 Oracle Assets 展开，覆盖资产增加、调整、转移、报废与折旧全生命周期，并讲解手工增加、成批增加、CIP 在建工程资本化、折旧规则与总账集成等关键环节；同时延伸至 Oracle Payables 的供应商与应付账款管理、Oracle GL 的总账设置与报表生成，以及 Projects、HR 等模块的关联知识。课件还涉及资产与总账共享帐套、货币、日历与账户结构，以及月末运行折旧、生成日记帐分录并过账至总账的数据表流转逻辑。目前已有 208 人学习，适合需要理解 Oracle 财务模块整体架构与资产核算细节的读者参考。
1. Oracle 财务四件套：AP、AR、FA、GL 到底怎么串起来
很多做 Oracle EBS 或 Fusion 财务模块的同行，第一次拿到一套完整的培训教材时，最直接的反应是「模块太多、表太多、接口太多，不知道从哪下手」。AP、AR、FA、GL 这四个模块，几乎覆盖了一家正常经营企业 80% 以上的财务核算动作：供应商发票进来走 AP，客户回款进来走 AR，固定资产买进来、折旧、报废走 FA，最后所有分录汇总到 GL 出报表。问题在于，这四个模块不是四个独立系统，它们之间靠 Subledger Accounting、靠 SLA 规则、靠 Period Close 顺序死死绑在一起。你单独学 AP 会做发票，单独学 AR 会做收款，但一到月末关账，AP 的应付款和 GL 的应付账款对不上、FA 折旧没传过去、AR 收款没核销干净，整个账就卡住了。这套培训教材的价值，不是教你点菜单，而是把「业务动作 → 子模块分录 → SLA 传递 → GL 过账」这条链路讲透。适合谁看？刚转 Oracle 财务模块的顾问、企业里负责月结的财务关键用户、以及需要做接口对接的技术开发。下面我按实际落地顺序，把四个模块的串联逻辑、关键配置和踩坑点拆开讲。
2. AP 到 GL 的完整链路：从发票录入到应付账款过账
2.1 AP 发票的四种类型与分录生成逻辑
Oracle AP 里最常见的发票类型是 Standard、Prepayment、Credit Memo、Debit Memo。很多人以为发票类型只是分类标签，实际上它直接决定 SLA 取哪条会计规则。Standard Invoice 走「借：费用/资产科目，贷：应付账款」；Prepayment 走「借：预付账款，贷：应付账款」，核销时再冲预付；Credit Memo 是红字冲销，方向相反。关键点在于：发票头上的 Liability Account 和 Distribution 上的 Charge Account 必须分开理解。Liability Account 是贷方应付，Charge Account 是借方费用或资产。如果这两个科目设错，GL 里就会出现「应付账款挂错供应商」或者「费用进错成本中心」。
实际操作中，我一般会先检查 Payables Options 里的 Accounting Method，是 Accrual 还是 Cash。Accrual 下发票验证即产生分录，Cash 下要等付款才产生。国内企业绝大多数用 Accrual，所以发票 Validate 之后，SLA 就会生成分录。这里有个容易翻车的点：发票验证后如果发现科目错，不能直接改 Distribution，必须先 Cancel 再重新录入，否则 SLA 会留下孤儿分录。
-- 查询某张 AP 发票在 SLA 中生成的分录 SELECT je_header_id, je_line_num, ledger_id, accounted_dr, accounted_cr, status, gl_transfer_status FROM xla_ae_lines WHERE application_id = 200 -- 200 是 AP 的 application_id AND ae_header_id IN ( SELECT ae_header_id FROM xla_ae_headers WHERE entity_id = :invoice_id );这段 SQL 查的是 XLA_AE_LINES，application_id 200 代表 AP。entity_id 传发票 ID。status 字段如果是 DRAFT 说明还没最终生成，gl_transfer_status 如果是 N 说明还没传到 GL。参数上，ledger_id 对应账套，accounted_dr/cr 是本位币金额。查出来如果发现借贷不平，先看 SLA 规则是不是被改过，再看发票 Distribution 的 Accounting Date 是否落在未打开的期间。
2.2 付款与核销：AP 付款如何冲减应付
付款环节的核心是 Payment Process Request。付款完成后，AP 会生成付款分录「借：应付账款，贷：现金/银行」。这里有个细节：如果发票是 Partial Payment，SLA 会按核销金额比例冲减。付款核销的方式有两种：AutoApply 和 Manual。AutoApply 按付款条件自动匹配，Manual 需要人工选发票。我一般建议先跑 AutoApply，再对未核销的做 Manual，否则容易出现「付了款但发票还挂着」的情况。
付款分录生成后，同样要确认 GL Transfer。如果付款已经过账但 GL 没收到，先查 Payables Transfer to General Ledger 这个请求有没有跑成功。常见报错是「Period is not open」，这时候要去 Open/Close Periods 里把 GL 期间打开。另一个坑是付款的 Accounting Date 和发票的 Accounting Date 不在同一期间，导致跨期核销，GL 里应付账款出现红字余额。
2.3 AP 月末关账的检查清单
月末关账前，我习惯跑三张报表：Invoice Aging Report、Payables Trial Balance、Unaccounted Transactions Report。Invoice Aging 看还有哪些发票没付款，Payables Trial Balance 看 AP 余额和 GL 应付账款是否一致，Unaccounted Transactions 看有没有没生成分录的交易。如果 Trial Balance 和 GL 对不上，差额通常是三类：一是发票没验证，二是付款没核销，三是 SLA 分录没传 GL。逐条排查，基本能定位。
提示：AP 关账前务必确认所有发票已 Validate，所有付款已 Accounting，所有 SLA 分录已 Transfer 到 GL。缺一步，GL 的应付账款就不准。
3. AR 收款与核销：客户回款怎么自动匹配发票
3.1 AR 发票与收款的分录生成
AR 的流程和 AP 镜像：发票生成「借：应收账款，贷：收入/税」，收款生成「借：现金/银行，贷：应收账款」。核销就是把收款和发票勾在一起。Oracle AR 支持自动核销（AutoCash Rule Set）和手动核销。AutoCash 的规则集决定收款先匹配哪张发票，常见的有「Match on Transaction Number」「Match on Sales Order」「Match on Amount」。如果客户回款备注里带了发票号，用 Transaction Number 规则最准；如果没带，用 Amount 规则容易匹配错。
-- 查询 AR 收款核销情况 SELECT r.receipt_number, r.amount, a.amount_applied, t.trx_number, t.trx_date FROM ar_cash_receipts_all r, ar_receivable_applications_all a, ra_customer_trx_all t WHERE r.cash_receipt_id = a.cash_receipt_id AND a.applied_customer_trx_id = t.customer_trx_id AND r.receipt_number = :receipt_num;这段 SQL 查收款和发票的核销关系。receipt_number 是收款编号，amount_applied 是核销金额。如果 amount_applied 为空，说明收款还没核销。参数上，applied_customer_trx_id 关联发票，trx_number 是发票号。查出来如果发现核销金额和收款金额不一致，差额就是未核销部分，需要做 Unapplied 或 On Account 处理。
3.2 自动核销规则集的配置要点
AutoCash Rule Set 在 Setup → Receipts → AutoCash Rule Sets 里配。规则顺序很重要：先跑最精确的匹配，再跑模糊匹配。我一般配成：Transaction Number → Sales Order → Amount → On Account。如果客户回款经常不带发票号，Amount 规则要设 Tolerance，比如 ±1 元以内才自动核销，否则容易错配。另一个坑是「Unapplied 收款」和「On Account 收款」的区别：Unapplied 是暂时没核销，On Account 是客户预付款。两者在 GL 里的科目不同，Unapplied 挂应收账款，On Account 挂预收账款。配错规则集，GL 科目就乱了。
3.3 AR 月末关账与账龄分析
AR 关账前要跑 Aging Report 和 Unapplied Receipts Report。Aging 按账龄分 0-30、31-60、61-90、90+，看哪些客户欠款超期。Unapplied Receipts 看还有多少收款没核销。如果 GL 的应收账款和 AR 的 Trial Balance 对不上，先查有没有未过账的发票或收款，再查 SLA 分录有没有传 GL。AR 的 SLA 和 AP 共用 XLA 表，但 application_id 是 222。
注意：AR 自动核销如果匹配错发票，不能直接删核销记录，要先 Unapply 再重新 Apply。直接删会导致 SLA 分录残留。
4. FA 资产折旧与 GL 过账：从资产新增到月末折旧
4.1 资产新增的四种方式与科目生成
FA 里资产新增有四种：Manual Addition、Mass Addition、Quick Addition、External Import。Manual 适合少量资产，Mass 适合批量导入。新增时最关键的是 Asset Category 和 Asset Key。Category 决定折旧方法、寿命、残值率，Key 是资产唯一标识。资产新增后，FA 会生成「借：资产成本科目，贷：资产清算科目」的分录。清算科目在 Category 里配，通常是「在建工程」或「应付账款」。
-- 查询 FA 资产新增的分录 SELECT fa.asset_number, fa.asset_cost, fa.date_placed_in_service, fah.asset_id, fah.period_name, xal.accounted_dr, xal.accounted_cr FROM fa_additions fa, fa_asset_history fah, xla_ae_lines xal WHERE fa.asset_id = fah.asset_id AND fah.asset_id = xal.entity_id AND xal.application_id = 140 -- 140 是 FA 的 application_id AND fa.asset_number = :asset_num;这段 SQL 查资产新增在 SLA 里的分录。application_id 140 是 FA。asset_cost 是资产成本，date_placed_in_service 是启用日期。accounted_dr/cr 是借贷金额。如果查不到分录，先看资产有没有跑「Generate Accounts」请求，再看 Category 的清算科目有没有配。
4.2 折旧运行与分录传递
折旧运行是 FA 月末的核心动作。跑「Depreciation Run」之前，要确认资产状态是 Active，启用日期在当期或之前。折旧分录是「借：折旧费用，贷：累计折旧」。折旧费用科目在 Category 的 Book 里配，累计折旧科目也在 Book 里配。跑完折旧后，要跑「Create Accounting」生成 SLA 分录，再跑「Transfer to GL」传到总账。常见报错是「Asset is not in the current period」，说明资产启用日期在未打开的期间，需要先打开 FA 期间。
4.3 FA 与 GL 对账的三种方法
FA 和 GL 对账，我一般用三种方法：一是跑「Asset Trial Balance」和 GL 的资产科目对比；二是跑「Depreciation Report」和 GL 的折旧费用对比；三是跑「Cost Summary Report」和 GL 的资产成本对比。如果对不上，先查有没有资产没跑折旧，再查有没有折旧没传 GL，最后查 Category 科目有没有配错。FA 的 SLA 分录在 XLA 表里，application_id 140。
提示：FA 折旧运行后，如果发现折旧金额不对，不能直接改折旧分录，要先回滚折旧（Rollback Depreciation），改资产信息，再重新跑。
5. GL 总账与 SLA 传递：四个模块怎么在总账里对齐
5.1 SLA 的会计规则与科目推导
SLA（Subledger Accounting）是 AP、AR、FA 和 GL 之间的桥梁。每个子模块的交易，先由 SLA 根据会计规则生成分录，再传到 GL。SLA 的核心是「Accounting Method」和「Application Accounting Definition」。Accounting Method 决定用哪套规则，Application Accounting Definition 决定具体科目怎么推导。科目推导有四种来源：Constant、Source、Mapping Set、Account Rule。Constant 是固定值，Source 是交易上的字段，Mapping Set 是映射表，Account Rule 是条件规则。配 SLA 最怕的是规则冲突，导致科目取错。
-- 查询 SLA 分录传到 GL 的状态 SELECT xah.entity_id, xah.event_type_code, xal.accounted_dr, xal.accounted_cr, xal.gl_transfer_status, xal.gl_batch_id FROM xla_ae_headers xah, xla_ae_lines xal WHERE xah.ae_header_id = xal.ae_header_id AND xah.application_id = :app_id AND xah.entity_id = :entity_id;这段 SQL 查 SLA 分录的 GL 传递状态。gl_transfer_status 如果是 N，说明还没传 GL；如果是 Y，说明已传。gl_batch_id 是 GL 批次号。参数上，app_id 是子模块 ID（AP=200，AR=222，FA=140），entity_id 是交易 ID。如果状态是 N，先跑「Transfer to GL」请求，再看 GL 接口表有没有数据。
5.2 GL 过账与期间关闭的顺序
GL 过账是最后一步。子模块传过来的分录，先在 GL_INTERFACE 表里，跑「Journal Import」生成 GL 日记账，再跑「Post」过账。过账后，GL 余额才更新。期间关闭的顺序是：先关子模块期间，再关 GL 期间。如果子模块没关，GL 关了，子模块的分录就传不进来。我一般建议按 AP → AR → FA → GL 的顺序关账，每个模块关之前确认所有交易已 Accounting 和 Transfer。
5.3 四模块对账的通用排查路径
四个模块和 GL 对不上，排查路径是：先查子模块的 Trial Balance，再查 SLA 的 XLA_AE_LINES，再查 GL 的 GL_JE_LINES。如果子模块有余额但 GL 没有，说明 SLA 没传；如果 SLA 有但 GL 没有，说明 Journal Import 没跑；如果 GL 有但金额不对，说明 SLA 规则取错科目。逐层排查，基本能定位。
注意：GL 期间关闭后，如果发现子模块还有分录没传，只能反关 GL 期间，传完再关。反关期间会影响报表，尽量在关账前确认干净。
6. 避坑与常见问题：AP、AR、FA、GL 联调中的五个血泪教训
6.1 发票验证后科目错，直接改 Distribution 导致 SLA 残留
现象：AP 发票验证后发现费用科目错，直接改 Distribution，重新验证，GL 里出现两套分录。原因：SLA 在第一次验证时已经生成分录，改 Distribution 不会自动冲销旧分录。解决：先 Cancel 发票，再重新录入，或者跑「Create Accounting」时选「Final Post」冲销。
6.2 AR 自动核销匹配错发票，直接删核销记录导致 GL 不平
现象：AR 自动核销把收款匹配到错误发票，直接删核销记录，GL 应收账款余额不对。原因：删核销记录不会自动冲销 SLA 分录。解决：先 Unapply 核销，再重新 Apply，让 SLA 生成冲销分录。
6.3 FA 折旧运行后改资产，没回滚折旧导致折旧金额错
现象：FA 折旧跑完后发现资产成本录错，直接改资产，下个月折旧金额不对。原因：折旧已经基于旧成本计算，改资产不会自动重算。解决：先 Rollback Depreciation，改资产，再重新跑折旧。
6.4 GL 期间关闭后子模块分录传不进来
现象：GL 期间已关，AP 还有发票没传 GL，跑 Transfer 报错「Period is not open」。原因：GL 期间关闭后不接受子模块分录。解决：反关 GL 期间，传完分录再关。或者等下一期间，但会导致跨期。
6.5 SLA 规则冲突导致科目取错
现象：AP 发票的費用科目取成了资产科目，GL 里费用和资产都错。原因：SLA 的 Account Rule 条件写错，或者 Mapping Set 配错。解决：查 SLA 的 Application Accounting Definition，逐条核对规则优先级，改完重新跑 Create Accounting。
7. 用 SQL 做四模块对账：一个可复用的排查脚本
对账这件事，菜单里能跑报表，但报表往往不够灵活。我习惯用 SQL 直接查 XLA 和 GL 的表，快速定位差异。下面这个脚本，可以查某个期间内 AP、AR、FA 传到 GL 的分录汇总，和 GL 的实际余额对比。
-- 四模块 SLA 分录汇总 vs GL 余额 SELECT xah.application_id, CASE xah.application_id WHEN 200 THEN 'AP' WHEN 222 THEN 'AR' WHEN 140 THEN 'FA' END AS module_name, SUM(xal.accounted_dr) AS total_dr, SUM(xal.accounted_cr) AS total_cr, COUNT(*) AS line_count FROM xla_ae_headers xah, xla_ae_lines xal WHERE xah.ae_header_id = xal.ae_header_id AND xah.application_id IN (200, 222, 140) AND xah.period_name = :period_name AND xal.gl_transfer_status = 'Y' GROUP BY xah.application_id ORDER BY xah.application_id;这段 SQL 按模块汇总已传 GL 的借贷金额。参数 period_name 传期间名，比如 '2024-01'。查出来如果 AP 的借贷不平，说明有单边分录；如果某个模块 line_count 为 0，说明该模块当期没传分录。对比 GL 的 GL_JE_LINES 里对应科目的余额，就能定位差异。
再补一个查未传 GL 的分录：
-- 查未传 GL 的 SLA 分录 SELECT xah.application_id, xah.entity_id, xah.event_type_code, xal.accounted_dr, xal.accounted_cr, xal.gl_transfer_status FROM xla_ae_headers xah, xla_ae_lines xal WHERE xah.ae_header_id = xal.ae_header_id AND xah.application_id IN (200, 222, 140) AND xal.gl_transfer_status = 'N' AND xah.period_name = :period_name;这个脚本查 gl_transfer_status = 'N' 的分录，这些就是没传 GL 的。跑出来如果有数据，直接跑「Transfer to General Ledger」请求，传完再查一次确认。
我自己的习惯是：每月关账前，先跑这两个脚本，确认所有分录已传 GL，再跑子模块 Trial Balance 和 GL 对账。对上了再关期间。这个习惯帮我省了无数次反关期间的麻烦。对账这件事，宁可事前多查十分钟，不要事后反关一整天。希望帮到你。
本文还有配套的精品资源，点击获取
