Phase 2: Inventory Management functionality is moved completely out of Products and into Inventory
Why?
confusing to users? / cleanness
related to our general problem of being too many places to do things so is confusing to people to have multiple
also we have increasing number of use cases where is going to be better for people to work with inventory . . so is there a clear case for actually keeping / maintaining ‘core’ P/V inventory settings
Concerns: if we do this, we no longer have a ‘core product / variant’ combo, from which inventories are set by default. To recreate this, we would have to build something that tells a stock level which inventory list to read from
What
The Products interface would carry only the product’s identifying information - only the more static information describes it, but not the more dynamic information about stock levels, price etc
People would then manage stock and price exclusively via Inventory
Add group buy to variant level, and enable hub control through inventory interface - NOT DOING
[upgraded note following conversation between me and @oeoeaio] - enable ‘mirroring’ of another Hub’s inventory list e.g. - NEXT UP
inherit products and variants that are on/off; stock levels; prices
option: check boxes / some way to say which things you want to copy across and which you want to keep as your settings (would this mean you are actually trying to merge a new list with an existing ‘own’ list?)
permissions should be same as P-VO
Add variant to inventory list - Hub / BG can control their own variants
From one set of overrides to one or more ‘inventory lists’
Enable Hub to have multiple ‘lists’ (for handling different selections of products)
Hubs can share lists
An inventory list can “inherit” from another - ie. price/inventory information flows between lists if that is the desired behaviour
@Kirsten, we have already talk about this, and I fee like there is always something wrong with my ideas that fundamentally breaks something but I cannot for the life of me remember what it is. Let’s have this conversation here and then when we break it, it will be documented.
I think a bigger overhaul is necessary. Variant overrides (or Inventory Units?, available in Spree 2.0) could ultimately allow us to separate the concerns around the retail specific properties of a variant (ie. price, on-hand, on-demand, skus, photos?) from the more fundamental properties of a variant (weight/volume, producer, name, description, properties, photos?, etc.).
The first set of properties are really the concern of distributors and so I think they should be able to be stored on the variant override model and made editable per distributor. They are more likely to be changed or edited after the variant is created and with higher frequency.
The second set of properties are really the concern of the producer. They probably don’t really change, and we really only want someone who knows what they are talking about (ie. owner or manager of the producer) to be able to change them. They are more likely to be set once and then pretty much left alone.
The two main issues that this raises for me are:
We would need to be able to “share” variant overrides between distributors, in order to share stock levels (on-hand). This seems doable.
In order to maintain price transparency, we would need to retain some of concept of a “base” price for the normal variant, which is only editable by users who can modify a producer’s products directly. That way any changes to the price of a variant override can still be flagged as a ‘markup’ by the distributor if the don’t explicitly assign enterprise fees.
Good things about this separation:
You always know that when you are changing the price, on-hand, etc that you are dealing with a variant override, because all of the prices and all of the on-hand counts in the system are on variant overrides.
We can split the products interface into two:
One for high frequency day-to-day updating of prices and stock levels (ie. a list of variant overrides, which I like to call “inventory”), and;
Another for altering the fundamental properties of variant
I actually think we need a third, for distributors to select variants from a list of those available to them to pull into their inventory list?
Other things to think about:
Would be great to be able to “hide” inactive products/variants, especially on the variant override / inventory page.
How do we allow producers to log into the system and update their available inventories in a way that flows through to relevant shops? I think this is something we solve with permissions, where distributors can grant producers permission to update relevant stock levels in their inventory.
What are the implications for adding new products to an order cycle? A distributor would first have to create a variant override for a given variant before they could go into the order cycle interface and add it to an exchange, rather than just selecting a variant from their list of permitted products as currently happens. There may need to be a rejig of the OC interface to allow a user to add a variant override on the fly?
Also, in terms of usability of interfaces: PANELS!
Not sure if we already covered this idea or not, maybe you touched on it at the end of this comment, but it just either came flooding back to me or crystallised in a magical new way my head: if we have inventories (ie. lists of variant overrides at the moment), that record the price, and stock levels for each variant available for sale by a hub (or set of hubs if we can share the lists), why don’t we just use this interface to control the actual availability of variants in the relevant shop(s)? If we can use the inventory interface to set the stock levels and show/hide variants for a given list, we shouldn’t need to double handle that information by turning variants on and off in the order cycle interface, one should just be able to select an inventory to pull from for each outgoing hub, and then any changes made in the inventory interface (our current variant overrides page) will just flow through to the shop.
Is that awesome or is my brain still in holiday mode?
If we want to be able to alter inventory or turn things on and off from the order cycles page we can just pull up the inventory interface in a modal and edit it there (when my new foundation interface comes across). Seems much cleaner than the current setup.
In terms of order cycle coordinator control over the products that are sold through the order cycle, we can retain this functionality through incoming exchanges which will continue to do what they do now: act as a whitelist filter for the variants that are saleable through a given order cycle. I guess that means that our “friends of friends” order cycle is just one where the whitelist is switched off, and anyone can sell whatever they want.
I seriously can’t tell if this is just sounding better because I have forgotten about all of the use cases and constraints or if I have had a good idea. Anyway, we can talk next week.
Never mind, I think I just broke it. Just relying on the lists would break the functionality of hubs being able to share an inventory, while simultaneously offering different subsets of that inventory for sale. Dang.
I still feel like there is something here that is beneficial, particularly around massively simplifying the basic use case for non-power-users…
