SmartDukaan – /

Rev 37409 – Changed WhatsApp service to botpenguin (DigiWaha)

vikas — Wed, 26 Aug 2026 13:03:25 +0530

vikas – 18 file(s) modified
Changed WhatsApp service to botpenguin (DigiWaha)

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/ProfitMandiConstants.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/BidService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/BidServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/LiquidationService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/NotificationService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/NotificationServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/offers/OfferServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/BotPenguinPayloads.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/BotPenguinWhatsappService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappFlow.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappNumbers.java
~ /trunk/profitmandi-dao/src/main/resources/shared-prod.properties
~ /trunk/profitmandi-dao/src/main/resources/shared-staging.properties
~ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/whatsapp/WhatsappNumbersTest.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/catalog/LiquidationController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/UpSaleController.java
~ /trunk/profitmandi-fofo/src/main/resources/META-INF/dev.properties
~ /trunk/profitmandi-fofo/src/main/resources/META-INF/prod.properties

Rev 37408 – Vivo IMEI activation: stop spending captchas on line items with ...

amit — Wed, 26 Aug 2026 12:38:10 +0530

amit – 2 file(s) modified
Vivo IMEI activation: stop spending captchas on line items with no IMEI

76% of production captcha rejections were line items whose serial number is
null. Vivo answers those with {"msg":"参数为空"} -- "parameter is empty" --
and status 0, which this code recorded as a captcha failure. So a correctly
solved captcha looked wrong, no activated_imei row was written, the line item
stayed pending, and it came back every 5 minutes indefinitely. Those rows were
permanently consuming roughly 43% of the run quota, which is why every tick ran
full at 20/20 and the backlog never drained.

It also made the model look far worse than it is: measured accept rate 44%,
while the same solver scores 85-93% when the IMEI is present. True captcha
accuracy is around 77%.

Fixed at source: both named queries now exclude null and blank serial numbers,
so such line items never enter the pool (this also covers the Realme caller).
The loop additionally skips them before fetching a captcha, so no captcha,
solver call or Vivo request is spent discovering it.

Found via the diagnostics added in r37407 -- the previous log line recorded
five words and discarded the response that named the cause.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/VivoImeiActivationService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/ActivatedImei.java

Rev 37407 – Vivo IMEI activation: log why a captcha was rejected ...

amit — Wed, 26 Aug 2026 12:26:43 +0530

amit – 1 file(s) modified
Vivo IMEI activation: log why a captcha was rejected

Production refuses ~56% of submissions, but reading the stored images by hand
showed 9 of 10 carried the CORRECT code. Replicating the request from the same
box gives 85-93%, and every external difference was measured and ruled out:
real vs dummy imei (7/8 both), user-agent (83% both), session reuse (74 vs 75%),
two concurrent jobs (80% both), source IP, and fetch-to-submit delay from 0 to
10s (90-91% throughout). Vivo's reply is byte-identical in every failure, so the
payload carries no discriminator.

That leaves something inside this process, and the old log line recorded five
words and discarded the evidence. It now captures the code submitted, the imei,
the real fetch-to-submit latency, the session cookies actually held at submit
time, and Vivo's full response.

The cookies matter most: if the SESSION cookie is being dropped or rotated
between fetching the captcha and submitting it, the captcha would be validated
against the wrong session and refused despite a correct code -- which fits every
measurement above and is invisible from outside the JVM.

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

Rev 37406 – Vivo captcha: put the /verdict shared secret in the cron ...

amit — Wed, 26 Aug 2026 11:15:36 +0530

amit – 3 file(s) modified
Vivo captcha: put the /verdict shared secret in the cron properties

The token was only in run-cron.sh, which is not version-controlled. Rebuild the
box or deploy elsewhere and it silently vanishes -- the verdict call is
best-effort and swallows failures, so nothing would break loudly; training data
would just quietly stop being collected. Properties travel with the build.

dev and staging are deliberately empty: with no token CaptchaService skips the
call entirely, so a local run cannot post verdicts to the live solver and
pollute the training corpus.

CAPTCHA_VERDICT_TOKEN in the environment still overrides this, so the token can
be rotated without a rebuild.

~ /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 37405 – Drive the onboarding/HR state dropdowns from inventory.statemaster fofo-form.vm, fofo-edit.vm ...

amit — Tue, 25 Aug 2026 22:59:54 +0530

amit – 6 file(s) modified
Drive the onboarding/HR state dropdowns from inventory.statemaster

fofo-form.vm, fofo-edit.vm and hr_employee_form.vm each hardcoded their own state
list instead of using $stateNames. Six of those 37 values do not exist in the
master (& vs and variants, Uttaranchal, the pre-merger UTs), so anything picked
from them could not be resolved back.

Only the name="state" select changed in hr_employee_form.vm; its other dropdowns
are untouched.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/FofoController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/HrmsController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/RegisterController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/fofo-edit.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/fofo-form.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/hr_employee_form.vm

Rev 37404 – Serve the canonical state list from inventory.statemaster Add GET ...

amit — Tue, 25 Aug 2026 22:59:47 +0530

amit – 1 file(s) modified
Serve the canonical state list from inventory.statemaster

Add GET /master-data/states returning each state's name and GST state code.

Clients were each carrying their own hardcoded state list, which drifted from the
master. Anything we store is later resolved back through that master by name, so a
drifted list writes values nothing can resolve - which is how customer addresses
ended up with states like 'Daman & Diu' that the master no longer holds, leaving
those invoices unable to generate. Serving the list means a correction to the
master reaches every client without a release.

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

Rev 37403 – Add the canonical state list URL constant Serves inventory.statemaster ...

amit — Tue, 25 Aug 2026 22:59:41 +0530

amit – 1 file(s) modified
Add the canonical state list URL constant

Serves inventory.statemaster to clients so none of them carry their own copy.

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/ProfitMandiConstants.java

Rev 37402 – Vivo IMEI activation: report Vivo's captcha verdict back to the ...

amit — Tue, 25 Aug 2026 20:57:24 +0530

amit – 2 file(s) modified
Vivo IMEI activation: report Vivo's captcha verdict back to the solver

Only this cron ever learns whether Vivo accepted a captcha (status 0 means it
was wrong), so it is the only place that can label the solver's training data.
After each checkCode response it now posts the image, the code and the outcome
to the solver's /verdict endpoint, which files the sample as accepted (the
prediction was right - a free label) or rejected (needs a human to label it).

The solver has been running at a measured 22.3% accept rate and no training
data was ever collected, so the model could not be improved at all.

Strictly best-effort: 2s connect / 3s read timeouts and every exception
swallowed. Data collection must never slow down or break IMEI activation.

The shared secret is read from CAPTCHA_VERDICT_TOKEN in the environment,
falling back to a captcha.verdict.token property, so it need not be committed.
Without a token the call is skipped entirely.

Also drops /tmp/captcha.jpg: the captcha bytes are needed in memory for the
verdict report anyway, so the two concurrently-scheduled Vivo jobs no longer
share one file and overwrite each other's image.

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

Rev 37401 – Drop commented reference to the removed InvoiceFormatter

amit — Tue, 25 Aug 2026 20:30:26 +0530

amit – 1 file(s) modified
Drop commented reference to the removed InvoiceFormatter

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

Rev 37400 – Merge the three sale-invoice download endpoints into /invoice/download generateInvoice, ...

amit — Tue, 25 Aug 2026 20:30:22 +0530

amit – 7 file(s) modified
Merge the three sale-invoice download endpoints into /invoice/download

generateInvoice, generateInvoices and downloadInvoices differed only in how they
resolved the order ids and who was allowed to ask; everything after that was the
same. That drift meant only the single-order download stapled the policy
certificates, so the same invoice pulled from sale history came out without
them. One handler now selects by orderId, partner date range (admin only) or the
caller's own sale-history search, over reusable resolvers plus a shared
render-and-respond step. The old URLs stay as deprecated shims.

The admin range download is now fault tolerant - one unbillable order used to
fail the whole batch.

Remove the commented-out thermal variant of generateInvoice and the unused
paymentOptionIdPaymentOptionMapUsingPaymentOptions. Bump the asset version for
the sale.js change.

~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/OrderController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/sale.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/order-details.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/sale-details.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/search-order-details.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/search-order.vm

Rev 37399 – Use the shared insurance invoice line builder for standalone policy ...

amit — Tue, 25 Aug 2026 20:30:12 +0530

amit – 1 file(s) modified
Use the shared insurance invoice line builder for standalone policy invoices

Replace the duplicated CustomInsurancePolicy block with InsuranceInvoiceLine.
Drop the setTotalAmount call - the renderer derives totals from the item lines,
so the value was never read - and the repository field it orphaned.

Derive and set the invoice state codes, as the partner invoice already does, so
the place of supply prints when billing a registered buyer.

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

Rev 37398 – Share one insurance invoice line builder across partner and standalone ...

amit — Tue, 25 Aug 2026 20:30:07 +0530

amit – 5 file(s) modified
Share one insurance invoice line builder across partner and standalone invoices

Extract InsuranceInvoiceLine next to the partner invoice builder so both callers
- OrderServiceImpl.getInvoicePdfModel(FofoOrder) and the standalone policy
invoice in InsuranceController - produce the SAC, tax split and description from
one place. Arithmetic is unchanged (verified bit-identical); policyPlan is null
for policies sold outside a device sale, so it falls back to a generic plan name
instead of printing null.

Add IciciLombardService.policyCertificatePath so the service that writes the
certificate owns the path; callers were rebuilding it and hardcoding the prod
directory, so lookups silently missed off prod.

Add selectByInvoiceNumbersAndProviderId so bulk invoice downloads fetch policies
in one query instead of one per invoice.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/InsurancePolicyRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/InsurancePolicyRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/IciciLombardService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/order/InsuranceInvoiceLine.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/order/OrderServiceImpl.java

Rev 37397 – Consolidate insurance invoice line rendering; drop dead thermal-printing path ...

amit — Tue, 25 Aug 2026 20:29:58 +0530

amit – 3 file(s) modified
Consolidate insurance invoice line rendering; drop dead thermal-printing path

Remove the unused 58/80mm thermal chain (InvoiceFormatter, PrinterType and the
PrinterType overload of generateAndWrite) - its only caller was a commented-out
endpoint, and it bypassed the insurance line folding in DocumentData.items().

Drop generateMarginSchemeInvoice, a no-op alias for generateInvoiceV2 with no
production callers.

x /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/util/InvoiceFormatter.java
~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/util/PdfUtils.java
x /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/util/PrinterType.java

Rev 37396 – observability: delete the log4j1 config left alongside log4j2.xml in fofo ...

amit — Tue, 25 Aug 2026 20:24:43 +0530

amit – 1 file(s) modified
observability: delete the log4j1 config left alongside log4j2.xml in fofo

The module logs through log4j2 (log4j2.xml). This log4j.properties is a
log4j1-era leftover that nothing reads.

x /trunk/profitmandi-fofo/src/main/resources/log4j.properties

Rev 37395 – observability: retire the dead Nagios monitoring path, migrate balance signals ...

amit — Tue, 25 Aug 2026 20:24:34 +0530

amit – 6 file(s) modified
observability: retire the dead Nagios monitoring path, migrate balance signals to Micrometer

There is no Nagios server and the NRPE daemons have been removed from every
host, so the properties files written under /var/log/services were being
produced for nobody.

Deleted:
- CronMetricsService: zero references. Spring instantiated the @Service so its
constructor registered three meters, but nothing ever incremented them --
cron_execution_* read 0 in prometheus while cron_job_count_total (from
CronJobMonitorAspect) had recorded 1,597 executions.
- NagiosMonitoringScheduledSkeleton.

Removed the nagios properties writes from ScheduledSkeleton (-155 lines) and
KnowlarityCallMonitorScheduler (-46, including its now-purposeless
markTaskComplete helper). These recorded a per-job 0/1 status that
CronJobMonitorAspect already captures properly as success, failure and
duration metrics.

Kept the two signals that are genuinely useful: SMS gateway balance and the
ThinkWalnut recharge wallet balance now publish as Micrometer gauges via the
new BalanceGauges component, scraped from /actuator/prometheus. -1 means 'not
read yet' so a scrape before the first run is distinguishable from a real zero.

No behaviour change to any scheduled job. Compiles clean.

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/BalanceGauges.java
x /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/CronMetricsService.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/monitored/NagiosMonitorTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/knowlarity/KnowlarityCallMonitorScheduler.java
x /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/NagiosMonitoringScheduledSkeleton.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java

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

ranu — Tue, 25 Aug 2026 19:53:37 +0530

ranu – 2 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/webapp/WEB-INF/views/ftl/admin.vm

Rev 37393 – Vivo IMEI activation: validate captcha solver response before submitting to ...

amit — Tue, 25 Aug 2026 16:59:27 +0530

amit – 2 file(s) modified
Vivo IMEI activation: validate captcha solver response before submitting to Vivo

The captcha solver at 45.79.121.178 was down from 09-Jul-2026 to 25-Aug-2026
(uwsgi never restarted after a host reboot). nginx returned a 502 page for
every request. RestClient.executeJson returns the response body regardless of
HTTP status, so CaptchaService handed that HTML page to Vivo as the captcha
code and Vivo logged it as 'Found invalid captcha' - indistinguishable from an
ordinary wrong guess. The outage went unnoticed for 46 days.

CaptchaService now checks the response against the solver model's own 31-class
alphabet (^[1-9A-HK-NP-Z]{4}$) and returns null for anything else, logging the
offending payload. VivoImeiActivationService skips the IMEI when the code is
null instead of posting the garbage; it is retried on the next run.

Also drops a System.out.println of the full base64 captcha image.

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

Rev 37392 – Whatsapp Apis

vikas — Mon, 24 Aug 2026 18:37:54 +0530

vikas – 1 file(s) modified
Whatsapp Apis

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

Rev 37391 – Whatsapp Apis

vikas — Mon, 24 Aug 2026 18:11:52 +0530

vikas – 2 file(s) modified
Whatsapp Apis

+ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/services/RemarkAlertService.java
+ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/services/RemarkSimilarity.java

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

ranu — Mon, 24 Aug 2026 17:32:01 +0530

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

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

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

ranu — Mon, 24 Aug 2026 17:16:59 +0530

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

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

Rev 37388 – Whatsapp Apis

vikas — Mon, 24 Aug 2026 16:49:11 +0530

vikas – 28 file(s) modified
Whatsapp Apis

~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/model/ProfitMandiConstants.java
~ /trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/web/client/RestClient.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/NotificationServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/BotPenguinPayloads.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/BotPenguinTemplateInfo.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/BotPenguinWhatsappService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/CpassWhatsappService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/GupshupWhatsappService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappFlow.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappNumbers.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappProvider.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappProviderResolver.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappTemplateComponent.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappTemplateParam.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappTemplateRequest.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappTemplateSender.java
~ /trunk/profitmandi-dao/src/main/resources/shared-prod.properties
~ /trunk/profitmandi-dao/src/main/resources/shared-staging.properties
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/whatsapp
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/whatsapp/BotPenguinPayloadTest.java
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/whatsapp/BotPenguinResponseTest.java
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/whatsapp/BotPenguinTemplateResolutionTest.java
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/whatsapp/WhatsappNumbersTest.java
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/whatsapp/WhatsappProviderResolverTest.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/WebMVCConfig.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/BeatTrackingController.java
+ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/BotPenguinTestController.java
+ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/BotPenguinWebhookController.java

Rev 37387 – Disable UPI data

vikas — Mon, 24 Aug 2026 15:36:31 +0530

vikas – 1 file(s) modified
Disable UPI data

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

Rev 37386 – aging stock report put dp after stock qty

ranu — Mon, 24 Aug 2026 13:43:23 +0530

ranu – 1 file(s) modified
aging stock report put dp after stock qty

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

Rev 37385 – Added Notice and PJP access to akhil.kumar@smartdukaan.com

vikas — Mon, 24 Aug 2026 13:07:57 +0530

vikas – 2 file(s) modified
Added Notice and PJP access to akhil.kumar@smartdukaan.com

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

Rev 37384 – Fix My Stock brand tile styling on partner dashboard: use ...

amit — Mon, 24 Aug 2026 13:00:31 +0530

amit – 1 file(s) modified
Fix My Stock brand tile styling on partner dashboard: use object-fit contain so brand wordmarks are not cropped, replace absolute-positioned ribbon hack with in-flow flex layout, and centre the brand columns instead of the hard-coded 10rem left margin

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

Rev 37383 – Disable UPI data

vikas — Mon, 24 Aug 2026 11:06:54 +0530

vikas – 1 file(s) modified
Disable UPI data

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

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