Product Model Refactor

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:

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?



1 Like

wooo thanks for this work!!!

I would say let’s get new admin colors on the way and then start design on part 3? Unless we feel we can do the 2 in parallel.

I think the most tricky part in the retirement of inventory will be how we want to handle prices. Stock being already handled in part 2 if I follow everything. So we will need to find something big enough it can help us :fire: inventory but also something small enough we don’t end up needing to work on our Offer model here already.

Chat in product circle, some other considerations:

  • Transition is going to be very tricky. We think we are going to need to run the two systems in parallel for a while, because we can’t just move everyone all at once
  • Back-office Uplift needs to go out alone - everyone will get this (soon)
  • We will then do product list tagging . .

We will need to run both systems in parallel - we can’t find a way to avoid this :frowning: How can we reduce this pain?

  • IF we can do Part 1 above BEFORE the product list tagging that would save refactoring - TBC depending on people availability

Then we identify different categories of users and use feature toggle to roll this out

  • Those who are NOT using Inventory: we turn on the product list tagging and turn off inventory
  • Then we identify specific users and work out the transition plan. Some might be manual, some might have a migration
    Possible we could/should have a working Inventory API endpoint, so that we can easily pull up the lists and info of where inventory is used for easy analysis and transition