Hello @Support-at-ERPgulf Team,
We encountered multiple problems in the advance payment → final Sales Invoice workflow while testing on our demo server.
The documentation/video example using full-payment cases masks this issue; partial payments as advances are where the behavior fails.
Below is a detailed summary of what we observed in the code, how we tested, the issues we saw, and questions / next steps. Please review and advise.
Summary
-
Taxes on Advance Sales Invoices are not consistently applied through the workflow, so final Sales Invoices do not deduct advance taxes correctly. This leads to incorrect outstanding amounts on final SIs.
-
Additional concerns: Advance Sales Invoice appears not to create expected GL entries; a Pre Payment Invoice flag on Payment Entry appears unused; several code sections are commented out; UI shows unexpected values (e.g., “Advance Amount” displayed as 115,000 instead of 11,500).
What we noticed in code
-
Advance Sales Invoice code:
-
Many validation, GL, and tax-related code blocks are commented out in advance_sales_invoice.py. It’s unclear whether this is intentional for regional customization or an incomplete change.
-
Tax helper methods and apply flow are present but in some runs not executed (comment/uncomment status inconsistent).
-
Some fields (e.g., a company_currency usage) appear to be referenced without guaranteed initialization in all code paths.
-
-
Advance fetcher:
- The logic that returns advances to the final Sales Invoice appeared to rely on a limited data fetch (returned paid_amount only in some implementations) instead of always reading the Advance SI computed tax fields.
-
Payment Entry UI:
- There is a checkbox Pre Payment Invoice (or pre_payment_invoice) visible, but we did not find code applying any behavior based on its value.
-
UI / list rendering:
- The advances listing sometimes shows a value equivalent to the Sales Order total (115,000), suggesting the wrong field is bound or the display label is confusing.
Exactly how we tested (step-by-step with values)
-
Create Sales Order / Sales Invoice baseline:
-
Base amount: 100,000 SAR
-
VAT: 15% → 15,000 SAR
-
Grand total expected: 115,000 SAR
-
-
Create Advance Sales Invoice (for the Sales Order):
-
Paid Amount = 10,000 SAR (we entered the cash amount only)
-
Tax row added:
-
Charge Type = “On Paid Amount”
-
Rate = 15
-
Add/Deduct = “Add”
-
(Expected tax on advance = 1,500 SAR)
-
-
Save Advance SI, observed an error initially (AttributeError referencing company_currency) in some runs.
-
Expected on Advance SI: total_taxes_and_charges = 1,500 and tax row tax_amount = 1,500.
-
-
Create Final Sales Invoice and apply advance:
-
Expected final outstanding = 115,000 − (10,000 + 1,500) = 103,500 SAR.
-
Observed final outstanding = 105,000 SAR (only 10,000 deducted).
-
-
UI checks:
-
Advances pane showed a row with “Advance Amount” = 115,000 (likely wrong field).
-
In Payment Entry and Advance SI the Paid Amount field was the base cash amount (10,000), which we believe is correct behavior, tax should be computed and tracked separately.
-
-
Other observations:
- When editing the tax row manually (entering 1,500 into the tax amount), some UI total columns still showed 115,000 which looked like cumulative or wrong-field values.
Problems observed
-
Advance tax not deducted in Final SI: Final SI deducted only base paid amount (10,000); advance tax (1,500) was ignored.
-
Advance SI GL behavior unclear: Advance SI does not appear to post tax GL entries; unclear if intended (we need confirmation whether tax GLs should be created at advance time).
-
Pre Payment Invoice flag unused: The flag exists in UI but we did not find supporting behavior in the codebase.
-
Wrong value shown in Advances list: UI shows 115,000 where it should show advance-specific values such as 10,000 (cash) and 1,500 (tax) or combined 11,500.
-
Partial vs full advance case: Documentation/video example uses full advance equal to SO amount (ex. Sales Order 900, Advance 900), this does not reveal the partial-advance bugs we observed. The partial-advance case demonstrates the real issue.
-
Incomplete initialization: Some fields like company_currency appeared referenced before guaranteed initialization, causing save-time AttributeErrors.
-
Large commented sections: A lot of AdvanceSalesInvoice logic is commented out; this makes it hard to reason about intended behavior.
What we think is likely (our understanding, may be wrong)
- The final deduction should include both cash advance and computed taxes on that cash advance (i.e., deduction = paid_amount + total_taxes_and_charges). If GL entries for tax are not to be created at advance time, tracking taxes on Advance SI and including them in Final SI deduction is still required so outstanding amounts are correct.
Questions for you / requests
-
Accounting intent: When an advance is received, should tax GL entries be posted at Advance SI time, or only when Final SI (or Payment Entry) is submitted/allocated? Please confirm desired accounting flow.
-
Is the large number of commented code blocks in AdvanceSalesInvoice intentional or accidental, including many validation/GL methods are commented out, was this intentional for regional behavior or temporary debugging?
-
The Pre Payment Invoice checkbox on Payment Entry: is there intended behavior wired in another app/module?
Thanks & Best regards,