Subversion Repositories SmartDukaan

Rev

Show changed files | Directory listing | RSS feed

Filtering Options

Rev Age Author Path Log message Diff
36528 1 d 8 h vikas /trunk/ Notifications APIs for marking notifications as read  
36519 2 d 11 h aman /trunk/ Fix:First Po  
36518 2 d 11 h aman /trunk/ Fix:Fix first po and edge case for bulk order  
36508 4 d 0 h ranu /trunk/ code committed for scheme and offers earning for v2  
36502 5 d 3 h amit /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ DN generation for cancelled MARGINS CNs + fix /A CN prefix extraction NPE

- Add generateDebitNotesForCancelled(List<String>) for explicit CN list
- Add selectByCreditNoteNumbers repository method
- Fix GstProService sandbox: use SANDBOX_GST_NUMBER before isGstEnabled check, sandbox buyer details
- Fix prefix extraction NPE for /A suffixed CN numbers (getCreditNotePdfModel, existingCNMap, extractPrefix)
 
36482 7 d 6 h vikas /trunk/ V2 Weekly feedback and All Brands API  
36471 9 d 6 h vikas /trunk/ V2 Profile Update APIs  
36464 9 d 13 h amit /trunk/ Add vendor pricing changes Excel download report on Vendor Price Circular page. Flat file with Vendor/Date/Model/CatalogId/TP/DP/MOP columns, filterable by vendor. Shows baseline pricing as of start date plus subsequent TP changes within period for all non-internal suppliers.  
36438 12 d 14 h amit /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ Fix SD Credit over-utilization: use live loan SUM + row lock + sanction guard

- blockLoan: use SELECT FOR UPDATE to prevent concurrent orders from both passing credit check
- processLoanRequest: replace stored utilized_limit counter with live SUM(pending_amount) from loan table
- processLoanRequest + getAvailableAmount: only add sanction amount if not already used today
- Prevents credit limit from going negative due to counter drift or race conditions
 
36437 12 d 14 h aman /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/ Fix  
36428 14 d 10 h aman /trunk/ Fix:Partner Stock Api  
36407 16 d 6 h amit /trunk/profitmandi-dao/src/main/ Sale-return reversal: cancellability gate, CN on approve, INV reject, ROI semantics

GstProService.isIrnCancellable(invoiceNumber): predicate extracted from
the inline 24h check used in cancelInvoiceGst, so callers outside the
service can decide branching without duplicating the rule. DC and no-IRN
cases return false — those paths use EWB cancel / credit-note issuance.

PurchaseReturnServiceImpl: split single-phase return-receive into
submitReceiptForApproval + applyReceipt. Submit persists per-item return
type on PurchaseReturnItem so apply (called inline on auto-approve, or
later from refundOrder when finance clicks Process Refund) can replay
the scan loop without the original itemReturnTypes map.

processInvoiceReturn(autoApprove=true) no longer creates a PRO. Routes
through new cancelInvoiceFully which calls gstProService.cancelInvoiceGst
(the canonical IRN-cancel path setting Order.status=INVOICE_CANCELLED)
and adds wallet credit + warehouse-stock restoration. Cancellations now
live on Order/EInvoiceDetails screens, not in the returns ledger —
matches standard ERP practice and the existing cancelInvoiceGst flow.

processInvoiceReturn(autoApprove=false) creates an INV-prefix PRO in
pending state and calls notifyFinanceApprovalPending (Finance L1+L2
emails resolved dynamically from PositionRepository).

approveInvoiceReturn now runs applyInvoiceReturnViaCreditNote — raises
local CreditNote + CreditNoteLine rows (sequential CN# from
SellerWarehouse), issues CRN at GST via generateCreditNoteIrn, restores
warehouse stock, populates ReturnOrderInfo (this path IS a customer
return without DN — ROI is the right anchor), credits wallet. Drops the
old applyInvoiceReturnEffects helper which mishandled both cancel and
return-via-CN as the same path.

rejectInvoiceReturn: new method for finance to reject pending INV PROs.
Sale stands — only stamps reject_timestamp/reject_remark. No inventory,
no wallet, no GST action, no ROI. Closes the gap where finance had
Approve as the only option on a pending INV PRO.

refundOrder gains a refund guard (PRO must exist, not refunded, not
rejected) and applyReceipt-if-needed at the top — Finance's existing
Process Refund button now drives approve+refund atomically.

PurchaseReturnOrderRepository.selectByWarehouseIdsAndDateRange: Hibernate
query for a date-range listing on /return/invoice (default last 30
days, limit 200).

@Transactional(rollbackFor=Exception.class) at class level —
ProfitMandiBusinessException is checked, so Spring's default rollback
didn't fire on guard failures, allowing partial commits. Closing that
silently broken behaviour.

LineItemImei N+1 fix: receiveDebitNoteItems / refundOrder / rejectReturn
each iterated orders calling selectByLineItemId per row. Switched to the
existing batch selectByLineItemIds(List).

Email template finance-receipt-approval-pending.vm and SQL migration
migration_imei_net_margin_modal_api.sql added (registers the
/getImeiNetMarginModal endpoint in dtr.api and grants access to the
roles that currently access /order).
 
36405 16 d 8 h amit /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ Fix duplicate SchemeInOut on concurrent GRN: SELECT FOR UPDATE on inventory_item before createSchemeInOut to serialise concurrent GRN calls per IMEI  
36403 16 d 11 h amit /trunk/profitmandi-dao/src/main/ Add catalog.catalog_monitor_type table, entity, and repository for per-catalog focused/normal monitor type tagging  
36399 16 d 11 h amit /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ Replace mailSender (SendGrid) with gmailRelaySender - SendGrid API key expired/revoked  
36397 16 d 11 h amit /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ Scheme item windowing: add startDate/endDate per scheme_item.

Each fofo.scheme_item row now carries an optional [start_date, end_date]
window so the same (scheme_id, catalog_id) pair can be applicable for
different date ranges. Backward compatible: NULL window = always active.

- SchemeItem entity: composite (schemeId, catalogId) PK -> surrogate
long id (IDENTITY), unique (catalog_id, scheme_id, start_date, end_date),
audit cols (updatedBy, updatedOn).
- Scheme + TagListing named queries: gated by
'(si.start_date is null or :onDate between si.start_date and si.end_date)'.
- SchemeItemRepository: + selectById, selectBySchemeId,
existsOverlapping (half-open, with self-exclude), selectItemsOutsideWindow.
- SchemeService: + updateSchemeItemWindow / addSchemeItemWithDates /
clampSchemeItems with containment + overlap validation; drop dead
getTotalMargin.
- SchemeServiceImpl.processSchemeOut: pin scheme resolution to each
IMEI's GRN billing date (Purchase -> Order.billingTimestamp via
PurchaseService.getBillingDateOfPurchase) instead of fofoOrder
createTimestamp, aligning OUT with the existing IN behaviour.
 
36376 19 d 9 h aman /trunk/ Feat:Cart Api Implementation  
36374 19 d 10 h ranu /trunk/ schemes and offer for v2 version  
36372 19 d 13 h amit /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ Wallet: SELECT FOR UPDATE on user_wallet mutations to close lost-update hole

addAmountToWallet/consumeAmountFromWallet(x2)/rollbackAmountFromWallet all
follow a read-modify-write pattern on user_wallet with no pessimistic lock
and no @Version, so two concurrent tx for the same partner both read the
same pre-snapshot amount, compute their own deltas, and commit - the second
UPDATE silently overwrites the first's credit/debit. user_wallet_history
still gets both rows, so balance drifts vs sum(history) with no exception.

Replaces the misnamed (and body-broken) selectByIdForUpdate - whose
implementation was a plain selectById, not a lock - with a new
selectByRetailerIdForUpdate that issues SELECT ... FOR UPDATE via
LockModeType.PESSIMISTIC_WRITE, mirroring the idiom already used in
GenericRepositoryImpl.selectByIdForUpdate and OrderRepositoryImpl.
Preserves the create-on-missing behavior of selectByRetailerId so
first-time partners keep working.

Switches the four read-modify-write call sites in WalletServiceImpl from
selectByRetailerId to the new locking variant. Read-only callers
(getUserWalletByUserId, getUserWalletHistoryByUserId, etc.) keep using
the non-locking selectByRetailerId - MVCC snapshot reads stay non-blocking
for display/statement endpoints.

Also drops the stale commented-out selectByIdForUpdate line in
rollbackAmountFromWallet and removes the broken method from the
UserWalletRepository interface / impl - it had zero live callers.

Blast radius: every write call to these three wallet methods now holds
an X-lock on the target user_wallet row for the rest of the outer tx.
Concurrent write tx for the same partner will briefly serialize at the
SELECT FOR UPDATE - correct serialization instead of silent drift.
Read-only traffic is unaffected (MVCC).
 
36371 19 d 14 h amit /trunk/ HDFC webhook: INSERT IGNORE on hdfc_payment to fix concurrent-duplicate 500 storm

Replaces persist() with a native INSERT IGNORE so concurrent same-UTR webhook
retries serialize on the unique-index check, and the loser gets a 0-row no-op
(warning, not exception). Outer @Transactional session stays clean, Spring
commits normally, HDFC sees 200 on both the winner (Success) and the loser
(Duplicate) - retry amplification ends.

Flow:
persist(hdfcPayment) -> insertIgnore(hdfcPayment) + selectByUtrNo(utr)
- inserted == 1: proceed with wallet / sidbi side-effects using fetched id
- inserted == 0: respond Duplicate, skip side-effects (owned by winning tx)
- defensive: log warn if insertIgnore returned 0 but selectByUtrNo finds
no row (could mean IGNORE swallowed a non-duplicate issue like truncation)

Also drops HdfcProcessingHelper (r36366) which used REQUIRES_NEW for the same
goal; that approach required a second JDBC connection and is no longer needed
with SQL-level idempotency.

Does NOT touch the wallet-side lost-update hole (user_wallet read-modify-write
without FOR UPDATE). That is a separate commit.
 

Show All