| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37842 |
1 d 21 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/ |
Fixed mail sender everywhere |
|
| 37841 |
1 d 21 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/ |
Fixed mail sender everywhere |
|
| 37816 |
6 d 21 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/ |
fix(einvoice): save the e-way bill whenever NIC returns EwbNo, not only with the EWBPPD note
GstProService saved EWB details only when InfoDtls held EWBPPD. NIC sends that
note (its pin-to-pin distance) only when we pass Distance=0, and the DUPIRN
get-by-IRN response carries no InfoDtls at all. So every partner with a
warehouse_partner_distance_mapping row, and every IRN recovered after a
timeout, lost its EWB although NIC had filed it (13 + 2 invoices in 30 days,
backfilled 2026-09-30), and a false "EWB Not Generated" mail was sent.
- Key on EwbNo; distance from EWBPPD, else the distance we sent, else none.
- Invoice PDF prints the "[distance]" suffix only when a distance is known
(was "[null]"). |
|
| 37809 |
7 d 22 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/ |
fix(einvoice): keep waiting for a fresh NIC auth token instead of giving up after one wait
getUsableAuthToken waited out an expiring token once and failed if NIC still
handed back one with under 60s of life. NSNOI14473 (2026-09-10) waited out a
token expiring 17:12:53, got one expiring 17:13:00 (6s left) and was parked at
irn_generated=0; the next invoice 5s later filed fine. Now waits up to 3 times,
each bounded by the remaining life of the token in hand. |
|
| 37801 |
8 d 17 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/pinelabs/ |
Disable Pine Labs offer discovery behind a config switch (default off)
Turns off the live Pine Labs per-item offer discovery on the user's
instruction. New pinelabs.offer.discovery.enabled, default FALSE, so the
integration is off in every environment unless a properties file opts in.
Gated at the single point all discovery funnels through
(PinelabsAffordabilityServiceImpl.discoverOffers), so one switch stops the
nightly cache loop, a single-item refresh and the /pinelabs/offers endpoint
without editing the six call sites. discoverOffersRawJson gated too.
cacheAllItemOffers returns before its listing query, since the loop costs
4,507 items and ~12 minutes of a cron thread even when every call is a no-op.
Degrades gracefully rather than breaking the product surface: an empty
OfferDiscoveryResponse is exactly what the existing catch block returns, and
getGroupedCachedOffersForItems already drops an entry with an empty issuer
map. The Redis cache is a 24h TTL, so live badges drain within a day rather
than vanishing mid-request.
The @Value carries a default deliberately — pinelabs.api.base.url and the
credentials carry none, so a missing key stops the whole context (the r37495
class of outage). A kill switch must never be able to do that.
SCOPE: offer discovery ONLY. Payment-gateway traffic (orders, refunds,
callbacks, webhooks) and offer create/validate/downpayment are untouched,
so no live money path changes behaviour.
@Scheduled on ScheduledSkeleton.fetchOffersByItem is intentionally left in
place — with the flag off it is one log line, and re-enabling stays a config
change rather than a code change.
Build: dao + web + cron + fofo compile, BUILD SUCCESSFUL. |
|
| 37790 |
8 d 22 h |
amit |
/trunk/profitmandi-dao/src/main/ |
Return refund as B2C when NIC refuses the buyer's GSTIN
A return whose credit note NIC refuses because the BUYER's GSTIN is
cancelled or invalid could not be settled at all: the approval threw, and
with it went the refund, the stock and the return rows (NSUPDL5176, Mobile
Hub, GSTIN 08DCUPD7948K1ZP). Where the invoice itself had never been filed
the return was instead refunded with no credit note at all, leaving the
refund undocumented.
Raising the note automatically is not the answer - it is Finance's call,
and the GST on a cancelled-GSTIN sale is not recoverable, so paying the
full value back loses it. Both flows therefore record the refusal and stop.
GstProService: getIrnFailureReason (NIC's refusal for an invoice),
isInvalidBuyerGstin (that refusal is about the buyer's registration -
deliberately NOT a state-code mismatch, which is a data error to fix and
retry, nor anything naming our own seller GSTIN) and briefIrnReason (one
plain-ASCII line of 128 chars; credit_note is latin1 and sql_mode is empty,
so anything else would store as '?').
PurchaseReturnServiceImpl: both the invoice-return and the debit-note
refund detect that refusal, record it through ReturnIrnFailureRecorder and
throw ReturnIrnGstinFailureException. The recorder commits in REQUIRES_NEW
because the approval it records is about to roll back, and it only inserts -
return_irn_failure carries no foreign key on purpose, since an FK check
would take a shared lock on the very PurchaseReturnOrder row the dying
transaction may still hold.
Finance may then settle the return as B2C for the rest of that calendar day:
refundAsB2c credits the value NET of GST in whole rupees (B2cRefundQuote,
HALF_UP per line, so the line table and the total always agree), restores
the stock and issues a local credit note for exactly that amount with no tax
on its lines, no IRN and NIC's reason recorded. The amount is fixed - the
caller must pass back the quoted figure - and a remark and explicit consent
are required. On a later day the option only reopens after a fresh approval
attempt is refused again, so NIC is always re-checked first.
Mails: every refusal notifies Accounts L2 and above; the B2C settlement
notifies them and the partner's Warehouse L1/L2, both tabulated.
The partner account statement is unaffected: it skips RETURNS notes and
credits returns from returnorderinfo, so the new notes cannot double-credit.
DEPLOY ORDER: apply sql/add_return_b2c_refund_20260921.sql BEFORE any war
built from this dao. CreditNote now maps irn_skip_reason and b2c, so every
credit-note read in web, fofo and cron fails until the columns exist.
Untested beyond compilation. |
|
| 37749 |
13 d 19 h |
vikas |
/trunk/ |
Upload directory and Data correction for lead |
|
| 37739 |
15 d 23 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/ |
GstProService: drop imports only the removed Perfios block used
HttpHostConnectException and JSONObject had no other use after r37736. |
|
| 37736 |
16 d 0 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/ |
Remove dead Perfios GST-return OTP block from GstProService
Commented-out since it was added; the Perfios UAT URL and auth key were the
only trace of that integration. Part of the dead-integrations cleanup
(r37730-37735). |
|
| 37731 |
16 d 0 h |
amit |
/trunk/profitmandi-dao/src/main/ |
Remove dead third-party integrations: dao
Nothing removed here had a live caller. No tables are touched.
- Toffee Insurance client + models, and the tofee.* keys in shared-*.properties
- Bharti Assist (BAG) service and its certificate/brand models. BagPlanModel
and PlanVariant stay in bharti/model: OneAssist and ICICI Lombard use them.
- Private, uncalled Toffee/BAG request builders in InsuranceServiceImpl
- Wiseapp insurance client and ZestResponseModel
- SmartPing client. CallDetailModel and PushCallLogModel move to
kommuno/model because the Knowlarity webhooks still parse them.
- SpiceMoney SSO (2-partner pilot), Thriwe stub + DTOs, DTDC/Shipsy (demo
URLs only), Blue Dart SOAP stubs, legacy Pine Labs v1 client
- FundFina pre-approval entity/repository, HyperTrack key entity/repository,
affiliate Click entity/repository
- Speqtra SMS constant; aramex.tracking.url keys
- PAYU PAY entry in payment-options.json
Gateway.MANDII and Gateway.FUNDFINA stay: historical fofo.payment rows. |
|
| 37656 |
20 d 20 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Point dao at the relocated KYC and SD Credit types (r37655)
Imports follow services.mandii -> services.kyc / services.sdcredit, and
RecordingService takes RawHttpResponse in place of MandiiResponse.
Gateway.MANDII is kept, with a comment saying why: it is persisted as a
string on FofoPayment.gateway and CreditAccount.gateway, and 740 historical
fofo.payment rows still carry it - removing the constant would make
Hibernate throw when reading them. |
|
| 37651 |
20 d 22 h |
vikas |
/trunk/ |
LMS click to call |
|
| 37647 |
21 d 15 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/ |
Invoice/DN return: file credit note at NIC only when the invoice IRN was filed
- GstProService.hasFiledIrn: invoice has a real IRN with ack date (DCs excluded)
- applyInvoiceReturnViaCreditNote: filed IRN -> CN + NIC CRN as before;
not filed + INTERNAL buyer -> CN issued locally, NIC skipped;
not filed + other buyer -> refund without CN, CN sequence untouched
- DN refund path: not filed + INTERNAL buyer -> local CN, NIC skipped
Fixes approval failing with 'Recipient GSTIN state code does not match' on
internal invoices whose IRN was never generated (NSPRJ41943, NSPRJ41950). |
|
| 37552 |
28 d 0 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
lead/knowlarity: stop a null lookup key from matching every row
selectByEquals maps a null VALUE to NO PREDICATE AT ALL rather than to "= null",
because GenericRepositoryImpl.prepareEqualPredicate skips null entries. So a null
lookup key does not miss -- it selects the whole table and dies on
NonUniqueResultException. Two live call paths were doing exactly that.
RecordingService.updateAgentCallLog read caller_id, which knowlarity has never sent
on push-call-log: a sample of 50 live webhooks contained it zero times. Every call
therefore ran selectByCallerId(null) -> "select every sip_master row" -> throw, and
the whole feed was discarded. 17 of those 50 were Connected calls with a real agent.
Resolve the agent from agent_number instead, which is the field that actually
identifies them and holds the sip_url; it arrives bare, sip:-prefixed, or as the
literals "False"/"None" when nobody picked up. caller_id is still honoured first in
case they ever start sending it. A payload naming no agent is INFO, and an agent
missing from sip_master is WARN (an ops fix, and per-agent, so an ERROR would
fingerprint into one GlitchTip issue per agent).
AuthRepositoryImpl.putEmailOrMobile had the same hole via Long.parseLong(null)
falling into the catch and putting a null email. selectByEmailOrMobile(null)
degenerated to "select all 405 users", and authenticate(null, hash) degenerated to
"does ANY user have this password hash", which would answer true. Both fail closed
today only as an accident of how many rows the table holds, so the guard goes on the
one path they share.
Fixes GlitchTip #58/#1324/#1335 (fofo, 281 events) and #10 (web). |
|
| 37538 |
32 d 7 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/ |
gstpro: a shipped delivery challan is a return, not a cancellation
Movement becomes the single discriminator for both document types. Nothing has
left the warehouse, so nothing happened and the document can be withdrawn; once
the goods have shipped the document records a movement that really occurred, and
the only honest reversal is an opposing document - a credit note through finance.
The clock is the only thing that differs. A tax invoice must also be inside its
24h IRN window, because past that NIC will not cancel the IRN. A delivery challan
has no IRN and no acknowledgement - every DC row carries a placeholder irn and a
null ack_date - so no clock applies to it: an unshipped challan stays withdrawable
whatever its age, and its e-way bill is cancelled on that path since nothing moved
under it.
Previously a DC short-circuited to cancellable regardless of shipping, which would
have voided challans whose goods were already in transit. |
|
| 37532 |
33 d 19 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/gstpro/ |
gstpro: do not cancel a DC e-way bill once the consignment has shipped
Three cases on cancelling a delivery-challan invoice:
- no EWB recorded: nothing to cancel at NIC
- already shipped: leave the EWB intact and void the challan locally. The goods
moved under that bill, so it is the record of a journey that happened; cancelling
would strip cover from it, and NIC refuses the cancel anyway once a bill has been
verified in transit. The return leg is a fresh movement needing its own EWB.
- never dispatched: cancel the EWB, since nothing moved under it.
Also reuses the orders already fetched for the shipped check rather than selecting
by invoice number twice. |
|
| 37529 |
33 d 19 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/ |
purchase return: auto-approve invoice cancellation where it is safe
GstProService.isCancellableWithoutApproval: a DC invoice cancels without approval;
anything else needs the order to be unshipped AND the IRN to still be cancellable.
PurchaseReturnServiceImpl marks the order INVOICE_CANCELLED with the refund actor,
timestamp and reason recorded, and sets each line item's returnQty to its full
quantity - a cancelled invoice returns everything on it.
Committed on behalf of the working copy; dao goes first so the method exists before
the fofo controller that calls it. |
|
| 37502 |
35 d 20 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/model/ |
sales target and achievement added cron and flags |
|
| 37501 |
35 d 21 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/model/ |
sales target and achievement added cron and flags |
|
| 37499 |
35 d 21 h |
ranu |
/trunk/ |
sales target and achievement added cron and flags |
|