| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37798 |
10 d 11 h |
amit |
/trunk/profitmandi-fofo/src/main/ |
Show a settled debit note as settled instead of offering Receive
The DN screens decided everything from "does a purchase_return_order exist",
which no return settled before the receive workflow ever had. A note settled
years ago therefore read "Pending Receive" with a Receive button, and receiving
one handed a partner back a phone already returned, refunded and resold
(DN UPBLY975/4, IMEI 864973083197734).
The debit note's own status now carries the fact - CREATED means there is
genuinely something to receive, anything else means it is settled - so the
screens read it directly instead of re-deriving it from warehouse scans on
every page load. r37797 backfilled the 4,154 notes the old flow left behind.
- invoice-return-results, debit-notes-table, debit-note-details,
receive-debit-note: Receive only while the note is CREATED with no return
order; otherwise "Processed - settled earlier".
- debit-notes-table: Refund only on a note received and not yet settled,
rather than on every row.
- PurchaseReturnController: the admin debit-note list now loads the return
orders its Refund button needs.
Deploy with profitmandi-dao r37797. |
|
| 36027 |
203 d 8 h |
amit |
/trunk/profitmandi-fofo/src/main/ |
Sale Returns: finance approval endpoint, invoice links in all views, invoice map for INV: returns, purchase reference check fix |
|
| 36022 |
204 d 8 h |
amit |
/trunk/profitmandi-fofo/src/main/ |
Sale Returns: invoice return flow with auto-approve, rename to Sale Returns, role-based search results, Finance L2+ access |
|
| 35998 |
208 d 8 h |
amit |
/trunk/profitmandi-fofo/src/main/ |
Invoice Return: controller endpoints, UI views (receive/refund/reject/details/search), JS handlers, role-based access, dashboard menu |
|