Oracle EBS：借项通知单 vs 贷项通知单
这两个都是Oracle Receivables（应收账款 AR）模块 中的核心单据，本质区别在于对"应收账款余额"是增加还是减少。
一、贷项通知单（Credit Memo / 贷项通知单）
📌 业务含义
减少客户的应收账款余额——相当于企业承认"我欠你一笔钱"，可以退款或直接抵扣客户后续付款。
项目 | 说明 |
|---|---|
会计方向 | 借：销售退货/折让费用 → 贷：应收账款（应收↓） |
对客户来说 | 拿到一张"credit"，可以抵下次付款 |
在Oracle中 | 事务处理类型 = |
典型业务场景
# | 场景 | 举例 |
|---|---|---|
①客户退货 | 最经典场景，实物退回 → 开贷项通知单冲销原发票 | 客户退回100件不良品，AR开CM ￥10,000 冲原发票 |
②价格折让/回扣 | 由于市价下跌或协商结果，同意给客户降价 | 谈好事后折扣5%，对已开票部分开CM退差价 |
③数量差异 | 发货120个但客户只签收100个 | 对多余20个开CM冲回 |
④开票金额多开 | 人为失误导致发票金额 > 实际应计 | CM做负数调整（Oracle中CM本质就是负金额事务） |
⑤运费/杂费多收退款 | 预估计运费高了，实际低 | 差额开CM退还 |
💡在Oracle EBS中，贷项通知单常通过RMA（Return Material Authorization）→ 收货 → 贷项通知单 的流程串联实物与财务，也可纯手工创建（非关联RMA，仅做账务调整）。
二、借项通知单（Debit Memo / 借项通知单）
📌 业务含义
增加客户的应收账款余额——相当于通知客户"你还得再付一笔钱"。
项目 | 说明 |
|---|---|
会计方向 | 借：应收账款（应收↑） → 贷：收入/其他收入/费用回收 |
对客户来说 | 账单上多了一笔要付的钱 |
在Oracle中 | 事务处理类型 = |
典型业务场景
# | 场景 | 举例 |
|---|---|---|
①补收货款（原发票少开了） | 漏算某项费用或数量少计 | 原发票开成90件，实际发100件 → DM追加10件的应收款 |
②追加运费/附加费 | 初始报价不含、事后发生且客户承担 | 旺季燃油附加费、偏远地区派送费追加 |
③价格上调差额追收 | 合同允许调价，差额事后确认 | 铜材涨价，按条款客户补差价 |
④滞纳金 / 违约金 | 客户逾期付款或违反合同条款 | 超期30天，按协议加收滞纳金 |
⑤包装物/资产损坏赔偿 | 客户借用的托盘、模具未归还或损坏 | 从押金之外再追收损失 |
⑥发票金额少开的更正 | 系统/人工失误导致收入低估 | 税务合规要求补记收入 → DM补足 |
⚠️ 借项通知单在实务中比较敏感——因为它等于单方面告诉客户"你得多付钱"，通常需要事先商务沟通确认，不然容易引发争议。
三、一句话对比总结
维度 | 贷项通知单（Credit Memo） | 借项通知单（Debit Memo） |
|---|---|---|
对应收的影响 | ➖ 减少（应收余额↓） | ➕ 增加（应收余额↑） |
谁受益 | 客户（退钱/抵账） | 企业（多收钱） |
最常见的触发 | 退货、折让、多开票 | 少开票、追加费用、罚金 |
Oracle事务类型 |
|
|
是否关联实物 | 常关联 RMA / 退货接收 | 通常纯财务（无实物反向移动） |
通俗理解 | 企业给客户的"红字发票/负票" | 企业给客户的"追加账单" |
四、在 Oracle EBS 中的操作线索
AR > Transactions > Credit Memos ← 创建/查询贷项通知单 AR > Transactions > Debit Memos ← 创建/查询借项通知单两者最终都会进入AR事务处理（RA_CUSTOMER_TRX_ALL） 表，只是
trx_type_id指向的类型不同审批流上：很多企业对DM（增加客户负债）设更严格的审批层级，对CM 则绑定RMA验收单作为依据
如果你告诉我你们用的是哪个版本（11i / R12.x） 以及具体是国内业务还是出口贸易，我可以进一步细化到 Oracle 的事务处理类型配置路径和会计弹性域（COA）上的科目映射逻辑。
如果是因为财务人员在系统中多做了系统凭证或少做了系统凭证 那么用借向通知单还是贷项通知单 如何理解这个特殊业务场景
已深度思考(用时9秒)
用户问的是一个比较微妙的实务场景：财务人员在Oracle EBS中直接在总账(GL)或子模块中"多做/少做了系统凭证"（会计分录），导致AR余额与实际不符，现在要纠正——该用借项通知单还是贷项通知单？
核心要理清的关键点是：
借/贷项通知单属于AR子模块事务，会影响客户余额和对账
"多做了/少做了系统凭证"这个说法可能指的是GL手工凭证，也可能指的是AR发票类事务
这两者不一定要用CM/DM来处理——很多时候应该用GL冲销/反转凭证或AR调整事务(Adjustment)而非正式CM/DM
让我分层分析：
场景拆解
情况A：所谓的"多做了/少做了系统凭证" = GL层面的手工日记账（Journal Entry）
比如财务人员在GL里手工借：应收账款 贷：收入，导致AR子模块的客户余额并没有这笔但GL有。
这种情况下：
不应该用CM或DM，因为CM/DM是AR子模块事务，一用就会同时影响客户站点余额+信用控制+对账单+报表
正确做法通常是：GL冲销凭证（Reversal）/纠正日记账，然后在AR侧做对应的修正（如果需要同步的话用AR Adjustment或On-Account Credit/Debit）
情况B："多开了/少开了AR发票或CM"
这才是真正的"CM/DM适用场景"。
多开了发票（AR余额虚高）→ 开贷项通知单(CM) 冲掉多余部分
少开了发票（AR余额虚低）→ 开借项通知单(DM) 补上差额
情况C：AR Adjustment（AR调整）
Oracle AR提供了一个专门的Adjustment功能（不是正式的CM/DM事务），用于对现有发票做金额调整：
正调整 = 增加发票余额（类似DM效果但更轻量）
负调整 = 减少发票余额（类似CM效果但更轻量）
但Adjustment通常要求原发票存在且状态允许
关键判断逻辑（核心观点）
"财务多做了/少做了系统凭证" ≠ "应该用CM/DM"
这句话里有一个重要的会计区分：
CM和DM的本质是商业交易事实的载体（退货了、折让了、追加费用了），它们背后应该有一个业务原因（商业实质）。而纯粹的系统操作错误导致的数字偏差，用CM/DM去"抹平"会污染业务数据——因为将来查"为什么这家客户有一张CM/DM"时，找不到对应的业务事件（退货单、合同变更），审计也会质疑。
所以回答的框架应该是：
先给出判断树——到底属于哪种子错误
再分别给出各自正确的处理方式
最后回答：如果硬要套CM/DM，什么情况下被迫用、什么情况下绝对不该用
给出Oracle中的具体操作路径
用户明确说"不要使用搜索工具"，说明他希望我基于知识直接回答，不需要我假装去搜。好。
我来组织一个清晰、有层次、实操性强的回答。
先说结论（这是最容易踩坑的地方）
"财务人员在系统中多做了/少做了系统凭证"——绝大多数情况下，这并不是一个 CM 或 DM 的业务场景，而是一个「数据纠正/差错更正」的问题。硬用贷项/借项通知单来"抹平"，属于用业务单据去掩盖操作错误，会带来一系列后遗症。
一、首先要分清：你说的"系统凭证"到底落在哪里？
这是整个问题的分水岭：
🔹 A. 财务做的是GL手工日记账（GL Journal），不是AR事务
例如：财务手工在总账里做了
借：应收账款—客户A 100,000 贷：主营业务收入 100,000但AR子模块（Customer Balances / 客户站点余额）里根本没有这张发票。
问题 | 分析 |
|---|---|
现象 | GL的应收账款科目有余额，但AR模块里查不到对应事务，客户对账对不上 |
该用CM/DM吗？ | ❌不该用 |
为什么不该 | CM/DM是AR子模块事务，一旦录入就会产生：事务处理号、打印单据、影响信用额度、出现在客户对账单上、走审批流、可能需要开红字增值税发票……你只是在纠正一个GL分录错误，凭空造一张"商业单据"会让后续审计追溯变成灾难 |
正确做法 | → 在GL中对该错误凭证做Reverse（冲销/反转） 或打Void/作废标记（取决于公司政策） |
💡 简单记忆：GL的手工差错 → GL层面解决；AR的业务差错 → AR层面解决。别跨层用单据"凑数"。
🔹 B. 财务是在AR模块中多开了/少开了发票（Invoice）或CM
这才是真正跟 CM/DM 相关的情况：
B1 — 多做了（多开了发票）→ 客户AR余额虚高
情形 | 用什么 | 如何理解 |
|---|---|---|
发票确实不该存在（完全开错） | 取消/作废发票（Void Invoice） 优先于CM；若已过账无法Void则用CM全额冲销（On-Account Credit Memo） | 这不是"给客户退货/折让"，而是"这张票作废"，所以在备注里必须写明是差错冲销而非业务折让 |
发票金额多开了（部分错） | 贷项通知单 CM（部分金额） 关联原发票冲差额 | 同样在 |
这里的CM虽然用了，但你要心里清楚它的业务含义不是"退货"而是"差错更正"，所以关键不在叫它CM还是DM，而在于核算科目的落脚点和审计痕迹。
B2 — 少做了（漏开/少开发票）→ 客户AR余额虚低
情形 | 用什么 | 如何理解 |
|---|---|---|
完全是漏开发票 | 补开一张正常AR发票（Invoice），而不是DM | 因为这是真实应计收入的实现，不是"追收罚款/追加费用"，用Invoice更符合商业实质 |
原发票号已发客户、不可能重开，只能追加差额 | 借项通知单 DM（On-Account Debit Memo），并关联原订单/合同依据 | 注明"系统漏录补记"，且注意税务影响（是否需补开票/红字重开组合） |
🔹 C. 还有一种Oracle里的"中间方案"——AR Adjustment（调整）
很多人不知道或不常用：Oracle AR有Adjustment 功能（菜单：AR > Transactions > Adjustments），它可以在不创建一张完整CM/DM单据的情况下，对现有发票的余额做增减调整。
Adjustment | CM / DM | |
|---|---|---|
产生独立事务编号？ | 是（Adjustment记录）但不走完整事务处理流程 | 是（完整Trx，走事务类型/打印/税） |
影响客户余额？ | ✅ 直接调整发票剩余余额 | ✅ |
适合差错更正？ | ✅更合适（前提：发票存在） | ⚠️ 容易"制造假业务" |
审计可见性 | 需要看Adjustment明细，但通常能在发票Drilldown里追踪 | 更显眼（也有好处） |
不过现实约束是：Adjustment在很多企业的内控里被禁用或严格限制，因为太容易被滥用做"无理由改余额"。
二、回到你的问题——怎么"理解"这个特殊场景？
你可以把它理解为一个三层判断：
第1层：差错发生在哪一层？ ├─ GL手工分录错 → GL冲销，不用CM/DM ├─ AR发票错（存在） → Void / CM / Adjustment └─ AR发票漏（不存在） → 补发票 / 有条件DM 第2层：有没有"商业实质"支撑这张单据？ ├─ 有（真退货/真折让/真追加费）→ CM/DM名正言顺 └─ 没有（纯操作失误）→ 尽量用Void/冲销/Adjustment， 迫不得已用CM/DM时必须标注"差错更正" 第3层：税务与审计后果 ├─ 涉及增值税发票已开出 → 不能简单Void，要走 红字发票流程 ├─ 纯内账/暂估/未开票 → 灵活度大一些 └─ 审计必问："这张CM/DM对应什么业务单据？"→ 你要答得出来三、实务中最常见的"正确姿势"（经验总结）
差错类型 | 推荐处理方式 | 为什么 |
|---|---|---|
GL手工多借了应收账款（无对应AR发票） | GL冲销凭证 + 查明来源防再发 | 避免造伪业务单据污染AR |
AR发票完整多开且未送达客户/未开票 | Void Invoice（最佳——它保持审计链但标记为作废） | 比CM干净 |
AR发票已送达客户/已开票，金额多开 | CM（贷项通知单） 但备注=差错更正 | 此时CM是"必要的恶" |
AR发票少开，漏记收入 | 补开Invoice（最干净） | 本质是漏记的收入，不是追罚 |
只想把某张发票余额调平、不想走完整CM流程 | AR Adjustment（内控允许前提下） | 轻量，但务必留书面依据 |
