I would create a new entity if there is or might be another attribute to add. It strikes me that a description might be a very useful thing here, so let's make it an entity. In OFBIZ-9127 I raised the possibility of internationalising descriptions that are currently hard-coded in English. We could prototype that here, by adding an attribute (perhaps named descriptionKey or i18nDescriptionKey) that can be used to fetch a localised description in the same way as the UI components of OFBiz.
I would like to get the word "direction" or something like it into the name, something along the lines of TaxAuthorityGlAccountDirectionType, to differentiate this entity from GlAccountType. We are talking about a type of direction (the transaction that initiated the tax event is in or out, income or expense) and not a type of GL account. What does everyone think?
> 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
Locked
