Dynamics 365 Project Operations

Currently, the project contract can only either be in status Draft or Confirmed. Because after the contract is confirmed it can no longer be edited, Microsoft suggests to keep it in status Draft. That is misleading for Account managers and Project managers. Thefore, a new status should exist between Draft and Confirmed to signal that the project contract is complete, such as Ready or Qualified. If a new status is introduced, the Draft status should prevent invoicing.

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!

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 

If Sales prices for hours are invoiced without a full currency amount (e.g. 120,50) and no full hours (e.g. quarter hours and three-quarter hours), D365 rounds the decimal places at line level.

This can lead to differences in cents adding up in the total and an incorrect invoice amount being issued in relation to the sales price per hour.

Example: One hour has a sales price of $127.50. The service is invoiced with three items of 0.25 hours, 0.75 hours and 1 hour. The total of 2 hours is $255, but the individual lines are rounded up and the invoice amount is $255.01.

The more positions with 3 or more decimal places, the more the difference is added up. A manual change is not possible.

In connection with eInvoicing, which will be mandatory from 2025 in Germany for B2B-transactions, the check leads to the invoices not being accepted and rejected. It is not possible to change this logic with the rounding settings in the system.

The rounding rules must be adjusted in order to comply with legal requirements.

In the Estimates tab of the project table, output the unit cost price and unit sales price by member and task to Export.

This feature is not currently implemented.

The addition of this feature will improve the experience for users.

When customer retention is set to decimals, the calculation fails somewhere. The project invoice total amount becomes a penny different than the revenue in calculated tax.

For example,

with customer retention 7,5% on a project invoice

Header

Invoice amount: 6,805,505.96

Gross margin: 5,444,404.77

Invoice proposal transaction summaries

Invoice line amount: 5,885,843.00

Retention: 7,5%

Customer retained amount: 441,438.23 (actually 441,438.225)

Amount less retention 5,444,404.78

Posted sales tax

Amount origin: 5,444,404.78

tax: 25%

Calculated sales tax amount: 1,361,101.19 (actually 1,361,101.195)

amount origin + calculated sales tax amount = 6,805,505.97

The problem is that this causes problems in in xml validation tools, which fails with the following error message:

Document not a valid Electronic invoice, failed in validation for document type. 

The error message is due to amount + calculated sales tax is not equal invoice total amount.

To sort this out today, you need to 1) send to external provider for validation, 2) receive the error message, 3)re-invoice and manually adjust retained amount so the penny difference no longer appears, and 4) resend.

Alternatively, the XML-file can be adjusted manually, causing penny difference between actually invoiced and stated in Dynamics.

The cost of this issue for one of our clients is at least 10.000USD per year, due to increased validation and resending of invoices. This does not include the labour cost for adjusting manually the xml files and re-uploading a new file.

This was reported to Microsoft as an issue, but it was declined - as they deem it too complex to fix and they believed it is an uncommon issue. However, it happens every month for our client.

Introducing a feature in Project Operations that sends automated email notifications to team members when a task is assigned to them. This enhancement will improve task management and ensure team members are promptly informed about their responsibilities