| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37724 |
16 m |
amit |
/trunk/profitmandi-dao/src/main/resources/sql/ |
chore(hot-deals): restore 5 catalogs to OEM brand, add POCO M7 Plus 5G (4GB 128GB)_s to Hot Deal
Applied on hadb1 2026-09-18. Removed 1025252/1025253 (Samsung A06) and
1026085/1026403/1026408 (Refurbished iPhones) via _hot_deal_brand_freeze;
added catalog 1026568 (item 40832) with freeze + scope rows. |
|
| 37723 |
1 h 16 m |
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. |
|
| 37722 |
1 h 16 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Movement PO availability: list stock arriving into the sending warehouse, per PO
The popup showed in stock, promised and can-move, but not stock on its way in once it was
fully promised - so UP to Noida read 'in stock 0, promised 4, can move 0' with the 4 units
arriving on PO 54031 nowhere, and looked wrong. It now reads as a sum:
in stock + arriving - promised = can move.
- selectOpenInboundPurchases: open POs into the warehouse, one row per PO, same filter as the
pending-stock layer so the rows add up to the arriving total
- InternalMovementAvailabilityModel: arrivingTotal (before holds) + arriving breakup;
inbound (after holds) unchanged, still used by the refusal message
- describeAvailability (single + batch) carries both; batch doc: quantities are no longer
checked at bulk upload, the screen flags them and order creation enforces them |
|
| 37721 |
1 h 51 m |
amit |
/trunk/profitmandi-dao/src/ |
fix(orders): price each order by the cart line that asked for it, not the first line of its model
Orders were priced from one cart line per catalog, so colours of one model at different
prices all took an arbitrary one. Internal movements (cost layers) failed with WLT_1000
when the dearer line won and were silently under-billed when the cheaper one did.
fulfillQty now prices from the item's own line, newColorQty from the model's any-colour
line; same-price output is unchanged. Refuse the transaction if orders do not total the cart. |
|
| 37720 |
2 h 32 m |
ranu |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/ |
today po rbm view showing only for l7 and above |
|
| 37719 |
2 h 53 m |
amit |
/trunk/profitmandi-fofo/src/main/ |
feat(po): show only allocated warehouse as 'To Warehouse' on open PO list, drop generic buyer label |
|
| 37718 |
3 h 4 m |
amit |
/trunk/profitmandi-fofo/src/main/ |
feat(po): show allocated warehouse name and id under buyer on open PO list |
|
| 37717 |
3 h 44 m |
ranu |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/ |
today po rbm view showing only for l7 and above |
|
| 37716 |
5 h 4 m |
ranu |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/ |
today po rbm view showing only for l7 and above |
|
| 37715 |
13 h 24 m |
amit |
/trunk/ |
SD credit: stop read paths writing utilized_limit - the SD Credit admin page and V2 getLoans mutated managed SDCreditRequirement entities to show recomputed utilization, so Hibernate dirty-checking flushed an UPDATE per partner at commit; fofo now feeds the view from display maps and getLoans detaches before the display write, leaving output identical |
|
| 37714 |
13 h 26 m |
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 |
|
| 37713 |
13 h 26 m |
amit |
/trunk/profitmandi-dao/src/main/ |
fix(warehouse): record the order's own vendor when a receipt line carries no origin
- r37694 took the origin only from lineitem.origin_vendor_id, which exists on orders raised from that revision onward, so goods arriving on older open orders landed with a cost but no vendor - 282 rows on the first day
- A purchase from an outside vendor now falls back to that supplier; internal movements are unchanged and an unknowable origin still stays NULL
- sql/backfill_receipt_origin_20260918.sql repairs the 282 already received (run on prod 2026-09-18; bak warehouse._bak_receipt_origin_20260918); in-stock unknown 895 -> 648 |
|
| 37712 |
13 h 29 m |
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. |
|
| 37711 |
13 h 36 m |
amit |
/trunk/ |
Bulk-uploaded PO rows show the same availability breakdown as hand-picked ones
A row added by hand showed what the warehouse holds, what older orders have promised and how many
units the order could take; the same row arriving from a bulk upload showed none of it. The file
was the one place the numbers behind a quantity were hidden, which is the case where a mistake is
least visible and hardest to unpick afterwards.
describeAvailability now also answers for a list of items. Both reads it needs already took a
list, so a whole file costs the same two queries a single item does rather than two per row. An
item the warehouse holds nothing of is left out of the result instead of failing the upload - its
quantity is still checked when the order is priced, and the row simply shows no breakdown.
The single-item and batch paths build their answer from one shared method, so the two cannot drift
apart, and the screen reuses the renderer it already had. |
|
| 37710 |
13 h 40 m |
amit |
/trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/warehouse/ |
Closing a movement PO now cancels its orders, and refuses if any has already shipped
A movement is a purchase order and a transaction raised as one, but closing only ever ended the
PO. Its orders stayed live, still able to dispatch stock against an order nobody was going to
receive - the same split that let PO/07-26/52029 ship and invoice goods its PO could never take.
r37709 closed the PO when the last order was cancelled; this is the other direction.
Before cancelling anything it checks every order on the transaction. If one has moved past being
submitted for processing its stock is billed or already gone, and cancelling would write off a
movement that physically happened - so the close is refused, naming the order and its status,
rather than quietly reversing a real dispatch. Rare, but not impossible.
External vendor POs are untouched: they carry no transaction, so the check returns immediately. |
|
| 37709 |
13 h 53 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/ |
Cancelling a movement's last order now closes its purchase order
An internal movement is raised as a purchase order and a transaction together, but only the
transaction was ever cancelled. The PO stayed open and read as live work until the auto-close
sweep aged it out days later - and that sweep writes CLOSED, which is what a PO that actually
received its stock gets. Eight movements raised between 15 and 17 September sat this way, 59
units and Rs 10.68 lakh, every one cancelled the same day it was raised because the model or
colour was discontinued.
refundOrder now pre-closes the movement PO once every order on its transaction is refunded -
every one, because a transaction can carry several and the movement is only over when the last
goes. PRECLOSED, not CLOSED: nothing was received, and the difference is what keeps it
distinguishable from a real completion in every report that reads the status.
Refunds reaching here are already validated as never billed, so no dispatched stock is involved
and nothing is closed out from under stock in transit. Both lookups it needs already existed. |
|
| 37708 |
14 h 5 m |
amit |
/trunk/profitmandi-dao/src/main/resources/sql/ |
Migration: state the algorithm and lock mode, and why it runs before the release
hadb1 is MySQL 5.7, so adding a column rebuilds the table rather than only touching metadata.
At ~53k rows that is seconds and InnoDB permits concurrent reads and writes throughout, but
ALGORITHM/LOCK are now stated explicitly so it fails loudly rather than quietly taking a table
lock if that ever stops holding. |
|
| 37707 |
14 h 10 m |
amit |
/trunk/profitmandi-fofo/src/main/ |
GRN price mismatch: say which PO the invoice will be received against, and what to do if it closes first
Resolving a price mismatch discards the PO line and raises a replacement dated to the invoice. That
replacement is what the invoice is received against, so it is the one that has to stay open long
enough for the stock to arrive - and it closes on its own after four days for a movement, six for a
vendor order. Until now nothing said so: the GRN simply stopped matching and the correction sat
holding stock that had already arrived.
The confirmation now states what is about to happen and what to do if the stock lands late, and the
request screen explains what Po Id is. Reopening is offered only where it exists - a movement can be
reopened from Purchase Orders, a vendor order cannot and needs a fresh PO. |
|
| 37706 |
14 h 11 m |
amit |
/trunk/ |
cart: take the cart row before any line, to break a lock-ordering deadlock
InnoDB was rolling back cart edits with "Deadlock found when trying to get lock"
(GlitchTip #53, 27 deadlocks) and losing others to OptimisticLockException
"actual row count: 0; expected: 1" (11 issues, 42 events). Both are the same cause.
Two request paths took the same two rows in OPPOSITE orders. Adding a line INSERTs
into user.line, and line_cart_id_fk shared-locks the parent cart FIRST, line second.
Validation/hydration mutated the line rows FIRST and wrote cart.total_price second.
Run those concurrently on one cart and it is a cycle. Caught in the act on prod:
T1: INSERT user.line (cart_id=175180781) -> holds S on cart, waits S on line
T2: UPDATE user.cart SET total_price=269340.0, version=175 WHERE version=174
-> holds X on line, waits X on cart
*** WE ROLL BACK TRANSACTION (1)
Fix is to give every mutating path one order: cart, then lines. CartRepository gains
selectByIdForUpdate, and it is called as the first statement of each path that writes
a cart line. Re-taking it inside one request is a no-op.
A lock-ordering fix is all-or-nothing -- one path in the wrong order is enough to
re-form the cycle -- so this covers ALL TEN cart-line writers, not just the two that
happened to show up in the stack traces: createCartItem, clearCart, getCartValidation,
addItemsToCart (x2), addShoppingBag, validateForOpen (x2) and V2BillingController's
bind/unbindInsurance. The audit is worth re-running before adding another writer.
Note validateForOpen and getCartValidation WRITE despite their names (they correct
cart_line quantity/price and roll up cart.total_price), which is why a "validate" call
was ever holding write locks. The lock is placed accordingly; making those genuinely
read-only is a separate, larger change.
This also serialises concurrent edits to the SAME cart, which is what the @Version
column on Cart was already trying and failing to express. Different carts are
different rows, so there is no cost across partners. |
|
| 37705 |
14 h 11 m |
amit |
/trunk/profitmandi-fofo/src/main/ |
PO list: show the transaction id so a movement can be found from the invoice being received
An internal movement is raised as a transaction, so the invoice on the GRN desk leads straight back to its PO
through that id. The list is a DataTable, so having the column makes it searchable - which is how someone finds
the PO to reopen when a receipt arrives after auto-close, instead of hunting through date ranges.
Placed after Status so existing column positions are unchanged. |
|