← Back to team overview

c2c-oerpscenario team mailing list archive

Re: [Bug 741863] Re: [6.0] Cash and bank journals are unintendedly created as refund journals

 

On Wednesday 30 March 2011, you wrote:
> Hi Azazahmed,
> 
> if you add the field 'refund_journal' to the tree view you will see what
> I mean.
> 

Confirmed and solved the issue. Thanks Stephan.

BQI account.journal> table id, name, type, refund_journal from search_read([])
[2011-03-30 11:18:30] INFO:web-services:successful login from 'admin' using 
database 'test_bqi'
id|        name        |      type     |refund_journal
------------------------------------------------------
13|Current             |bank           |False         
14|Deposit             |bank           |False         
15|Cash                |cash           |False         
12|Purchase Refund Jour|purchase_refund|True          
10|Purchase Journal    |purchase       |False         
9 |Sales Journal       |sale           |False         
11|Sales Refund Journal|sale_refund    |True          
5 |Bank Journal - (test|bank           |False         
6 |Checks Journal - (te|bank           |False         
7 |Cash Journal - (test|cash           |False         
4 |Expenses Credit Note|purchase_refund|True          
3 |Expenses Journal - (|purchase       |False         
1 |Sales Journal - (tes|sale           |False         
2 |Sales Credit Note Jo|sale_refund    |True

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/741863

Title:
  [6.0] Cash and bank journals are unintendedly created as refund
  journals

Status in OpenERP Modules (addons):
  Incomplete

Bug description:
  In 6.0 head, the chart of accounts wizard creates bank and cash
  journals as refund journals. This is an unintended consequence of the
  fact that the same python dictionary is reused for journal creation,
  right after the creation of the refund journals. The 'refund_journal'
  boolean value is never overwritten or deleted.

  We noticed this when manually encoding cash entries on accounts with
  default taxes messed up our tax report.

  The same problem does not appear to exist in trunk anymore due to a
  rewrite of this part of the code.



References