[ 
https://issues.apache.org/jira/browse/OFBIZ-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacopo Cappellato resolved OFBIZ-885.
-------------------------------------

    Resolution: Cannot Reproduce

It seems that this issue has been fixed some time ago and cannot be recreated 
in trunk and in the release branch 4.0.

> Multiple issuances, one tax item on invoice
> -------------------------------------------
>
>                 Key: OFBIZ-885
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-885
>             Project: OFBiz (The Open for Business Project)
>          Issue Type: Bug
>          Components: accounting
>            Reporter: Iain Fogg
>         Assigned To: Jacopo Cappellato
>            Priority: Critical
>
> I have a couple of sales orders, and through the course of picking/packing 
> multiple item issuances from different inventory items were generated for the 
> order. Eg, customer orders 4 of item X, and we issued 2+1+1 items from 
> inventory as they came into stock.
> When I pack the order, and generate the invoice, a tax adjustment is created 
> for only one of the issuances, and consequently total tax is being wrongly 
> reported on the invoice. 
> On the invoice I can see entries for:
> (a) 2 x item X
> (b) tax on 2 x item X
> (c)1 x item X
> (d) 1 x item X
>      (no tax on the last 2 items)
> Both invoices that exhibit this problem have the same characteristic - 
> multiple issuances  for a single product id.
> Has anyone else seen this, or can point at a fix? I suspect the problem is in 
> .../accounting.../InvoiceServices.java (createInvoiceForOrder).
> It looks like when the invoice items are being generated it is trying to work 
> out when NOT to create another invoice adjustment by comparing the 
> adjAlreadyInvoicedAmount to the amount of "this" adjustment. In my example, 
> when it processes the adjustment for (c) above, it sees that we've already 
> invoiced for 1/2 the total tax adjustment (b), and the this is greater than 
> the tax adjustment for (c), so happily "continue"s to the next adjustment.
> This is a bug, right? (that's a rhetorical question :-)
> Cheers, Iain

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to