This topic is to document and discuss a new funded feature named sourced variants. This stems from the explorations done over the years on Network and funding received from some hubs in France (approx. 12K euros).
The main idea is to give ability to the distributor to create products, but only products from producers they have access to.
In more detail:
When creating a variant, a producer or a hub will be able to link the variant to a âsourceâ.
to start with, distributor variants will only be created through cloning
Each user profile will only be able to link their products to a source from whom they have a granted permission.
a new permission need to be created
Each time a user (owner) gives access to another user to its catalog, the user which was granted access can populate its own catalog with products from the owner. The source of these new products is set to the âoriginalâ owner. The user which was granted access wonât be able to change the source of the product.
Some other fields might not be available for a change : unit, product category and weight (others??)
We are starting with a small iteration that allows us to begin development, and iterate based on community and paying hubsâ feedback.
For now hub managers will be able to create a sourced variant from their existing product list by clicking on the actions menu in each individual variant and selecting âCreate sourced variantâ.
only accounts that have âManage productsâ + âCreate sourced variantsâ permissions will be able to effectively use this. This is due to the fact that a hub needs to be able to see the list of products that they can create sourced variants from. We will likely iterate on this later on.
Sourced variants will be part of the original product for now. They will have a different hub âownerâ, which is a new field for variants, to be displayed in the list as a new column, and filterable, as described in this issue
A new type of permissions needs to be created. This will be activated and displayed exactly as the existing permissions. @dcook said that itâs easier to just implement it in the Permissions page UI already, rather than manually editing the database.
Sourced variants will temporarily be recognised by a link/chain emoji icon on the left side of the row. We will change this later
Sourced variants fields will be freely editable for now, weâll discuss later if some of those fields need to be locked or not
We are currently still evaluating if this will be hidden behind a feature toggle or not. Also, this is just the start of the development of this functionality, and as we progress we will build on top of it.
If you would like to provide feedback, feel free to reply here or join the conversation in slack at #sourced-variants.
In this first iteration, the newly created âsourced variantâ is now a variant OWNED by whichever enterprise created it. So - in most of our examples that is the hub. I just want to make sure I understand what happens when a source variant sells in a store.
Producer owns a variant - in their product list, at a price and stock
Hub, with permission, creates a Sourced Variant - and now this source variant is owned by the creator/hub.
Right now, when a producer sells a variant in a hubâs store, the sale of that variant is accrued to the producer. So when the hub or the producer runs a report - order cycle producer totals, or pay suppliers reportâŚ, the sale of the variant is there. And, when the order cycle closes, most typically, hubs have chosen to automatically send pick and pack lists to the producer - and this email lists all the variants, owned by the supplier, that have sold in the store. This is how producers know what to go pick.
But as i understand it, this is different for this first iteration of sourced variants.
A source variant, when it is sold in a store, is no longer OWNED by the producer. It is now owned by the hub/seller (or whoever created it). So - the sale of that variant is of course on the order, but would it be accrued to the producer who OWNED the original variant? Iâm guessing no because the ownership of the variant changed.
And so - how does the producer know what to pick, pack⌠and is the original producerâs stock of a variant debited, when the source variant created from it sells?
What makes a âsourced variantâ different from a new variant created by the hub?
is the original producerâs stock of a variant debited, when the source variant created from it sells?
For this first iteration, no.
What makes a âsourced variantâ different from a new variant created by the hub?
Currently hubs cannot create variants unless they are also producers or declare themselves as producers.
This is the first use case we are after: stop duplicated products catalogs because hubs want to sell their own product, not the one from the producer. And keep the name of the producer on the product (currently when hubs declare themselves as producers when they are not, this is lost).
When hubs declare themselves as producers currently, there is no link between the hub product and the producer product. Stock info is already not shared.
@Mario FYI turns out I was wrong and there are 2 use cases left where hubs might want to keep using old inventory: the âuse producer stock settingsâ option for the on-hand column. And for prices, we need to handle how producers can access orders made on linked variants.
Definitely material for the next iteration, maybe even before the compound product. But I donât think it fits the budget coopcircuits has raised so we would need to find funding for this first.
Thanks very much for taking this time to respond @Rachel . I think FINALLY I understand this first use case. (Sorry I didnât understand it until now, and probably raised many issues that were irrelevant.)
We have had such use cases on OFN-CAN too, where an enterprise wants to sell their own products but keep some âbrandingâ of the supplier/producer. They might see producers and variants on OFN, but they arrange supply (stock) and payment for these outside the platform. They donât use most of the OFN app (dynamic stock, pick/pack communications, payout reportsâŚ) Interesting.
So I think this leave 2 âuse casesâ of enterprises using inventory outstanding - but Iâm not sure how big the need is. (Maybe others can comment on that?)
Hub that sells âanyâ needs allocated stock - different from what the producer sets in the producer product list.
Hub that sells âanyâ needs to sell at a variant-specific price.
I have some ideas on these - and will wait until we are ready. But, OFN-CAN had hubs with both these needs, who used inventory. But over the past 2 years (knowing we were sunsetting inventory) we have coached them to other solutions. So I"m curious, how big the demand is across instances for these 2 âinventoryâ features.
(We decided to sunset inventory because of its complexity. If we make sourced variants just as complex but call it something different, we have wasted time and money, and gained little.)
@tschumilas no I think these 2 use cases are already covered: hubs selling any can create their linked variants and change stock and price.
The 2 cases that are not covered are :
the âuse producer stock settingsâ for stock: for the first release you cannot share stock info between the sourced variant and the linked variant
the producer has not yet access to the order made with linked variants. We need to analyze how we want to do this (regular cases, compound products, are hubs ok to share their number of orders with producerâŚ) and not indeed end up in a complex override like we had for inventory