Dynamics 365 Project Operations

I have requirements to financially post discounts to a different GL on projects. The discounts would be coming from item requirement sales orders. I would like to see the Category Groups and Project Category Groups extended to be able to specify a GL account for discounts, similar to what is currently available for item group setup for sales orders.

The project invoice form for the GST group is currently generating inaccurate values for each invoice.

When we attempt to check the GST group in Visual Studio, the data is processed for localization purposes, which causes the incorrect GST group to display, rather than the correct GST group associated with the lines in the invoice.

As a result, we are required to review each invoice individually to confirm the corresponding GST group, which is proving to be an inefficient and time-consuming process.

As organizations transition from Project Service Automation (PSA) to Project Operations (PO), they often encounter various errors that can disrupt the upgrade process. To streamline this transition and minimize downtime, it would be highly beneficial to have a comprehensive master list of potential errors, their root causes, and detailed steps to resolve them.

Benefits

• Reduced Downtime: Minimize disruptions during the upgrade process by proactively addressing common errors.
• Improved Efficiency: Streamline the upgrade process with clear guidelines and steps to resolve issues.
• Enhanced User Experience: Provide users with a smoother transition from PSA to PO, reducing frustration and increasing satisfaction.

In D365 F&O, when a project is selected in an Item Journal line, the financial dimensions are inherited from the project master record and applied to both the debit and credit sides of the voucher posting. By default, the system debits the project for the cost and credits the transaction based on the item’s inventory posting which is balance sheet. Most of the times, customers use different account structures for Balance Sheet and P&L accounts and item journal can fail to post. By providing a separate offset account string for items, this error can be avoided, and client can use different financial dimension combinations for "Inventory-issue" type side of voucher posting ONLY. 

Example:

Preconcepts:

• Site is configured with a Financial Dimension.
• The Financial Dimensions configured for Sites have also Derived Dimensions values.
• When an order is created (PO or SO) and a Site is selected, all financial dimensions are populated based on the derived dimensions.
• Projects are configured with financial dimensions as well (different than Site financial dimensions).

When an item consumed against a project using an item journal, the credit side of the voucher posting to derive financial dimensions based on the Item’s Site. Customer has linked the Site inventory dimension with a particular financial dimension and configured Derived Dimension values accordingly. Expectation is for the system to inherit financial dimension combinations from the Site inventory dimension for the credit side of the transaction ONLY because the credit line is an inventory-issue type posting. The same behavior is expected if the item journal line has a negative quantity (inventory capitalization) but in this case the financial dimensions will be used on the Debit side of the transaction ONLY.

Note: This new posting logic could be parameterized, for the clients that want to use the current posting logic, this parameter must remain as "No", but for the clients who sees this a good opportunity they can use this parameter to follow new logic.

Project forecast transactions do not include indirect cost considerations, so the total cost forecast is not aligned with the actual costs when they are posted. Because the forecast lines include all the necessary variables to rationalize indirect applicability, forecast transactions could/should include those costs.

In D365 F&O, when a project is selected in an Item Journal line, the financial dimensions are inherited from the project master record and applied to both the debit and credit sides of the voucher posting. By default, the system debits the project for the cost and credits the transaction based on the item’s inventory posting which is balance sheet. Most of the times, customers use different account structures for Balance Sheet and P&L accounts and item journal can fail to post. By providing a separate offset account string for items, this error can be avoided, and client can use different financial dimension combinations for credit side of voucher posting. 

Example:

Preconcepts:

• Site is configured with a Financial Dimension.
• The Financial Dimensions configured for Sites have also Derived Dimensions values.
• When an order is created (PO or SO) and a Site is selected, all financial dimensions are populated based on the derived dimensions.
• Projects are configured with financial dimensions as well (different than Site financial dimensions).

This implies the credit side of the voucher posting to derive financial dimensions based on the Item’s Site. Customer has linked the Site inventory dimension with a particular financial dimension and configured Derived Dimension values accordingly. Expectation is for the system to inherit financial dimension combinations from the Site inventory dimension for the credit side of the transaction ONLY.

Note: This new posting logic could be parameterized, for the clients that want to use the current posting logic, this parameter must remain as "No", but for the clients who sees this a good opportunity they can use this parameter to follow new logic.

Currently, there is no function to delete achievements, and there are no realistic plans to implement this function.

There is a restriction on achievements that prevents achievement data from being deleted from the system, and this is set to protect the integration with financial and accounting functions in project management.

As a result, this restriction cannot be lifted, and achievements cannot be deleted.

In addition, the project itself in which achievements exist cannot be deleted, and due to a design issue, there is no workaround.

However, a lot of data is stored during the course of work, and capacity is consumed every day.

For this reason, being able to delete unnecessary projects with registered achievements and achievements that are no longer necessary can free up some data capacity, and the ability to delete achievements is also convenient in terms of data management.

So, we hope that the function to delete achievements will be implemented.

Create a parent project and a Subproject. Same Project group but different dimensions. 

Register a cost for parent project.

Adjust the transaction, to move cost from Parent Project to Subproject. 

GL records incorrectly, original entry is not reversed.  

Expectation: the original entry should have been reversed, the correct accounting with proper dimensions to be created and post to subproject.

Support for advances and retainers on subcontracts

Be able to trigger the print management of FO to communicate the purchase order confirmation. Verdord need the purchase order number from FO to make their invoice with our purchase order number so it can be matched automatically.