[16.0][ADD] advance_payment_receipt_kmitl: issue receipt on advance return - #1255
Open
n3n wants to merge 6 commits into
Open
[16.0][ADD] advance_payment_receipt_kmitl: issue receipt on advance return#1255n3n wants to merge 6 commits into
n3n wants to merge 6 commits into
Conversation
n3n
force-pushed
the
16.0-review-advance-payment-refund-receipt
branch
2 times, most recently
from
September 3, 2026 18:16
a976dc1 to
0656723
Compare
Extract the money-in creation in advance.payment.return.line from action_approve/action_admin_reset into two overridable methods, _settle_return() and _cancel_return_settlement(). Behaviour is unchanged (still a draft inbound account.payment) when no bridge overrides them; this lets a bridge settle a return through a different document without re-implementing action_approve.
Bridge advance_payment_budget and receipt_kmitl: when a returned advance is approved, override the base return-settlement seam to issue a draft kmitl.receipt (the single money-in + accounting document) instead of a draft inbound account.payment, avoiding a double count. The receipt copies the agreement's partner and analytic dimensions, its product and payment method come from Settings, and it flows through the normal remittance workflow. Admin-reset cancels a draft receipt and is blocked once it has entered remittance/posting.
Replace the auto-issued receipt on approval with an explicit officer step: the loan officer records the receiving transfer method and date on the return line, then presses "สร้างใบเสร็จรับเงิน" to both create the kmitl.receipt and finalize the return in one action. - Return line gains receipt_payment_method_id (transfer-only) and receipt_transfer_date, editable while pending_review. - Receipt vals are built from the line's officer-entered data instead of a config-only payment method; payment type is hard-set to transfer. - Guard against agreements with no department dimension set, and against a missing receiving method, with clear UserErrors instead of a raw DB constraint failure. - Smart buttons: return line -> receipt, receipt -> advance agreement. - Receipt description/line description now include the agreement, borrower, and loan reason instead of being auto-derived only from config.
…scription Keep the header description to the agreement number and borrower name.
Remove the to_verify_report / to_reconcile review states from the loan lifecycle. Reporting the actual expense and returning leftover money both happen freely while in_progress; closing the agreement is never automatic anymore, the loan officer must press "ปิดสัญญา" once the debt is settled. - state: draft -> to_verify -> to_approve -> waiting_transfer -> in_progress -> done (+ cancel), collapsing the previous report/reconcile substates. - action_submit_report stays in_progress; action_accept_report and _try_auto_close are removed; action_close becomes the explicit, loan-officer-gated close action. - Return line confirm / return wizard confirm now check state == in_progress instead of to_reconcile. - Views: drop the "ตรวจรับรายงาน" button, add "ปิดสัญญา", fix the "รอคืนเงิน" banner and "แจ้งคืนเงิน" visibility to key off amount_remaining, collapse the dead search filters, update statusbar/decorations. - advance_payment_followup.DEBTOR_STATES collapses to (in_progress,). - Update advance_payment and advance_payment_receipt_kmitl tests for the new lifecycle (explicit action_close, no auto-close assertions).
The loan officer has no ACL read access to account.analytic.plan, but department_analytic_id computes by walking it — reading it in the officer's own user context raised AccessError when pressing "สร้างใบเสร็จรับเงิน". Sudo the read, same rationale as the receipt create() call right below it.
n3n
force-pushed
the
16.0-review-advance-payment-refund-receipt
branch
from
September 6, 2026 09:13
cd1f062 to
b857a6f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a returned advance is approved, the office must now issue a proper cash receipt (ใบเสร็จรับเงิน) instead of the old draft inbound
account.payment, which never posted and left the money-in unreceipted.This adds a small extension seam to
advance_payment(_settle_return/_cancel_return_settlementon the return line, behaviour unchanged when no bridge is present) and a newadvance_payment_receipt_kmitlbridge that overrides it to issue a draftkmitl.receipt— the single money-in + accounting document — copying the agreement's partner and analytic dimensions, taking its product and payment method from Settings, and flowing through the normal remittance workflow. Admin-reset cancels a draft receipt and is blocked once the receipt has entered remittance/posting. The bridge depends onadvance_payment_budget(which supplies the agreement's analytic dimensions the receipt requires) andreceipt_kmitl; static-verified (pyflakes + xmllint) with tests for the happy path, missing-config, and admin-reset cases.