When you have a customer project that is linked to a sales order with both fixed price and time & material items you may run into figures which look strange at first sight. Well, to be honest, also at second sight they might look strange. But there is no way to change that because of ByDesign customers using projects in a manifold of fashions.
I will explain why this is so and what the remedy is.
This is the setup
- Consider a sales order (SO) with two items, one is a fixed price item the other is a T&M item.
- Now create a project from that SO and let the system create one task for the fixed price item and one task for the T&M item
- Assign accrual method “108 – Recognize using cost-to-cost project PoC” to the fixed price SO item
- Perform a time recording with respect to the project task that points to the fixed price SO item
If you now run the revenue recognition for the SO in question you will end up with this situation:
The time confirmation performed created deferred cost of 100 USD. These were recognized with the revenue recognition run as internal service expenses. At the same time revenues of 150 USD were posted. Why 150 USD? When you look at the system documentation you will find that for accrual method cost-to-cost project PoC the PoC in this case is determined as follows: PoC = Total actual cost for SO item 20 / total estimated project cost. Thus, 150 USD = 100 USD / 200 USD * 300 USD (net value of SO item 20) is the documented but maybe not expected result. You probably expect 300 USD since 100% of the planned work has been performed.
Reading through the documentation you will find that the authors anticipated this expectation and recommended to go for manual accrual methods and then manually adjust the PoC.
Now for the rationale behind this. You might have noticed that I only talked about fixed price SO items and not fixed price project tasks. There is a good reason for this: There is no such thing as a fixed price task in ByDesign! The project itself – the execution related part of your customer engagement – is agnostic of how expense recordings will be dealt with in Financials. The system defines a set of default rules how expenses recorded with respect to a project task are mapped to a sales order item. Thus, it looks like task CPSO39-2 is a fixed price task. But, you are free to introduce additional rules for different types of expenses and can even manually reassign recordings in the not yet invoiced time and expenses work center view to other sales order items. Once you have more complicated project structures – and by the way: the project structure does not necessarily have to follow the sales order structure – the situation gets worse and the mapping of planned cost to SO items is sort of unforeseeable.
But since I promised you a remedy, here it is:
Use accrual method “102 – cost-to-cost PoC” instead.
Then you will get the expected result: 1 h recorded, 100 % of planned work for task CPSO39-2 gives a PoC of 100% and thus a revenue that corresponds to the net value of SO item 20.
Admittedly, this approach requires you to maintain a price component in the sale order item for the cost estimate, but the benefit is that you get what you expect.
When you use the project-related accrual method this is something that comes for free since in this case the system always accesses the currently planned cost of the project. But as explained above, there is no easy way to map the project tasks to the SO items and thus to automatically fill the cost estimate in the SO item.