ofbiz-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacopo Cappellato (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases
Date Thu, 13 Jul 2017 11:37:01 GMT

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

Jacopo Cappellato commented on OFBIZ-9492:

Thank you [~paul_foxworthy], I agree with the need to implement this requirement and with
your design proposal.
One possible alternative to the creation of the enumeration records and fields would be that
of creating a new entity TaxAuthorityGlAccountType and then add the two records there.
I don't have a strong preference but I wanted to mention it just for the records.

> 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
> 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

View raw message