Dynamics 365 Project Operations

The financial dimension values from expense report does not transfer to project invoice proposal when the financial dimension of expense account structure is different than project dimension setup. The project invoice proposal inherits the financial dimensions on the main account of the expense, which is set up in Account structure, instead of the dimensions in the Project setup. Therefore, some financial dimensions will become blank on project proposal and unable to post invoice proposal.

However, when comparing with the invoice journal side, the project invoice proposal is picking up all Project default dimensions even though its account structure lacks some dimensions.

This causes an inconsistency in the system behavior and has a serious impact to customers who are using this function to post project invoice proposal for expense report.

After posting project invoice proposal, the name of the project invoice report when it gets emailed has a double extension "Invoice.pdf.pdf”.

On the print parameters for File, the name is set to Invoice and then pdf selected as the file type. That then updates the file name to Invoice.pdf. On the email tab select the file type as pdf.  

What appears to be happening when the Invoice is emailed is that an extra .pdf is being added to the attached document file name in the email. The file attachment is showing as Invoice.pdf.pdf. 

This could possibly cause issue with Spam filters. It would be great if this can be looked at for correction in a future build of D365 Finance and Operations. 

Currently, project revenue postings are considered in the project statement only once they are invoiced.

Ideally, they are already considered as soon as they are posted.

For other project transactions (hours etc), the project statement includes them as soon as they are posted.

Environment: Project Operations non-stock

Information: Microsoft time standard time zone is UTC - Universal coordinated time. When a transaction is made for actual transactions the transaction date uses the users specific time zones. The transaction date which is time zone independent shows the correct date.

Issue: When a user changes their local time zone from UTC, and their personalization to their local time zone, then the Document date/Accounting Date are one day off from the transaction date. This poses confusion and inconsistency.

Idea: Solution to make document date/accounting date consistent behavior with transaction date.

Business Value:

Improved decision-making, enhanced trust in the system, reduce risks

This idea is to propose that the expense management mobile app also displays the expense category name, for usability purposes.

Once expenses have been added to the mobile application, users only see the category icon and merchant value on the "Expenses" tab. When users create a new report and choose "Attach expenses", they only see the Merchant name (if this value was keyed in/selected when the expense was created). Even icons are not displayed on this form.

Not displaying the category name can create confusion for users as there are so few icons available and sometimes, the icons aren't shown.

When using the expense management app on my phone, all amount are wrong, they are multiplied by 100.

It seems like the app is missing support for multi cultural setup, i.e. where my user in Power Platform is using en-us as language, but my phone is using DK setup. This gives a difference in the decimal separator. this is common scenario and it makes the app useless if everything need to be fixed in FO afterwards.

So the change suggested here is for the app to support multicultural setup between the different devices.

To invoice for example a timesheet transaction with sales taxes in an intercompany customer invoice AND using there the standard function “Add line” will lead to a bug that the total amount from the intercompany customer invoice will differ from the automatic generated pending vendor invoice totals.

Problem is here that the sales taxes on line level in the intercompany customer invoice and also in the linked pending vendor invoice will be calculated wrongly if you have line number duplicates.

The idea would be to fix this standard behavior as you right now are not able to use the “Add Line” function on the intercompany customer invoice form.

When we create a project invoice proposals with billing rules we will pass the constant start date, end date and invoice date.

When running this in recurrence batch mode on daily basis the system checks for the same dates which we supplied on the parameters for all days.

if we try to use (DayRange(-30,0)) in query range against Project date but it is not getting filtered out.

if we try to pass future date in start date and end date field it is throwing an error “End date cannot be later than current date of legal entity's time zone.”

as per the limitation of our product we cannot run this in recurrence batch mode.

The idea is to provide a feasibility to supply dynamic values for start date, end date and invoice date so that invoice and other dates will get updated regularly if it was running in recurrence batch mode.

We had requirements to extend the Project Task Table with Information we should transfer from the Project Summary to the Tasks when they are created. As we found out in this case the attribute mapping did not work. We really would appreciate being able to use this functionality on these Tables in order to allow better Transfer of information, for those users who mainly work with Project Tasks.

In Microsoft Dynamics Project Operations, when a custom attribute is added to the task grid, its default value is not automatically applied to new records. This issue occurs even though the default value is correctly configured in the attribute settings. Interestingly, the behavior appears to be linked to the visibility of the column: when the custom attribute column is added to the task grid, the default value is not populated; however, when the column is removed, the default value is applied as expected. This suggests a potential bug or limitation in how the task grid handles default values for custom fields.