SmartDukaan – /

Rev 37631 – feat(mail): wire inactive-recipient filter, clean addresses, remove attendance alerts ...

amit — Tue, 15 Sep 2026 13:16:03 +0530

amit – 6 file(s) modified
feat(mail): wire inactive-recipient filter, clean addresses, remove attendance alerts

Wire MailRecipientFilter into both mail senders. Remove inactive hardcoded recipients, fix typo addresses, send market-share reminder to tech@. Delete sendAttendanceMorningAlert/EveningAlert, sendMailToHR and their CLI options.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/RunOnceTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/OnBoardingRelatedSchelduleTask.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/razorpay/FetchPartnersDisbursementTask.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasksTest.java

Rev 37630 – feat(mail): wire inactive-recipient filter and clean hardcoded addresses Wire ...

amit — Tue, 15 Sep 2026 13:16:02 +0530

amit – 9 file(s) modified
feat(mail): wire inactive-recipient filter and clean hardcoded addresses

Wire MailRecipientFilter into googleMailSender and gmailRelaySender. Remove inactive/unknown addresses from recipient and access lists, bulk uploader gate to akhil.kumar.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LeadController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LoiFormController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/PartnerOnBoardingPanelController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/RefferalController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/RetailerController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ServiceConfigContoller.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/WalletController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/WebListingController.java

Rev 37629 – feat(mail): wire inactive-recipient filter and clean hardcoded addresses Wire ...

amit — Tue, 15 Sep 2026 13:16:01 +0530

amit – 16 file(s) modified
feat(mail): wire inactive-recipient filter and clean hardcoded addresses

Wire MailRecipientFilter into googleMailSender and gmailRelaySender. Remove inactive/unknown addresses from recipient and access lists, fix typo addresses, bulk uploader gate to akhil.kumar, V2 brand fee gate to kamini.sharma.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/CartController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/OrderController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ContactUsController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LeadController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/StoreController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/UserController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoDashboardController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoLeadController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoLoiFormController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoMonitorController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoRefferalController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoRetailerController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoServiceConfigController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoWalletController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoWebListingController.java

Rev 37628 – feat(mail): filter inactive auth users from outgoing mail InactiveAuthUserRecipientFilter ...

amit — Tue, 15 Sep 2026 13:16:00 +0530

amit – 9 file(s) modified
feat(mail): filter inactive auth users from outgoing mail

InactiveAuthUserRecipientFilter drops @smartdukaan.com recipients whose auth.auth_user is inactive (cached, 5 min refresh, fail-open). Remove inactive hardcoded recipients (sm@, praveen.sharma, tejus.lohani).

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/PendingOrderServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/LocationTrackingServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/loiForm/LoiFormServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/InactiveAuthUserRecipientFilter.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/serviceConfig/ServiceConfigServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/TransactionServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/user/StoreTimelineTatServiceImpl.java
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/mail
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/mail/InactiveAuthUserRecipientFilterTest.java

Rev 37627 – feat(mail): drop inactive recipients before send Add MailRecipientFilter and ...

amit — Tue, 15 Sep 2026 13:15:59 +0530

amit – 5 file(s) modified
feat(mail): drop inactive recipients before send

Add MailRecipientFilter and RecipientFilteringMailSender, which strips To/Cc/Bcc addresses the filter reports inactive and skips a mail left with no recipients instead of failing. AuthenticatedIdentityMailSender now extends it.

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/services/AuthenticatedIdentityMailSender.java
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/services/MailRecipientFilter.java
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/services/RecipientFilteringMailSender.java
+ /trunk/profitmandi-common/src/test/java/com/spice/profitmandi/common/services
+ /trunk/profitmandi-common/src/test/java/com/spice/profitmandi/common/services/RecipientFilteringMailSenderTest.java

Rev 37626 – test(billing): assert internal transfer and billing resolve the same external ...

amit — Mon, 14 Sep 2026 18:57:21 +0530

amit – 1 file(s) modified
test(billing): assert internal transfer and billing resolve the same external origin vendor

~ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/BillingPricingServiceTest.java

Rev 37625 – fix(internal-movement): trace serial origin to the latest external purchase, matching ...

amit — Mon, 14 Sep 2026 18:57:18 +0530

amit – 3 file(s) modified
fix(internal-movement): trace serial origin to the latest external purchase, matching billing

- resolveInternalMovementPrices orders the serial's external purchases newest first (was oldest), so transfers and billing name the same original vendor; no in-stock unit on prod changes (0 of 3,734)
- Restore resolveInternalMovementPrices javadoc onto its own method
- Add drop_internal_vendor_catalog_pricing_20260914.sql, as run on prod 2026-09-14 17:33 (15 New Spice internal suppliers; backups _bak_vcp/_bak_vcpl_internal_20260914)

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementPriceModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepositoryImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/drop_internal_vendor_catalog_pricing_20260914.sql

Rev 37624 – feat(price-drop): auto-approve V2 price drop DP/MOP into external vendor catalog ...

amit — Mon, 14 Sep 2026 17:10:47 +0530

amit – 1 file(s) modified
feat(price-drop): auto-approve V2 price drop DP/MOP into external vendor catalog pricing

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

Rev 37623 – feat(price-drop): auto-approve price drop DP/MOP into external vendor catalog pricing ...

amit — Mon, 14 Sep 2026 17:10:46 +0530

amit – 2 file(s) modified
feat(price-drop): auto-approve price drop DP/MOP into external vendor catalog pricing

- PriceDropController calls VendorCatalogPricingService.applyPriceDrop with the affected date and logged-in user
- BillingPricingServiceTest: local-DB integration tests (rolled back) for origin-based billing prices, catalog fallback and re-billed orders

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/PriceDropController.java
+ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/BillingPricingServiceTest.java

Rev 37622 – feat(billing): price warehouse billing from the external supplier of the ...

amit — Mon, 14 Sep 2026 17:10:35 +0530

amit – 9 file(s) modified
feat(billing): price warehouse billing from the external supplier of the billed stock; auto-approve price drop DP/MOP into vendor catalog pricing

- BillingPricingService resolves TP/NLC per order from vendor_catalog_pricing of the most recent external supplier of the units scanned out (serial trace, else own external PO); units reversed by SALE_RET are ignored
- Falls back to the latest approved external catalog price when no supplier can be traced; vendorId stays the warehouse vendor
- addBillingDetailsForGrouppedOrders no longer reads vendoritempricing (removes NPE when the row is missing); order.vendorId set to the origin supplier
- VendorCatalogPricingService.applyPriceDrop writes approved pricing logs for external vendors with the price drop DP/MOP, keeping each vendor's TP on the effective date

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/BillingPriceModel.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InventoryItemExternalOriginModel.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/inventory/VendorCatalogPricingService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/VendorCatalogPricingServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/TransactionServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/BillingPricingService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/BillingPricingServiceImpl.java

Rev 37621 – V2 /entity honours activeOnly, defaulting to false Same defect ...

amit — Mon, 14 Sep 2026 17:09:03 +0530

amit – 1 file(s) modified
V2 /entity honours activeOnly, defaulting to false

Same defect as the fofo endpoint fixed in profitmandi-fofo r37620: the flag was
accepted and ignored. Defaulting to false keeps callers that omit it unchanged.

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

Rev 37620 – Offer creation suggests only active models unless asked for all ...

amit — Mon, 14 Sep 2026 17:08:58 +0530

amit – 4 file(s) modified
Offer creation suggests only active models unless asked for all

/entity accepted activeOnly but always searched with false, so the offer
screen's model picker listed every catalog of the brand, delisted ones included.
It now honours the flag. The default becomes false so the pages that never pass
it keep their current results; the notification product search, which already
asked for active-only, now gets it.

Each item-criteria block gets an Include inactive checkbox, off by default.
Ticking Exclude ticks it too: a brand-level offer still pays on delisted models
partners hold stock of, and they cannot be excluded if they cannot be picked.
Inactive models are labelled, and reloading the list keeps picks still present.

The reload flag is now per block; the old global one let a brand change in one
block be consumed by opening another, leaving the first with a stale list.
Brand names are URL-encoded so a brand like Ai+ is not sent as 'Ai '.

Requires profitmandi-common r37619 for the inactive label.

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

Rev 37619 – Return active_b in the unlimited content search The offer ...

amit — Mon, 14 Sep 2026 17:08:47 +0530

amit – 1 file(s) modified
Return active_b in the unlimited content search

The offer screen's model picker needs to mark delisted models as inactive when
it is asked to include them. The other unlimited-search callers read only
catalogId_i and title_s, so the extra field changes nothing for them.

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/solr/SolrService.java

Rev 37618 – logger added

ranu — Mon, 14 Sep 2026 15:12:29 +0530

ranu – 1 file(s) modified
logger added

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

Rev 37617 – Undo an internal GRN so its invoice can be received ...

amit — Mon, 14 Sep 2026 05:37:03 +0530

amit – 3 file(s) modified
Undo an internal GRN so its invoice can be received again

A receipt taken before the serials were split left stock that cannot be corrected in place: a
serialised unit is held one to a row, so an invoice that should have created several rows created one,
and the rows that are missing cannot be added without also unpicking the running figures the receipt
moved. Reversing the receipt and taking it again through the same path is the only way to arrive at
what the invoice actually says.

The reversal removes what receiving created - the scans, the inventory units, the invoice items, the
purchase and the supplier invoice - and gives back the two running figures it moved: the warehouse
availability, and the quantity taken off the purchase order line. Both are worked out from the rows
being deleted rather than recomputed, so whatever the receipt added is exactly what comes off. A
purchase order the receipt closed is opened again. Availability is kept only as a running count with
nothing to rebuild it from, which is why it is adjusted by what is known to have been added rather
than by anything inferred.

An invoice whose stock has moved since is refused, not worked around. A unit that has been scanned out
or partly consumed is no longer the receipt's to remove, and deleting around it would leave the
warehouse holding stock that no record explains. Each invoice is reversed on its own so one refusal
leaves the rest untouched, and a dry run reports everything it would delete and every figure it would
change without writing.

Invoices are named explicitly rather than selected by date, so a reversal can only ever touch what it
was given.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnReverser.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnTask.java

Rev 37616 – Split a line item's serials into one inventory unit each ...

amit — Mon, 14 Sep 2026 05:28:42 +0530

amit – 1 file(s) modified
Split a line item's serials into one inventory unit each

A serialised line item carries one serial per unit in serial_number, comma separated. The internal
GRN passed that whole field across as a single serial, so a line of four units became one unit whose
serial was the four serials joined together - a string no scan can ever match. Where the joined
string ran past the 128 characters the inventory column allows, the receipt failed outright; where it
fitted, it was accepted and the stock was quietly understated.

The serials are now split out and each unit is received on its own, which is what grnPoModels expects
- it creates one inventory row per serial.

A serial count that does not match the line's quantity now skips the invoice. Receiving fewer units
than were billed is exactly the failure this had, and it is not something to infer a best guess from:
the invoice is left for someone to look at instead.

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

Rev 37615 – Receive internal transfers the way the portal does, not via ...

amit — Mon, 14 Sep 2026 04:56:50 +0530

amit – 1 file(s) modified
Receive internal transfers the way the portal does, not via the Excel upload

The live run failed on every invoice with "Column 'status' cannot be null". The Excel upload path it
was calling, addPORowModels, persists a supplier invoice without ever setting a status, and the
column does not allow one to be absent, so that route cannot complete a receipt at all.

Rather than change a path the portal shares, this follows what the Receive Invoice screens actually
do: record the supplier invoice, record its items through InvoiceService.createInvoiceItem, then hand
it to PurchaseOrderService.grnPoModels, the call behind the Create GRN button. grnPoModels sets the
invoice to received itself, so the status is never left for the caller to remember.

Recording the invoice items matters beyond the receipt: warehouse.invoice_item is what the buying
reports join against, and the Excel path never wrote those rows either.

An invoice is carried as one entry per item rather than one per order, since that is the shape
grnPoModels expects - every serial of an item arrives together and a non serialised item arrives as a
single quantity. There is no supplier document to attach, which is ordinary here; most existing
warehouse invoices carry none.

Resolving the purchase order now uses the mapping recorded when the internal PO was raised - the
transaction it created, held on the purchase order - instead of walking every order to find it.
An invoice whose orders do not share that one transaction is skipped rather than guessed at.

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

Rev 37614 – Run each internal GRN in a transaction that is actually ...

amit — Mon, 14 Sep 2026 04:46:19 +0530

amit – 2 file(s) modified
Run each internal GRN in a transaction that is actually applied

The internal GRN one-off failed immediately with "no transaction is in progress", thrown while
flushing the Hibernate session at commit.

The per invoice method was annotated to start its own transaction, but it sat in the same bean as
the loop that called it. Spring applies @Transactional through a proxy, and a call from one method
of a bean to another never leaves the object, so the annotation was inert - the receiving ran with
no transaction at all while the driver had suspended the surrounding one. The repositories still
bound a session to the thread, and the flush at commit then found nothing to flush into.

The receiving moves to its own bean, so the driver now reaches it through the proxy and the
transaction is real. The driver keeps no transaction of its own, which is what lets one invoice
fail without disturbing those already received.

No change to what is received or to the conditions under which an invoice is skipped.

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnReceiver.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnTask.java

Rev 37613 – Receive internal transfer stock that was billed but never GRNed ...

amit — Mon, 14 Sep 2026 03:20:42 +0530

amit – 2 file(s) modified
Receive internal transfer stock that was billed but never GRNed

Stock moved between our own warehouses is dispatched against an internal purchase order and
billed, but the destination warehouse still has to receive it by hand through the portal. Where
that never happened the units exist on an invoice and nowhere in inventory, and there is no way
to clear a backlog of them short of keying each invoice in again.

This adds a cron one-off that receives them. Per invoice it builds the rows the Excel GRN upload
would have carried and hands them to PurchaseOrderService.addPORowModels, which creates the
supplier invoice, the purchase and the inventory items in a single call, so none of receiving is
reimplemented here - the portal and this take the same path and can only ever agree.

It is deliberately narrow about what it will touch. Only INTERNAL buyers, because nothing should
be able to receive a partner's goods on their behalf. Only invoices with no supplier invoice
already recorded, so a repeat run skips what it has already done rather than receiving twice.
Only invoices resolving to a single purchase order, since addPORowModels resolves one order for
the whole map it is given and would otherwise attribute an invoice to the wrong one - for the
same reason each invoice is passed on its own. A serialized line whose serial number is missing
aborts its invoice instead of creating a unit no scan could ever match.

Each invoice commits or rolls back on its own, so one bad invoice cannot undo the ones already
received, and a dry run reports what it would receive without writing anything.

The receipt is recorded against the destination warehouse, which is what warehouse inventory is
keyed by. The buyer on the order is read only to confirm the store is internal; partner side
inventory is a separate receipt and is not touched.

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

Rev 37612 – Value an internal PO's cart the same way the transaction ...

amit — Sun, 13 Sep 2026 02:37:36 +0530

amit – 1 file(s) modified
Value an internal PO's cart the same way the transaction validates it

Creating an internal PO failed with "Cart Value-Payment value mismatch" whenever a line
carried paise and the quantity was more than a handful. Two places were computing the same
cart total from the same stored float through two different decimal conversions, so they
disagreed on the value of prices binary cannot hold exactly.

createOrderInternally read WarehouseLineItem.unitPrice through String.valueOf, which
resolves a float via Float.toString and yields 10499.99, while createTransactionForWarehouse
re-values the persisted cart lines with BigDecimal.valueOf, which widens that same float to
double and yields 10499.990234375. The per-unit gap is around two ten-thousandths of a rupee;
quantity multiplies it, and it crosses the 0.001 tolerance the validator allows at a quantity
of five. Round prices are exact in binary and passed, which is why this looked intermittent
rather than total - across randomised carts the old arithmetic disagreed 98% of the time.

The total is no longer computed in its own loop. It is derived from the cart items that are
about to be written, using the conversion and the line-inclusion rule the validator applies,
so both sides are the same function over the same rows and cannot drift apart. That also
brings across two rules the PO side never had: quantities of zero or less, which
addItemsToCart drops and which therefore never reach the validated total, and the one paisa
carry bag, which the validator treats as a marker line rather than a billed one. Either of
those reaching an internal PO would have failed it outright, and a carry bag is only a
rounding error away from the paisa-per-unit pricing used for FOC stock.

The wallet top-up still truncates the total to whole rupees, and now lands within a rupee of
where it did before, well inside the twenty rupee buffer it already carried. Nothing outside
internal PO creation is touched: the validator, bulk orders and the refurb split keep their
existing numbers, and the wallet debit is driven by the order totals, not by this value.

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

Rev 37611 – Pin the unrecorded-stock behaviour Covers the shape behind the ...

amit — Sun, 13 Sep 2026 01:49:52 +0530

amit – 1 file(s) modified
Pin the unrecorded-stock behaviour

Covers the shape behind the 2026-09-12 bulk-upload failures: an item with some stock
traceable to a vendor and some with no recorded origin must move in one order, at the
traceable stock's price. Two genuinely different vendors must still refuse.

Also pins that no refusal message quotes a zero price from either side - including when the
oldest stock is itself the unrecorded pile, which is how 'at 0.00 each' reached users.

Requires profitmandi-dao r37610.

~ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceTest.java

Rev 37610 – Carry stock with no recorded origin along instead of refusing ...

amit — Sun, 13 Sep 2026 01:49:46 +0530

amit – 1 file(s) modified
Carry stock with no recorded origin along instead of refusing the movement

A movement was refused whenever an item had some stock traceable to a vendor and some whose
origin was never recorded, telling the user to raise a second purchase order for the rest.
Unrecorded stock has no vendor of its own, so that second order carried no more information
than the first - and the prices were identical anyway: boAt 34336 at 85 both ways, Samsung
36343/36344 at 1099, Riversong 36589 at 524, 36590 at 657. Bulk uploads of 200 rows were
dying on the first such item, repeatedly.

Only a second ORIGINAL VENDOR stops an order now, which is the case the refusal was for: a
line item holds one price per item, so units genuinely bought from someone else cannot ride
along. Unrecorded units move with the oldest stock at its price. They are not attributed to
that vendor as a fact - nothing persists origin today, but if that is ever added they must
not be stamped from this.

The refusal also reported unrecorded stock as moving at 0.00. Such a bucket carries no price
until it is resolved from the catalog when units are allocated, so reading one off it early
reported perfectly good stock as worthless. Both sides of the message now resolve the price
the same way the allocation does.

Three tests added: a mixed traceable/unrecorded item moves in one order, two genuinely
different vendors still refuse, and no message quotes a zero price from either side.

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

Rev 37609 – Offer the stock a warehouse actually holds when ordering from ...

amit — Sat, 12 Sep 2026 18:29:44 +0530

amit – 4 file(s) modified
Offer the stock a warehouse actually holds when ordering from an internal supplier

The purchase order item picker listed whatever the supplier had vendor catalog pricing rows
for. For an outside vendor that is right - the order is for stock nobody holds yet, so their
catalogue is the only sensible list. For one of our own warehouses it is not: a movement can
only send stock that is standing there, and the pricing rows were never a statement about
stock. Vendor 275 was offering 6,845 items while Noida held 79; Delhi 6,637 against 330.

It also made the picker depend on data the movement no longer needs. Pricing for internal
suppliers is derived from the stock itself since r37603, so those rows are inert - but
clearing them emptied the picker completely, because selectVendorItems joins
VendorCatalogPricing to Item and an internal supplier then matched nothing.

Internal suppliers now list distinct items with currentQuantity > 0 in their mapped
warehouse. External suppliers are untouched and still list from vendor catalog pricing.

~ /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/WarehouseService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseServiceImpl.java

Rev 37608 – Select a default schema before the multi-table deletes MySQL's ...

amit — Sat, 12 Sep 2026 17:57:09 +0530

amit – 1 file(s) modified
Select a default schema before the multi-table deletes

MySQL's 'DELETE alias FROM' form needs a default database even when every table is fully
qualified, so the deletes aborted with 'No database selected' while the backups above them
had already been written. Added USE inventory so the script runs end to end regardless of
how the client is invoked.

Run on hadb1 2026-09-12: 12,372 + 17,241 + 33,252 internal-supplier rows removed, external
pricing untouched at 40,670 / 45,049 / 68,749.

~ /trunk/profitmandi-dao/src/main/resources/sql/drop_internal_vendor_pricing_20260912.sql

Rev 37607 – SQL to remove vendor pricing held against internal suppliers ...

amit — Sat, 12 Sep 2026 17:45:19 +0530

amit – 1 file(s) modified
SQL to remove vendor pricing held against internal suppliers

Nothing reads these since r37603-05: an internal movement is priced from the stock being
moved, resolved to the original external vendor, and receiving no longer validates price for
those movements. A stale row would silently win over the derived price if any lookup were
reintroduced, so they are worse than inert.

Backs every row up to a _bak_ table and deletes against those frozen backups rather than
re-reading supplier.internal, so what is removed is exactly what is preserved. Run only
after the fofo WAR carrying the warehouse-grn-request-items.vm guard (r37606) is live.

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

Rev 37606 – Render a dash, not a raw reference, when there is ...

amit — Sat, 12 Sep 2026 17:45:11 +0530

amit – 1 file(s) modified
Render a dash, not a raw reference, when there is no system price

warehouse-grn-request-items.vm called getTransferPrice() straight off a map lookup with no
null guard. An internal movement has no vendor circular to quote a system price from, so
that lookup misses and Velocity prints the literal reference text into the System Price
column - it fails quietly rather than erroring, so the screen just looks broken.

Renders '-' instead, which is what the column actually means for a movement priced from the
stock itself. Prerequisite for removing internal-supplier pricing rows.

~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse-grn-request-items.vm

Rev 37605 – Use the derived movement price in the v2 vendor controller ...

amit — Sat, 12 Sep 2026 17:01:11 +0530

amit – 1 file(s) modified
Use the derived movement price in the v2 vendor controller too

Same change as the fofo controller: /getPricing returns the movement price for internal
suppliers, and addVendorPricingIfMissing is gone. This copy is component-scanned, so
leaving it behind would have kept writing the pricing rows the fofo side stopped writing.

Requires profitmandi-dao r37603.

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

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

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