You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by "Martin Kreidenweis (Commented) (JIRA)" <ji...@apache.org> on 2012/03/23 16:21:33 UTC

[jira] [Commented] (OFBIZ-4514) Taxes are not handled correctly when creating accounting transactions from purchase invoices

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

Martin Kreidenweis commented on OFBIZ-4514:
-------------------------------------------

Hi, 

I've found some time now to explain what our patch is doing. 

The changes are actually in production in our system and generate correct accounting for the German tax system. 
When we have sales tax in a purchase invoice it means that we actually get a tax refund/rebate ("Vorsteuer"). 

The change at @@ -2144,6 +2122,18 @@ sets the glAccountId in the acctgTransEntry according to the tax authority party and geo id found in the invoice items. This is necessary so that the right account for the tax authority is used in the posting of the transaction. 
The changes were basically copied from the {{createAcctgTransForSalesInvoice}} method, where the same logic is implemented. (For sales invoices we have to pay taxes, so it is a creditEntry. For purchase invoices we get a tax rebate, so it is a debitEntry.)
The change at @@ -2165,6 +2155,7 @@ also just makes the purchase invoice code more like the sales invoice code. The unattributedTaxTotal has to be posted to a tax account. In the sales invoice this is already set, in the purchase invoice it isn't -- the patch fixes that. This is basically like the fallback in the change @@ -2144,6 +2122,18 @@, where we set the same value when we can't find a matching configuration for the tax authority. In case we have unattributed tax entries, we don't even need to try to find a tax authority configuration and simply set the fallback account type, so it gets posted to the default tax account. 

Regarding @@ -2173,6 +2164,10 @@: The call to {{getInvoiceTaxTotal}} was simply missing here. A few lines down the variable {{invoiceTaxTotal}} is accessed. Without applying the patch it is never set. 

Jacopo is right for @@ -1841,28 +1841,6 @@ and @@ -2359,39 +2354,6 @@ -- they are just (unrelated) cleanup. Like the comment says, the functionality has moved to the createAcctgTransAndEntriesForPaymentApplication method, and as far as I can tell is working correctly. 

I hope the changes make more sense now. 

Best Regards, 
Martin
                
> Taxes are not handled correctly when creating accounting transactions from purchase invoices
> --------------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-4514
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-4514
>             Project: OFBiz
>          Issue Type: Wish
>          Components: accounting
>    Affects Versions: SVN trunk
>            Reporter: Martin Kreidenweis
>            Priority: Trivial
>         Attachments: OFBIZ-4514.patch
>
>
> Taxes are not handled correctly when creating accounting transactions from purchase invoices in GeneralLedgerServices#createAcctgTransForPurchaseInvoice

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira