Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id EDE75200CDC for ; Sat, 22 Jul 2017 08:51:04 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id EC5A116DA06; Sat, 22 Jul 2017 06:51:04 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3B7F416D9F1 for ; Sat, 22 Jul 2017 08:51:04 +0200 (CEST) Received: (qmail 30737 invoked by uid 500); 22 Jul 2017 06:51:03 -0000 Mailing-List: contact notifications-help@ofbiz.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ofbiz.apache.org Delivered-To: mailing list notifications@ofbiz.apache.org Received: (qmail 30728 invoked by uid 99); 22 Jul 2017 06:51:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 22 Jul 2017 06:51:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id B26481805C0 for ; Sat, 22 Jul 2017 06:51:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id q-YmO8OWclWw for ; Sat, 22 Jul 2017 06:51:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 564035FD49 for ; Sat, 22 Jul 2017 06:51:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id C6DC1E0DF0 for ; Sat, 22 Jul 2017 06:51:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 3050F21EE7 for ; Sat, 22 Jul 2017 06:51:00 +0000 (UTC) Date: Sat, 22 Jul 2017 06:51:00 +0000 (UTC) From: "Deepak Nigam (JIRA)" To: notifications@ofbiz.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (OFBIZ-9492) Tax Authorities need two GL accounts for sales and purchases MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Sat, 22 Jul 2017 06:51:05 -0000 [ https://issues.apache.org/jira/browse/OFBIZ-9492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16097138#comment-16097138 ] Deepak Nigam commented on OFBIZ-9492: ------------------------------------- Hi [~paul_foxworthy], I explored a little more about using separate GL accounts for Tax Authorities (for sales and purchases) and it looks good to me now. If we use same GL account for both sales and purchase, then tax paid at the time of purchase will be shown as a negative liability on the financial reports, which is not a correct way of representation. If we use separate GL account then this tax will be shown in Asset section. > 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)