Tested on:
Dynamics 365 CE version 9.1, PSA solution version 3.2, Unified Interface
In Part I of the Pricing Dimensions article series I covered the basic idea of what MDP is and how option set based Pricing Dimensions work. Part II of the series will focus on entity based Pricing Dimensions as well as on using fields that already exist in Dynamics 365 Project Service Automation as Pricing Dimensions.
Entity based Pricing Dimensions
Entity based dimensions give flexibility in scenarios where Bookable Resources may have varying characteristics that define pricing. Microsoft’s Pricing Dimensions Setup Guide covers entity based dimensions in a context of a Standard Title and that’s also what I have used and included in my solution package so that Microsoft’s guide can be referenced for additional in depth information. Another example of an entity based pricing dimension could be a proficiency rating with values between 1 and 10. Sales and cost prices would depend on the proficiency of a person. This information – much like in the case of Standard Title – would be stored under a Bookable Resource record.
Enabling entity based Pricing Dimensions is pretty straightforward and described very well in Microsoft’s guide. What’s important to comprehend about entity based dimensions are the uses cases compared to option set based dimensions. Option sets are great for dimension values that are static but vary between Time Entries. Work hours is a good example. 90 % of the week might be standard hours but on a certain day a few hours are overtime and the dimension is markup based. Usually a person chooses an option set based dimension at Time Entry.
With entity based dimensions the value of a dimension doesn’t change between Time Entries. A person’s pay grade may only change once a year and a person doesn’t necessarily have to select between any dimension values at Time Entry. Entity based dimensions are most likely managed by managers and directors etc.
Use case – Entity based Pricing Dimensions
John Doe works as a Project Manager on a project. His Standard Title defines the sales and costs prices for his Time Entries. Option set based dimensions are used for Work Hours as well as Work Location. A Quote can be used to identify how changes to Price Lists affect pricing on a Quote that doesn’t have custom pricing created for it. After Time Entries have been approved, Actuals are used to verify that all prices and dimensions are correct.
Existing PSA fields as a Pricing Dimension
Existing fields such as Bookable Resource and Transaction Category can be used as Pricing Dimensions in PSA. The setup for forms and views is the same as with custom Pricing Dimensions. With Bookable Resource there is a difference in the field name between Project Team Member and Role Price and Role Price Markup entities (msdyn_bookableresource vs. msdyn_bookableresourceid). The pricing dimension record for Bookable Resource must be made aware of the difference in field names. Microsoft’s guide has a section on how to settle this difference.
When Bookable Resource is set as a Pricing Dimension the next step is to set up both Cost and Sales Price Lists and validate them by creating a new Quote. As Time Entries are approved, the prices and dimensions can be verified on Actuals.
This two part article series has covered option set based dimensions, entity based dimensions as well as existing PSA fields as dimensions. This new functionality, introduced in PSA version 3, takes pricing to a whole new level in PSA. I strongly recommend everyone working intensely with PSA to learn MDP. It has a lot to offer.
My updated managed and unmanaged solutions for MDP can be found from the TDG Power Platform Bank here. The updated solutions include Bookable Resource as a Pricing Dimension as well as a minor bug fix around fields missing on the Journal Line entity’s form and views.
Disclaimer:
All my blog posts reflect my personal opinions and findings unless otherwise stated.