When no result is found on the function field 'invoice' (account.move.line), instead of returning {move_id: (False, '')}, return {move_id: False} (expected for m2o fields)
Fixes#2138, opw 613096
Explicitely refresh invoice browse_record(...) in order to have correct 'date' in account.move.
Use context_today() date instead of time.strftime() for date_invoice. (opw 611210)
Avoid revalidating the complete account moves
that contain the lines being reconciled.
The reconciliation does not change the validity
of those moves anyway.
This represents a very important speed up of
reconciliation when moves with several hundred
lines are involved.
The residual amount is typically needed to render the
online payment forms (payment acquirers).
Payments on the other hand rely on account.move.line,
something that portal users should never be allowed to read.
Removing the field from the view by setting a model-level
group permission ensures they will not see an error.
When computing the price difference lines, in move_line_get of account_anglo_saxon, we loop on the result of super call for each lines (n * n times) to compute the price difference.
The product_id was used to match the returned line and the original invoice line. This was wrong as we could get several lines with the same product_id (and then get n * n price difference lines).
This patch adds the line id to the result of move_line_get (from account) so that account_anglo_saxon can filter more efficiently and only get one price difference per invoice line.
Fixes#704
If we try to generate twice entries on the same fiscal year, we can get completly unrelated errors ("You can only reconcile journal items with the same partner").
With this, we make sure people will first cancel the entries before regeneraing the entries.
The wizard to generate recurring entries did not respect multicompany rules as the request was done in plain sql.
Add ir.rule and use the orm (opw 607782)
Prior to this fix, the domain was set in the onchange methods onchange_company_id. Therefore, if the onchange was not triggered, the domain wasnt apply (e.g. while editing an existing invoice).
The field note on account.fiscal.position and account.fiscal.position.template should not be translatable in classic modules.
The l10n_multilang module is intendend to make chart of accounts multilang and is the place to set translate=True
In the account.invoice.line form, do not assume the parent is defined when
evaluating the context to invoice_line_tax_id as we could come from another
view (e.g.: purchase order line form).
Fixes#206
Denis Ledoux
Ferdinand Gassauer
dhr-odoo
Ravi Gohil
Humberto Arocha
Martin Trigaux
Christophe Simonis
Olivier Dony
Ruchir Shukla
fka-odoo
Anael Closson
Yannick Vaucher
Jeremy Kersten
Alexandre Fayolle