Dynamics 365 Project Operations

On the time entry screen of the Project Operations app, click the Copy Week button in the dialog box "Start Week", "Start Date", "End Date", etc.

The display name is confusing to users, so the weekly copy feature is not familiar to users.

From the above, we want to make the display name easy to understand that the start week is the period of the copy source and the end collection is the period of the copy destination.

We ask that developer allow customization of the dialog box or change the display names such as "Start Week", "Start Date", and "End Date" to more descriptive display names.

Currently, when users create PO-s for a project with multiple sub-projects, they need to create separate PO-s for each sub-project. This means an additional workload for users and is also error-prone as they need to keep track of several PO-s for the same main project. The procurement process for the projects would be greatly streamlined if it would be possible at PO creation to include items from item requirements of different sub-projects of one main project.

There are situations where part of a project needs to be invoiced via an order A and a different part of the project via an order B.

e.g. because of different conditions for the different parts of the project like reduced project prices for certain tasks or different payment terms.

Currently this is not supported. It is possible to assign multiple order lines to one project (if "selected tasks" = "Included tasks only") but only if these order lines are within the same order. I would like to be able to assign order lines of different orders to one project.

Hi,

Currently, users can attach only one document at a time when submitting expenses. To improve efficiency and user experience could you please consider implementing bulk uploads for receipts? I saw such suggestion appear back in 2017 but it was not yet implemented.

Thank you in advance!

Link language settings for the Tasks view in Project in Dyn365 Project Operations - coming from Project for the Web - to Dyn365 language settings, i.e. not using the format settings for this. Some users want to change their format e.g. to German format but still use English language across Dyn365.

Similar to the way we have a ledger to AP reconciliation report, we need the ability to reconcile against the cash advance balances within the expense management module.

I'm seeking the ability to copy a timesheet without duplicating written hours, creating a new timesheet with only projects and tasks for manual hour input to avoid errors. It is commom that resources work on the same projects and tasks as the week before, but that the number of hours is different. A copy of the previous week without the written hours would be more user friendly.

When using Porject Operations intensively, with many data conversions running and many batch processing jobs running, chances are, there will be some hick-ups in the process, possible causing corrupt data.

This, for instance now happened multiple times with one of our biggest customers, resulting in a request to Microsoft for disabling a plug-in that prevented us from doing a data correction.

The plug-in did not only prevent data in the table to be modified, but also had some functionality in it, filling certain fields in that table.

Disabling the plug-in had more effect than just enabling modifications. Also, requesting a plug-in to be disabled, takes a lot of time, and way too much effort, we sometimes needed multiple weeks, and multiple escalations to make it happen.

This idea has 2 changes in it :

Split up some plug-ins (for instance the one on the actuals table), so that it only enables or disables the modification of a record, and have all the other functionality in a different plug-in.

Enable the partner to disable or enable the plug-in that prevents the modification of a record, so there is no more dependency on Microsoft.

These 2 changes will make it much more easy for a parnter to correct data, and will cause higher partner satification but more importantly a better customer satisfaction.

The investigation into transportation details and the text engine for setting a ship-from Applicability rule for project invoice proposals confirmed that the address is taken from the transportation details loading address. This was verified with the official Microsoft Tax Calculation engine team. However, it was communicated with the Microsoft Project Accounting team that there is no way to default the loading address automatically for project invoice proposals; it must be selected manually. This raised concerns about the feasibility of manually entering the transportation address due to the high volume of projects and invoice proposals.

I would like Microsoft to enable a default loading adress. For now, this is only possible manually. Which is not workable in practice.

Tracking ID: TrackingID#2406130050003155

Importing project estimates on the project contract line details is calculated differently to the manual creation of project contract line details.

MS ticket raised for this idea.TrackingID#2404240050001707. Details as below.

Hello, Hieu.

I hope you are well!

Our Product team has advised that this is the current expected system behavior because from the screenshots, it appears that a day is 7.5 hours, so 2.75 days gives 20.625 hours, which is rounded to 20.63. In the two contract line details (CLD), we can see that the imported one is priced in hours and the manual one in days.

When assigning to tasks, it creates a resource assignment that has contours, or day-by-day pricing. If viewed in the estimates tab, we should see 7.5 hours for days one and two, then 5.63 for day three, so when we import, it imports as hours rather than days. Thus, the calculation for the manual one is £475 * 2.75 days = £1306.25, while the other is 7.5 hours * 2.75 days * £475 / 7.5 hours. While the two equations are functionally the same, we round 20.625 hours to 20.63 which then gives us the difference.

So, to sum up, this is a rounding issue which could likely be mitigated by adding additional decimal places. Our Product Team has begun doing this in other areas.

There is a fix coming, likely in a release which should be released by the end of June, that will key off the currency precision. However, this will not help in your case as it's the quantity field that is causing the rounding issue. It's currently set to a precision of 2 decimal places meaning even with the currency precision fixed, multiplying by the quantity will still be a problem.

They will add a suggestion/design change request to up the quantity precision to 4 decimal places for CLDs, QLDs, estimate lines, and possibly resource assignment contours (If it's also 2 decimal places, it will just get imported as that even if the CLD/QLD quantity is fixed).

Looking forward to hearing from you!

Kind Regards,

Kristian Hadzhiyski