From a technical point of view, updating an attribute will behave in a similar way to Referenced Inventory. In fact it reuses most of the API to do it.
In Referenced Inventory each time a box is performed the system creates a new attribute set instance on the fly by cloning the original one and setting the referenced inventory and the parent attribute set instance relationship. Then it runs a goods movement that changes the original attribute set instance by the new one (linked to the referenced inventory).
For attribute edition we will have a similar behavior: each time the user edits an updatable attribute, the Frontend will automatically create a cloned attribute set instance from the original attribute and will change the concrete attribute value in the cloned instance. The new attribute set instance will be associated to the task's Confirmed Attribute field. When confirming the task, the system will detect the attribute change and will perform the stock update at the same time the transaction movement is executed. In this case we won’t have a relationship with Referenced Inventory, but only with the Attribute Set Instance cloned from. The traceability feature can be activated on this table for auditing reasons.
In case there is an attribute set instance with exactly the same values as the new cloned one (including the attribute set instance cloned from), then the system will try to use existing one instead of creating a new clone. This can happen in 'delta same' scenarios, so we are interested in merging the storage details once the delta is completed.
These are the technical implementation details:
- AWOAttributeLifeCycleUtils.class: This is the main class related to Attribute Life Cycle project. It contains useful methods to manage it.
- AWOAttributeLifeCycleUtils.cloneAttributeSetInstance(final AttributeSetInstance originalAttributeSetInstance, final Map<String, String> newAttributeValues) method is in charge of cloning the original attribute set instance and to change the attribute values. It validates the change is possible before doing it. The frontend must call this method each time an updatable attribute is changed. The returned object must be set to the task's confirmed attribute before confirming the task.
- InternalMovementGenerator.class: This class is in charge of generating goods movements when confirming tasks. It has been extended to allow hooks execution. This was necessary to reduce class complexity after adding projects like Referenced Inventory or Attribute Life Cycle.
- AttributeLifeCycleManager.class: Hook implementation for InternalMovementGenerator. It is executed always after Referenced Inventory hook. It's in charge of populating the right field in goods movement line to allow the attribute change.
Developed more than 50 test cases for this feature. See AWOs_AttributeLifeCycleTestSuite.class for details