| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37327 |
1 h 0 m |
ranu |
/trunk/ |
super retailer club 5 live |
|
| 37326 |
1 h 22 m |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
Add --backfillMissingEwb cron arg
Runs InvoiceService.backfillMissingEwb over an explicit invoice list:
--backfillMissingEwb --invoiceNumbers=A,B,C [--dryRun]
Explicit list rather than a date window so the backfill only touches the invoices known
to have lost their EWB. NOT_SUPPORTED on the RunOnceTasks wrapper suspends the
class-level transaction, keeping the NIC lookups outside one. |
|
| 37325 |
1 h 22 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/invoicing/ |
Add EWB backfill for invoices whose IRN was recovered via DUPIRN
When GenerateIRN carries EwbDtls, NIC files the IRN and e-way bill together and reports
the EWB back only in that response, flagged by InfoDtls[InfCd=EWBPPD]. A read timeout
sends the retry down the DUPIRN path, which recovers the IRN via the get-e-invoice
endpoint — that response carries neither InfoDtls nor EWB fields. The EWB therefore
exists at NIC while ewb_no stays null locally, and since updatePdfModelWithIrnDetails
gates the entire e-way bill section on ewb_no, the stored PDF omits it altogether.
backfillMissingEwb() looks the EWB up by (seller GSTIN, ack date), matches on docNo, and
takes actualDist from the per-EWB call since the distance is printed on the invoice. It
then re-renders the PDF; generateIrnForInvoices returns early once irn_generated is set,
so nothing is re-filed at NIC.
NIC is queried with the transaction suspended (NOT_SUPPORTED); the write and the
re-render each run in their own REQUIRES_NEW transaction. |
|
| 37324 |
2 h 13 m |
aman |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
Lead Management: restrict lead view to field-level sales only (L1-L3). Any SALES position at any level previously forced the own+reportees lead filter, so senior sales heads (L4+ BM/RSM/NSM/co-founder L7) lost visibility of all leads and their dashboard charts collapsed. hasCategory check replaced with isFieldSales() at both view-filter sites; assignee validation untouched. |
|
| 37323 |
2 h 17 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Drop irn_attempt_count; IRN transport retry is unbounded
Removes the attempt counter added in r37322 along with its pending ALTER TABLE, so the
change no longer carries a schema dependency.
NIC outages resolve within the day, and an invoice legally requires an IRN, so capping
the retry would not remove the obligation — it would only stop trying. Transport failures
now stay queued (irn_generated NULL) until the provider recovers; only a genuine rejection
from NIC is terminal. The failure reason is still recorded in irn_error_message, which
distinguishes a requeued transport failure from an invoice never yet attempted. |
|
| 37322 |
3 h 0 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Stop treating IRN transport timeouts as terminal; isolate NIC calls from batch transaction
A read timeout to GSTPro/NIC was recorded as a final verdict (irn_generated=false),
so 79 invoices billed on 2026-08-17 were left permanently without an IRN even though
NIC may well have filed them. A timeout means the call never completed, not that the
document was rejected.
- markEInvoiceFailed -> recordIrnFailure(invoiceNumber, Throwable): transport failures
leave irn_generated NULL so the cron retries (DUPIRN recovers anything NIC did file);
only a genuine rejection is terminal. Alert email now fires only when terminal.
- New einvoice_details.irn_attempt_count bounds that retry at 10 attempts, reset on
success, so a prolonged NIC outage still converges instead of looping forever.
Requires the matching ALTER TABLE before deploy.
- New saveInvoiceInNewTransaction(invoiceNumber): REQUIRES_NEW per invoice, reloading
orders inside it. RunOnceTasks has class-level @Transactional wrapping the whole
batch loop, so every NIC call previously ran inside one transaction holding write
locks on all orders in the batch; at 60s per call that window is unacceptable.
updateIrnsToInvoices and regenerateBilledInvoices now carry only invoice numbers,
keeping the batch transaction read-only.
- Route all NIC calls (IRN gen, auth, cancel, EWB) through the 60s regulator profile
via GstProAuthService.nicRestClient(). getGstDetails stays on the 10s default since
it runs on request threads. |
|
| 37321 |
3 h 1 m |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/web/client/ |
Preserve transport-failure cause in RestClient; add 60s regulator timeout profile
RestClient wrapped IOException/ClientProtocolException into RuntimeException(GE_1006)
without a cause, so callers could not tell a read timeout apart from a business
rejection. Pass the original exception as the cause at all four transport catch sites;
message text is unchanged.
Add HttpClientFactory.slowRegulatorRequestConfig() (60s socket) for NIC e-invoice/EWB
calls, which routinely exceed the global 10s default at peak, plus a RestClient
constructor taking an explicit RequestConfig. The global default is unchanged. |
|
| 37320 |
2 d 23 h |
ranu |
/trunk/profitmandi-dao/src/main/resources/ |
one assist ew at 99 up to 20k |
|
| 37319 |
3 d 0 h |
amit |
/trunk/ |
Fix partner-performance tertiary: aggregate order items (qty*mop), not the POS-typed order header
The tertiary panel summed fofo_order.total_amount - a price typed at the partner POS
and never validated against the catalogue - and attributed each whole order to its
first line item's brand via .get(0). One mistyped digit inflated reported sell-out
10x, and mixed-brand orders booked 100% to the first brand, leaving the rest at zero.
Defect dates from r32000/r32034 (May 2023); the panel was the only tertiary consumer
diverging from the qty*mop basis.
- New FofoOrder.selectMonthlyBrandTertiary: sum(quantity*mop) grouped by
(year*100+month) and item brand - the same basis selectPartnerTertiarySales
already uses for the DSR and the partner tier calculation
- PerformanceController: replaces two entity-loading queries (every FofoOrder and
FofoOrderItem for 6 months) with one aggregate; all items now count, each under
its own brand
- Month labels unchanged - toMonthLabel rebuilds the MMM''uu key, template untouched
- Remove V2FofoPerformanceController, the /v2/fofo JSON copy carrying the same defect
Verified against dev DB for fofo_id 175139501: Jul 2026 now 16,94,939 (panel
previously showed 50,92,440); all six months match the qty*mop basis. |
|
| 37318 |
3 d 2 h |
ranu |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/controller/checkout/ |
v2 version some fixes |
|
| 37317 |
3 d 2 h |
vikas |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/ |
Active Scratch Offers |
|
| 37316 |
3 d 2 h |
vikas |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/dtr/ |
Active Scratch Offers |
|
| 37315 |
3 d 3 h |
vikas |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/ |
Active Scratch Offers |
|
| 37314 |
3 d 5 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
Fixed max limit to 15 lac for Credit limit |
|
| 37313 |
3 d 6 h |
ranu |
/trunk/profitmandi-web/src/main/java/com/spice/profitmandi/web/v2/controller/fofo/ |
v2 version some fixes |
|
| 37312 |
3 d 6 h |
ranu |
/trunk/ |
one assist ew at 99 up to 20k |
|
| 37311 |
3 d 18 h |
vikas |
/trunk/ |
Scratch Offers code modify |
|
| 37310 |
3 d 21 h |
vikas |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/scratch/ |
Scratch Offers now selects only active partners |
|
| 37309 |
3 d 23 h |
vikas |
/trunk/ |
Scratch Offers now selects only active partners |
|
| 37308 |
4 d 0 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/ |
DN receipt: reject on condition mismatch instead of silently reclassifying
The receive screen defaulted the Condition dropdown to GOOD and receiveDebitNoteItems
overwrote purchase_return_item.type with whatever was submitted. A DOA return received
without touching the dropdown was rewritten BAD->GOOD, so on reject -> acknowledge the
restoreInventory branch put the unit back into good (sellable) stock instead of bad.
UKHD948/57: IMEI 353243710802439 was declared DOA, rejected as 'wrong entry', restored
as good stock and resold at MOP 3h44m later.
- receiveDebitNoteItems now compares each submitted condition against the stored one and
rejects the WHOLE debit note on any mismatch (PRO + rejectReturn are both per-DN and
there is no model for a partial receipt). PRO is still persisted so the receipt attempt
stays on record, then stamped rejected; no scans, no refund, no IRN work.
- Removed the pri.setReturnType(rt) overwrite. Past the gate the submitted condition always
equals the stored one, and applyReceipt already reads it off the entity. Rejected returns
now keep the declared type, so restoreReturnedItems restores to the right bucket.
- New notifyReturnRejectedConditionMismatch: to partner, cc Logistics L2/L3, RBM L1/L2 and
Sales L1 + first populated level in L2..L4. Sales ladder is sparse (L2 262 partners,
L3 64, L4 1582 of 1524 open stores) so a fixed L2/L3 rule resolves to nobody for most.
- getTeamEmails now filters inactive users and dedupes. csService.getAuthUserByCategoryId
(2-arg) does not filter active unlike its 1-arg sibling; fixed here rather than in
CsServiceImpl because that overload has ~25 other call sites where dropping inactive
users would change report scoping. |
|