| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37851 |
2 d 4 h |
amit |
/trunk/profitmandi-fofo/src/ |
fix(warehouse): warehouse partner drill-down lists ACTIVE warehouses instead of forcing 7573; courier/rider admin default warehouse 13368; MovementPurchaseOrderSplitTest uses splitByWarehouseAndCost (renamed in r37830, fofo tests compile again) |
|
| 37818 |
7 d 7 h |
amit |
/trunk/profitmandi-fofo/src/ |
feat(movement): allow full movable qty on PO screen, split raised as separate POs
- Cap the movement quantity at everything that can move; stock at more than one cost is
raised as one PO per cost on create (dao r37817). Note replaces 'raise a separate PO'.
- Tests: split by cost, multi-item PO grouping, same-warehouse refusal, shelf before arriving.
- jsVersion 440. |
|
| 37807 |
8 d 10 h |
amit |
/trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/inventory/ |
test(returns): B2C settlement after a GSTIN refusal, end to end
ReturnB2cRefundTest (Spring context, local dev DB, invoice NSNOI5746) covers
the r37790 flow: the quote is the value net of GST (33,439 -> 28,338); a
refused approval refunds nothing and records the attempt in its own
transaction; a wrongly typed amount and a missing remark or consent are
refused; settling as B2C refunds net of GST and issues a local credit note.
Seeded data rolls back; the refusal row it must commit is cleaned up by the
test. 5/5 pass. |
|
| 37780 |
12 d 10 h |
amit |
/trunk/profitmandi-fofo/src/ |
feat(partner-access): demo partner access page + validation
- Demo Partner Access page (Admin Control): grant partners to a Sales person,
list and revoke active grants; server-guarded by canManage
- Partner access dropdown: position partners + active demo partners "(Demo)";
shared cached mapping is copied, never mutated
- /login-as-partner-readonly: partner must be in caller's positions or demo
grants (was unchecked; Partner access is its only caller)
- /mobileapp?emailId=: Sales position holders get the partner app token only
for position/demo partners; other admins (Partner Info) unchanged
- DemoPartnerAccessTest (5, local DB, rolled back)
- jsVersion 437
Needs dao r37779 and migration_demo_partner_access.sql applied. |
|
| 37777 |
13 d 3 h |
amit |
/trunk/profitmandi-fofo/src/ |
returns: finance endpoint to reverse a return whose goods never reached the warehouse
PUT /return/reverse?imei=&reason=&dryRun= calls ReturnReversalService (r37776) for one
IMEI. Finance only, same canRefund gate as the refund it undoes, and dryRun defaults to
true so a call without it reports the plan and writes nothing.
ReturnReversalTest covers the four cases against the local database with NIC on the
sandbox: the dry run writes nothing, a note past its 24h window issues a DBN and undoes
every effect of the refund (warehouse scan and stock, partner stock and offers, order
status, wallet, return item, debit note, audit row), a note inside the window has its IRN
cancelled and drops out of the statement, and bad input or a second reversal is refused.
Run it as `gradle :test --tests ...` - without the colon the filter also reaches
profitmandi-common and fails with "No tests found". |
|
| 37744 |
14 d 11 h |
amit |
/trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/ |
test(warehouse): raising a movement order stamps the line with the stock's cost and vendor
Covers the last untested link in the cost-layer chain: PurchaseOrderServiceImpl writing lineitem.origin_vendor_id and the line price, which is what GRN copies onto received stock. |
|
| 37723 |
19 d 6 h |
amit |
/trunk/profitmandi-fofo/src/ |
Bulk-uploaded movement rows are validated on screen; popup shows arriving stock per PO
Bulk upload only fills the PO screen - the PO is created from the screen. It used to price
with resolvePrices(qty), so one row over what could move rejected the whole file. It now prices
from describeAvailability (same cost layer order creation uses) and never refuses on quantity:
over-cap rows turn red on render, createPO blocks while any row is red and lists them, and
the server checks again on create. An item with no stock and nothing arriving still fails
the upload (nothing to price).
Popup reads in stock + arriving (per PO, <- supplier) - promised (per PO) = can move; the
'Of these, still to arrive' line is gone. Tests for the Oppo A6 UP->Noida case. jsVersion 433.
Needs dao r37722. |
|
| 37714 |
19 d 19 h |
amit |
/trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/ |
test(warehouse): receiving on an order raised before lines carried an origin still records the vendor |
|
| 37712 |
19 d 19 h |
amit |
/trunk/profitmandi-fofo/src/test/ |
Fix the fofo test profile, which had been failing every context-loading test
The test resources carry their own META-INF/dev.properties and it shadows the main one on the
classpath, so anything missing from it is simply unresolvable when a context is built for a test.
It had drifted 23 keys behind - among them prod - and a single unresolvable placeholder stops the
whole context. Every test that loads one failed on mailOutboxService with 'Could not resolve
placeholder prod', which read like a broken bean and was really a stale file. Missing keys copied
from the dev profile.
InventoryCostLayerTest could then run for the first time since, and two of its cases still
described the old rules. Expected receipts can now be ordered against, so the inbound case asserts
a price rather than a refusal. A line stops reserving stock once its order moves past being
submitted for processing, so the raw unfulfilled quantity is now an upper bound: the held figure is
checked against what the commitments query reports, rather than by restating its SQL in the test.
7 of 7 pass. |
|
| 37701 |
19 d 23 h |
amit |
/trunk/profitmandi-fofo/src/ |
PO create: expected stock counts toward the quantity, popover wording follows
Stock still to arrive is now part of what the order can take, so the breakdown reports it as a
qualifier on that number rather than as something set aside - 'Of these, still to arrive' instead
of 'On the way in (not yet received)', which read as though it could not be ordered.
Tests follow the two rule changes: expected receipts can be ordered against, a quantity beyond
what is held and expected together is still refused and says so, and availability counts expected
receipts toward what can move. 21 tests pass. |
|
| 37697 |
20 d 1 h |
amit |
/trunk/profitmandi-fofo/src/ |
PO create: show what can move, and which orders hold the rest, while the quantity is typed
Picking an item on a movement order already called getPricing, which read the sending
warehouse's stock and returned only a price. It now returns the availability too, so the row
can show it: an info marker beside the quantity box opens the breakdown - in stock, promised
with each holding order named by PO number and date, anything still arriving, and the quantity
this order can take.
The quantity box flags the moment what is typed passes that cap, so it is corrected before
submitting rather than after being refused. The marker turns amber when stock is partly
promised and red when none can move.
Outside vendors are unaffected: their pricing response carries no availability and their rows
are left exactly as they were. jsVersion bumped so the screen picks up the new script.
Tests cover the four cases that matter: what can move with orders named, zero movable reported
rather than refused, this order's cap kept separate from what the warehouse holds when stock
came in at two costs, and a warehouse holding none of the item still refusing. |
|
| 37695 |
20 d 5 h |
amit |
/trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/ |
test(warehouse): cost layer tests; update movement tests for cost-based allocation
- InventoryCostLayerTest: local-DB tests for layers vs stock on hand, movement priced at recorded cost, refusal across costs, promised stock held back, pending inbound offered but not dispatchable, and GRN recording vendor and cost
- InternalMovementPricingServiceTest: layers now keyed by cost, so same-cost stock moves together and a different cost needs its own order
- BillingPricingServiceTest: compare against recorded origins rather than the serial-trace source |
|
| 37651 |
21 d 8 h |
vikas |
/trunk/ |
LMS click to call |
|
| 37637 |
22 d 6 h |
amit |
/trunk/profitmandi-fofo/src/ |
feat(pricing): log tag_listing price changes; reference TP instead of vendoritempricing in price drop and tag listing
- Add Pricing and price drop set DP/MOP/MRP via TagListingPriceService (logged with user; price drop logs carry price_drop_id)
- Price drop no longer writes vendoritempricing or vendor catalog pricing; old TP and prefill TP from reference TP
- Tag listing download TP from reference TP; drop unused VendorItemPricingRepository
- TagListingPricingTest: local-DB tests for the price log, reference TP and internal supplier guard |
|
| 37626 |
23 d 5 h |
amit |
/trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/ |
test(billing): assert internal transfer and billing resolve the same external origin vendor |
|
| 37623 |
23 d 6 h |
amit |
/trunk/profitmandi-fofo/src/ |
feat(price-drop): auto-approve price drop DP/MOP into external vendor catalog pricing
- PriceDropController calls VendorCatalogPricingService.applyPriceDrop with the affected date and logged-in user
- BillingPricingServiceTest: local-DB integration tests (rolled back) for origin-based billing prices, catalog fallback and re-billed orders |
|
| 37611 |
24 d 22 h |
amit |
/trunk/profitmandi-fofo/src/test/java/com/spice/profitmandi/service/warehouse/ |
Pin the unrecorded-stock behaviour
Covers the shape behind the 2026-09-12 bulk-upload failures: an item with some stock
traceable to a vendor and some with no recorded origin must move in one order, at the
traceable stock's price. Two genuinely different vendors must still refuse.
Also pins that no refusal message quotes a zero price from either side - including when the
oldest stock is itself the unrecorded pile, which is how 'at 0.00 each' reached users.
Requires profitmandi-dao r37610. |
|
| 37604 |
25 d 7 h |
amit |
/trunk/profitmandi-fofo/src/ |
Show the derived movement price when building an internal purchase order
Both places a price reaches a purchase order now use the movement price for internal
suppliers: the single lookup as an item is added on screen, and the per-item resolution
behind a bulk upload, which does the whole file in one pass instead of loading a circular
the sending warehouse does not have.
Removes addVendorPricingIfMissing, which fired only when someone typed a numeric item id
into the search box, and only for Samsung or non-handsets, writing permanent approved
pricing rows onto the internal supplier from a hardcoded source vendor. Bulk upload never
called it at all, which is why the same item could be added on screen but rejected in a
file.
Tests cover what is decided once origins are known - drawing the oldest stock first,
refusing a quantity that spans two original vendors while naming how many can move and
asking for a separate order, refusing an unmapped supplier, and falling back to the catalog
without ever recording an inferred vendor as though it were known.
Requires profitmandi-dao r37603. |
|
| 37580 |
27 d 9 h |
amit |
/trunk/ |
web offer: state an EMI scheme the circular gave without months
Rs.2,500 on Credit Card EMI (CIB) with IDFC First Bank, Kotak Mahindra Bank
52 Sep'26 offers have a bare 'CIB' tenure cell - the circular names the EMI type and
gives no months. TenureParser correctly yields no tenure row for a cell with no digits,
so the type vanished and the badge said only 'on Credit Card EMI'. Every one of those
52 carries a cashback, so it was 52 offers' worth of SKUs silent about the EMI they
apply to.
The type is stated because the circular stated it. The MONTHS are not invented,
because it did not give them - the same line the CIB expansion was left on.
Read from offer_raw_row.col_emi_tenure rather than stored: 'scheme, no month' is not a
tenure, and offer_tenure.tenure_months is NOT NULL, so persisting it would mean a fake
0 row standing for a fact that is not a tenure.
Only ever attached to an EMI mode, and real tenures always win over the bare code.
ModelOfferTest 8 -> 11. |
|
| 37579 |
27 d 10 h |
amit |
/trunk/profitmandi-fofo/src/ |
web offer: one badge per model, consolidating everything the circular grants it
Edge 60 Pro 12+256 carried five badges - a Full Swipe cashback, an EMI cashback and
three EMI schemes - and the partner's card listed all five. It now carries one:
SEPTEMBER 2026 Motorola Cashback Offer-2,500 On Credit Card EMI
& 2,000 On Credit Card Full Swipe
Models whose consolidated terms are IDENTICAL share a badge, so 314 models collapse to
~107 rows while every model still appears in exactly one.
Rules, from the taxonomy: any model has cashback on Full Swipe and/or EMI, instant or
deferred, plus NCE/LCE/CIB with tenures, and any of it may differ per bank.
- 'Upto' only where a mode carries several values - which is what per-bank pricing
looks like. One value is stated plainly.
- Highest value first.
- Banks ride with each line only when they DIFFER; one shared set is hoisted to a
single trailing 'Banks:' line. A third of models need the per-line form.
- An amount whose window is narrower than the badge's states its own end date. Apple
1025780 pays Rs.6,000 to the 16th then Rs.4,000 to the 26th; without this the badge
would advertise Rs.6,000 for ten days it is not available.
⚠️ Banks and tenures belong to the OFFER a line came from, never to the model. On Edge
60 Pro the no-cost EMI is ICICI on 3 and 6 months but SBI on 3 only, and the EMI
cashback is IDFC/Kotak with no tenure at all. Attaching the model's tenures to its
cashback would promise no-cost EMI on a bank that never offered it. This also corrects
an earlier reading of mine that called the SBI 3-month line a duplicate of ICICI's -
it is a different bank, not noise.
New ModelOfferTest, 8 cases, every one taken from a real Sep'26 row. |
|