SmartDukaan – /

Rev 37604 – Show the derived movement price when building an internal purchase ...

amit — Sat, 12 Sep 2026 17:00:50 +0530

amit – 4 file(s) modified
Show the derived movement price when building an internal purchase order

Both places a price reaches a purchase order now use the movement price for internal
suppliers: the single lookup as an item is added on screen, and the per-item resolution
behind a bulk upload, which does the whole file in one pass instead of loading a circular
the sending warehouse does not have.

Removes addVendorPricingIfMissing, which fired only when someone typed a numeric item id
into the search box, and only for Samsung or non-handsets, writing permanent approved
pricing rows onto the internal supplier from a hardcoded source vendor. Bulk upload never
called it at all, which is why the same item could be added on screen but rejected in a
file.

Tests cover what is decided once origins are known - drawing the oldest stock first,
refusing a quantity that spans two original vendors while naming how many can move and
asking for a separate order, refusing an unmapped supplier, and falling back to the catalog
without ever recording an inferred vendor as though it were known.

Requires profitmandi-dao r37603.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/VendorController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/warehouse/PurchaseOrderController.java
+ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse
+ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceTest.java

Rev 37603 – Price internal warehouse movements from the stock's original vendor ...

amit — Sat, 12 Sep 2026 17:00:04 +0530

amit – 11 file(s) modified
Price internal warehouse movements from the stock's original vendor

Stock moving between our own warehouses was priced from the sending internal supplier's
own vendor catalog, which only ever holds prices copied from elsewhere - so every hop let
the price drift further from what the group actually paid, and a movement was blocked
outright whenever that supplier happened to have no row for the item.

It is now derived from the stock being moved: the original EXTERNAL vendor is established
per unit and that vendor's current catalog price is used. Origin is looked for in
descending order of certainty - the serial traced back to the external purchase that first
brought the unit in, then the unit's own inbound PO when that was external, both of which
are facts that survive any number of internal hops. Non-serialised stock that has already
moved internally has no recoverable origin at all, since fungible units carry no identity
and the movement records nothing linking the receiving row to its source, so those fall
back to the most recent externally approved price for the catalog and are never recorded
as though their vendor were known.

A purchase order carries one price per item, so an item can only move from one original
vendor at a time. Where a requested quantity would run past the oldest vendor's stock into
another's, this refuses and reports how many can move now and at what price, leaving the
second order to whoever is moving the stock, rather than averaging the two or silently
splitting the order. Each order therefore stays attributable to one vendor.

Receiving no longer validates price for these movements: both sides of the comparison come
from the same derivation, so a mismatch cannot mean anything. That also removes a null
dereference in GrnRequestServiceImpl, which assumed every supplier has a circular.

Removes addVendorPricingIfMissing, which wrote permanent approved pricing rows onto internal
suppliers sourced from hardcoded vendor 334 for Samsung or an arbitrary findFirst() vendor
otherwise, stamped with hardcoded auth ids. Those rows are now not just unnecessary but
harmful: they would pin a stale price that wins over the derived one.

Verified against live data: covers every unit in every warehouse with none unresolved,
agrees exactly with the origin join the FOCO/ImeiSupplierPricing report already runs in
production, and prices 12,305 of 13,589 units within 2% of what was actually paid.
Resolution takes 0.7ms for one item and 1.1ms for ten.

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementAllocationModel.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementPriceModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/VendorCatalogPricingLogRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/VendorCatalogPricingLogRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/GrnRequestServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InvoiceServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 37602 – Remove no-op refreshSnapshotAgeing task; restore originalInventoryItemId backfill call refreshSnapshotAgeing ...

amit — Sat, 12 Sep 2026 14:51:26 +0530

amit – 2 file(s) modified
Remove no-op refreshSnapshotAgeing task; restore originalInventoryItemId backfill call

refreshSnapshotAgeing ran every 30 minutes aggregating warehouse.inventoryItem.rootInvoiceDate,
a column nothing ever wrote, so its UPDATE ... JOIN matched zero rows on every run and
currentinventorysnapshot.oldest_invoice_date was never populated on any of 11,686 rows.
Removed along with the sessionFactory field it was the only consumer of.

Application.java had migrations.migrateWarehouseOriginalInventoryItemId(batchSize) commented
out while still logging 'Starting migration...' and 'Migration completed.', so
--migrateOriginalInventoryItemId reported success while doing nothing. Restored the call;
it remains opt-in via the CLI flag and cannot fire on its own.

Requires profitmandi-dao r37601 (entity fields removed).

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

Rev 37601 – Remove dead stock-ageing fields rootInvoiceDate and oldest/newest_invoice_date rootInvoiceDate on ...

amit — Sat, 12 Sep 2026 14:51:19 +0530

amit – 3 file(s) modified
Remove dead stock-ageing fields rootInvoiceDate and oldest/newest_invoice_date

rootInvoiceDate on WarehouseInventoryItem had no writer anywhere in the codebase and
was read only by ScheduledTasks.refreshSnapshotAgeing(), which therefore matched zero
rows on every 30-minute run. oldest/newest_invoice_date on SaholicInventorySnapshot
were written only by that task and read by nothing. Verified on prod: null on all
1,528,669 inventoryItem rows and all 11,686 snapshot rows respectively.

Stock ageing that is actually in use resolves the original external supplier at query
time by serialNumber + supplier.internal = false, and does not read these columns.
originalInventoryItemId is deliberately left alone - it is populated on 157,020 rows.

Includes sql/drop_dead_ageing_columns_20260912.sql to drop the columns. Run it only
after web, fofo and cron are all on this build.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/inventory/SaholicInventorySnapshot.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/warehouse/WarehouseInventoryItem.java
+ /trunk/profitmandi-dao/src/main/resources/sql/drop_dead_ageing_columns_20260912.sql

Rev 37600 – Replace entity loads with scalar aggregates in the investment sweep ...

amit — Fri, 11 Sep 2026 20:40:13 +0530

amit – 4 file(s) modified
Replace entity loads with scalar aggregates in the investment sweep

Order.lineItem is a ManyToOne with FetchType.EAGER, so getInTransitOrders() and
selectPendingGrnOrders() pulled ~6,865 Order entities plus a LineItem for each
into the session every two minutes - all dirty-checked at flush - when the sweep
only reads getRetailerId() and getTotalAmount(). That, plus ~1,690 FofoStore and
~984 PartnerInvestment rows, put roughly 17,000 entities in one session per pass
and is most of the ~10s each sweep was taking.

Adds two scalar named queries returning (retailerId, sum(totalAmount)) grouped by
partner. A projection never hydrates the entity, so the eager association never
fires - about 13,700 entities become ~1,000 rows. The predicates copy
selectOrders(ids, pendingOrderStatus) and selectPendingGrnOrders(ids) exactly,
including the SD_START_DATE floor, and the comment on the named queries says to
change them together.

Deliberately NOT done by making lineItem lazy: that mapping is shared by every
Order consumer in the codebase and flipping it globally is a far wider change than
this needs.

Entity-returning variants are untouched for their existing callers. Drops the now
unused sumOrderAmounts helper and the TransactionService dependency.

Not a fix for a problem - the sweep was comfortably inside its 120s window at ~8%
duty. It removes waste that would matter if the cadence were ever shortened.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/transaction/Order.java
~ /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-dao/src/main/java/com/spice/profitmandi/service/PartnerInvestmentSweepService.java

Rev 37599 – Reuse the managed snapshot row in the sweep instead of ...

amit — Fri, 11 Sep 2026 20:09:50 +0530

amit – 2 file(s) modified
Reuse the managed snapshot row in the sweep instead of building a second instance

Every sweep after the first failed with 'A different object with the same
identifier value was already associated with the session :
PartnerInvestment#107198' and wrote nothing.

selectByFofoIds returns managed entities. The loop then constructed a fresh
PartnerInvestment for the same id and called saveOrUpdate on it, which Hibernate
rejects. Sweep one survived only because the table was empty, so no row was
managed - the failure could not appear until a second run.

Now mutates the row already in the session when there is one, falling back to a
new instance only for partners with no snapshot. The previous base and gross stock
are captured before mutation, since comparing the row against itself afterwards
would report nothing as ever changed.

persist() is kept: a no-op for the managed rows (dirty checking flushes them), and
still the INSERT for partners appearing between sweeps.

Drops baseDiffersFrom(), now unused - the comparison is against the captured prior
value, still rounded to paise by the setter on both sides.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/PartnerInvestment.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/PartnerInvestmentSweepService.java

Rev 37598 – Add missing @Transactional to the investment sweep The sweep ...

amit — Fri, 11 Sep 2026 19:57:29 +0530

amit – 1 file(s) modified
Add missing @Transactional to the investment sweep

The sweep failed on every run with 'Could not obtain transaction-synchronized
Session for current thread' and wrote nothing. BatchScheduledTasks deliberately
carries no class-level @Transactional - each partner gets its own via REQUIRES_NEW
in the helper beans - so the sweep ran outside a transaction and
sessionFactory.getCurrentSession() threw at the first repository call.

PartnerLimitHelper already does this correctly with @Transactional(readOnly=true)
on its read phase; the sweep simply did not mirror it. Compilation cannot catch
this - only a run can.

sweep() and refreshAgedStockDaily() both read and write, so they take a read-write
transaction. Annotations sit on the service rather than the caller because
BatchScheduledTasks is intentionally non-transactional, and the service is a
separate bean so the proxy applies.

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

Rev 37597 – Register /agedAppleImeis for the partner role RoleInterceptor authorises every ...

amit — Fri, 11 Sep 2026 19:55:40 +0530

amit – 1 file(s) modified
Register /agedAppleImeis for the partner role

RoleInterceptor authorises every non-admin request through
RoleManager.isAuthorizedURI(), which regex-matches the URI against dtr.api rows
reachable via dtr.role_api and throws GE_1004 when nothing matches. The new
aged-Apple IMEI endpoint (r37593) had no row, so partners would have been denied -
the Java change alone does not expose an endpoint.

Adds the api row and links it to FOFO, mirroring /activatedImeis (id 215) and
/activated-imeis-grn-pending (id 285). FOFO_ADMIN needs no row because isAdmin()
short-circuits before the lookup.

Applied to hadb1: api id 330, linked to role FOFO. Both inserts are guarded by
NOT EXISTS so the script is safe to re-run per environment.

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

Rev 37596 – Mirror the gateway sanction when a hard limit is released ...

amit — Fri, 11 Sep 2026 19:43:21 +0530

amit – 1 file(s) modified
Mirror the gateway sanction when a hard limit is released

/resetHardLimit set hard_limit=false and reverted credit_limit to suggested_limit
but never touched dtr.credit_account, so the SIDBI/SDDIRECT gateway kept the old
pinned sanction until some later full limit pass rewrote it. Releasing a hard
limit can move the number a long way - RJAMR501 Inder Mobile is pinned at 800,000
against a suggested 909,114, so the gateway would under-report him by 109,114.

This was previously masked rather than absent: the 20-minute pass rewrote ~220
partners every run because float noise made almost every comparison look like a
change, which repaired the mirror by accident. Rounding that comparison to paise
(r37589) removed the accidental repair and moving the full pass to daily (r37595)
stretched the window to most of a day, so the gap is now worth closing properly.

Mirrors sanctioned/available in the same request, matching what
/creditRequirement already does, and stamps update_timestamp so the change is
visible as a real limit movement.

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

Rev 37595 – Move the full partner-limit pass from every 20 minutes to ...

amit — Fri, 11 Sep 2026 19:24:56 +0530

amit – 1 file(s) modified
Move the full partner-limit pass from every 20 minutes to daily

The 2-minute sweep already recalculates the limit for every partner whose base
moved, which covers investment and utilisation - the inputs that actually change.
The full 980-partner rescan only exists for inputs base cannot see: credit risk,
the SIDBI floor and hard_limit.

Those move on a far slower clock. RISK_DECREASE_DAYS_THRESHOLD is 90 days, and
transaction.fofo_sidbi_sanction has had no new row since Oct 2024 and no recorded
settlement. Running the rescan 72 times a day to catch them was 71 wasted passes.

Folded into the existing daily job, after the aged-stock refresh so the limit pass
sees haircuts for partners whose Apple or demo stock crossed its threshold
overnight. Leaves two scheduled jobs instead of three.

Limit latency is unaffected - that is the 2-minute sweep's job and it is unchanged
(~3 partners per window show a changed base, peak 18). The --updatePartnerLimitWithBatch
CLI entrypoint is untouched for manual runs.

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

Rev 37594 – Format activated-stock amounts as currency on the dashboard banners ...

amit — Fri, 11 Sep 2026 19:22:09 +0530

amit – 2 file(s) modified
Format activated-stock amounts as currency on the dashboard banners

Both banners rendered the raw float - '112682.0' instead of a formatted amount -
because the value sat in a plain <strong> with no currency class, so
common.js formatCurrency() never picked it up. The sibling
dashboard-grn-pending-activated-imeis.vm already had the class, which is why one
banner formatted and the one above it did not.

No jsVersion bump needed: template-only change, no JS or CSS touched.

~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/analysis-dashboard-activated-imeis.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/dashboard-activated-imeis.vm

Rev 37593 – Show partners their aged Apple stock and why it lowers ...

amit — Fri, 11 Sep 2026 19:19:53 +0530

amit – 7 file(s) modified
Show partners their aged Apple stock and why it lowers their credit limit

Apple handsets held past 30 days are deducted when the credit limit is
calculated, but nothing told the partner - they saw a limit drop with no
explanation. Adds a dashboard banner alongside the existing 'activated but not
billed' one, shown only when the partner actually has such stock (70 of 980
today), with the unit count, the value, and View Imeis for the detail.

- dashboard-aged-apple-stock.vm, parsed in dashboard1.vm under
#if($investments.aged_apple_qty > 0)
- count and value both read from the maintained partner_investment snapshot, so
the banner never runs its own query and always matches the amount the limit is
actually reduced by
- amount wrapped in <span class="currency"> so common.js formatCurrency() renders
it instead of a raw float
- /agedAppleImeis + aged-apple-imeis.vm list the units, excluding activated ones -
those are already deducted as activated stock and shown in their own banner, so
no handset appears in both
- click handler added to the existing activated-imeis.js rather than inline in the
fragment: an inline script in an AJAX-injected fragment re-registers
$(document).on on every load and stacks duplicate requests
- jsVersion 420 -> 421

~ /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/java/com/spice/profitmandi/web/controller/InventoryController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/business/activated-imeis.js
+ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/aged-apple-imeis.vm
+ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/dashboard-aged-apple-stock.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/dashboard1.vm

Rev 37592 – Fix live-demo deduction lost in the investment snapshot; maintain aged-Apple ...

amit — Fri, 11 Sep 2026 19:19:38 +0530

amit – 8 file(s) modified
Fix live-demo deduction lost in the investment snapshot; maintain aged-Apple qty

BUG FIX to r37588. InventoryService.getTotalAmountInStock() returns stock net of
live-demo units held past 90 days, and both original investment paths assigned
that netted value to inStockAmount - which is why
PartnerDailyInvestment.getTotalInvestment() carries no separate demo term. The
sweep stored the RAW snapshot sum and never applied the deduction, overstating
investment for 328 partners by Rs 5.19 crore and their limits by roughly Rs 1.3
crore. Maxwell validated clean earlier only because he holds no demo stock.

Fixed by storing what is measured and deriving what is computed: the column is
now in_stock_gross_amount and getNetInStockAmount() applies the haircut. The demo
holding moves on its own daily clock, so storing the netted figure would have
meant re-netting it in three places every time the haircut changed - the same
'two things must move together' trap behind the original cache bug. Deriving it
means a daily demo refresh flows through to stock and base with nothing to sync.

Also:
- aged_apple_qty stored on the snapshot and maintained on the same daily cycle as
aged_apple_stock_amount, so the partner banner reads a saved count instead of
running a count query per dashboard load, and count and value can never disagree
- selectPartnerStockCountMap mirrors selectPartnerStockValueMap, including the
activated exclusion
- selectAgedAppleStock lists the units behind the haircut for the partner view
- FofoUser exposes aged_apple_stock / aged_apple_qty
- stock-moved detection compares GROSS: a demo unit crossing 90 days changes net
stock but nothing physically moved, and that is the daily refresh's job

Schema: partner_investment_snapshot.sql updated (in_stock_gross_amount,
aged_apple_qty). Applied to prod - the table was empty, so it was dropped and
recreated from the script.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/PartnerDailyInvestment.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/PartnerInvestment.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/InventoryItemRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/InventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/FofoUser.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/PartnerInvestmentServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/PartnerInvestmentSweepService.java
~ /trunk/profitmandi-dao/src/main/resources/sql/partner_investment_snapshot.sql

Rev 37591 – Route V2 admin wallet adjustment through WalletServiceImpl Byte-identical duplicate ...

amit — Fri, 11 Sep 2026 17:30:13 +0530

amit – 1 file(s) modified
Route V2 admin wallet adjustment through WalletServiceImpl

Byte-identical duplicate of the fofo /walletUpdate handler, with the same missing
row lock. Points at the shared walletService.applyManualAdjustment so both
modules share one code path.

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

Rev 37590 – Route admin wallet adjustment through WalletServiceImpl /walletUpdate hand-rolled the ...

amit — Fri, 11 Sep 2026 17:30:12 +0530

amit – 1 file(s) modified
Route admin wallet adjustment through WalletServiceImpl

/walletUpdate hand-rolled the balance update and history row, bypassing the
service entirely, and read the wallet with selectByRetailerId instead of
selectByRetailerIdForUpdate - so unlike every other wallet path it took no row
lock, and a concurrent adjustment and purchase could lose an update.

Now calls walletService.applyManualAdjustment, which reuses getManualReference
for the reference allocation and routes the movement through
addAmountToWallet/consumeAmountFromWallet(forced). Behaviour is preserved: admin
debits stay forced, so they can still push a wallet negative as before. Removes
~45 duplicated lines.

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

Rev 37589 – Drive credit limits off the investment sweep; stop phantom limit ...

amit — Fri, 11 Sep 2026 17:30:03 +0530

amit – 3 file(s) modified
Drive credit limits off the investment sweep; stop phantom limit writes

Adds the 2-minute sweep schedule and points the limit recalculation at the
partners whose base_value actually moved, instead of rescanning all 980 every
20 minutes. Measured on production: 3 partners change per 2-minute window on
average, peak 18.

- ScheduledSkeleton: 2-min sweepPartnerInvestment, daily refreshAgedStockDaily
at 00:20; the 20-min full pass is kept as a backstop for inputs base does not
capture (risk, the SIDBI floor, hard_limit)
- BatchScheduledTasks.sweepPartnerInvestment: sweep, then limits for changed
bases only
- calculateChangedPartnerLimits(restrictTo) to support that
- scaleMoney(): round to paise before comparing and storing. The limit comes out
of a double multiply, so 65123.7400 round-tripped as 65123.740000000005 and
compareTo called it a change. 208 of 230 'changed' partners in one production
run differed by under half a paisa, rewriting sd_credit_requirement and
dtr.credit_account ~14,000 times a day for identical values and churning the
SIDBI mirror. Real changes were never below a rupee, so 2dp cannot suppress one.
- getFirstBillingDates: one grouped query instead of one per partner

Credit limits for 24 partners will rise on the first sweep after deploy - that is
the aged-Apple double-deduction correction landing (see r37588), not a defect.

NOTE: cron is a standalone Spring Boot jar; the new schedules only fire once it
is restarted with --spring.profiles.active=scheduled.

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

Rev 37588 – Serve partner investment from a 2-minute snapshot instead of a ...

amit — Fri, 11 Sep 2026 17:29:49 +0530

amit – 17 file(s) modified
Serve partner investment from a 2-minute snapshot instead of a 3-hour cache

getInvestment() was @Cacheable on a 3-hour Redis cache that addAmountToWallet
evicted but consumeAmountFromWallet did not. A partner whose advance payment was
swept straight to a loan had the money counted twice - once as a still-cached
wallet balance, once as the reduced utilisation - overstating their credit limit
by the payment x their tier until the cache expired.

Replaced with fofo.partner_investment, refreshed every 2 minutes by
PartnerInvestmentSweepService. Every coupled term is read in one pass, so wallet
and utilisation (and in-stock and aged-Apple) can never come from different
moments. A shorter TTL would only have made the error rarer - it scales with the
payment, not the delay.

- PartnerInvestment entity/repository + partner_investment_snapshot.sql
- PartnerInvestmentSweepService: 9 batched reads, stores base_value for change
detection, refreshes aged-Apple for partners whose stock moved intra-day
- getInvestment/getInvestmentsForFofoStores both read the snapshot, so the two
paths no longer disagree; live compute retained as fallback
- selectActivatedStockAmountByFofoIds: batches an N+1 that cost 233ms x 1690
partners (6.6 min -> 1.0 s)
- getFirstBillingDates: batches another N+1 (4.6 s -> 0.67 s)
- selectPendingGrnOrders(List) now applies the same SD_START_DATE floor as the
single-partner overload; the two were reporting different GRN-pending
- selectPartnerStockValueMap takes excludeActivated: an activated Apple handset
held past the aging window was added once to in-stock and subtracted twice
(activated stock, then the aged haircut). 90 units, 24 partners, Rs 65.19 lakh
double-deducted. Live-demo passes false - no overlap there.
- applyManualAdjustment: routes the two hand-rolled admin wallet adjustments
through WalletServiceImpl so they take the FOR UPDATE lock
- add_idx_order_grn_pending.sql: covering index, GRN query 1320ms -> 514ms

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/InventoryItem.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/PartnerInvestment.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/transaction/Order.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/InventoryItemRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/InventoryItemRepositoryImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/PartnerInvestmentRepository.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/PartnerInvestmentRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/OrderRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/TransactionRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/TransactionRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/InventoryServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/PartnerInvestmentServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/PartnerInvestmentSweepService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/wallet/WalletService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/wallet/WalletServiceImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/add_idx_order_grn_pending.sql
+ /trunk/profitmandi-dao/src/main/resources/sql/partner_investment_snapshot.sql

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

ranu — Fri, 11 Sep 2026 15:51:38 +0530

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

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

Rev 37586 – drr view modification

ranu — Fri, 11 Sep 2026 15:48:56 +0530

ranu – 5 file(s) modified
drr view modification

~ /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
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/retailer-details.vm

Rev 37585 – Fix web-offer sync: selectModelOffers join order (Unknown column 'o.id' in ...

amit — Thu, 10 Sep 2026 17:19:06 +0530

amit – 1 file(s) modified
Fix web-offer sync: selectModelOffers join order (Unknown column 'o.id' in 'on clause')

selectModelOffers led its FROM with offers.offer_product p and then joined
offers.offer_raw_row r ON r.offer_id = o.id, referencing alias o one join
before o was introduced. An ON clause resolves only against tables already
in the join order, so MySQL rejected it with SQLSyntaxErrorException:
Unknown column 'o.id' in 'on clause'. Every per-model sync since r37581 has
therefore failed - webOfferSync=FAILED on the 15:04 and 17:14 re-ingests of
document 4 - leaving the 166 legacy NULL-key row-badges active and zero
consolidated badges published.

Reordered to lead with offers.offer o, matching the proven shape of the
sibling selectRowOffers query. All three are inner joins so the result set
is unchanged; BEST_OFFER_WINS and ORDER BY p.catalog_id still resolve.

Verified by executing the corrected statement read-only against prod for
document 4: 733 rows over 314 distinct catalog ids, the expected model
count. Not caught by tests because all 53 offercircular tests are
stub-based (no Spring, no DB) and never execute this SQL.

Failure was visible only because r37568 records webOfferSync= in
ingest_summary; the runner still swallows the exception by design.

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

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

ranu — Thu, 10 Sep 2026 15:24:07 +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 37583 – ticket download option given and some enhancement on notification panel

ranu — Thu, 10 Sep 2026 15:21:19 +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 37582 – ticket download option given and some enhancement on notification panel

ranu — Thu, 10 Sep 2026 15:13:31 +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 37581 – web offer sync: retire the pre-consolidation badges instead of deleting ...

amit — Thu, 10 Sep 2026 14:58:44 +0530

amit – 2 file(s) modified
web offer sync: retire the pre-consolidation badges instead of deleting them

The sync now deactivates any CIRCULAR row with a NULL circular_offer_key on its next
run. A row-keyed badge is a fragment of what a consolidated badge says, so leaving it
active would show a partner the same offer twice - once whole and once in pieces.

That removes the DELETE from the migration entirely, which is strictly better:

* nothing is destroyed, so a bad sync is one UPDATE away from being undone
* web_offer_product has NO foreign key to web_offer, so the DELETE had to clear its
532 rows separately or strand them as orphans
* no window where a circular has no badges at all - the old ones stay live until the
new ones exist

The migration is now purely additive: one ALTER, safe to run ahead of the deploy, which
is how it was applied to prod.

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

Rev 37580 – web offer: state an EMI scheme the circular gave without ...

amit — Thu, 10 Sep 2026 14:55:17 +0530

amit – 3 file(s) modified
web offer: state an EMI scheme the circular gave without months

Rs.2,500 on Credit Card EMI (CIB) with IDFC First Bank, Kotak Mahindra Bank

52 Sep'26 offers have a bare 'CIB' tenure cell - the circular names the EMI type and
gives no months. TenureParser correctly yields no tenure row for a cell with no digits,
so the type vanished and the badge said only 'on Credit Card EMI'. Every one of those
52 carries a cashback, so it was 52 offers' worth of SKUs silent about the EMI they
apply to.

The type is stated because the circular stated it. The MONTHS are not invented,
because it did not give them - the same line the CIB expansion was left on.

Read from offer_raw_row.col_emi_tenure rather than stored: 'scheme, no month' is not a
tenure, and offer_tenure.tenure_months is NOT NULL, so persisting it would mean a fake
0 row standing for a fact that is not a tenure.

Only ever attached to an EMI mode, and real tenures always win over the bare code.

ModelOfferTest 8 -> 11.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/WebOfferSyncRepositoryImpl.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/ModelOfferTest.java

Rev 37579 – web offer: one badge per model, consolidating everything the circular ...

amit — Thu, 10 Sep 2026 13:47:02 +0530

amit – 2 file(s) modified
web offer: one badge per model, consolidating everything the circular grants it

Edge 60 Pro 12+256 carried five badges - a Full Swipe cashback, an EMI cashback and
three EMI schemes - and the partner's card listed all five. It now carries one:

SEPTEMBER 2026 Motorola Cashback Offer-2,500 On Credit Card EMI
& 2,000 On Credit Card Full Swipe

Models whose consolidated terms are IDENTICAL share a badge, so 314 models collapse to
~107 rows while every model still appears in exactly one.

Rules, from the taxonomy: any model has cashback on Full Swipe and/or EMI, instant or
deferred, plus NCE/LCE/CIB with tenures, and any of it may differ per bank.
- 'Upto' only where a mode carries several values - which is what per-bank pricing
looks like. One value is stated plainly.
- Highest value first.
- Banks ride with each line only when they DIFFER; one shared set is hoisted to a
single trailing 'Banks:' line. A third of models need the per-line form.
- An amount whose window is narrower than the badge's states its own end date. Apple
1025780 pays Rs.6,000 to the 16th then Rs.4,000 to the 26th; without this the badge
would advertise Rs.6,000 for ten days it is not available.

⚠️ Banks and tenures belong to the OFFER a line came from, never to the model. On Edge
60 Pro the no-cost EMI is ICICI on 3 and 6 months but SBI on 3 only, and the EMI
cashback is IDFC/Kotak with no tenure at all. Attaching the model's tenures to its
cashback would promise no-cost EMI on a bank that never offered it. This also corrects
an earlier reading of mine that called the SBI 3-month line a duplicate of ICICI's -
it is a different bank, not noise.

New ModelOfferTest, 8 cases, every one taken from a real Sep'26 row.

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

Rev 37578 – web offer sync: read what the circular grants each MODEL, ...

amit — Thu, 10 Sep 2026 13:46:45 +0530

amit – 3 file(s) modified
web offer sync: read what the circular grants each MODEL, not each row

selectModelOffers returns one row per (catalog_id, benefit), carrying the context that
qualifies it - the banks it applies to, its tenures and their scheme, the timing and
the window. Consolidation happens in the service; this is the read it needs.

LEFT JOIN on the benefit, because a scheme-only offer carries no cashback and dropping
it here would lose the NCE/LCE badge entirely.

Content-keyed writes alongside: selectSyncedByKey, insertKeyedWebOffer,
replaceProducts, deactivateMissingKeys. A badge is now identified by a sha256 of its
terms, so models with identical terms share one and a model appears in exactly one.

Migration add_web_offer_per_model.sql adds circular_offer_key + its unique key, and
drops the row-keyed CIRCULAR badges - one of those is a fragment of what a
content-keyed badge says and there is no mapping from five fragments to one whole, so
they are regenerated by the next ingest.

⚠️ web_offer_product has NO foreign key to web_offer, so its rows do not cascade and
are deleted explicitly or they are orphaned. web_offer_sync_shadow does cascade.
source='CIRCULAR' only - the 3,850 hand-authored rows are never touched.

~ /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
+ /trunk/profitmandi-dao/src/main/resources/sql/add_web_offer_per_model.sql

Rev 37577 – web offer: an EMI cashback names its tenures WITH their ...

amit — Thu, 10 Sep 2026 13:17:50 +0530

amit – 2 file(s) modified
web offer: an EMI cashback names its tenures WITH their scheme

Rs.2,500 on Credit Card EMI (NCE 3, 6; LCE 9, 12 months)

A bare '3, 6, 9, 12 months' says which tenures earn the cashback but not which of
them are no-cost - and at the counter the two facts are only useful together.

The trailing scheme sentence is dropped when an EMI benefit already carried it, since
it would state the same thing twice. It stays when the cashback is on Full Swipe only:
EMI is still available, it just is not what the cashback is on.

Tenures whose scheme the circular never gave keep their months but carry no label -
the months are real, the scheme would be invented.

Tests 16 -> 18.

~ /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 37576 – ticket download option given and some enhancement on notification panel

ranu — Thu, 10 Sep 2026 13:02:55 +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 37575 – ticket download option given and some enhancement on notification panel

ranu — Thu, 10 Sep 2026 12:51:28 +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 37574 – web offer: print the EMI scheme code, not a guessed ...

amit — Thu, 10 Sep 2026 12:45:42 +0530

amit – 2 file(s) modified
web offer: print the EMI scheme code, not a guessed expansion

NCE / LCE / CIB are industry standard and now appear verbatim:

Instant cashback. Rs.3,000 on Credit Card EMI (3, 6 months);
Rs.3,000 on Credit Card Full Swipe. LCE on 3, 6 months. Banks: ...

The expansions were not ours to invent. emi_scheme.display_name carries 'Cashback
Instant Benefit' for CIB, and the evidence contradicts it: the Sep'26 cell
'3 NC 6,9,12 CIB' puts CIB in ONE ladder with NCE, so it describes who bears the
interest on a tenure rather than how a cashback is delivered - and 53 of 55 CIB rows
carry a separate cashback amount anyway, which that expansion would make redundant.
Pine Labs' own docs define ICB as Instant Cashback on UPI; the circular writes CIB 60
times and ICB never.

A guessed expansion on a partner badge risks stating the opposite of the truth - for
CIB, advertising a benefit where the customer may in fact be bearing the interest.
The code cannot be wrong that way.

A scheme is still stated ONLY when the circular gave one; tenures with no scheme are
described as nothing at all.

Also fixes the singular: 'NCE on 3 month', not '3 months'.

Rev 37573 – ui look and feel color changing mode for drr

ranu — Thu, 10 Sep 2026 12:45:13 +0530

ranu – 1 file(s) modified
ui look and feel color changing mode for drr

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

Rev 37572 – web offer: state the whole offer in the title, and ...

amit — Thu, 10 Sep 2026 12:34:31 +0530

amit – 2 file(s) modified
web offer: state the whole offer in the title, and the EMI scheme in the detail

Title now states EVERY payment mode, highest first, in the house style of the
hand-written rows:

SEPTEMBER 2026 Samsung Cashback Offer-3000 On Credit Card Full Swipe
& 3000 On Credit Card EMI & 3000 On UPI

A partner scanning the card should see the whole offer, not just its best number.
Brand keeps its catalog casing (Samsung, not SAMSUNG). A scheme-only offer is still
titled by its scheme - calling it a cashback offer is what produced the live
'Cashback Offer- NA' badges.

Detail additions:
- the EMI scheme, when the circular gave one: '... Low Cost EMI on 3, 6 months.'
The circular states it in its own column ('3m,6m LCE' beside '3000 CC Full
Swipe/CC EMI/UPI') and a partner needs both halves.
- eligible tenures on an EMI benefit: 'Rs.3,000 on Credit Card EMI (3, 6 months)'.
Cashback 'on Credit Card EMI' is not actionable without knowing which tenures
qualify. Full Swipe and UPI carry no tenure, so they get none.

⚠️ A scheme is stated ONLY when the circular gave one. Tenures with no scheme are
described as nothing at all - naming them would read as a no-cost or low-cost claim
that was never made.

Tests 14 -> 16.

Rev 37571 – offer circular: the month unit was swallowing the EMI scheme ...

amit — Thu, 10 Sep 2026 12:34:19 +0530

amit – 2 file(s) modified
offer circular: the month unit was swallowing the EMI scheme marker

'M' is the month UNIT, not a separator, but the token loop flushed on it. '3m,6m LCE'
tokenises to 3, M, 6, M, LCE - each M banked its month as NONE, so the LCE arrived
with nothing pending and was silently lost.

74 Sep'26 offers carry a scheme in the tenure cell that never reached offer_tenure;
22 of them through this path ('3m,6m LCE', '6m,9m LCE', '3m & 6m LCE', '3m, 6m, 9m,
12m, 18m, 24m LCE'). The rest are bare 'CIB' cells with no months at all, which is a
separate case and left alone.

It also fixes '3M (NCE), 6M & Above LCE', where the M flushed BOTH groups before
either marker was seen - so an offer that is no-cost on 3 months and low-cost beyond
recorded neither.

This is money: no-cost EMI costs the customer nothing and low-cost does not, so a lost
marker is a term a partner could quote wrongly at the counter.

Months with no marker anywhere still bank as NONE via the end-of-cell flush - the same
answer the M branch used to give for a genuinely unmarked cell.

New TenureParserTest, 6 cases, covering the regression and the shapes that must not
change.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/TenureParser.java
+ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/web/offercircular/TenureParserTest.java

Rev 37570 – drr view color change

ranu — Thu, 10 Sep 2026 12:31:14 +0530

ranu – 1 file(s) modified
drr view color change

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

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