When a discount is added to a project purchase order with a posting profile main account, other than the main account of the item used, the discount is ignored in the consumption of the related project budget.
This idea is to ensure that the discount is taken into consideration when consuming the project budget to prevent a data inconsistency between the project budget and actual spend.
An example of a scenario that is happening now: A purchase order with a line of 1250 dollar and a discount of 250 dollar (total of line is 1000) is consuming 1250 dollar from the budget while the actual spend on the project is 1000 (and correct). In this case, the idea is that the consumed budget should be identical to the total amount of the purchase order, taking the discount into consideration.
The word 'Estimates' have always been confusing for clients when is introduced to them first time. In addition a lot of clients use 'estimate' to actually mean the 'quotation'.
Now that the fasttab which holds the estimate have been renamed to 'Revenue recognition' it will be appropriate to start extending the renaming of the underlying objects as well.
- On the MANAGE tab, the 'Estimates' link can be renamed to 'Recognise revenue'
- Once clicked and the 'Estimates' form itself is open, that 'Estimate' form can also be renamed to 'Revenue recognition'.
Then maybe we can explore making the following changes as well:
- Estimate date > Revenue recognition date
- Estimate status > Revenue recognition status
- Estimate project > Revenue recognition project
There should be line discounts on project item transactions and project invoice in order to invoice items with use of projects item transactions. You often invoice item transactions which originate from project item journals and project purchase orders instead of using a project sales order.
You have trade agreements with discounts, and use for example both retail/sales orders and projects to deliver/invoice items to the customers. But since discounts are not fully supported in project module, then you need extra manual work to support both scenarios.
As-is there are discount fields on some project business documents, but you need discount fully implemented on all documents in order do fully support discounts in same way as using standard sales order, including transfer from project quotation to project. For example there are now no discount on item requirement, WBS, project invoice report, project adjustment etc.
There are also different behaviour when discount is used as-is, either the net amount is reduced with discount or the unit sales price is reduced with discount on the project item transactions. It should be consistent with net amount reduced with discount, with discount field in addition as on sales order. I have submitted this to Microsoft and it has been postponed - LCS link: https://fix.lcs.dynamics.com/Issue/NotFixed/1187145?bugId=3838627&qc=80d1139efec6e5968deca0fc4bae275f16a19c67ad29f3682eafb8d8f3ceeec2
A recent update based on KB3178570 made it impossible to change the project contract after project transactions were made. This was done to prevent a problem in a specific scenario. However, this also caused a regression in functionality.
All information from the project contract is stored in the project transactions, including the funding source. To that end changing the project contract on a running project should be possible. This allows users to change the customer (and other commercial details) of a running project for all new transactions. In the meanwhile the existing transactions can be invoiced based on the old project contract.
This functionality is even more needed since a funding source cannot be change while project transactions exist (which is good) and working with multiple funding sources is not allowed when working with item requirement and/or project salesorders.
Working with item requirements is not allowed if multiple funding sources are setup in the project contract that is attached to the project.
It would be very helpfull if a design change was made which allowed working with item requirements and/or project sales orders in conjunction with a project contract with multiple funding sources.
When an asset has been created from the project and additional cost to add life to the asset are incurred in a sub project then D365/AX posts these costs as another 'acquisition'. There is no possibility to select a different posting type such as acquisition adjustment or write up journal, etc.
Please make a corresponding enhancement with the next release.
Thank you and best regards,
Investment projects to create more than one asset - there should be a one to many relationship between the project and fixed asset
At present, an investment project can only be linked to one asset via the Estimation process i.e. there is a one to one relationship between the project and the fixed asset. This is limited. The reality in business is a single project will contribute to more than one asset i.e. there should be a one to many relationship between the project and fixed asset. For example, image a business develops housing estates. There would be an investment project for each house but there would also be a investment project to create the road which would go past all of the houses. Each house would get a allocation of the road. This is true of a Retailer outfitting a group of stores. The design concept for all stores would be developed in a single investment project and then each store would also have an investment project for the direct labour and materials relating to the store outfitting. At this end of the project, costs would be capitalised both at the design level and the individual store to individual store assets.
Lastly, the "Estimation" process for investment projects should be renamed to "Capitalisation".
Currently it is not possible to create a return order as an item task underneath a project. Als a return order cannot be related to a project. This would be a nice feature to add to D365 for Finance and Operations.
Currently, when a project is setup in a legal entity, the project manager must have an employment relationship with that same legal entity. This is a significant limitation, as global companies frequently ask project managers from company A to manage projects in company B.
When assigning project manager, allow the user to select from any global worker, and not only those within the project's particular legal entity.
The on-account transactions form holds lines for the different on-account transactions (Milestones, Deductions, Prepayment Journal lines, Beginning balances) depending on the project type. They can be created either via Billing rules or manually.
- Client may use it in different ways, and sometimes where this is being used to drive invoicing that has been based off quotation lines, certain clients may want to see the individual lines broken down into the elements of build-up as it was in the quote. This result in potentially having to create multiple lines on the on-account form.
- Also in a dense project hierarchy with on-account lines at different sub-project highlighting it at the top of the hierarchy can present you with quite a large number of lines.
- Users require a TOTAL field, which is a read-only summary on this form to show a total of the lines. This easily allows the on-account lines to be compared to either the forecast/budget/quotation lines that have been created.
- This can be implemented by choosing to provide a single TOTAL which considers all the different types of the on-account lines or a box each for each type of on-account and a TOTAL that represents the sum of the individual total.
- The TOTAL box should be able to reflect the correct totals in a mixed hierarchy of project types and the different levels within the hierarchy (ie be able to reflect the sums of all on-account lines from child projects within the hierarchy).
This will make a massive difference and improve efficiency of using this form.