HRYEUS
ForumExpertsArticlesKnowledgeJobs

Spaces

  • All8
  • ORAOracle HCM2
  • WKDWorkday1
  • SFCSAP SuccessFactors1
  • DWBDarwinbox1
  • SMBBambooHR & SMB0
  • PAYPayroll Systems1
  • INTIntegrations & Data1
  • GENGeneral HRIS1

Forum

Start a thread
ALLORAWKDSFCDWBSMBPAYINTGEN
ALLTHREADS

About this community

A practitioner network for the experts behind Oracle HCM, Workday, SuccessFactors, Darwinbox and more — real questions, real answers, no vendor spin.

13 members joined

Browse experts
ARTICLES
RA
Rana Al-MutairiFounding Member
2 months ago·ORAOracle HCM

EBS R12 to Fusion: element entries not carrying retro with the balance initialization

Mid-project on EBS R12 to Fusion. We're initializing balances as of go-live and loading open element entries. The recurring entries load fine, but anything with a retro impact from before go-live isn't reflected — so the first Fusion payroll under-recovers on a few loans and over-pays on a couple of allowances that had a backdated increase in EBS. Are people loading a separate retro adjustment element for the pre-go-live delta, or is there a cleaner way through balance init?

LikeFollow2 replies
  • TF

    Tomás FerreiraFounding Member Separate one-time adjustment element per employee for the pre-go-live delta is the standard move. Balance init gets you the year-to-date figures for statutory, but it won't replay retro events. Calculate the delta in EBS, load it as a non-recurring entry dated go-live, and let the first Fusion run true it up.

  • RA

    Rana Al-MutairiFounding Member That's what I feared. Fine — I'll extract the retro delta from EBS by element and load one-time adjustments. At least it's auditable.

Sign in to reply.
RA
Rana Al-MutairiFounding Member
2 months ago·ORAOracle HCM

Fast Formula rounding drift on GB gross-to-net — 1p off for a subset

We run a small GB population off the same Fusion instance as our GCC entities. Every cycle a handful of employees are 1p off on net pay versus the parallel run. It's always the same shape — someone with a mid-period rate change and a percentage-based deduction. I suspect the order of the deduction fast formula relative to the proration formula. Has anyone nailed down whether it's a rounding rule on the element or the formula itself?

LikeFollow3 replies
  • TF

    Tomás FerreiraFounding Member We had this exact thing. It was the deduction element's rounding rule set to 'Standard' while the earnings were 'Round Down'. Once we aligned both to the same rule and forced the proration formula to return a rounded value before the deduction reads it, the drift went away. Check the element's Rounding Rule under the input value, not just the formula.

  • DN

    Deepa NairFounding Member Also worth checking whether the percentage deduction is reading the prorated amount or the full-period amount. If the formula pulls the un-prorated balance and then applies the percentage, you get a fraction that rounds differently than payroll expects.

  • View all 3 replies →
  • Sign in to reply.