We had a good detailed discussion about next steps for Product Refactor and how to take it forward towards 'Retiring Inventory / Variant Overrides; while gathered in Aus in May 23. Notes below.
Relates to previous discussions:
- Discovery sessions - Networks
-
First iteration on product chain logic
The time has come.
We can progress Part 1 independently. It needs to happen before any further network or release of Product API v1 can happen.
Part 2 probably shouldn’t start until we are clear on Part 3. Design work on Part 3 could commence now? or following Product tagging? (@Rachel @lin_d_hop @Mario TBD)
1. Simple Product Model - Merge Products & Variants into one Model
- Merge Products & Variants into one
- Add family/set/group so that ‘variants’ of the same Product can be ‘grouped’
. . maybe as outlined here - Update Products API v0
NB. We will need agreed process for giving notice of changes to API v0 (agreed it will be in release notes … but someway to give people a chance to make sure they’re looking - post release notes also to API channel if API changes included?)
2. Create Linked Products (LPs)
(Note: Calling it Linked Products instead of Chained Products, to avoid any sense of 1-to-1 from each Product link. Each product may be linked to many parents and children . . once part 5 is complete).
- Add Parent field to Product
- Replace Variant Override with 1st generation product
- ‘Permission to create Variant Override’ becomes ‘Permission to Create Copy’
- Keep logic of Variant overrides re. stock and price i.e. if a Child Product has Stock or Price of NULL, use Stock or Price of parent product
3. UX/UI - Transition Variant Overrides (VOs) to manage new Chained Products (CPs)
- Will retire Inventory page, aim to handle all within Catalogue page
- How much UX/UI for handling chained products already exists? Maybe some but needs big revisit
- Will need some kind of drop-down for handling the key classes e.g. ‘my own products’ ‘my copies’ ‘hidden’? etc . . some core functions that should exist outside of voluntary tagging (@lin_d_hop @maikel I didn’t write a decent note on this - if either of you can remember more clearly what we thought was on the drop-down please update)
- UX consideration - can we make the ‘chain’ visible / functional - so that I can see the linked stock and prices?
- At some point there will need to be data migration from VOs to CPs
- NB. We want to keep the ability to add a Product (permission manage) without creating own copy. We also want to KEEP the permission to add a product to order cycle as is, without taking your own copy, so that we don’t lose the ability to just draw from the same stock. We are replacing variant overrides, not removing product sharing permissions
- NB. This will have big implications through Reports, Bulk Products, Order Cycle Settings . . we will want to simplify where we can - particularly in Order Cycle settings
4. Transformations
- Allow for management of changed products i.e. increase the number of fields that can be edited when creating the copy - change Units; descriptions etc TBC which fields we open up at different times
- Allow for automation of ‘transformation’ rules e.g. I want my copy of this product to have 10x the stock of the parent product (because I am splitting it into 10 packets), of 1.10x the price because I’m adding a 10% mark-up etc - needs thinking about what transformations we will support
- Transformations will need to consider affect how stock and price changes flow through the network
5. From 1 Copy to Chained Copies
- Allow me to make a copy of a copy
- Make a product that has multiple parents
- Add multiple children to a parent (?)
There was some discussion as to whether 4 or 5 should come first, but both are adequately far away that we felt we could reconsider closer to the time
Who to ping?
TBC
inventory but also something small enough we don’t end up needing to work on our Offer model here already.
How can we reduce this pain?