Subversion Repositories SmartDukaan

Last modification

• Rev 0 – 1 d 8 h
• Author: amit

• Log message:

  Add Pine Labs affordability circular parsing and ingest
  
  Turns the monthly OEM "Mobile & Laptop Offers" PDF into the offers schema: tabula
  extraction to nine verbatim columns per row, per-cell parsers for benefit, tenure,
  bank and footnote text, catalog matching, and a scheduler that claims DRAFT
  documents uploaded from the FOFO portal and emails the uploader the outcome.
  
  Ships inert. offer.circular.ingest.enabled defaults to false, so the scheduler does
  nothing until an environment opts in, and offer.circular.review.url defaults to
  empty - neither key is required for the context to start.
  
  - tabula added here and not in profitmandi-common so PDFBox never reaches the
  web/fofo WARs; bouncycastle, slf4j-simple and jai-imageio excluded (version
  clash, duplicate SLF4J binding, and unused image decoding respectively)
  - offer_raw_row holds all nine columns verbatim, so re-parsing reads the table and
  never the PDF again
  - product_alias is consulted before matching, so a human confirmation recorded once
  keeps applying every following month
  
  ProductNamesTest locks in the product-name parsing, which decides which SKU an
  offer's money lands on. Every case there is a real mis-parse, and they share one
  root cause: characters or digits belonging to the model name being eaten as memory
  or stripped as punctuation. Two worth naming:
  
  - A memory spec with no GB/TB unit is still a memory spec. Motorola writes
  "(8+256)" and vivo "(8+256G)"; unrecognised, the matcher believed no size was
  given and bound the offer to an arbitrary sibling - a 1,000 Edge 60 Pro 8+256
  offer and a 2,000 12+256 offer landed on the same SKU.
  - Two variant groups written back-to-back are two products. "Edge 70 Pro
  (8+256)(12+256)" stayed one product bound to a single SKU while the 12+256
  variant silently got no offer at all.
  
  Bundled accessories are deliberately NOT stripped back to the bare phone. Doing so
  resolves 30 CATALOG_GAP rows and looks safe on Oppo, whose bundled and bare rows
  carry identical values - but vivo caps X300 Pro(16+512G) at 10,000 on its own row
  and 11,000 on the "+Extender" row, the difference being the Extender. Merging them
  would let the bundle's cap be claimed on a phone sold without the accessory.
  Whether a bundle offer transfers to the bare SKU is a commercial question the PDF
  does not answer, so it is a manual coverage decision, not a parsing rule.
  
  Verified against the Aug'26 circular on the local DB: 324 rows in the PDF, 239
  loaded, producing 361 benefits, 511 tenures, 911 bank links and 663 products, of
  which 74% resolve automatically. ProductNamesTest 11/11.