簡介這是一份面向Oracle財務(wù)管理系統(tǒng)實施顧問、財務(wù)IT運維及企業(yè)財務(wù)人員的專項培訓(xùn)資料重點講解現(xiàn)金模塊CE中收款、付款、銀行對賬與調(diào)節(jié)等核心業(yè)務(wù)幫助讀者系統(tǒng)掌握企業(yè)現(xiàn)金流管理流程。資源包為單個doc文檔共1個文件壓縮后約1.74MB內(nèi)容為可編輯的Word版106頁完整手冊便于查閱標(biāo)記和二次整理。目前已有91人學(xué)習(xí)下載。手冊編排體系化設(shè)有文檔控制頁涵蓋多個培訓(xùn)單元從現(xiàn)金模塊概述及其與應(yīng)收應(yīng)付、總賬、固定資產(chǎn)等模塊的關(guān)系切入逐步展開系統(tǒng)參數(shù)設(shè)置、銀行事務(wù)代碼定義、銀行對賬單導(dǎo)入與手工輸入、對賬單調(diào)節(jié)、差錯處理、人工結(jié)清以及過賬與查詢、現(xiàn)金預(yù)測等關(guān)鍵環(huán)節(jié)每個單元均配有培訓(xùn)目標(biāo)和Lesson小節(jié)步驟說明完整既能用于企業(yè)內(nèi)部培訓(xùn)也可作為財務(wù)人員自學(xué)的操作手冊幫助提升現(xiàn)金管理的規(guī)范性和準(zhǔn)確性。1. 現(xiàn)金模塊培訓(xùn)手冊在講什么從“界面截圖”到“科目表與銀行賬戶映射”“ORACLE財務(wù)管理系統(tǒng)現(xiàn)金模塊培訓(xùn)手冊.doc”這個文件名經(jīng)常出現(xiàn)在兩類人電腦上一類是剛接手 Oracle EBS 或 Oracle Financials 的出納、總賬會計另一類是準(zhǔn)備給客戶做三天實施培訓(xùn)的顧問?，F(xiàn)金模塊在 Oracle 財務(wù)系統(tǒng)里叫 Cash Management簡稱 CE核心工作無非四件事維護銀行賬戶、錄入收付款、銀行對賬、現(xiàn)金預(yù)測。可多數(shù)人翻完培訓(xùn)手冊才發(fā)現(xiàn)手冊全是界面截圖和點擊路徑真正讓財務(wù)對不上賬的元兇——科目映射、匯率、銀行賬戶綁定往往一句話帶過。下面直接按“先懂表結(jié)構(gòu)、再走流程、最后排坑”的順序把手冊變成一套能照著落地的方法。2. 先搞清三張表再翻手冊現(xiàn)金模塊的科目映射與收付款源頭培訓(xùn)手冊按界面走排錯卻必須按表走。我新接手一套 Oracle 財務(wù)系統(tǒng)時不會先去點菜單而是先弄清楚三張表的關(guān)系銀行賬戶主數(shù)據(jù)、收付款單據(jù)、銀行對賬單行。這三個對象串起來現(xiàn)金模塊的骨架就清楚了。2.1 銀行賬戶綁定現(xiàn)金科目CE_BANK_ACCOUNTS 與 GL_CODE_COMBINATIONSOracle 財務(wù)系統(tǒng)里的“現(xiàn)金”不是一個簡單科目它是會計科目彈性域Accounting Flexfield里的一組段組合每個組合落在 GL_CODE_COMBINATIONS 表用 code_combination_id 唯一標(biāo)識。銀行賬戶主數(shù)據(jù)落在 CE_BANK_ACCOUNTS一張銀行卡還會在 CE_BANK_ACCT_USES_ALL 里登記多條用途比如收款項、付款項、內(nèi)部轉(zhuǎn)賬。最關(guān)鍵的一條用途是 GL Account它決定了這個賬戶的錢過賬后進總賬的哪個現(xiàn)金科目。我一般接手環(huán)境的第一件事就是跑一遍銀行賬戶與現(xiàn)金科目映射查詢把結(jié)果導(dǎo)成 Excel 發(fā)給財務(wù)確認。語句如下SELECT ba.bank_account_name, ba.bank_account_num, bu.acct_use_type, gcc.segment1 || - || gcc.segment2 || - || gcc.segment3 AS gl_account FROM ce_bank_accounts ba, ce_bank_acct_uses_all bu, gl_code_combinations gcc WHERE ba.bank_account_id bu.bank_account_id AND bu.gl_account_code gcc.code_combination_id AND ba.bank_account_id :bank_account_id;這段 SQL 的關(guān)鍵在兩張表的關(guān)聯(lián)CE_BANK_ACCT_USES_ALL 通過 bank_account_id 找到賬戶通過 gl_account_code 找到總賬科目組合。gcc.segment1 到 segment3 是我這個環(huán)境的科目段結(jié)構(gòu)你們環(huán)境的段數(shù)可能更多或更少改一下拼接數(shù)量即可。acct_use_type 的枚舉以你們系統(tǒng)值列表為準(zhǔn)常見的是收款、付款兩類用途都各占一條只有一條往往說明賬戶沒配全。跑出來的結(jié)果如果發(fā)現(xiàn)兩個賬戶映射到同一個現(xiàn)金科目而財務(wù)又說應(yīng)該分開就要回去改用途配置。2.2 收付款單從哪里來AR_RECEIPTS_ALL 與 AP_CHECKS_ALL新手最容易混淆的一點Oracle 財務(wù)管理系統(tǒng)里收款單不一定在現(xiàn)金模塊錄而是在 AR應(yīng)收模塊的收款工作臺錄付款單在 AP應(yīng)付模塊錄。CE 現(xiàn)金模塊管的是銀行賬戶里的真實資金流動。所以排查收付款問題時AR_RECEIPTS_ALL 和 AP_CHECKS_ALL 才是第一落點。AR_RECEIPTS_ALL 是收款頭表記錄了收款編號、日期、金額、狀態(tài)、銀行賬戶。我用下面這條 SQL 查最近三十天的收款核對“總金額對不對”和“狀態(tài)有沒有異?！?。SELECT r.receipt_number, r.receipt_date, r.amount, r.status, ba.bank_account_name FROM ar_receipts_all r, ce_bank_accounts ba WHERE r.bank_account_id ba.bank_account_id AND r.receipt_date BETWEEN TRUNC(SYSDATE - 30) AND TRUNC(SYSDATE) AND r.amount 0;TRUNC(SYSDATE - 30) 是取三十天前零點避免把當(dāng)天未完成的行也算進區(qū)間。r.amount 0 是為了排除負數(shù)沖銷如果你要查退款把條件反過來即可。status 字段在不同版本有不同枚舉值常見的有已確認、已核銷、已過賬記不住沒關(guān)系先 SELECT DISTINCT status 看一眼有哪些值再對號入座。付款側(cè)看 AP_CHECKS_ALL支票和電匯都在這張表里?？梢圆橐欢螘r間內(nèi)所有付款SELECT c.check_number, c.check_date, c.amount, c.status FROM ap_checks_all c WHERE c.check_date TRUNC(SYSDATE - 30) ORDER BY c.check_date;這里沒有關(guān)聯(lián) CE_BANK_ACCOUNTS因為 AP_CHECKS_ALL 里銀行賬戶名稱直接冗余了一份省一次連接。status 如果出現(xiàn)作廢VOIDED而銀行已扣款那就是典型的“系統(tǒng)外付款、銀行已兌”要立刻找財務(wù)確認。2.3 現(xiàn)金預(yù)測的數(shù)據(jù)底子別直接查底表先看收付款計劃培訓(xùn)手冊往往把現(xiàn)金預(yù)測放在最后幾頁寫得非常單薄。其實現(xiàn)金預(yù)測不是銀行實時余額而是按計劃預(yù)測未來一段時間現(xiàn)金流入流出數(shù)據(jù)源是應(yīng)收收款計劃、應(yīng)付付款計劃、手工預(yù)測三類。很多顧問喜歡直接查 CE 的預(yù)測底表我不建議這樣因為預(yù)測表在不同版本差異太大字段名能給你繞暈。先把應(yīng)付發(fā)票的付款計劃拿出來是最快能用的方案SELECT i.invoice_num, s.due_date, s.amount_remaining FROM ap_payment_schedules_all s, ap_invoices_all i WHERE s.invoice_id i.invoice_id AND s.due_date BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE 30) ORDER BY s.due_date;邏輯是AP_PAYMENT_SCHEDULES_ALL 把一張發(fā)票拆成多期付款計劃amount_remaining 是還沒付完的金額。這個結(jié)果集合起來就是未來三十天應(yīng)付側(cè)的現(xiàn)金流預(yù)測。應(yīng)收側(cè)可以拿 AR_RECEIPTS_ALL 里狀態(tài)為計劃但不帶收款日的行做類似加工。手工預(yù)測則是把系統(tǒng)外的大額收支補進去比如老板口頭承諾的一筆投資款。2.4 一張表看懂現(xiàn)金模塊數(shù)據(jù)流把上面內(nèi)容壓縮成一張表適合貼在工位旁業(yè)務(wù)動作來源模塊核心表是否直接進總賬收款A(yù)R 應(yīng)收AR_RECEIPTS_ALL過賬后進 GL_JE_LINES付款A(yù)P 應(yīng)付AP_CHECKS_ALL過賬后進 GL_JE_LINES銀行對賬CE 現(xiàn)金CE_STATEMENT_LINES不進總賬只出調(diào)節(jié)表現(xiàn)金預(yù)測CE 現(xiàn)金CE 預(yù)測相關(guān)表版本差異大不進總賬重點理解銀行對賬那行對賬結(jié)果是生成銀行余額調(diào)節(jié)表不生成會計憑證。未達賬項不會自動變成總賬分錄要靠財務(wù)在總賬里做調(diào)節(jié)科目。這個認知能幫你少走很多彎路。3. 把手冊當(dāng)操作手冊用跑通一筆收款從銀行賬戶到總賬手冊的作用是告訴你“跟著點哪個菜單能完成操作”但如果只點菜單不理解后臺出了錯就得抓瞎。這一章按最小業(yè)務(wù)閉環(huán)走一遍定義賬戶、錄收款、對賬、過賬。3.1 先建銀行賬戶再做任何收款分支結(jié)構(gòu)、賬戶用途、現(xiàn)金科目很多公司上線后急著錄收款結(jié)果發(fā)現(xiàn)收款工作臺里值列表選不到銀行賬戶。原因幾乎都是銀行賬戶主數(shù)據(jù)沒建完整。正確順序是定義銀行Bank輸入銀行名稱、代碼。在該銀行下定義分支機構(gòu)Branch。在分支機構(gòu)下定義銀行賬戶填賬號、幣種、描述。為這個賬戶添加賬戶用途至少包含收款用途和付款用途。指定該用途對應(yīng)的總賬現(xiàn)金科目。這個流程里最容易漏的是第 4 步。一個賬戶如果只有收款項用途AP 付款時就選不到它如果用途沒指定 GL 科目收款確認后創(chuàng)建會計分錄會直接報錯。測試環(huán)境里想快速驗證可以建一個名字帶 TEST 的專用賬戶走完整流程再清理。生產(chǎn)環(huán)境不要直接往 CE_BANK_ACCT_USES_ALL 里插數(shù)據(jù)用界面維護最穩(wěn)系統(tǒng)會幫你做校驗。3.2 小額收款手工錄入收款工作臺四個必填項日常業(yè)務(wù)里小額現(xiàn)金收款、客戶支票收款常見做法是在 AR 收款工作臺手工錄入。界面字段很多真正必填的核心就四個收款來源現(xiàn)金、支票、銀行轉(zhuǎn)賬、收款日期、客戶、核銷發(fā)票。保存后收款單進入“已確認”狀態(tài)這時還沒產(chǎn)生總賬分錄要再點一次“創(chuàng)建會計分錄”。我經(jīng)常用下面這條 SQL 幫出納核對“今天到底錄了多少收款”。它把當(dāng)天的收款按操作員分組匯總誰錄的、錄了幾筆、總金額多少一目了然。SELECT u.user_name, COUNT(r.receipt_id) AS receipt_count, SUM(r.amount) AS total_amount FROM ar_receipts_all r, fnd_user u WHERE r.created_by u.user_id AND r.creation_date TRUNC(SYSDATE) GROUP BY u.user_name ORDER BY total_amount DESC;邏輯說明created_by 是操作員用戶 ID關(guān)聯(lián) FND_USER 拿出來名字。SUM(r.amount) 查的就是當(dāng)天收款總金額。如果你發(fā)現(xiàn)出納錄了五筆但 SUM 金額和銀行回單對不上優(yōu)先查有沒有一筆收款核銷金額填錯導(dǎo)致余款掛在了未核銷那邊。3.3 銀行對賬單導(dǎo)入與匹配手工對賬和自動對賬怎么選銀行對賬是現(xiàn)金模塊最花時間的環(huán)節(jié)。標(biāo)準(zhǔn)動作是銀行給到電子對賬單在 CE 職責(zé)下導(dǎo)入把銀行流水行導(dǎo)入 CE_STATEMENT_LINES然后和 AR_RECEIPTS_ALL、AP_CHECKS_ALL 里的單據(jù)做匹配。匹配方式有兩種維度手工匹配自動匹配適用行數(shù)幾十行以內(nèi)幾百行以上匹配依據(jù)日期、金額、參考號逐筆核對系統(tǒng)規(guī)則自動執(zhí)行出錯的概率低但慢高規(guī)則太寬會錯配對參考號的要求不強制強制否則容易把多筆同金額錯配項目剛上線時建議前三個月用手工匹配。原因很簡單業(yè)務(wù)還沒形成統(tǒng)一的收付款參考號規(guī)則自動匹配規(guī)則再嚴格也白搭。等供應(yīng)商、客戶回單里都有穩(wěn)定的單據(jù)編號再開自動匹配。3.4 生成會計憑證并過賬讓現(xiàn)金進入總賬收款單確認并核銷后點“創(chuàng)建會計分錄”會在 GL_JE_HEADERS 和 GL_JE_LINES 里生成憑證。這個動作可以在收款工作臺逐筆做也可以跑標(biāo)準(zhǔn)請求集中做。過賬則要到總賬職責(zé)的“日記賬-過賬”里執(zhí)行。驗證是否過賬成功我一般直接查現(xiàn)金科目的借貨發(fā)生額SELECT gcc.segment1 AS cash_account, SUM(gjl.accounted_dr) AS total_dr, SUM(gjl.accounted_cr) AS total_cr FROM gl_je_lines gjl, gl_je_headers gjh, gl_code_combinations gcc WHERE gjl.je_header_id gjh.je_header_id AND gjl.code_combination_id gcc.code_combination_id AND gcc.segment1 1002 -- 改成你的現(xiàn)金科目段值 AND gjh.period_name 2025-02 -- 改成當(dāng)前會計期間 GROUP BY gcc.segment1;首要參數(shù)是 period_name 和現(xiàn)金科目段值兩個都要換成你環(huán)境里的真實值。accounted_dr 和 accounted_cr 是未過賬已發(fā)生額過賬后不會清掉它們會變成余額表里的發(fā)生數(shù)。如果你發(fā)現(xiàn)查詢結(jié)果和銀行賬戶流水對不上先別急著懷疑 SQL回去看收款單狀態(tài)是不是還停在已確認未創(chuàng)建分錄。4. 現(xiàn)金模塊常見問題與避坑4 個參數(shù)和 3 類翻車現(xiàn)場現(xiàn)金模塊平時看著安靜一到月末結(jié)賬就炸。下面幾個問題是我在多個項目里反復(fù)見過的全部按“現(xiàn)象、原因、解決”寫清楚。4.1 匯率類型沒設(shè)對外幣收款金額回車就變現(xiàn)象錄外幣收款單輸入原幣金額后系統(tǒng)自動算出的本幣金額和業(yè)務(wù)員提供的金額差一截總賬現(xiàn)金科目平不了。原因收款工作臺默認的匯率類型不是業(yè)務(wù)實際約定類型。Oracle 系統(tǒng)里匯率類型有很多種系統(tǒng)配置文件里設(shè)了一個全局默認值而單據(jù)上的匯率日期又默認取單據(jù)日期兩邊沒對上折算金額自然錯。解決在系統(tǒng)管理員職責(zé)下打開“系統(tǒng)配置文件”搜索收款匯率相關(guān)配置項改成業(yè)務(wù)簽約時使用的匯率類型同時要求業(yè)務(wù)在收款單界面上把匯率類型改為手工指定別讓系統(tǒng)自動抓取。查配置值用這條 SQLSELECT po.profile_option_name, pv.profile_option_value, pv.level_id FROM fnd_profile_options po, fnd_profile_option_values pv WHERE po.profile_option_id pv.profile_option_id AND po.profile_option_name LIKE %RECEIPT%;level_id 表示這個配置在哪一層生效比如應(yīng)用層、職責(zé)層、用戶層。見到同一配置項有多個值別慌越往下層的優(yōu)先級越高這就是“我改了但別人沒變”的解釋。4.2 賬戶用途沒加“付款”AP 付款時選不到銀行賬戶現(xiàn)象應(yīng)付會計錄付款單銀行賬戶的值列表里看不到剛建好的賬戶以為是權(quán)限問題。原因賬戶用途沒登記付款類。CE_BANK_ACCT_USES_ALL 里只有收款用途沒有付款用途AP 模塊自然不認。解決回銀行賬戶維護界面加一條付款用途。如果界面一時找不到入口可以先備份再手工補CREATE TABLE ce_bank_acct_uses_all_bak_202502 AS SELECT * FROM ce_bank_acct_uses_all WHERE bank_account_id 1001; INSERT INTO ce_bank_acct_uses_all (bank_account_id, acct_use_type, gl_account_code, start_date, end_date) VALUES (1001, PAYMENT, 123456, TRUNC(SYSDATE), NULL);注意1001 是示例賬戶 ID123456 是示例科目組合 ID都要換成真實值。acct_use_type 的枚舉不要自己編先執(zhí)行 SELECT DISTINCT acct_use_type FROM ce_bank_acct_uses_all 看看已有的值。最后一條鐵律生產(chǎn)環(huán)境別直接 INSERT走界面。4.3 自動對賬規(guī)則太寬兩筆同金額流水被一次性匹配現(xiàn)象銀行對賬單導(dǎo)入后同一天兩筆金額相同的收款系統(tǒng)把兩筆銀行流水都匹配到了第一張收款單上第二張收款單還是未核銷。原因自動匹配規(guī)則只按“同一天、同金額”匹配沒有要求參考號唯一。這類匹配邏輯在后臺是一個存儲過程驅(qū)動的規(guī)則窗口里的選項就是它的入?yún)⒃O(shè)置太寬就出現(xiàn)錯配。解決打開自動匹配規(guī)則開啟“按參考號匹配”關(guān)閉“允許部分金額匹配”。如果已經(jīng)錯配先在銀行對賬單界面撤銷原匹配再重新執(zhí)行。抽查有沒有未匹配流水用這條 SQLSELECT sl.trx_number, sl.amount, sl.status FROM ce_statement_lines sl WHERE sl.status U AND sl.creation_date TRUNC(SYSDATE - 7);status 用 U 只適用部分版本有的環(huán)境是 OPEN。跑之前先 DESC CE_STATEMENT_LINES確認你環(huán)境里的狀態(tài)值再查。這里的核心啟發(fā)是自動對賬不是把規(guī)則設(shè)嚴就完事先看參考號數(shù)據(jù)質(zhì)量再決定規(guī)則。4.4 現(xiàn)金預(yù)測少一大截都是預(yù)測來源沒啟用現(xiàn)象現(xiàn)金預(yù)測報表只顯示手工錄的幾筆大額收支應(yīng)收預(yù)測、應(yīng)付預(yù)測完全沒出現(xiàn)。原因預(yù)測來源設(shè)置里只勾了“手工”沒有啟用應(yīng)收收款計劃、應(yīng)付付款計劃。CE 的預(yù)測來源是按優(yōu)先級取數(shù)的來源沒啟用等于沒數(shù)據(jù)。解決在現(xiàn)金預(yù)測工作臺打開預(yù)測來源配置添加 AR 收款計劃和 AP 付款計劃。我一般按下面這張表設(shè)權(quán)重來源類型使用場景權(quán)重建議AR 收款計劃客戶回款預(yù)測中AP 付款計劃供應(yīng)商付款預(yù)測中手工預(yù)測系統(tǒng)外大額收支補充高但需人維護權(quán)重影響的是同一預(yù)測區(qū)間內(nèi)多來源沖突時的排序不是金額計算的加權(quán)。這個區(qū)分很多人搞混。4.5 月末結(jié)賬時長期未達賬項不平先查這幾張表現(xiàn)象銀行余額調(diào)節(jié)表里有一筆老賬連續(xù)三個月沒動結(jié)賬組每次都要寫說明。原因收款或付款已經(jīng)做了賬務(wù)處理但銀行對賬單里始終沒有對應(yīng)流水或者對賬單行導(dǎo)入日期跨了會計期間總賬銀行科目余額平了調(diào)節(jié)表卻不平。解決先把整個期間所有未匹配流水查出來別只看近幾天SELECT sh.statement_number, sl.line_amount, sl.status FROM ce_statement_headers sh, ce_statement_lines sl WHERE sh.statement_header_id sl.statement_header_id AND sl.status IN (UNMATCHED, OPEN) ORDER BY sh.statement_number;排查順序是先看這筆流水是否真的在銀行發(fā)生過再問財務(wù)是否走了內(nèi)部過渡科目。對不上的老賬最怕的就是財務(wù)為了平賬直接做一筆總賬調(diào)整結(jié)果下個月又冒出來。正確做法是單獨掛到未達賬項科目逐筆跟蹤核銷。5. 把培訓(xùn)手冊 doc 變成能落地的知識庫角色、腳本與檢查表拿到一本現(xiàn)成的現(xiàn)金模塊培訓(xùn)手冊 doc直接分發(fā)出去基本沒人看因為里面百分之八十的內(nèi)容和某個人的日常操作無關(guān)。真正有用的做法是把它拆成按角色組織的小冊子再配合自動化檢查腳本。5.1 按角色-路徑-例外重寫而不是保留整本 doc我一般把手冊拆成三份出納版、總賬會計版、系統(tǒng)管理員版。每份只保留“這個角色必須會的路徑”和“例外怎么處理”其他菜單一概不寫。組織結(jié)構(gòu)參考這張表角色必會路徑例外處理出納收款工作臺、銀行對賬單導(dǎo)入、手工匹配退票、錯賬沖正、客戶重打款總賬會計期間開關(guān)、日記賬過賬、調(diào)節(jié)表核對匯率錯調(diào)、未達賬長期掛賬系統(tǒng)管理員銀行賬戶定義、配置文件設(shè)置、標(biāo)準(zhǔn)請求接口報錯、值列表缺失、權(quán)限問題重寫時有一個原則界面上能看到的字段名要寫背后的表名也要寫。比如“收款來源”旁邊標(biāo)個 AR_RECEIPTS_ALL.source。這樣出納操作遇到問題顧問能直接按表名下 SQL不用再對著截圖猜來猜去。5.2 用測試環(huán)境跑最小閉環(huán)一個月度結(jié)賬演練腳本文檔定稿前一定要在測試環(huán)境把“收款、對賬、過賬”最小閉環(huán)跑通。每個月底結(jié)賬前也可以跑一遍下面的演練腳本檢查當(dāng)前環(huán)境有沒有異常數(shù)據(jù)SET PAGESIZE 100 SET LINESIZE 200 SELECT 未核銷收款 AS check_item, COUNT(*) AS cnt FROM ar_receipts_all WHERE status U UNION ALL SELECT 未過賬付款, COUNT(*) FROM ap_checks_all WHERE status NOT IN (POSTED, VOIDED);UNION ALL 把兩個檢查項拼成一張兩行結(jié)果的表一眼就能掃完。狀態(tài)值按你環(huán)境的枚舉調(diào)整測試環(huán)境正常情況輸出兩個 0。如果輸出非 0先別急著清數(shù)據(jù)把明細查出來人工核對很多“異?！逼鋵嵤菢I(yè)務(wù)還沒走到下一步。5.3 把高頻問題轉(zhuǎn)成值班腳本每天自動盯一遍人工每天去跑 SQL 不現(xiàn)實。我習(xí)慣把 5.2 的腳本擴展后放進 shell 腳本交給 cron 每天跑有異常時把結(jié)果輸出到固定日志文件。腳本長這樣#!/bin/bash export ORACLE_SIDPROD export ORACLE_HOME/u01/app/oracle/product/12.2 ORA_USERapps ORA_PWD$(cat ~/.ora_pwd) # 密碼單獨存文件別寫死在腳本里 sqlplus -s ${ORA_USER}/${ORA_PWD}${ORACLE_SID} EOF WHENEVER SQLERROR EXIT 1 SET PAGESIZE 100 SET LINESIZE 200 SELECT 未核銷收款 AS check_item, COUNT(*) AS cnt FROM ar_receipts_all WHERE status U / EOFORACLE_SID 和 ORACLE_HOME 按實際服務(wù)器改。密碼從 ~/.ora_pwd 讀取權(quán)限設(shè)為 600比硬編碼在腳本里安全得多。如果團隊用的是 EBS 并發(fā)管理器也可以把這段 SQL 掛成一個標(biāo)準(zhǔn)請求按頻率調(diào)度不一定要走 cron。值班盯數(shù)據(jù)的意義是問題當(dāng)天發(fā)現(xiàn)當(dāng)天處理而不是月底結(jié)賬時才發(fā)現(xiàn)一個月都在錯。5.4 文檔版本責(zé)任到人doc 只是起點培訓(xùn)手冊 doc 最大的問題是靜態(tài)。財務(wù)系統(tǒng)隔幾個月調(diào)一次配置文件、加一個銀行賬戶、改一次匯率規(guī)則手冊沒更新就成了害人文檔。我的習(xí)慣是doc 只作為歷史存檔另建一份在線知識庫作為唯一引用源每章開頭寫清最后驗證日期、驗證人和對應(yīng)系統(tǒng)版本。每次版本升級或配置變更由系統(tǒng)管理員重跑一遍關(guān)鍵流程截圖更新而不是等出問題再補。手冊的價值在維護不在初見。6. 驗證現(xiàn)金模塊是否順手的 5 條體檢 SQL月底結(jié)賬前我會花十分鐘跑下面五條 SQL。不需要專門報表工具SQL*Plus 或者 PL/SQL Developer 都行。每一條都對應(yīng)一類高頻事故。-- 1. 銀行賬戶缺現(xiàn)金科目映射會導(dǎo)致過賬報錯 SELECT ba.bank_account_name FROM ce_bank_accounts ba LEFT JOIN ce_bank_acct_uses_all bu ON ba.bank_account_id bu.bank_account_id LEFT JOIN gl_code_combinations gcc ON bu.gl_account_code gcc.code_combination_id WHERE gcc.code_combination_id IS NULL; -- 2. 超過 30 天仍未核銷的收款通常是漏了對賬 SELECT receipt_number, receipt_date, amount FROM ar_receipts_all WHERE status U AND receipt_date TRUNC(SYSDATE) - 30; -- 3. 長期未匹配的銀行對賬行 SELECT statement_header_id, line_amount, status FROM ce_statement_lines WHERE status UNMATCHED AND creation_date TRUNC(SYSDATE) - 30; -- 4. 付款審批卡住的單據(jù)狀態(tài)碼按環(huán)境調(diào)整 SELECT check_number, check_date, amount, status FROM ap_checks_all WHERE status PP AND check_date TRUNC(SYSDATE) - 3; -- 5. 現(xiàn)金預(yù)測來源被停用 SELECT cash_forecast_name, available_flag FROM ce_cash_flows WHERE available_flag N;第一條查出來若有銀行賬戶沒綁定科目過賬當(dāng)天必報錯第二條抓的是忘記做核銷的收款金額往往不小第三條是銀行調(diào)節(jié)表不平的源頭第四條看審批流有沒有卡單第五條檢查預(yù)測來源有沒有被誤停用。跑之前注意狀態(tài)值在不同版本有差異先 DESC 表確認枚舉再執(zhí)行。我自己的習(xí)慣是每月倒數(shù)第二個工作日跑一遍這五條把結(jié)果貼到結(jié)賬檢查單里該處理的當(dāng)天處理?，F(xiàn)金模塊的坑大多不是高深技術(shù)而是小參數(shù)、小狀態(tài)沒盯住。提前十分鐘查一遍比月底加班對賬劃算得多。希望幫到你。本文還有配套的精品資源點擊獲取