Benefits of supporting custom date formats in the "Dynamics Project Operations" project task grid for start and finish date:

1. Enhanced User Experience:
2. Localized Date Formats: Users can view dates in a format they are familiar with, reducing confusion and errors.
3. Consistency: Aligns with other regional settings on their devices, providing a seamless experience. Also, it would be consistent with dynamics 365 date format over other date fields
4. Increased Productivity:
5. Quick Recognition: Users can quickly recognize and interpret dates without needing to mentally convert formats.
6. Reduced Training Time: New users can adapt faster as the date format matches their regional standards.
7. Improved Data Accuracy:
8. Minimized Errors: Reduces the risk of misinterpreting dates, which can lead to scheduling errors and project delays.
9. Standardization: Ensures that all team members are on the same page regarding project timelines.
10. Global Collaboration:
11. Cultural Sensitivity: Shows respect for cultural differences, fostering a more inclusive work environment.
12. Ease of Use: Facilitates collaboration among international teams by accommodating diverse date format preferences.
13. Competitive Advantage:
14. User Satisfaction: Enhances overall user satisfaction, potentially increasing adoption rates.
15. Market Appeal: Makes the product more appealing to a global market by addressing regional needs.

Once supported this feature would add significant value to the product and improve the end-user experience and productivity.

Resource Group Allocation on Project Planning Lines is a feature that many customers in project management want to use.

Here are some ideas and suggestions for implementing or improving this functionality:

1. We would like you to add a Resource Group option in the Type field of project planning lines.
2. Many clients prefer allocating resource groups to project planning lines instead of assigning individual resources to each line, as assigning a single resource can be time-consuming.
3. Therefore, they request a feature that allows grouping resources into teams and assigning the entire group directly to project lines.
4. They want the ability to add desired resources as team members of a created resource group and then assign this group directly to project planning lines.
5. This approach enables more efficient planning and utilization of grouped resources.

When the revenue recognition ends on 30.11 and you also have posting date 30.11, the exchange rate should not use the actual positing date (2^nd December).

In this example (which are using actual currencies from the actual period), this contract has a difference in contract value on 40735 USD because the exchange rate is using 2^nd December instead of 30^th november. This is making wrong accruals and many contracts with high amounts make very high differences in accruals than would be in the fiscal period end.

Business impact:

The issue of incorrect contract value calculations in fixed-price contracts denominated in foreign currency poses significant financial and operational risks. Specifically, when posting revenue recognition, the exchange rate for these contracts is inaccurately applied, as the rate from December 2nd is used instead of November 30th.

This discrepancy resulted in a $40,735 USD variance in the contract value for a single example, leading to incorrect accruals. When scaled across multiple contracts, particularly those with substantial values, the impact becomes materially significant. Such discrepancies distort financial statements, compromise the accuracy of fiscal period-end reporting, and could lead to regulatory non-compliance or audit findings.

Furthermore, the issue introduces inefficiencies as teams may need to perform manual corrections, increasing workload and the risk of errors. Addressing this problem promptly is crucial to ensure the integrity of financial reporting, maintain stakeholder confidence, and reduce operational inefficiencies.

Please refer to the work item 979192.

When we try to post a project invoice proposal, and then he cancel the posting from the popup screen, the invoice proposal data change to different invoice. It has been identified that the current system may cause confusion among end users during the invoice posting process. This confusion could potentially result in incorrect postings, which in turn could have significant implications for financial accuracy and operational efficiency.

It should be possible but we are unable to create a custom price list when the price list contains a Bundle product.

User's are unable to apply discounts or custom rates due to this missing feature

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.

In the business process where the user updates attributes relating to project transactions, often in bulk, the simple yes/no option under Sales price update is insufficient.

Some transactions it would be appropriate to recalculate the sales price. For PO item transactions, this is problematic because the price for recalc coming from the released product rather than the PO means that the sales price is missing in the case of service items, where one service item is used for multiple purposes and will never contain a sales price against the released product.

In the case where you select Yes for an item transaction, the Sales price is recalculated from the details against the released product record, and does not respect the calculation for sales price already carried out for the purchase transaction on the purchase order. In the case of service items where we do not hold any prices against the items, this will always calculate as zero when referring back to the released product record.

The impact is zeroing out a sales price which should be non-zero, this has significant impact on both sales invoicing and accounting as the billed amount will be lower than expected, meaning that the only feasible alternative is to select No therefore making it impossible to make sales price adjustments to service item transactions on projects.

If this function was adjusted to be parameterised to respect source transaction (e.g. Purchase Order) price rather than released product price, this would be a significant improvement.

If the owner/creator of a project leaves the company and their account gets disabled or licenses and security roles removed, no other user can manage the project's tasks. This requested change would eliminate permissions checks on project owner when another authorized user attempts to work with the record. This would allow someone else to work with project tasks where the project owner is no longer with the business.

If the owner/creator of an invoice leaves the company and their account gets disabled or licenses and security roles removed, no other user can manage those invoices including revising. This requested change would eliminate permissions checks on invoice owner when another authorized user attempts to work with the record. This would allow someone else to work with invoices where the invoice owner is no longer with the business.

Dual Write analytics

It will be really useful, if we have a Monitoring/analytics Tool for Dual write similar to Power Automate analytics. This should be able to scheduled and proactively provides the detail for Errors and warning around Dual write Mappings and integration.

Report or potential Tool should cover following area

• Plugin trace log for Dual Write Real time Integration from ProjOps to FinOps
• Dual Write Health Check for each Mappings running