computed pricing #4

Open
opened 2026-03-24 18:31:43 +11:00 by Ghost · 1 comment
Ghost commented 2026-03-24 18:31:43 +11:00 (Migrated from codeberg.org)

need a page to input overhead and margin settings, then:

plan:

  • on form or list view -> little flag to show pricing_status (uptodate, stale, pending, error), and button to recompute/analyse price. on form view also multi select -> recompute (maybe separate recompute and analyse, or have both but analyse does recompute, no bulk analyse). [error status for bom cycle, missing purchase info]
  • analyse modal: few tabs: 1. shows breakdown of computed price (bom tree with cost of each node, and then adding overhead, margin). you can select product variant from dropdown (restricted to minimal variants, each time you change it shows which ones it is equivalent to). 2. updating tab: shows recommended base price, and price extra for attr vals (you can edit but still see the recommended). also a preview of results for each minimal variant.

compute code:

  • get cost -> then add overhead, margin. store each value (price, overhead, margin, margin%). maybe have a 'computedPriceResult' to store on a product variant instead of putting all fields on the variant itself? -> because this is light weight (getbomcost does the heavy listing, let's just make these computed fields.

helper funcs:

  • getPriceAffectingPavs -> if has bom, for each line, add it's pavs. then go through product attributes, and for each, add all the found pavs, plus one neutral if possible (should always be possilbe to add one neutral if no price affecting pavs for that pa, we need it also). if no bom -> check if purchaseable, and go through purchase lines, add all pavs of each variant there. if no purchase lines, just add all pavs as price affecting.
  • getMinimalVariants -> generate combinations based on those pavs, and fetch them. (these are what we will compute on).
  • writeBomCost -> recursively go through boms (for all minimal variants), set cost of each product, roll up to total cost. (this func also needs to write price/cost status). when running, we check hash first to see if we need to recompute. when bulk recomputing, we just do the same thing, feed in all the variants and compute, skipping where hash hasnt changed or already done.

notes:

  • the main getBomCost func should use caching of bom costs etc with a map, because we are running on multiple variants we will hit the same sub-bom a few times. (key is productvariant id)
  • store a 'bomTreeHash', to determine price status. on fetch product, compare, and set price status.
  • store 'equivalentvariants (fk)', and 'represenativeVariant (bool)' on pv.
  • detect bom cycles somehow? -> maybe just error if we go 50 levels deep.
  • update prices needs a simultaneous solver on minimal variants like np.linalg.lstsq. -> new func, analyse cost which does this.
  • when running 'updateproductvariants', and archiving, set price status to stale.

New plan:

need a page to input overhead and margin settings, then: plan: - on form or list view -> little flag to show pricing_status (uptodate, stale, pending, error), and button to recompute/analyse price. on form view also multi select -> recompute (maybe separate recompute and analyse, or have both but analyse does recompute, no bulk analyse). [error status for bom cycle, missing purchase info] - analyse modal: few tabs: 1. shows breakdown of computed price (bom tree with cost of each node, and then adding overhead, margin). you can select product variant from dropdown (restricted to minimal variants, each time you change it shows which ones it is equivalent to). 2. updating tab: shows recommended base price, and price extra for attr vals (you can edit but still see the recommended). also a preview of results for each minimal variant. compute code: - get cost -> then add overhead, margin. store each value (price, overhead, margin, margin%). maybe have a 'computedPriceResult' to store on a product variant instead of putting all fields on the variant itself? -> because this is light weight (getbomcost does the heavy listing, let's just make these computed fields. helper funcs: - getPriceAffectingPavs -> if has bom, for each line, add it's pavs. then go through product attributes, and for each, add all the found pavs, plus one neutral if possible (should always be possilbe to add one neutral if no price affecting pavs for that pa, we need it also). if no bom -> check if purchaseable, and go through purchase lines, add all pavs of each variant there. if no purchase lines, just add all pavs as price affecting. - getMinimalVariants -> generate combinations based on those pavs, and fetch them. (these are what we will compute on). - writeBomCost -> recursively go through boms (for all minimal variants), set cost of each product, roll up to total cost. (this func also needs to write price/cost status). when running, we check hash first to see if we need to recompute. when bulk recomputing, we just do the same thing, feed in all the variants and compute, skipping where hash hasnt changed or already done. notes: - the main getBomCost func should use caching of bom costs etc with a map, because we are running on multiple variants we will hit the same sub-bom a few times. (key is productvariant id) - store a 'bomTreeHash', to determine price status. on fetch product, compare, and set price status. - store 'equivalentvariants (fk)', and 'represenativeVariant (bool)' on pv. - detect bom cycles somehow? -> maybe just error if we go 50 levels deep. - update prices needs a simultaneous solver on minimal variants like np.linalg.lstsq. -> new func, analyse cost which does this. - when running 'updateproductvariants', and archiving, set price status to stale. New plan:
davenh99 added this to the v0.2.0 milestone 2026-05-31 14:20:58 +10:00
davenh99 removed this from the v0.2.0 milestone 2026-06-05 13:57:28 +10:00
davenh99 added reference computed-pricing 2026-06-16 08:37:10 +10:00
Owner

first need:
product:

  • pricingStatus
  • bomTreeHash

productVariant:

  • representativeVariant (bool)
  • equivalentVariants (fk)
  • computedPrice
  • cost

methods:

  • writeBomCost
  • getMinimalVariants
  • getPriceAffectingPavs
  • computeSellPrice

routes:

  • computeSellPrice (takes list of product ids)

views:

  • pricingAnalysisModal

also:

  • multi select behaviour in multi view
  • two actions: compute, and analyse.
  • add pills to pricing status.
first need: product: - pricingStatus - bomTreeHash productVariant: - representativeVariant (bool) - equivalentVariants (fk) - computedPrice - cost methods: - writeBomCost - getMinimalVariants - getPriceAffectingPavs - computeSellPrice routes: - computeSellPrice (takes list of product ids) views: - pricingAnalysisModal also: - multi select behaviour in multi view - two actions: compute, and analyse. - add pills to pricing status.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
davenh99/inventory#4
No description provided.