简介本资源是一份面向Oracle EBS R12财务实施顾问、财务关键用户及运维人员的月结专题培训演示文稿围绕月结概述、子模块与总账关系、关帐顺序展开并重点讲解应付、采购、库存、应收、资产、PAC及总账等模块的详细结帐流程与对帐方法。内容涵盖发票与付款处理检查、会计科目创建、凭证传送与过账、供应商余额核对、期间关闭、库存盘点与成本更新等实务操作并结合具体报表与SQL对账思路适合用于月结制度的系统学习、上线初期方案梳理及内部培训参考。资源包共1个文件为pptx演示文稿压缩包大小2.9MB内容以结构化目录呈现知识密度较高。目前已有60人学习下载适合对Oracle EBS财务模块月结与对账机制有一定了解、希望快速掌握各模块关账顺序及关键控制点的读者。1. OracleEBS R12月结到底在结什么一次只讲清楚一件事每个月底财务部催着关账OracleEBS R12系统里却还有几十张未过账的凭证没处理这种事情在实施和运维现场一点也不少见。所谓月结不是点一个“Close Period”按钮就结束而是一个跨模块的闭合流程把GL总账、AP应付、AR应收、FA固定资产、Inventory库存这几个模块本期间的所有业务全部确认、过账、对平然后把会计期推进到下一期。整个过程如果你只操作GL会发现怎么都对不上数如果你不管子模块GL这边关了账前面AP还在往里传凭证后面AR还有收款没确认——这种状态就是大家常说的“月结算关了个寂寞”。这篇文章把OracleEBS R12财务月结按“前置检查 → 子模块关账 → GL关账 → 验证对账”拆开讲适合两类人看一类是刚刚接手EBS财务模块运维的IT人员需要一套可以直接照着做的流程另一类是做实施项目的功能顾问需要知道月结时哪些参数会影响结果、哪些操作顺序不能反。内容以R12为基础重点讲GL、AP、AR、FA四个模块的配合关系不涉及采购库存的复杂成本结算那些属于另一个量级的课题。最后会给出验证月结是否闭环的SQL以及我最常踩的几个坑。2. 月结前夜会计期与数据完备性检查2.1 会计期先打开子模块才能进单先确认一件最基础的事GL的会计期打开了吗子模块的会计期打开了吗两个不是一回事但经常有人忽略。在OracleEBS R12里GL打开会计期之后AP和AR才能把该期间的事务处理过账到GL反过来如果GL还没打开该期间你在AP做Invoice Validation时会报“Period not open”根本走不下去。常见做法是每个月初先打开系统里所有相关模块的下一个会计期但月结的时候我们要确保的是本期间已经打开了而且没有其他人员在同一个期间里乱做业务。上线初期发生过这种事故财务在月末跑月结采购同事在AP里录入了一张发票结果GL关账后这张发票验证通过并过账直接进了已经关闭的期间导致Trial Balance对不上最后只能用Reopen Period把期间重新打开。所以我自己做月结第一件事永远是查会计期状态而不是直接跑请求。-- 查看GL与子模块会计期状态 SELECT gl.name AS ledger_name, glp.period_name AS period_name, glp.period_year AS fiscal_year, glp.period_num AS period_number, glp.quarter_num AS quarter_number, glp.closing_status AS gl_close_status, glp.period_type AS period_type, glp.period_status AS period_status FROM gl_periods glp, gl_ledgers gl WHERE glp.ledger_id gl.ledger_id AND glp.period_name LIKE %-18 AND glp.period_type A ORDER BY glp.period_year, glp.period_num;这段SQL查询总账的会计期状态period_status字段是月结的关键它会显示OOpen、FFuture Entry、CClosed、PPermanently Closed等状态。在月结前period_status必须是O或者F一旦变成C就说明已经有人动过关账动作。代码里period_name LIKE %-18是限定会计期年份实际使用时改成你对应的年份和期间关键字。这里有一个很重要的细节R12中GL会计期是独立的而AP、AR、FA、Inventory的会计期维护在各自模块里。你可以在子模块打开多个期间甚至让子模块的当前期间和GL不一致但月结时所有模块的期间必须对齐到同一个期间。我一般建议在月结开始前跑一遍SQL把五个模块的打开期间列出来人工对一遍防止某个子模块的期间还停留在上一期。2.2 未过账、未验证、未转账三类脏数据的SQL体检会计期打开之后下一步是查“脏数据”。月结最怕的不是账做错了——做错了可以调最怕的是账没做完。系统里还有未验证的发票、未过账的日记帐、未创建会计分录取证的收款这些都会在月结时变成拦路虎。第一类要查的是GL里未过账的日记帐。很多人以为Post Journals是一个可选步骤实际上R12的GL月结要求所有本期日记帐完成Post否则Trial Balance不平。出现过一种情况调拨公司间往来的时候日记帐保存了但还没Post结果月结后子公司报表里应收账款对不上查了半天发现是那笔调整没有过账。-- 查询GL中未过账的日记帐 SELECT jh.je_batch_name, jh.je_header_name AS journal_name, jh.je_category, jh.je_source, jh.running_total_dr AS total_dr, jh.running_total_cr AS total_cr, jh.status AS journal_status, jh.posting_status AS posting_status, jh.ledger_id FROM gl_je_headers jh WHERE jh.ledger_id 2025 -- 换成你的ledger_id AND jh.period_name DEC-18 -- 换成你要关闭的期间 AND jh.posting_status P ORDER BY jh.je_batch_name;posting_status字段有三个常见值P表示已过账U表示未过账F表示过账失败。月结前查出所有不带P的记录先解决掉。命中的记录里如果状态是F说明过账过程中出现数据库错误最常见的处理办法是进入日记帐界面重新点了Post。如果还是失败就要去GL_INTERFACE表查是否有数据没进入GL_JE_HEADERS。第二类要查的是AP的未验证发票。AP里一张发票只有从Pending变成Validated才会生成会计分录取证。没有验证的发票不会出现在总账里但它会让你在Accrue Uninvoiced Receipts之后怀疑自己的应计费用算少了。我见过一次翻车现场财务人员以为所有发票都验证过了跑完Accrue Expense结果采购部在月末最后一天录入了一批发票但没人做Validation导致未开票收货应计费用少计了十几万。-- 查询AP中未验证发票 SELECT ai.invoice_num, ai.invoice_date, ai.invoice_amount, aps.vendor_name, ai.invoice_type_lookup_code, ai.validation_date, ai.amount_remaining FROM ap_invoices_all ai, ap_suppliers aps WHERE ai.vendor_id aps.vendor_id AND ai.validation_date IS NULL AND ai.invoice_date :p_close_date -- 月结截止日期 AND ai.cancelled_date IS NULL ORDER BY ai.invoice_date;这段SQL核心是validation_date IS NULL它是判断发票是否完成验证的唯一可靠字段。如果一张发票创建了但没验证validation_date就是空的。注意不要用invoice_amount是否为0来判断有些冲销发票金额为0但也是需要验证后才能在系统里留存。查出来后能验证的就验证不能验证的确认是否需要删除。第三类是AR里未确认的收款。AR的收款要经过Create Accounting生成分录并且成功转移至GL才会体现在总账。R12里利用SLASubledger Accounting架构AR的会计分录取证和转移是两步独立的操作先Create Accounting再Transfer to GL。如果业务量大转移过程可能半途失败导致GL有接口数据但没有真正过账。查询AR接口表是一种办法但更直接的是查AR的Receipt状态。-- 查询AR中未确认是否创建会计分录取证的收款 SELECT r.receipt_number, r.receipt_date, r.amount, r.status AS receipt_status, r.cash_receipt_id, r.attribute1 FROM ar_cash_receipts_all r WHERE r.status IN (CONFIRMED, UNCONFIRMED, REVERSED) AND r.receipt_date :p_close_date AND r.org_id :p_org_id -- 指定OU ORDER BY r.receipt_date;2.3 预算控制与外币不影响过账但影响余额很多项目上了预算控制月结的时候预算状态会直接影响GL期间的状态。如果启用了GL Budgetary Control且当月预算还没有做调整为Final可能出现期间无法关闭的现象。这类问题没有通用的SQL因为预算控制表结构因版本和配置而异。我的建议是月结前一周就把预算调整做完不要在关账当天做预算。外币这块则是另一条线。如果账套启用了多币种月结时要做Currency Revaluation外币重估这是GL内部的步骤不涉及子模块。重估不是简单的汇率折算而是把以外币计量的科目余额按期末汇率调整为本位币产生的汇兑损益进入指定的重估科目。这个动作必须在所有子模块传完数据之后再做否则你重估出来的数字会漏掉之后进来的凭证。所以流程上它必然排在GL Post之后、Period Close之前。后面单独开一节讲。3. 子模块月结顺序AP、AR、FA谁先谁后3.1 AP月结Accrue Expense与Payables CloseAP模块月结的第一步不是跑请求而是确认所有本期间的发票都已经完成Validation。接下来是处理未开票收货Uninvoiced Receipts。这个步骤的官方名称是Accrue Expense但实际上它处理的是“已经收货、还没收到发票”的金额需要按采购订单的接收记录计算应计费用生成AP分录。很多项目这个步骤不做因为他们的业务模式是先票后货或者发票处理及时但对于月末到货集中、发票滞后的企业这个动作必须有否则月结后的应付账款余额会少一块。-- 检查是否存在未匹配的PO接收记录 SELECT pih.po_number, prh.receipt_num, rsl.quantity_received, rsl.quantity_accepted, rsl.quantity_billed, (rsl.quantity_accepted - NVL(rsl.quantity_billed, 0)) AS to_accrue_qty FROM rcv_shipment_headers rsh, rcv_shipment_lines rsl, po_headers_all pih, po_lines_all pla, rcv_receiving_rules rrr WHERE rsh.shipment_header_id rsl.shipment_header_id AND rsl.po_header_id pih.po_header_id AND rsl.po_line_id pla.po_line_id AND rrr.receiving_rule_id rsl.receiving_rule_id AND rrr.name Standard AND rsl.quantity_accepted - NVL(rsl.quantity_billed, 0) 0;这段SQL的核心就是计算数量差异quantity_accepted是已经接收的数量quantity_billed是已经匹配到发票的数量两者相减大于0说明还有货已经收了但发票还没到。跑完这个查询你就能判断该不该做Accrue Expense。Accrue Expense的操作路径是AP Responsibility → Journals Entry → Subledger Accounting → Accrue Expense。请求跑完之后要去核对生成的会计分录借了费用科目、贷了应计负债科目这两个科目在AP选项中配置常见问题是对应会计科目未建立账户组合导致请求报错或分录跳行生成。AP模块的关账动作是Payables Close和Payables Close-Close。前者是结束当前期间的过账权限后者是彻底关闭期间的AP事务处理。我一般建议月结当天只做Payables Close等GL整套流程走完确认无误第二天或者隔天再做Payables Close-Close。原因很现实如果Accrue Expense之后发现漏掉了某些应收的贷项通知单只要还没做Close-Close还可以回退一旦Close-Close就只能做下期的调整分录。3.2 AR月结Revenue Recognition与Receipt ReconciliationAR月结的第一步是确认所有发票Invoice和贷项通知单Credit Memo完成了处理并创建了会计分录取证。R12中Create Accounting跑完之后数据会进入GL_INTERFACE然后由Transfer to GL这个请求把接口数据传进GL。这两个动作很多人当成一个步骤实际上是两个独立请求经常有人跑完第一个没跑第二个结果GL里查不到AR的数据。# 检查AR会计分录取证是否成功Transfer to GL之后GL接口与GL日记帐应该匹配 SELECT gjh.je_header_name, gjh.je_source, gjh.je_category, gjh.running_total_dr, gjh.running_total_cr, gjh.period_name FROM gl_je_headers gjh WHERE gjh.je_source AR AND gjh.period_name :p_period_name AND gjh.posting_status P ORDER BY gjh.je_header_name;这段SQL查的是AR来源的已过账日记帐。如果查不到记录说明要么Create Accounting没跑要么转移失败。这时候不要重新跑AR请求先把失败原因找出来打开GL_INTERFACE表看status字段如果是E说明接口数据有错误查看error_message列会告诉你具体原因通常是科目组合失效或账户段值被禁用。AR月结另一个高发问题叫Receipt Reconciliation。它是把银行的收款记录和AR的应收发票进行匹配。R12里提供了AR Receipt Reconciliation和Quick Reconciliation两种工具。简单说如果一笔收款没有匹配到任何发票它就会挂在Unapplied状态资金已经进账但应收账款的余额没有减少。月结时如果不对这一块做梳理后续对账会很痛苦。-- 查询AR中处于Unapplied状态的收款 SELECT r.receipt_number, r.receipt_date, r.amount, r.status FROM ar_cash_receipts_all r WHERE r.status UNIDENTIFIED -- 或 UNAPP取决于版本 AND r.receipt_date :p_close_date AND r.org_id :p_org_id ORDER BY r.receipt_date;收到这种结果处理方式是确认该笔收款对应的发票做Apply操作。如果实在无法匹配至少调整到Suspense科目并记录原因不要让它一直挂在Unapplied状态。月结前的AR对账要确认所有已确认收款都已经Apply to Invoice所有Unapplied已经处理或说明用途。AR模块的关账动作是Receivables Close和Receivables Close-Close。和AP一样也建议先做Close确认GL对账无误后再做Close-Close。如果项目采用统一管理AR和AP的Close-Close可以在同一天做但顺序上AP先行。3.3 FA月结折旧跑完不等于关账完成FA模块是所有子模块里最容易被人遗忘的。因为固定资产的业务量小平时几乎没人操作它但月结要是漏了折旧麻烦非常大折旧没跑GL里固定资产的累计折旧余额就不动资产负债表的数字就会和上个月一模一样。这种情况发生过不止一次财务拿着一张上月和本月完全相同的固定资产报表来找我问我是不是系统坏了结果一看FA的折旧请求根本没有运行。FA月结的操作顺序先运行Depreciation Run折旧再运行Create Accounting创建分录取证最后运行Transfer to GL转移到总账。这个顺序不能错折旧没跑完就没有分录取证可创建Create Accounting没跑完Transfer就没有数据可转。-- 查询FA折旧运行状态 SELECT book.book_name, depr.request_id, depr.period_name, depr.run_status, depr.set_of_books_id, depr.accounting_status FROM fa_deprn_periods depr, fa_book_controls book WHERE depr.book_type_id book.book_type_id AND depr.period_name :p_period_name ORDER BY depr.request_id DESC;run_status字段显示折旧请求是否完成常见值是CCompleted和RRunning。如果状态长期停留在R说明并发管理器有异常要去查并发请求日志如果状态是C但accounting_status不是C说明折旧已经计算了但还没生成分录取证。这两个状态要同时是完成状态才算FA这一环结束。FA有一个特殊参数Depreciation Run的Run类型分为RRegular、BBonus、SSupplemental。普通月结只跑Regular即可但如果项目当初启用了Bonus Reserve奖金准备规则还要跑一次Bonus折旧。这个参数很多人不知道我见过一家企业月结后固定资产原值和累计折旧都正常但资产净值多出一小块查了三天发现是Bonus折旧从未跑过。FA的Create Accounting请求还有个细节它可以选择Post to GL的选项。如果你在FA里勾选了自动过账分录取证会直接送到GL如果没勾选你需要在GL里对FA来源的日记帐手动Post。我建议所有FA产生的分录取证统一在GL月结时手动Post这样便于统一控制过账节奏。4. GL月结核心操作从Post到Permanently Close4.1 Post Journals欠账不消余额不平所有子模块的数据都转移到位之后GL侧的第一个动作是Post Journals。这是最基础但也是最容易被忽略的一步。原因在于EBS的GL里一张Journal即使被批准只要没Post它就不会参与账户余额的计算Trial Balance也不会包含它。月结时发现余额不平第一反应应该是查未过账日记帐而不是急着去调账。Post Journals的操作路径GL Responsibility → Journals → Post。界面上会列出所有未过账的日记帐可以全选然后点击Post。如果数据量大建议使用Post Journals并发请求这样有日志可查。过账失败时去并发请求的日志文件里找SQLCA错误信息最常见的失败原因是数据库锁或接口表死锁。R12里偶发过由于GL_JE_LINES表索引异常导致Post请求失败的情况这类问题需要DBA介入但作为功能顾问你至少能从报错信息判断是应用层还是数据库层的问题。Post完成的标准不是“请求成功了”而是“所有来源的数据都过账了”。你可以用下面这个SQL检查各模块来源的过账状态。-- 检查GL中所有模块来源日记帐过账状态 SELECT je_source, je_category, COUNT(*) AS header_count FROM gl_je_headers WHERE period_name :p_period_name GROUP BY je_source, je_category ORDER BY je_source, je_category;这段SQL把当前期间的日记帐按来源分组统计。JE_SOURCE字段会显示AP、AR、FA、GL、INV等来源。理想情况下每个来源都有记录并且数量符合预期。如果某个模块来源的记录数为0说明该模块的数据根本没进入GL回头查子模块的Transfer to GL请求。我当时做月结的习惯是把各来源的日记帐数量记录下来做成一张表每月对比数量突然的增减往往意味着业务异常。4.2 Revaluation与Translation外币科目的两次处理如果账套涉及多币种在Post Journal之后、Period Close之前要执行Currency Revaluation。这是GL层面的重估和子模块的外币处理不同。外币重估的目的是把以外币计量的科目余额按期末汇率转换成本位币并生成汇兑损益分录取证。Revaluation的操作路径GL Responsibility → Journals → Revaluation。这里有几个必填参数Revaluation Reversal一般选择Yes表示下期期初自动冲回本期重估分录避免余额重复累积。Exchange Rate Type常用Corporate或User取决于企业汇率政策。用User意味着你需要提前维护好期末汇率。Revaluation Account指定汇兑损益科目这个科目必须在科目结构里存在。Account Range需要重估的科目范围。实务中通常只重估资产、负债类科目损益类科目不做重估否则利润会被汇率波动扭曲。-- 查询需要重估的外币科目余额 SELECT gcc.segment1 AS company, gcc.segment2 AS account, gcc.segment3 AS currency, gcc.segment4 AS dept, SUM(NVL(gb.begin_balance_dr, 0) - NVL(gb.begin_balance_cr, 0)) AS opening_balance, SUM(NVL(gb.period_net_dr, 0) - NVL(gb.period_net_cr, 0)) AS period_activity FROM gl_balances gb, gl_code_combinations gcc WHERE gb.code_combination_id gcc.code_combination_id AND gb.currency_code :p_functional_currency -- 非本位币科目 AND gb.period_name :p_period_name GROUP BY gcc.segment1, gcc.segment2, gcc.segment3, gcc.segment4 HAVING SUM(NVL(gb.period_net_dr, 0) - NVL(gb.period_net_cr, 0)) 0;这段SQL的用途是发现是否存在外币余额变动。currency_code不是本位币的记录才有重估需求。如果查询结果为0说明系统里没有外币的余额变动重估这一步骤可以只跑流程不做实际调整。重估之后会生成新的日记帐这些日记帐需要再次Post。忘记Post重估分录是新手最常见的错误导致重估后的余额还是旧的。Translation外币折算和Revaluation不一样Translation用于合并报表场景把一个实体的本位币账务折算成报告币种。一般只在多公司合并时才需要。如果没有合并报表需求只需要做Revaluation。4.3 关账三步走Close、Close-Close、Permanently Close当所有日记帐过账完成、重估完成、再次过账完成之后才进入关账动作。R12的GL期间提供三个关账级别Close Period、Close-Close Period、Permanently Close Period。理解这三者的区别你才能决定用哪个。Close of Period是在GL期间状态从Open变成Closed的行为。关闭之后普通用户无法再录入或过账到该期间的日记帐但财务主管可以通过Open Period重新打开期间。这是月结日常使用的选项每个月末做一遍。Close-Close of Period是一个更严格的关闭状态。执行Close-Close之后期间的日记帐过账被严格禁止即使你是财务主管也需要先执行Reopen Period才能恢复。它的意义是防止事后有人偷偷改数据。不少企业月结后用Close-Close把期间锁死但遇到跨期调整时又得重新打开。Permanently Close是终态执行之后期间无法再打开。这个操作一般一年做一次把完全审计结束的年结期间永久关闭。我见过一个有点极端的案例有企业月结时为了省事直接把所有历史期间都选了Permanently Close结果来年发现有张去年的凭证需要改Treasury那边的银行余额不对最后只能做重分录冲回再调整白白多了一堆麻烦。所以我的习惯是月度关账只做Close季度或年度视审计节奏做Close-Close年度审计彻底结束后才做Permanently Close。-- 查看GL期间当前的关闭状态 SELECT period_name, period_year, period_num, period_type, closing_status, period_status FROM gl_periods WHERE period_type A AND period_name :p_period_name;执行顺序在GL界面是Period Close → Close Period → Close-Close Period。每个操作会弹窗询问确认确认后可以在GL_PERIODS表里看到CLOSING_STATUS字段从O变成C或F。注意Close-Close之后子模块的未处理事务不会受影响但GL侧无法再补充日记帐。如果子模块还有数据未转移必须先回子模块处理完毕否则以后补录只能进下一期。一个容易被忽略的点AR和AP的Close-Close和GL的Close-Close要配合做。正确顺序是先AP/AR做Close-Close再GL做Close-Close顺序反了会出现GL无法关闭子模块期间的情况。5. 月结避坑五个真实翻车记录5.1 现象GL Trial Balance不平AR、AP余额对不上在月末结账对账时发现GL的应收余额比AR子模块的期末余额少了这张差异对不上账。查了所有AR来源的日记帐也在GL里确认过账了看起来一切正常。原因在于AR的Transfer to GL请求没有跑完。Create Accounting已经把分录取证生成好了但由于并发管理器压力过大Transfer请求半路终止导致GL_INTERFACE表里AR数据没有完全进入GL_JE_HEADERS。解决方法是重新提交Transfer to GL请求。在AR Responsibility的Journals Entry界面找到Transfer to GL并重新运行。注意不要重复跑Create Accounting那样会生成重复分录。重新转移时接口表里已经存在的数据不会二次导入系统会自动跳过。如果重新Transfer后还是有差异查看GL_INTERFACE表的状态和错误消息把报错记录解决掉。5.2 现象Accrue Expense跑完AP里却没有任何应计分录月结做AP应计费用请求状态显示已完成但打开AP日记帐查询发现没有任何分录GL里也没有相应的应计金额。原因出在SLASubledger Accounting的映射配置上。R12里AP的应计分录是通过SLA规则生成的假如应付模块的会计方法中ACCRUE事件没有配置映射或者映射到了不存在的科目组合请求仍然会正常完成但不会生成任何日记帐你需要去AP Accounting Options里检查SLA配置。解决方法是进入Payables Accounting Options查看Accounting Method确认其中包含了Accrue Expense事件并且映射的账户组合在GL科目结构里有效。如果找不到配置用系统预置的Standard Accrual方法作为基准对照。修改配置后重新运行Accrue Expense请求这次产生的分录会在下一个期间或当期显示。提个醒修改SLA配置只影响修改后的事件不会追溯历史数据。5.3 现象FA折旧已跑但GL查不到FA的分录FA模块折旧请求状态为Completed但GL模块中JE_SOURCE FA的日记帐数为零。固定资产月结明明已经完成了总账里却没有折旧费用。原因是FA的Create Accounting请求没有在折旧后运行。运行折旧只计算了折旧额并更新了FA_DEPRN_DETAIL表不产生会计分录取证产生分录取证需要单独运行Create Accounting。折旧和取证的分离是R12的设计不算缺陷但确实容易忽略。解决方法是补跑Create Accounting。在FA Responsibility的Accounting菜单下找到Create Accounting选择对应的账簿和折旧期间运行选项里选择Entire Period生成分录取证。之后还需运行Transfer to GL将分录加入GL。此后确认对应期间FA来源的日记帐数量和金额和折旧报告比对一致即可。5.4 现象外币重估后科目余额不对差了汇兑损益的金额执行Currency Revaluation后查看外币科目的余额发现本位币金额没有变化或者说只有一半的调整汇兑损益没有体现。原因多数情况是Revaluation之后没有对生成的分录取证进行Post。Revaluation只是生成了重估分录这些分录若没有Post就不会影响余额。程序逻辑分两步但容易让人以为一次请求全搞定。解决方法是回到Revaluation的批次列表找到生成的日记帐批次在GL里Post该批记录。另一个可能性是Revaluation参数设置中Reversal选项选择了Yes导致重估分录在期初被自动冲回月末余额看起来没有变化。这时只要确认期末余额是用调整后的汇率计算即可不必担心期初冲回那是正确的处理方式。5.5 现象Permanently Close点早了凭证需要调整却改不了为了赶年度结账进度把会计期直接Permanently Close之后发现需要调整一笔重要凭证但系统提示期间已永久关闭无法再打开。原因是Permanently Close是一个不可逆操作用的时候过于激进。本质上这个操作只适用于年度审计和税务申报彻底结束之后。解决办法只有一条如果开了Permanently Close必须找DBA直接更新GL_PERIODS表的CLOSING_STATUS字段才能恢复风险较大。更稳妥的做法是在非极端情况下年度关账最多用Close-Close给后续留下调整空间。我的个人习惯是月度永远只点Close季度用一次Close-Close年度审计完毕后才做Permanently Close。6. 月结后的验证清单一个SQL对平五个模块月结流程跑完之后账是不是真的平了我见过最多的问题是“流程全走完了但数字怎么也和子模块对不上”。所以每次月结收尾我都会跑一遍跨模块余额核对。这里的思路是GL作为总账它应该等于各子模块的汇总。AP应付、AR应收、FA固定资产折旧全部要映射到GL的对应一级科目。只要对平了这个月才算真正关干净。-- 月结后核验GL当期余额与子模块余额一致性检查 SELECT alg.ledger_id, alg.period_name, alg.account_code, alg.account_description, NVL(alg.begin_balance_dr - alg.begin_balance_cr, 0) AS opening_balance, NVL(alg.period_net_dr - alg.period_net_cr, 0) AS period_activity, NVL(alg.end_balance_dr, 0) - NVL(alg.end_balance_cr, 0) AS closing_balance FROM ( SELECT gb.ledger_id, gb.period_name, gcc.concatenated_segments AS account_code, gcc.description AS account_description, gb.begin_balance_dr, gb.begin_balance_cr, gb.period_net_dr, gb.period_net_cr, gb.end_balance_dr, gb.end_balance_cr FROM gl_balances gb, gl_code_combinations gcc WHERE gb.code_combination_id gcc.code_combination_id AND gb.period_name :p_period_name AND gb.actual_flag A AND gcc.segment2 LIKE 1% -- 假设资产类科目段范围按实际科目结构调整 ) alg ORDER BY alg.account_code;这段SQL查询的是GL的gl_balances表的期末余额是月结后最容易上手的验证工具。查出来的结果要和AP、AR、FA各子模块的报表做横向对比。实际操作中你可以再写一个子查询分别把AP的日记帐余额、AR的日记帐余额、FA的折旧费用余额输出来然后按科目段拼接比对。但不要指望系统能自动告诉你“对不上”EBS没有这样一个一键对账的报表你得自己有好的方法。我最后留着的一个习惯是月结完成后把当月的Trial Balance和Period Close Exception Report导出存档至少保留两年。这样即使以后需要追溯某个期间的余额是怎么来的不用重新打开早已关闭的期间还能快速定位是哪个步骤出了问题。如果审计来查也有完整的证据链。这是我从第一年上线翻车后养成的习惯到现在都觉得值得。希望帮到你。本文还有配套的精品资源点击获取