SmartDukaan – /

Rev 37427 – src dashboard logic correction

ranu — Wed, 26 Aug 2026 19:45:06 +0530

ranu – 3 file(s) modified
src dashboard logic correction

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

Rev 37426 – Realme: treat the lookup response, not a missing error element, ...

amit — Wed, 26 Aug 2026 19:40:47 +0530

amit – 1 file(s) modified
Realme: treat the lookup response, not a missing error element, as success

After r37425 Realme logged 27 'Success at attempt' and 27 'no active/check
response captured' in the same window, and wrote 0 rows. The hook was not at
fault -- reproduced locally, it captures both XHR and fetch correctly.

Success was being inferred from the ABSENCE of dx_captcha_basic_bar-inform:

try { wait5Sec.until(visibilityOf(bar-inform)); log('Failed') }
catch { log('Success') }

realme rebuilt this page, so that element may no longer exist. The wait then
always times out and EVERY attempt reports success while the captcha was never
solved, no lookup fired and nothing was captured. The 27/27/0 is that exactly.

The response arriving is the only signal that actually proves the captcha
passed, so it now waits for that (polling, up to 8s) and treats its absence as a
failure worth retrying. This also removes the separate 'no response captured'
branch, since reaching the success path now means the response is in hand.

Oppo is left alone: its bar-inform detection is working (0 missed captures
against 673 lookups), so there is nothing to fix there.

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

Rev 37425 – Oppo/Realme: capture the response from fetch as well as XHR ...

amit — Wed, 26 Aug 2026 19:27:25 +0530

amit – 2 file(s) modified
Oppo/Realme: capture the response from fetch as well as XHR

r37423 got Realme solving the captcha again -- 4 of 4 on the first tick after
deploy -- but every one logged 'Result shown but no active/check response
captured'. The capture hook only wrapped XMLHttpRequest, and realme's page issues
the lookup through fetch, so it recorded nothing and each imei was stored with a
null date.

The hook now wraps window.fetch too, cloning the response before reading it so
the page still consumes its own body. Applied to Oppo as well: its XHR path is
working today, but the same silent failure would follow any move to fetch, and
the cost is a few lines.

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

Rev 37424 – Oppo/Realme slider captcha: size the calibration nudge from the gap ...

amit — Wed, 26 Aug 2026 19:05:20 +0530

amit – 2 file(s) modified
Oppo/Realme slider captcha: size the calibration nudge from the gap

r37422 replaced a 15px calibration nudge with a fixed 60px, which fixed the
under-measurement but introduced the opposite error. Production data over 764
calibrations shows 45% ended UNUSABLE (closed <= 0, i.e. the piece shot past the
hole and the measured gap grew instead of shrinking), and among gaps under 60px
it was 85%.

The nudge is now sized from the gap -- aim to close about half of it -- and
clamped to [10,60]. Replaying the real observed gap distribution: unusable and
overshoot fall from 21% to 2%.

The observed travel ratio in production is 1.13 circle px per slider px, against
1.68 measured locally; it varies with render scale, which is why the ratio is
still derived from the measurement. ASSUMED_RATIO only sizes the probe, and 1.7
errs toward a smaller nudge, which is the safe direction here.

Oppo is currently solving 43% (was 9% before r37422). Realme carries the same
widget and the same defect and has not been deployed yet.

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

Rev 37423 – Realme warranty check: retarget the rebuilt page and read its ...

amit — Wed, 26 Aug 2026 18:59:28 +0530

amit – 1 file(s) modified
Realme warranty check: retarget the rebuilt page and read its JSON

Realme has recorded nothing since 24-Aug, the same day Oppo stopped. Driving the
page confirms why: it was rebuilt and every selector the code used is gone.

.sn-input -> the field is now .imei-input input (placeholder 'Please input IMEI')
div.check-btn -> the submit is now an icon, .imei-input .search-icon

So it failed even earlier than Oppo did -- it could not type the imei, let alone
reach the captcha, which is why the log showed only 'Initiating webdriver...'.

The result now comes from the JSON the page already receives
(customer-api.realme.com/in/active/check) rather than an XPath keyed off a label
that no longer exists. That old locator also had an '| //h1[contains(@class,
title)]' branch which would silently match a page heading and try to parse it as
a date. The API is explicit: expiryDate (yyyy.MM.dd) and an isActivation flag,
so nothing is inferred from message text.

expiryDate is the WARRANTY EXPIRY, so a year is still subtracted -- warranty is
12 months as standard. Checked against our own records rather than assumed:
41,267 of 41,289 stored Realme activation dates precede the date we checked
them, averaging 13 days before, which is only consistent with the subtraction
already being correct.

Ports the r37422 captcha fix verbatim -- identical dingxiang slider, identical
15px calibration nudge that made it land ~30px out against a ~30px hole. And as
with Oppo the outcome is always recorded, even as null: findElement THREW when
the element was missing, so nothing was written and the imei was re-queued every
5 minutes indefinitely.

Also converts 29 System.out.println to the logger. The cron JVM's stdout is a
socket from the launching ssh session, so every diagnostic was going nowhere.

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

Rev 37422 – Oppo slider captcha: calibrate over a longer nudge and correct ...

amit — Wed, 26 Aug 2026 17:11:44 +0530

amit – 1 file(s) modified
Oppo slider captcha: calibrate over a longer nudge and correct before releasing

The captcha solves about 10 times in 115 attempts. The arithmetic was right; the
measurement feeding it was not.

To place the piece the code must first learn how far it travels per slider pixel,
which it did by nudging 15px and re-measuring. The piece moves ~1.7px per slider
px, so 15px closed the gap by only ~25px -- and Hough circle detection carries
about +/-2-3px per circle, so the ratio came from a measurement roughly 20%
wrong. That error was then multiplied across the whole remaining travel: on a
150px gap it landed ~30px out, against a hole ~30px wide.

Nudging 60px closes ~100px, so the same detection noise is ~5% rather than ~20%.
The code also released on its single computed offset, committing all of that
error to the final position; it now measures once more after the main move and
closes the remainder before releasing. Math.round replaces an (int) cast that
biased every move short by up to a pixel.

Monte Carlo over the measurement noise (20k trials, +/-8px tolerance): median
placement error 16.3px -> 2.1px, success 26% -> 98%. Holds across a 2x range of
travel ratios and degrades gracefully as detection worsens, because the ratio is
derived rather than assumed. Real-world will be lower -- the same model puts the
old code at 26% where production sees 9% -- so expect roughly 1 in 3, not 49 in
50, and read Success/Failed in the log to get the true figure.

The ratio is returned rather than held on a field: this is a singleton and the
Oppo secondary and tertiary jobs run through it concurrently.

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

Rev 37421 – EWB: recover existing e-way bill on NIC 604 instead of ...

amit — Wed, 26 Aug 2026 16:47:32 +0530

amit – 2 file(s) modified
EWB: recover existing e-way bill on NIC 604 instead of storing a placeholder

DCNSUPDL948 generated EWB 451765074092 at NIC, then the transaction rolled back and
the number was lost. Every retry hit 604 and stored the literal EXISTING-LOOKUP-NEEDED
with no validity date, which routed the PDF down the transporter branch and NPE'd on a
self-pickup dispatch with no warehouse_provider row. ~640 retries in 55 minutes, and
because the failure surfaced as an Error it escaped catch(Exception) and blocked six
other documents behind it.

- GstProService: on 604, look the bill up via GetEwayBillsByDate + docNo match and
return it in GENEWAYBILL shape; stamp NIC's generation time instead of now().
Throw when it cannot be recovered rather than persist a placeholder.
- InvoiceService: saveInvoiceInNewTransaction no longer propagates. It commits
irn_generated=0 with the reason so a failed document stops churning; already-filed
invoices being re-rendered are left untouched.
- InvoiceService: cron loop catches Throwable so one bad document cannot skip the batch.
- InvoiceService: null-guard warehouse_provider; omit the transporter line instead of
failing the PDF.
- recordIrnFailure: transport failures now park at 0 for escalation rather than
requeueing for unbounded retry.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/GstProService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/invoicing/InvoiceService.java

Rev 37420 – Oppo warranty check: read the JSON response instead of scraping ...

amit — Wed, 26 Aug 2026 16:23:17 +0530

amit – 1 file(s) modified
Oppo warranty check: read the JSON response instead of scraping the date

Oppo has recorded no activation dates since 23-Aug. With logging restored
(r37410) the cause is visible: the captcha IS solved -- 10 successes per tick --
and it then fails on the very next line with

no such element: //*[contains(text(),'UTC+5.5') or contains(text(),'Non-Activate')]

Their result is now label/value pairs, and the value is rendered from TWO text
nodes: dayjs(regDate).format('DD/MM/YYYY') plus a '(UTC+x)' suffix computed from
the browser's own timezone. XPath contains(text(),...) tests only the first node
-- the date -- so it never matched. 'Non-Activate' is gone too: an inactive
device now reads 'The system will update the date within 7 days of device
activation.' Verified against a replica of their DOM: old locator 0 matches, and
the value element yields '23/08/2026 (UTC+5.5)'.

Rather than chase their markup again, take the value from the source: the page
calls /oppo-api/basic/v1/getDeviceInfo and the response carries regDate as epoch
millis -- no date format, no locale, no timezone suffix to parse. A small hook
records that response as the page receives it; nothing extra is requested and no
captcha behaviour changes.

Also switches the outcome to always record the imei. findElement THREW when the
element was missing, which skipped the fallback entirely, so nothing was written
to dateMap and the row was re-queued on every run indefinitely -- 'Could not
capture date' appears 0 times in the log because it was unreachable.

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

Rev 37419 – Whatsapp botpenguin

vikas — Wed, 26 Aug 2026 14:03:37 +0530

vikas – 1 file(s) modified
Whatsapp botpenguin

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/remarkscore/RemarkScoreService.java

Rev 37418 – Whatsapp botpenguin

vikas — Wed, 26 Aug 2026 14:02:05 +0530

vikas – 3 file(s) modified
Whatsapp botpenguin

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/remarkscore
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/remarkscore/DuplicateRemarkDigestRunner.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/remarkscore/RemarkScoreRunner.java

Rev 37417 – Whatsapp botpenguin

vikas — Wed, 26 Aug 2026 14:00:06 +0530

vikas – 1 file(s) modified
Whatsapp botpenguin

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

Rev 37416 – Port two cron WhatsApp call sites left behind by r37409/r37415. ...

vikas — Wed, 26 Aug 2026 13:56:04 +0530

vikas – 2 file(s) modified
Port two cron WhatsApp call sites left behind by r37409/r37415.

OrderTrackingService sends the ORDER_DELIVERED template with the airway bill
as its only variable; the push notification on the same loop keeps its
formatted sentence, since template wording lives in Meta, not the call site.
Application drops the userMobileNumberOptIn and authUserMobileNumberOptIn CLI
options, whose NotificationService.optIn backing went with the Gupshup gateway.

ScheduledTasks.java is deliberately not in this commit: locally it also carries
unrelated in-flight remark-scoring work whose package is still unversioned, so
committing it would put @Autowired RemarkScoreRunner into trunk with no such
class. Its two WhatsApp call sites (optIn at ~4618, sendWhatsappMessage at
~5276) therefore still fail to compile at HEAD and need a follow-up.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ordertracking/OrderTrackingService.java

Rev 37415 – Whatsapp Apis

vikas — Wed, 26 Aug 2026 13:46:51 +0530

vikas – 14 file(s) modified
Whatsapp Apis

x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/Optin.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/OptinRepository.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/OptinRepositoryImpl.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/CpassWhatsappService.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/GupshupWhatsappService.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappListRow.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappListSection.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappProvider.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappProviderResolver.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappReplyButton.java
x /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappTemplateSender.java
x /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/whatsapp/WhatsappProviderResolverTest.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/CpassTestController.java
x /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/CpassWebhookController.java

Rev 37414 – Whatsapp Apis

vikas — Wed, 26 Aug 2026 13:39:31 +0530

vikas – 15 file(s) modified
Whatsapp Apis

~ /trunk/profitmandi-common/src/test/resources/golden/cn-inter-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/cn-intra-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/dn-inter-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/dn-intra-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/dn-po-suppressed-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/v1-inter-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/v1-intra-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/v1-margin-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/v2-dc-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/v2-inter-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/v2-intra-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/v2-margin-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/v2-multiorder-p0.png
~ /trunk/profitmandi-common/src/test/resources/golden/v2-po-orderdate-p0.png
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/whatsapp/WhatsappNumbers.java

Rev 37413 – Whatsapp Apis

vikas — Wed, 26 Aug 2026 13:19:27 +0530

vikas – 1 file(s) modified
Whatsapp Apis

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

Rev 37412 – Whatsapp Apis

vikas — Wed, 26 Aug 2026 13:16:24 +0530

vikas – 6 file(s) modified
Whatsapp Apis

~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/config/WebMVCConfig.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/BotPenguinTestController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoLiquidationController.java
~ /trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/V2FofoUpSaleController.java
~ /trunk/profitmandi-web/src/main/resources/META-INF/prod.properties
~ /trunk/profitmandi-web/src/main/resources/META-INF/staging.properties

Rev 37411 – v2 version some fixes

ranu — Wed, 26 Aug 2026 13:13:33 +0530

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

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

Rev 37410 – Oppo warranty check: log to the logger instead of stdout ...

amit — Wed, 26 Aug 2026 13:10:28 +0530

amit – 1 file(s) modified
Oppo warranty check: log to the logger instead of stdout

Oppo has resolved nothing all day -- 83 ticks, the same 10 IMEIs recycled every
time, zero "Serial Number ... Date" results -- and the log shows only a single
line, 'Initiating webdriver...'. That is not silence: the class had 1 LOGGER call
against 28 System.out.println, and the cron JVM's stdout is a socket inherited
from the SSH session that launched it. Every diagnostic was going nowhere.

So the code has been reporting what is wrong 28 times per attempt (which element
was missing, the computed slider distance, success or failure per attempt, the
parsed date) and all of it was discarded. Same pattern as the Vivo bug found
today, where a five-word log line hid the real cause for weeks.

Converted to LOGGER at info, with warn on the failure paths and error on the
catch-all, which now includes the exception rather than a bare printStackTrace.
The slider-widget timeout says which element it was waiting for, since that is
the most likely failure point.

No behaviour change -- only where the output goes.

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

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