The `amount_residual` computation depends on the fact
the `acccount_id` of the move line does allow reconciliation
or not. If it doesn't, the amount residual will always be 0.0.
So, if you check the "allow reconciliation" on the account
after creating the journal items or after changing the
debit/credit amount, the amount residual is not recomputed.
We do not set the `depends` directly on `account_id.reconcile`,
as, if we do, and a user checks/unchecks this box on an account
having a lot of records, this will recompute this residual
amount on all lines, and this is something we do not want
to happen.
The work-around when this case happens,
that the amount residual is not correct due to the fact
the `allow reconciliation` on the account
was checked after having posted the entry,
is to cancel the entry and repost it. This
will recompute the residual amount.
opw-656972
The invoice date of demo data is changed to match the current
month/year. The original issue is the following:
- install accounting, keep default configuration (company currency: USD)
- add a payment for Agrolait in USD (e.g. $10,000)
- go to customer invoice demo_invoice_2 (which is in EUR)
- the system proposes you to add a outstanding payment to pay the
invoice -> do it
The invoice is not shown as fully paid, but on the other hand if you
click again to add an outstanding payment, nothing happens.
The reason of this bug is because for this specific bill, the currency
rate has changed between the invoice date and the payment date. The
amount used to pay the bill: this is the price in USD, at the rate
corresponding to the date of the invoice (i.e., what you were supposed
to pay at the time of invoicing). The fact that is does not mark your
bill as paid is also correct: the payment is written with the rate at
the date of the payment, and in this case, the invoice is not fully
paid. You should therefore reconcile the invoice and create a write-off
afterwards to register the exchange rate difference.
This unusual situation (pay an invoice in a different currency, and
moreover the rate has changed) has not been taken into account for v9,
and there is no clean solution which can be foreseen for a stable
version.
However, since this situation arises right away with the demo data, this
can be very misleading for a new user. The fix simply changes the date
of the invoices, so that there will be no rate change between the
invoice date and the payment date with the demo data.
opw-657151
The fields Total Receivable and Payable are calculated as debit-credit.
However, this leads to a wrong computation if, for example, a payment is
used to pay several invoices. For example:
- Create a customer invoice of 2500 USD
- Register a payment of 3000 USD
The Total Receivable will be 3000 USD instead of 500 USD.
At the same time, this commits changes the sign of the field. The help
depicts the Total Receivable field as "Total amount this customer owes
you". Therefore, one would expect that if the customer owes 250 USD, the
Total Receivable is 250 USD, not -250 USD.
The same logic applies to Total Payable.
opw-657053
The error message on the journal entry for currency was wrong.
The multi-currency view does not exists anymore in 9.0 so is no longer relevant.
To avoid breaking existing translations, create a en translation.
Rename the en_US.po to en.po to be used by _GB and _AU
Will be fixed in saas-7 by the mighty @csnauwaert 📯
The method `process_reconciliations` is written in api.v7.
Therefore, any calls done on ORM models must be done
in the 7.0 API in this method.
To reproduce the issue:
- Open a pos session, and sell something, select a partner
and choose to create an invoice.
- Come back to the back-end, and in the accounting dashboard,
in Customer Invoices > More > Matching payment,
hit ctrl-enter to reconcile all the balanced items in the sheet.
opw-654410
The sequence of the first account.payment.term.line must be 9 because
the default sequence for a new line is 10.
Before the fix:
When changing the value of the default line by "percent" and adding a
new line with value equal to "balance". An exception was raised because
the sequence of the default line was 500 and then this default line was
always considered as the last one.
opw:656704
This rev. is related to 3dd79b3d65.
Both `journal_id` and `date` on `account.move.line` are
related from the `move_id` of the line.
Besides, the move associated to these move lines is
created with the same values, in
`_prepare_reconciliation_move`:
- The move `date` is set with `self.date`,
exactly the same than what was set in the `aml_dict`
- The move `journal_id` is set with `self.statement_id.journal_id.id`,
which is the origin field of the related field `self.journal_id.id`
used in the `aml_dict`
opw-656463
The field `company_id` on `account.move.line`
is a related to the `company_id` field of the
`account_id` field on this move line.
Therefore:
- Forcing the company of the `account.move.line` to the
company of the `account.bank.statement.line` is pointless,
as this field is supposed to be a related from the `account_id`
of the move line. It's the `account_id` that must be set correctly,
to an `account.account` of the right company. This is the case, btw.
- Forcing the company of the `account.move.line` triggers the
write of the `company_id` on the related `account.account`, which
triggers the write of the `company_id` on all `account.move.line`
records having as `account_id` this `account.account`.
Therefore, the more you had move lines on an `account.account`,
the more the reconciliation was slow for move lines with this `account_id`.
opw-656463
When a partner is created, the fiscal position is set automatically if
possible. This is not correct, the fiscal position should only be set
automatically on a SO, based on the delivery address.
Here is a scenario explaining the reason:
- Create 2 fiscal positions, one in US and one in Canada. Both fiscal
positions apply automatically depending on the country.
- As an non-logged user, go in the web shop
- Buy a product
- At the checkout phase, the Billing Information are in US, but the
Shipping Information in Canada.
- The fiscal position which will apply will be US, while you expect it
to be Canada
The reason is that the fical position which applies is the one on the
parent partner (US in this case), since all children partners must have
the same accounting data.
With this fix, we simply remove the automatic setting of the fiscal
position on the partner.
opw-653072
When a payment is created for a bill, this is always the 'commercial_partner_id'
which is used as 'partner_id'.
Then:
-When registering a payment with several bills, the 'commercial_partner_id'
field of these bills must be the same.
-When grouping bills by partner, the groups must contain all the bills from
the same 'commercial_partner_id'.
opw:653005
When an account.move.line(aml) is created for a reconciliation, the date
used in the aml must be the date of the bank.statement.line used to
create the aml.
opw:653335
This commit was necessary to fix weird problems in 9.0-nightly.
Phantomjs and the old nvd3 implementations did not play well together.
* transitionDuration() replaced by duration()
* tooltips() & tooltipContent replaced by tooltip.enable and tooltip.contentGenerator
* remove useless less for tooltip
Thanks to mge for his help
The method `compute_all` of `account.tax` in api.v8
expects a currency browse record, not a currency id.
It's the `compute_all` of api.v7
that expects a currency id.
opw-653106
`vals[tax_ids]` can be a command triplet,
see:
https://www.odoo.com/documentation/master/reference/orm.html#openerp.models.Model.write
Doing
`tax_ids = map(lambda tax: tax[1], vals['tax_ids'])`
to resolve the command doesn't work for all triplet types,
for instance it doesn't work for triplet `(6, 0, [...])`
To resolve properly a 2many commands, `resolve_2many_commands`
should be used.
opw-653106
The below revision:
275234c067
Makes the multi-companies record rule disabled by default,
meaning the user can see contacts from other company than
his current company.
Nevertheless, to read the computed field `currency_id` on
the `res.partner` model, the user need the read access
on the contact `company_id` field, that the user does not have
if the partner company is not a child of the user current company.
opw-653103
When reversing entries in Journal Entry, each entry(account.move.line)
must be copied with its own 'tax_line_id'. In this way, the action window
"act_account_tax_tax" can find all the entries linked to a specific tax
(active_id) to compute the Tax Report.
opw:652598
The amount to show in payments_widget must be the opposite of amount_currency like
in the else condition:
amount_to_show = payment.company_id.currency_id.compute(-amount, self.currency_id)
opw:652478
Fixes/hides a deadlock when running test_sale_order with either a single
database or a db_filter making a single database visible: the test
causes a report to be printed, which invokes wkhtmltopdf, which tries to
fetch assets using the registry which is being loaded. The asset request
thus waits on a lock which is held by the test which waits on the asset,
deadlocking the whole thing.
Using HttpCase means we're using the test_cr or something and bypassing
the deadlock, instead the asset requests just 404 as they do when using
the nodb routing.
When creating an invoice in a foreign currency,
and adding a line with a product,
the `onchange` failed,
due to the fact the field `date_invoice`
is not on the invoice line, but on the invoice.
qdp-odoo