Rev 37614 – Run each internal GRN in a transaction that is actually ...

amit — Mon, 14 Sep 2026 04:46:19 +0530

amit – 2 file(s) modified
Run each internal GRN in a transaction that is actually applied

The internal GRN one-off failed immediately with "no transaction is in progress", thrown while
flushing the Hibernate session at commit.

The per invoice method was annotated to start its own transaction, but it sat in the same bean as
the loop that called it. Spring applies @Transactional through a proxy, and a call from one method
of a bean to another never leaves the object, so the annotation was inert - the receiving ran with
no transaction at all while the driver had suspended the surrounding one. The repositories still
bound a session to the thread, and the flush at commit then found nothing to flush into.

The receiving moves to its own bean, so the driver now reaches it through the proxy and the
transaction is real. The driver keeps no transaction of its own, which is what lets one invoice
fail without disturbing those already received.

No change to what is received or to the conditions under which an invoice is skipped.

+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnReceiver.java
~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnTask.java

Rev 37613 – Receive internal transfer stock that was billed but never GRNed ...

amit — Mon, 14 Sep 2026 03:20:42 +0530

amit – 2 file(s) modified
Receive internal transfer stock that was billed but never GRNed

Stock moved between our own warehouses is dispatched against an internal purchase order and
billed, but the destination warehouse still has to receive it by hand through the portal. Where
that never happened the units exist on an invoice and nowhere in inventory, and there is no way
to clear a backlog of them short of keying each invoice in again.

This adds a cron one-off that receives them. Per invoice it builds the rows the Excel GRN upload
would have carried and hands them to PurchaseOrderService.addPORowModels, which creates the
supplier invoice, the purchase and the inventory items in a single call, so none of receiving is
reimplemented here - the portal and this take the same path and can only ever agree.

It is deliberately narrow about what it will touch. Only INTERNAL buyers, because nothing should
be able to receive a partner's goods on their behalf. Only invoices with no supplier invoice
already recorded, so a repeat run skips what it has already done rather than receiving twice.
Only invoices resolving to a single purchase order, since addPORowModels resolves one order for
the whole map it is given and would otherwise attribute an invoice to the wrong one - for the
same reason each invoice is passed on its own. A serialized line whose serial number is missing
aborts its invoice instead of creating a unit no scan could ever match.

Each invoice commits or rolls back on its own, so one bad invoice cannot undo the ones already
received, and a dry run reports what it would receive without writing anything.

The receipt is recorded against the destination warehouse, which is what warehouse inventory is
keyed by. The buyer on the order is read only to confirm the store is internal; partner side
inventory is a separate receipt and is not touched.

~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/Application.java
+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnTask.java

SmartDukaan – /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnTask.java

Rev 37614 – Run each internal GRN in a transaction that is actually ...

Rev 37613 – Receive internal transfer stock that was billed but never GRNed ...