Software consists of 3 major parts:
- Custom Code Value Definition and Constraints
- Configurator changes to allow entry of Custom Code Values
- Rule processing in the BOM for passing Custom Code values to Child Items
Custom Code Value Definitions and Constraints:
You define Custom Code values under Product Definition Column COde Definition. A new or existing Column Code can have its checkbox checked that says it is a COde that allows Custom values to be input. Checking the box means if this Code is selected in the Configurator, a manual input is required to make the item. No exceptions to that rule.
When you check the box, new Definition fields will appear:
The above is for a Character Type of Custom Value(like a Finish Description). Custom Value Prompt is what will appear in the popup window to accept the value in the Configurator.
You can also have a Numeric Type of Custom Value. It has a couple of additional Definition values:
Min and Max values are inclusive, and is the only edit you have for the value(you can't make it conditional on a window size or some other variable, since this is not a formula).
The UI for this is simple and doe not need a lot of exercising.
Configurator changes to allow entry of Custom Code Values:
Here's where you need a testing checklist. When you Configure a window and select the custom value in the Select Pane, you get a popup to allow you to enter your value and click Save. Simple. Now let's list some of the scenarios. I recommend you do this through a Quote, since that is the 99% way to access the Configurator by users. Setup your Product Definition to have 2 Custom Values in the same column (like Kynar1 and Kynar2).
- Brand new Quote, first line added.
- After added, click on it and add a new line. Should come up with the Custom Value set and in the description.
- Go off the Custom Code(pick a regular code) and Save.
- Select the plain line, add a new line. Select the custom code and give it the same Custom Value as the first line. Save (we'll check that it found the same item later).
- Add a new line and give it a Custom Value and Save.
- Edit that line and change the Custom Value and Save.
- Edit that same line and change the Custom Value to a regular selection and Save.
- Change the line's Custom Value to the second custom value (K1 to K2), and put in the same Code you used for the K1 in the first one. Save (we'll check the ItemCode later).
- Try to get out of the Configurator by setting a Custom Value, going off the column, resetting it, and trying to save without having a valid Custom Value. Check the description and display for irregularities.
Rule Processing in the BOM:
When we pass Column Codes down to a Child Series, we currently use c[x] to be the value of the Parent Column. I have created a new "variable" to contain the Custom Code Value (if any). It is cxv[x], where x is the Column number. I have also added a new place to put a formula in the BOM when you're defining the Child Column Values:
In this case, we are passing down the Custom Code Value into the Finish. Notice that I don't have to condition the formula. In the Case that the Parent did NOT have a Custom Code Value, this is still OK - it just passes in a NULL value (which is correct for any Column Codes that are NOT Custom Values).
If cxv[3] is defined and has a value (because the Parent item was using the Custom Code in the Column and a Value was set in the Configurator (or passed down from a Parent), then it will be defined in the Child as well. So Custom Finish can be passed down to all the Matrix items that need to get it, resulting in the cut parts showing the Finish as the Parent's Custom Code value (i.e., "Blue Kynar Paint").
I have built in the 10SH in the 560800997155 login 2 custom finishes, and entered the BOM rules down to the SH Frame Head, so if you go in and configure the 10SH, give it a custom color, and click ShowBom, you will see the Frame Only and the Frame Head Cut Part come up as the custom color you put on the Parent. Pretty cool!!
WARNING! Even though I have given you the cxv[x] value, it will not be a good practice (at least for the character values like custom colors) to try to condition things based on the values. They are entered by humans with no checking, so you will get "GREEN", "GREENE" "GRN", etc. as entry values. For color, these should only be considered "notes" that we can pass down into the BOM. But for numeric values, you should be able to write some tules based on the entered Custom Values. Suppose the Custom Value is the Brickmold Width, which can be from 4 9/16 to 10" , and when it is over 6", we have to add a new BOM component to support it. In that case, you could write a rule condition that is something like "cxv[5] > 6" for the added piece's condition rule, and that should work. The value will ALWAYS be attached to the "Custom Code" in the column, so if the CustomCode was a "C" for Custom, you should really write the rule like c[5] = "C" .and. cxv[5] > 6. This is because NULL values can be tricky for the formula parser to handle, and if c[5] = "C" (or whatever the Custom Code is), then you are guaranteed to have a value in cxv[5] - don't use cxv[5] alone EVER!