This snippet to rollback multiple payroll actions. Handy in a test environment.

for r in (
Select payroll_action_id from pay_payroll_actions
where
order by 1 desc
)
loop
py_rollback_pkg.rollback_payroll_action
(
p_payroll_action_id => r.payroll_action_id,
p_all_or_nothing => FALSE,
p_dml_mode => 'FULL'
);
end loop;

The API pay_balance_adjustment_api.create_adjustment is functionally the same as the Adjust Balance form. An element entry is created (creator type and entry type = B), non visible in the element entry screen. The creator id points to an assignment action. A payroll action (B) is created, with one assignment action, and one single run result.

Hrms FamilyPack G has been applied. From that moment on hrglobal is reporting problems on database items. Seems that there is now a new who-trigger on the ff_database_items table, but the code to decide whether to insert or to update the database item from the shadow tables uses therefore still the last_update_date. As such, every database_item is seen as a new one, so every time hrglobal tries to insert an extra row in ff_database_items, violating some constraints.

A quick fix in in the body of ff_data_dict resolved it. Now the tar.

The Formula functions (link between PlSql functions and Fast Formula) do now support output parameters. No idea since what release, but in 11 it was not working. This enhances the PlSql-FF integration significantly.

The output from hr_utility.set_location can be redirected to dbms_output. This has an upper limit of 1 Mb. Since the assignment api's generate tons of tracing ,the 1 Mb can not be enough.

In that case, you can redirect your tracing to Oracle trace files.

Hr_Utility.set_trace_options(UPPER( 'trace_dest:trace_file'));
Hr_Utility.trace_on;

We encountered some problems with the pre-payment process for third party payment methods.

By adding some trace code into the package HR_PRE_PAY, we could knock down the issue.

fnd_file.put_line( 1, 'your message');

The line above adds some lines to the log file of the concurrent request.

When you change or create a balance route, you have to recompile all fast formulas, since the route text is part of the fast formula package code.

Bulk compile of fast formulas: $FF_TOP/bin/FFXBCP apps/apps 0 Y %% %%

Oops, deleted data, and 2 hours later my report was not working anymore. And the dba was not in to restore the table.

Flashback queries saved me.

SELECT * FROM xxrs_pay_balance_redefinitions
AS OF TIMESTAMP TO_TIMESTAMP ('07012004 00:00:01','DDMMRRRR HH24: MI: SS')

The API for assignment extra information types requires that there is a line for your session in the Fnd_sessions table, since some of the queries rely on that datetrack information.

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.