简介：这是一份面向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_COMBINATIONS
Oracle 财务系统里的“现金”不是一个简单科目，它是会计科目弹性域（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 系统里汇率类型有很多种，系统配置文件里设了一个全局默认值，而单据上的汇率日期又默认取单据日期，两边没对上，折算金额自然错。
解决：在系统管理员职责下打开“系统配置文件”，搜索收款汇率相关配置项，改成业务签约时使用的汇率类型；同时要求业务在收款单界面上把汇率类型改为手工指定，别让系统自动抓取。查配置值用这条 SQL：
SELECT 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 是示例账户 ID，123456 是示例科目组合 ID，都要换成真实值。acct_use_type 的枚举不要自己编，先执行 SELECT DISTINCT acct_use_type FROM ce_bank_acct_uses_all 看看已有的值。最后一条铁律：生产环境别直接 INSERT，走界面。
4.3 自动对账规则太宽，两笔同金额流水被一次性匹配
现象：银行对账单导入后，同一天两笔金额相同的收款，系统把两笔银行流水都匹配到了第一张收款单上，第二张收款单还是未核销。
原因：自动匹配规则只按“同一天、同金额”匹配，没有要求参考号唯一。这类匹配逻辑在后台是一个存储过程驱动的，规则窗口里的选项就是它的入参，设置太宽就出现错配。
解决：打开自动匹配规则，开启“按参考号匹配”，关闭“允许部分金额匹配”。如果已经错配，先在银行对账单界面撤销原匹配，再重新执行。抽查有没有未匹配流水，用这条 SQL：
SELECT 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_SID=PROD export ORACLE_HOME=/u01/app/oracle/product/12.2 ORA_USER=apps 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 表确认枚举再执行。
我自己的习惯是每月倒数第二个工作日跑一遍这五条，把结果贴到结账检查单里，该处理的当天处理。现金模块的坑大多不是高深技术，而是小参数、小状态没盯住。提前十分钟查一遍，比月底加班对账划算得多。希望帮到你。
本文还有配套的精品资源，点击获取
