<?xml version="1.0" encoding="utf-8"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>SmartDukaan &#x2013; //trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnReceiver.java</title><description>WebSVN RSS feed &#x2013; SmartDukaan</description><lastBuildDate>Tue, 06 Oct 2026 19:09:03 +0530</lastBuildDate><generator>WebSVN 2.8.6-DEV</generator><language>en</language><link>https://svn.smartdukaan.com/log.php?repname=SmartDukaan&amp;path=%2F%2Ftrunk%2Fprofitmandi-cron%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsmartdukaan%2Fcron%2Fmigrations%2FInternalGrnReceiver.java&amp;max=40&amp;</link><atom:link href="https://svn.smartdukaan.com/rss.php?path=%2F%2Ftrunk%2Fprofitmandi-cron%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsmartdukaan%2Fcron%2Fmigrations%2FInternalGrnReceiver.java&amp;repname=SmartDukaan" rel="self" type="application/rss+xml" />
<item><pubDate>Mon, 14 Sep 2026 05:28:42 +0530</pubDate><dc:creator>amit</dc:creator><title>Rev 37616 – Split a line item&apos;s serials into one inventory unit each ...</title><description>&lt;div&gt;&lt;strong&gt;amit – 1 file(s) modified&lt;/strong&gt;&lt;br/&gt;Split a line item&apos;s serials into one inventory unit each&lt;br /&gt;
&lt;br /&gt;
A serialised line item carries one serial per unit in serial_number, comma separated. The internal&lt;br /&gt;
GRN passed that whole field across as a single serial, so a line of four units became one unit whose&lt;br /&gt;
serial was the four serials joined together - a string no scan can ever match. Where the joined&lt;br /&gt;
string ran past the 128 characters the inventory column allows, the receipt failed outright; where it&lt;br /&gt;
fitted, it was accepted and the stock was quietly understated.&lt;br /&gt;
&lt;br /&gt;
The serials are now split out and each unit is received on its own, which is what grnPoModels expects&lt;br /&gt;
- it creates one inventory row per serial.&lt;br /&gt;
&lt;br /&gt;
A serial count that does not match the line&apos;s quantity now skips the invoice. Receiving fewer units&lt;br /&gt;
than were billed is exactly the failure this had, and it is not something to infer a best guess from:&lt;br /&gt;
the invoice is left for someone to look at instead.&lt;/div&gt;~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnReceiver.java&lt;br /&gt;</description><link>https://svn.smartdukaan.com/revision.php?repname=SmartDukaan&amp;path=%2F%2Ftrunk%2Fprofitmandi-cron%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsmartdukaan%2Fcron%2Fmigrations%2FInternalGrnReceiver.java&amp;rev=37616</link><guid>https://svn.smartdukaan.com/revision.php?repname=SmartDukaan&amp;path=%2F%2Ftrunk%2Fprofitmandi-cron%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsmartdukaan%2Fcron%2Fmigrations%2FInternalGrnReceiver.java&amp;rev=37616</guid></item>
<item><pubDate>Mon, 14 Sep 2026 04:56:50 +0530</pubDate><dc:creator>amit</dc:creator><title>Rev 37615 – Receive internal transfers the way the portal does, not via ...</title><description>&lt;div&gt;&lt;strong&gt;amit – 1 file(s) modified&lt;/strong&gt;&lt;br/&gt;Receive internal transfers the way the portal does, not via the Excel upload&lt;br /&gt;
&lt;br /&gt;
The live run failed on every invoice with &quot;Column &apos;status&apos; cannot be null&quot;. The Excel upload path it&lt;br /&gt;
was calling, addPORowModels, persists a supplier invoice without ever setting a status, and the&lt;br /&gt;
column does not allow one to be absent, so that route cannot complete a receipt at all.&lt;br /&gt;
&lt;br /&gt;
Rather than change a path the portal shares, this follows what the Receive Invoice screens actually&lt;br /&gt;
do: record the supplier invoice, record its items through InvoiceService.createInvoiceItem, then hand&lt;br /&gt;
it to PurchaseOrderService.grnPoModels, the call behind the Create GRN button. grnPoModels sets the&lt;br /&gt;
invoice to received itself, so the status is never left for the caller to remember.&lt;br /&gt;
&lt;br /&gt;
Recording the invoice items matters beyond the receipt: warehouse.invoice_item is what the buying&lt;br /&gt;
reports join against, and the Excel path never wrote those rows either.&lt;br /&gt;
&lt;br /&gt;
An invoice is carried as one entry per item rather than one per order, since that is the shape&lt;br /&gt;
grnPoModels expects - every serial of an item arrives together and a non serialised item arrives as a&lt;br /&gt;
single quantity. There is no supplier document to attach, which is ordinary here; most existing&lt;br /&gt;
warehouse invoices carry none.&lt;br /&gt;
&lt;br /&gt;
Resolving the purchase order now uses the mapping recorded when the internal PO was raised - the&lt;br /&gt;
transaction it created, held on the purchase order - instead of walking every order to find it.&lt;br /&gt;
An invoice whose orders do not share that one transaction is skipped rather than guessed at.&lt;/div&gt;~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnReceiver.java&lt;br /&gt;</description><link>https://svn.smartdukaan.com/revision.php?repname=SmartDukaan&amp;path=%2F%2Ftrunk%2Fprofitmandi-cron%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsmartdukaan%2Fcron%2Fmigrations%2FInternalGrnReceiver.java&amp;rev=37615</link><guid>https://svn.smartdukaan.com/revision.php?repname=SmartDukaan&amp;path=%2F%2Ftrunk%2Fprofitmandi-cron%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsmartdukaan%2Fcron%2Fmigrations%2FInternalGrnReceiver.java&amp;rev=37615</guid></item>
<item><pubDate>Mon, 14 Sep 2026 04:46:19 +0530</pubDate><dc:creator>amit</dc:creator><title>Rev 37614 – Run each internal GRN in a transaction that is actually ...</title><description>&lt;div&gt;&lt;strong&gt;amit – 2 file(s) modified&lt;/strong&gt;&lt;br/&gt;Run each internal GRN in a transaction that is actually applied&lt;br /&gt;
&lt;br /&gt;
The internal GRN one-off failed immediately with &quot;no transaction is in progress&quot;, thrown while&lt;br /&gt;
flushing the Hibernate session at commit.&lt;br /&gt;
&lt;br /&gt;
The per invoice method was annotated to start its own transaction, but it sat in the same bean as&lt;br /&gt;
the loop that called it. Spring applies @Transactional through a proxy, and a call from one method&lt;br /&gt;
of a bean to another never leaves the object, so the annotation was inert - the receiving ran with&lt;br /&gt;
no transaction at all while the driver had suspended the surrounding one. The repositories still&lt;br /&gt;
bound a session to the thread, and the flush at commit then found nothing to flush into.&lt;br /&gt;
&lt;br /&gt;
The receiving moves to its own bean, so the driver now reaches it through the proxy and the&lt;br /&gt;
transaction is real. The driver keeps no transaction of its own, which is what lets one invoice&lt;br /&gt;
fail without disturbing those already received.&lt;br /&gt;
&lt;br /&gt;
No change to what is received or to the conditions under which an invoice is skipped.&lt;/div&gt;+ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnReceiver.java&lt;br /&gt;~ /trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/migrations/InternalGrnTask.java&lt;br /&gt;</description><link>https://svn.smartdukaan.com/revision.php?repname=SmartDukaan&amp;path=%2F%2Ftrunk%2Fprofitmandi-cron%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsmartdukaan%2Fcron%2Fmigrations%2FInternalGrnReceiver.java&amp;rev=37614</link><guid>https://svn.smartdukaan.com/revision.php?repname=SmartDukaan&amp;path=%2F%2Ftrunk%2Fprofitmandi-cron%2Fsrc%2Fmain%2Fjava%2Fcom%2Fsmartdukaan%2Fcron%2Fmigrations%2FInternalGrnReceiver.java&amp;rev=37614</guid></item>
</channel></rss>