Anglo-saxon Accounting does not use input stock account when purchase order invoicing control set to: “from picking” V6

Bug #708874 reported by mvhman
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Fix Released
Medium
OpenERP R&D Addons Team 2

Bug Description

V6 stable, ubuntu 9.10, launchpad version
Anglo-saxon Accounting does not use input stock account when purchase order invoicing control set to: “from picking”.
Example:
 Make sure anglo-saxon installed. Accounts setup in categories.
 Setup input and output stock correctly.
Create purchase order with invoicing control set to: “from order”
Approve purchase order then receipt shipment.
Journals:
CR Stock input account (Correct)
DR Inventory account (Correct)
Approve Invoice created from sales order.
Cr Supplier Trade Account (Correct)
Dr Tax (Correct)
Dr Stock input account (Correct)

HOWEVER:
Create new purchase order with invoicing control set to: “from picking”
Approve purchase order then receipt shipment.
CR Stock input account (Correct)
DR Inventory account (Correct)
Create invoice from validated reception.
CR Supplier Trade Account (Correct)
DR Tax (Correct)
DR Expense Account (INCORRECT)

In summary: V6 seems to work fine when the purchase order invoicing control is "from order" but not when "from picking"

Tags: maintenance

Related branches

description: updated
affects: openobject-server → openobject-addons
Changed in openobject-addons:
assignee: nobody → OpenERP R&D Addons Team 3 (openerp-dev-addons3)
importance: Undecided → Medium
status: New → Confirmed
Changed in openobject-addons:
status: Confirmed → In Progress
Revision history for this message
Mustufa Rangwala (Open ERP) (mra-tinyerp) wrote :

I have tested the Anglo-saxon module and i am agree the we got wrong account in "from picking" policy for invoice order.

But the problem arises from stock/wizard/stock_invoice_onshipping.py file where they passed type = None while creating invoice from picking. It should be type = context.get('inv_type').

So i moved it to Addons2 team they will correct it.

Changed in openobject-addons:
status: In Progress → Confirmed
assignee: OpenERP R&D Addons Team 3 (openerp-dev-addons3) → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
Changed in openobject-addons:
status: Confirmed → In Progress
Revision history for this message
Rifakat Husen (OpenERP) (rha-openerp) wrote :

Hello,

It has been fixed in lp:~openerp-commiter/openobject-addons/dev-addons2-rha1

Revision ID: <email address hidden>
Revision no: 4490

Thanks for reporting.

Changed in openobject-addons:
status: In Progress → Fix Committed
Revision history for this message
mvhman (michael-openrevolution) wrote :

I am running stable launchpad version.
What should I do to intergrate. Should branch this commiter release, or should I hardcode the change the code on my local branch.
When will this be integrated into next stable release.

Revision history for this message
Rucha (Open ERP) (rpa-openerp) wrote :

Hello Michael,
the fix is available in branch lp:~openerp-dev/openobject-addons/trunk-dev-addons2
thanks

Changed in openobject-addons:
status: Fix Committed → Fix Released
Revision history for this message
mvhman (michael-openrevolution) wrote :

changed the code on my local branch:

Using "But the problem arises from stock/wizard/stock_invoice_onshipping.py file where they passed type = None while creating invoice from picking. It should be type = context.get('inv_type')."

No luck though. It did not fix the journals.
Do I need to download the who lp:~openerp-dev/openobject-addons/trunk-dev-addons2 to get it to work.

regards,
Michael

Revision history for this message
mvhman (michael-openrevolution) wrote :

Appologies.
I downloaded the new trunk and it worked.

regards,
michael

Revision history for this message
mvhman (michael-openrevolution) wrote :

Please note: This error is still occuring in version 6.1 stable. bzr pulled 21march2012
Is there a fix for this in the new stable 6.1 version.

kind regards,
Michael

tags: added: maintenance
Revision history for this message
mvhman (michael-openrevolution) wrote : Re: [Bug 708874] Re: Anglo-saxon Accounting does not use input stock account when purchase order invoicing control set to: “from picking” V6

Hi Vinay,
Please explain what maintenance will mean?

regards,
Michael

On Thu, Mar 22, 2012 at 7:28 AM, Vinay Rana (openerp) <email address hidden>wrote:

> ** Tags added: maintenance
>
> -- Vinay
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/708874
>
> Title:
> Anglo-saxon Accounting does not use input stock account when purchase
> order invoicing control set to: “from picking” V6
>
> Status in OpenERP Addons (modules):
> Fix Released
>
> Bug description:
> V6 stable, ubuntu 9.10, launchpad version
> Anglo-saxon Accounting does not use input stock account when purchase
> order invoicing control set to: “from picking”.
> Example:
> Make sure anglo-saxon installed. Accounts setup in categories.
> Setup input and output stock correctly.
> Create purchase order with invoicing control set to: “from order”
> Approve purchase order then receipt shipment.
> Journals:
> CR Stock input account (Correct)
> DR Inventory account (Correct)
> Approve Invoice created from sales order.
> Cr Supplier Trade Account (Correct)
> Dr Tax (Correct)
> Dr Stock input account (Correct)
>
> HOWEVER:
> Create new purchase order with invoicing control set to: “from picking”
> Approve purchase order then receipt shipment.
> CR Stock input account (Correct)
> DR Inventory account (Correct)
> Create invoice from validated reception.
> CR Supplier Trade Account (Correct)
> DR Tax (Correct)
> DR Expense Account (INCORRECT)
>
> In summary: V6 seems to work fine when the purchase order invoicing
> control is "from order" but not when "from picking"
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-addons/+bug/708874/+subscriptions
>

Revision history for this message
mvhman (michael-openrevolution) wrote :

Hi Vinay,
Appologies, I have now seen where the error was. The module did not load by
default, and I thought it was now integrated into v6.1.
However it works fine.
please close this bug.

kind regards,
Michael

On Thu, Mar 22, 2012 at 9:09 PM, Michael <email address hidden>wrote:

> Hi Vinay,
> Please explain what maintenance will mean?
>
> regards,
> Michael
>
> On Thu, Mar 22, 2012 at 7:28 AM, Vinay Rana (openerp) <email address hidden>wrote:
>
>> ** Tags added: maintenance
>>
>> -- Vinay
>>
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/708874
>>
>> Title:
>> Anglo-saxon Accounting does not use input stock account when purchase
>> order invoicing control set to: “from picking” V6
>>
>> Status in OpenERP Addons (modules):
>> Fix Released
>>
>> Bug description:
>> V6 stable, ubuntu 9.10, launchpad version
>> Anglo-saxon Accounting does not use input stock account when purchase
>> order invoicing control set to: “from picking”.
>> Example:
>> Make sure anglo-saxon installed. Accounts setup in categories.
>> Setup input and output stock correctly.
>> Create purchase order with invoicing control set to: “from order”
>> Approve purchase order then receipt shipment.
>> Journals:
>> CR Stock input account (Correct)
>> DR Inventory account (Correct)
>> Approve Invoice created from sales order.
>> Cr Supplier Trade Account (Correct)
>> Dr Tax (Correct)
>> Dr Stock input account (Correct)
>>
>> HOWEVER:
>> Create new purchase order with invoicing control set to: “from picking”
>> Approve purchase order then receipt shipment.
>> CR Stock input account (Correct)
>> DR Inventory account (Correct)
>> Create invoice from validated reception.
>> CR Supplier Trade Account (Correct)
>> DR Tax (Correct)
>> DR Expense Account (INCORRECT)
>>
>> In summary: V6 seems to work fine when the purchase order invoicing
>> control is "from order" but not when "from picking"
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/openobject-addons/+bug/708874/+subscriptions
>>
>
>

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.