Hi,
Does anyone have an elegant, scalable solution for storing alternative units of measure in Pimberly without creating a separate attribute for each unit?
For example, I need to represent the following for a product:
- EACH = 1
- BOX = 10
- CARTON = 100
- PALLET = 1000
The base unit (EACH) can be implied from the product code, so it doesn't necessarily need to be stored. The product may be sold in any of the alternative units, and we need to capture this flexibly in Pimberly.
Creating fixed attributes like UOM_1_UNIT, UOM_2_UNIT, etc., isn’t scalable some products may skip BOX or CARTON, while others might include additional units not yet defined. This rigid structure doesn’t accommodate variability well.
Any suggestions would be appreciated.
Thanks,
Colin
0
Comments
Please sign in to leave a comment.
Option 1: Using a product set to solve the problem
Solved issue: No but close.
By creating a new "Product Type" we can make specific "items" which are in of themselves the representation of the packaging we needed. (Ideal came mostly from Matt Freking in support team)
By taking this approach, we were then able to utilise the "Product set" attribute and the "link metadata" in order to load bespoke packaging dimensions which exist on the product level instead of on the child item.
This option was a good one as it mitigated the requirement for separate attributes and loading the initial data is relatively easy. The reason why we didn't continue with this option is that currently, mapping for the "link metadata" from an import file is manual and requires knowledge of the correct formatting of the "link metadata" value. At the point when we create product data, the complete data is imported and auto mapped thanks to the import template matching the Pimberly attributes, using "link metadata" deviates a little in the import process which can easily generate errors.
An alternative would be to load this data via a "Feed" as we can pre-map everything, however, this also deviates from the current process but it could be valuable should we change to a "Feed" in the future.
Option 2: Using decision table and expressions
Solved issue: Yes but requires attributes :(
By utilising the sequential nature of decision tables we were able to design a solution using a set of expressions. We currently have a solution where we pass a stringified json object on an API channel so we explored creating something similar as we discovered a few more challenges when trying to express the data so easy consumption into SAP ECC.
We needed to create specific attributes, some of which might not be completely necessary as some of the data can be assumed, such as the dimensions of a 4-way pallet typically is standardised or the minor variation doesn't generate an issue downstream.
We then pass this data into a decision table, the first part is mostly related to if we have "carton" data, if we do then we populate a text attribute with an expression formatted "nicely" to be sent on the API. The next rule within the decision table is then triggered if we have "pallet" data, this then adds to the end of the previous value in the text attribute data from the new expression. (concatenated)
{existing_data_from_attribute} + {new_expression_data}
As there are certain characters reserved for expressions, such as " we needed to use ' as a placeholder and this is also similar with curly braces. Once we have the complete data, we then use the "replaceAll" expression a few times to change the placeholder characters to the characters we want to use.
{complete_expression_data}|replaceAll \x5B \x7B|replaceAll \x5D \x7D|replaceAll \x27 \x22}
As mentioned, certain characters are reserved for expressions but thankfully, we can utilise hexadecimal values instead. In the end we are then able to construct the complete data that should "easily" slip into a standard material Idoc for SAP.
[{"SEGMENT":"1","MEINH":"CAR","UMREZ":"10","BRGEW":"5","GEWEI":"KG","LAENG":"100","BREIT":"120","HOEHE":"125"},{"SEGMENT":"1","MEINH":"PAL","UMREZ":"100","BRGEW":"19.1","GEWEI":"KG","LAENG":"120","BREIT":"100","HOEHE":"165"}]
Note, when Pimberly sends this via API, the double quotes will be escaped and the system which parses it, would need to only need to evaluate this string as a standard dictionary.
Although the cost of this solution is fixed attributes, the value of making it easy for users to import data is much more valuable. This solution is also quite scalable and easy to interpret should another admin need to alter it. For "calculated" attributes, we only need one as when we add data to the attribute, the decision table is able to consider the existing value and alter the existing value concurrently as each rule in a decision table is triggered sequentially. If required, we can also handle alternative packaging units, euro pallet and non-standard pallet instead of 4-way pallet, due to the rule based nature of decision tables.