Oracle PA 主数据模型(WBS/FBS/RBS)→ EBS 与 Fusion 落地差异 → 全场景分录汇总」四块给你做深度串讲。所有会计分录以《企业会计准则第 14 号——收入》(CAS 14 / IFRS 15 时段法)为基准,旧建造合同准则的"工程施工—合同毛利"仅作过渡说明。
一、工程项目时段法:投入法 / 产出法 / 完工百分比
1.1 三个概念的关系
- 完工百分比(POC) 是结果,投入法 / 产出法 是计算 POC 的两种路径。
- 新收入准则下不再叫"完工百分比法",叫"按履约进度确认收入",POC ∈ (0,100%]。
- 一项履约义务只能一贯采用一种方法(投入或产出),不得混用。
1.2 投入法(Cost-to-Cost,最常用)
POC = 累计履约投入成本 ÷ 最新预计总成本
- 投入指标还可用工时、机时、材料量,但会计上 90% 用"成本比例"。
- 当期收入 = 交易价格 × 累计 POC − 以前期间已确认收入
- 当期成本 = 当期实际发生的合同履约成本
- 必须剔除:未安装材料、预付分包款、非正常浪费、跌价准备(投入与履约进度不成比例时要调整,通常以已发生成本为限确认收入)。
例:合同 8000 万,预计总成本 6000 万;第 1 期发生 2100 万 → POC=35%,确认收入 2800 万,成本 2100 万。
1.3 产出法(Output Method)
POC = 已转移给客户的产出价值 ÷ 合同总产出价值
- 常用指标:监理签认工程量、里程碑节点、实测进度、已交付单元数、评估已实现结果。
- 优点:直接绑定客户价值,避免"钱花多了进度虚高"。
- 缺点:产出指标若无法反映控制权转移(如半成品)则不能用;变更签证滞后会导致波动。
同一项目投入法 35% 时,产出法可能只有 30%(材料早进场但未施工),也可能 40%(前期人工密集)。
Oracle PA 主数据模型(WBS/FBS/RBS)→ EBS 与 Fusion 落地差异 → 全场景分录汇总」四块给你做深度串讲。所有会计分录以《企业会计准则第 14 号——收入》(CAS 14 / IFRS 15 时段法)为基准,旧建造合同准则的"工程施工—合同毛利"仅作过渡说明。
一、工程项目时段法:投入法 / 产出法 / 完工百分比
1.1 三个概念的关系
- 完工百分比(POC) 是结果,投入法 / 产出法 是计算 POC 的两种路径。
- 新收入准则下不再叫"完工百分比法",叫"按履约进度确认收入",POC ∈ (0,100%]。
- 一项履约义务只能一贯采用一种方法(投入或产出),不得混用。
1.2 投入法(Cost-to-Cost,最常用)
POC = 累计履约投入成本 ÷ 最新预计总成本
- 投入指标还可用工时、机时、材料量,但会计上 90% 用"成本比例"。
- 当期收入 = 交易价格 × 累计 POC − 以前期间已确认收入
- 当期成本 = 当期实际发生的合同履约成本
- 必须剔除:未安装材料、预付分包款、非正常浪费、跌价准备(投入与履约进度不成比例时要调整,通常以已发生成本为限确认收入)。
例:合同 8000 万,预计总成本 6000 万;第 1 期发生 2100 万 → POC=35%,确认收入 2800 万,成本 2100 万。
1.3 产出法(Output Method)
POC = 已转移给客户的产出价值 ÷ 合同总产出价值
- 常用指标:监理签认工程量、里程碑节点、实测进度、已交付单元数、评估已实现结果。
- 优点:直接绑定客户价值,避免"钱花多了进度虚高"。
- 缺点:产出指标若无法反映控制权转移(如半成品)则不能用;变更签证滞后会导致波动。
同一项目投入法 35% 时,产出法可能只有 30%(材料早进场但未施工),也可能 40%(前期人工密集)。
1.4 成本确认 vs 收入确认(核心逻辑)
|
维度 |
成本端 |
收入端 |
|---|---|---|
|
归集科目 |
合同履约成本(旧:工程施工—合同成本) |
合同结算—收入结转 / 主营业务收入 |
|
确认时点 |
实际发生时先资本化进"合同履约成本",期末结转主营业务成本 |
资产负债表日按 POC 计算,经"合同结算—收入结转"过渡 |
|
结算对价 |
— |
合同结算—价款结算(与业主验工计价) |
|
差额处理 |
合同履约成本减值测试(预计总成本>总收入提减值) |
合同结算借方余额→合同资产;贷方余额→合同负债 |
科目平衡关系:
合同结算—价款结算(贷方累计)− 合同结算—收入结转(借方累计)= 合同负债(贷)/合同资产(借)
二、Oracle PA 主数据:WBS / FBS / RBS 到底是什么、怎么关
2.1 WBS(Work Breakdown Structure)= 项目任务树
- Oracle 载体:Project → Task(Top/Mid/Lowest Task)。支出项(Expenditure Item)只能挂在 Task 上,不能挂 Project 抬头。
- 作用:成本归集最小单元、进度测量锚点、计费行、POC 取数点。
- 一个 Project 至少 1 个 Task。
2.2 FBS(Facility Breakdown Structure)= 资产/设施分解结构
- 本质:"这笔成本最终形成哪个资产部件"的树(Asset Category / Location / FA Tree)。
- 在 EBS 里 FBS 不是独立一等主数据,是通过 Capitalization Options + Asset Category + Task 上的资本化规则把 WBS 成本汇总过去,再
PRC: Interface Assets推 FA。 - 在 Fusion 里升级为 FPS(Financial Plan Structure / Financial Breakdown),成为顶层一等财务主数据,可直挂财务单据,并绑定 Contract 的 POB(履约义务)。
2.3 RBS(Resource Breakdown Structure)= 资源分解结构
- 按"人/材/机/费用"分类的树:顶层=部门,底层=工种/物料类/费用类型。
- Oracle 里 RBS 与 Expenditure Category / Expenditure Type / Revenue Category 联动:
- Task(WBS)决定"钱花在哪个活"
- Expenditure Type 决定"花的是什么资源"(人工/差旅/材料)
- RBS 把 Expenditure Type 归类做预算控制(Budgetary Control)和资源报表。
2.4 三者关联模型(重点)
WBS (Task)
│ Expenditure Item 必须挂 Task
│ 成本分配(Distribute Costs)后带 Expenditure Type
↓
RBS ← Expenditure Type 映射到 RBS 节点(用于预算控制/资源分析)
│
↓ 资本项目:Asset Cost Allocation Method
FBS / FPS(资产部件)
│ PRC: Interface Assets / Send Assets to Assets
↓
FA(固定资产)
- WBS ↔ FBS:不是父子,是"业务明细 → 财务汇总"单向流。桥梁 = Project Type(资本类) + Task 上绑 Asset Category + 资本化分配规则。
- WBS ↔ RBS:通过 Expenditure Type / Expenditure Category 间接关联。预算可控制在 "Task + Lowest RBS Resource" 组合上(Fusion 原生支持,EBS 靠 Budgetary Control + Top Task 近似)。
- FBS ↔ RBS:无直接关联,二者在财务层通过 GL 科目和资产成本交汇。
2.5 EBS R12 vs Fusion 的关键差异
|
维度 |
EBS R12 PA |
Fusion Project Management |
|---|---|---|
|
WBS |
Project→Task 树,业务+成本一体 |
Project Task 纯执行层,排程/进度 |
|
FBS |
隐性,靠资本化规则+FA Category 模拟 |
FPS 显性一等主数据,绑 POB/Contract |
|
RBS |
Expenditure Category/Type 映射,预算控制较弱 |
RBS 原生,Task+Lowest Resource 双维预算控制 |
|
科目推导 |
AutoAccounting(PA 内)→ SLA |
无 AutoAccounting,全走 SLA 子分类账规则 |
|
会计入口 |
PRC: Create Accounting → XLA → GL |
Create Accounting ESS → XLA → GL |
|
合同绑定 |
松散(Project 挂 Agreement) |
强制 Project↔Contract↔POB 绑定 |
三、各场景会计核算分录汇总(新收入准则 + Oracle PA 视角)
说明:
合同履约成本对应 EBS 里 PA 的 Raw Cost 临时归集(最终经 SLA 进费用/CIP);合同结算—收入结转 / 价款结算是 CAS 14 科目,Oracle PA 的 Revenue Event 经 Generate Revenue 生成,再 Create Accounting 进 GL;- 资本项目不确认收入,走 CIP→FA。
场景 1:归集人工(工时卡 OT→PA)
借:合同履约成本—人工(或 在建工程—待摊/ CIP-人工) 150
贷:应付职工薪酬 / 人工清算科目(Labor Clearing) 150
PA 侧:Timecard → Expenditure Item → Distribute Costs(含 Burden 间接成本)
借:项目成本-人工(raw) 150
借:项目成本-Burden 30
贷:Labor Clearing 150
贷:Burden Clearing 30
场景 2:材料领用(INV→PA 项目发放)
借:合同履约成本—材料 80
贷:原材料 80
场景 3:期末按投入法确认收入成本(POC=35%,合同 8000,当期成本 2100)
借:合同结算—收入结转 2800
贷:主营业务收入 2800
借:主营业务成本 2100
贷:合同履约成本—工程施工 2100
场景 4:与业主验工计价结算(结算 2700,增值税 9%)
借:应收账款 2943
贷:合同结算—价款结算 2700
贷:应交税费—应交增值税(销项) 243
场景 5:收到工程款
借:银行存款 2000
贷:应收账款 2000
期末"合同结算"贷方余额 100 万(2700-2800=-100? 实际 2700 结算 vs 2800 收入 → 借方 100 为合同资产,若反方向为合同负债)按借贷方向重分类至合同资产/合同负债。
场景 6:预计总成本上升导致 POC 重算 + 计提合同减值
第 2 期发现预计总成本 6000→6500,已发生 4300,POC=66.15% 而非 71.67%,调减当期收入;且若总收入<总成本:
借:主营业务成本(减值部分) XXX
贷:预计负债 / 合同履约成本减值准备 XXX
(旧准则走"工程施工—合同毛利"借方红字,新准则走预计负债或存货跌价准备)
场景 7:资本项目(自建厂房)成本归集与转固
归集:
借:在建工程—CIP(WBS Task 成本) 200
贷:应付/原料/人工清算 200
PA:PRC: Distribute Costs → 成本进 CIP 子目
期末/完工 PRC: Interface Assets / Send Assets to Assets:
借:固定资产—厂房 200
贷:在建工程—CIP 200
场景 8:合同项目 Generate Revenue(固定总价 POC 法,EBS PA 事件)
PA 事件:PRC: Generate Revenue
SLA 出:
借:合同结算—收入结转(或 AR 暂估) XXX
贷:主营业务收入(项目收入) XXX
场景 9:Project Billing 开票给客户(EBS Project Billing / Fusion Invoice)
借:应收账款 XXX
贷:合同结算—价款结算 XXX
贷:销项税 XX
场景 10:内部跨 OU Cross-Charge
OU-A 借:项目成本(Receiving OU) OU-B 贷:收入/清算(Sending OU)
经 PA Cross-Charge + SLA 双向过账
场景 11:间接项目(研发/行政)费用归集,无收入
借:管理费用—研发项目 50
贷:应付/折旧/清算 50
(Project Class=Indirect,不跑 Generate Revenue)
场景 12:预算控制超支(Fusion Task+RBS 控制)
不发生分录,只产生 Funds Check 失败;若绝对控制则阻止 PA 接 Expenditure Item。
四、把会计和 Oracle PA 串起来的"一句心法"
- WBS Task = 合同履约成本的归集桶,也是 POC 的计算锚(投入法看 Task 上累计成本,产出法看 Task 完工量)。
- RBS = 决定这笔成本在预算控制里扣哪个资源池(人工超了锁人工,不改材料)。
- FBS/FPS = 决定合同履约成本或 CIP 最终变哪台资产、进哪个折旧树。
- 会计上"合同结算"在 Oracle 里不是物理科目,是 PA Revenue Event + Billing Event 经 SLA 映射出来的"收入结转/价款结算"对冲结果;EBS 用 AutoAccounting 定默认科目,Fusion 完全由 SLA 规则定。
- 投入法在 Oracle 最好落地(成本本来就在 Task 上),产出法需要在 Task 上维护"物理进度%"或接 PJT 进度管理模块的 Measured Progress。
→ EBS 与 Fusion 落地差异 → 全场景分录汇总」四块给你做深度串讲。所有会计分录以《企业会计准则第 14 号——&spm=1001.2101.3001.5002&articleId=164268193&d=1&t=3&u=4880a557019a4b409bea416bc19eb985)
1361

被折叠的 条评论
为什么被折叠?



