|
|
Before I create a JIRA for this I want to make sure that I understand the expected behaviour. Our situation is that we have a sales order with a product shipped from non-serialized inventory. If the customer now returns the order the magic begins ...
It appears that the "quickReceiveReturn" (when receiving inventory is required) will always set the statusId of the received inventory item to "INV_RETURNED" (unless otherwise specified on the ReturnItem). The trouble here is that strictly speaking, INV_RETURNED is only valid for serialized inventory (according to the StatusItem seed data). And if you were to create a ReturnItem with an empty expectedStatusId, the service would go ahead and override it to INV_RETURNED on you.
Business Process time -- is the line of thinking here that all products that are received create inventory item records with this status and it is up to the company to check these and change their status to something more applicable (blank for non-ser and INV_AVAILABLE for ser?).
Our business process is going to dictate that when a return is explicitly returned, we are going to consider that inventory "re-stocked" and we will want services that return the available counts to properly reflect the returned goods. If I was to set the return item's expected status id to INV_AVAILABLE (while not valid according to StatusItem) it would at least be properly reflected in services such as getProductInventoryAvailable.
Perhaps the solution is to allow "INV_AVAILABLE" and "INV_RETURNED" as valid statuses for non serialized inventory (or some variant of those).
Thoughts?
|
Locked
