| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37543 |
2 h 59 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 |
21 h 17 m |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/enumuration/onBorading/onBoardingFormEnums/ |
loi process added, revival and code changes process |
|
| 37541 |
21 h 18 m |
ranu |
/trunk/ |
loi process added, revival and code changes process |
|
| 37540 |
21 h 20 m |
ranu |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/service/ |
loi process added, revival and code changes process |
|
| 37539 |
1 d 2 h |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/ |
Fixed mail sender everywhere |
|
| 37538 |
3 d 9 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 15 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 15 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 15 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 13 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/ |
loi process added, revival and code changes process |
|
| 37533 |
4 d 13 h |
ranu |
/trunk/ |
loi process added, revival and code changes process |
|
| 37532 |
4 d 20 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 |
4 d 20 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 |
4 d 20 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 |
4 d 20 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 |
4 d 20 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 |
4 d 20 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. |
|
| 37526 |
4 d 21 h |
amit |
/trunk/profitmandi-fofo/src/ |
offer circular: scope config screen, resolve screen, web offer sync (fofo)
Screens (each its own endpoint, under the OFFER CIRCULAR menu):
- /offerCircularScope - add/edit divisions, take a brand in or out of scope,
register label aliases. 'Remove' is in_scope=0 + a required reason, never a
DELETE: offer.division_id is an FK and the history would go with it.
- /offerCircularResolve - the product queue, split out of the review screen. The
editor was a <td colspan=6> pretending to be a form, which is why it never
aligned; it is now master-detail. Naming and Coverage are separate tabs because
an alias cannot answer a bundle at all - the coverage panel says so and offers
the two answers that ARE safe (ignore, or reclassify as naming).
Ingest:
- ScopeConfig resolves division aliases and carries the canonical label on
Decision. insertOffer and ProductAliases.find use it; offer_raw_row keeps the
verbatim label, being the source of truth for re-parsing.
- CircularIngestRunner publishes to dtr.web_offer after the document is marked
PUBLISHED, in its own transaction with exceptions swallowed - a circular that
parsed correctly must stay published even if the web sync fails.
Review screen:
- the ingest summary was a raw Map.toString() inside a nowrap span and ran off
the card; now parsed into chips with the drop reasons behind a disclosure.
jsVersion -> 417 (merged with r37525's 412; cssVersion 53 kept from that commit). |
|
| 37525 |
4 d 21 h |
amit |
/trunk/profitmandi-dao/src/ |
offer circular: division aliases, portal-editable scope, web offer sync (dao)
- division_alias support: CircularIngestRepository.selectDivisionAliases so an
alternate OEM label resolves onto an existing division instead of dropping the
rows as UNKNOWN. Both pdf_label columns are ALIASED - Hibernate discovers
native-query results by name and throws NonUniqueDiscoveredSqlAlias on a dup.
- OfferScopeRepository{,Impl}: write side for scope config (add/edit a division,
in_scope toggle, label aliases). Kept apart from OfferCurationRepository, whose
contract is limited to product_alias - a bad alias mismaps one product, a bad
scope change silently drops a whole brand.
- OfferCircularRepositoryImpl: label-side division join now resolves through
division_alias (dva), otherwise an UNPARSED row under an aliased label is hidden
by the inScopeOnly filter - exactly the rows the review screen exists to show.
Also isoDate(): period_month left as java.sql.Date serialised to epoch millis,
which an <input type=date> silently rejects, so the circular filter cleared
itself and every circular showed every row.
- WebOfferSyncRepository{,Impl} + migration: publish a parsed circular into
dtr.web_offer / web_offer_product. Anchored on (document, page, row) stored as
VALUES, never offers.offer.id, which is recreated on every re-ingest. source
defaults to MANUAL so the 3850 hand-typed rows are untouched; web_offer_sync_shadow
is what lets a human edit win over a later sync. |
|
| 37524 |
5 d 13 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/enumuration/onBorading/ |
loi process added, revival and code changes process |
|