It might be a 'new user' restriction, similar to having to approve posts.
The contents of that attachment is as follows:
******************************************************************************************
Copyright (c) clive Tucker, 2005 all rights reserved.
NB Any and all trademarks acknowledged.
(Version 2.0, 06/07/2010)
Document History
-----------------------------------------------------------------------------
Version Date Author Comment
-----------------------------------------------------------------------------
1.0 15/03/2005 C Tucker Initial version
2.0 06/07/2010 C Tucker Updated to 11.5.10
=============================================================================
Here's some useful tips on migrating balances into Payroll, based on my own experiences (some decidedly unpleasant)
Pre-requisites:
1. Every assignment for which you are loading balances must have a payroll.
2. If you are loading element-level balances, then the element entry to which the value belongs must already exist, you will need its element_entry_id for the balance batch line source_id - best to avoid this if you can.
3. Every balance being initialised must be fed by an input value from a balance initialisation type element. For legislative balances these feeds will already exist, but for non-legislative ones (ie user-defined) then balance initialisation elements, and the initialisation feeds, will need to be created. Since an element can have up to 15 inputs, then it is theoretically possible to create one BI element to initialise up to 15 balances. It's a good idea to make sure that any Balance Initialisation elements that are set up to initialise non-statutory balances, have a termination rule of 'Final Close'. It'll save hassle with loading such balances for leavers.
4. You will need an element link for every balance initialisation element (even the seeded/legislative ones) which must be 'linked to all payrolls', and with no other restrictions (ie an open link)
VERY IMPORTANT: all balance initialisation elements and links will need an effective start date of 01-JAN-0001. You or your tame payroll functional should be able to do this through the application.
Other things to note:
1. There is *still* no actual API to create balance batches, so you must populate the tables PAY_BALANCE_BATCH_HEADERS and PAY_BALANCE_BATCH_LINES yourself. There are various solutions to this floating about- just ask the right people!
2. You can only initialise balances once for an assignment, so it is important that balances for an assignment are contained within a single batch, ie not split across more than one batch. A batch can however contain balances for more than one assignment. However, see Note 6!
3. A batch must only contain balances for assignments that belong to a specific payroll.
4. There must be no previous payroll-process activity for the assignment prior to loading balances, ie quick-pays, payroll runs, in fact anything that creates an assignment action. Nowadays, this also includes processed Mix Batches and a host of other stuff!
5. When creating the header, set the upload date to be the period end date for the last period processed on the legacy system. That will ensure that the next period, which will be processed on Oracle, will pick up those balances you have loaded. If, however, you are uploading any balances for leavers, the upload date cannot be later than the final close date for the leaver. This is particularly noteworthy where leavers in the previous tax year have balances arising from payments in the current tax year. They will need to have an appropriate last standard process and final close date set to some point in the current tax year.
6. Keep your batches to a manageable size. Personally, I would limit balance batches to 1 assignment. If this results in a large number of batches, then I would consider writing a small PL/SQL script to process the contents of the PAY_BALANCE_BATCH_HEADERS table, for each row found, call the standard upload process. There is method in the madness with this: Balance initialisation adopts an 'all-or-nothing' strategy when processing balances for an assignment; the balances will either all be loaded, or, in the event that even one is invalid, then none will be loaded. It is possible, however, for a balance batch containing balances for more than one assignment to be partially loaded. You could, for example, have a batch containing, say, balances for 10 assignments - 9 of which would be successfully processed, and the one in error still remaining. That leaves you with the choice of either backing out the whole lot (including the balances for the 9 successful assignments) or recreating a new batch for the one failed assignment, hopefully with the issue resolved. Messy. With a batch of one assignment, it's cut and dried - the batch is either wholly successful, or not-at-all successful, in which case backing it out and reloading as necessary is much more straightforward.
7. It is sometimes possible to avoid loading zero balances in order to save time/space. There is an exception to this: where a balance has e.g. 2 dimensions to be initialised, and one of them is zero whilst the other is not, then you **must** load the zero value. If you don't the system will not object, but it will assume the non-zero value applies to both balances!
8. It is a commonly held misconception that one can only run the balance initialisation process once. This is only true for an assignment. (see note 2 above) It is possible (and may indeed be preferable) as part of a 'phased' go-live to initialise balances for a particular subset of employees/leavers having already initialised balances for a different subset.
9. Beware if you use the upload date in the batch LINE table. It can't be later than the one in the header. Indeed, it gives a misleading error message, which is nothing whatsoever to do with the real problem! (True in 2003, but may not be the case any more)
10. Keep an eye on Metalink, or My Oracle Support, or whatever it's called this week. In particular, there is a document called 'The Secret Life of Initial Balance Upload' (Note no: 60057.1) which gives some useful tips. Another useful doc is 'Balance Initialization - 10 Common Problems' (Note no:73966.1)
11. Don't rely on the batch status of 'T' ('Transferred') as indicating that everything was loaded successfully. I have found to my cost that where there are tablespace issues involving the PAY_RUN_RESULT_VALUES or PAY_RUN_RESULTS tables and their associated indexes, it can happen that the batch line looks like it loaded, but in fact did not. It is therefore very important to reconcile the results of the balance migration to Oracle with the equivalent on the legacy system.
12. If loading balances for leavers, it's a good idea to load the balances before terminating their employment, as it makes the task of choosing a balance batch upload date much easier. If for any reason you cannot do this, then the balance upload date for leavers cannot be later than their final close date (assuming all relevant BI elements have been set up with a termination rule of 'Final Close')
13. The Initial Balance Upload process operates in one of 4 modes: VALIDATE, TRANSFER, UNDO and DELETE.
VALIDATE and TRANSFER are fairly self explanatory.
UNDO allows you to reverse out the uploading of a specified batch.
DELETE removes the batch header and its associated lines. *BEWARE* that once you have DELETEd a batch, you cannot UNDO the loading of the balances referred to in that batch. The DELETE is usually only used once the system is off and running, and you are 100% confident that the data is no longer needed, and there is some benefit to removing the balance batches, e.g. space recovery etc.
*End*
_________________________
L&K
CT
Remember: A dog is for life, not just for Christmas... unless you're in Korea
Previous Topic
Index