简介这是一份面向Oracle财务管理系统实施顾问、财务IT运维及企业财务人员的专项培训资料重点讲解现金模块CE中收款、付款、银行对账与调节等核心业务帮助读者系统掌握企业现金流管理流程。资源包为单个doc文档共1个文件压缩后约1.74MB内容为可编辑的Word版106页完整手册便于查阅标记和二次整理。目前已有91人学习下载。手册编排体系化设有文档控制页涵盖多个培训单元从现金模块概述及其与应收应付、总账、固定资产等模块的关系切入逐步展开系统参数设置、银行事务代码定义、银行对账单导入与手工输入、对账单调节、差错处理、人工结清以及过账与查询、现金预测等关键环节每个单元均配有培训目标和Lesson小节步骤说明完整既能用于企业内部培训也可作为财务人员自学的操作手册帮助提升现金管理的规范性和准确性。1. 现金模块培训手册在讲什么从“界面截图”到“科目表与银行账户映射”“ORACLE财务管理系统现金模块培训手册.doc”这个文件名经常出现在两类人电脑上一类是刚接手 Oracle EBS 或 Oracle Financials 的出纳、总账会计另一类是准备给客户做三天实施培训的顾问。现金模块在 Oracle 财务系统里叫 Cash Management简称 CE核心工作无非四件事维护银行账户、录入收付款、银行对账、现金预测。可多数人翻完培训手册才发现手册全是界面截图和点击路径真正让财务对不上账的元凶——科目映射、汇率、银行账户绑定往往一句话带过。下面直接按“先懂表结构、再走流程、最后排坑”的顺序把手册变成一套能照着落地的方法。2. 先搞清三张表再翻手册现金模块的科目映射与收付款源头培训手册按界面走排错却必须按表走。我新接手一套 Oracle 财务系统时不会先去点菜单而是先弄清楚三张表的关系银行账户主数据、收付款单据、银行对账单行。这三个对象串起来现金模块的骨架就清楚了。2.1 银行账户绑定现金科目CE_BANK_ACCOUNTS 与 GL_CODE_COMBINATIONSOracle 财务系统里的“现金”不是一个简单科目它是会计科目弹性域Accounting Flexfield里的一组段组合每个组合落在 GL_CODE_COMBINATIONS 表用 code_combination_id 唯一标识。银行账户主数据落在 CE_BANK_ACCOUNTS一张银行卡还会在 CE_BANK_ACCT_USES_ALL 里登记多条用途比如收款项、付款项、内部转账。最关键的一条用途是 GL Account它决定了这个账户的钱过账后进总账的哪个现金科目。我一般接手环境的第一件事就是跑一遍银行账户与现金科目映射查询把结果导成 Excel 发给财务确认。语句如下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 的关键在两张表的关联CE_BANK_ACCT_USES_ALL 通过 bank_account_id 找到账户通过 gl_account_code 找到总账科目组合。gcc.segment1 到 segment3 是我这个环境的科目段结构你们环境的段数可能更多或更少改一下拼接数量即可。acct_use_type 的枚举以你们系统值列表为准常见的是收款、付款两类用途都各占一条只有一条往往说明账户没配全。跑出来的结果如果发现两个账户映射到同一个现金科目而财务又说应该分开就要回去改用途配置。2.2 收付款单从哪里来AR_RECEIPTS_ALL 与 AP_CHECKS_ALL新手最容易混淆的一点Oracle 财务管理系统里收款单不一定在现金模块录而是在 AR应收模块的收款工作台录付款单在 AP应付模块录。CE 现金模块管的是银行账户里的真实资金流动。所以排查收付款问题时AR_RECEIPTS_ALL 和 AP_CHECKS_ALL 才是第一落点。AR_RECEIPTS_ALL 是收款头表记录了收款编号、日期、金额、状态、银行账户。我用下面这条 SQL 查最近三十天的收款核对“总金额对不对”和“状态有没有异常”。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) 是取三十天前零点避免把当天未完成的行也算进区间。r.amount 0 是为了排除负数冲销如果你要查退款把条件反过来即可。status 字段在不同版本有不同枚举值常见的有已确认、已核销、已过账记不住没关系先 SELECT DISTINCT status 看一眼有哪些值再对号入座。付款侧看 AP_CHECKS_ALL支票和电汇都在这张表里。可以查一段时间内所有付款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;这里没有关联 CE_BANK_ACCOUNTS因为 AP_CHECKS_ALL 里银行账户名称直接冗余了一份省一次连接。status 如果出现作废VOIDED而银行已扣款那就是典型的“系统外付款、银行已兑”要立刻找财务确认。2.3 现金预测的数据底子别直接查底表先看收付款计划培训手册往往把现金预测放在最后几页写得非常单薄。其实现金预测不是银行实时余额而是按计划预测未来一段时间现金流入流出数据源是应收收款计划、应付付款计划、手工预测三类。很多顾问喜欢直接查 CE 的预测底表我不建议这样因为预测表在不同版本差异太大字段名能给你绕晕。先把应付发票的付款计划拿出来是最快能用的方案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 把一张发票拆成多期付款计划amount_remaining 是还没付完的金额。这个结果集合起来就是未来三十天应付侧的现金流预测。应收侧可以拿 AR_RECEIPTS_ALL 里状态为计划但不带收款日的行做类似加工。手工预测则是把系统外的大额收支补进去比如老板口头承诺的一笔投资款。2.4 一张表看懂现金模块数据流把上面内容压缩成一张表适合贴在工位旁业务动作来源模块核心表是否直接进总账收款AR 应收AR_RECEIPTS_ALL过账后进 GL_JE_LINES付款AP 应付AP_CHECKS_ALL过账后进 GL_JE_LINES银行对账CE 现金CE_STATEMENT_LINES不进总账只出调节表现金预测CE 现金CE 预测相关表版本差异大不进总账重点理解银行对账那行对账结果是生成银行余额调节表不生成会计凭证。未达账项不会自动变成总账分录要靠财务在总账里做调节科目。这个认知能帮你少走很多弯路。3. 把手册当操作手册用跑通一笔收款从银行账户到总账手册的作用是告诉你“跟着点哪个菜单能完成操作”但如果只点菜单不理解后台出了错就得抓瞎。这一章按最小业务闭环走一遍定义账户、录收款、对账、过账。3.1 先建银行账户再做任何收款分支结构、账户用途、现金科目很多公司上线后急着录收款结果发现收款工作台里值列表选不到银行账户。原因几乎都是银行账户主数据没建完整。正确顺序是定义银行Bank输入银行名称、代码。在该银行下定义分支机构Branch。在分支机构下定义银行账户填账号、币种、描述。为这个账户添加账户用途至少包含收款用途和付款用途。指定该用途对应的总账现金科目。这个流程里最容易漏的是第 4 步。一个账户如果只有收款项用途AP 付款时就选不到它如果用途没指定 GL 科目收款确认后创建会计分录会直接报错。测试环境里想快速验证可以建一个名字带 TEST 的专用账户走完整流程再清理。生产环境不要直接往 CE_BANK_ACCT_USES_ALL 里插数据用界面维护最稳系统会帮你做校验。3.2 小额收款手工录入收款工作台四个必填项日常业务里小额现金收款、客户支票收款常见做法是在 AR 收款工作台手工录入。界面字段很多真正必填的核心就四个收款来源现金、支票、银行转账、收款日期、客户、核销发票。保存后收款单进入“已确认”状态这时还没产生总账分录要再点一次“创建会计分录”。我经常用下面这条 SQL 帮出纳核对“今天到底录了多少收款”。它把当天的收款按操作员分组汇总谁录的、录了几笔、总金额多少一目了然。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关联 FND_USER 拿出来名字。SUM(r.amount) 查的就是当天收款总金额。如果你发现出纳录了五笔但 SUM 金额和银行回单对不上优先查有没有一笔收款核销金额填错导致余款挂在了未核销那边。3.3 银行对账单导入与匹配手工对账和自动对账怎么选银行对账是现金模块最花时间的环节。标准动作是银行给到电子对账单在 CE 职责下导入把银行流水行导入 CE_STATEMENT_LINES然后和 AR_RECEIPTS_ALL、AP_CHECKS_ALL 里的单据做匹配。匹配方式有两种维度手工匹配自动匹配适用行数几十行以内几百行以上匹配依据日期、金额、参考号逐笔核对系统规则自动执行出错的概率低但慢高规则太宽会错配对参考号的要求不强制强制否则容易把多笔同金额错配项目刚上线时建议前三个月用手工匹配。原因很简单业务还没形成统一的收付款参考号规则自动匹配规则再严格也白搭。等供应商、客户回单里都有稳定的单据编号再开自动匹配。3.4 生成会计凭证并过账让现金进入总账收款单确认并核销后点“创建会计分录”会在 GL_JE_HEADERS 和 GL_JE_LINES 里生成凭证。这个动作可以在收款工作台逐笔做也可以跑标准请求集中做。过账则要到总账职责的“日记账-过账”里执行。验证是否过账成功我一般直接查现金科目的借货发生额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 -- 改成你的现金科目段值 AND gjh.period_name 2025-02 -- 改成当前会计期间 GROUP BY gcc.segment1;首要参数是 period_name 和现金科目段值两个都要换成你环境里的真实值。accounted_dr 和 accounted_cr 是未过账已发生额过账后不会清掉它们会变成余额表里的发生数。如果你发现查询结果和银行账户流水对不上先别急着怀疑 SQL回去看收款单状态是不是还停在已确认未创建分录。4. 现金模块常见问题与避坑4 个参数和 3 类翻车现场现金模块平时看着安静一到月末结账就炸。下面几个问题是我在多个项目里反复见过的全部按“现象、原因、解决”写清楚。4.1 汇率类型没设对外币收款金额回车就变现象录外币收款单输入原币金额后系统自动算出的本币金额和业务员提供的金额差一截总账现金科目平不了。原因收款工作台默认的汇率类型不是业务实际约定类型。Oracle 系统里汇率类型有很多种系统配置文件里设了一个全局默认值而单据上的汇率日期又默认取单据日期两边没对上折算金额自然错。解决在系统管理员职责下打开“系统配置文件”搜索收款汇率相关配置项改成业务签约时使用的汇率类型同时要求业务在收款单界面上把汇率类型改为手工指定别让系统自动抓取。查配置值用这条 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 表示这个配置在哪一层生效比如应用层、职责层、用户层。见到同一配置项有多个值别慌越往下层的优先级越高这就是“我改了但别人没变”的解释。4.2 账户用途没加“付款”AP 付款时选不到银行账户现象应付会计录付款单银行账户的值列表里看不到刚建好的账户以为是权限问题。原因账户用途没登记付款类。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 的枚举不要自己编先执行 SELECT DISTINCT acct_use_type FROM ce_bank_acct_uses_all 看看已有的值。最后一条铁律生产环境别直接 INSERT走界面。4.3 自动对账规则太宽两笔同金额流水被一次性匹配现象银行对账单导入后同一天两笔金额相同的收款系统把两笔银行流水都匹配到了第一张收款单上第二张收款单还是未核销。原因自动匹配规则只按“同一天、同金额”匹配没有要求参考号唯一。这类匹配逻辑在后台是一个存储过程驱动的规则窗口里的选项就是它的入参设置太宽就出现错配。解决打开自动匹配规则开启“按参考号匹配”关闭“允许部分金额匹配”。如果已经错配先在银行对账单界面撤销原匹配再重新执行。抽查有没有未匹配流水用这条 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 只适用部分版本有的环境是 OPEN。跑之前先 DESC CE_STATEMENT_LINES确认你环境里的状态值再查。这里的核心启发是自动对账不是把规则设严就完事先看参考号数据质量再决定规则。4.4 现金预测少一大截都是预测来源没启用现象现金预测报表只显示手工录的几笔大额收支应收预测、应付预测完全没出现。原因预测来源设置里只勾了“手工”没有启用应收收款计划、应付付款计划。CE 的预测来源是按优先级取数的来源没启用等于没数据。解决在现金预测工作台打开预测来源配置添加 AR 收款计划和 AP 付款计划。我一般按下面这张表设权重来源类型使用场景权重建议AR 收款计划客户回款预测中AP 付款计划供应商付款预测中手工预测系统外大额收支补充高但需人维护权重影响的是同一预测区间内多来源冲突时的排序不是金额计算的加权。这个区分很多人搞混。4.5 月末结账时长期未达账项不平先查这几张表现象银行余额调节表里有一笔老账连续三个月没动结账组每次都要写说明。原因收款或付款已经做了账务处理但银行对账单里始终没有对应流水或者对账单行导入日期跨了会计期间总账银行科目余额平了调节表却不平。解决先把整个期间所有未匹配流水查出来别只看近几天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;排查顺序是先看这笔流水是否真的在银行发生过再问财务是否走了内部过渡科目。对不上的老账最怕的就是财务为了平账直接做一笔总账调整结果下个月又冒出来。正确做法是单独挂到未达账项科目逐笔跟踪核销。5. 把培训手册 doc 变成能落地的知识库角色、脚本与检查表拿到一本现成的现金模块培训手册 doc直接分发出去基本没人看因为里面百分之八十的内容和某个人的日常操作无关。真正有用的做法是把它拆成按角色组织的小册子再配合自动化检查脚本。5.1 按角色-路径-例外重写而不是保留整本 doc我一般把手册拆成三份出纳版、总账会计版、系统管理员版。每份只保留“这个角色必须会的路径”和“例外怎么处理”其他菜单一概不写。组织结构参考这张表角色必会路径例外处理出纳收款工作台、银行对账单导入、手工匹配退票、错账冲正、客户重打款总账会计期间开关、日记账过账、调节表核对汇率错调、未达账长期挂账系统管理员银行账户定义、配置文件设置、标准请求接口报错、值列表缺失、权限问题重写时有一个原则界面上能看到的字段名要写背后的表名也要写。比如“收款来源”旁边标个 AR_RECEIPTS_ALL.source。这样出纳操作遇到问题顾问能直接按表名下 SQL不用再对着截图猜来猜去。5.2 用测试环境跑最小闭环一个月度结账演练脚本文档定稿前一定要在测试环境把“收款、对账、过账”最小闭环跑通。每个月底结账前也可以跑一遍下面的演练脚本检查当前环境有没有异常数据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 把两个检查项拼成一张两行结果的表一眼就能扫完。状态值按你环境的枚举调整测试环境正常情况输出两个 0。如果输出非 0先别急着清数据把明细查出来人工核对很多“异常”其实是业务还没走到下一步。5.3 把高频问题转成值班脚本每天自动盯一遍人工每天去跑 SQL 不现实。我习惯把 5.2 的脚本扩展后放进 shell 脚本交给 cron 每天跑有异常时把结果输出到固定日志文件。脚本长这样#!/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 按实际服务器改。密码从 ~/.ora_pwd 读取权限设为 600比硬编码在脚本里安全得多。如果团队用的是 EBS 并发管理器也可以把这段 SQL 挂成一个标准请求按频率调度不一定要走 cron。值班盯数据的意义是问题当天发现当天处理而不是月底结账时才发现一个月都在错。5.4 文档版本责任到人doc 只是起点培训手册 doc 最大的问题是静态。财务系统隔几个月调一次配置文件、加一个银行账户、改一次汇率规则手册没更新就成了害人文档。我的习惯是doc 只作为历史存档另建一份在线知识库作为唯一引用源每章开头写清最后验证日期、验证人和对应系统版本。每次版本升级或配置变更由系统管理员重跑一遍关键流程截图更新而不是等出问题再补。手册的价值在维护不在初见。6. 验证现金模块是否顺手的 5 条体检 SQL月底结账前我会花十分钟跑下面五条 SQL。不需要专门报表工具SQL*Plus 或者 PL/SQL Developer 都行。每一条都对应一类高频事故。-- 1. 银行账户缺现金科目映射会导致过账报错 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. 付款审批卡住的单据状态码按环境调整 SELECT check_number, check_date, amount, status FROM ap_checks_all WHERE status PP AND check_date TRUNC(SYSDATE) - 3; -- 5. 现金预测来源被停用 SELECT cash_forecast_name, available_flag FROM ce_cash_flows WHERE available_flag N;第一条查出来若有银行账户没绑定科目过账当天必报错第二条抓的是忘记做核销的收款金额往往不小第三条是银行调节表不平的源头第四条看审批流有没有卡单第五条检查预测来源有没有被误停用。跑之前注意状态值在不同版本有差异先 DESC 表确认枚举再执行。我自己的习惯是每月倒数第二个工作日跑一遍这五条把结果贴到结账检查单里该处理的当天处理。现金模块的坑大多不是高深技术而是小参数、小状态没盯住。提前十分钟查一遍比月底加班对账划算得多。希望帮到你。本文还有配套的精品资源点击获取