SmartDukaan – /

Rev 37733 – Remove dead third-party integrations: web - PayU: /payu-pay and ...

amit — Mon, 21 Sep 2026 12:33:44 +0530

amit – 33 file(s) modified
Remove dead third-party integrations: web

- PayU: /payu-pay and the payu-pay-response/cancelled handlers (bodies were
already commented out), PayuHandler, payment/ helpers, PayU POJOs, and the
PAYU PAY option served by checkout/payment-options.
PayuPayController stays: it holds the live CCAvenue, Razorpay and Pine Labs
callbacks.
- SmartPing: GET /click2call/{toMobile} (v1 + v2) and the caller-ID hook
/smartping/receipt + /v2/hookCallerID, which only logged
- HyperTrack: device location, partner location and geofence endpoints plus
HyperTrackService. The attendance endpoints (/getPunchHistory,
/employee/attendance) never called HyperTrack and are kept, moved to
EmployeeAttendanceController / V2EmployeeAttendanceController.
- Affiliate click-outs and live pricing (Amazon/Flipkart/Snapdeal via OMG):
ClicksController, LivePricingController and v2 wrappers. Live pricing was
already returning an empty list.
- Thriwe controller (fully commented out), SpiceMoney and FundFina v2 controllers
- Aramex branch of /track; tofee.* keys in dev/prod properties

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/WebMVCConfig.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/OrderController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/PayuHandler.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/PayuPayController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/PayuPayResponseController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/SmartPingReceiptModel.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ClicksController.java
+ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/EmployeeAttendanceController.java (copied from /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/HyperTrackController.java@37732)
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/HyperTrackController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/HyperTrackService.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LivePricingController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LogisticsTrackingController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ThriweController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/TicketChatActivityController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/payment
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/req/PayuPayResponsePojo.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/res/AddClickReponse.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/res/LivePricingResponse.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/res/order/PayuPayPojo.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/res/order/PayuResponseParams.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoFundFinaController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoSpiceMoneyController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoWebHookController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2ClicksController.java
+ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2EmployeeAttendanceController.java (copied from /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2HyperTrackController.java@37732)
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2HyperTrackController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2LivePricingController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2PayuPayController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2PayuPayResponseController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/V2TicketChatActivityController.java
~ /trunk/profitmandi-web/src/main/resources/META-INF/dev.properties
~ /trunk/profitmandi-web/src/main/resources/META-INF/payment-options.json
~ /trunk/profitmandi-web/src/main/resources/META-INF/prod.properties

Rev 37732 – purchase return: look up the open return against a document ...

amit — Mon, 21 Sep 2026 12:33:17 +0530

amit – 2 file(s) modified
purchase return: look up the open return against a document

selectOpenByDocumentReference returns the return still outstanding against a
document reference - neither refunded nor rejected - or null when none is.

Backs a duplicate guard on the invoice-return submit path: the same invoice was
being submitted twice, the closest pair eight seconds apart, and finance was
rejecting the extras by hand. A settled return deliberately does not count, since
rejecting a return is precisely what frees the invoice to be raised again.

Repository lands first so the method exists before the caller uses it.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/PurchaseReturnOrderRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/PurchaseReturnOrderRepositoryImpl.java

Rev 37731 – Remove dead third-party integrations: dao Nothing removed here had ...

amit — Mon, 21 Sep 2026 12:33:07 +0530

amit – 39 file(s) modified
Remove dead third-party integrations: dao

Nothing removed here had a live caller. No tables are touched.

- Toffee Insurance client + models, and the tofee.* keys in shared-*.properties
- Bharti Assist (BAG) service and its certificate/brand models. BagPlanModel
and PlanVariant stay in bharti/model: OneAssist and ICICI Lombard use them.
- Private, uncalled Toffee/BAG request builders in InsuranceServiceImpl
- Wiseapp insurance client and ZestResponseModel
- SmartPing client. CallDetailModel and PushCallLogModel move to
kommuno/model because the Knowlarity webhooks still parse them.
- SpiceMoney SSO (2-partner pilot), Thriwe stub + DTOs, DTDC/Shipsy (demo
URLs only), Blue Dart SOAP stubs, legacy Pine Labs v1 client
- FundFina pre-approval entity/repository, HyperTrack key entity/repository,
affiliate Click entity/repository
- Speqtra SMS constant; aramex.tracking.url keys
- PAYU PAY entry in payment-options.json

Gateway.MANDII and Gateway.FUNDFINA stay: historical fofo.payment rows.

x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/Click.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/FundFinaPreApproval.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/HypertrackKey.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/HyperTrackKeyModel.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/thriwe
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/cs/CsServiceImpl.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/ClickRepository.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/ClickRepositoryImpl.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/FundFinaPreApprovalRepository.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/FundFinaPreApprovalRepositoryImpl.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/user/HypertrackKeyRepository.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/user/HypertrackKeyRepositoryImpl.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/dtdc
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/OtpProcessor.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/thriwe
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/bharti/BAGService.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/bharti/model/BAGInsuranceModel.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/bharti/model/BrandModel.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/bharti/model/CreateCertificateRequestModel.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/bharti/model/CreateCertificateResponseModel.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/bharti/model/Sample.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/bluedart
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/kommuno/model
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/kommuno/model/CallDetailModel.java (copied from /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/smartping/model/CallDetailModel.java@37730)
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/kommuno/model/PushCallLogModel.java (copied from /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/smartping/model/PushCallLogModel.java@37730)
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/kommuno/RecordingService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/pinelabs/PinelabsOrderService.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/PineLabsPaymentService.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/smartping
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/spicemoney
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/toffee
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/zest/InsuranceServiceImpl.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/zest/WiseappInsuranceServiceImpl.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/zest/WiseappWebService.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/zest/ZestResponseModel.java
~ /trunk/profitmandi-dao/src/main/resources/META-INF/payment-options.json
~ /trunk/profitmandi-dao/src/main/resources/shared-dev.properties
~ /trunk/profitmandi-dao/src/main/resources/shared-prod.properties
~ /trunk/profitmandi-dao/src/main/resources/shared-staging.properties

Rev 37730 – Remove dead third-party integrations: common Part of the integrations ...

amit — Mon, 21 Sep 2026 12:32:52 +0530

amit – 6 file(s) modified
Remove dead third-party integrations: common

Part of the integrations cleanup across all modules. Nothing here had a
live caller.

- Snapdeal product-page parser and UserMessagePojo (affiliate live pricing)
- FundFina request/response DTOs (inbound lender API, removed)
- Aramex XML tracking client (only reachable via /track provider=2)
- WiseApp insurance model
- URL constants for PayU, the SmartPing caller-ID hook, affiliate clicks and
live pricing; the SmartPing agent map

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/ProfitMandiConstants.java
x /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/UserMessagePojo.java
x /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/WiseAppInsuaranceModel.java
x /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/services/AramexTrackingService.java
x /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/services/fundfina
x /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/services/SnapdealProductPageParser.java

Rev 37729 – lead: one workable lead per mobile, with a 6-month supersede ...

amit — Mon, 21 Sep 2026 12:31:43 +0530

amit – 13 file(s) modified
lead: one workable lead per mobile, with a 6-month supersede and an L2+ override

There was no choke point for lead creation. Ten sites did `new Lead()` across four
modules -- three in web's LeadController, two in V2FofoLeadController, three in fofo's
LeadController, one in TrialServiceImpl and one in the cron LeadSyncRunner -- and only
ONE of them (fofo /createLead) checked for an existing lead at all. Result on live data:
5,137 mobiles carrying duplicate leads over 12,156 rows, worst case 29 on one number,
and two agents unknowingly working the same shop.

THE RULE, in new LeadCreationService, which all ten now route through:

no active lead on the number -> create
active, last activity >= 6 months -> retire the old one, create the new one, SILENTLY
active, last activity < 6 months -> BLOCK; only an L2+ user may override

Active = status in (pending, followUp) AND the assignee is still an active auth_user.
Last activity = GREATEST(lead.updated/created, MAX(lead_activity.created)).

The stale branch is deliberately quiet. A shop enquiring again after six months is a
handover, not a clash, and mailing on it would train the desk to ignore the alert -- so
only a genuine collision notifies. Live split: 195 stale against 1,241 fresh, and roughly
three blocks a month.

WHY "ACTIVE" ALSO MEANS A LIVE OWNER

331 open leads are assigned to 11 DEACTIVATED accounts (157 to sm@smartdukaan.com alone,
whose newest lead is from 2022). Counting them as active would block fresh enquiries
behind an account nobody can log in to and therefore nobody can close. Requiring a live
owner defuses all 331 without retiring a single row. Retirement here is only ever
REACTIVE -- triggered by a new entry on the same number. Nothing runs on a schedule.

ASSUMPTION worth flagging: a superseded lead becomes status=notInterested (stage DROPPED)
with closure_timestamp and reason 'Superseded after 6 months inactivity', rather than a
new `expired` status. "Closed" is an explicit allow-list in the UI --
Arrays.asList(notInterested, finalized) at V2FofoLeadController:150 and fofo
LeadController:313 -- and there are ~107 references to specific LeadStatus values, so a
new enum value would make these leads vanish from BOTH the open and closed screens.
Stage DROPPED keeps the nuance (the shop never said no) and still maps to notInterested
via LeadStage.toLegacyStatus().

OVERRIDE is L2+ in ANY team, not Call Center only: Sales L1 owns 1,063 of the 1,776 open
leads, so a Call-Center-only gate would funnel every team's collisions through three
people. The MAIL still goes to Call Center L2+, resolved from cs.position at send time
rather than hardcoded. An override is a TAKEOVER -- it closes the existing lead -- because
a second live lead is the exact thing the rule exists to prevent.

UNATTENDED CALLERS (cron sync, CSV upload, trial registration, AI intake) have nobody to
offer an override to, so they use createUnattended: skip the colliding row and mail the
desk rather than throwing. CSV reports imported/duplicateSkipped/duplicateMobiles back to
the operator instead of failing the whole file over one number.

ALSO FIXES selectByMobileNumber, which called getSingleResult and therefore threw
NonUniqueResultException on any mobile with more than one lead -- GlitchTip #99 and #1359,
both still firing. It now prefers the open lead, then the most recently touched.

NOT INCLUDED, deliberately: no DB unique constraint. 10 mobiles already carry more than
one open lead and would have to be resolved by hand first, which conflicts with the
no-auto-retirement rule. The service enforces the invariant going forward.

NEEDS A DBA STEP: user.lead.mobile is unindexed on 37,580 rows, so this check is a full
scan on every create. Index DDL is in the accompanying note; it has NOT been applied.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/leadsync/LeadSyncRunner.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/CreateRefferalRequest.java
~ /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/dao/service/lead
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/lead/LeadCreationService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/lead/LeadCreationServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/lead/LeadDuplicateDecision.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/lead/LeadDuplicateNotifier.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/TrialServiceImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LeadController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/LeadController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoLeadController.java

Rev 37728 – logging: stop three non-defects reporting to the error board as ...

amit — Mon, 21 Sep 2026 12:18:41 +0530

amit – 10 file(s) modified
logging: stop three non-defects reporting to the error board as ERROR

log4j2.xml ships ERROR and above to GlitchTip, so the log level IS the filter.
Three sources of ordinary, expected behaviour were logging at ERROR and between
them accounted for 51,244 events -- 43% of the whole board -- none of them a bug.
GlobalExceptionHandler already logs ProfitMandiBusinessException at WARN and is
unchanged; every leak below bypassed it.

1. Session state (27,302 events, 23% of the board). CookiesProcessor and the two
interceptors logged a missing or expired cookie at ERROR. A logged-out or
anonymous visitor is the normal case -- the code already handles it by
redirecting to /login or returning 403 -- and each of these sits in a class
whose surrounding lines already log at DEBUG. These never reach the handler,
which is why its WARN-level treatment never applied. Now DEBUG.

2. Client disconnect (19,349 events). There was no handler for it, so a client
hanging up mid-response fell through to @ExceptionHandler(Exception.class) and
was recorded as an unhandled server bug. Adds an IOException handler to both
GlobalExceptionHandlers that logs a disconnect at DEBUG and everything else at
ERROR with its 500 intact.

⚠ ClientAbortException CANNOT be imported here: catalina is provided by the
container and is not on either module's compileClasspath (verified against
the configuration, not assumed). The match is therefore on the simple class
name plus the "broken pipe"/"connection reset" messages, walked down the cause
chain. A genuine IOException matches none of those and keeps its ERROR.

The handler returns null for a disconnect rather than a body: the connection
that would carry it is already closed, and writing to it is what raised the
exception. Null is the supported way to say "handled, no body" --
HttpEntityMethodProcessor marks the request handled before reading the value.

3. Business exceptions re-logged at ERROR (11 sites). Each catches a
ProfitMandiBusinessException, logs it, and CONTINUES with a fallback -- a
missing wallet history defaults to an empty list, a user not found by primary
email is retried against the secondary. That is an expected outcome being
reported as a failure, and logging it at ERROR pre-empted the handler that
would have logged it at WARN. Now WARN.

Selenium/WebDriver (58,776 events) is deliberately untouched: that is a genuinely
broken ChromeDriver, and muting it would hide Oppo/Realme IMEI activation failing.
It looks like noise only because one broken thing repeated 52,000 times.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/GlobalExceptionHandler.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/LoginController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/WalletController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/interceptor/AuthenticationInterceptor.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/interceptor/RoleInterceptor.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/util/CookiesProcessor.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/AddressController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/BrandController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/GlobalExceptionHandler.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoWalletController.java

Rev 37727 – Fixed mail sender everywhere

amit — Mon, 21 Sep 2026 12:14:21 +0530

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

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/transaction/Order.java

Rev 37726 – sentry: stop developer laptops reporting to the live GlitchTip board ...

amit — Sat, 19 Sep 2026 16:08:32 +0530

amit – 6 file(s) modified
sentry: stop developer laptops reporting to the live GlitchTip board

GlitchTip #586 was 57 events tagged environment=production whose stack read
/opt/homebrew/Cellar/tomcat@8/8.5.100/libexec/... with server_name set to a
developer's machine. Nothing was wrong on prod: a laptop was posting into the
production project and was indistinguishable from it.

Two things combined to allow that. The DSN lives in log4j2.xml, which ships inside
every build, so any machine running this code can report. And the Sentry SDK
defaults `environment` to "production" when it is not set -- which it never was --
so local runs arrived pre-labelled as prod.

Adds sentry.properties to each module, read off the classpath by the SDK itself
(io.sentry.config.PropertiesProviderFactory) and merged over the appender's config.
Both keys used here are honoured by io.sentry.ExternalOptions in 7.22.6 (verified
against the jar): `enabled` and `environment`.

The COMMITTED values are the safe ones -- enabled=false, environment=dev -- so a
plain local build is silent. build.gradle rewrites both from -Penv= alongside the
env.property it already writes, so only a deliberate -Penv=staging|prod build
reports, and it carries the right environment tag. tasks.build.doLast restores the
safe default afterwards, mirroring the existing handling of env.property.

Verified both directions: default build leaves enabled=false/environment=dev,
-Penv=prod yields enabled=true/environment=prod.

Note this makes the board trustworthy rather than merely quieter: events can now be
filtered on environment, and anything unlabelled is a build that predates this.

~ /trunk/profitmandi-cron/build.gradle
+ /trunk/profitmandi-cron/src/main/resources/sentry.properties
~ /trunk/profitmandi-fofo/build.gradle
+ /trunk/profitmandi-fofo/src/main/resources/sentry.properties
~ /trunk/profitmandi-web/build.gradle
+ /trunk/profitmandi-web/src/main/resources/sentry.properties

Rev 37725 – Fixed mail sender everywhere

amit — Fri, 18 Sep 2026 19:33:24 +0530

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

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

Rev 37724 – chore(hot-deals): restore 5 catalogs to OEM brand, add POCO M7 ...

amit — Fri, 18 Sep 2026 18:15:09 +0530

amit – 1 file(s) modified
chore(hot-deals): restore 5 catalogs to OEM brand, add POCO M7 Plus 5G (4GB 128GB)_s to Hot Deal

Applied on hadb1 2026-09-18. Removed 1025252/1025253 (Samsung A06) and
1026085/1026403/1026408 (Refurbished iPhones) via _hot_deal_brand_freeze;
added catalog 1026568 (item 40832) with freeze + scope rows.

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

Rev 37723 – Bulk-uploaded movement rows are validated on screen; popup shows arriving ...

amit — Fri, 18 Sep 2026 17:14:53 +0530

amit – 4 file(s) modified
Bulk-uploaded movement rows are validated on screen; popup shows arriving stock per PO

Bulk upload only fills the PO screen - the PO is created from the screen. It used to price
with resolvePrices(qty), so one row over what could move rejected the whole file. It now prices
from describeAvailability (same cost layer order creation uses) and never refuses on quantity:
over-cap rows turn red on render, createPO blocks while any row is red and lists them, and
the server checks again on create. An item with no stock and nothing arriving still fails
the upload (nothing to price).

Popup reads in stock + arriving (per PO, <- supplier) - promised (per PO) = can move; the
'Of these, still to arrive' line is gone. Tests for the Oppo A6 UP->Noida case. jsVersion 433.
Needs dao r37722.

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

Rev 37722 – Movement PO availability: list stock arriving into the sending warehouse, ...

amit — Fri, 18 Sep 2026 17:14:46 +0530

amit – 6 file(s) modified
Movement PO availability: list stock arriving into the sending warehouse, per PO

The popup showed in stock, promised and can-move, but not stock on its way in once it was
fully promised - so UP to Noida read 'in stock 0, promised 4, can move 0' with the 4 units
arriving on PO 54031 nowhere, and looked wrong. It now reads as a sum:
in stock + arriving - promised = can move.

- selectOpenInboundPurchases: open POs into the warehouse, one row per PO, same filter as the
pending-stock layer so the rows add up to the arriving total
- InternalMovementAvailabilityModel: arrivingTotal (before holds) + arriving breakup;
inbound (after holds) unchanged, still used by the refusal message
- describeAvailability (single + batch) carries both; batch doc: quantities are no longer
checked at bulk upload, the screen flags them and order creation enforces them

~ /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 37721 – fix(orders): price each order by the cart line that asked ...

amit — Fri, 18 Sep 2026 16:39:30 +0530

amit – 3 file(s) modified
fix(orders): price each order by the cart line that asked for it, not the first line of its model

Orders were priced from one cart line per catalog, so colours of one model at different
prices all took an arbitrary one. Internal movements (cost layers) failed with WLT_1000
when the dearer line won and were silently under-billed when the cheaper one did.
fulfillQty now prices from the item's own line, newColorQty from the model's any-colour
line; same-price output is unchanged. Refuse the transaction if orders do not total the cart.

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/OrderLineAllocator.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/TransactionServiceImpl.java
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/transaction/OrderLineAllocatorTest.java

Rev 37720 – today po rbm view showing only for l7 and above

ranu — Fri, 18 Sep 2026 15:58:28 +0530

ranu – 1 file(s) modified
today po rbm view showing only for l7 and above

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

Rev 37719 – feat(po): show only allocated warehouse as 'To Warehouse' on open ...

amit — Fri, 18 Sep 2026 15:37:40 +0530

amit – 2 file(s) modified
feat(po): show only allocated warehouse as 'To Warehouse' on open PO list, drop generic buyer label

~ /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-open-purchase-order.vm

Rev 37718 – feat(po): show allocated warehouse name and id under buyer on ...

amit — Fri, 18 Sep 2026 15:26:40 +0530

amit – 2 file(s) modified
feat(po): show allocated warehouse name and id under buyer on open PO list

Rev 37717 – today po rbm view showing only for l7 and above

ranu — Fri, 18 Sep 2026 14:46:30 +0530

ranu – 1 file(s) modified
today po rbm view showing only for l7 and above

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

Rev 37716 – today po rbm view showing only for l7 and above

ranu — Fri, 18 Sep 2026 13:27:06 +0530

ranu – 1 file(s) modified
today po rbm view showing only for l7 and above

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

Rev 37715 – SD credit: stop read paths writing utilized_limit - the SD ...

amit — Fri, 18 Sep 2026 05:07:16 +0530

amit – 5 file(s) modified
SD credit: stop read paths writing utilized_limit - the SD Credit admin page and V2 getLoans mutated managed SDCreditRequirement entities to show recomputed utilization, so Hibernate dirty-checking flushed an UPDATE per partner at commit; fofo now feeds the view from display maps and getLoans detaches before the display write, leaving output identical

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/SDCreditRequirementRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/SDCreditRequirementRepositoryImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/SDCreditController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/sd-credit-requirement-row.vm
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoSDCreditController.java

Rev 37714 – test(warehouse): receiving on an order raised before lines carried an ...

amit — Fri, 18 Sep 2026 05:05:16 +0530

amit – 1 file(s) modified
test(warehouse): receiving on an order raised before lines carried an origin still records the vendor

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

Rev 37713 – fix(warehouse): record the order's own vendor when a receipt line ...

amit — Fri, 18 Sep 2026 05:05:15 +0530

amit – 2 file(s) modified
fix(warehouse): record the order's own vendor when a receipt line carries no origin

- r37694 took the origin only from lineitem.origin_vendor_id, which exists on orders raised from that revision onward, so goods arriving on older open orders landed with a cost but no vendor - 282 rows on the first day
- A purchase from an outside vendor now falls back to that supplier; internal movements are unchanged and an unknowable origin still stays NULL
- sql/backfill_receipt_origin_20260918.sql repairs the 282 already received (run on prod 2026-09-18; bak warehouse._bak_receipt_origin_20260918); in-stock unknown 895 -> 648

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseServiceImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/backfill_receipt_origin_20260918.sql

Rev 37712 – Fix the fofo test profile, which had been failing every ...

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

amit – 2 file(s) modified
Fix the fofo test profile, which had been failing every context-loading test

The test resources carry their own META-INF/dev.properties and it shadows the main one on the
classpath, so anything missing from it is simply unresolvable when a context is built for a test.
It had drifted 23 keys behind - among them prod - and a single unresolvable placeholder stops the
whole context. Every test that loads one failed on mailOutboxService with 'Could not resolve
placeholder prod', which read like a broken bean and was really a stale file. Missing keys copied
from the dev profile.

InventoryCostLayerTest could then run for the first time since, and two of its cases still
described the old rules. Expected receipts can now be ordered against, so the inbound case asserts
a price rather than a refusal. A line stops reserving stock once its order moves past being
submitted for processing, so the raw unfulfilled quantity is now an upper bound: the held figure is
checked against what the commitments query reports, rather than by restating its SQL in the test.

7 of 7 pass.

~ /trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/InventoryCostLayerTest.java
~ /trunk/profitmandi-fofo/src/test/resources/META-INF/dev.properties

Rev 37711 – Bulk-uploaded PO rows show the same availability breakdown as hand-picked ...

amit — Fri, 18 Sep 2026 04:54:36 +0530

amit – 5 file(s) modified
Bulk-uploaded PO rows show the same availability breakdown as hand-picked ones

A row added by hand showed what the warehouse holds, what older orders have promised and how many
units the order could take; the same row arriving from a bulk upload showed none of it. The file
was the one place the numbers behind a quantity were hidden, which is the case where a mistake is
least visible and hardest to unpick afterwards.

describeAvailability now also answers for a list of items. Both reads it needs already took a
list, so a whole file costs the same two queries a single item does rather than two per row. An
item the warehouse holds nothing of is left out of the result instead of failing the upload - its
quantity is still checked when the order is priced, and the row simply shows no breakdown.

The single-item and batch paths build their answer from one shared method, so the two cannot drift
apart, and the screen reuses the renderer it already had.

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

Rev 37710 – Closing a movement PO now cancels its orders, and refuses ...

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

amit – 1 file(s) modified
Closing a movement PO now cancels its orders, and refuses if any has already shipped

A movement is a purchase order and a transaction raised as one, but closing only ever ended the
PO. Its orders stayed live, still able to dispatch stock against an order nobody was going to
receive - the same split that let PO/07-26/52029 ship and invoice goods its PO could never take.
r37709 closed the PO when the last order was cancelled; this is the other direction.

Before cancelling anything it checks every order on the transaction. If one has moved past being
submitted for processing its stock is billed or already gone, and cancelling would write off a
movement that physically happened - so the close is refused, naming the order and its status,
rather than quietly reversing a real dispatch. Rare, but not impossible.

External vendor POs are untouched: they carry no transaction, so the check returns immediately.

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

Rev 37709 – Cancelling a movement's last order now closes its purchase order ...

amit — Fri, 18 Sep 2026 04:37:25 +0530

amit – 1 file(s) modified
Cancelling a movement's last order now closes its purchase order

An internal movement is raised as a purchase order and a transaction together, but only the
transaction was ever cancelled. The PO stayed open and read as live work until the auto-close
sweep aged it out days later - and that sweep writes CLOSED, which is what a PO that actually
received its stock gets. Eight movements raised between 15 and 17 September sat this way, 59
units and Rs 10.68 lakh, every one cancelled the same day it was raised because the model or
colour was discontinued.

refundOrder now pre-closes the movement PO once every order on its transaction is refunded -
every one, because a transaction can carry several and the movement is only over when the last
goes. PRECLOSED, not CLOSED: nothing was received, and the difference is what keeps it
distinguishable from a real completion in every report that reads the status.

Refunds reaching here are already validated as never billed, so no dispatched stock is involved
and nothing is closed out from under stock in transit. Both lookups it needs already existed.

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

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