201210235AM-Simultaneous Gross to Net

Overview

Simultaneous gross to net calculations are where the calculation within the single transaction (1) is logically split based on some criteria.

The criteria will be defined by a localisation nominated component within a deduction card or the card itself. For the UK they require each PAYE reference to be processed independently of any others. The association of the deduction card (PAYE Reference component) to individual terms implies that the element entries for that term and its assignments belong to that PAYE reference and need to be processed together.

(1) - Single transaction (payroll run) for a payroll relationship including multiple terms and multiple assignments (i.e. single action).

Diagram

 
 

Key Points

There can only be one criterion for the split per localisation.

The split will be internally represented by a context - this will be the ID of the component e.g. PAYE Reference.

The processing of individual element entries is based purely on processing priority - all element entries across all 3 levels are put into a single list and sorted based on this e.g. all salaries will be processed, then O/T. then Bonus, and finally Tax. No account is taken of the employment hierarchy or striping when this is done. It is the setting of the context against each result and the use of context balances that enables the calculation to be logically split.

The creation of child actions for either run pro-ration or run types will be as before. Within each child action there may be more than one simultaneous GTN based on the element entries being processed.

Any element entries at payroll relationship level need to be allocated (possibly pro-rated) to the relevant simultaneous GTNs. This can be achieved through auto-indirects or via formula results.

All results of the calculation need to be stamped with the correct context value. Core payroll will provide a default value for this context using the relationship between the term and the deduction card component. Where this is not possible the localisation will need to ensure the context is set correctly.

Element templates will be used to ensure the setup of all user elements are compatible with the consistent setting of the context.

Balances will need to use the context e.g. in the above example there will be two gross amounts to be used as a basis for two separate tax calculations.

Pre-payments will be created based on the split NB. Within a single pre-payment action there will be one or more pre-payments per logical split. The net amount for each simultaneous GTN will be distributed across the payment methods identified against the payroll relationship.

An archive action will be created per split and the archive contents will reflect that split.

The payslip will also follow the split i.e. user will get a payslip per PAYE Reference.

Any other reports will need to be aware of the simultaneous GTNs / split by deduction card component so that they show the correct information.

Worked Example

Taking the example shown in the diagram the following calculation sequence will take place... 

Level			Element Entry	Element	Processing Priority	Amount	Context	Tax Base (PAYE 1 )	Tax Base (PAYE 2 )
Pay Rel 1	Term 1	Asg 1	Direct	Salary	1000	1000	PAYE 1	1000
Pay Rel 1	Term 1	Asg 2	Direct	Salary	1000	400	PAYE 1	1400
Pay Rel 1	Term 1	Asg 3	Direct	Salary	1000	200	PAYE 1	1600
Pay Rel 1	Term 2	Asg 4	Direct	Salary	1000	2000	PAYE 1	3600
Pay Rel 1	Term 2	Asg 5	Direct	Salary	1000	1000	PAYE 1	4600
Pay Rel 1	Term 3	Asg 6	Direct	Salary	1000	500	PAYE 2		500
Pay Rel 1	Term 1	Asg 1	Direct	O/T	1100	100	PAYE 1	4700
Pay Rel 1	Term 1	Asg 3	Direct	O/T	1100	50	PAYE 1	4750
Pay Rel 1	Term 1	Asg 6	Direct	O/T	1100	200	PAYE 2		700
Pay Rel 1	Term 3	Asg 6	Direct	Bonus	1200	700	PAYE 2		1400
Pay Rel 1			Direct	Tax Calc	10000
Pay Rel 1			Indirect (Tax Calc)	Tax	10100	475	PAYE 1
Pay Rel 1			Indirect (Tax Calc)	Tax	10100	140	PAYE 2

 

The elements are processed in processing priority order and they will contribute to the correct base balance for tax calculation by having the correct context set on them. I'm not sure (doubt) if the processing sequence within the same priority is deterministic i.e. will always process assignments in same sequence. As such you shouldn't rely on that sequence when planning out the calculation. 

The Tax Calc element will identify that there are two PAYE references and therefore create two further element entries (indirects) with each one targeted (using a context) at one of the two PAYE References. The subsequent processing of each of these will get the base amount using a context balance and work out the tax accordingly. 

The calculation at this stage is very much at PAYE Reference level i.e. it does not care if there is one or 100 assignments. If the localisation requires that the tax needs to be distributed across the assignments for some reason then they can create further indirects as required using same approach as used by Tax Calc element and apportion the tax amount between them. 

Given that the processing sequence of the assignments is not deterministic I don't believe it'll be possible to allocate the stepped amounts accurately from a tax calculation and I'm not sure it would make sense to anyway. The allocation would have to use some form of pro-ration across the assignments using whatever criteria is appropriate. The whole new way of calculation is to help avoid such inconsistencies where the sequence of processing would affect the tax amount taken 'per assignment'. 

The above principles can be used for any striping of the data at any level e.g. could initiate term level deductions, assignment level deductions, state level deductions for US, etc. The key components are the setting of the correct contexts on the results and the generation of the 'calculation' elements with the correct contexts.

Considerations

Localizations need to analyze what the factor for defining the split is e.g. PAYE Reference for UK. 

The above analysis then needs to be taken into account when defining the structure of the deduction cards. 

The definition of elements and balances will need to support the context. 

All calculations need to be aware of the split and use contexts correctly - both in stamping results as well as accessing balances. 

Any localization specific UIs or reports need to be aware of the split.

Identifying the split

There is a CALC_BREAKDOWN_FLAG on both the PAY_DIR_CARD_DEFINITIONS and the PAY_DIR_CARD_COMP_DEFS_F tables.

One of these tables should have the flag set to Y, for 1 of the rows.

PAY_DIR_CARD_DEFINITIONS - use this flag if the breakdown is for the whole card, i.e. the whole card represents a gross to net calc.

PAY_DIR_CARD_COMP_DEFS_F - use this flag if one of your components is the breakdown id, i.e. you can have multiple gross to nets within a card. A maximum of 1 row in PAY_DIR_CARD_COMP_DEFS_F should be set to Y, as it would not make sense to breakdown by more than 1 object.

Link: http://hcmwiki.us.oracle.com:8880/display/L10N/Simultaneous+Gross+to+Net