| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37353 |
2 m |
aman |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/ |
AI lead intake: assign new leads to a random active Sales L1 instead of fixed auth id 53 |
|
| 37352 |
48 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Fixed max limit to 15 lac for Credit limit |
|
| 37351 |
2 h 14 m |
ranu |
/trunk/ |
code committed for sales l3 added in bi and other model |
|
| 37350 |
3 h 26 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/ |
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. |
|
| 37349 |
18 h 48 m |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/ |
super retailer club 5 live |
|
| 37348 |
18 h 52 m |
ranu |
/trunk/ |
super retailer club 5 live |
|
| 37347 |
20 h 20 m |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/offercircular/ |
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. |
|
| 37346 |
20 h 33 m |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
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. |
|
| 37345 |
21 h 7 m |
vikas |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
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> |
|
| 37344 |
21 h 14 m |
vikas |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/user/ |
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> |
|
| 37343 |
22 h 0 m |
vikas |
/trunk/profitmandi-fofo/src/main/ |
Update PJP, Visit quality flags |
|
| 37342 |
22 h 19 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/ |
Allow re-ingest to start a circular already sitting in DRAFT
Moving the parse into the portal turned DRAFT into a dead end. Under the cron
scheduler DRAFT meant "something will pick me up", so re-ingest only ever had to push
a document back into it, and PUBLISHED/FAILED were the only sensible sources. Nothing
polls DRAFT any more - the runner is triggered by the upload that created the
document - so a circular whose trigger never fired had no way to be started at all.
That is not hypothetical: the Aug'26 circular uploaded to production before the runner
was deployed sits in DRAFT, and pressing re-ingest matched zero rows and reported
"not started".
DRAFT now joins PUBLISHED and FAILED as a valid source state. PROCESSING stays
excluded - that one is genuinely in flight - and claimForProcessing remains the single
arbiter of who actually parses, so allowing DRAFT cannot cause a double parse. |
|
| 37341 |
22 h 26 m |
amit |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ |
fix(rbm-dashboard): return full partner book and exclude inactive stores
/v2/fofo/rbm-dashboard capped partners/alerts at 50 by default. The RBM home
searches and filters client-side, so any partner outside that slice was
unfindable while summary.totalPartners reported the real (much larger) count.
- limit now defaults to 0 = uncapped; an explicit ?limit=n is still honoured
up to RBM_DASHBOARD_MAX_LIMIT (200)
- deactivated stores are skipped for the whole computation, not just alerts:
they have no target, scored 0% and sorted to the top of the action list
- summary.limit reports 0 when uncapped instead of Integer.MAX_VALUE |
|
| 37340 |
22 h 32 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
Fixed max limit to 15 lac for Credit limit |
|
| 37339 |
23 h 30 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Fixed max limit to 15 lac for Credit limit |
|
| 37338 |
23 h 41 m |
amit |
/trunk/profitmandi-cron/ |
Remove offer-circular ingest from cron - it now runs in the portal
Counterpart to the fofo commit that moved the parse into profitmandi-fofo. Nothing is
lost: all 13 parser classes and the test moved verbatim, and CircularIngestScheduler
was replaced by an executor-driven runner in the portal.
- com.smartdukaan.cron.offercircular deleted, main and test
- tabula dependency removed; PDFBox no longer enters this artifact at all
- dumpCircularClasspath moved to fofo, where the parser and its classpath now live
This module no longer knows anything about offer circulars, so a cron rebuild is no
longer a prerequisite for the feature to work - which was the entire problem. |
|
| 37337 |
23 h 41 m |
amit |
/trunk/profitmandi-fofo/ |
Move offer-circular ingest out of cron and into the portal
The parse now runs in profitmandi-fofo, on a background thread, triggered by the
upload that produced the document.
Why: splitting one feature across two artifacts with independent deploy cadences
cost a full day. fofo shipped, cron did not, and a valid upload sat in DRAFT with
nothing on the server able to parse it - the deployed cron jar contained none of the
ingest classes. One 9-page PDF a month never justified a batch tier, and the portal
already ships two PDF stacks, so the isolation argument for keeping PDFBox out was
weaker than it looked.
- 13 parser classes move verbatim from com.smartdukaan.cron.offercircular to
com.spice.profitmandi.web.offercircular. No logic changed.
- CircularIngestScheduler becomes CircularIngestRunner: the @Scheduled(every 5 min)
entry point and the offer.circular.ingest.enabled flag are gone, replaced by a
single-threaded daemon executor. All claim, ingest and notification logic is
unchanged.
- Upload hands the document id to the runner AFTER COMMIT, not inline. The DRAFT row
is written inside the request transaction; a worker starting immediately would race
that commit, find nothing to claim and silently do nothing - which is precisely the
stuck-on-DRAFT symptom this change removes.
- The guarded claim is KEPT even though there is now one trigger. It still stops a
double-submit, a second portal node, and a re-ingest racing an in-flight parse.
- Re-ingest parses immediately instead of queueing for a scheduler.
- The stall reaper runs when the review screen loads. There is no timer here any
more, and a document stranded by a redeploy mid-parse only matters when somebody
looks for it - which matters more now the parse lives in the web application.
- tabula moves to this module with its exclusions intact, as does the
dumpCircularClasspath helper the local ingest harness depends on.
- Screen no longer claims "the ingest job runs every 5 minutes", which was untrue the
moment cron stopped being the route; poll interval 15s -> 3s to match a parse that
takes seconds. jsVersion 404 -> 405.
- offer.circular.review.url added here, since the runner sends that email now.
Verified: full ingest of the Aug'26 circular through the relocated code is identical
to the reference - 239 offers, 663 products, 279 AUTO_EXACT, 361 benefits, 511
tenures, 911 bank links. ProductNamesTest 11/11 in its new home. |
|
| 37336 |
1 d 1 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/ |
Expose loginEmail to the admin views
admin.vm gates the OFFER CIRCULAR sidebar entry on the exact logged-in email,
because visibility there is per-email and auth.menu can only express roles. Nothing
was setting that variable, so the #if was always false and the entry rendered for
nobody on a clean build - it only appeared where a working copy happened to carry
this line locally.
Committed alongside r37331, which added the gate itself. |
|
| 37335 |
1 d 1 h |
amit |
/trunk/profitmandi-fofo/src/main/ |
Show offer circular ingest state on the review screen
Upload and parsing run in different processes - the portal stores the PDF as DRAFT
and the cron job claims it minutes later - so the screen looked identical before and
after a successful ingest. A reviewer had no way to tell "not parsed yet" from
"parsed and produced nothing", and a FAILED circular showed nothing at all.
- the selected circular's state is shown as queued / parsing / parsed / failed,
with the recorded reason on failure and the ingest summary on success
- while it is DRAFT or PROCESSING the screen polls every 15s and pulls in the rows
the moment the parse lands. Polling stops as soon as the state settles, so it
cannot spin forever, and a transient error keeps waiting rather than giving up
- jsVersion 403 -> 404, since offer-circular-review.js is already being served and
this is a modification rather than a new file
Pairs with the stall reaper: a circular abandoned mid-parse is now both recovered
and explained on screen instead of sitting silently in PROCESSING. |
|
| 37334 |
1 d 1 h |
amit |
/trunk/profitmandi-cron/ |
Sweep stalled offer circulars before each ingest run, and drop stale scaffolding
- The scheduler now calls reclaimStalledProcessing before looking for new work, so
a circular stranded in PROCESSING by a dead or redeployed worker is failed with a
reason instead of staying invisible forever. Threshold is 30 minutes against a
parse that takes seconds, so it can only ever catch a genuinely dead worker. The
sweep is wrapped so it can never stop the actual ingest.
- dumpCircularClasspath was labelled a temporary helper for diffing against the
reference Python. That Python has been deleted, but the task is what lets an
ingest be reproduced and measured locally per scripts/offer_circular/README.md,
so the comment now says what it is for rather than telling the next reader to
delete it.
- CircularExtractor's javadoc claimed verification against the Python reference.
That proved equivalence, not correctness - both shared the missing-memory-unit
bug that bound offers to the wrong SKU. Reworded so it cannot be read as a
correctness guarantee, and points at the fixture and ProductNamesTest instead.
Verified: full ingest of the Aug'26 circular is byte-identical to the reference -
239 offers, 663 products, 279 AUTO_EXACT. ProductNamesTest 11/11. |
|