SmartDukaan – /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/

Rev 37845 – feat(warehouse): ACTIVE/SUSPENDED/INACTIVE status + label on sellerwarehouse replace WAREHOUSE_MAP - ...

amit — Mon, 05 Oct 2026 18:48:21 +0530

amit – 33 file(s) modified
feat(warehouse): ACTIVE/SUSPENDED/INACTIVE status + label on sellerwarehouse replace WAREHOUSE_MAP - BillingWarehouseService (active for dashboards, active+suspended for warehouse screens, names in every state, 5 min cache); setup service: guarded status change (no suspend while franchise stores or brand mapping route there, no close while stock/unshipped orders), rename, all-warehouse overview with usage; partner store assignable only to an active warehouse; daily stock alert for suspended/inactive warehouses to logistics/accounts top 2 staffed levels + leadership; dashboard warehouse list = active (replaces r37834 stock-holding loop); migration sellerwarehouse_status_display_name_20261005.sql (applied on hadb1)

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/transaction/SellerWarehouse.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/enumuration/warehouse/WarehouseStatus.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/warehouse/PhysicalWarehouseView.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/warehouse/WarehouseStockLine.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/warehouse/WarehouseUsage.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/dtr/FofoStoreRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/InventoryWarehouseRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/SaholicInventoryCISRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/SaholicInventoryCISRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/WarehouseRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/SellerWarehouseRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/SellerWarehouseRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/service/solr/FofoSolr.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/AdminUser.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/authentication/JWTUtil.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/offers/OfferServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/RbmTargetServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/TransactionServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/user/RetailerServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/BillingWarehouseService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/BillingWarehouseServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PoStockApprovalDigestServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PoStockApprovalServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/SuspendedWarehouseStockAlertService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/SuspendedWarehouseStockAlertServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseSetupService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseSetupServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseSetupValidator.java
+ /trunk/profitmandi-dao/src/main/resources/sql/sellerwarehouse_status_display_name_20261005.sql
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/warehouse/BillingWarehouseServiceImplTest.java
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/warehouse/SuspendedWarehouseStockAlertServiceImplTest.java
~ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/warehouse/WarehouseSetupServiceImplTest.java

Rev 37830 – feat(movement): one PO per source vendor warehouse and cost - ...

amit — Fri, 02 Oct 2026 01:53:51 +0530

amit – 9 file(s) modified
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

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementAllocationModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementPriceModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/TransactionService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/TransactionServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseServiceImpl.java
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/warehouse/MovementPoSplitTest.java

Rev 37826 – feat(warehouse): previewMovementPurchaseOrders - read-only view of the POs an internal ...

amit — Fri, 02 Oct 2026 00:03:38 +0530

amit – 2 file(s) modified
feat(warehouse): previewMovementPurchaseOrders - read-only view of the POs an internal movement would be raised as (margin-scheme apart, one per cost)

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 37822 – feat(warehouse): physical warehouse setup service, supplier mapping PO guard, address ...

amit — Thu, 01 Oct 2026 21:06:34 +0530

amit – 24 file(s) modified
feat(warehouse): physical warehouse setup service, supplier mapping PO guard, address active flag

- WarehouseSetupService + WarehouseSetupValidator: create seller (state from GSTIN,
unique label/GSTIN), address master (city stored last, 6-digit pin, contact),
physical warehouse (OURS/BAD vendor 40 + Dummy/G + sellerwarehouse + mapping in
one transaction), activate/deactivate (sellerwarehouse.is_active), remap address
with internal store sync. Limits follow column sizes (sql_mode is empty).
- WarehouseAddressMaster.active: only active addresses are offered for assignment.
Migration sql/20261001_warehouseaddressmaster_active.sql (applied on hadb1).
- PO guard: createPurchaseOrder refuses a supplier with no OURS/GOOD vendor
warehouse at the destination (GRN could never receive it).
InventoryWarehouseRepository.hasGoodSupplierWarehouse / selectSupplierIdsWithGoodWarehouse
use existence checks; 67 pairs carry duplicate OURS/GOOD rows.
- SellerService.syncInternalStoreAddress(store); RetailerServiceImpl syncs an
INTERNAL store's address when it moves warehouse or becomes internal.
- Record of 2026-10-01 HR Gurugram setup SQL (seller 21, warehouses 13368/13370/13372).
- Tests: WarehouseSetupValidatorTest (10), WarehouseSetupServiceImplTest (7).

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/transaction/WarehouseAddressMaster.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/warehouse/NewPhysicalWarehouseRequest.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/warehouse/NewSellerRequest.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/warehouse/NewWarehouseAddressRequest.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/warehouse/PhysicalWarehouseView.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/warehouse/WarehouseAddressView.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/InventoryWarehouseRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/InventoryWarehouseRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/WarehouseAddressMappingRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/WarehouseAddressMappingRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/SellerService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/SellerServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/user/RetailerServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseSetupService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseSetupServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseSetupValidator.java
+ /trunk/profitmandi-dao/src/main/resources/sql/20261001_delete_hrgn1715_hr_uk_store.sql
+ /trunk/profitmandi-dao/src/main/resources/sql/20261001_hr_gurugram_vendor_warehouses.sql
+ /trunk/profitmandi-dao/src/main/resources/sql/20261001_hr_gurugram_virtual_warehouses.sql
+ /trunk/profitmandi-dao/src/main/resources/sql/20261001_warehouseaddressmaster_active.sql
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/warehouse/WarehouseSetupServiceImplTest.java
+ /trunk/profitmandi-dao/src/test/java/com/spice/profitmandi/service/warehouse/WarehouseSetupValidatorTest.java

Rev 37817 – fix(movement): shelf stock before arriving, one PO per cost, close ...

amit — Wed, 30 Sep 2026 16:43:15 +0530

amit – 7 file(s) modified
fix(movement): shelf stock before arriving, one PO per cost, close PO on invoice cancel

- Internal movement fills from shelf stock before stock still arriving (a pending PO dated at
midnight ranked ahead of same-day receipts, pricing movements from units that never shipped).
- A quantity spanning stock at different costs is raised as one PO per cost at once instead of
being refused (first PO takes every item's oldest cost, the next the following cost).
- Refuse a movement from a warehouse to itself.
- Cancelling a movement's invoice/DC takes the order's qty off its PO and pre-closes it when
nothing is left open, as refunds already did.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementAvailabilityModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/OrderRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/OrderRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/PurchaseReturnServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 37776 – returns: reverse a refunded debit-note return whose goods never reached ...

amit — Thu, 24 Sep 2026 20:16:26 +0530

amit – 16 file(s) modified
returns: reverse a refunded debit-note return whose goods never reached the warehouse

Once a return was refunded nothing could undo it - rejectReturn refuses an already
refunded one - so a return booked and paid for goods that never arrived left phantom
warehouse stock, the unit missing from partner stock, the order marked returned, a
wallet credit and a filed credit note, with no way back.

ReturnReversalService.reverse(imei, reason, by, dryRun) undoes exactly one unit:
the warehouse return scan (row deleted so a genuine return later is not rejected as a
duplicate) and the stock it added, partner stock with its schemes/price drop/offers,
the order's return quantity and status, the wallet refund as a REVERSAL entry, and the
return item / debit note. Guards refuse anything that has moved since the refund, and a
dry run reports the plan without writing.

The credit note follows movement and the NIC clock: inside the 24h window, and only
when the note credits nothing but this unit, its IRN is cancelled and the note marked
cancelled; past it a DBN with its own IRN is issued against the note
(CreditNoteService.issueReturnReversalDebitNote, stored as CN_CANCELLATION with no
margin month so the statement does not show it twice - the wallet REVERSAL is the
statement line); a note never filed at NIC is voided locally. Every local write happens
first and NIC last, so a refusal rolls the whole reversal back.

fofo.return_reversal (return_reversal_20260921.sql) records each reversal and, unique
per return item, makes it once-only. Also adds cancelled=0 to the RETURNS_CN branches of
the account statement queries, without which a cancelled note keeps crediting the
statement - no current effect, no RETURNS note is cancelled today.

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/ReturnReversal.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/ReturnReversalRepository.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/fofo/ReturnReversalRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/CreditNoteRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/CreditNoteRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/transaction/OrderRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/InventoryService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/InventoryServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/ReturnReversalModel.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/ReturnReversalService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/ReturnReversalServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/CreditNoteService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/CreditNoteServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseInventoryService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseInventoryServiceImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/return_reversal_20260921.sql

Rev 37769 – fix(movement): receive a movement invoice only against its own PO, ...

amit — Thu, 24 Sep 2026 18:54:23 +0530

amit – 10 file(s) modified
fix(movement): receive a movement invoice only against its own PO, stop auto-closing movements, cancel reduces the PO line

- GRN: movement invoice resolves invoice -> orders -> transaction -> its own movement PO (or a receive-only PO
from the billing warehouse); supplier/warehouse keyed at entry must match; scanned IMEIs must be the billed ones
- Cancelling an unbilled movement order takes its qty off the PO line; PO CLOSED/PRECLOSED once nothing is open
- reopenedAt removed (movements no longer auto-close); PO records createdBy
- SupplierStateResolver: a supplier's state is derived from its GSTIN on save
- sql: add_po_created_by (applied), drop_po_reopened_at (run AFTER fofo/cron/web deploy)

Rev 37762 – aging po approval process

ranu — Thu, 24 Sep 2026 13:17:11 +0530

ranu – 1 file(s) modified
aging po approval process

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PoStockApprovalServiceImpl.java

Rev 37761 – aging po approval process

ranu — Thu, 24 Sep 2026 12:59:33 +0530

ranu – 4 file(s) modified
aging po approval process

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/ItemAgingBreakdownModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PoStockApprovalServiceImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/RbmDrrDashboardController.java
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/rbm-drr-dashboard.vm

Rev 37756 – aging po approval process

ranu — Wed, 23 Sep 2026 19:24:55 +0530

ranu – 1 file(s) modified
aging po approval process

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PoStockApprovalServiceImpl.java

Rev 37755 – aging po approval process

ranu — Wed, 23 Sep 2026 19:23:32 +0530

ranu – 1 file(s) modified
aging po approval process

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PoStockApprovalService.java

Rev 37751 – aging po approval mail to some collected users

ranu — Wed, 23 Sep 2026 19:16:30 +0530

ranu – 5 file(s) modified
aging po approval mail to some collected users

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/RunOnceTasks.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledSkeleton.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/ScheduledTasks.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PoStockApprovalDigestServiceImpl.java

Rev 37750 – aging sku purchasing need to approval of niranjan kala sir

ranu — Wed, 23 Sep 2026 18:50:55 +0530

ranu – 15 file(s) modified
aging sku purchasing need to approval of niranjan kala sir

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/warehouse/WarehousePurchaseOrder.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/CreateWarehousePurchaseOrderModel.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/ItemAgingStockByVendorModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/PurchaseOrderApprovalRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/PurchaseOrderApprovalRepositoryImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PoStockApprovalDigestService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PoStockApprovalDigestServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/monitors/MonitorController.java
+ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/warehouse/PoStockApprovalController.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/warehouse/PurchaseOrderController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/warehouse-purchase.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/rbm-drr-dashboard.vm
+ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse-po-stock-approvals.vm
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse-purchase-order-add-item.vm

Rev 37722 – Movement PO availability: list stock arriving into the sending warehouse, ...

amit — Fri, 18 Sep 2026 17:14:46 +0530

amit – 6 file(s) modified
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

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementAvailabilityModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/MovementCommitmentModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java

Rev 37713 – fix(warehouse): record the order's own vendor when a receipt line ...

amit — Fri, 18 Sep 2026 05:05:15 +0530

amit – 2 file(s) modified
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

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseServiceImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/backfill_receipt_origin_20260918.sql

Rev 37711 – Bulk-uploaded PO rows show the same availability breakdown as hand-picked ...

amit — Fri, 18 Sep 2026 04:54:36 +0530

amit – 5 file(s) modified
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.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/warehouse/PurchaseOrderController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/warehouse-purchase.js

Rev 37704 – Reopen a movement PO whose stock arrived late, and stop ...

amit — Fri, 18 Sep 2026 04:18:12 +0530

amit – 8 file(s) modified
Reopen a movement PO whose stock arrived late, and stop stranding GRN price corrections

Internal movements auto-close after four days, which fits 99.6% of them - 5,491 of 5,515 receipts
land inside the window. The remainder leave the PO closed with the stock still in transit and
nowhere to receive it: 998 internal POs closed during 2026 still holding 21,996 unreceived units.

A closed movement PO can now be reopened from the purchase order list. Reopening stamps
reopenedAt, and auto-close measures from WarehousePurchaseOrder.getOpenSince() - reopenedAt when
set, the PO date otherwise - so a reopened PO gets the same fresh window a new one gets instead of
being closed straight back on the next sweep. Only movements between our own warehouses: an
external vendor PO that has closed is settled with that vendor, not reopened unilaterally.

Separately, a GRN price correction now checks that the PO it just raised is one the invoice can
actually be received against. Matching reads POs that are open and approved for the same supplier
and warehouse dated on or before the invoice; it never looks at the PO being corrected, so what
matters is that the new PO is receivable. 54 were not - backdated into INIT by the old approval
gate, hence outside the match - and each stranded silently: original line discarded, GRN completed
without it, the correction left holding a reservation for stock that had already arrived.

isOpen() names the open set - INIT, READY, PARTIALLY_FULFILLED - that the movement and commitment
queries already read.

Migration sql/add_po_reopened_at_20260918.sql adds reopenedAt, nullable and additive. It must run
before this ships: the entity maps the column.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/scheduled/purchaseorder/POScheduler.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/warehouse/WarehousePurchaseOrder.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/GrnRequestServiceImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/add_po_reopened_at_20260918.sql
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/config/AppConfig.java
~ /trunk/profitmandi-fofo/src/main/java/com/spice/profitmandi/web/controller/warehouse/PurchaseOrderController.java
~ /trunk/profitmandi-fofo/src/main/webapp/resources/js/warehouse-purchase.js
~ /trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/warehouse-purchase-order.vm

Rev 37703 – GRN price mismatch: ask for the original PO to be ...

amit — Fri, 18 Sep 2026 04:10:51 +0530

amit – 2 file(s) modified
GRN price mismatch: ask for the original PO to be reopened instead of stranding a correction PO

Resolving a price mismatch raised a correction PO dated to the supplier invoice, and stored its id
on the GRN request item to receive against. But by then the stock has already arrived and the PO it
corrects is closed - every one of the 54 raised this way had its mapped PO in CLOSED. The
correction therefore had nowhere to land: the GRN completed against the original, nothing was ever
received against the correction, and it sat holding a reservation for stock that was not coming.
Backdated by nature, it also parked in INIT under the old approval gate, so it could not have been
received even if anyone tried.

Resolving a mismatch against a closed PO now says so and names it, asking for that purchase order
to be reopened first, rather than silently creating a second PO that cannot be used.

WarehousePurchaseOrder.isOpen() names the open set - INIT, READY, PARTIALLY_FULFILLED - that the
movement and commitment queries already read, so it stops being restated per caller.

Rev 37702 – Internal movement: an unapproved PO no longer dispatches stock ...

amit — Fri, 18 Sep 2026 04:06:59 +0530

amit – 2 file(s) modified
Internal movement: an unapproved PO no longer dispatches stock

A PO raised on one of our own warehouses also raises the order that moves the stock, and that
order pays and processes immediately - so raising it ships goods. The approval gate never
governed that half. It set the PO to INIT and mailed an approval link, then created and processed
the order anyway, several lines later and without consulting the status it had just set. The gate
held back receiving - PO list, GRN matching, auto-close all skip INIT - while dispatch went ahead
unconditionally.

That is how PO/07-26/52029 was delivered and invoiced while frozen out of GRN. Its goods had to be
received against a second PO raised for the purpose, leaving the first holding a phantom
unfulfilled quantity for two months.

Order creation now waits on approval. WarehousePurchaseOrder.isApproved() names the rule once -
INIT is the only state before approval, every other state is something the order has already been
approved to do - matching how the PO list, GRN matching and the auto-close sweep already read it,
so callers stop restating it.

Backdated POs are approved at creation since r37682, so this holds nothing up today; it is what
keeps the two halves from separating again if any future rule leaves a PO unapproved. Nothing
raises the order later, so such a PO simply does not move stock and has to be raised again once
approved - the safe failure, and it is logged.

Rev 37700 – Internal movement: order against expected stock, and stop reserving lines ...

amit — Fri, 18 Sep 2026 01:05:17 +0530

amit – 3 file(s) modified
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.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementPriceModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java

Rev 37696 – Internal movement: report what a warehouse can actually send, not ...

amit — Thu, 17 Sep 2026 22:45:33 +0530

amit – 6 file(s) modified
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.

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementAvailabilityModel.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/MovementCommitmentModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java

Rev 37694 – feat(warehouse): record where stock came from and what it cost; ...

amit — Thu, 17 Sep 2026 18:19:28 +0530

amit – 11 file(s) modified
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

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/warehouse/WarehouseInventoryItem.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/warehouse/WarehouseLineItem.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementAllocationModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementPriceModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseLineItemRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseLineItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseServiceImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/add_inventory_cost_layer_20260917.sql

Rev 37682 – feat(warehouse): auto-approve backdated POs in the creator's name A ...

amit — Thu, 17 Sep 2026 16:40:41 +0530

amit – 1 file(s) modified
feat(warehouse): auto-approve backdated POs in the creator's name

A backdated PO used to be parked in POStatus.INIT until an HOD clicked a mailed approval link. INIT
keeps a PO out of the PO list, out of GRN/invoice matching and out of the auto-close sweep, so an
unclicked PO was frozen rather than merely pending - 440 had accumulated since 2024, of 2547 approval
rows only 2023 were ever clicked.

- every PO now goes READY at creation, backdated or not
- the warehouse.poapproval row is still written, stamped approvedOn=now and approvedBy=<creator> by
recordAutoApproval(), since that row is what identifies a PO as backdated and who backdated it
- the HOD mail survives as a notification: names the creator, no approval link, PDF still attached
- /approve-po-date/* endpoints kept so links already sent do not 404

Completes r37679-81. Backfill for the three POs still inside POScheduler's window is staged at
profitmandi-dao/src/main/resources/sql/backdated_po_auto_approval_backfill_20260917.sql, not run.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 37679 – feat(warehouse): carry the PO creator through purchase order creation for ...

amit — Thu, 17 Sep 2026 16:29:06 +0530

amit – 4 file(s) modified
feat(warehouse): carry the PO creator through purchase order creation for backdated auto-approval

Backdated POs are to be auto-approved in the name of whoever raised them, but the service had no way
to know who that was: the model carried no user and buyerId is the seller, not a person.

- CreateWarehousePurchaseOrderModel carries createdBy
- resolvedMismatchRequest takes resolvedBy, so the correction PO raised on a GRN price mismatch -
dated to the supplier invoice and therefore backdated by nature - is credited to whoever resolved it
- staged backfill SQL for the three backdated POs still stuck in INIT inside POScheduler's
auto-close window; data only, no schema change, not yet run

The release-to-READY change in PurchaseOrderServiceImpl follows separately.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/CreateWarehousePurchaseOrderModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/GrnRequestService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/GrnRequestServiceImpl.java
+ /trunk/profitmandi-dao/src/main/resources/sql/backdated_po_auto_approval_backfill_20260917.sql

Rev 37622 – feat(billing): price warehouse billing from the external supplier of the ...

amit — Mon, 14 Sep 2026 17:10:35 +0530

amit – 9 file(s) modified
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

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/BillingPriceModel.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InventoryItemExternalOriginModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/VendorCatalogPricingService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/VendorCatalogPricingServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/TransactionServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/BillingPricingService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/BillingPricingServiceImpl.java

Rev 37612 – Value an internal PO's cart the same way the transaction ...

amit — Sun, 13 Sep 2026 02:37:36 +0530

amit – 1 file(s) modified
Value an internal PO's cart the same way the transaction validates it

Creating an internal PO failed with "Cart Value-Payment value mismatch" whenever a line
carried paise and the quantity was more than a handful. Two places were computing the same
cart total from the same stored float through two different decimal conversions, so they
disagreed on the value of prices binary cannot hold exactly.

createOrderInternally read WarehouseLineItem.unitPrice through String.valueOf, which
resolves a float via Float.toString and yields 10499.99, while createTransactionForWarehouse
re-values the persisted cart lines with BigDecimal.valueOf, which widens that same float to
double and yields 10499.990234375. The per-unit gap is around two ten-thousandths of a rupee;
quantity multiplies it, and it crosses the 0.001 tolerance the validator allows at a quantity
of five. Round prices are exact in binary and passed, which is why this looked intermittent
rather than total - across randomised carts the old arithmetic disagreed 98% of the time.

The total is no longer computed in its own loop. It is derived from the cart items that are
about to be written, using the conversion and the line-inclusion rule the validator applies,
so both sides are the same function over the same rows and cannot drift apart. That also
brings across two rules the PO side never had: quantities of zero or less, which
addItemsToCart drops and which therefore never reach the validated total, and the one paisa
carry bag, which the validator treats as a marker line rather than a billed one. Either of
those reaching an internal PO would have failed it outright, and a carry bag is only a
rounding error away from the paisa-per-unit pricing used for FOC stock.

The wallet top-up still truncates the total to whole rupees, and now lands within a rupee of
where it did before, well inside the twenty rupee buffer it already carried. Nothing outside
internal PO creation is touched: the validator, bulk orders and the refurb split keep their
existing numbers, and the wallet debit is driven by the order totals, not by this value.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 37610 – Carry stock with no recorded origin along instead of refusing ...

amit — Sun, 13 Sep 2026 01:49:46 +0530

amit – 1 file(s) modified
Carry stock with no recorded origin along instead of refusing the movement

A movement was refused whenever an item had some stock traceable to a vendor and some whose
origin was never recorded, telling the user to raise a second purchase order for the rest.
Unrecorded stock has no vendor of its own, so that second order carried no more information
than the first - and the prices were identical anyway: boAt 34336 at 85 both ways, Samsung
36343/36344 at 1099, Riversong 36589 at 524, 36590 at 657. Bulk uploads of 200 rows were
dying on the first such item, repeatedly.

Only a second ORIGINAL VENDOR stops an order now, which is the case the refusal was for: a
line item holds one price per item, so units genuinely bought from someone else cannot ride
along. Unrecorded units move with the oldest stock at its price. They are not attributed to
that vendor as a fact - nothing persists origin today, but if that is ever added they must
not be stamped from this.

The refusal also reported unrecorded stock as moving at 0.00. Such a bucket carries no price
until it is resolved from the catalog when units are allocated, so reading one off it early
reported perfectly good stock as worthless. Both sides of the message now resolve the price
the same way the allocation does.

Three tests added: a mixed traceable/unrecorded item moves in one order, two genuinely
different vendors still refuse, and no message quotes a zero price from either side.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java

Rev 37609 – Offer the stock a warehouse actually holds when ordering from ...

amit — Sat, 12 Sep 2026 18:29:44 +0530

amit – 4 file(s) modified
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.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseServiceImpl.java

Rev 37603 – Price internal warehouse movements from the stock's original vendor ...

amit — Sat, 12 Sep 2026 17:00:04 +0530

amit – 11 file(s) modified
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.

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementAllocationModel.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/InternalMovementPriceModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/VendorCatalogPricingLogRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/inventory/VendorCatalogPricingLogRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepository.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/warehouse/WarehouseInventoryItemRepositoryImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/GrnRequestServiceImpl.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingService.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InternalMovementPricingServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/InvoiceServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 37302 – Split refurbished (margin scheme) items into their own order at ...

amit — Thu, 13 Aug 2026 13:55:10 +0530

amit – 3 file(s) modified
Split refurbished (margin scheme) items into their own order at placement

Refurbished lines are invoiced on the RF- series, but only the partner checkout path
split them out. Internal POs and bulk orders raised a single mixed transaction, which
billed as one invoice on whichever series its first line happened to resolve to
(NSPJB2757, NSPJB3212, NSUPDL3898/3899/4365/4366).

- PurchaseOrderServiceImpl: split a mixed internal PO into a regular PO and a margin
scheme PO, each with its own PO number, PDF and internal transaction. External vendor
POs raise no transaction, so they are left intact.
- BulkOrderService: raise one transaction per billing group, each with its own loan
sized to the wallet balance left to it. Pricing, combo, credit availability and the
first-PO gates still validate the order as a whole, so a split first PO cannot block
its own second half.
- TransactionServiceImpl: drop the float narrowing of walletUsed in
createTransactionForCartLines - the field is a double and the cart total is validated
within 0.001, so any total carrying paise was rejected.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/order/BulkOrderService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/TransactionServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 37099 – GRN: default supplier invoiceDate to received date when blank ...

amit — Thu, 16 Jul 2026 13:55:07 +0530

amit – 1 file(s) modified
GRN: default supplier invoiceDate to received date when blank

Operators frequently leave invoiceDate empty on PO-based GRN uploads
(addPORowModels), persisting NULL invoice.invoiceDate (~26% of received
invoices historically). This breaks the warehouse ageing/valuation
reports that key off invoiceDate. Default it to the received date at the
single feed into addWarehouseSupplierInvoice, matching the historical
backfill convention. Fofo newReceiveInvoice already enforces this.

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 36910 – Internal PO: map created transaction to PO; block warehouse change ...

amit — Wed, 24 Jun 2026 11:53:31 +0530

amit – 6 file(s) modified
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

Rev 36640 – Fix NPE in addQuantity when inventory snapshot missing for partner ...

amit — Fri, 22 May 2026 19:29:00 +0530

amit – 2 file(s) modified
Fix NPE in addQuantity when inventory snapshot missing for partner warehouse - use addAvailability which creates snapshot if absent

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseInventoryService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseInventoryServiceImpl.java

Rev 36624 – Thrift cleanup: migrate types, remove dead code, add moved files ...

amit — Thu, 21 May 2026 14:45:45 +0530

amit – 13 file(s) modified
Thrift cleanup: migrate types, remove dead code, add moved files

- Added Affiliate.java POJO (replaces Thrift struct)
- Moved from profitmandi-common: WalletHistoryModel, ExcelUtils, CustomOrder
- Removed dead createReturnTransaction method from ReturnService/Impl
- Removed dead getPartnerStockOnDate from InventoryService/Impl
- Replaced CatalogServiceException with Exception in PdfPoSheetGenerator
- Removed Thrift client imports from UserServiceImpl

+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/common
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/common/model
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/common/model/CustomOrder.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/common/util
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/common/util/ExcelUtils.java
+ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/common/util/WalletHistoryModel.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/InventoryService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/InventoryServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/ReturnService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/ReturnServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/user/UserServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PdfPoSheetGenerator.java
+ /trunk/profitmandi-dao/src/main/java/in/shop2020/model/v1/user/Affiliate.java

Rev 36611 – Allow GRN corrections for SALE_RET items in addition to PURCHASE ...

amit — Wed, 20 May 2026 14:44:36 +0530

amit – 1 file(s) modified
Allow GRN corrections for SALE_RET items in addition to PURCHASE - serial correction, serialized item change, and non-serialized item change paths all now accept SALE_RET scan type since the item is back in warehouse custody

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 36586 – Fix:Restructure mail send

aman — Mon, 18 May 2026 12:07:36 +0530

aman – 3 file(s) modified
Fix:Restructure mail send

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/entity/fofo/FofoOrder.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/user/StoreTimelineTatServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 36542 – Validate oldItemId exists on invoice at GRN correction request creation ...

amit — Thu, 14 May 2026 19:49:06 +0530

amit – 1 file(s) modified
Validate oldItemId exists on invoice at GRN correction request creation time

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 36450 – Refactor applyReceipt: extract scan creation to WarehouseInventoryService.recordReturnScan with validation for ...

amit — Sat, 02 May 2026 17:14:12 +0530

amit – 3 file(s) modified
Refactor applyReceipt: extract scan creation to WarehouseInventoryService.recordReturnScan with validation for all return types (SALE_RET/DOA_IN/SALE_RET_UNUSABLE), qty>0, sold-qty capacity check, and SALE_RET warehouse capacity check

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/inventory/PurchaseReturnServiceImpl.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseInventoryService.java
~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/WarehouseInventoryServiceImpl.java

Rev 36417 – Fix:PO item swap — update/delete old PURCHASE scan record when ...

amit — Tue, 28 Apr 2026 18:17:53 +0530

amit – 1 file(s) modified
Fix:PO item swap — update/delete old PURCHASE scan record when reducing quantity on swapped inventory item

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java

Rev 36414 – without vendor catalog pricing po will not create

ranu — Tue, 28 Apr 2026 16:48:05 +0530

ranu – 1 file(s) modified
without vendor catalog pricing po will not create

~ /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/warehouse/PurchaseOrderServiceImpl.java