SmartDukaan – /

Rev 37708 – Migration: state the algorithm and lock mode, and why it ...

amit — Fri, 18 Sep 2026 04:26:13 +0530

amit – 1 file(s) modified
Migration: state the algorithm and lock mode, and why it runs before the release

hadb1 is MySQL 5.7, so adding a column rebuilds the table rather than only touching metadata.
At ~53k rows that is seconds and InnoDB permits concurrent reads and writes throughout, but
ALGORITHM/LOCK are now stated explicitly so it fails loudly rather than quietly taking a table
lock if that ever stops holding.

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

Rev 37707 – GRN price mismatch: say which PO the invoice will be ...

amit — Fri, 18 Sep 2026 04:21:02 +0530

amit – 3 file(s) modified
GRN price mismatch: say which PO the invoice will be received against, and what to do if it closes first

Resolving a price mismatch discards the PO line and raises a replacement dated to the invoice. That
replacement is what the invoice is received against, so it is the one that has to stay open long
enough for the stock to arrive - and it closes on its own after four days for a movement, six for a
vendor order. Until now nothing said so: the GRN simply stopped matching and the correction sat
holding stock that had already arrived.

The confirmation now states what is about to happen and what to do if the stock lands late, and the
request screen explains what Po Id is. Reopening is offered only where it exists - a movement can be
reopened from Purchase Orders, a vendor order cannot and needs a fresh PO.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/warehouse-purchase.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse-grn-request-items.vm

Rev 37706 – cart: take the cart row before any line, to break ...

amit — Fri, 18 Sep 2026 04:20:00 +0530

amit – 5 file(s) modified
cart: take the cart row before any line, to break a lock-ordering deadlock

InnoDB was rolling back cart edits with "Deadlock found when trying to get lock"
(GlitchTip #53, 27 deadlocks) and losing others to OptimisticLockException
"actual row count: 0; expected: 1" (11 issues, 42 events). Both are the same cause.

Two request paths took the same two rows in OPPOSITE orders. Adding a line INSERTs
into user.line, and line_cart_id_fk shared-locks the parent cart FIRST, line second.
Validation/hydration mutated the line rows FIRST and wrote cart.total_price second.
Run those concurrently on one cart and it is a cycle. Caught in the act on prod:

T1: INSERT user.line (cart_id=175180781) -> holds S on cart, waits S on line
T2: UPDATE user.cart SET total_price=269340.0, version=175 WHERE version=174
-> holds X on line, waits X on cart
*** WE ROLL BACK TRANSACTION (1)

Fix is to give every mutating path one order: cart, then lines. CartRepository gains
selectByIdForUpdate, and it is called as the first statement of each path that writes
a cart line. Re-taking it inside one request is a no-op.

A lock-ordering fix is all-or-nothing -- one path in the wrong order is enough to
re-form the cycle -- so this covers ALL TEN cart-line writers, not just the two that
happened to show up in the stack traces: createCartItem, clearCart, getCartValidation,
addItemsToCart (x2), addShoppingBag, validateForOpen (x2) and V2BillingController's
bind/unbindInsurance. The audit is worth re-running before adding another writer.

Note validateForOpen and getCartValidation WRITE despite their names (they correct
cart_line quantity/price and roll up cart.total_price), which is why a "validate" call
was ever holding write locks. The lock is placed accordingly; making those genuinely
read-only is a separate, larger change.

This also serialises concurrent edits to the SAME cart, which is what the @Version
column on Cart was already trying and failing to express. Different carts are
different rows, so there is no cost across partners.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/cart/CartServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/cart/v2/CartValidationServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/user/CartRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/user/CartRepositoryImpl.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2BillingController.java

Rev 37705 – PO list: show the transaction id so a movement can ...

amit — Fri, 18 Sep 2026 04:19:28 +0530

amit – 2 file(s) modified
PO list: show the transaction id so a movement can be found from the invoice being received

An internal movement is raised as a transaction, so the invoice on the GRN desk leads straight back to its PO
through that id. The list is a DataTable, so having the column makes it searchable - which is how someone finds
the PO to reopen when a receipt arrives after auto-close, instead of hunting through date ranges.

Placed after Status so existing column positions are unchanged.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse-purchase-order.vm

Rev 37704 – Reopen a movement PO whose stock arrived late, and stop ...

amit — Fri, 18 Sep 2026 04:18:12 +0530

amit – 8 file(s) modified
Reopen a movement PO whose stock arrived late, and stop stranding GRN price corrections

Internal movements auto-close after four days, which fits 99.6% of them - 5,491 of 5,515 receipts
land inside the window. The remainder leave the PO closed with the stock still in transit and
nowhere to receive it: 998 internal POs closed during 2026 still holding 21,996 unreceived units.

A closed movement PO can now be reopened from the purchase order list. Reopening stamps
reopenedAt, and auto-close measures from WarehousePurchaseOrder.getOpenSince() - reopenedAt when
set, the PO date otherwise - so a reopened PO gets the same fresh window a new one gets instead of
being closed straight back on the next sweep. Only movements between our own warehouses: an
external vendor PO that has closed is settled with that vendor, not reopened unilaterally.

Separately, a GRN price correction now checks that the PO it just raised is one the invoice can
actually be received against. Matching reads POs that are open and approved for the same supplier
and warehouse dated on or before the invoice; it never looks at the PO being corrected, so what
matters is that the new PO is receivable. 54 were not - backdated into INIT by the old approval
gate, hence outside the match - and each stranded silently: original line discarded, GRN completed
without it, the correction left holding a reservation for stock that had already arrived.

isOpen() names the open set - INIT, READY, PARTIALLY_FULFILLED - that the movement and commitment
queries already read.

Migration sql/add_po_reopened_at_20260918.sql adds reopenedAt, nullable and additive. It must run
before this ships: the entity maps the column.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/purchaseorder/POScheduler.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/warehouse/WarehousePurchaseOrder.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/GrnRequestServiceImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/add_po_reopened_at_20260918.sql
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/warehouse/PurchaseOrderController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/warehouse-purchase.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse-purchase-order.vm

Rev 37703 – GRN price mismatch: ask for the original PO to be ...

amit — Fri, 18 Sep 2026 04:10:51 +0530

amit – 2 file(s) modified
GRN price mismatch: ask for the original PO to be reopened instead of stranding a correction PO

Resolving a price mismatch raised a correction PO dated to the supplier invoice, and stored its id
on the GRN request item to receive against. But by then the stock has already arrived and the PO it
corrects is closed - every one of the 54 raised this way had its mapped PO in CLOSED. The
correction therefore had nowhere to land: the GRN completed against the original, nothing was ever
received against the correction, and it sat holding a reservation for stock that was not coming.
Backdated by nature, it also parked in INIT under the old approval gate, so it could not have been
received even if anyone tried.

Resolving a mismatch against a closed PO now says so and names it, asking for that purchase order
to be reopened first, rather than silently creating a second PO that cannot be used.

WarehousePurchaseOrder.isOpen() names the open set - INIT, READY, PARTIALLY_FULFILLED - that the
movement and commitment queries already read, so it stops being restated per caller.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/warehouse/WarehousePurchaseOrder.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/GrnRequestServiceImpl.java

Rev 37702 – Internal movement: an unapproved PO no longer dispatches stock ...

amit — Fri, 18 Sep 2026 04:06:59 +0530

amit – 2 file(s) modified
Internal movement: an unapproved PO no longer dispatches stock

A PO raised on one of our own warehouses also raises the order that moves the stock, and that
order pays and processes immediately - so raising it ships goods. The approval gate never
governed that half. It set the PO to INIT and mailed an approval link, then created and processed
the order anyway, several lines later and without consulting the status it had just set. The gate
held back receiving - PO list, GRN matching, auto-close all skip INIT - while dispatch went ahead
unconditionally.

That is how PO/07-26/52029 was delivered and invoiced while frozen out of GRN. Its goods had to be
received against a second PO raised for the purpose, leaving the first holding a phantom
unfulfilled quantity for two months.

Order creation now waits on approval. WarehousePurchaseOrder.isApproved() names the rule once -
INIT is the only state before approval, every other state is something the order has already been
approved to do - matching how the PO list, GRN matching and the auto-close sweep already read it,
so callers stop restating it.

Backdated POs are approved at creation since r37682, so this holds nothing up today; it is what
keeps the two halves from separating again if any future rule leaves a PO unapproved. Nothing
raises the order later, so such a PO simply does not move stock and has to be raised again once
approved - the safe failure, and it is logged.

Rev 37701 – PO create: expected stock counts toward the quantity, popover wording ...

amit — Fri, 18 Sep 2026 01:05:24 +0530

amit – 3 file(s) modified
PO create: expected stock counts toward the quantity, popover wording follows

Stock still to arrive is now part of what the order can take, so the breakdown reports it as a
qualifier on that number rather than as something set aside - 'Of these, still to arrive' instead
of 'On the way in (not yet received)', which read as though it could not be ordered.

Tests follow the two rule changes: expected receipts can be ordered against, a quantity beyond
what is held and expected together is still refused and says so, and availability counts expected
receipts toward what can move. 21 tests pass.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/warehouse-purchase.js
~ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceTest.java

Rev 37700 – Internal movement: order against expected stock, and stop reserving lines ...

amit — Fri, 18 Sep 2026 01:05:17 +0530

amit – 3 file(s) modified
Internal movement: order against expected stock, and stop reserving lines that can no longer ship

Two rules changed, both about stock that was being treated as unavailable when it is not.

Stock still to arrive now counts toward what a movement order can be raised for. A movement is
planned against what the warehouse will hold, so the order is raised now and dispatched once the
stock lands; previously a warehouse holding only inbound stock refused outright, even though the
receipt was already on an open order.

A purchase order line stops reserving stock once its own order moves past being submitted for
processing. Billed or shipped means the units have already come off the shelf; cancelled means
the line can never dispatch them. Holding either back a second time hid stock that was genuinely
free - on prod, 660 of 675 reserved units were on lines whose orders had already moved on. A line
whose order has not been raised at all is still a live promise and keeps its hold, and a line is
held only for the quantity still sitting in an in-process order, so a partly-shipped order
releases the rest.

priceFor and describeAvailability continue to read stock through one shared examine(), so what is
shown while choosing a quantity stays exactly what the order is created against.

~ /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/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java

Rev 37699 – Fix: movement availability popover rendered empty except the closing note ...

amit — Thu, 17 Sep 2026 22:56:54 +0530

amit – 3 file(s) modified
Fix: movement availability popover rendered empty except the closing note

The breakdown was built as a table. Bootstrap 3.4.1 sanitizes popover content against a
whitelist that includes neither table nor its rows and cells, and it removes a non-whitelisted
element together with everything inside it - so the whole table was dropped and only the note
survived, leaving a popover that referred to orders that were not shown.

Rebuilt from divs and spans, which are whitelisted. Sanitizing stays on rather than being
switched off for this popover: the content carries PO numbers and warehouse names read out of
the database.

Also stops the zero-quantity note pointing at orders that are not there - a warehouse whose
only stock is still inbound has nothing promised to point at. jsVersion bumped.

Rev 37698 – V2 getPricing: carry internal movement availability alongside the price ...

amit — Thu, 17 Sep 2026 22:46:05 +0530

amit – 1 file(s) modified
V2 getPricing: carry internal movement availability alongside the price

Mirrors the fofo change so the two /getPricing endpoints answer alike. V2 is dormant but
component-scanned, so it has to keep compiling against the service signature.

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

Rev 37697 – PO create: show what can move, and which orders hold ...

amit — Thu, 17 Sep 2026 22:45:53 +0530

amit – 5 file(s) modified
PO create: show what can move, and which orders hold the rest, while the quantity is typed

Picking an item on a movement order already called getPricing, which read the sending
warehouse's stock and returned only a price. It now returns the availability too, so the row
can show it: an info marker beside the quantity box opens the breakdown - in stock, promised
with each holding order named by PO number and date, anything still arriving, and the quantity
this order can take.

The quantity box flags the moment what is typed passes that cap, so it is corrected before
submitting rather than after being refused. The marker turns amber when stock is partly
promised and red when none can move.

Outside vendors are unaffected: their pricing response carries no availability and their rows
are left exactly as they were. jsVersion bumped so the screen picks up the new script.

Tests cover the four cases that matter: what can move with orders named, zero movable reported
rather than refused, this order's cap kept separate from what the warehouse holds when stock
came in at two costs, and a warehouse holding none of the item still refusing.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/VendorController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/warehouse-purchase.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse-purchase-order-add-item.vm
~ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceTest.java

Rev 37696 – Internal movement: report what a warehouse can actually send, not ...

amit — Thu, 17 Sep 2026 22:45:33 +0530

amit – 6 file(s) modified
Internal movement: report what a warehouse can actually send, not just refuse on submit

The quantity a movement order can take was only discovered by submitting the order and being
refused. The stock reading that decides it already computed everything needed to say so in
advance - what is on the shelf, what older orders have promised, what is still arriving - and
then discarded it.

selectOpenOutboundCommitments returns those promises one row per order, with the PO number,
PO date and destination, instead of a single summed quantity. applyOutboundCommitments now
aggregates those rows and behaves exactly as before, so no extra query is run.

describeAvailability answers with the price plus that working. It shares one stock reading with
priceFor via examine(), so the cap shown while choosing a quantity and the cap enforced on
submit cannot drift apart. Unlike pricing it reports rather than refuses: stock that is entirely
promised comes back as zero movable with the orders holding it named, which is what lets someone
chase an abandoned order rather than only see a smaller number.

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementAvailabilityModel.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/MovementCommitmentModel.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/InternalMovementPricingService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java

Rev 37695 – test(warehouse): cost layer tests; update movement tests for cost-based allocation ...

amit — Thu, 17 Sep 2026 18:19:29 +0530

amit – 3 file(s) modified
test(warehouse): cost layer tests; update movement tests for cost-based allocation

- InventoryCostLayerTest: local-DB tests for layers vs stock on hand, movement priced at recorded cost, refusal across costs, promised stock held back, pending inbound offered but not dispatchable, and GRN recording vendor and cost
- InternalMovementPricingServiceTest: layers now keyed by cost, so same-cost stock moves together and a different cost needs its own order
- BillingPricingServiceTest: compare against recorded origins rather than the serial-trace source

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

Rev 37694 – feat(warehouse): record where stock came from and what it cost; ...

amit — Thu, 17 Sep 2026 18:19:28 +0530

amit – 11 file(s) modified
feat(warehouse): record where stock came from and what it cost; price internal movements at that cost

- inventoryItem.origin_vendor_id / receipt_unit_cost and lineitem.origin_vendor_id (sql/add_inventory_cost_layer_20260917.sql, applied on prod 2026-09-17 in 75s): GRN copies both from the PO line it arrived on, so origin survives any number of hops and non-serialised stock keeps it too. Unknowable origin stays NULL - never a guess, never an internal supplier
- A movement now moves stock at the cost it was received at, not the origin vendor's current catalog TP. Layers are grouped by cost; a quantity spanning two costs is refused with both numbers, since a PO line carries one price
- Stock already promised on open outbound movement orders is no longer offered again (176 item/warehouse pairs on prod are fully promised today)
- Stock on open inbound POs is offered for planning at that order's price and reported as 'on the way in', but cannot be dispatched until received; the PO item picker lists those items too
- Backfill: 4,010 of 4,646 in-stock rows on prod got origin and cost; 636 stay unknown and are priced from the latest approved external catalog price as before

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/warehouse/WarehouseInventoryItem.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/warehouse/WarehouseLineItem.java
~ /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/warehouse/WarehouseInventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseLineItemRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseLineItemRepositoryImpl.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/PurchaseOrderServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseServiceImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/add_inventory_cost_layer_20260917.sql

Rev 37693 – rbm ranking mailer

ranu — Thu, 17 Sep 2026 18:16:36 +0530

ranu – 1 file(s) modified
rbm ranking mailer

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

Rev 37692 – LMS + Airtel Calling

vikas — Thu, 17 Sep 2026 18:12:13 +0530

vikas – 9 file(s) modified
LMS + Airtel Calling

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/LeadRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/LeadRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/LmsDashboardService.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LmsDashboardController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LmsLeadController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/lms-dashboard.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/include-scripts.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/lead-record.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/lms-dashboard-standalone.vm

Rev 37691 – rbm rankijng mail

ranu — Thu, 17 Sep 2026 18:11:39 +0530

ranu – 1 file(s) modified
rbm rankijng mail

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

Rev 37690 – notification scheduler

ranu — Thu, 17 Sep 2026 18:01:08 +0530

ranu – 1 file(s) modified
notification scheduler

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

Rev 37689 – notification scheduler

ranu — Thu, 17 Sep 2026 18:00:04 +0530

ranu – 1 file(s) modified
notification scheduler

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

Rev 37688 – Record that the counter/privatedealuser rename was applied on hadb1 (suffix ...

amit — Thu, 17 Sep 2026 17:59:10 +0530

amit – 1 file(s) modified
Record that the counter/privatedealuser rename was applied on hadb1 (suffix _dropped_20260917)

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

Rev 37687 – rbm ranking mailer

ranu — Thu, 17 Sep 2026 17:59:01 +0530

ranu – 2 file(s) modified
rbm ranking mailer

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

Rev 37686 – for rbm ranking mail on month end

ranu — Thu, 17 Sep 2026 17:56:53 +0530

ranu – 5 file(s) modified
for rbm ranking mail on month end

~ /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-dao/src/main/java/com/spice/profitmandi/service/monitors
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/monitors/RbmPerformanceRankingService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/monitors/RbmPerformanceRankingServiceImpl.java

Rev 37685 – Remove selenium from the fofo portal entirely No browser ...

amit — Thu, 17 Sep 2026 17:53:41 +0530

amit – 7 file(s) modified
Remove selenium from the fofo portal entirely

No browser starts in this WAR any more, and the selenium-java and
webdrivermanager dependencies are gone with it. Verified: no source reference to
selenium/WebDriver/ChromeDriver anywhere in the module, and zero selenium
artifacts on the runtime classpath.

Three pieces:

1. The insights schedule and its pull move to profitmandi-cron (r37684) and dao
(r37683). This service keeps only the READ paths -- redis, then in-memory,
then cs.agent_daily_insight -- plus refreshInsights(), which now asks the dao
sync service to run once and re-reads what it wrote. The portal therefore
holds no credentials at all: KNOWLARITY_USERNAME/PASSWORD are deleted from
this source, along with INSIGHTS_PAGE_URL and the 200-character CSS selector
the scrape depended on.

2. KnowlarityScraperService deleted. It was dead, not merely idle: zero
references anywhere, both @Scheduled annotations commented out, and its
@PostConstruct selenium block commented out with the note 'DISABLED - Live
status now comes from WebSocket via profitmandi-cron'. SVN backs that up --
r36057/r36058 (25-Mar) moved agent status to the websocket and r36072/r36075
(26-Mar) created KnowlarityBreakLogService in dao, but nobody removed the
corpse. It kept selenium in this WAR for six months after nothing used it.
The data agrees: 'On Break - <reason>' rows in cs.rbm_break_log stop on
25-27 March and plain 'Break' takes over, which is exactly that handover.

⚠ Consequence worth knowing: break-REASON granularity (lunch/meeting/sick)
was lost at that migration and is not coming back from the websocket feed.

3. setTokens() and POST /indent/set_knowlarity_tokens removed -- the method had
already been reduced to a log line, and the pull now authenticates itself per
run. Also retired the orphan knowlarity.scraper.enabled property (nothing read
it; it was still 'true' in prod), and corrected a stale section header and a
doc comment that promised 'current tokens' which no longer exist.

Not touched, deliberately: POST update_agent_status / bulk_update_agent_status /
update_status_by_name still exist and still write cs.rbm_break_log through
AgentLiveStatusService. They are orphaned -- the deleted scraper was their only
feeder and no view or script in the deployed WAR calls them -- but they are
public HTTP surface, so proving there is no INTERNAL caller is not the same as
proving no external one. Left for a separate decision.

~ /trunk/profitmandi-fofo/build.gradle
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/MonitorController.java
x /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/service/KnowlarityApiClient.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/service/KnowlarityInsightsService.java
x /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/service/KnowlarityScraperService.java
~ /trunk/profitmandi-fofo/src/main/resources/META-INF/dev.properties
~ /trunk/profitmandi-fofo/src/main/resources/META-INF/prod.properties

Rev 37684 – Schedule the knowlarity insights pull here instead of in the ...

amit — Thu, 17 Sep 2026 17:53:22 +0530

amit – 2 file(s) modified
Schedule the knowlarity insights pull here instead of in the fofo tomcat

Eight times a day, unchanged times (11:40, 13:40, 15:40, 17:40, 18:40, 19:15,
20:00, 20:40) so the shape of the day's data does not move. Calls
KnowlarityInsightsSyncService (dao r37683).

This lands next to KnowlarityCallMonitorScheduler on purpose: that one owns the
WebSocket status feed into cs.rbm_break_log, this one owns the periodic KPI pull
into cs.agent_daily_insight. They are the two halves of the same integration and
were previously split across two processes for no reason other than history.

What it replaces: the same schedule inside the fofo tomcat, where every run
started an ~850MB headless chrome on a box that holds a -Xmx8g tomcat and a
-Xmx2g cron jar on 16GB and has been kernel-OOM-killed twice. A run is now four
HTTPS calls, ~2-3 seconds.

⚠ Only fires under --spring.profiles.active=scheduled; a one-shot CLI run does
not start the schedulers.

staging.properties gains the knowlarity block. It had NO knowlarity keys at all,
which means the WebSocket call monitor has never run there either -- this fixes
both. Same credentials as prod; there is no separate SR tenant for staging.

Cadence is worth revisiting separately: the 8 slots were chosen when a run cost
75 seconds and 850MB. At 2 seconds, hourly or every 15 minutes during the
10:00-21:00 window (matching the call monitor) would be nearly free.

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/knowlarity/KnowlarityInsightsScheduler.java
~ /trunk/profitmandi-cron/src/main/resources/META-INF/staging.properties

Rev 37683 – Move the knowlarity insights pull into dao, and delete the ...

amit — Thu, 17 Sep 2026 17:53:09 +0530

amit – 6 file(s) modified
Move the knowlarity insights pull into dao, and delete the dead earlier attempt

The pull belongs in dao because its SCHEDULE moves to profitmandi-cron while the
fofo portal still reads the same rows. Both modules depend on dao, so that is the
only place the two can share it.

KnowlarityInsightsSyncService fetches via KnowlarityApiClient (moved here from
fofo, unchanged) and upserts cs.agent_daily_insight. No DDL: every column it
writes already exists.

It writes what the old chrome scrape could not:
- the *_seconds columns. Verified on prod over 7 consecutive days, every row had
logged_in_seconds, break_seconds, available_seconds and talk_seconds = 0. The
API returns fractional seconds as numbers, so they are stored directly rather
than re-parsed out of a display string.
- calls_answered / missed_calls / total_calls, also 0 on every row, because the
scrape never captured them at all.

auth_id resolution keeps the email-PREFIX match from the fofo version: some
stored emails are truncated ('user@smartdukaan.co..'), so matching the whole
address silently misses those agents.

Redis keys are deliberately the same pair the portal reads, so its fast path
stays warm across the process boundary. ⚠ That makes AgentInsightRow's getter
names a contract with fofo's AgentInsightDTO -- rename one without the other and
the portal deserialises blanks.

Also deleted, all with zero external references:
- KnowlarityAgentInsightsService: an earlier, unfinished run at this same API.
Its ALT_INSIGHTS_APIS list of guessed endpoints is the giveaway that it never
worked; nothing ever called it. It owned three redis keys nobody read
(knowlarity:agent:insights, :summary, :lastUpdate) -- distinct from the live
knowlarity:insights:* pair, which stays.
- AgentInsightsDTO / AgentInsightsSummaryDTO: used only by that service.
- KnowlaritySocketTest: a scratch main(), never referenced.

x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/knowlarity/dto/AgentInsightsDTO.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/knowlarity/dto/AgentInsightsSummaryDTO.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/knowlarity/KnowlarityAgentInsightsService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/knowlarity/KnowlarityApiClient.java (copied from /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/service/KnowlarityApiClient.java@37682)
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/knowlarity/KnowlarityInsightsSyncService.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/knowlarity/KnowlaritySocketTest.java

Rev 37682 – feat(warehouse): auto-approve backdated POs in the creator's name A ...

amit — Thu, 17 Sep 2026 16:40:41 +0530

amit – 1 file(s) modified
feat(warehouse): auto-approve backdated POs in the creator's name

A backdated PO used to be parked in POStatus.INIT until an HOD clicked a mailed approval link. INIT
keeps a PO out of the PO list, out of GRN/invoice matching and out of the auto-close sweep, so an
unclicked PO was frozen rather than merely pending - 440 had accumulated since 2024, of 2547 approval
rows only 2023 were ever clicked.

- every PO now goes READY at creation, backdated or not
- the warehouse.poapproval row is still written, stamped approvedOn=now and approvedBy=<creator> by
recordAutoApproval(), since that row is what identifies a PO as backdated and who backdated it
- the HOD mail survives as a notification: names the creator, no approval link, PDF still attached
- /approve-po-date/* endpoints kept so links already sent do not 404

Completes r37679-81. Backfill for the three POs still inside POScheduler's window is staged at
profitmandi-dao/src/main/resources/sql/backdated_po_auto_approval_backfill_20260917.sql, not run.

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

Rev 37681 – feat(warehouse): resolve the logged-in user on V2 PO creation and ...

amit — Thu, 17 Sep 2026 16:29:18 +0530

amit – 2 file(s) modified
feat(warehouse): resolve the logged-in user on V2 PO creation and GRN mismatch resolution

V2 mirror of r37680, keeping the dormant V2 controllers in step with the fofo MVC ones.

- createPurchaseOrder resolves the logged-in user via getEmailId + authRepository and sets createdBy
- resolvedMismatchRequest passes the resolver through

Pairs with r37679.

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

Rev 37680 – feat(warehouse): resolve the logged-in user on PO creation and GRN ...

amit — Thu, 17 Sep 2026 16:29:12 +0530

amit – 3 file(s) modified
feat(warehouse): resolve the logged-in user on PO creation and GRN mismatch resolution

Backdated POs are auto-approved in their creator's name, so the user has to travel with the request.

- createPurchaseOrder resolves the logged-in user via cookiesProcessor + authRepository and sets createdBy
- resolvedMismatchRequest passes the resolver through, for the correction PO it can raise
- PO create page no longer says backdated POs need HOD approval

Pairs with r37679.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/warehouse/GrnController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/warehouse/PurchaseOrderController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse-create-purchase-order.vm

Rev 37679 – feat(warehouse): carry the PO creator through purchase order creation for ...

amit — Thu, 17 Sep 2026 16:29:06 +0530

amit – 4 file(s) modified
feat(warehouse): carry the PO creator through purchase order creation for backdated auto-approval

Backdated POs are to be auto-approved in the name of whoever raised them, but the service had no way
to know who that was: the model carried no user and buyerId is the seller, not a person.

- CreateWarehousePurchaseOrderModel carries createdBy
- resolvedMismatchRequest takes resolvedBy, so the correction PO raised on a GRN price mismatch -
dated to the supplier invoice and therefore backdated by nature - is credited to whoever resolved it
- staged backfill SQL for the three backdated POs still stuck in INIT inside POScheduler's
auto-close window; data only, no schema change, not yet run

The release-to-READY change in PurchaseOrderServiceImpl follows separately.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/CreateWarehousePurchaseOrderModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/GrnRequestService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/GrnRequestServiceImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/backdated_po_auto_approval_backfill_20260917.sql

Rev 37678 – Replace the knowlarity insights chrome scrape with SR's own JSON ...

amit — Thu, 17 Sep 2026 15:55:49 +0530

amit – 2 file(s) modified
Replace the knowlarity insights chrome scrape with SR's own JSON API

Drops the last unattended headless chrome out of the fofo tomcat. The scheduled
insights job ran 8 times a day and each run started an ~850MB chrome tree inside
the tomcat JVM's host -- a box holding -Xmx8g tomcat plus a -Xmx2g cron jar on
16GB that has been kernel-OOM-killed twice with tomcat the victim.

It was also losing data the whole time. Verified on prod across 7 consecutive
days: every row of cs.agent_daily_insight has logged_in_seconds, break_seconds,
available_seconds, talk_seconds, calls_answered, missed_calls and total_calls
set to 0. Two separate causes, both fixed here:

- parseTimeToSeconds split on ':' expecting 'HH:mm:ss', but the table renders
'2h 50m 39s'. A one-element split fell through to return 0, and because it
never reached the NumberFormatException branch it did not even warn. It now
parses the h/m/s shape and still accepts HH:mm:ss and HH:mm.
- the scrape never captured the call counts at all. The API carries them.

The auth chain is four calls and is not guessable, so it is documented in
KnowlarityApiClient: POST /vr/sr_login/ establishes the session and returns an
HS256 token that the API REJECTS; GET /newsr/user_details yields new_sr_ui_url
carrying a one-shot SSO blob (in a browser this hop is javascript, so it is
invisible to anything that merely follows redirects); POST /vr/sso_login/
exchanges that blob for the RS256 token the API accepts, whose claims embed the
srsessionid and so bind it to the session; GET /newsr/agents_insights/ with
header jwtAuthorization. Wrong token and wrong header name both answer
'Invalid token', so the error never tells you which mistake you made. The window
parameters are start_time/end_time -- start_date/end_date authenticates fine and
returns 'Error in API'.

Redirects are followed BY HAND. setInstanceFollowRedirects(true) exposes only
the final response's headers, so the Set-Cookie issued on the intermediate hops
is lost, the session never forms and user_details answers with an HTML error
page. This cost a debugging cycle; the reason is commented at the call site.

Verified against the live account before committing: 13 agents returned,
calls_offered == calls_answered + missed_calls holds for all 13, durations match
the previous scrape to within the elapsed window (~55s), and formatSeconds /
parseTimeToSeconds round-trip cleanly over the real values.

DTO fields stay the same display strings ('2h 50m 39s'), so every existing
reader is unaffected; only the previously-zero numeric columns change.

KnowlarityScraperService still uses ChromeDriver for operator-triggered break-log
scrapes, so the selenium dependency stays for now. Its @Scheduled annotations are
already commented out, so nothing unattended starts a browser any more.

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

Rev 37677 – price drop and hike fixed

ranu — Thu, 17 Sep 2026 15:26:23 +0530

ranu – 1 file(s) modified
price drop and hike fixed

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

Rev 37676 – v2 version some fixes

ranu — Thu, 17 Sep 2026 15:19:50 +0530

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

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

Rev 37675 – Remove the dead Samsung and Amazon Selenium paths Both ...

amit — Thu, 17 Sep 2026 14:52:14 +0530

amit – 5 file(s) modified
Remove the dead Samsung and Amazon Selenium paths

Both were manual one-shots that nothing runs any more, and each started an
850MB chrome tree that now has to queue on the browser lane, so they are cost
without a caller.

Evidence they are dead rather than merely idle:
- No crontab entry, no cron.d file and no script references --samsung or
--amazonPurchase, and neither flag appears even once in cron.log.
- fofo.activated_imei has ZERO Samsung rows written by the cron (auth_id 0) in
the last 90 days. All 2,331 Samsung rows in that window are auth_id 307, i.e.
the human CSV upload, most recently 16-Sep. The scraper is not what keeps
Samsung current; people are.
- ScheduledSkeleton.fetchImeiActivation() had already been retired in place --
its @Scheduled was commented out with 'No longer scheduled'.
- RunOnceTasks.amazonPurchase() reads /Users/amit/Downloads/amazon.xlsx, a
laptop path that cannot exist on the server.

Removed: SamsungIMEIActivationService, the whole scheduled/amazon package
(AmazonPurchaseService, OrderSummary, OrderRow, AmazonUser), their RunOnceTasks
callers and helpers (fetchImeiActivation, amazonPurchase, getOrderSummary,
parseRow), the two Application CLI blocks and the retired ScheduledSkeleton
wrapper. The amazon package had no importers outside RunOnceTasks.

Both also leaked a chrome profile dir on every run -- AmazonPurchaseService
never called quit() at all, and SamsungIMEIActivationService called it outside
any finally -- so this removes two leak sources rather than fixing them.

Untouched: RunOnceTasks.mailDashboardScreenshots() is a third dead Selenium
one-shot (also zero invocations) but it mails a report, so it is left for a
separate decision.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/RunOnceTasks.java
x /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/amazon
x /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/SamsungIMEIActivationService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java

Rev 37674 – Hold the browser lane around the knowlarity scrapes These ...

amit — Thu, 17 Sep 2026 13:13:15 +0530

amit – 2 file(s) modified
Hold the browser lane around the knowlarity scrapes

These run Chrome inside the tomcat JVM, on the same box as the cron jar's
oppo/realme imei lane, with nothing coordinating the two. isScraping only guards
this JVM and cannot see the cron's driver, so the interlock has to be the
OS-level one -- BrowserLane, common r37672.

Fifteen minutes rather than the cron side's five: the insights scrape runs only
8 times a day against a lane that is busy ~96% of the time, so a short timeout
here would mean the insights never refreshed. On contention it serves cache.

The break-log scraper takes the lane around its freshDriver, which has a clean
try/finally bracket. setupDriver()'s long-lived field driver is deliberately left
alone -- its lifetime spans init to @PreDestroy and holding an OS lock that long
would starve the imei lane.

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

Rev 37673 – Hold the browser lane around the oppo/realme/motorola drivers Takes ...

amit — Thu, 17 Sep 2026 13:13:07 +0530

amit – 3 file(s) modified
Hold the browser lane around the oppo/realme/motorola drivers

Takes BrowserLane (common r37672) before new ChromeDriver and releases it after
quit() returns -- the 850MB is resident for the whole chunk, not just at
startup, so bracketing only the constructor would protect nothing.

Five minutes of waiting, then give up and return what we have: the only things
that can hold the lane that long are the other brand mid-chunk or the knowlarity
scrape in the fofo tomcat, and giving up costs nothing because an unstamped imei
stays pending and the lane's next turn picks it up.

CheckMotorolaWarrantyTask carries a comment saying 'do not let this job overlap
the oppo/realme window' that nothing ever enforced. It is wired here too so it is
already safe whenever it gets a trigger -- it still has none today.

Note on sizing, since the obvious knob is the wrong one: shrinking CHUNK from 25
was evaluated and rejected. The idle window is a fixed 20s bolted onto a variable
work period, so 25->10 moves the duty cycle only 96% -> 91% while costing 8.4%
of daily throughput and 2.5x the driver launches. The lever for duty cycle is the
fixedDelay gap, not the chunk size.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CheckMotorolaWarrantyTask.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CheckOppoWarrantyTask.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/CheckRealmeWarrantyTask.java

Rev 37672 – Add BrowserLane: machine-wide interlock so only one headless Chrome runs ...

amit — Thu, 17 Sep 2026 13:12:56 +0530

amit – 1 file(s) modified
Add BrowserLane: machine-wide interlock so only one headless Chrome runs at a time

Every ChromeDriver tree on the app box costs ~850MB RSS, on a host holding a
-Xmx8g tomcat and a -Xmx2g cron jar on 16GB that has been kernel-OOM-killed
twice with tomcat the victim. Peak concurrent drivers is the number that
matters, not drivers per day.

Measured on the oppo/realme lane: a 25-imei chunk takes 505s (12s driver
startup, then ~19.7s an imei) against a fixed 20s fixedDelay, i.e. a 96% duty
cycle. Meanwhile tomcat starts its own driver 8 times a day for the knowlarity
scrape. On 17-Sep that scrape ran 11:40:00-11:41:07 and the lane's next driver
came up at 11:42:21 -- it cleared by 74 seconds, by luck. At a 96% duty cycle
the collision cannot be dodged by choosing better times, only by serialising.

The two JVMs are separate processes owned by different users, so an in-process
flag cannot see across the boundary. Uses an OS file lock at
/var/lock/sd-browser.lock (overridable via -Dsd.browser.lock), created 0666 on
first use because cron runs as root and tomcat as tomcat and whichever starts
first creates it. A file lock rather than a marker file so the kernel reclaims
it when the holder dies: verified by SIGKILLing the holder mid-hold, the next
JVM acquired in 264ms. A ReentrantLock gates it first, since a second thread in
the same JVM would otherwise get OverlappingFileLockException rather than block.

Callers wait rather than skip. The knowlarity scrape needs 67s against a lane
busy 96% of the time, so skip-on-contention would mean it essentially never
refreshed again. Eight scrapes a day costs the imei lane about nine minutes of
waiting in total.

Fails open if the lock file is unusable (missing /var/lock, read-only mount, dev
laptop): serialising within the JVM only, rather than stopping imei activation
over what is a safety interlock.

+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/util/BrowserLane.java

Rev 37671 – loi revival process modify

ranu — Thu, 17 Sep 2026 11:33:22 +0530

ranu – 2 file(s) modified
loi revival process modify

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/user/StoreTimelineTatServiceImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LoiFormController.java

Rev 37670 – Check GSTIN shape on the onboarding screen before submit (jsVersion ...

amit — Wed, 16 Sep 2026 20:29:46 +0530

amit – 2 file(s) modified
Check GSTIN shape on the onboarding screen before submit (jsVersion 425)

Both GST boxes are validated client-side and must match, so ops see the problem on the screen
instead of discovering it when NIC refuses the first invoice. Server-side guard in dao r37669
is what actually enforces it.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/update-retailer-details.js

Rev 37669 – Reject an invalid or mismatched partner GSTIN before it is ...

amit — Wed, 16 Sep 2026 20:29:41 +0530

amit – 1 file(s) modified
Reject an invalid or mismatched partner GSTIN before it is saved

The onboarding screen carries the GSTIN in two boxes both labelled GST NUMBER - the retailer
one (dtr.retailer.number) and the store one (fofo_store.gst_number, which billing reads).
Neither was validated, so DLSH1660 was saved with the LOI's pincode in the store box while the
retailer box held the real GSTIN, and its first invoice would have been refused by NIC.

validateGstNumbers runs before any write (covers the fofo portal, the V2 API and the partner
app, which all funnel through updateRetailerDetails): both values are normalised, both must be
valid GSTINs, and when both are present they must agree - across 1,800 partners on record they
already do, bar the one that caused this. Needs common r37668.

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