Tax Payable

[agritheory]

#218
Sales Taxes and Charges, before being paid via Check Run (Outstanding Amount is $8.12)

Example Check Run

Example config (Sales Invoices and JEs allowed, other doctypes shouldn't be)

Example Payment Entry / output of Check Run

Satisfied Sales Tax Payable (Outstanding Amount is $0.00)

[agritheory]

@basawaraj-fosserp Would love to discuss this at our next meeting

[agritheory]

Not sure how to defeat this notification, otherwise this seems to be ready to go.

[agritheory]

@basawaraj-fosserp Adjacent, potentially overlapping use case: commissions payable. Potentially appropriate for Sales Partner (Supplier) or Sales Person (Employee or Supplier) as party types. Also potentially freight payable.

[agritheory]

There's one TODO left as of 6/4/24, which is to pull in the supplier default payment terms and payment due date. Normally this would have a a "days after month end" style of payment, we can use 25 days for testing purposes.

[fproldan]

I have just a couple of questions

[agritheory]

Todos as of 6/18/24:

• Test that payable amounts are reduced when the SI is returned/ reversed
• Test that a SI can be returned after Payable is remitted.
• Assert that the reversed payable amount shows up in correctly the Check Run. (Requires a V15 cherry-pick of Allow and Disallow setting to create stand-alone debit note #232)

[github-actions]

📝 Draft Changelog Entry

Changelog Entry

This update adds support for managing sales tax payable amounts through the Check Run system. Sales taxes and charges can now be tracked as outstanding payables and processed through check runs, similar to other payable accounts. The system includes configuration options to control which document types (such as Sales Invoices and Journal Entries) are eligible for tax payable processing. When a check run is executed for tax payables, it generates a payment entry that records the tax payment and updates the outstanding amount to reflect the paid balance. Documentation has been added to explain the sales tax payable workflow and configuration requirements.

This changelog entry was automatically generated by the Changelog Generator Action.

[agritheory]

@HKuz Finally ready to go, please review, docs first

[HKuz]

Getting there on this - I'm just tracking down a bug I came across when I create a Payment Entry from a Sales Invoice that has taxes payable (party is set in the Taxes and Charges row). The new Payment Entry's references table only shows the tax amount as what's outstanding - it should show the grand total. Seems some wires are crossing regarding outstanding amounts when ERPNext builds the Payment References table:

[agritheory]

@HKuz I can pick that back up, good catch

[agritheory]

@HKuz Fixed

[HKuz]

Looks like the root of the issue happens during on_submit of the Sales Invoice - when I create a new SI (with taxes), submit, then refresh the page, it immediately shows as "Partly Paid". The doc's outstanding_amount shows as only the tax amount. The issue doesn't happen if I leave taxes off.

In our override for max_tax_gl_entries, because the tax account being used is a Payable, this has downstream effect of triggering a Payment Ledger Entry for the tax amount with against voucher set to the SI. This then triggers an update on the SI's outstanding amount.

Looks like if I set "against_voucher" to the tax row name and "against_voucher_type" to "Sales Taxes and Charges", it avoids the issue above. I want to run some more tests to see the Payment Ledger impact - when Check Run remits the tax amount, should the Accounts Payable report match them and remove?

[HKuz]

Latest push fixes two bugs:

1. Noted above - on submit, the Sales Invoice would adjust the outstanding amount to only the Taxes payable amount.

si_os_amount_bug.mov

BUG: This happened because the GL entry being created for the taxes, has a Payable account and the against_voucher_type was "Sales Invoice". These two things combined triggered the creation of a PLE (the account is a payable), and the erpnext.accounts.utils.update_voucher_outstanding (because the against voucher is a Sales Invoice). But the query in the update o/s code only finds the tax because it's filtering on the voucher number and party (which is the Mass Dept of Rev), so resets the o/s amount to only that tax amount.

FIX: our override for make_tax_gl_entries should specify the against_voucher and against_voucher_type as the Sales Taxes and Charges when the account is a payable account (not specifying these keys defaults to the SI info). This avoids updating the SI's o/s amount issue. Also, by specifying the voucher info as the Sales Taxes and Charges info (same as against_voucher), when the Check Run pays the taxes payable, the Accounts Payable report properly matches the PLEs so they clear here.

I had to adjust the tests a bit to find the correct GL Entries with this change.

2. Minor one with the order of the query to collect the Sales Taxes and Charges transaction in Check Run

BUG: depending on the Settings checks I had (include JEs / include Taxes), I wouldn't see any results in Check Run sometimes. Turns out the ref_no and name fields in the query have to be in exact same order of others it's union'ing with, because sometimes it would "flip" the data in those fields, then falsely trigger the "not o/s or cancelled" check, removing them from result

FIX: make order same as other queries that combine via union

[HKuz]

LGTM! Nice feature 🎉 🔥