In a lot of cases you need to make your pure plsql session application aware. Standard software needs to know the application user, responsibility or application to find the right profile option values.

This can be established through the following procedure call:

Fnd_global.apps_initialize
(
my_user_id,
my_responsibility_id,
800 -- application_id HR.
);

The bank details keyflexfield that defines personal payments methods has in a lot of legislations a hidden segment to validate the account number.

The segment is defaulted from a sql statement, using the account number as an input. A cross validation rule checks the content of that hidden segment.

When loading personal payment methods through the api's, one has to fill that hidden segment too.

To create yourself extra information types, you still have to insert some metadata yourself. Familypack G promises that this will be the last time.

Insert into Pay_element_type_info_types
(
information_type,
active_inactive_flag,
multiple_occurences_flag,
description,
legislation_code,
object_version_number
)
Values
(
'XX$your type$',
'Y',
'Y',
'$your meaningfull description$',
'BF',
1
);

The element_type_id is not available in the screen before saving, so you can not use it as a context for valuesets.

'Transfer to GL' writes data in the GL_Interface table. The code is available in the Pay_trgl_pkg package.

Rollback of the process does not removes the lines in the interface table. Funny.

Back in town after some hollidays...

I was working on Retronotification. As such, I enabled some dynamic triggers (API user hooks in fact) for the Incident Register functional area. The package that holds the code was generated promptly (Pay_dyt_element_entries_pkg) en the logging started right away (See Pay_process_events).

Then I created a event group to monitor inserts on the Pay_element_entries_f table. I used that event group as parameter for the RetroNotification Report (concurrent program), and the generated assignment set included the correct lines.

Some extra testing foreseen the next days.

Hrms G will have extra retropay functionality, on top of Retropay by Element. 'Enhanced Retropay' is the name of the new version.

The Pre-payments process sums over all data not already processed. We want a payment for every run, so we will have to run the pre-payments over and over again.
The bank wire does not aggregates the data.

I was doing some test with distributed costing. The out-of-the-box functionality was perfectly spreading costs, as present in the distribution set.

We cannot run payrolls (employers) in a random order with the actual version of the Dutch multi assignment solution.
We tried ourselves to set some flags in the pay_legislation_rules, (I(nterlock) to Y(es)) and this indeed enables us to run employers as we want.
But the results go crazy that way.
Seems that the payroll engine writes the run results in a different way when the I is set or not. Strange.

The first tests with multiple assignments for the Dutch payroll give good results. We tested cases where one employee had multiple employers (payrolls), and within the employer two premium groups (organization). Our test emp had in total 4 assignments, each with a different organization, but with 2 different payrolls.

The new balance dimension _PER_PAY_PTD does a good job till now.

I changed the route of the NL PTD balance to filter also on the date earned. I based my changes on examples from the localization of France and Australa.

Afer updating also the expiry check function of the balance dimension associated to the NL PTD route with the Australian expiry check function, it worked fine.

Also the latest balances behave properly.

We had yesterday a meeting with some people from Oracle core Payroll development about retropay. The requirements needed by the customer are pretty specific, and the actual functionality of retropay cannot bridge the gap. We found a fit through the Reversal process.

But reversal was never foreseen to be used en masse, and prepayments are excluding the results of a reversal calculation.

Next to reversal, we need to run the payroll with date earned different then date paid (or process date, or effective date). This was not giving any problems in the prototype we built, but gives problems when combined with the Dutch localization. The tax part of the Dutch localization uses PDT balances, which sums all over the date paid, so including multiple periods of date earned. This gives wrong results, since the annual salary is going sky high.

Lesson learned : do not use date earned parameter in combination with PTD balances.

Development suggested to enrich the functionality of the actual Retropay by Element process. They will evaluate the possibility to add an additional parameter to specify the date of the legal rules.

This means that it should be possible to retrorun month 7, with the legal conditions of month 10 (this is the new functionality).

Hope they provide us with a reasonable timeframe, otherwise we have to work-around the date earned - PTD balance controversy.

Collegues of me have reported some extra difficulties with Web ADI for Hrms.

The imported ADE.ini loads fine, but there are lines missing in TL tables for secondary languages. Result is that all works fine for the base language, but that the loaded integrators do not show up in other installed languages.

Loading multiple integrators for a single Hrms screen errors. Exact fetch returns more than one row.

List of difficulties and TARs for Web ADI for Hrms is becoming very long. I would not be surprised if we decide next week to abandon for a while the Web ADI track.

ADE is only working with Oracle client 8.0.5. And if you have already an other Oracle home on your computer, it is a nightmare to make it working.
And 8.0.5 does not support UTF8. So ADE is no option.

We start the installation of BNE C, to see if this recent family pack for Web ADI resolves the UTF8 restrictions.

But I do still not see how I can add extra filters or parameters to the Hrms Web ADI integrators.

By the way, the problem stated in the previous post, is classified by development 'as designed'. I'm not supposed to launch form specific Hrms integrators in the Self Service environment. They even told me that this was stated clearly in the documentation. The famous documentation, indeed.

I'm so desperate for the moment that I even consider seriously Oracle reports. I just have to find a way to integrate nicely the Oracle reports output with Excel.

I was still too enthousiactic about Web ADI. I was playing around, but encountered problems with some special characters (à) on our UTF8 environment.

And it looks that Web ADI stores additional query filters somewhere, and that those are appended at any other following query. So it was very easy to enforce an invalid query. I combined the current_employee_flag of the per_people_v2 (People folder) with the default view of the assignment folder (per_assignments_v3). ADI concatenated ( and current_employee_flag = 'Y' ) to that assignment view, and there you have the error. I wonder even why they append it anyway. It is not because I query Mr X in the People Folder, that I want to see only the assignment details of Mr X through the web interface.

I just downloaded ADE, to see if it supports the strange characters on UTF8. Hope so, otherwise I do not have a backup plan.

Web ADI was not working properly. The documentation states that you have to add the forms function Web ADI Create Document to the menu of the responsibility you are working with. But that function does not exists over here. I tried it with Desktop Integration Create Document, but without success.

We created that function at the end by ourselves, and there it goes. Bye bye ADE. Welcome ADI.

Surprise on Contingent Workers. PO is not seeing them as a buyer, nor Project Costing sees them. I really wonder what the added value of Contingent Workers is, if we cannot include them into the non-HR business processes.

TAR opened, wait and see.

We restarted today the Hrms setup in the Golden instance. FNDLOAD is our lifesaver. After one day, all setup is migrated. Only some minor issues with the characterset (UTF8) and the versions of the lct files (the most recent versions are in the patch directories, not in the import directories).

The join I was using for years between Per_people_f and Per_person_types (on Person_type_id) is not valid anymore.

An extra table (Per_person_type_usages_f) joined the club. With this extra table, a person can have at the same time an infinite number of person types. Before, that was limited, and all combinations were listed in the Per_person_types table (eg: EX_EMP_APL, Ex-employee and Applicant).

The function hr_person_type_usage_info.get_user_person_type constructs now the person type.

Included a query that combines the old and new way of findeing the person type.

select
per.person_id, full_name,
typ1.user_person_type, typ1.system_person_type,
typ2.user_person_type, typ2.system_person_type
from
per_people_x per, per_person_type_usages_x ptu,
per_person_types typ1, per_person_types typ2
where per.person_id = ptu.person_id
and ptu.person_type_id = typ1.person_type_id
and per.person_type_id = typ2.person_type_id


Differences were found for Contingent Workers (CWK), where the old join returned a person_type OTHER.

The new functionality of Contingent Workers is really made for us. Configuration is very straight-forward (define simply the person types needed), and add the End Placement screen to the taskflow.

The API's to load and terminate contingent workers (or NPW: Non Payroll Workers) work out of the box.

Firenze. Setup of the Golden instance should start today. Some minor issues with the upload part of previously generated FNDLOAD files. But we could resolve all, and our flexfields, value set and quickcodes are in now.

Surprise. The dba started patching from the wrong old instance. Some test-people were already in, test-projects, test-orders, ... So back to nothing and restart Golden Week next week.

Multi assignments are, next to retro-active recalculations (I do not use Retropay on purpose, I come back on that later), a very crucial part of this implementation over here.

The latest patch for the Dutch Payrol localization was installed yesterday, including the multi assignment functionalities. Installtion went smooth. New routes were found, and I saw the first time a balance dimension _PER_PAY_PTD. A dimension that aggragates run results for all assignments belonging to a specific payroll.

That's almost what we need over here.

Last time I was creating manually routes and balance dimensions was in the good old 10.7 era. Almost nothing is changed in the datamodel for all the FF tables. I guess this is so crucial and omni-present in the core payroll engine, that nobody from development wants to touch it anymore.

The tables I added some lines were:
* FF_routes
* FF_context_usages
* FF_route_parameters
* Pay_balance_dimensions

To overcome sequence related problems, I simply use negative id numbers.

We need to configure the payroll engine over here in such a way that a specific run result is generated a variable number of times. This is realized by using the Fast Formula feature that the RETURN clause can have a variable number of return values.

First I created a direct element type E0, with one input value loops, to hold the number of times the run result is needed. Then intermediate element types E001, E002 and E003 were created, also with one input value, to store at run time the actual loop number. And finally, the element E1 was created, the one we need a variable number of times.

E0 was linked with E001, E002 and E003, with in between this fast formula:

inputs are loops

v1 = '1'
v2 = '2'
v3 = '3'

if loops = 1
then
(
return v1
)
else if loops = 2
then
(
return v1, v2
)
else if loops = 3
then
(
return v1, v2, v3
)

E001, E002 and E003 were all linked to E1 by an other, single Fast Formula.

Had an hilarious TAR. The API for the Soft Coded Legislative (SCL) flexfield, specific for the Dutch legislation, was missing. Advise was to use the core assignment API to load the assignments, and use the forms interface to add to those assignments the SCL defaults. And this for 100.000 assignments...
I had to repeat tree times that this was not really feasible over here, and to escalate the TAR, before they saw the light.

Having a dedicated SDM in Oracle support really helps you further. Now we should have the missing API within one week.

We are using weekly payrolls. A year can have 53 weeks. Oracle numbers them incorrectly: the week that contains the first of January is week nr 1. The Netherlands and other European countries follow the ISO standard.

An 'enhancement request' is on the way.

My first Oracle Hr project was in the Netherlands on 10.7. For the moment I'm back in the Netherlands, implementing the first Oracle Payroll for the Netherlands. The localization for the Netherlands is delivered in multiple stages, and by the end of the year, all phases and patches should be there. Cross fingers.

Anyway, since Friday we have a fresh installed 11.5.9 on Linux with Hrms F on top of it. Installation went very smooth, the only hick ups were related to the multiple tier install and that the payroll product was not selected by default as a product to install.

Only at the end, when installing the HRGLOBAL driver, we found out that the product Payroll (801) was not installed. So the HRGLOBAL did nothing at all. A simple query on the Fnd_product_installations made this clear. So starting up the license manager, select Payroll, et voila.