SmartDukaan – /

Rev 37382 – Unbreak profitmandi-web: pass the optional fofoId r37377 added r37377 ...

amit — Fri, 21 Aug 2026 18:52:07 +0530

amit – 1 file(s) modified
Unbreak profitmandi-web: pass the optional fofoId r37377 added

r37377 widened PurchaseReturnOrderRepository.selectByWarehouseIdsAndDateRange
with an optional fofoId so the FOFO Sale Returns partner filter could be a
predicate rather than a post-filter. r37378 updated the FOFO caller; this web
caller was missed, so it still passed 4 arguments to a 5-argument method and
profitmandi-web has not compiled since - the web war could not be built at all.

/return/invoice has no partner picker (its only params are fromDate/toDate; the
fofoId param elsewhere in this controller belongs to searchDebitNotes), so null
is the right value: the impl only adds the fofoId predicate when non-null, which
is exactly this endpoint's pre-r37377 behaviour. No listing change.

The other three methods r37377 added - selectPendingByWarehouseIds,
selectUnreceivedSince, selectEarliestCreateTimestamp - have no web callers; the
pending-queue screen is FOFO-only, so nothing else was left half-migrated.

Verified all five modules compile.

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

Rev 37381 – Guard empty item IN () and null billing address on ...

amit — Fri, 21 Aug 2026 18:44:23 +0530

amit – 2 file(s) modified
Guard empty item IN () and null billing address on the app sale-details paths

Mirrors fofo r37380 on the profitmandi-web side, where the same two defects exist.

V2FofoOrderController (live mobile-app API, not the dormant fofo V2):
- sale details built itemIds from fofoOrderItems and passed them straight to
itemRepository.selectByIds. An insurance-only sale has no fofo_order_item row,
so the list is empty and selectAllByInOrderByDesc throws "List should not be
empty". The sibling sale-search method in this same file was already guarded;
the detail method was not.
- customerBillingAddressObj was put into the response unconditionally, so an
order with customerAddressId 0 (no address is required for a plain POS sale)
returned null and the app had no name or phone to show. Fall back to the
customer's own name and mobile, matching the invoice PDF. Applied at both sites.

CustomerController: same empty-IN exposure in the customer order-history batch
fetch, where a customer whose only order is an insurance sale yields no order
items. Adds the java.util.HashMap import this file needed (it imports java.util
members individually).

Verified profitmandi-web compiles clean with these changes. Note trunk currently
does NOT build: V2FofoPurchaseReturnController:635 still calls the 4-arg
selectByWarehouseIdsAndDateRange that r37377 widened to 5 args (r37378 updated
the fofo caller but not this one). That break is untouched here and needs its
own fix before a web war can be built.

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

Rev 37380 – Fix /saleDetails 500 on insurance-only orders and null billing name/phone ...

amit — Fri, 21 Aug 2026 18:44:11 +0530

amit – 1 file(s) modified
Fix /saleDetails 500 on insurance-only orders and null billing name/phone

Two defects on the sale-details screen, both from a legitimately-empty source.

1. /saleDetails 500s on an insurance-only order. A policy is not a catalog item,
so an insurance sale carries no fofo_order_item row; itemIds comes out empty and
itemRepository.selectByIds hits GenericRepositoryImpl.selectAllByInOrderByDesc,
which throws "List should not be empty" to guard against an empty IN (). The
same guard already exists two methods below at the sale-search site, so this
carries it across to the detail site. 346 orders across 95 partners are affected
- every insurance-only order ever written. The screen already loads the policies
and the view renders them, so nothing else was needed to display the sale.

2. Billing name and phone rendered as the literal
.getName(). A plain POS sale does not require an
address (only insurance does), so ~140k orders across 1038 partners carry
customerAddressId 0 and the lookup returns null. The existing guard covered the
address *string* but the object was added to the model unconditionally, and
Velocity prints an unresolvable reference verbatim. Fall back to the customer's
own name and mobile, which the invoice PDF already does via
OrderServiceImpl.createCustomAddressWithoutId - so screen and invoice now agree.
The fallback is transient and never persisted; a missing customer row is
swallowed deliberately, since this feeds a display field and throwing would turn
blank text into a 500.

Applied at both model-writing sites in this controller.

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

Rev 37379 – Restore insurance lines on invoice PDFs dropped by the r37066 ...

amit — Fri, 21 Aug 2026 15:27:23 +0530

amit – 8 file(s) modified
Restore insurance lines on invoice PDFs dropped by the r37066 renderer refactor

The modular doc-generation extraction moved the item table into ItemsTableSection,
which iterates only DocumentData.items() -> model.getOrderItems(). The legacy
renderer also emitted a row per CustomInsurancePolicy (PdfUtils r36674, lines
241-261); that block was lost in the extraction and nothing consumed
getInsurancePolicies() any more.

Effect: an extended-warranty policy is not a catalog item, so it has no
fofo_order_item row. Insurance sold after the device sale gets its own invoice
whose only line is the policy, so the whole table came out empty and the totals
- which SummarySection derives from the table, not from FofoOrder.totalAmount -
printed as 0.00 / 'Zero Rupees Only' (e.g. HRJND1424/94). On a combined
device+insurance invoice the policy line vanished silently and the invoice total
and GST were understated by the premium. InsuranceController's insurer document
pack, whose model carries policies and no order items at all, hit an NPE.

Fold the policies in at DocumentData.items(), the single accessor every section
reads, so the fix covers all callers at once. Column mapping mirrors the legacy
renderer: quantity 1, no discount, taxable value repeated in the Rate column.
Only the applicable tax side is populated (CGST/SGST or IGST) rather than both
as the policy model carries them, matching how real order items are built, so
ItemsTableSection's taxAmount = cgst+sgst+igst stays correct on margin-scheme
invoices. With no policies the model's own list is returned untouched.

Tests: InsuranceInvoiceRenderTest asserts on extracted PDF text (insurance-only,
intra/inter-state GST split, combined invoice, and a no-insurance control), so it
holds on any machine unlike the pixel goldens; three golden baselines added.
Verified all 14 pre-existing golden fixtures render byte-identical before and
after.

Also set java.awt.headless=true on the test JVM: the golden harness rasterizes
through PDFBox, whose font handling calls
GraphicsEnvironment.getLocalGraphicsEnvironment() and made the forked JVM attach
to the macOS window server as a Foreground app, stealing focus on every run.
Test-only property, no effect on the built war.

~ /trunk/profitmandi-common/build.gradle
~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/document/DocumentData.java
~ /trunk/profitmandi-common/src/test/java/com/spice/profitmandi/common/document/golden/GoldenInvoiceV2Test.java
+ /trunk/profitmandi-common/src/test/java/com/spice/profitmandi/common/document/golden/InsuranceInvoiceRenderTest.java
~ /trunk/profitmandi-common/src/test/java/com/spice/profitmandi/common/document/golden/PdfFixtures.java
+ /trunk/profitmandi-common/src/test/resources/golden/v2-insurance-combined-p0.png
+ /trunk/profitmandi-common/src/test/resources/golden/v2-insurance-only-inter-p0.png
+ /trunk/profitmandi-common/src/test/resources/golden/v2-insurance-only-p0.png

Rev 37378 – Put the action-pending returns at the top of Sale Returns, ...

amit — Fri, 21 Aug 2026 14:30:59 +0530

amit – 3 file(s) modified
Put the action-pending returns at the top of Sale Returns, and filter by partner

Sorting the received list pending-first changed nothing on screen, because every return
that still needs an action was missing from it. The list was built from purchase return
orders inside the date window, and a return order only exists once the warehouse has
received the goods - so a debit note awaiting receipt had no row to sort, and a return
sitting unrefunded for weeks fell out of the window entirely.

The screen is now two lists:

- Action Pending, on top, with no date bound. It merges the three shapes a pending return
takes - a debit note never received, a return order received but unrefunded, and one
rejected but not yet acknowledged - into a single row type, oldest first, with the age
in days beside it. Each row carries only the action that actually applies to it
- Settled Returns below, refunded and cancelled only, still bound to From/To. The pending
rows were lifted out of it, so nothing is listed twice

Two things worth recording:

- a debit note has no warehouse of its own. It is placed through the item's invoice and
the order that invoice was raised on, and a note that cannot be placed is dropped rather
than shown to a warehouse it may not belong to
- debit notes raised before the receive/refund flow existed were settled the old way and
cannot be worked from this screen. The cutoff is read from the earliest return order in
the database, so it needs no maintenance, and the page says so in a footnote instead of
quietly hiding them

The partner filter reuses the shared /partners typeahead and passes the id down into both
queries. Only a picked suggestion filters, so a half-typed name cannot blank the page. Its
handlers sit inline in the template, next to the markup they drive, following the pattern
add-wallet-request.vm already uses - which leaves the now-unused #invoice-return-date-apply
handler in return.js dead, to be removed with the return.js work already in flight.

Rendered offline through Velocity with the app's own directive.set.null.allowed to confirm
all four action variants emit the right buttons.

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

Rev 37377 – Queries behind the Sale Returns action-pending queue The Sale ...

amit — Fri, 21 Aug 2026 14:30:40 +0530

amit – 4 file(s) modified
Queries behind the Sale Returns action-pending queue

The Sale Returns screen could only ever list purchase return orders received inside the
chosen date window, which left the returns that actually need someone unreachable: a
return order is written at receive time, so a debit note the warehouse has not received
yet has no return order at all and could not appear however the list was sorted.

- selectPendingByWarehouseIds returns every unsettled return order with no date bound -
received but unrefunded, or rejected but not yet acknowledged by the retailer. A return
nobody acted on only gets older, so bounding it by date is what buried it
- selectUnreceivedSince finds debit notes with no return order against them, which is the
only place a not-yet-received return exists. Cancelled notes are excluded
- selectEarliestCreateTimestamp exposes when the receive/refund flow went live. Notes
raised before the first return order ever recorded were settled through the older
item-level flow and are not a queue anyone can work, so the caller uses this to bound
the lookup off the data rather than off a date pinned in code
- both listing queries now take an optional fofoId, so the partner filter is a predicate
rather than a post-filter - filtering after the 200 row cap would silently drop a
partner's older rows

Counts on live data: 6 unsettled return orders, 24 unreceived debit notes since the flow
started, against 5,618 older notes correctly left out.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/DebitNoteRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/DebitNoteRepositoryImpl.java
~ /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 37376 – total show on warehouse wise stock value on item detail

ranu — Thu, 20 Aug 2026 19:40:42 +0530

ranu – 1 file(s) modified
total show on warehouse wise stock value on item detail

+ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse_wise_stock_rows.vm

Rev 37375 – total show on warehouse wise stock value on item detail

ranu — Thu, 20 Aug 2026 19:36:16 +0530

ranu – 3 file(s) modified
total show on warehouse wise stock value on item detail

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/inventory/SaholicInventoryCIS.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/SaholicInventoryCISRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/SaholicInventoryCISRepositoryImpl.java

Rev 37374 – total show on warehouse wise stock value on item detail

ranu — Thu, 20 Aug 2026 18:51:17 +0530

ranu – 3 file(s) modified
total show on warehouse wise stock value on item detail

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/AdminUser.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/DashboardController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/admin.vm

Rev 37373 – Active Scratch Offers

vikas — Thu, 20 Aug 2026 15:49:15 +0530

vikas – 1 file(s) modified
Active Scratch Offers

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

Rev 37372 – Fixed mail sender everywhere

amit — Thu, 20 Aug 2026 13:21:07 +0530

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

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/common/util/ExcelUtils.java

Rev 37371 – Fixed mail sender everywhere

amit — Thu, 20 Aug 2026 13:00:10 +0530

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

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

Rev 37370 – Fixed mail sender everywhere

amit — Thu, 20 Aug 2026 12:32:51 +0530

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

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

Rev 37369 – Fixed mail sender everywhere

amit — Thu, 20 Aug 2026 11:21:57 +0530

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

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/AppConfig.java

Rev 37368 – Cron: raise SMTP timeouts, rotate app password, add offer-circular ingest ...

amit — Wed, 19 Aug 2026 20:33:28 +0530

amit – 4 file(s) modified
Cron: raise SMTP timeouts, rotate app password, add offer-circular ingest keys

- SMTP 10s -> 30s connect / 120s read-write on both senders; the 10s read timeout was
cutting off larger attachment sends. App password rotated to match the current
Google account credential.
- offer.circular.ingest.enabled / offer.circular.review.url added to dev, staging and
prod. Off by default in all three: enabling it makes the job pick up DRAFT circulars
uploaded from the FOFO portal, parse them and mail the uploader, which should only be
switched on once offer.circular.dir is a real path in that environment. There is no
fallback between profiles, so the key has to exist in each one.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/resources/META-INF/dev.properties
~ /trunk/profitmandi-cron/src/main/resources/META-INF/prod.properties
~ /trunk/profitmandi-cron/src/main/resources/META-INF/staging.properties

Rev 37367 – Mail: raise SMTP timeouts and rotate the sdtech app password ...

amit — Wed, 19 Aug 2026 20:33:21 +0530

amit – 2 file(s) modified
Mail: raise SMTP timeouts and rotate the sdtech app password

The 10s read timeout was cutting off larger attachment sends (policy PDFs, invoice
attachments) and surfacing as a send failure the outbox then retried. Raised to 30s
connect / 120s read-write on both senders. App password rotated to match the current
Google account credential.

Also fills in new.solr.url and store.app.url in staging.properties - staging carries no
fallback to dev/prod, so a missing key stops the context from starting.

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-web/src/main/resources/META-INF/staging.properties

Rev 37366 – Staging config: fill in the keys fofo needs to start ...

amit — Wed, 19 Aug 2026 20:33:13 +0530

amit – 1 file(s) modified
Staging config: fill in the keys fofo needs to start on staging

staging.properties is much thinner than dev/prod and there is no fallback between
profiles - a missing key stops the context from starting. Adds react.app.url (no
dedicated staging build of the react partner app exists, so it points at the prod
host), app.token.url (profitmandi-web is co-deployed on the same Tomcat there) and
media.document.url.

~ /trunk/profitmandi-fofo/src/main/resources/META-INF/staging.properties

Rev 37365 – Debit note receive: surface the partner-declared condition and warn before ...

amit — Wed, 19 Aug 2026 20:33:08 +0530

amit – 3 file(s) modified
Debit note receive: surface the partner-declared condition and warn before rejecting

The receive screen defaulted every row's condition to GOOD regardless of what the
partner declared, so a warehouse user could not see what they were disagreeing with -
and the backend treats any disagreement as a rejection of the whole debit note.

- Show 'Declared By Partner' per row and preselect the condition to match it, so
submitting unchanged is a genuine agreement rather than an accident of the default.
- A changed row now switches the submit button to 'Reject Return', shows what rejection
means (no refund; partner, Logistics, RBM and Sales notified), makes the remark
mandatory and confirms before posting.
- SMTP timeouts raised to 30s connect / 120s read-write; the 10s read timeout was
cutting off larger attachment sends.
- jsVersion 405 -> 406 for the return.js change.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/business/return.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/receive-debit-note.vm

Rev 37364 – Offer circular ingest: report discarded rows instead of counting attempts ...

amit — Wed, 19 Aug 2026 20:32:59 +0530

amit – 1 file(s) modified
Offer circular ingest: report discarded rows instead of counting attempts

Pairs with the repository change that makes insertBenefit/insertTenure/insertBank return
their affected row count. The summary now bumps only when a row actually landed, and
records a drop naming the likely unseeded master (offers.txn_mode / emi_scheme / bank)
when it did not. Without this an ingest over empty masters reported a full, healthy
parse while writing nothing.

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

Rev 37363 – Offer circular ingest: return affected rows so INSERT IGNORE cannot ...

amit — Wed, 19 Aug 2026 20:32:53 +0530

amit – 2 file(s) modified
Offer circular ingest: return affected rows so INSERT IGNORE cannot hide an FK failure

insertBenefit/insertTenure/insertBank use INSERT IGNORE for idempotency, which also
makes MySQL downgrade a foreign key violation to a warning. Production was bootstrapped
without the bank / txn_mode / emi_scheme masters, so all 872 benefit and tenure inserts
were silently discarded: the ingest reported PUBLISHED with 239 offers carrying no
amounts, no tenures and no bank eligibility, and nothing anywhere said so.

The three methods now return the affected row count (1 written, 0 discarded) so the
caller can count what landed rather than what it attempted.

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

Rev 37362 – External feed: keep placeholder 'Any Colour' SKUs out of the ...

amit — Wed, 19 Aug 2026 20:32:47 +0530

amit – 1 file(s) modified
External feed: keep placeholder 'Any Colour' SKUs out of the partner feed

catalog.item rows whose color is a placeholder ("Any Colour", "f_Any Color", ...) are
not real sellable variants and must never reach partners. Excluded from every feed and
count query via a single NO_PLACEHOLDER_SKU predicate so the SKU list and its count
cannot drift apart. The boundary check leaves real colors like "Rainbow" untouched.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/external/ExternalFeedRepositoryImpl.java

Rev 37361 – Mail outbox: one transaction per mail, retry once more, stable ...

amit — Wed, 19 Aug 2026 20:32:41 +0530

amit – 2 file(s) modified
Mail outbox: one transaction per mail, retry once more, stable Message-ID

processPendingMails ran the whole batch in a single REQUIRES_NEW transaction, so a
crash mid-batch rolled back the status of every mail already delivered in that cycle
and the next run re-sent them.

- Split into selectPendingIds (read-only) plus sendOne per mail, each REQUIRES_NEW via
a @Lazy self-reference so the proxy actually applies. Outcome is committed as soon
as it is known; a crash now loses at most the mail in flight.
- MailOutbox.selectPending retries FAILED rows once more (retryCount < 2).
- Stable per-row Message-ID so a retry arrives as the same message and the receiving
server can collapse it instead of showing a duplicate.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/mail/MailOutbox.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/MailOutboxService.java

Rev 37360 – ICICI policy issuance: stop losing policies to a proposal read ...

amit — Wed, 19 Aug 2026 20:30:29 +0530

amit – 2 file(s) modified
ICICI policy issuance: stop losing policies to a proposal read timeout

hitAfinityProposal called ICICI's gadget proposal endpoint on the default 10s socket
timeout. That POST issues the policy, so a read timeout abandons a request ICICI is
still completing. The exception then unwound through generateIciciLombardPolicy into
the controller's @Transactional(rollbackFor = Throwable.class), rolling back the whole
request - including the wallet debit - before the tracker row was ever touched. Result:
policy possibly live at ICICI, no trace on our side, and the 'policy already exists'
retry path dead-ends because its Redis cache is only written on a parsed success.

- Proposal and policy-certificate calls move to a dedicated RestClient built on
HttpClientFactory.insuranceIssuanceRequestConfig() (socket 45s). JWT and quote stay
on the default client - fast, and no remote write.
- Transport failures are classified via HttpTransportFailures and reported as 'outcome
unknown', not as an ICICI rejection.
- IciciPolicyTrackerBookkeeping writes the tracker in REQUIRES_NEW, so both the UNKNOWN
outcome and the issued policy number survive the request rollback. Recovery from an
UNKNOWN row is the existing recoverPolicyNumberByProposalNumber path.

Code only, no DDL: status is varchar(20) and remarks is text on prod already.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/IciciLombardService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/IciciPolicyTrackerBookkeeping.java

Rev 37359 – ICICI proposal read timeout: add insurance-issuance HTTP config + shared ...

amit — Wed, 19 Aug 2026 20:30:18 +0530

amit – 2 file(s) modified
ICICI proposal read timeout: add insurance-issuance HTTP config + shared transport-failure classifier

The default RestClient carries a 10s socket timeout, sized for quick lookups. ICICI's
gadget proposal endpoint underwrites and issues the policy synchronously and needs
longer; abandoning the read discards the only response carrying the policy and
proposal numbers for a policy that is already live at the insurer.

- HttpClientFactory.insuranceIssuanceRequestConfig(): connect 5s, socket 45s. Not
slowRegulatorRequestConfig() - its contract forbids request-thread use with an open
transaction, which is exactly the ICICI call site.
- HttpTransportFailures: cause-chain check separating 'the call never completed' from
'the remote said no'. Needed because RestClient rewraps transport errors as
RuntimeException(GE_1006), so the top-level exception type is uninformative.

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/web/client/HttpClientFactory.java
+ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/web/client/HttpTransportFailures.java

Rev 37358 – total show on warehouse wise stock value on item detail

ranu — Wed, 19 Aug 2026 18:04:00 +0530

ranu – 1 file(s) modified
total show on warehouse wise stock value on item detail

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

Rev 37357 – Add CsService.getAuthUsersByPartnerIdAndCategory for partner+category+escalation lookup sendMailForActionOnDispatch mailed every L1 ...

amit — Wed, 19 Aug 2026 18:01:36 +0530

amit – 2 file(s) modified
Add CsService.getAuthUsersByPartnerIdAndCategory for partner+category+escalation lookup

sendMailForActionOnDispatch mailed every L1 position on the partner, which on live data
means the DESIGN (17), SALES (4) and WAREHOUSE (11) owners as well as the RBM (18). It
also hand-rolled the partner_position -> position -> auth_user walk against repositories.

Add a single reusable resolver on CsService: active auth users holding one position
category against a partner, optionally narrowed to escalation levels. It follows the
house resolver shape - the partner's own regions plus ALL_PARTNERS_REGION, partner_id in
(0, fofoId) - so region-wide mappings are honoured, and it short-circuits on empty id
lists because selectByIds builds an IN () predicate that breaks on an empty list.

The call site in TransactionServiceImpl went in with r37356; without this commit trunk
does not compile.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/cs/CsService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/cs/CsServiceImpl.java

Rev 37356 – Fixed max limit to 15 lac for Credit limit

amit — Wed, 19 Aug 2026 17:59:24 +0530

amit – 1 file(s) modified
Fixed max limit to 15 lac for Credit limit

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

Rev 37355 – AI lead intake (fofo, live): assign new leads to a ...

aman — Wed, 19 Aug 2026 13:23:38 +0530

aman – 1 file(s) modified
AI lead intake (fofo, live): assign new leads to a random active BGC L1 instead of the hardcoded Khushbu/Archana round-robin

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

Rev 37354 – AI lead intake: pool is BGC L1 (category 20), not ...

aman — Wed, 19 Aug 2026 13:22:05 +0530

aman – 1 file(s) modified
AI lead intake: pool is BGC L1 (category 20), not Sales L1 - BGC is the desk that works AI leads

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

Rev 37353 – AI lead intake: assign new leads to a random active ...

aman — Wed, 19 Aug 2026 13:16:59 +0530

aman – 1 file(s) modified
AI lead intake: assign new leads to a random active Sales L1 instead of fixed auth id 53

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

Rev 37352 – Fixed max limit to 15 lac for Credit limit

amit — Wed, 19 Aug 2026 12:30:38 +0530

amit – 1 file(s) modified
Fixed max limit to 15 lac for Credit limit

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

Rev 37351 – code committed for sales l3 added in bi and other ...

ranu — Wed, 19 Aug 2026 11:04:35 +0530

ranu – 5 file(s) modified
code committed for sales l3 added in bi and other model

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasksTest.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/BIRetailerModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/FofoReportingModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/cs/CsServiceImpl.java

Rev 37350 – Fix SD Credit daily statement showing zero interest on overdue ...

amit — Wed, 19 Aug 2026 09:52:34 +0530

amit – 1 file(s) modified
Fix SD Credit daily statement showing zero interest on overdue loans

sdDirectService classified each day's interest by exact-matching the
loan_statement description ('Interest On Loan Per Day' /
'Penalty On Loan Per Day'). Once a loan crossed its due date the cron
switches the label to 'Overdue Interest On Loan Per Day', which matched
neither filter, so the daily statement reported 0.00 interest for every
overdue day even though the charge was booked correctly in
loan_statement and loan.interest_accured.

Classify by tenure window against loan.getPenaltyDate() instead - the
same test addInterest() uses to pick the rate - and net the day's full
interest out of the opening balance so penalty days are consistent too.

Seen on loan 120277 (invoice NSLCK35860): Rs.73-83/day accruing from
08-Aug, displayed as 0.00.

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

Rev 37349 – super retailer club 5 live

ranu — Tue, 18 Aug 2026 18:31:10 +0530

ranu – 1 file(s) modified
super retailer club 5 live

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

Rev 37348 – super retailer club 5 live

ranu — Tue, 18 Aug 2026 18:26:37 +0530

ranu – 3 file(s) modified
super retailer club 5 live

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/OrderRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/OrderRepositoryImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/DashboardController.java

Rev 37347 – Give the ingest runner a transaction; it had none on ...

amit — Tue, 18 Aug 2026 16:58:26 +0530

amit – 2 file(s) modified
Give the ingest runner a transaction; it had none on its background thread

Parsing failed instantly on production with

org.hibernate.HibernateException: Could not obtain transaction-synchronized
Session for current thread
at CircularIngestRepositoryImpl.claimForProcessing
at CircularIngestRunner.processOne

The runner works on a background thread. Nothing binds a Hibernate session to it, so
the very first repository call - the claim - threw. Worse, the failure handler called
markFailed, which threw for the same reason, so nothing was recorded: the document sat
in DRAFT with no error, no processed_at and no outward sign that anything had gone
wrong. CircularIngestService.ingest was never reached.

This was latent in the cron version too. It never surfaced because that scheduler was
never actually deployed anywhere.

- New CircularIngestBookkeeping: claim / document / published / failed /
reclaimStalled, each REQUIRES_NEW. Independent transactions matter most for failed(),
which runs after the ingest transaction has already rolled back and must not be
dragged into it.
- It is a SEPARATE bean on purpose. @Transactional on the runner's own methods would be
invoked from inside its own Runnable - a self-invocation never passes through the
Spring proxy, so the annotation would be silently ignored and the bug would come back
wearing a disguise.
- The runner no longer touches CircularIngestRepository at all.

Not caught locally because the RunIngest harness uses JdbcIngestRepo, a plain-JDBC
implementation that bypasses Hibernate entirely - so it can reproduce the parsing but
never a session or transaction problem.

+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/CircularIngestBookkeeping.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/CircularIngestRunner.java

Rev 37346 – Sort sale returns so the ones still needing an action ...

amit — Tue, 18 Aug 2026 16:45:26 +0530

amit – 1 file(s) modified
Sort sale returns so the ones still needing an action come first

The Recently Received Debit Notes table was ordered purely by receive time, so a
return waiting on a refund or on the partner's acknowledgment sank below rows that
were already refunded and needed nothing. On a busy warehouse the actionable rows
were off the first screen.

- recentOrders is now ranked pending-first (Received - Pending Refund, Rejected -
Pending Acknowledgment) ahead of settled ones (Refunded, Cancelled), with the
existing receiveTimestamp DESC kept as the tie-breaker inside each group
- getPendingActionRank follows the same precedence invoice-return.vm uses to pick
the status badge - reject checked before refund - so the ordering can never
disagree with the label the user sees
- ranked on the return's own state, not on the viewer's canReceive/canRefund
permissions, so a pending return stays at the top for everyone looking at it

Presentation only; no query, entity or lifecycle change. Note that returns never
received at all cannot surface here regardless, since the query filters on
receiveTimestamp BETWEEN the selected dates.

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

Rev 37345 – Beat Journey (today): LOI-based 'Onboarded' + last-billing recency board columns, ...

vikas — Tue, 18 Aug 2026 16:12:06 +0530

vikas – 1 file(s) modified
Beat Journey (today): LOI-based 'Onboarded' + last-billing recency board columns, level-filtered orders list (grouped by partner), and flag tuning — remove #1/#3, use per-visit total_distance for #4.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

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

Rev 37344 – Beat Journey: LoiFormRepository.selectMaxApprovedAcquiredDateByBdm() — max approved-LOI acquiredDate per BDM, powering ...

vikas — Tue, 18 Aug 2026 16:05:12 +0530

vikas – 2 file(s) modified
Beat Journey: LoiFormRepository.selectMaxApprovedAcquiredDateByBdm() — max approved-LOI acquiredDate per BDM, powering the board 'Onboarded' column (store.active_timestamp is null for all stores).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/user/LoiFormRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/user/LoiFormRepositoryImpl.java

Rev 37343 – Update PJP, Visit quality flags

vikas — Tue, 18 Aug 2026 15:18:27 +0530

vikas – 2 file(s) modified
Update PJP, Visit quality flags

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/BeatJourneyController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/beat-journey.vm