when new calendar created with the Base calendar with the "normal" working hours, will inherit the normal working hours , not the holidays. it has to be updated manually for every new calendar.
Base calendar should inherit the holidays also.
It would be very usefull to have some extensions on the Manage worker addresses functionality:
1/ If I, today, create a worker with an employment that started yesterday, and add an address, the address is created with Effective date = date/timestamp.
So i would need to change the Effective date to 'yesterday' but I can't. It seems that the Edit option for Effective dates is disabled for the Primary address, but it's impossible to create a first Worker address with Primary set to No and in almost all cases a worker only has 1 address.
2/ If I create a 2nd address record with Effective date in the future and want to indicate this address as Primary, then the 1st address is immediately set to Primary = No, which leads to the fact that the worker doesn't have a primary address untill the Effective date of the 2nd address record.
Also for Future address records, the Primary checkbox isn't visible on the form so from the moment on the record got saved, it's no longer possible to uncheck Primary or to check another address as primary.
And to the user it seems as there is no Primary address at all.
These are business requirements to support Belgian payroll (in a user friendly manner ;-)).
Currently, annual contribution limits for 401K employee deductions are calculated based on the Earnings date rather than the Pay date. So if wages are earned by 12/31/2017 but paid 1/1/2018 the annual limit will be applied from 2017 which may cause 401IK deductions to be skipped on that last/first pay period of the year. The 401K deduction amounts are reported based on the Pay date (i.e. 2018 in this example). Recommendation is to allow users to set annual limit calculation on benefits to use either earnings date or pay date.
Issue reported in Dynamics AX 2012 R3.
Client reported that after installing 2018-R2 tax update that all workers earnings were negatively affected causing them to receive less per paycheck. The issue was submitted to Microsoft and (118013117566487) and tech stated that "There is a parameter called allowSupplementalElection, which determines whether or not the pretax 401k deduction should be applied to both regular and supplemental wages. We have this turned on by default in our code, which is causing the 401k deduction to hit both the regular and supplemental wages, driving down the taxable wages just enough to produce the 75 cent difference we are seeing. So the results that we see in the system are expected and by design.
In your example that you provided you do not want 401k deductions to be taken out of the supplemental wages, but we don't support that.
Since we have other customer who are using the system as it currently is and are expecting the results that we see the system calculate the way it currently is we cannot just switch the flag to false, either, as other customers are expecting the existing behavior.
I would recommend entering a product suggestion to have the system calculate"
Suggested by – New – 0
The PayrollEarningCode table has CacheLookup property set as EntireTable. Since in our solution we have more then 1000 PayrollEarningCode records, the table works extremenly slowly.
According to recomendation form Microsoft (actually, from you guys) tables which have TableGroup = Reference are not allowed to have CacheLookup = EntireTable.
My recomendation would be to change it from Entire to NonInTTS.