标签：Gross context Pay will Simultaneous split Rel 201210235AM PAYE
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
标签：Gross,context,Pay,will,Simultaneous,split,Rel,201210235AM,PAYE 来源： https://blog.csdn.net/johnny_niu/article/details/90232638
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。