SmartDukaan – /

Rev 37365 – Debit note receive: surface the partner-declared condition and warn before ...

amit — Wed, 19 Aug 2026 20:33:08 +0530

amit – 3 file(s) modified
Debit note receive: surface the partner-declared condition and warn before rejecting

The receive screen defaulted every row's condition to GOOD regardless of what the
partner declared, so a warehouse user could not see what they were disagreeing with -
and the backend treats any disagreement as a rejection of the whole debit note.

- Show 'Declared By Partner' per row and preselect the condition to match it, so
submitting unchanged is a genuine agreement rather than an accident of the default.
- A changed row now switches the submit button to 'Reject Return', shows what rejection
means (no refund; partner, Logistics, RBM and Sales notified), makes the remark
mandatory and confirms before posting.
- SMTP timeouts raised to 30s connect / 120s read-write; the 10s read timeout was
cutting off larger attachment sends.
- jsVersion 405 -> 406 for the return.js change.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/business/return.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/receive-debit-note.vm

Rev 37364 – Offer circular ingest: report discarded rows instead of counting attempts ...

amit — Wed, 19 Aug 2026 20:32:59 +0530

amit – 1 file(s) modified
Offer circular ingest: report discarded rows instead of counting attempts

Pairs with the repository change that makes insertBenefit/insertTenure/insertBank return
their affected row count. The summary now bumps only when a row actually landed, and
records a drop naming the likely unseeded master (offers.txn_mode / emi_scheme / bank)
when it did not. Without this an ingest over empty masters reported a full, healthy
parse while writing nothing.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/CircularIngestService.java

Rev 37363 – Offer circular ingest: return affected rows so INSERT IGNORE cannot ...

amit — Wed, 19 Aug 2026 20:32:53 +0530

amit – 2 file(s) modified
Offer circular ingest: return affected rows so INSERT IGNORE cannot hide an FK failure

insertBenefit/insertTenure/insertBank use INSERT IGNORE for idempotency, which also
makes MySQL downgrade a foreign key violation to a warning. Production was bootstrapped
without the bank / txn_mode / emi_scheme masters, so all 872 benefit and tenure inserts
were silently discarded: the ingest reported PUBLISHED with 239 offers carrying no
amounts, no tenures and no bank eligibility, and nothing anywhere said so.

The three methods now return the affected row count (1 written, 0 discarded) so the
caller can count what landed rather than what it attempted.

Rev 37362 – External feed: keep placeholder 'Any Colour' SKUs out of the ...

amit — Wed, 19 Aug 2026 20:32:47 +0530

amit – 1 file(s) modified
External feed: keep placeholder 'Any Colour' SKUs out of the partner feed

catalog.item rows whose color is a placeholder ("Any Colour", "f_Any Color", ...) are
not real sellable variants and must never reach partners. Excluded from every feed and
count query via a single NO_PLACEHOLDER_SKU predicate so the SKU list and its count
cannot drift apart. The boundary check leaves real colors like "Rainbow" untouched.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/external/ExternalFeedRepositoryImpl.java

Rev 37361 – Mail outbox: one transaction per mail, retry once more, stable ...

amit — Wed, 19 Aug 2026 20:32:41 +0530

amit – 2 file(s) modified
Mail outbox: one transaction per mail, retry once more, stable Message-ID

processPendingMails ran the whole batch in a single REQUIRES_NEW transaction, so a
crash mid-batch rolled back the status of every mail already delivered in that cycle
and the next run re-sent them.

- Split into selectPendingIds (read-only) plus sendOne per mail, each REQUIRES_NEW via
a @Lazy self-reference so the proxy actually applies. Outcome is committed as soon
as it is known; a crash now loses at most the mail in flight.
- MailOutbox.selectPending retries FAILED rows once more (retryCount < 2).
- Stable per-row Message-ID so a retry arrives as the same message and the receiving
server can collapse it instead of showing a duplicate.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/mail/MailOutbox.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/MailOutboxService.java

Rev 37360 – ICICI policy issuance: stop losing policies to a proposal read ...

amit — Wed, 19 Aug 2026 20:30:29 +0530

amit – 2 file(s) modified
ICICI policy issuance: stop losing policies to a proposal read timeout

hitAfinityProposal called ICICI's gadget proposal endpoint on the default 10s socket
timeout. That POST issues the policy, so a read timeout abandons a request ICICI is
still completing. The exception then unwound through generateIciciLombardPolicy into
the controller's @Transactional(rollbackFor = Throwable.class), rolling back the whole
request - including the wallet debit - before the tracker row was ever touched. Result:
policy possibly live at ICICI, no trace on our side, and the 'policy already exists'
retry path dead-ends because its Redis cache is only written on a parsed success.

- Proposal and policy-certificate calls move to a dedicated RestClient built on
HttpClientFactory.insuranceIssuanceRequestConfig() (socket 45s). JWT and quote stay
on the default client - fast, and no remote write.
- Transport failures are classified via HttpTransportFailures and reported as 'outcome
unknown', not as an ICICI rejection.
- IciciPolicyTrackerBookkeeping writes the tracker in REQUIRES_NEW, so both the UNKNOWN
outcome and the issued policy number survive the request rollback. Recovery from an
UNKNOWN row is the existing recoverPolicyNumberByProposalNumber path.

Code only, no DDL: status is varchar(20) and remarks is text on prod already.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/IciciLombardService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/IciciPolicyTrackerBookkeeping.java

Rev 37359 – ICICI proposal read timeout: add insurance-issuance HTTP config + shared ...

amit — Wed, 19 Aug 2026 20:30:18 +0530

amit – 2 file(s) modified
ICICI proposal read timeout: add insurance-issuance HTTP config + shared transport-failure classifier

The default RestClient carries a 10s socket timeout, sized for quick lookups. ICICI's
gadget proposal endpoint underwrites and issues the policy synchronously and needs
longer; abandoning the read discards the only response carrying the policy and
proposal numbers for a policy that is already live at the insurer.

- HttpClientFactory.insuranceIssuanceRequestConfig(): connect 5s, socket 45s. Not
slowRegulatorRequestConfig() - its contract forbids request-thread use with an open
transaction, which is exactly the ICICI call site.
- HttpTransportFailures: cause-chain check separating 'the call never completed' from
'the remote said no'. Needed because RestClient rewraps transport errors as
RuntimeException(GE_1006), so the top-level exception type is uninformative.

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/web/client/HttpClientFactory.java
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/web/client/HttpTransportFailures.java

Rev 37358 – total show on warehouse wise stock value on item detail

ranu — Wed, 19 Aug 2026 18:04:00 +0530

ranu – 1 file(s) modified
total show on warehouse wise stock value on item detail

~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse_item_details.vm

Rev 37357 – Add CsService.getAuthUsersByPartnerIdAndCategory for partner+category+escalation lookup sendMailForActionOnDispatch mailed every L1 ...

amit — Wed, 19 Aug 2026 18:01:36 +0530

amit – 2 file(s) modified
Add CsService.getAuthUsersByPartnerIdAndCategory for partner+category+escalation lookup

sendMailForActionOnDispatch mailed every L1 position on the partner, which on live data
means the DESIGN (17), SALES (4) and WAREHOUSE (11) owners as well as the RBM (18). It
also hand-rolled the partner_position -> position -> auth_user walk against repositories.

Add a single reusable resolver on CsService: active auth users holding one position
category against a partner, optionally narrowed to escalation levels. It follows the
house resolver shape - the partner's own regions plus ALL_PARTNERS_REGION, partner_id in
(0, fofoId) - so region-wide mappings are honoured, and it short-circuits on empty id
lists because selectByIds builds an IN () predicate that breaks on an empty list.

The call site in TransactionServiceImpl went in with r37356; without this commit trunk
does not compile.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/cs/CsService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/cs/CsServiceImpl.java

Rev 37356 – Fixed max limit to 15 lac for Credit limit

amit — Wed, 19 Aug 2026 17:59:24 +0530

amit – 1 file(s) modified
Fixed max limit to 15 lac for Credit limit

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/TransactionServiceImpl.java

Rev 37355 – AI lead intake (fofo, live): assign new leads to a ...

aman — Wed, 19 Aug 2026 13:23:38 +0530

aman – 1 file(s) modified
AI lead intake (fofo, live): assign new leads to a random active BGC L1 instead of the hardcoded Khushbu/Archana round-robin

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LeadController.java

Rev 37354 – AI lead intake: pool is BGC L1 (category 20), not ...

aman — Wed, 19 Aug 2026 13:22:05 +0530

aman – 1 file(s) modified
AI lead intake: pool is BGC L1 (category 20), not Sales L1 - BGC is the desk that works AI leads

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LeadController.java

Rev 37353 – AI lead intake: assign new leads to a random active ...

aman — Wed, 19 Aug 2026 13:16:59 +0530

aman – 1 file(s) modified
AI lead intake: assign new leads to a random active Sales L1 instead of fixed auth id 53

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LeadController.java

Rev 37352 – Fixed max limit to 15 lac for Credit limit

amit — Wed, 19 Aug 2026 12:30:38 +0530

amit – 1 file(s) modified
Fixed max limit to 15 lac for Credit limit

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/PartnerLimitHelper.java

Rev 37351 – code committed for sales l3 added in bi and other ...

ranu — Wed, 19 Aug 2026 11:04:35 +0530

ranu – 5 file(s) modified
code committed for sales l3 added in bi and other model

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasksTest.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/BIRetailerModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/FofoReportingModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/cs/CsServiceImpl.java

Rev 37350 – Fix SD Credit daily statement showing zero interest on overdue ...

amit — Wed, 19 Aug 2026 09:52:34 +0530

amit – 1 file(s) modified
Fix SD Credit daily statement showing zero interest on overdue loans

sdDirectService classified each day's interest by exact-matching the
loan_statement description ('Interest On Loan Per Day' /
'Penalty On Loan Per Day'). Once a loan crossed its due date the cron
switches the label to 'Overdue Interest On Loan Per Day', which matched
neither filter, so the daily statement reported 0.00 interest for every
overdue day even though the charge was booked correctly in
loan_statement and loan.interest_accured.

Classify by tenure window against loan.getPenaltyDate() instead - the
same test addInterest() uses to pick the rate - and net the day's full
interest out of the opening balance so penalty days are consistent too.

Seen on loan 120277 (invoice NSLCK35860): Rs.73-83/day accruing from
08-Aug, displayed as 0.00.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/SDCreditServiceImpl.java

Rev 37349 – super retailer club 5 live

ranu — Tue, 18 Aug 2026 18:31:10 +0530

ranu – 1 file(s) modified
super retailer club 5 live

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/OrderRepositoryImpl.java

Rev 37348 – super retailer club 5 live

ranu — Tue, 18 Aug 2026 18:26:37 +0530

ranu – 3 file(s) modified
super retailer club 5 live

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/OrderRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/OrderRepositoryImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/DashboardController.java

Rev 37347 – Give the ingest runner a transaction; it had none on ...

amit — Tue, 18 Aug 2026 16:58:26 +0530

amit – 2 file(s) modified
Give the ingest runner a transaction; it had none on its background thread

Parsing failed instantly on production with

org.hibernate.HibernateException: Could not obtain transaction-synchronized
Session for current thread
at CircularIngestRepositoryImpl.claimForProcessing
at CircularIngestRunner.processOne

The runner works on a background thread. Nothing binds a Hibernate session to it, so
the very first repository call - the claim - threw. Worse, the failure handler called
markFailed, which threw for the same reason, so nothing was recorded: the document sat
in DRAFT with no error, no processed_at and no outward sign that anything had gone
wrong. CircularIngestService.ingest was never reached.

This was latent in the cron version too. It never surfaced because that scheduler was
never actually deployed anywhere.

- New CircularIngestBookkeeping: claim / document / published / failed /
reclaimStalled, each REQUIRES_NEW. Independent transactions matter most for failed(),
which runs after the ingest transaction has already rolled back and must not be
dragged into it.
- It is a SEPARATE bean on purpose. @Transactional on the runner's own methods would be
invoked from inside its own Runnable - a self-invocation never passes through the
Spring proxy, so the annotation would be silently ignored and the bug would come back
wearing a disguise.
- The runner no longer touches CircularIngestRepository at all.

Not caught locally because the RunIngest harness uses JdbcIngestRepo, a plain-JDBC
implementation that bypasses Hibernate entirely - so it can reproduce the parsing but
never a session or transaction problem.

+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/CircularIngestBookkeeping.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/CircularIngestRunner.java

Rev 37346 – Sort sale returns so the ones still needing an action ...

amit — Tue, 18 Aug 2026 16:45:26 +0530

amit – 1 file(s) modified
Sort sale returns so the ones still needing an action come first

The Recently Received Debit Notes table was ordered purely by receive time, so a
return waiting on a refund or on the partner's acknowledgment sank below rows that
were already refunded and needed nothing. On a busy warehouse the actionable rows
were off the first screen.

- recentOrders is now ranked pending-first (Received - Pending Refund, Rejected -
Pending Acknowledgment) ahead of settled ones (Refunded, Cancelled), with the
existing receiveTimestamp DESC kept as the tie-breaker inside each group
- getPendingActionRank follows the same precedence invoice-return.vm uses to pick
the status badge - reject checked before refund - so the ordering can never
disagree with the label the user sees
- ranked on the return's own state, not on the viewer's canReceive/canRefund
permissions, so a pending return stays at the top for everyone looking at it

Presentation only; no query, entity or lifecycle change. Note that returns never
received at all cannot surface here regardless, since the query filters on
receiveTimestamp BETWEEN the selected dates.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/PurchaseReturnController.java

Rev 37345 – Beat Journey (today): LOI-based 'Onboarded' + last-billing recency board columns, ...

vikas — Tue, 18 Aug 2026 16:12:06 +0530

vikas – 1 file(s) modified
Beat Journey (today): LOI-based 'Onboarded' + last-billing recency board columns, level-filtered orders list (grouped by partner), and flag tuning — remove #1/#3, use per-visit total_distance for #4.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/BeatJourneyController.java

Rev 37344 – Beat Journey: LoiFormRepository.selectMaxApprovedAcquiredDateByBdm() — max approved-LOI acquiredDate per BDM, powering ...

vikas — Tue, 18 Aug 2026 16:05:12 +0530

vikas – 2 file(s) modified
Beat Journey: LoiFormRepository.selectMaxApprovedAcquiredDateByBdm() — max approved-LOI acquiredDate per BDM, powering the board 'Onboarded' column (store.active_timestamp is null for all stores).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/user/LoiFormRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/user/LoiFormRepositoryImpl.java

Rev 37343 – Update PJP, Visit quality flags

vikas — Tue, 18 Aug 2026 15:18:27 +0530

vikas – 2 file(s) modified
Update PJP, Visit quality flags

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/BeatJourneyController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/beat-journey.vm

Rev 37342 – Allow re-ingest to start a circular already sitting in DRAFT ...

amit — Tue, 18 Aug 2026 14:59:37 +0530

amit – 2 file(s) modified
Allow re-ingest to start a circular already sitting in DRAFT

Moving the parse into the portal turned DRAFT into a dead end. Under the cron
scheduler DRAFT meant "something will pick me up", so re-ingest only ever had to push
a document back into it, and PUBLISHED/FAILED were the only sensible sources. Nothing
polls DRAFT any more - the runner is triggered by the upload that created the
document - so a circular whose trigger never fired had no way to be started at all.

That is not hypothetical: the Aug'26 circular uploaded to production before the runner
was deployed sits in DRAFT, and pressing re-ingest matched zero rows and reported
"not started".

DRAFT now joins PUBLISHED and FAILED as a valid source state. PROCESSING stays
excluded - that one is genuinely in flight - and claimForProcessing remains the single
arbiter of who actually parses, so allowing DRAFT cannot cause a double parse.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/OfferCurationRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/OfferCurationRepositoryImpl.java

Rev 37341 – fix(rbm-dashboard): return full partner book and exclude inactive stores ...

amit — Tue, 18 Aug 2026 14:52:54 +0530

amit – 1 file(s) modified
fix(rbm-dashboard): return full partner book and exclude inactive stores

/v2/fofo/rbm-dashboard capped partners/alerts at 50 by default. The RBM home
searches and filters client-side, so any partner outside that slice was
unfindable while summary.totalPartners reported the real (much larger) count.

- limit now defaults to 0 = uncapped; an explicit ?limit=n is still honoured
up to RBM_DASHBOARD_MAX_LIMIT (200)
- deactivated stores are skipped for the whole computation, not just alerts:
they have no target, scored 0% and sorted to the top of the action list
- summary.limit reports 0 when uncapped instead of Integer.MAX_VALUE

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoMonitorController.java

Rev 37340 – Fixed max limit to 15 lac for Credit limit

amit — Tue, 18 Aug 2026 14:46:23 +0530

amit – 2 file(s) modified
Fixed max limit to 15 lac for Credit limit

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java

Rev 37339 – Fixed max limit to 15 lac for Credit limit

amit — Tue, 18 Aug 2026 13:48:38 +0530

amit – 1 file(s) modified
Fixed max limit to 15 lac for Credit limit

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/PartnerLimitHelper.java

Rev 37338 – Remove offer-circular ingest from cron - it now runs in ...

amit — Tue, 18 Aug 2026 13:38:14 +0530

amit – 3 file(s) modified
Remove offer-circular ingest from cron - it now runs in the portal

Counterpart to the fofo commit that moved the parse into profitmandi-fofo. Nothing is
lost: all 13 parser classes and the test moved verbatim, and CircularIngestScheduler
was replaced by an executor-driven runner in the portal.

- com.smartdukaan.cron.offercircular deleted, main and test
- tabula dependency removed; PDFBox no longer enters this artifact at all
- dumpCircularClasspath moved to fofo, where the parser and its classpath now live

This module no longer knows anything about offer circulars, so a cron rebuild is no
longer a prerequisite for the feature to work - which was the entire problem.

~ /trunk/profitmandi-cron/build.gradle
x /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular
x /trunk/profitmandi-cron/src/test/java/com/smartdukaan/cron/offercircular

Rev 37337 – Move offer-circular ingest out of cron and into the portal ...

amit — Tue, 18 Aug 2026 13:37:58 +0530

amit – 23 file(s) modified
Move offer-circular ingest out of cron and into the portal

The parse now runs in profitmandi-fofo, on a background thread, triggered by the
upload that produced the document.

Why: splitting one feature across two artifacts with independent deploy cadences
cost a full day. fofo shipped, cron did not, and a valid upload sat in DRAFT with
nothing on the server able to parse it - the deployed cron jar contained none of the
ingest classes. One 9-page PDF a month never justified a batch tier, and the portal
already ships two PDF stacks, so the isolation argument for keeping PDFBox out was
weaker than it looked.

- 13 parser classes move verbatim from com.smartdukaan.cron.offercircular to
com.spice.profitmandi.web.offercircular. No logic changed.
- CircularIngestScheduler becomes CircularIngestRunner: the @Scheduled(every 5 min)
entry point and the offer.circular.ingest.enabled flag are gone, replaced by a
single-threaded daemon executor. All claim, ingest and notification logic is
unchanged.
- Upload hands the document id to the runner AFTER COMMIT, not inline. The DRAFT row
is written inside the request transaction; a worker starting immediately would race
that commit, find nothing to claim and silently do nothing - which is precisely the
stuck-on-DRAFT symptom this change removes.
- The guarded claim is KEPT even though there is now one trigger. It still stops a
double-submit, a second portal node, and a re-ingest racing an in-flight parse.
- Re-ingest parses immediately instead of queueing for a scheduler.
- The stall reaper runs when the review screen loads. There is no timer here any
more, and a document stranded by a redeploy mid-parse only matters when somebody
looks for it - which matters more now the parse lives in the web application.
- tabula moves to this module with its exclusions intact, as does the
dumpCircularClasspath helper the local ingest harness depends on.
- Screen no longer claims "the ingest job runs every 5 minutes", which was untrue the
moment cron stopped being the route; poll interval 15s -> 3s to match a parse that
takes seconds. jsVersion 404 -> 405.
- offer.circular.review.url added here, since the runner sends that email now.

Verified: full ingest of the Aug'26 circular through the relocated code is identical
to the reference - 239 offers, 663 products, 279 AUTO_EXACT, 361 benefits, 511
tenures, 911 bank links. ProductNamesTest 11/11 in its new home.

~ /trunk/profitmandi-fofo/build.gradle
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/OfferCircularController.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/BankTextParser.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/BenefitParser.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/CatalogIndex.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/CircularExtractor.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/CircularIngestRunner.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/CircularIngestService.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/CircularRow.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/FootnoteParser.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/ProductAliases.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/ProductMatcher.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/ProductNames.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/ScopeConfig.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/SequenceRatio.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/TenureParser.java
~ /trunk/profitmandi-fofo/src/main/resources/META-INF/dev.properties
~ /trunk/profitmandi-fofo/src/main/resources/META-INF/prod.properties
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/offer-circular-review.js
+ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/web/offercircular
+ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/web/offercircular/ProductNamesTest.java

Rev 37336 – Expose loginEmail to the admin views admin.vm gates the ...

amit — Tue, 18 Aug 2026 12:13:49 +0530

amit – 1 file(s) modified
Expose loginEmail to the admin views

admin.vm gates the OFFER CIRCULAR sidebar entry on the exact logged-in email,
because visibility there is per-email and auth.menu can only express roles. Nothing
was setting that variable, so the #if was always false and the entry rendered for
nobody on a clean build - it only appeared where a working copy happened to carry
this line locally.

Committed alongside r37331, which added the gate itself.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/AdminUser.java

Rev 37335 – Show offer circular ingest state on the review screen ...

amit — Tue, 18 Aug 2026 12:12:09 +0530

amit – 3 file(s) modified
Show offer circular ingest state on the review screen

Upload and parsing run in different processes - the portal stores the PDF as DRAFT
and the cron job claims it minutes later - so the screen looked identical before and
after a successful ingest. A reviewer had no way to tell "not parsed yet" from
"parsed and produced nothing", and a FAILED circular showed nothing at all.

- the selected circular's state is shown as queued / parsing / parsed / failed,
with the recorded reason on failure and the ingest summary on success
- while it is DRAFT or PROCESSING the screen polls every 15s and pulls in the rows
the moment the parse lands. Polling stops as soon as the state settles, so it
cannot spin forever, and a transient error keeps waiting rather than giving up
- jsVersion 403 -> 404, since offer-circular-review.js is already being served and
this is a modification rather than a new file

Pairs with the stall reaper: a circular abandoned mid-parse is now both recovered
and explained on screen instead of sitting silently in PROCESSING.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/offer-circular-review.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/offer-circular-review.vm

Rev 37334 – Sweep stalled offer circulars before each ingest run, and drop ...

amit — Tue, 18 Aug 2026 12:11:53 +0530

amit – 3 file(s) modified
Sweep stalled offer circulars before each ingest run, and drop stale scaffolding

- The scheduler now calls reclaimStalledProcessing before looking for new work, so
a circular stranded in PROCESSING by a dead or redeployed worker is failed with a
reason instead of staying invisible forever. Threshold is 30 minutes against a
parse that takes seconds, so it can only ever catch a genuinely dead worker. The
sweep is wrapped so it can never stop the actual ingest.
- dumpCircularClasspath was labelled a temporary helper for diffing against the
reference Python. That Python has been deleted, but the task is what lets an
ingest be reproduced and measured locally per scripts/offer_circular/README.md,
so the comment now says what it is for rather than telling the next reader to
delete it.
- CircularExtractor's javadoc claimed verification against the Python reference.
That proved equivalence, not correctness - both shared the missing-memory-unit
bug that bound offers to the wrong SKU. Reworded so it cannot be read as a
correctness guarantee, and points at the fixture and ProductNamesTest instead.

Verified: full ingest of the Aug'26 circular is byte-identical to the reference -
239 offers, 663 products, 279 AUTO_EXACT. ProductNamesTest 11/11.

~ /trunk/profitmandi-cron/build.gradle
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/CircularExtractor.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/CircularIngestScheduler.java

Rev 37333 – Reclaim offer circulars stranded in PROCESSING, and surface the ingest ...

amit — Tue, 18 Aug 2026 12:11:38 +0530

amit – 3 file(s) modified
Reclaim offer circulars stranded in PROCESSING, and surface the ingest reason

A claim moves a circular DRAFT -> PROCESSING, and selectDraftDocumentIds only ever
picks up DRAFT. So a worker that died, was redeployed, or hung mid-parse left that
document stranded in PROCESSING forever, invisible to every later sweep. The batch
tier looked like it provided retry semantics and did not.

- reclaimStalledProcessing(minutes) fails anything left in PROCESSING past the
threshold. Deliberately FAILED and not back to DRAFT: a circular that reliably
kills the parser would otherwise be re-claimed on every sweep forever. FAILED is
visible, carries the reason, and the existing re-ingest action already allows
FAILED -> DRAFT, so re-queueing is one click.
- claimForProcessing now stamps processed_at, which is what the stall is measured
against. No DDL: that column is written only by this repository and read by
nothing else, so it can carry the last-transition time.
- selectDocuments returns ingest_error and ingest_summary. Without the reason the
screen would show a bare FAILED, which the reaper would now produce routinely.

Verified against the local DB both ways: a claim aged 45 minutes is reclaimed with
its reason recorded, a fresh claim is untouched.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/CircularIngestRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/CircularIngestRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/OfferCircularRepositoryImpl.java

Rev 37332 – Move the offer-circular upload directory off a developer home path ...

amit — Tue, 18 Aug 2026 11:18:51 +0530

amit – 3 file(s) modified
Move the offer-circular upload directory off a developer home path

Every upload in production failed with a 400 on mkdirs. offer.circular.dir was
never set in any environment, so it fell back to the code default
/users/amit/uploads/offer-circulars; Tomcat runs as the tomcat user, which cannot
create /users at the filesystem root, and the controller threw "Circular storage
directory is not writable".

- default is now /var/lib/smartdukaan/offer-circulars, a real server path
- offer.circular.dir set explicitly in prod.properties, and pointed at the
developer's own space in dev.properties, since /var/lib needs sudo on a
workstation
- staging.properties deliberately untouched; the new default covers it

The location has two hard constraints, now recorded on the field itself:

- OUTSIDE webapps/. A redeploy wipes anything under it, and
offer_document.stored_path is how both re-ingest and re-download resolve the
PDF, so a wipe breaks them permanently. Stray PDFs are already sitting in
WEB-INF/classes/META-INF on the server from exactly this mistake.
- OUTSIDE any web root. A circular carries the OEM's confidential cashback
economics and must never be servable as a static file. Hence /var/lib rather
than /var/www, whose local precedent /var/www/partner_stats is chmod 777.

Only fofo needs the key: the cron ingest resolves the PDF from
offer_document.stored_path and reads it as root, so 0750 tomcat:tomcat is enough.

Deploying this alone does not fix production - the directory must also exist and
be writable by tomcat.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/OfferCircularController.java
~ /trunk/profitmandi-fofo/src/main/resources/META-INF/dev.properties
~ /trunk/profitmandi-fofo/src/main/resources/META-INF/prod.properties

Rev 37331 – Add offer circular review and curation screen Shows the ...

amit — Tue, 18 Aug 2026 00:19:29 +0530

amit – 5 file(s) modified
Add offer circular review and curation screen

Shows the nine verbatim PDF columns beside what the parser made of them, uploads a
new monthly circular, and resolves the products the matcher could not.

Upload deliberately does not parse - it stores the PDF, sha256-deduped, and
registers it DRAFT, so an upload can never half-populate the offer tables. The cron
ingest job picks it up from there.

The curation queue groups by distinct (division, raw text) because that is the
product_alias key: one answer clears every row carrying that text, on this circular
and on every later one. On the Aug'26 circular that turns 152 unresolved rows into
106 decisions. Three actions mirror product_alias.action - PIN to a catalog id,
REWRITE to the catalog's spelling and match again, or IGNORE.

- Writes product_alias only, so nothing the screen does can set manually_curated
and lock a circular against re-ingest. Coverage decisions, which do need that,
are listed but visibly parked rather than offered a naming answer.
- A saved decision changes nothing until re-ingest, because aliases are read at
ingest time; the queue says so and the re-ingest button puts the document back
to DRAFT for the scheduler. The portal cannot run the ingest itself - that lives
in profitmandi-cron, which fofo does not depend on.
- The closest rejected match is shown for context and never pre-selected. Four new
OnePlus models each "nearly" matched a 2015 OnePlus 2 at 0.80-0.84, and offering
that as a suggestion invites a reviewer to confirm it. Where the catalog has no
such SKU the search says so and steers to IGNORE.
- aliasExport emits every decision as replayable SQL, because the portal writes to
one database and environments would otherwise drift apart silently.

Access is an email allowlist AND the admin role. Both are enforced in the
controller; the sidebar entry repeats the allowlist because visibility in auth.menu
is role-driven and cannot express a per-email rule.

No jsVersion bump: offer-circular-review.js is a new file that was never cached,
so it needs no cache-buster, and churning that shared counter only conflicts with
whoever is mid-edit on it.

+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/OfferCircularController.java
+ /trunk/profitmandi-fofo/src/main/webapp/resources/js/offer-circular-review.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/admin.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/include-scripts.vm
+ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/offer-circular-review.vm

Rev 37330 – Add Pine Labs affordability circular parsing and ingest Turns ...

amit — Mon, 17 Aug 2026 21:07:56 +0530

amit – 21 file(s) modified
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.

~ /trunk/profitmandi-cron/build.gradle
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/BankTextParser.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/BenefitParser.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/CatalogIndex.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/CircularExtractor.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/CircularIngestScheduler.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/CircularIngestService.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/CircularRow.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/FootnoteParser.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/ProductAliases.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/ProductMatcher.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/ProductNames.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/ScopeConfig.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/SequenceRatio.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/offercircular/TenureParser.java
+ /trunk/profitmandi-cron/src/test/java/com
+ /trunk/profitmandi-cron/src/test/java/com/smartdukaan
+ /trunk/profitmandi-cron/src/test/java/com/smartdukaan/cron
+ /trunk/profitmandi-cron/src/test/java/com/smartdukaan/cron/offercircular
+ /trunk/profitmandi-cron/src/test/java/com/smartdukaan/cron/offercircular/ProductNamesTest.java

Rev 37329 – Add offers-schema repositories for the Pine Labs affordability circular ...

amit — Mon, 17 Aug 2026 21:07:00 +0530

amit – 7 file(s) modified
Add offers-schema repositories for the Pine Labs affordability circular

Three repositories over the offers schema, split by who is allowed to write what:

- OfferCircularRepository - read side for the review screen (verbatim rows,
documents, per-offer parsed detail)
- CircularIngestRepository - write side for ingest; claims a DRAFT document with
a guarded UPDATE and deletes only rows derived from that one document, so
re-ingesting one month cannot disturb another
- OfferCurationRepository - write side for manual curation

The split is deliberate: a caller that only displays circulars should not hold a
handle that can rewrite the scope config or the offer tables.

OfferCurationRepository writes offers.product_alias and nothing else. An alias is
config, keyed on (division_id, raw_text), so re-ingest reproduces it and one
decision carries into every later circular. Writing offer_product instead would be
derived data that re-ingest deletes, which is why doing so has to set
manually_curated and freeze the circular permanently - not a trade worth making for
a naming decision, so this repository cannot make it.

A PIN is validated against the division's own brand and category before it is
stored. Nothing downstream re-checks a pinned id - the matcher takes it at face
value - so an unverified exception would silently mismap money.

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/CircularIngestRepository.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/CircularIngestRepositoryImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/OfferCircularRepository.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/OfferCircularRepositoryImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/OfferCurationRepository.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/OfferCurationRepositoryImpl.java

Rev 37328 – Fetch a fresh EWB auth token when the cached one ...

amit — Mon, 17 Aug 2026 19:25:56 +0530

amit – 2 file(s) modified
Fetch a fresh EWB auth token when the cached one is stale

Two defects made an expired EWB token unrecoverable, surfacing as GSP102
"eInvoice AuthToken not found or expired" on every GET.

1. ewbApiGet's retry was unreachable. NIC returns GSP102 with HTTP 400, and
RestClient.execute throws GE_1005 on any non-2xx before returning the body, so the
'if (response.contains("GSP102"))' branch could never run. A failed first attempt is
now treated as a possibly-stale token and retried once with a freshly minted one; a
second failure propagates. The POST path was unaffected — executeJson does not check
status, so its retry already worked.

2. Eviction targeted the wrong cache. The token is cached in redisCacheManager but all
three sites evicted through redisFortnightlyCacheManage, a different cache, so the
eviction was a silent no-op and the stale token survived. Eviction now goes through
GstProAuthService.evictEwbAuthToken, declared beside the @Cacheable and pinned to the
same cacheManager so the two cannot drift apart again.

Found while dry-running the EWB backfill, which failed on the first invoice.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/GstProAuthService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/GstProService.java

Rev 37327 – super retailer club 5 live

ranu — Mon, 17 Aug 2026 17:46:07 +0530

ranu – 21 file(s) modified
super retailer club 5 live

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/FofoOrderRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/FofoOrderRepositoryImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/DashboardController.java
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/1 GM Gold Coin.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/accessories.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/calendar_.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/CURRENTLY AIMING FOR.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/download.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/Group 4.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/Maharaja.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/Mobile And tv.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/Raftaar.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/Shuruaat.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/Tarakki.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/Target.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/TOTAL ACHIEVEMENT.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/Udaan.png
+ /trunk/profitmandi-fofo/src/main/webapp/resources/images/src-images/Vijeta.png
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/dashboard1.vm

Rev 37326 – Add --backfillMissingEwb cron arg Runs InvoiceService.backfillMissingEwb over an explicit ...

amit — Mon, 17 Aug 2026 17:23:40 +0530

amit – 2 file(s) modified
Add --backfillMissingEwb cron arg

Runs InvoiceService.backfillMissingEwb over an explicit invoice list:
--backfillMissingEwb --invoiceNumbers=A,B,C [--dryRun]

Explicit list rather than a date window so the backfill only touches the invoices known
to have lost their EWB. NOT_SUPPORTED on the RunOnceTasks wrapper suspends the
class-level transaction, keeping the NIC lookups outside one.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/RunOnceTasks.java