There are two table maps each Mapping the fields of InventDim to concrete fields on other tables and entities: InventDimFieldsMap and InventInventoryDimensionEntityFieldsMapping. These maps provide common inventory Dimension features such as copying and resolving dimensions.

When you add a new inventory dimension, like Flavor, you must add Flavor fields to many tables and entities and map your field to a generic dimension field in these table maps.

Unfortunately; the platform has no support for creating such mappings – and if it did it would not be ideal for inventory dimensions. The problem is that the mapping is implementation specific (i.e. a job for the VAR) whereas the introduction of the field is solution specific (i.e. a job for the ISV).

Figure: It is not required to explicitly map generic Inventory Dimensions.

In 10.0 we have solved this problem in a quite elegant way.

All methods on both maps have been adjusted to not only take the explicit mapping into account; but if a field is not mapped, it will search the table for a field with the right EDT. This is the same logic that is already applied in many inventory dimension scenarios – see the InventDimension.fieldIdOnTable() method for implementation and references.

This means the only action required is to add the dimension field as an extension, and the map will automatically pick it up. No explicit table mapping is required. Everything related to the mapping can be handled by the ISV.

Note

You still need to do the binding to the InventDim fields. For example, using a computed string field.

This blog post is provided AS-IS; and confers no rights.