Hey CPQ gang,
Wanted to fire up a topic over here, to get some activity with the super cool folks that do CPQ. What better topic than the use of JSON in a field on the form to store your Pricing and MoM data?
We are using this method so that our Pricing is based on the same data we are feeding to Kinetic for the MoM.
Anyone else using a technique like this?
We are very early in our CPQ implementation (KBMAX team is still building the prototype config). How do you go about accomplishing this?
Tory,
Isn’t that how CPQ does it now? Stores all the configurator info as JSON, then passes the blob over to the Quote in Epicor?
Yes behind the scenes for sure it uses JSON, but instead of building Pricing rules manually, then repeating those similar steps to build the MoM. For us it would be essentially creating the same thing twice in two sets of rules. Prone to making errors, inconsistencies, and not getting updated at the same time.
So we build a JSON string once in a Value Rule and store that JSON string in a Field in the Configurator itself, then for the Pricing rule, and MoM rule we parse the same string to build those items as needed. This way they are both referencing the same parts/operations and if we ever make changes only one place to make changes.
That’s a great idea! Anything to reduce the duplicate programming will help mistake-proof building out CPQ…
If you are working with the Epicor CPQ team they might be familiar with this method.
We add a field to the configurator, at first we leave it visible for debugging, but eventually we will turn off visibility.
We create a value rule that stores all the Materials and Operations as types into a JSON string and set the value of the field to that JSON string.
In the Pricing rule you will parse that JSON string and do the normal pricing of parts out of that string.
Then in the MoM rules we also parse that JSON string from that field and appropriately add Kinetic Materials and Kinetic Operations from the parsed string.
I know I am speaking very high level here, there is of course some detail to those steps like building types for materials and operations that will include values for whether the item added to the string is a Material or an Operation, also may want to add values to the JSON string specific to Pricing vs. MoM values.
That is good to know. We’re contemplating CPQ as we move to Kinetic. What I saw this year at Insights was very promising for us to build the MOM/BOM dynamically and store all the variables needed back in Kinetic.
We do something very similar. We have a Global Type called “Part” which contains all of the data we need (part number, qty, etc.) We use a Global Function to generate and return an array of Parts. The Method and Pricing Rules each call this function and run their own logic to produce the MoM and Price Object from the same data source.