Subversion Repositories SmartDukaan

Last modification

• Rev 37555 2026-09-09 14:42:05
• Author: amit

• Log message:

  web offer sync: one value per SKU per payment mode
  
  The circular says two things about the same phone. Motorola Sep'26 page 9 names
  'G37 Power' generically at Rs.1,000 CC Full Swipe (row 12) and 'G37 Power (8+128)'
  at Rs.2,000 (row 13), so G37 Power 8+128 carried both badges and a partner could
  quote either.
  
  Precedence, per (catalog_id, txn_mode):
  1. a specifically named VARIANT beats a generic MODEL - the named line is the OEM
  being precise about that SKU
  2. at the same level, the higher value wins
  3. tie-break on lowest offer id, so the outcome is deterministic
  
  The generic line still covers every variant nobody named: G37 Power 4+64 keeps its
  Rs.1,000 Full Swipe while 8+128 takes Rs.2,000. Verified on the live data - 1026311
  now resolves to exactly CC_EMI 2500 and CC_FULL_SWIPE 2000, down from four competing
  values.
  
  An offer keeps a SKU if it wins on at least one of its own modes, since one badge
  carries every mode of its offer. Scheme-only offers are never filtered - no value to
  compare.
  
  Deliberately NOT reusing v_offer_applicable, which encodes the same VARIANT-beats-
  MODEL rule but has no document or status filter: once August is re-ingested its rows
  enter that view and an EXPIRED August variant would silently suppress a live
  September model. Scoping to one document avoids that; the view is left alone for
  other consumers.
  
  Measured on Sep'26: 557 product links -> 458, 191 badges -> 166.