[29.x]: When receiving a payment from an SEZ (Special Economic Zone) customer under the "Without Payment of Duty" scenario, GST is being calculated incorrectly in the Bank Receipt Voucher in the Indian version.

[Tabrez Ajaz (v-ajaztabrez)]

(AB#650741)
Bug 650741: [29.x]-When receiving a payment from an SEZ (Special Economic Zone) customer under the "Without Payment of Duty" scenario, GST is being calculated incorrectly in the Bank Receipt Voucher in the Indian version.

Issue:
For an SEZ customer transaction created through Bank Receipt Voucher, enabling GST Without Payment of Duty did not immediately recalculate GST. After recalculation, IGST became zero, but GST Ledger Entry, Detailed GST Ledger Entry, and Detailed GST Ledger Entry Information were not generated during posting.

Cause:
The Bank Receipt Voucher page did not invoke the tax engine when GST Without Payment of Duty was validated. Additionally, the existing SEZ General Journal use case for transactions without payment of duty calculated IGST instead of zero and lacked the required GST posting configuration and posting-table metadata.

Solution:
Added tax-engine recalculation when GST Without Payment of Duty is validated on Bank Receipt Voucher. Updated the existing SEZ General Journal use case to calculate zero IGST while retaining GST ledger posting definitions, added the required GST Posting Setup table metadata, and increased the use-case version so the updated configuration is imported during deployment.

[alexei-dobriansky]

Good Sense Reviewer - Round 1

Recommendation: Request Changes

What this PR does

This PR adds tax-engine recalculation when GST Without Payment of Duty is validated on Bank Receipt Voucher and updates the SEZ without-duty GST use case so IGST is zero while GST ledger records are still posted. It also adds posting metadata for detailed GST ledger records.

Problem-solution fit

Fit: Partial

The reported scenario is valid and the recalculation hook is in the right area. The posting metadata still stores a customer receipt with a vendor source type, and one sample also found an uncovered sibling SEZ path, so the fix is not safe as-is.

Suggestions

S1 (🔴 High): Use customer source type for sales entry
The Detailed GST Ledger Entry uses Transaction Type = Sales and Source No. from the customer account, but the new Source Type value is Vendor. Change it to Customer; otherwise posted GST details for this receipt are stored with the wrong source type.

S2 (🔴 High): Cover the sibling SEZ path
The fix updates only the SEZ Unit use case. The without-duty flow can also use the matching SEZ Development setup, so update that sibling use case too or make the scope explicit if that customer type is not affected.

Risk assessment and necessity

Risk: This is a financial tax posting path. Wrong use-case metadata can persist incorrect GST ledger source classification even when the tax amount is zero.

Necessity: The fix is needed so SEZ without-duty receipts recalculate to zero IGST and still produce statutory GST ledger artifacts. The posting configuration must be corrected before merge.

---

[AI-PR-REVIEW] version=1 promptVersion=4 system=github pr=11649 round=1 by=alexei-dobriansky at=2026-09-21T20:24:04.4144933Z lastSha=3d15f44f8efb6625c3edeb99e954e79c8574e83d reviewKey=d35e896085237f7304888050c9682f1a34d12da4fc2222d06f859fd57710a0b6 suggestions=S1@b7d173ed,S2@b7d173ee