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.