When creating an invoice with a fiscal position(fp) which maps an included tax(itax)
to an excluded tax(etax). Each invoice line mapped by fp must recompute its unit price
to substract the included tax.
Inspired from 503820aCloses#9811
opw:658109
It was impossible to make a partial reconciliation with several lines.
Each time a new line is proposed for the reconciliation, the previous
partial reconcialtion is canceled. The partial reconciliation can just
be proposed on the last selected line when:
self.get("balance") * (last_line.debit - last_line.credit)<0
The `account.account` `name` can be translated
as soon as `l10n_multilang` is installed.
Not passing the context in the calls to
the `search` method prevented to search
on the translations of this name.
Closes#4511
During reconciliation wizard, the wizard tries to find the best match with
exisiting unreconciled lines.
When more than one line could be reconciled with the bank statement line, the
oldest line was not selected.
e.g.
- statemement line: 10€
- invoice 1: 10€
- invoice 2: 10€
- invoice 3: 5€
The statement line was reconciled with the 5€ invoice instead of the first one.
This was due to the domain not matching when the exact same amount was found.
Sign CLA for compassionCH
Closes#8767
The domain for the analytic account in the `reconcile with writeoff` wizard
should be based on the `type` field, which must be `view`,
not on the `parent_id` field, as it's done everywhere else
(e.g. in the supplier invoice form).
`[('parent_id', '!=', False)]`
and
`[('type', '!=', 'view')]`
is almost the same, but the second domain is more appropriate.
Closes#4562
In the case where target_currency == company_currency, the actual_debit or the
actual_credit must be equal to the amount_residual defined on the account.move.line
and expressed in the currency of the company. The actual_debit/actual_credit must
take into account the possible partial reconciliations and this is done by the
residual amount.
opw:648744
In Accounting > Bank and Cash > Cash Registers, when clicking in "More" button
on 'Put Money In' or 'Take Money out', the date used for the bank statement line
created must be the date of the bank stattement(same behaviour then when clicking
on "Add item" in edit mode). It's forbidden to put/take money in/out for a bank
statement which is not open.
opw:647631
When a account.bank.statement.line is created by clicking on "Put Money In"
(Accounting(Menu)>Bank and Cash(Menu)>Cash Registers(Menu)>More(Button)>"Put Money In"),
the account.bank.statement linked to this line must be updated(by passing in the write of
this model) to compute the real closing balance. This fix allow to have the same
behaviour than when a line is manually added (with "Add Item) in an account.bank.statement.
opw:647631
With 3e82c94d we use the timezone in the context to format date
sequences when formatting an ir.sequence.
This commit adds the other missing context when getting a sequence, so
these sequences are also dependant on the timezone.
closes#8351
opw-646487
In bank statement reconciliation, when selecting an other partner(with the pencil),
the possible invoices to reconcile must be suggested.
opw:647210, 647885
It has no sens to map a tax by a tax included in the price because
when a tax is included in the price, the price must be computed
according to this tax.
-account:_fix_tax_included_price
If a fiscal position mapped an included tax on a SO or on a PO line
then the price unit of the product must be recomputed.
-purchase: onchange_product_id test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
-sale:product_id_change test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
opw:647321
This revision is related to cfbd086b09.
This is the same use case than above, but with a different
currency than the one of the company, for the field
`amount_currency` this time.
Closes#8135
opw-647639
The propositions of reconciliation for a bank statement line must
be taken from account move lines with the same partner_id of this
bank statement line or without partner_id.
opw:647199
When converting an invoice in journal entries,
the invoice lines amounts must be currency rounded
not only when the invoice currency is different
than the company invoice,
but also when they are the same.
Otherwise, a rounding issue can happen
if the `Account` decimal accuracy is greater
than the currency rounding, the journal entries
total and the invoice total could be different.
e.g.
- Set decimal accuracy of Account and product to 4
- Create a supplier invoice, any supplier
- Add a line as follow:
- Product: None
- Quantity: 2057
- Price unit: 11.9150
- Tax: 16% (create a new tax with 0.16 as percentage)
- Validate the invoice
- In the other information tab of the invoice,
click on the journal entry
- Notice that the first line has as credit amount 28430.6150
While the invoice total is 28430.6200
- Now if you try to create a bank statement with one line
of -28430.6200 and as partner the supplier you chose
in the second step of this explanation, and try
to reconciliate it to the invoice created above,
the above won't be marked as paid, while it should.
opw-647639
Fixes#8135
The string belongs to the account module, but was wrongly added to
stock.pot. This commit adds it to account.pot, but also keeps it for the
moment in stock.pot to prevent losing existing translations in
Transifex.
When creating a new bank account
e.g. Accounting > Configuration > Accounts >
Setup your Bank Accounts
When the user leaves the journal blank,
a journal, and an account associated to this
journal, are automatically created.
The account type of the account created could be wrong,
as it used the account type of the parent of the first
account of internal type `Liquidity`, which
could not be an account of account type Cash or Bank, but of
account type 'View', and such an account type does not
have the right delivery forward method, in order to report
correctly the amounts when closing a fiscal year.
Instead of using the account type of the parent,
it should actually uses the account type of the sibbling,
which have a correct delivery forward method
opw-647311
in method `button_confirm_cash` of `account.cash.statement`
The check was verifying that the profit/loss account
was set on the journal, and if it was, it raised that it
wasn't, which is obviously wrong.
This was solved in Odoo 8.0 by replacing the code
by something more readable in 9dc9169, and the same
logic to check that the profit/loss accounts are
set is still there.
Closes#2924