SmartDukaan – /

Rev 37569 – fcm: stop holding a row lock on the whole batch ...

amit — Thu, 10 Sep 2026 12:05:44 +0530

amit – 2 file(s) modified
fcm: stop holding a row lock on the whole batch across every FCM call

sendNotification lived in ScheduledTasks, which carries a class-level @Transactional,
so one pass was one transaction: it loaded EVERY pending row uncapped, then per row
made an FCM call over the network and stamped sentTimestamp on the entity. A dirty
row stays write-locked until commit, so a run held a lock on every notification in
the batch for the SUM of all the remote waits. Volume is real -- 11,581 sent on
2026-09-09, 12,036 on 2026-09-05 -- and HttpClientFactory sets a 10s socket timeout,
so one bad run could hold thousands of locks for minutes.

That is the shape behind a 33 SECOND average InnoDB row-lock wait server-wide
(Innodb_row_lock_time 63,291s over 15.4 days uptime, max 51,941ms against a 50s
innodb_lock_wait_timeout -- which is where LockAcquisitionException comes from).

Moved to PushNotificationSendService using the same seam the invoicing pass already
uses in InvoiceService.updateIrnsToInvoices: one short read transaction to pick up
the batch and build the payloads, NO transaction across the network call, and one
REQUIRES_NEW transaction per row to record the outcome. No lock is held while waiting
on FCM.

It is a separate bean, and reaches its own transactional methods through an injected
self-reference, because REQUIRES_NEW is applied by a Spring proxy and a plain
self-invocation would bypass it -- same idiom, for the same reason, as InvoiceService.

Also caps the batch at 500/run (30,000/hour against a 12,000 peak day) using the
already-present but never-wired selectPendingNotifications(limit); the previous query
was uncapped, which is what let a campaign burst become one multi-minute transaction.
Send outcomes are unchanged: 200 stamps now, anything else stamps the 1970 sentinel.
The HttpClient is now closed, which it previously was not.

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

Rev 37568 – offer circular: a failed web-offer sync must not be silent ...

amit — Thu, 10 Sep 2026 12:04:40 +0530

amit – 2 file(s) modified
offer circular: a failed web-offer sync must not be silent

Swallowing the exception was right - a circular that parsed correctly must stay
PUBLISHED, and the sync is re-runnable while the parse is the expensive part.
Swallowing it SILENTLY was not.

A TINYINT(1) cast threw in the sync on every ingest from 2026-09-08 to r37553 and
nothing looked wrong: processed_at advanced, the circular published, the email said
success. The only symptom was web_offer.synced_at standing still, which nobody was
watching. It went unnoticed for two days.

Now:
- Summary carries webOfferSync, and states it in EVERY case - the counts on success,
'FAILED - <cause>' on failure, 'NOT RUN' if it never executed. A missing line would
be indistinguishable from a sync that never ran, so there is no missing line.
- That lands in offer_document.ingest_summary, so the review screen shows it.
- The notification email carries it too, and a failure renders as a red
'Web offers NOT updated' block saying partners are still seeing the previous
offers and that the parse itself is fine.
- The sync now runs BEFORE published(), so its outcome is part of what gets recorded
rather than an afterthought. It is still REQUIRES_NEW with its exception caught, so
it still cannot fail the ingest.

~ /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

Rev 37567 – Schedule the catalogue delist daily at 05:30 Runs 30 ...

amit — Thu, 10 Sep 2026 11:58:19 +0530

amit – 2 file(s) modified
Schedule the catalogue delist daily at 05:30

Runs 30 minutes before the existing 06:00 scheduledPushDataToSolr in the same
class, so the same morning's reindex publishes it. A bulk UPDATE fires no
TagListingChangeListener event, so without that ordering the portal would lag
until 18:00.

Gated on catalog.autoDelist.enabled with an inline default of true - env profiles
have no fallback between each other, so a key missing from one profile's
properties would otherwise stop the context booting.

Also exposes --delistDeadListings for a manual run, honouring the same flag.

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

Rev 37566 – Delist logic v3: require a month of no movement; add ...

amit — Thu, 10 Sep 2026 11:58:08 +0530

amit – 4 file(s) modified
Delist logic v3: require a month of no movement; add CatalogDelistService

Zero stock alone was too weak a test. It fired on SKUs partners were still
transacting, where the recent movement was often the very sale that emptied the
stock. v3 additionally requires no movement for a month on either side:
- SmartDukaan via warehouse.scanNew (3.4M rows, live). Note warehouse.scan is a
dead Saholic relic - 2,476 rows, last write 2012.
- any partner via fofo.scan_record, any scan type.
Phrased as NOT EXISTS so they short-circuit on the first recent row and use the
(inventoryItemId, scannedAt) / (inventory_item_id, create_timestamp) indexes.
An item that has never moved still qualifies, which is correct.

Also in v3:
- the internal pseudo-brands (Dummy, FOC, FOC HANDSET, Live Demo) are no longer
excluded and are swept like anything else.
- vendor-PO guard narrowed to status = 1. PARTIALLY_FULFILLED is UNREACHABLE,
not merely rare: none of the 8 PO-status writes in the codebase sets it, no
native SQL writes the column, and status = 2 has 0 rows across 51,593+ POs
back to 2011. Partial receipt is modelled per line (unfulfilledQuantity), so a
part-received PO sits in READY and is already caught. Documented so it is not
'restored' later as a supposed gap.

CatalogDelistService/Impl mirrors the migration statement for statement, for the
daily scheduled run. Bulk SQL rather than per-row updateActiveById +
publishStatusChange, which would commit to Solr once per catalog (~1,750 times
on the 2026-09-10 backlog); the job is instead scheduled ahead of the existing
06:00 full reindex. The dark-model step is deliberately house-wide rather than
run-scoped so it converges instead of leaving pre-existing dark models on a
stale RUNNING forever.

rollback_delist_recent_movement_20260910.sql restores the 24 listings / 21
models that the v2 run delisted before NEW 3 existed; their partners had
transacted them within the month. Id list frozen, not re-derived.

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/catalog/CatalogDelistService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/catalog/CatalogDelistServiceImpl.java
~ /trunk/profitmandi-dao/src/main/resources/sql/delist_inactive_listings_rolling_24m.sql
+ /trunk/profitmandi-dao/src/main/resources/sql/rollback_delist_recent_movement_20260910.sql

Rev 37565 – IMEI activation: 20s tick lanes for oppo/realme/vivo, idle once the ...

amit — Thu, 10 Sep 2026 03:00:55 +0530

amit – 7 file(s) modified
IMEI activation: 20s tick lanes for oppo/realme/vivo, idle once the day clears

Replaces the two once-a-day passes with chunk-per-tick lanes. Each tick takes one
chunk and returns; when a brand's pool comes back empty its turn is skipped, and
when everything is clear the ticks do nothing and stay silent until midnight.

- browser lane (StandAlone): one chunk of 25 for one brand every 20s, oppo and
realme by turns. Still exactly one ChromeDriver alive at a time.
- vivo lane: its own tick, chunk of 250. It must not share the browser lane --
0.24s an imei against oppo's 10.2s means it would need ~70 hours behind them
for work it does alone in 39 minutes.

The snapshot is gone; the pool query is the cursor. That is what makes a restart
cost one chunk instead of the day: the 12:03 restart on 09-Sep forfeited ~4,000
lookups and the whole afternoon, and last_finish had read -1 for three days.

The snapshot existed to stop the re-ask loop (realme, 29-Aug: 4,524 requests
against 1,004 distinct imeis). That is now closed at the source instead -- oppo,
realme and motorola stamp every imei they asked about, not just the ones that
produced a map entry, so a failed lookup rests until tomorrow rather than coming
back on the next tick. Motorola is fixed pre-emptively; nothing schedules it yet.

Also:
- secondary and tertiary are merged by turns rather than concatenated. Safe while
a pass walked to the end; without that guarantee oppo's 163 tertiary serials sat
behind 3,819 secondary ones and would only be reached on a day that cleared.
- vivo abandons a tick rather than the chunk when the captcha solver returns no
code -- one probe per 20s while it is down instead of 250, and no rows rested
over a transient outage.
- the funnel gauges move from a pass to a day. due is measured on the first tick
after midnight, the rest accumulate, and last_finish_epoch becomes a real
completion clock. Truncation is detected at the midnight rollover, which is the
case that never reaches an end-of-run at all.

This does not create capacity. At the 21s/imei measured on 09-Sep the pool still
needs ~35 hours and will not clear; it now rolls over visibly instead of silently.
The lever for that is DAYS=1.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/ImeiActivationGauges.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/MotorolaImeiActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/OppoImeiActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/RealmeImeiActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/StandAlone.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/VivoImeiActivationService.java

Rev 37564 – Creation screens request only live listings from the item typeahead ...

amit — Thu, 10 Sep 2026 02:59:56 +0530

amit – 5 file(s) modified
Creation screens request only live listings from the item typeahead

/item takes an activeOnly flag (default false, preserving current behaviour)
and passes it to getAllPartnerItemStringDescription. getItemAheadOptions takes
an optional 4th argument, so existing 3-argument callers are unaffected.

Sent true from the two creation entry points:
- warehouse purchase (PO) invoice line picker
- the new-price-drop modal (#typeaheaditem)

Left false where the screen works on records that already exist and may since
have been delisted: the price-drop pause/manage picker (#typeaheaditem1),
catalog-item, combo and prebooking.

jsVersion 419 -> 420 to cache-bust common.js / warehouse-purchase.js (419 was
already taken by another change).

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/PriceDropController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/common.js
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/warehouse-purchase.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/price-drop.vm

Rev 37563 – Filter delisted SKUs out of creation pickers; add rolling 24m ...

amit — Thu, 10 Sep 2026 02:52:18 +0530

amit – 7 file(s) modified
Filter delisted SKUs out of creation pickers; add rolling 24m delist migration

Creation screens could offer items whose catalog.tag_listing.active = 0:
- Item.selectAllModels (scheme/offer model dropdown) joined tag_listing with
no active predicate. Adding tl.active = true also gives the model-level
rollup, since callers dedupe to catalogItemId: a model whose colours are
all inactive now yields no rows, one keeping a listed colour stays.
- The shared partner item picker had no active filter at all. Added a second
basis via getAllPartnerItemStringDescription(anyColor, activeOnly);
activeOnly participates in the fofoItems cache key so the two bases cannot
serve each other's cached results. Default stays false for screens that
inspect or edit existing records.
- New TagListing.selectActiveItemIds named query backs the filter.

Also adds the rolling 24-month delist migration: zero stock both sides, no
outstanding vendor PO (status IN (1,2), external supplier, unfulfilled > 0 --
INIT is excluded as it is a drawer of stale drafts), and re-categorises
fully-dark mobile models to OTHER. Idempotent, audited, rollback documented.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/catalog/Item.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/catalog/TagListing.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/catalog/TagListingRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/catalog/TagListingRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/InventoryService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/InventoryServiceImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/delist_inactive_listings_rolling_24m.sql

Rev 37562 – Add SQL to delist pre-2025 Samsung listings with no stock ...

amit — Thu, 10 Sep 2026 00:50:44 +0530

amit – 1 file(s) modified
Add SQL to delist pre-2025 Samsung listings with no stock

Marks 738 catalog.tag_listing rows (tag_id 4) inactive with eol_date
2026-09-08. These are Samsung listings published before 2025-01-01 holding
no stock in any SmartDukaan warehouse and none at any active partner store.

Id list is frozen from the prod evaluation rather than re-derived, so the
same listings are delisted in every environment; stock tables in a copy
drift from prod. Script is idempotent and carries guards, verification and
a rollback block.

Applied to prod hadb1 and the local dev copy.

+ /trunk/profitmandi-dao/src/main/resources/sql/delist_samsung_pre2025_no_stock.sql

Rev 37561 – ticket download option given and some enhancement on notification panel

ranu — Wed, 09 Sep 2026 18:10:22 +0530

ranu – 1 file(s) modified
ticket download option given and some enhancement on notification panel

~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/rbm-drr-dashboard.vm

Rev 37560 – ticket download option given and some enhancement on notification panel

ranu — Wed, 09 Sep 2026 17:55:00 +0530

ranu – 3 file(s) modified
ticket download option given and some enhancement on notification panel

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/CsController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/managerTicket.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/my-partner-tickets.vm

Rev 37559 – ticket download option given and some enhancement on notification panel

ranu — Wed, 09 Sep 2026 17:40:59 +0530

ranu – 5 file(s) modified
ticket download option given and some enhancement on notification panel

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/CsController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/send-notification.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/send-notification.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/ticket.vm

Rev 37558 – system generated leak bgc l2 can assign to l1 without ...

ranu — Wed, 09 Sep 2026 17:16:43 +0530

ranu – 4 file(s) modified
system generated leak bgc l2 can assign to l1 without any geo location

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/enumuration/dtr/LeadStage.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/enumuration/dtr/LeadStatus.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LeadController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/lead.vm

Rev 37557 – system generated leak bgc l2 can assign to l1 without ...

ranu — Wed, 09 Sep 2026 15:50:50 +0530

ranu – 1 file(s) modified
system generated leak bgc l2 can assign to l1 without any geo location

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

Rev 37556 – loi process added, revival and code changes process

ranu — Wed, 09 Sep 2026 14:51:37 +0530

ranu – 2 file(s) modified
loi process added, revival and code changes process

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

Rev 37555 – web offer sync: one value per SKU per payment mode ...

amit — Wed, 09 Sep 2026 14:42:05 +0530

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

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

Rev 37554 – web offer: put the brand back in the title ...

amit — Wed, 09 Sep 2026 13:34:48 +0530

amit – 2 file(s) modified
web offer: put the brand back in the title

SEPTEMBER 2026 MOTOROLA Rs.1,000 cashback on Credit Card Full Swipe
SEPTEMBER 2026 MOTOROLA No Cost EMI on 3, 6 months

Month and brand now both match the convention of the 3,850 hand-written rows, which
is how the admin listing is scanned. What stays gone is the redundant
'Cashback Offer-' label: the value already states what the offer is, and calling a
scheme-only row a cashback offer is what produced the live 'Cashback Offer- NA'
badges on 81 SKUs.

Brand comes from the division's catalog brand, falling back to its display name, so
a division with no catalog.brand row (Google) still reads sensibly rather than
emitting an empty gap.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/WebOfferSyncService.java
~ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/web/offercircular/WebOfferSyncServiceTest.java

Rev 37553 – web offer sync: all_banks is TINYINT(1), so never cast it ...

amit — Wed, 09 Sep 2026 13:11:25 +0530

amit – 1 file(s) modified
web offer sync: all_banks is TINYINT(1), so never cast it to Number

ClassCastException: java.lang.Boolean cannot be cast to java.lang.Number, thrown from
selectPublishableOffers on every ingest since 2026-09-08. Confirmed against the live
driver: SELECT all_banks returns java.lang.Boolean.

MySQL Connector/J maps TINYINT(1) to Boolean while Hibernate may hand back a Number,
so the value must be read through isTrue() - the same shape as ScopeConfig.isTrue and
OfferScopeRepositoryImpl.isTrue, both of which exist for exactly this reason and both
of which I had in front of me when writing the cast.

The failure was silent by design: CircularIngestRunner swallows sync exceptions so a
web-offer problem can never fail a good ingest. The circular kept publishing, the
document's processed_at kept moving, and the only symptom was that web_offer.synced_at
stopped advancing - which is what should have been checked before reporting the sync
as working on 8 September.

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

Rev 37552 – lead/knowlarity: stop a null lookup key from matching every row ...

amit — Wed, 09 Sep 2026 12:43:18 +0530

amit – 4 file(s) modified
lead/knowlarity: stop a null lookup key from matching every row

selectByEquals maps a null VALUE to NO PREDICATE AT ALL rather than to "= null",
because GenericRepositoryImpl.prepareEqualPredicate skips null entries. So a null
lookup key does not miss -- it selects the whole table and dies on
NonUniqueResultException. Two live call paths were doing exactly that.

RecordingService.updateAgentCallLog read caller_id, which knowlarity has never sent
on push-call-log: a sample of 50 live webhooks contained it zero times. Every call
therefore ran selectByCallerId(null) -> "select every sip_master row" -> throw, and
the whole feed was discarded. 17 of those 50 were Connected calls with a real agent.
Resolve the agent from agent_number instead, which is the field that actually
identifies them and holds the sip_url; it arrives bare, sip:-prefixed, or as the
literals "False"/"None" when nobody picked up. caller_id is still honoured first in
case they ever start sending it. A payload naming no agent is INFO, and an agent
missing from sip_master is WARN (an ops fix, and per-agent, so an ERROR would
fingerprint into one GlitchTip issue per agent).

AuthRepositoryImpl.putEmailOrMobile had the same hole via Long.parseLong(null)
falling into the catch and putting a null email. selectByEmailOrMobile(null)
degenerated to "select all 405 users", and authenticate(null, hash) degenerated to
"does ANY user have this password hash", which would answer true. Both fail closed
today only as an accident of how many rows the table holds, so the guard goes on the
one path they share.

Fixes GlitchTip #58/#1324/#1335 (fofo, 281 events) and #10 (web).

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/auth/AuthRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/auth/SipRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/auth/SipRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/kommuno/RecordingService.java

Rev 37551 – web offer: keep the month in the title ...

amit — Wed, 09 Sep 2026 12:42:06 +0530

amit – 2 file(s) modified
web offer: keep the month in the title

SEPTEMBER 2026 Up to Rs.4,000 cashback
SEPTEMBER 2026 Rs.1,500 cashback on Credit Card EMI
SEPTEMBER 2026 No Cost EMI on 3, 6 months

Matches the convention of the 3,850 hand-written rows and is how the admin listing is
scanned. The brand stays out - the product card already shows it, so that was the
redundant half, and dropping it is what makes room for the value to lead.

The month comes from the OFFER's own start date, not the circular's period: offers
run past a month end - four Aug'26 Apple offers ran to 26 September - and labelling
one of those AUGUST on a badge read in September would be wrong.

Rev 37550 – web offer: partner-facing titles, and stop calling a scheme offer ...

amit — Wed, 09 Sep 2026 12:37:13 +0530

amit – 3 file(s) modified
web offer: partner-facing titles, and stop calling a scheme offer a cashback offer

web_offer.title is partner-facing - StoreController and DealsController map it into
the product's offer list - so it now leads with the value rather than a filing label:

Up to Rs.4,000 cashback
Rs.1,500 cashback on Credit Card EMI
10% cashback up to Rs.7,500 on Credit Card EMI
No Cost EMI on 3, 6 months

Month and brand are gone: the card already shows the product, and the offer carries
its own dates. The full breakdown sits in detailedText below it.

This fixes a live defect. 16 published offers have no cashback at all, and the old
template rendered them 'SEPTEMBER 2026 XIAOMI Cashback Offer- NA' with detail 'NA',
on 81 SKUs. They are EMI-scheme offers and now say so.

Scheme inference at ingest: Motorola states the scheme in the DESCRIPTION rather than
the tenure cell - '[3&6 M]' plus 'Only NCEMI', where every other OEM writes
'6(NCE),9,12(LCE)'. TenureParser is right to return NONE for such a cell; the scheme
is simply not in it. Recovered in CircularIngestService where both columns are in
hand, and deliberately narrow: only when EVERY tenure came back without a scheme AND
the description names exactly one. On Sep'26 that is 10 offers, all Motorola; the
other 23 scheme-less rows are cashback offers whose descriptions are amounts, and
inventing a scheme for those would misstate the terms.

This distinction is money: four of the Motorola rows are LOW cost EMI, and calling
them no-cost would promise a partner something the bank will not honour.

'No cashback.' is dropped everywhere - the absence of an amount says it, and beside a
Cashback Instant Benefit scheme it flatly contradicted the name.

Tests 8 -> 12.

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

Rev 37549 – web offer sync: read tenures for scheme-only offers selectTenures, ...

amit — Wed, 09 Sep 2026 12:36:26 +0530

amit – 2 file(s) modified
web offer sync: read tenures for scheme-only offers

selectTenures, keyed by offer id like the benefit and bank reads.

Needed because an offer with no cashback is still a real offer - a no-cost or
low-cost EMI scheme - and its tenures are the only thing it has to say. Without them
those rows can only be described as 'NA'.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/WebOfferSyncRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/WebOfferSyncRepositoryImpl.java

Rev 37548 – v2 version some fixes

ranu — Wed, 09 Sep 2026 12:01:03 +0530

ranu – 2 file(s) modified
v2 version some fixes

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/User.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2UserController.java

Rev 37547 – v2 switch version fixes on server side

ranu — Wed, 09 Sep 2026 11:58:50 +0530

ranu – 1 file(s) modified
v2 switch version fixes on server side

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

Rev 37546 – web offer sync: compose detailed text from the parsed offer ...

amit — Tue, 08 Sep 2026 19:39:29 +0530

amit – 2 file(s) modified
web offer sync: compose detailed text from the parsed offer

detailedText is now built from benefit_timing + offer_benefit + offer_bank instead
of copying the circular's line:

Instant cashback. Rs.4,000 on Credit Card EMI; Rs.3,000 on Credit Card Full
Swipe. Banks: Axis Bank, ICICI Bank, State Bank of India (credit cards)

Every payment mode is always named, even when the circular's prose is terse
('10% CC EMI'), and the amounts come from offer_benefit - the authoritative
per-mode source. CC/DC cannot leak here at all, because the mode codes expand
natively rather than being patched by find-and-replace.

Three cases that would otherwise read badly:
- 21 offers carry NO benefit (circular cell 'NA', timing NONE). They are tenure-only
offers, so they read 'No-cost EMI. No cashback.' rather than showing a blank badge.
- The bank columns often list a bank under both card types while only one carries a
benefit. Card types shown are restricted to those actually paid on, or the text
would imply a debit offer that does not exist.
- benefit_timing UPI and NONE are not timings. Nothing is asserted rather than
inventing one.

smallText keeps the circular's short line - that column is only VARCHAR(256) and the
composed detail runs past it. One flowing paragraph, no line breaks, since the badge
may not render them.

Tests 8 -> 14.

Rev 37545 – web offer sync: read benefits and banks for the composed ...

amit — Tue, 08 Sep 2026 19:39:16 +0530

amit – 2 file(s) modified
web offer sync: read benefits and banks for the composed detail text

selectBenefits and selectBanks, keyed by offer id and fetched once per circular
rather than per offer - 259 offers would otherwise be 518 extra round trips.

The main query now also carries offer_id, benefit_timing and all_banks.

Bank read takes INCLUDE rows only: an EXCLUDE is meaningful only when all_banks=1,
and such an offer is described as 'All banks' rather than by listing an exclusion a
partner cannot act on.

Rev 37544 – web offer sync: expand CC and DC to Credit Card ...

amit — Tue, 08 Sep 2026 16:39:19 +0530

amit – 2 file(s) modified
web offer sync: expand CC and DC to Credit Card and Debit Card

The circular writes 'Rs.4000 Cashback on CC EMI'; a partner reading the badge should
see 'Credit Card EMI'. Applied to the title and the small/detailed text together, so
a badge and its detail never disagree.

Word-bounded and applied BEFORE truncation: an expansion is never cut in half, and
letters inside a word are untouched - the circular's cells carry strings like
'X300 Ext Kit' and 'ACCESSORIES', which an unbounded replace would corrupt.

On Sep'26 this affects 155 of 259 descriptions for CC and 48 for DC.

Two existing expectations updated to the new wording, and two tests added: one for
the expansion, one asserting DCX and ACCESSORIES survive intact.

Rev 37543 – receive debit note: resolve the DOA section from the declared ...

amit — Tue, 08 Sep 2026 12:10:42 +0530

amit – 2 file(s) modified
receive debit note: resolve the DOA section from the declared condition, not from a change

The condition dropdown renders with the partner's declared value already selected, so
a declared BAD - the ordinary DOA case - fired no change event and the DOA certificate
radios stayed hidden. The operator could not supply a certificate, and receiveDebitNoteItems
then refused the receipt for a missing one, making those debit notes unreceivable.

applyDeclaredConditions seeds each dropdown from the row's data-declared and settles the
dependent sections on load; the show/hide logic moves out of the change handler into
syncReceiveConditionState, which reads the current state of the form rather than whatever
was last touched. The change handler now calls the same function.

The server-side 'selected' stays as a fallback: without it a declared BAD would present as
GOOD if the script failed to load, and the server reads that difference as the warehouse
disagreeing with the partner, which rejects the whole debit note.

jsVersion 417 -> 418.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/business/return.js

Rev 37542 – loi process added, revival and code changes process

ranu — Mon, 07 Sep 2026 17:52:35 +0530

ranu – 1 file(s) modified
loi process added, revival and code changes process

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/enumuration/onBorading/onBoardingFormEnums/StoreType.java

Rev 37541 – loi process added, revival and code changes process

ranu — Mon, 07 Sep 2026 17:51:16 +0530

ranu – 2 file(s) modified
loi process added, revival and code changes process

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/enumuration/dtr/LeadSource.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/lead.vm

Rev 37540 – loi process added, revival and code changes process

ranu — Mon, 07 Sep 2026 17:49:34 +0530

ranu – 1 file(s) modified
loi process added, revival and code changes process

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/service/KnowlarityInsightsService.java

Rev 37539 – Fixed mail sender everywhere

amit — Mon, 07 Sep 2026 12:42:16 +0530

amit – 1 file(s) modified
Fixed mail sender everywhere

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

Rev 37538 – gstpro: a shipped delivery challan is a return, not a ...

amit — Sat, 05 Sep 2026 05:56:43 +0530

amit – 1 file(s) modified
gstpro: a shipped delivery challan is a return, not a cancellation

Movement becomes the single discriminator for both document types. Nothing has
left the warehouse, so nothing happened and the document can be withdrawn; once
the goods have shipped the document records a movement that really occurred, and
the only honest reversal is an opposing document - a credit note through finance.

The clock is the only thing that differs. A tax invoice must also be inside its
24h IRN window, because past that NIC will not cancel the IRN. A delivery challan
has no IRN and no acknowledgement - every DC row carries a placeholder irn and a
null ack_date - so no clock applies to it: an unshipped challan stays withdrawable
whatever its age, and its e-way bill is cancelled on that path since nothing moved
under it.

Previously a DC short-circuited to cancellable regardless of shipping, which would
have voided challans whose goods were already in transit.

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

Rev 37537 – carlcare activation: retry a transient failure once before giving up ...

amit — Fri, 04 Sep 2026 23:19:27 +0530

amit – 1 file(s) modified
carlcare activation: retry a transient failure once before giving up

One retry after a 1.5s backoff - long enough to clear the far end's rate window,
short enough to still fit inside a scheduler tick. A transient network blip was
otherwise recorded as a hard activation failure for that IMEI.

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

Rev 37536 – purchase return: order the invoice-return queue by what still needs ...

amit — Fri, 04 Sep 2026 23:19:26 +0530

amit – 2 file(s) modified
purchase return: order the invoice-return queue by what still needs doing

A return with no debit note sorts first - it is the one still owing an action -
and the screen reflects that ordering. Also refuses the cancel path when any order
on the invoice is in a state that must not be cancelled.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/PurchaseReturnController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/invoice-return.vm

Rev 37535 – purchase return: guard invoice cancellation, and surface rejected-with-DN returns ...

amit — Fri, 04 Sep 2026 23:19:17 +0530

amit – 2 file(s) modified
purchase return: guard invoice cancellation, and surface rejected-with-DN returns

PurchaseReturnServiceImpl gains assertInvoiceNotCancelled and assertNotGrnd, so a
cancellation is refused when the invoice is already cancelled or the goods have been
GRN'd - a return cannot be undone once the stock has been received in.

PurchaseReturnOrderRepositoryImpl also counts returns that were rejected but never
acknowledged by the retailer while carrying a debit note, which otherwise fell out
of the pending queue despite still owing an action.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/PurchaseReturnOrderRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/PurchaseReturnServiceImpl.java

Rev 37534 – loi process added, revival and code changes process

ranu — Fri, 04 Sep 2026 01:37:10 +0530

ranu – 2 file(s) modified
loi process added, revival and code changes process

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/SalesHierarchyBrandPartnerCountModel.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/SalesHierarchyBrandSoldModel.java

Rev 37533 – loi process added, revival and code changes process

ranu — Fri, 04 Sep 2026 01:35:50 +0530

ranu – 4 file(s) modified
loi process added, revival and code changes process

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/RbmTargetService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/RbmTargetServiceImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/RbmDrrDashboardController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/rbm-drr-dashboard.vm

Rev 37532 – gstpro: do not cancel a DC e-way bill once the ...

amit — Thu, 03 Sep 2026 18:23:08 +0530

amit – 1 file(s) modified
gstpro: do not cancel a DC e-way bill once the consignment has shipped

Three cases on cancelling a delivery-challan invoice:
- no EWB recorded: nothing to cancel at NIC
- already shipped: leave the EWB intact and void the challan locally. The goods
moved under that bill, so it is the record of a journey that happened; cancelling
would strip cover from it, and NIC refuses the cancel anyway once a bill has been
verified in transit. The return leg is a fresh movement needing its own EWB.
- never dispatched: cancel the EWB, since nothing moved under it.

Also reuses the orders already fetched for the shipped check rather than selecting
by invoice number twice.

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

Rev 37531 – offer circular: stop letter-led model names inheriting the previous variant ...

amit — Thu, 03 Sep 2026 18:22:12 +0530

amit – 2 file(s) modified
offer circular: stop letter-led model names inheriting the previous variant

A part that is ONLY a memory spec inherits the preceding model name, because Oppo
writes 'RENO 15 PRO 256GB, 512GB' and the second part is not a product. The pattern
matched too loosely: the optional unit group matched the FIRST letter of a model
name and the rest fell through the trailing character class, so 'G06, G37, G37
Power' inherited its way to 'G06 G37' - two Motorola phones fused into one entity
that matches no SKU, costing G37 its cashback on five offers.

Requiring a leading digit makes it a memory spec rather than anything that merely
contains G/T and digits. Realme 'GT 7' matches the same way and survived only
because it never follows a comma.

Same root cause as the word-boundary guards on CAPACITY and MEMORY_PAIR: a digit
glued to letters belongs to the model name.

ProductNamesTest: 11 -> 12, covering 'G06, G37, G37 Power' and 'GT 7T, GT 7'.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/ProductNames.java
~ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/web/offercircular/ProductNamesTest.java

Rev 37530 – purchase return: use the auto-approve check on invoice cancellation ...

amit — Thu, 03 Sep 2026 18:22:01 +0530

amit – 1 file(s) modified
purchase return: use the auto-approve check on invoice cancellation

Calls GstProService.isCancellableWithoutApproval (r37529) so a DC invoice, or an
unshipped order whose IRN is still cancellable, skips the approval step.

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