| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37546 |
45 m |
amit |
/trunk/profitmandi-fofo/src/ |
web offer sync: compose detailed text from the parsed offer
detailedText is now built from benefit_timing + offer_benefit + offer_bank instead
of copying the circular's line:
Instant cashback. Rs.4,000 on Credit Card EMI; Rs.3,000 on Credit Card Full
Swipe. Banks: Axis Bank, ICICI Bank, State Bank of India (credit cards)
Every payment mode is always named, even when the circular's prose is terse
('10% CC EMI'), and the amounts come from offer_benefit - the authoritative
per-mode source. CC/DC cannot leak here at all, because the mode codes expand
natively rather than being patched by find-and-replace.
Three cases that would otherwise read badly:
- 21 offers carry NO benefit (circular cell 'NA', timing NONE). They are tenure-only
offers, so they read 'No-cost EMI. No cashback.' rather than showing a blank badge.
- The bank columns often list a bank under both card types while only one carries a
benefit. Card types shown are restricted to those actually paid on, or the text
would imply a debit offer that does not exist.
- benefit_timing UPI and NONE are not timings. Nothing is asserted rather than
inventing one.
smallText keeps the circular's short line - that column is only VARCHAR(256) and the
composed detail runs past it. One flowing paragraph, no line breaks, since the badge
may not render them.
Tests 8 -> 14. |
|
| 37545 |
45 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/ |
web offer sync: read benefits and banks for the composed detail text
selectBenefits and selectBanks, keyed by offer id and fetched once per circular
rather than per offer - 259 offers would otherwise be 518 extra round trips.
The main query now also carries offer_id, benefit_timing and all_banks.
Bank read takes INCLUDE rows only: an EXCLUDE is meaningful only when all_banks=1,
and such an offer is described as 'All banks' rather than by listing an exclusion a
partner cannot act on. |
|
| 37544 |
3 h 45 m |
amit |
/trunk/profitmandi-fofo/src/ |
web offer sync: expand CC and DC to Credit Card and Debit Card
The circular writes 'Rs.4000 Cashback on CC EMI'; a partner reading the badge should
see 'Credit Card EMI'. Applied to the title and the small/detailed text together, so
a badge and its detail never disagree.
Word-bounded and applied BEFORE truncation: an expansion is never cut in half, and
letters inside a word are untouched - the circular's cells carry strings like
'X300 Ext Kit' and 'ACCESSORIES', which an unbounded replace would corrupt.
On Sep'26 this affects 155 of 259 descriptions for CC and 48 for DC.
Two existing expectations updated to the new wording, and two tests added: one for
the expansion, one asserting DCX and ACCESSORIES survive intact. |
|
| 37543 |
8 h 13 m |
amit |
/trunk/profitmandi-fofo/src/main/ |
receive debit note: resolve the DOA section from the declared condition, not from a change
The condition dropdown renders with the partner's declared value already selected, so
a declared BAD - the ordinary DOA case - fired no change event and the DOA certificate
radios stayed hidden. The operator could not supply a certificate, and receiveDebitNoteItems
then refused the receipt for a missing one, making those debit notes unreceivable.
applyDeclaredConditions seeds each dropdown from the row's data-declared and settles the
dependent sections on load; the show/hide logic moves out of the change handler into
syncReceiveConditionState, which reads the current state of the form rather than whatever
was last touched. The change handler now calls the same function.
The server-side 'selected' stays as a fallback: without it a declared BAD would present as
GOOD if the script failed to load, and the server reads that difference as the warehouse
disagreeing with the partner, which rejects the whole debit note.
jsVersion 417 -> 418. |
|
| 37542 |
1 d 2 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/enumuration/onBorading/onBoardingFormEnums/ |
loi process added, revival and code changes process |
|
| 37541 |
1 d 2 h |
ranu |
/trunk/ |
loi process added, revival and code changes process |
|
| 37540 |
1 d 2 h |
ranu |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/service/ |
loi process added, revival and code changes process |
|
| 37539 |
1 d 7 h |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
Fixed mail sender everywhere |
|
| 37538 |
3 d 14 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. |
|
| 37537 |
3 d 21 h |
amit |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ |
carlcare activation: retry a transient failure once before giving up
One retry after a 1.5s backoff - long enough to clear the far end's rate window,
short enough to still fit inside a scheduler tick. A transient network blip was
otherwise recorded as a hard activation failure for that IMEI. |
|
| 37536 |
3 d 21 h |
amit |
/trunk/profitmandi-fofo/src/main/ |
purchase return: order the invoice-return queue by what still needs doing
A return with no debit note sorts first - it is the one still owing an action -
and the screen reflects that ordering. Also refuses the cancel path when any order
on the invoice is in a state that must not be cancelled. |
|
| 37535 |
3 d 21 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
purchase return: guard invoice cancellation, and surface rejected-with-DN returns
PurchaseReturnServiceImpl gains assertInvoiceNotCancelled and assertNotGrnd, so a
cancellation is refused when the invoice is already cancelled or the goods have been
GRN'd - a return cannot be undone once the stock has been received in.
PurchaseReturnOrderRepositoryImpl also counts returns that were rejected but never
acknowledged by the retailer while carrying a debit note, which otherwise fell out
of the pending queue despite still owing an action. |
|
| 37534 |
4 d 18 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/ |
loi process added, revival and code changes process |
|
| 37533 |
4 d 18 h |
ranu |
/trunk/ |
loi process added, revival and code changes process |
|
| 37532 |
5 d 2 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. |
|
| 37531 |
5 d 2 h |
amit |
/trunk/profitmandi-fofo/src/ |
offer circular: stop letter-led model names inheriting the previous variant
A part that is ONLY a memory spec inherits the preceding model name, because Oppo
writes 'RENO 15 PRO 256GB, 512GB' and the second part is not a product. The pattern
matched too loosely: the optional unit group matched the FIRST letter of a model
name and the rest fell through the trailing character class, so 'G06, G37, G37
Power' inherited its way to 'G06 G37' - two Motorola phones fused into one entity
that matches no SKU, costing G37 its cashback on five offers.
Requiring a leading digit makes it a memory spec rather than anything that merely
contains G/T and digits. Realme 'GT 7' matches the same way and survived only
because it never follows a comma.
Same root cause as the word-boundary guards on CAPACITY and MEMORY_PAIR: a digit
glued to letters belongs to the model name.
ProductNamesTest: 11 -> 12, covering 'G06, G37, G37 Power' and 'GT 7T, GT 7'. |
|
| 37530 |
5 d 2 h |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
purchase return: use the auto-approve check on invoice cancellation
Calls GstProService.isCancellableWithoutApproval (r37529) so a DC invoice, or an
unshipped order whose IRN is still cancellable, skips the approval step. |
|
| 37529 |
5 d 2 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. |
|
| 37528 |
5 d 2 h |
amit |
/trunk/profitmandi-fofo/src/ |
offer circular: apply the supersede rule on ingest (fofo)
A published circular now expires still-running offers from earlier circulars, and
deactivates the web offers they produced, so the same cashback is never current
twice. The converse also holds: re-ingesting an older circular while a newer one is
live leaves it expired rather than resurrecting it.
Older offers remain readable as reference - only status changes, never end_date.
Counts appear in the ingest summary as supersededOlderOffers / expiredAsSuperseded
and, on the web side, supersededOlderMonths / notPublishedSuperseded.
ScopeConfigTest's stub gains the two new CircularIngestRepository methods - the same
brittleness the scripts/offer_circular README notes for JdbcIngestRepo. |
|
| 37527 |
5 d 2 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/offers/ |
offer circular: a new month supersedes every older one
Publishing a circular expires still-running offers from earlier circulars, at the
offers level and again for the web offers they produced.
Why: the new circular restates whatever is still live, so leaving the old month
ACTIVE means the same cashback is current twice. Verified Aug'26 -> Sep'26: all 24
SKUs covered by August's four still-running Apple offers were carried into
September, six of them twice.
- expireOlderDocumentOffers: status ACTIVE -> EXPIRED for earlier documents.
end_date is deliberately NOT touched - it is what the OEM said, and older offers
stay readable as reference. They simply stop being current.
- expireIfSuperseded: the converse, so re-ingesting an OLD circular while a newer
one is live cannot resurrect it. With both, 'newest circular wins' holds whatever
order documents are ingested in.
- deactivateOlderPeriods / hasNewerPublishedPeriod do the same for dtr.web_offer.
Verified on real data in a rolled-back transaction: publishing Sep expired 165
still-ACTIVE Aug offers (many stale since the 18 Aug ingest), Sep did not expire
itself, and re-ingesting Aug while Sep is live self-expired its 4 revived offers. |
|