This wizard also reconciles automatically entries done on reconcilable accounts. It can hence for example be used to "move" the balance of a receivable account into a payable account (or the opposite), using the generated transfer entry to do as if the receivable and payable accounts were directly reconciled together.
[IMP] account: display 'P' as matching number when account.move.line objects are partially reconciled
For this, we introduce a new matching_number field, used in account.move.line's tree views instead of full_reconcile_id, which used to be shown directly.
Was task: 2037318
closesodoo/odoo#39415
Related: odoo/enterprise#6544
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create a 10 % purchase tax with price included
- Create a Purchase Receipt with a price unit of 100 and the 10 % tax
The total is 90.91 + 8.26 = 99.17.
The root cause of the issue is that... actually I have no idea. For some
mysterious reasons, in case of an `in_invoice`, `in_refund` and
`in_receipt`, we go through `_compute_base_line_taxes` when the price is
changed. In case of the `in_receipt`, we compute the tax based on the
`balance` (= 90.91) rather than the price unit, which screws things up.
Note that in case of `out_*` moves, we simply don't go through
`_compute_base_line_taxes` at all, so Sales Receipts are fine.
opw-2170975
closesodoo/odoo#43475
X-original-commit: 1bbf66937c2b4fdb45318652e3ed1147f1edd29b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The creation of an account with a single character code crashes.
opw-2176764
closesodoo/odoo#43455
X-original-commit: 7b1e881e60d6424f7b3a676c06a4b5b8a222d025
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
=======
When the customer and supplier boolean fields were dropped
from res.partner in 13.0, the 'customers' and 'vendors' filters
were removed as well.
Two new 'customers' and 'vendors' filters have since been added
in the account module.
They might look identical to the former ones at first, but those
are instead based on two brand new 'rank' integer fields:
customer_rank and supplier_rank.
Those fields start off at zero and are increased by one each
time an in_invoice/out_invoice line is posted for the res.partner.
This means that, to be considered as a customer, a res.partner
has to have at least one invoice line posted.
This has stem confusion in both former and new users of Odoo:
- users do not have a clear idea of how this filter actually
works. (I personally had to go through xml and python code to
understand how to turn a res.partner into a 'customer')
- to the users that were used to the 'customer/supplier' boolean
fields, it simply looks like the old filters stayed while the
boolean fields were removed
- one of the reason why we got rid of the 'is a customer' field,
is that there is no unanimous definition of what a customer
actually is
- is it when the lead is won? when the quotation is
created/sent/confirmed? when the invoice is
created/sent/confirmed?
- here, we decided that is it when the invoice is posted,
but whether the user agrees or not with this definition,
there is no way for him to know this is where we decided
to draw the line
A simple way to clarify all this is to rename the 'Customers' and
'Vendors' filters to make it obvious that they are based on the
customer invoices and vendor bills.
closesodoo/odoo#43349
Taskid: 2166410
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- 'partial' payment state corresponds to invoices whose payable/receivable move line has been partially reconciled with some other line.
- 'reversed' payment state corresponds to entries that have been cancelled by the creation of a single reverse entry (using the dedicated button on the form view). This state can be set on invoice as well as on regular entries.
=> To stay consistent with the naming conventions, this commit also renames invoice_payment_state field to payment_state, since it's no longer only applicable on invoices.
closesodoo/odoo#41723
Related: odoo/enterprise#7202
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Purpose
=======
Fix multi-company access issues following the big changes that happened
(the 13.0). Make the usability better in order to avoid potential
multi-company issues for the user.
Specification
=============
Check the related commits to see the different fixes that have been
made. For more information about the technical/functional considerations,
check the related task.
closesodoo/odoo#43321
Taskid: 2088891
Forward-port-of: odoo/odoo#43230
Forward-port-of: odoo/odoo#42418
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Description of the issue:
Transfer between Bank1 (550001) and Bank 2 (550002) of the same company via the intercompany bank account (580000) :
Bank 1: minus 1000 EUR, we create the following accounting entry via the reconcile widget
account 550001 credit 1000
account 580000 debit 1000
Bank 2 : Plus 1000 EUR
When we select the counterparty 580000 entry of the Bank 1 statement via the reconcile widget
than the statement_line_id of the entry from Bank 1 statement is replaced by the one of the Bank 2 statement.
Hence this account.move.line is linked to the wrong statement line.
closesodoo/odoo#43371
X-original-commit: 3d74e7397e15311f1e9189589a435d9683376317
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Purpose
Fix multi-company access issues following the big changes that happened
(the 13.0). Make the usability better in order to avoid potential
multi-company issues for the user.
Specification
Check the related commits to see the different fixes that have been
made. For more information about the technical/functional considerations,
check the related task.
Taskid: 2088891
X-original-commit: 5c8df3a5e5f7960e5eab6439e0a32a06224ba826
Before this commit, bank accounts tab on partner view is available directly
in base whereas it should not, as it contains information useful only
for accountants. We therefore move them directly to account.
Task ID: 2172260
closesodoo/odoo#43322
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
If neither Invoicing nor Accounting are installed, users are stuck with menus
items to create bank-related informations (Banks and Bank accounts). They won't
be able to set these information directly on their contacts.
After this commit:
The Bank Accounts part of the Invoicing tab has been moved from the `account`
module to `base`, so it's now visible in the partner form even when only
`contacts` is installed
Task ID: 2126832
closesodoo/odoo#40563
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When switching a invoice to a refund, the bank account to which the move
should be paid should be removed: while it (might) contain the partner's
bank account before, when becoming a refund it makes no sense to keep
the partner's bank account as the recipient.
closesodoo/odoo#43176
X-original-commit: e94234f435622b7de00c917ca7c6302fd6c92881
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Before the merge of account.invoice with account.move, a group of taxes was
expanded on journal items and not on invoice lines. Since both are now the
same thing, we only get the group of taxes when using the 'tax_ids' field.
To correctly handle this new behavior, we need to call 'flatten_taxes_hierarchy'
every time we use the 'tax_ids' field to get the children taxes instead of the
group of taxes itself.
[FIX] account: Wrong unit price with included tax and fiscal position
Steps to reproduce the bug:
Let's consider a sale included tax T1 of 10% and a sale excluded tax T2 of 0%
Let's consider a product P with T1 and a sale price of 110€
Let's consider a fiscal position FP that mappes T1 to T2
Let's consider a customer C with FP as fiscal position
Create a customer invoice for C
Add P on the first line and T1 is replaced by T2
Bug:
The unit price of P was still 110€ instead of 100€ because the included tax was not removed from the base
price of P.
Same behavior as in 11.0 and 12.0
opw:2150564
closes odoo/odoo#43100
Co-author: simongoffin (sig@odoo.com)
Forward-port-of: #42926
Forward-port-of: #42188
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
If the opening entry is balanced, the auto-balance line is unlinked.
However, before unlinking we test if it is balanced, which it is not. A
solution is removing the line from the move and it will be unlinked
automatically.
closesodoo/odoo#43045
X-original-commit: 56ecc9c4c2e9dcc3e06ee0a388d439845ddeedfc
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Activate Multicurrency
Create a Journal Entry with default currency (USD)
Save
Error will trigger because of the sql constraint
'check_amount_currency_balance_sign'
The currency_id and company_currency_id are the same while they
shouldn't because company_id should be unset if it is the same as the
company_currency.
Fix to update the error message to let the user know that it's best to
keep the field empty so the company_id would not be set
opw-2169523
closesodoo/odoo#43082
X-original-commit: 6a420921818d741d48bf873e0a62a220c135fbfa
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This feature has been lost when removing the account.invoice model.
closesodoo/odoo#43060
--task: 2154792
X-original-commit: 7615030fb293356fc5540ba65afa66ff71b207c1
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- In a multi currency company, create an invoice with the domestic
currency ($);
- Add a product (500$) with taxes;
- Change the currency to a foreign one (€);
- The product don't change of amount but only of currency (500€);
- Save the invoice, and print it.
Before this commit, the base_amount_tax of the tax wasn't be updated.
Note that the base_amount_tax it should be expressed in domestic
currency. As this field didn't update in this case, the base_amount_tax
is expressing the amount in foreign currency. As this amount is supposed
to be in domestic, for the sake of the reports, it's change in currency
of the invoice (in this case the foreign one), and it's shown in the
report. The amount shown is not correct.
Now, the base_amount_tax is recompute and setted in domestic currency.
opw-2157853
closesodoo/odoo#43071
X-original-commit: 226a1155124e890d00e33968feb43b9fd6b99fa5
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Create an invoice, click on send and print without an associated
template.
Traceback will occur because the lang parameter is set correctly only
from a template. Adding a fallback in case there is no template setting
opw-2168623
closesodoo/odoo#43008
X-original-commit: 8fd8fdcf0fa6fb26a1797ad2b40fcaf34d23eee2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create a journal.
- Create a vendor bill on this journal.
=> Odoo allows you to set a starting sequence number for your invoice.
This number must always use the sequence used when posting the invoice.
However, the invoice date was taken instead of the accounting date.
Before this commit, when setting an invoice date at Y and an accounting date at Y - 1,
the edited sequence was the one in Y - 1 but at the one in Y was used at the validation.
Manual forward-port of 42579
closesodoo/odoo#42914
X-original-commit: 525b5b1a8676e4d1ed1082505c33afb29fed6a42
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
In 13.0, account.invoice.line `name` Text field was transformed into
account.move.line `name` Char field.
So when we want to have this field on several line, we need to specify
the widget `text` instead of `char` explicitely.
opw-2160694
closes#42395closesodoo/odoo#42476
X-original-commit: 18bb3788a9de474c4c5f4aff8d3e51dde547c86a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When you create a new bank account from an account.move there is a very high chance that you're creating the bank account for this specific vendor. As we can create a bank account from the account.move we can directly set the vendor (account holder) if there is one set
closesodoo/odoo#42788
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create a customer invoice.
- Validate it.
- A payment reference (`invoice_payment_ref`) is given.
- Refund with option 'Full refund and new draft invoice'
The `invoice_payment_ref` field is kept on the draft invoice, while we
want a new reference since it is a new invoice.
opw-2159166
closesodoo/odoo#42832
X-original-commit: 77c28421e6c7711e3d3c39dbece4e2bfa0b26b5c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In v12, it was possible to add an internal note on a journal entry.
In order to retrieve this feature, we add the field in the 'Other Info'
tab. Note that this tab is only displayed for journal entries, not
invoices. Therefore, the same field is not displayed twice.
opw-2167108
closesodoo/odoo#42825
X-original-commit: 764536c0620c9d80d1e9c59a8c8186c9e33861eb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When an account of type receivable or payable is used as default debit
account or default credit account of a journal of type sale or
purchases, an error is raised.
Now, constraints are added to avoid this.
opw-2151924
closesodoo/odoo#42817
X-original-commit: 0c90eb50b352ee003d52ef927260d1b9310ec69f
Related: odoo/enterprise#7562
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Create multiple tax and assign them to the same tax group. Now create an
invoice, in the line add all the taxes in the group. Save and click on
"Preview". In the tax recap the tax group will be reported applied on a
total equal to the number of used taxes multiplied by the total of the
product. This append because in the calculation the tax are included
multiple times and not just once per group.
opw-2158989
closesodoo/odoo#42814
X-original-commit: 261c528b87bd8e5b5e4cd0dbaf01c49197bf192c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Create a journal entry JE
- Add a partner P and an account A
- Click on 'Add a line'
Bug:
A line with P and A was suggested instead of only P as smart suggestion
opw:2152827
closesodoo/odoo#42699
X-original-commit: b71143bb3d68ed5ecab97e45699f001914bbc00f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Tests about financial reports could be not determinist because the tests are made
using two companies having the same chart of accounts.
closesodoo/odoo#42226
Related: odoo/enterprise#6432
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before this commit, the corrected test crashed when the current
date was before the arbitrary dates of the test
because the wrong exchange rate was taken
After this commit, the test passes
closesodoo/odoo#42671
X-original-commit: 5867e9bf0cc745d7b1b3dcf76bc94567e859cff7
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce:
-install accounting
-go to accounting > accounting > assets
-create a deprecable asset (account moves for deprecations
are set automatically)
-change your user's language to blank
-try to post one of the automatically created deprecations line
Previous behavior:
you get a traceback error
"TypeError: strftime() argument 1 must be str, not bool"
Current behavior:
you get the intended error message
opw-2162318
closesodoo/odoo#42641
X-original-commit: 6cd38a64893428db5c2b30e85b09a34b90aa8f4f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This method makes a write on res.company but many people do not have
access to the company
closesodoo/odoo#42644
X-original-commit: 130f08f13b49a529c1da0e1dc603c62337842f45
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When an invoice is duplicated, the `invoice_date` is not carried over.
If the field is not set, it will be set at posting at the current date.
closesodoo/odoo#42622
X-original-commit: 135d3db7b9b222be198e91235657bbef77d2f69b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Activate multicurrency. The default currency for the company should be
USD. Make an invoice in EUR, with taxes, save and create the invoice.
The tax section will display the correct tax amount but the displayed
amount on which the tax should be applied is wrong: it's displayed the
amount in the company currency rather than the invoice currency.
Adding a _convert step to restore the correct currency since that
information does not appear to be saved in the database
opw-2161039
closesodoo/odoo#42494
X-original-commit: f9a8015ef8231a23cf8e5552c08248cfc95e977c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
TaskID: 2088586
Beside this override, the records in timesheets often change order
because the date field is a date type and then, many timesheets can
have the same date, thus the order isn't the same every time.
When we remove this override in account module, the default order is
restore for account.analytic.line model and it's 'date desc, id desc',
with this order, we keep the same order every time in the different
views of timesheet.
The recent refactoring made at 30cf7bc798 introduces a new object for the different writeoff lines that could be created from a reconciliation model. Unfortunately, Billing users were forgotten during that refactoring which made them unable to read/use the reconciliation models anymore.
This patch grants them the Read and Create permission on the new account.reconcile.model.line object, as they already have to the reconciliation model.
closesodoo/odoo#42009
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
There is actually nothing preventing changing the company of some records even
there is some journal entries/items that are using them.
closesodoo/odoo#41945
X-original-commit: b3b66304eb98819cd87d6e4c7a29ca4803ffc3ff
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Be in multi-company with companies C1, C2.
Let user U1 in company C1 create a vendor bill V.
Then U1 change to company C2.
Another user U2, in company C1, tries to print the vendor bill.
Traceback: Access error trying to access U1 to render the template
opw 2145738
closesodoo/odoo#41977
X-original-commit: 5b7b12c9907d7da03e08df4f5bac2198c3dc9cba
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Slight semantics change on the behavior of _onchange_journal with
respect to payment_method_id: in the old version, it would be set to
the first method of the new journal if no default had been provided.
However if a default had been provided, a non-default method selected,
then the journal was changed, the method could remain to something
invalid. Instead, check if the method is still valid and if not reset
to either the default (if one was provided) or the journal's first.
It also seems like it'd make sense to update self.amount based on
self.invoices directly (instead of going back to the active_ids) but
TestAccountMovePayment does *not* like that.
Task 2115472
closesodoo/odoo#41868
Related: odoo/enterprise#7260
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
`possible_bank_partner_ids` is an override hook, it's not useful in
and of itself.
Task 2115472
closesodoo/odoo#41872
Related: odoo/enterprise#7261
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
It seems very strange that we'd want to use active_ids as invoices to
work with when when we already have invoices available, and these are
browsed / converted from the active_ids if they weren't provided
explicitly.
There's also an odd divergence between the filtering on the journal's
company here and in the default_get too: in the default_get we get a
journal in the user's company but then we only allow selecting a
journal from the invoices' company...
Task 2115472
closesodoo/odoo#41871
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The dynamic domain really seems wholly unnecessary (though the static
one does require adding a field to a bunch of views)
Task 2115472
closesodoo/odoo#41870
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Pretty straightforward so long as you know `current_company_id` is the
currently active company for the user, which is exactly what we need.
Task 2115472
closesodoo/odoo#41869
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
oco-odoo