| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37868 |
1 d 10 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/ |
fix(warehouse): return empty availability for empty item list
getAvailabilityToWarehouse / ToVendorWarehouse / ToVendorWarehouseToBill
passed an empty itemIds list into the named query, producing "IN ()" and a
SQL syntax error (GlitchTip #20 /cart validation, #88 /om/orderByTransaction). |
|
| 37830 |
6 d 23 h |
amit |
/trunk/profitmandi-dao/src/ |
feat(movement): one PO per source vendor warehouse and cost - layers carry their GOOD/OURS vendor warehouse, orders are raised pinned to it, holds of pinned orders come off their own warehouse, billing takes units at the order's price first |
|
| 37753 |
15 d 6 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/ |
aging po approval process |
|
| 37752 |
15 d 6 h |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/ |
today po rbm view showing only for l7 and above |
|
| 37750 |
15 d 6 h |
ranu |
/trunk/ |
aging sku purchasing need to approval of niranjan kala sir |
|
| 37722 |
20 d 8 h |
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 |
|
| 37700 |
21 d 0 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Internal movement: order against expected stock, and stop reserving lines that can no longer ship
Two rules changed, both about stock that was being treated as unavailable when it is not.
Stock still to arrive now counts toward what a movement order can be raised for. A movement is
planned against what the warehouse will hold, so the order is raised now and dispatched once the
stock lands; previously a warehouse holding only inbound stock refused outright, even though the
receipt was already on an open order.
A purchase order line stops reserving stock once its own order moves past being submitted for
processing. Billed or shipped means the units have already come off the shelf; cancelled means
the line can never dispatch them. Holding either back a second time hid stock that was genuinely
free - on prod, 660 of 675 reserved units were on lines whose orders had already moved on. A line
whose order has not been raised at all is still a live promise and keeps its hold, and a line is
held only for the quantity still sitting in an in-process order, so a partly-shipped order
releases the rest.
priceFor and describeAvailability continue to read stock through one shared examine(), so what is
shown while choosing a quantity stays exactly what the order is created against. |
|
| 37696 |
21 d 3 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Internal movement: report what a warehouse can actually send, not just refuse on submit
The quantity a movement order can take was only discovered by submitting the order and being
refused. The stock reading that decides it already computed everything needed to say so in
advance - what is on the shelf, what older orders have promised, what is still arriving - and
then discarded it.
selectOpenOutboundCommitments returns those promises one row per order, with the PO number,
PO date and destination, instead of a single summed quantity. applyOutboundCommitments now
aggregates those rows and behaves exactly as before, so no extra query is run.
describeAvailability answers with the price plus that working. It shares one stock reading with
priceFor via examine(), so the cap shown while choosing a quantity and the cap enforced on
submit cannot drift apart. Unlike pricing it reports rather than refuses: stock that is entirely
promised comes back as zero movable with the orders holding it named, which is what lets someone
chase an abandoned order rather than only see a smaller number. |
|
| 37694 |
21 d 7 h |
amit |
/trunk/profitmandi-dao/src/main/ |
feat(warehouse): record where stock came from and what it cost; price internal movements at that cost
- inventoryItem.origin_vendor_id / receipt_unit_cost and lineitem.origin_vendor_id (sql/add_inventory_cost_layer_20260917.sql, applied on prod 2026-09-17 in 75s): GRN copies both from the PO line it arrived on, so origin survives any number of hops and non-serialised stock keeps it too. Unknowable origin stays NULL - never a guess, never an internal supplier
- A movement now moves stock at the cost it was received at, not the origin vendor's current catalog TP. Layers are grouped by cost; a quantity spanning two costs is refused with both numbers, since a PO line carries one price
- Stock already promised on open outbound movement orders is no longer offered again (176 item/warehouse pairs on prod are fully promised today)
- Stock on open inbound POs is offered for planning at that order's price and reported as 'on the way in', but cannot be dispatched until received; the PO item picker lists those items too
- Backfill: 4,010 of 4,646 in-stock rows on prod got origin and cost; 636 stay unknown and are priced from the latest approved external catalog price as before |
|
| 37625 |
24 d 6 h |
amit |
/trunk/profitmandi-dao/src/main/ |
fix(internal-movement): trace serial origin to the latest external purchase, matching billing
- resolveInternalMovementPrices orders the serial's external purchases newest first (was oldest), so transfers and billing name the same original vendor; no in-stock unit on prod changes (0 of 3,734)
- Restore resolveInternalMovementPrices javadoc onto its own method
- Add drop_internal_vendor_catalog_pricing_20260914.sql, as run on prod 2026-09-14 17:33 (15 New Spice internal suppliers; backups _bak_vcp/_bak_vcpl_internal_20260914) |
|
| 37622 |
24 d 8 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
feat(billing): price warehouse billing from the external supplier of the billed stock; auto-approve price drop DP/MOP into vendor catalog pricing
- BillingPricingService resolves TP/NLC per order from vendor_catalog_pricing of the most recent external supplier of the units scanned out (serial trace, else own external PO); units reversed by SALE_RET are ignored
- Falls back to the latest approved external catalog price when no supplier can be traced; vendorId stays the warehouse vendor
- addBillingDetailsForGrouppedOrders no longer reads vendoritempricing (removes NPE when the row is missing); order.vendorId set to the origin supplier
- VendorCatalogPricingService.applyPriceDrop writes approved pricing logs for external vendors with the price drop DP/MOP, keeping each vendor's TP on the effective date |
|
| 37609 |
26 d 7 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Offer the stock a warehouse actually holds when ordering from an internal supplier
The purchase order item picker listed whatever the supplier had vendor catalog pricing rows
for. For an outside vendor that is right - the order is for stock nobody holds yet, so their
catalogue is the only sensible list. For one of our own warehouses it is not: a movement can
only send stock that is standing there, and the pricing rows were never a statement about
stock. Vendor 275 was offering 6,845 items while Noida held 79; Delhi 6,637 against 330.
It also made the picker depend on data the movement no longer needs. Pricing for internal
suppliers is derived from the stock itself since r37603, so those rows are inert - but
clearing them emptied the picker completely, because selectVendorItems joins
VendorCatalogPricing to Item and an internal supplier then matched nothing.
Internal suppliers now list distinct items with currentQuantity > 0 in their mapped
warehouse. External suppliers are untouched and still list from vendor catalog pricing. |
|
| 37603 |
26 d 8 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Price internal warehouse movements from the stock's original vendor
Stock moving between our own warehouses was priced from the sending internal supplier's
own vendor catalog, which only ever holds prices copied from elsewhere - so every hop let
the price drift further from what the group actually paid, and a movement was blocked
outright whenever that supplier happened to have no row for the item.
It is now derived from the stock being moved: the original EXTERNAL vendor is established
per unit and that vendor's current catalog price is used. Origin is looked for in
descending order of certainty - the serial traced back to the external purchase that first
brought the unit in, then the unit's own inbound PO when that was external, both of which
are facts that survive any number of internal hops. Non-serialised stock that has already
moved internally has no recoverable origin at all, since fungible units carry no identity
and the movement records nothing linking the receiving row to its source, so those fall
back to the most recent externally approved price for the catalog and are never recorded
as though their vendor were known.
A purchase order carries one price per item, so an item can only move from one original
vendor at a time. Where a requested quantity would run past the oldest vendor's stock into
another's, this refuses and reports how many can move now and at what price, leaving the
second order to whoever is moving the stock, rather than averaging the two or silently
splitting the order. Each order therefore stays attributable to one vendor.
Receiving no longer validates price for these movements: both sides of the comparison come
from the same derivation, so a mismatch cannot mean anything. That also removes a null
dereference in GrnRequestServiceImpl, which assumed every supplier has a circular.
Removes addVendorPricingIfMissing, which wrote permanent approved pricing rows onto internal
suppliers sourced from hardcoded vendor 334 for Samsung or an arbitrary findFirst() vendor
otherwise, stamped with hardcoded auth ids. Those rows are now not just unnecessary but
harmful: they would pin a stale price that wins over the derived one.
Verified against live data: covers every unit in every warehouse with none unresolved,
agrees exactly with the origin join the FOCO/ImeiSupplierPricing report already runs in
production, and prices 12,305 of 13,589 units within 2% of what was actually paid.
Resolution takes 0.7ms for one item and 1.1ms for ten. |
|
| 36910 |
106 d 13 h |
amit |
/trunk/profitmandi-dao/src/main/ |
Internal PO: map created transaction to PO; block warehouse change for PO-mapped orders
- WarehousePurchaseOrder: add transactionId column + selectByTransactionId
- createOrderInternally returns txn id; createPurchaseOrder maps it onto the PO
- Block order.setWarehouseId for PO-mapped orders in changeFulfillmentWarehouse; cron moveOrders skips them
- Migration: add warehouse.purchaseorder.transactionId |
|
| 36568 |
145 d 11 h |
amit |
/trunk/ |
refactor: RTV - add local caching, batch queries, typed DTO, fix documentNumber overwrite and settledAmount validation |
|
| 36544 |
146 d 9 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/ |
Refactor RTV (Return to Vendor) flow: replace native SQL with repository/service methods, extract reusable helpers (resolvePurchase, resolveLineItem, markItemReturned, createPurchaseReturnEntity), fix availability bug by adding saholicInventoryService.reduceAvailability, validate returnability by currentQuantity>0 instead of lastScanType |
|
| 36318 |
171 d 6 h |
aman |
/trunk/ |
Fix:Migrate legacy Purchase Return flow (Report + Bulk Create + Debit Notes) into FOFO |
|
| 36316 |
171 d 6 h |
aman |
/trunk/ |
Fix:Migrate legacy Purchase Return flow (Report + Bulk Create + Debit Notes) into FOFO |
|
| 36309 |
172 d 1 h |
amit |
/trunk/profitmandi-dao/src/main/ |
Route phantom orders to per-region Dummy warehouse; complete applyColorChange rename
- Phantom allocations in getFulfillments route to the Dummy/GOOD/OURS warehouse under
vendor 40 for the partner's billing region. WarehouseServiceImpl.ensureDummyForBillingRegion
returns the existing Dummy or creates one on the fly. createVendorWarehouse hook auto-seeds
a Dummy when a new billing region's first warehouse is created.
- WarehouseRepository.selectByVendorBillingAndType supports the lookup.
- OrderService interface: rename notifyColorChange -> applyColorChange to match r36305's impl
rename (r36305 renamed only the impl, leaving trunk inconsistent).
- PurchaseOrderServiceImpl: remove auto-rebalance on PO receive. Real-wh rebalancing and
phantom-to-real binding are now ops-driven via the order billing UI
(changeFulfillmentWarehouse / applyColorChange / moveOrdersFulfilmentWarehouse).
- migration_dummy_warehouses.sql: idempotent seeding script for 14 Dummy/GOOD/OURS warehouses
under vendor 40, one per WAREHOUSE_MAP billing region that lacked one. Already applied to
hadb1 and local. |
|
| 36169 |
189 d 6 h |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/ |
Fix NonUniqueResult for duplicate serial numbers: use latest inventory entry for refurbished items |
|