Adjustment reasons for unpacking kits


(Elias Muluneh) #1

A kit, is a product/orderable and it’s stock level can be managed in the stock management service just like any other orderable. Facilities will be able to receive, consume or adjust it’s stock status in the stock management service. In some cases, the facility may decide to “unpack” those kits and consume the constituent products. When facilities unpack kits, the stock level for the constituent products will be incremented by the amount contained in the unpacked kits. The unpack list introduced in the reference-data service will be used to calculate this amounts. This assumes that the constituent products are also being managed in the stock management service.

The following questions are option questions that I am seeking feedback on.

What adjustment reason should be used? When unpacking a kit, the stock level will be considered to be reduced. This consumption however, is not a direct consumption. To properly record this, there is need to introduce a new adjustment reason. What should this adjustment reason be?

  • Unpack-Debit? (tagged consumption?)

What reason should be used to increment the constituent product’s stock? Assuming we used the unpack reason we introduced above to decrement the stock of kit, what adjustment reason should be used to increment the constituent product’s stock?

  • Unpacked-Credit? (tagged receipt?)

What should the category of these adjustment reasons be? should we consider those adjustments? or introduce a new category (Unpack?)

A new criteria: These adjustment reasons are specific to kits. (products that have children). How should this constraint be expressed on the adjustment reasons? should we have a flag to this effect? From the current design, do we consider these reasons not "Show"en?

Linking adjustment reasons: I did not find examples of adjustment reasons where two reasons are linked in any way. The adjustment reasons discussed above may need to go together. When “Unpack-debit” is used on one side of the transaction, the unpacked-credit is always expected be used to increment the stock of constituent products. How should this relationship be expressed in the design of adjustment reasons?

@joshzamor this post captures the questions that I briefly tried to run by you. If you get a chance to think about the topic, I appreciate your feedback.


(Josh Zamor) #2

Thanks @Elias_Muluneh,

I’ve had a few minutes to think through some of this but not really what it deserves.

I think this is key. Part of the design goal of StockEvents was to capture business events such as an unpack transaction where one action should enter both a credit and debit into the ledger. My recollection of how far we got with StockManagement is a bit fuzzy, however I do believe that one of our sticking points was figuring out adjustment reasons within this context.

GS1 EPCIS has some conceptual overlap with events that occur in Stock Management, particularly an aggregation type event could be thought of as an overarching event type for actions such as (un-)packing a kit.

If we solved for this problem I feel that solving for the previous questions would be simpler. Thoughts?

I’m headed out of town here so I won’t be able to support as much as usual. I don’t want to throw a big design wrench into what we have left, and realisticly our current requirements are pretty simple, so perhaps a stop-gap measure which provides less configuration for this type of “reason” would work.