The field tax_amount is fieled with onchanges and the compute_tax method. Setting a different value than the one computed by the system may lead to unbalanced move (which is obviously wrong).
In the future, handeling these operations by setting the correct value to the tax accounts would be better.
The field partner_id is not required on an account.voucher but the validation was failing if none was set (opw 611663).
This patch makes a fallback on the account of the voucher if neither a partner nor a writeoff account is specified.
Fixing several issues for refunds in multicurrency mode that prevented the moves to be balanced.
The amount_currency needs to use the absolute value, as a refund will have a negative amount.
The sign for currency_rate_difference needs to use the line instead of the voucher as they can have different value. e.g. a voucher of 1000$ with invoice of 1200$ and refund of 200$ will have two lines and their currency_rate_difference should have different signs.
Avoids doubling the value in foreign_currency_diff
Fixes#1490, opw 607118 & 611580
When we cancel a voucher, we may be trying to unlink a reconciliation that was already removed on another move (just looking at the version in cache). In such cases, the unlink would fail with traceback. opw 610287
When the user who validated and closed the pos session was not the same user who created the session, and if this user was not in the same company, it wasnt possible to validate and close the pos session.
This explanation if also valid if the user who created the pos session changed of company in his preferences between the creation and the validation.
bzr revid: dle@openerp.com-20140206163444-ckcmurcwk2vhi5vp
When importing invoices to a bank statement the bank statement lines are created with statement date instead of today
Set the date on the created voucher in the same wizard to the statement date instead of invoice date (problematic if different period)
When creating the account moves (at bank statement confirmation), make sur the date and period of the vouncher are synchronised
bzr revid: mat@openerp.com-20140129172009-vbp5n1nco51kaly8
This bug may have generated incorrect account_voucher_line when validating a voucher with amount less than 1. This patch will avoid reproducing the problem on new lines but not fix already existing vouchers. To do so apply the following steps:
1. apply this patch
2. do a manual reconciliation of the account.move.lines with amount less than 1 (use the manual reconciliation menu to see every line, included 0-0 lines)
3. execute the following SQL query
DELETE FROM account_voucher_line WHERE id IN (SELECT l.id FROM account_voucher_line AS l JOIN account_voucher AS v ON (v.id = l.voucher_id) JOIN account_move_line AS ml ON (l.move_line_id = ml.id) WHERE l.amount = 0 AND v.state = 'draft' AND ml.debit = ml.credit AND ml.credit = 0);
that will remove account voucher lines from draft vouchers linked to an empty move lines
bzr revid: mat@openerp.com-20130802120311-oh64d47t8x6t1wf9
*uniformized the computation in multi-currency in order to always use res_currency.compute()
*make sure to pass the right conversion rate to _current_rate() function using the context if it is specified on the voucher and, in this function, used the info from the context instead of the computed one if relevant. (This involves an ugly overwriting of the 'rate' field that will disappear in trunk: to stay backward compatible and avoid any update of 'base' module it has to be done this way).
*replace the currency_id field on the voucher by a fields.function (was a fields.related) in order to always have a currency, even if it's a voucher in the company currency. (makes the treatment easier and more consistent. Less error prone)
*misc code reaftoring
bzr revid: qdp-launchpad@openerp.com-20130502225937-ya45q2wvgqy7zo1c
This patch will be forward ported in trunk by changing the behaviour of account_period.find() in order to fetch the normal periods by default (account_period_prefer_normal will be True by default) because there are no business case i could think of where you'd like to get the opening period (except in the closure but it's held in a different way there). On the other hand, it's pretty easy to forget to put that key in the context and introduce a new bug that will select the opening period instead of the wanted one
bzr revid: qdp-launchpad@openerp.com-20130418102433-t52uj23trkpr8vnb
Martin Trigaux
Ravi Gohil
Amit Dodiya
Denis Ledoux
Quentin (OpenERP)
Foram Katharotiya (OpenERP)
Christophe Matthieu
Niels Huylebroeck
Rifakat
Somesh Khare (OpenERP)
Cedric Snauwaert
dle@openerp.com
Thibault Delavallée