[jira] [Commented] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16091164#comment-16091164 ]

Paul Foxworthy commented on OFBIZ-9492:
---------------------------------------

Hi [~deepak.nigam],

Yes and no.

No, I think the tax paid and collected shouldn't be put in the same account, at least in Australia. At the end of a reporting period, you need to know and be able to report the total tax paid on purchases and collected with sales as two separate numbers. The tax to pay is indeed the difference between the two, but the difference number alone will not satisfy the good people at the Australian Tax Office.

I would expect when this Jira is completed, during purchases there will be a credit to a "tax paid on purchases" asset GL account, and during sales there will be a debit to a "tax collected on sales" liability GL account.

So technically, you could use a debitCreditFlag in the TaxAuthorityGlAccount entity.

But imagine someone trying to do the data entry to configure the GL accounts for a tax authority, something like https://demo-trunk.ofbiz.apache.org/accounting/control/EditTaxAuthorityGlAccounts . I think asking the user to choose Credit or Debit would be very confusing. We *could* reuse one of the existing ways of categorising things in OFBiz: debitCreditFlag as you say, or INCOME vs EXPENSE (very general GL account types). I have explored a little more in thinking about your suggestion, and I wonder if the right thing is to use the AcctgTransType entity instead of inventing a new one. There are already SALES_INVOICE, PURCHASE_INVOICE and CUST_RTN_INVOICE values which correspond to the three services. I could imagine a larger company wanting to account for tax in other transactions like a credit note.

What does everyone think of using AcctgTransType instead of inventing a new enum or entity which is trying to do similar categorisation of transactions?

Cheers

Paul

> Tax Authorities need two GL accounts for sales and purchases
> ------------------------------------------------------------
>
>                 Key: OFBIZ-9492
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-9492
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: accounting
>    Affects Versions: Trunk
>            Reporter: Paul Foxworthy
>            Assignee: Paul Foxworthy
>              Labels: accounting, vat
>
> In jurisdictions with Value Added Tax, you need to track tax you have paid on purchases, and tax you have collected with sales. When you report to a tax authority, you pay them the difference between the two, i.e. you pay tax on the value added, not on your inputs.
> OFBiz has an entity, TaxAuthorityGlAccount (TAGLA), which currently assumes the GL account is for a sale.
> We need to extend OFBiz so it is possible to find two GL accounts for a tax authority, one for sales and one for purchases.
> I propose:
> - Define a new Enumeration for the direction of a transaction. I suggest
> calling the Enumeration TAGLADIR, with two values TAGLADIR_INCOMING
> and TAGLADIR_OUTGOING.
> We could reuse an existing indication of the direction of a transaction,
> for example the GlAccountClassIds INCOME and EXPENSE. However, when we receive
> income from a sale, we would incur a tax *liability*, and the GL account for that
> would be a liability account. So I think it would be less confusing to have a
> separate enum here that's just for TAGLA.
> - add a new attribute to the TaxAuthorityGlAccount entity for the direction of the transaction.
> The new attribute should be included in the primary key.
> - Add a new service in TaxAuthorityServices named getTaxAuthorityGlAccountId which
> looks up a TAGLA given primary key values, including the direction
> - There are two places in TaxAuthorityServices that would call getTaxAuthorityGlAccountId: getTaxAdjustments and getItemTaxAdjustments, one for orders, and the other for invoice item types. The direction can be inferred from the order type or the invoice item type
> - createAcctgTransForPurchaseInvoice and createAcctgTransForCustomerReturnInvoice
> should use getTaxAuthorityGlAccountId
> - createAcctgTransactionForSalesInvoice should be rewritten to use getTaxAuthorityGlAccountId.
> I am working on a patch to do this, but I'd like your thoughts on my proposal

--
This message was sent by Atlassian JIRA
(v6.4.14#64029)