Oracle CPQ Cloud is a SaaS (Software as a Service) product that allows extension of the functionality using the built-in tools, JCS - SaaS Extension, or both. By default the system comes with standard attributes, a commerce process, rules, integrations, layouts, document outputs etc., but to really make use of the full potential it should be adapted to the specific business. Most of the times the integration process involves several developers, each of them having different technical background. Because of this it is very important to have a policy on naming convention in place before the project kickoff, so that all the team member understand it and can adapt to it. This will save a lot of time during development as there will be no need to ask around the about an attribute, a rule, a function, a document or anything else related to the system as everything will be clearly named . In long term this will extremely augment the team productivity when the time comes for testing, debugging and especially the maintenance of the system.
You can find official Oracle CPQ Cloud documentation on this subject in the help section of your instance, but I want to analyze few critical considerations that will help you and your team avoid common pitfalls.
Attributes can be created at different levels which creates a layer of confusion when the engineer is trying to access it in code, Document Engine or Document Designer. This is why it is good to mention in the variable name of the attribute it's level. We suggest that you adopt the habit of adding a suffix to specify the level of the attribute like so:
- Example Attribute (exampleAttribute_cf) - where cf represents the Configuration Product Family
- Example Attribute (exampleAttribute_cl) - where cl represents the Configuration Product Line
- Example Attribute (exampleAttribute_cm) - where cf represents the Configuration Model
- Example Attribute (exampleAttribute_cl) - where cl represents the Configuration Product Line
- Example Attribute (exampleAttribute_tq) - where tq represents the Transaction/Quote
- Example Attribute (exampleAttribute_tl) - where tl represents the Transaction/Quote Line
Rules can also be created at different levels, but we suggest that you try to create them as high in the product configuration hierarchy as possible because it will allow a rule to have access to all attributes below it. Having this in mind it is important to specify in the rule's variable name which model or line it refers to. Also we advise to make the name of the rule as descriptive as possible. For example:
* Suggest Software System by Package for Example Model (autogenerated1_exampleModel) - as a set recommendation rule
* Imply Software System when loaded for Example Model (autogenerated2_exampleModel) - as a force set recommendation rule
* Mandate Parts for Example Model (autogenerated3_exampleModel) - as a set recommended items rule
* Filter State when Country is USA for Example Model (autogenerated4_exampleModel) - as a set recommendation rule
* Hide OS when Vendor is REDHAT for Example Model (autogenerated5_exampleModel) - as a hiding rule
* Validate OS is WINDOWS when Vendor is Microsoft for Example Model (autogenerated6_exampleModel) - as a validation rule
Note: when you have multiple attributes to set make the rule more general and specify the attributes in the description.
Oracle CPQ Code can be written in a way that it can be easily read and understood. Make use of proper names when creating functions so that those could be reused whenever similar functionality is required. Another good idea is to group the functionality when the function is becoming big so that it's easy to spot where and how the values are changed.
—
Do you think there is something missing or incorrect?
Let us know and we’ll be happy to update the post with your comments and mention your name.
Comments
Post a Comment