Neil Catubig SUPPORT ESCAL ENG

Currently, there is no 'Project' field that can be configured and added into the Invoice capture app, for validation and linking purposes.

For businesses that deal with a high-volume of Project-related PO/PO Invoices, that information is pertinent and will help in correctly capturing/linking the captured invoices.

Thank you!

There appears to be an issue with the leave accrual calculations, as the system does not seem to take into account the employee's working calendar. For example, if an employee works 6 hours a day 3 days a week, the leave accruals should be calculated based on this schedule. However, the system currently accrues leave based solely on the default leave plan, without considering the employee's specific working hours or days.

=

Expectation, the system must consider the employee working calendar to arrive to the right calculations. My expectation the monthly accrual should be:

Part time employee 

Hours per day Working days per week Total hours per week (Hrs) Total hours per month Leave entitlement (Hrs)

6 3 18 72 5.4

However, if the employee is a full-time employee, then calculation should be:

Full time employee

Hours per day Working days per week Total hours per week (Hrs) Total hours per month Leave entitlement (Hrs)

8 5 40 160 12

=

It needs to be noted that it can happen that Customers can have around 30 different Working calendars, with different configurations of work- hours per day, and work-days per week.

We’ve looked into it and here are our findings:

++

A. When using Accrual type: Hours worked, it is not calculating the Leave accruals based off the Employee’s work calendar.

It seems tied up to actual worked hours recorded against the Employee, which is not applicable to the Client’s requirements (as not all Employees will be linked to Timesheets/Hours journals).

B. A Leave plan with an Accrual frequency of Weekly/Monthly can be used, but then the users would need to define the ‘Accrual amount’ per week/month for each Leave plan that is defined for each Working calendars (noting that the Client has around 30 different Working calendars).

For example, for a 6-hr/day, 2 day/week work week, they would need to create a specific Working calendar for that as well as manually create an equivalent Leave plan like the following:

Part time employee

Hours per day Working days per week Total hours per week (Hrs) Total hours per month Leave entitlement (Hrs)

6 2 12 48 3.6

You would then need to multiply that to how many Work calendars they have and multiply that to how many leave types they have (at least 5 Leave types).

Whereas, if we have an oprtion or a way to calculate the Leave accruals based on the work hours/days that the Employee is set up with (against a Work calendar), they'd only need to set up a single Leave plan (for each Leave type) applicable across all Employees (even though they’d have different work hours/days).

Customers require an equivalent ER Payment model for ANZ Direct Credit Service compatible for countries like Hong Kong and Singapore

Currently, Customers would need to create their own custom ER bank payment file formats to address missing formats for specific banks in specific countries.

This would be one of those requirements that would be great to be included as part of the existing standard/out-of-the-box ER bank payment formats in D365FO.

Thanks!

PO Invoice workflow approval history is important for basic auditing purposes.

Thus, there is a need to enhance the Purchase update history cleanup, and provide an option for users to include or exclude cleanup/deletion of Invoice workflow history for auditing purposes.

Thank you!

Customers continue to face random failures of automatic posting of approved Timesheets even when the Project management and accounting - Timesheet parameter - Approved timesheet posting is set to 'Automatic.'

We understand the workaround is to create a recurring Batch job [via Project management and accounting>Periodic>Post all approved timesheets] to catch approved Timesheets that are not automatically posted.

It would be ideal to have telemetry information defined and captured around that PMA parameter [Approved timesheet posting = 'Automatic'] functionality to better understand the source of the posting failures and avoid those as much as possible.

Currently, there is a need to create or link Project Purchase orders to Item requirements in order to consume Project PO Item costs upon PO Receipt posting (and not wait for PO Invoicing).

Without the use of Item requirements, the current standard/OOB functionality is designed to consume Project PO item costs at the time of PO invoicing and not at PO receiving.

There should be an option to do so, to consume Project PO item costs at the time of PO product receipting even before PO invoicing) without the use of Item requirements.

Actual/Verbatim business requirement:

=

"The option to use Item requirements has already been considered but not accepted and the reason being that item requirements will be created for actual deliverable items for the project and not for the direct consumables. This is related to a client business where they are manufacturing the items as well as selling the items so each item which they are selling and is part of the deliverable will be created as item requirement. Now these item requirements will create linked PO or production orders as required via master planning. But during the manufacturing process (Using consumption method of production), if they realize any of the production order need additional material then rather than going through the whole cycle of changing the BOM line, they want to manually create direct POs and consume the material in the project directly. And since it’s a consumption method of manufacturing (where every picking list and route card is posted to project directly) so they don’t care about adding the additional stock item in the production process and want to consume directly in the project since their reporting is based on project and not production. Now if they create this direct material consumption via item requirement then it will disturb the whole delivery process via the advance warehouse. 

=

Thank you!