Welcome back to the second last (🥹) Episode of the Project Operations Advent Calendar! 🎅🏼
It's the 23rd article in our series and today we look into my favorite Project Operations feature.
Pricing Dimensions
Yes, we talk about pricing dimensions. First, let's clarify what they're even doing and why I like that feature so much.
As the name implies, we are in the pricing area. Pricing Dimensions define how bill, purchase and cost prices are applied. The out-of-the-box setup is available with the installation of Project Operations in the Project Parameter (1)
There are two types of dimensions available, Amount Based (2) and Markup Based Pricing Dimensions.
Because the system ships with Amount Based Pricing Dimensions, we will highlight them today. Markup Based Pricing Dimensions fulfilling the same purpose only applying a percentage price on top of a base price. So in general, if you looking into percentage based pricing, Role Price Markups and Markup Based Pricing Dimensions would be your place to be.
For Amount Based Pricing Dimensions, Microsoft already preset three by default. Bookable Resource, Organizational Unit, and Resource Category (Role) (3).
The Dimension Name is always given by the Schema name so don't get confused there - sometimes the Display and Schema name doesn't match in your environment.
Especially when we talk about industry-specific solution implementations.
Each single Pricing Dimension can apply to either one or more of the three different categories of Cost, Purchase, and Sales Pricing (4).
That enables different use cases in terms of pricing across each type of price list type on the very same environment.
You could drive an easy-to-understand billing pricing for customers, e.g. one global hourly rate that can be communicated. While having a quite individual cost price calculation to stay ahead of your real costs in planning.
With each of the applicable areas, a Priority (5) can be defined. This priority helps resolve the different columns on the related tables when the pricing is established.
So based on the priority (1 = highest priority) the system tries to find a fitting Role price on the desired Price List.
If there is no match on the first try, the condition with the lowest priority gets dropped and matching starts again.
That again enables the case to register a single base price on the price list without any conditions:
Either as a fallback or base for markups.
While multiple Role Prices per Pricing Dimensions can be established to configure different scenarios, like here, where the Organizational Unit (here: Resourcing Unit) is considered twice for the Consultant Role with different pricing output, even different currencies.
Example
In the generated cost Actual the Role (msdyn_resourcecategory) and Resourcing Unit (msdyn_organizationalunit) are set with Solution Architect Role and the proMX Demo Unit.
Just to remember, Role and Resourcing Unit are the two values are the Pricing Dimensions applied for cost calculation:
In the Actual, the pricing will be determined based on the Price List USD Cost Price List as linked in the record:
The price is listed as 120.00 USD here and with the Quantity of 2 Hours, we end up with a total Amount of 240.00 USD.
Let's double-check this with the price defined on the cost Price List:
On the Price List, we can find the Solution Architect Role defined with 120.00 USD in the Role Prices tab but without any Resourcing Unit.
For our example, the 120.00 USD per Hour is applied correctly, because we had a Role Price defined for the specific Role that was assigned to the Employee.
What happens in Price generation is that the System was searching first for a combination of our Pricing Dimensions (Solution Architect and proMX Demo) but while couldn't find any, the Dimension with the higher number in Priority (20 > 10) got dropped.
The second matching trial was only considering the Role - Match!
We find the Role price for Solution Architect at 120.00 USD.
What if we would have a Role price with a matching Resourcing Unit?
=> In this case the first run would've been successful already and that price would have been applied to the Actual.
What if there is no Solution Architect Role Price in the Price List?
=> In our case we have one role price set up with no Resourcing Unit and no Role definition at 90.00 USD, so we would receive some price - if this is correct for that specific Actual is a different Question. But in the worst case, the system can't find a valid Role price which results in 0.00 USD for the Actual.
Custom Pricing Dimensions
And the best thing about Pricing Dimensions is, and that's pretty sure the reason I like it so much, you can establish custom dimensions!
In the Parameter, you can simply add additional columns from the system for the pricing calculation.
The condition for the new dimension is that the field is available on the following tables:
Actual
Bookable Resource
Estimate Line
Project Task
Invoice Line Detail
Journal Line
Project Contract Line Detail
Project Team Member
Quote Line Detail
Role Price Markup
Role Price
Time Entry
Also, feel free to explore the documentation about this topic in general. Thereby it doesn't matter if the desired field is a lookup (referring to another table), Choice (former Option Set), or any other type.
What if the schema name for the already existing column is different on these mentioned tables?
=> That will happen, pretty sure. But there is a solution. On the Role Price itself, there is a mapping available to define these offsets in naming conditions:
For each required table it's possible to set the correct name. In the example of the Organizational Unit, not one of the columns is named msdyn_organizationalunitid in that context - still, it works based on the Pricing Dimension Field Names mapping.
Your Custom Pricing Dimensions
But wait, there is more, and I feel guilty that I didn't tell you earlier. You can bring not only existing columns in the price resolving process, but you can also bring your own custom columns or tables.
Just consider the same rules as for any other new field you add as a pricing dimension - the information must be available on the mentioned tables.
The feature is highly adaptable for any situation, making it customizable in real time. Additionally, the feature is easy to use and aesthetically pleasing. Despite its initial complexity, it has become my favorite feature in Project Operations.
I hope you enjoyed the second last episode, many thanks from my side for stopping by 😊
And catch you tomorrow for the grand final 🎅🏼
Comments