Odoo/addons/account/models/__init__.py, branch 14.0 The current checkout of upstream Odoo [FIX] account, mail: link attachments to invoice 2021-05-31T07:21:02+00:00 Adrien Widart awt@odoo.com 2021-05-04T14:51:12+00:00 e6c69a8cf00cd858a45ebf321a190666322c0897 When using the "Send & Print" functionality, if the user adds an attachment, the latter won't be linked to the record. To reproduce the error: 1. Open a posted invoice 2. Send & Print 3. Attach a file > Select a file on your device 4. Send the email Error: The invoice's PDF is added to record's attachments, but not the other file (from step 3). When the module selects the attachments that need to be linked to the invoice, it only keeps the ones currently linked to `mail.compose.message`: https://github.com/odoo/odoo/blob/6441ab71cb68648aa735057952bf757677a20ee3/addons/mail/models/mail_thread.py#L1719-L1725 This is correct when the user creates a message directly in the chatter. However, when the mail is created thanks to `Send & Print` functionality, the attachment is linked to `account.invoice.send`. Another flow have a similar issue: from invoices list, select few ones, Action > Send & Print: the generated PDF won't be attached to their invoice. In such a situation, here is the source of the problem: https://github.com/odoo/odoo/blob/05ad6c477f7da2a495e5baf5b4629323b9d11fa0/addons/mail/wizard/mail_compose_message.py#L363-L367 There isn't any information about the invoice, therefore it is not possible to linked the attachment to it. OPW-2438457 closes odoo/odoo#71425 X-original-commit: e87f599d4eb22250b628d650b9f59b54db8d043c Signed-off-by: Adrien Widart <adwid@users.noreply.github.com> 
When using the "Send & Print" functionality, if the user adds an
attachment, the latter won't be linked to the record.

To reproduce the error:
1. Open a posted invoice
2. Send & Print
3. Attach a file > Select a file on your device
4. Send the email

Error: The invoice's PDF is added to record's attachments, but not the
other file (from step 3).

When the module selects the attachments that need to be linked to the
invoice, it only keeps the ones currently linked to `mail.compose.message`:
https://github.com/odoo/odoo/blob/6441ab71cb68648aa735057952bf757677a20ee3/addons/mail/models/mail_thread.py#L1719-L1725
This is correct when the user creates a message directly in the chatter.
However, when the mail is created thanks to `Send & Print` functionality,
the attachment is linked to `account.invoice.send`.

Another flow have a similar issue: from invoices list, select few ones,
Action > Send & Print: the generated PDF won't be attached to their
invoice. In such a situation, here is the source of the problem:
https://github.com/odoo/odoo/blob/05ad6c477f7da2a495e5baf5b4629323b9d11fa0/addons/mail/wizard/mail_compose_message.py#L363-L367
There isn't any information about the invoice, therefore it is not
possible to linked the attachment to it.

OPW-2438457

closes odoo/odoo#71425

X-original-commit: e87f599d4eb22250b628d650b9f59b54db8d043c
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
[REF] account: journal items reconciliation (part 1/2) 2020-06-15T08:36:04+00:00 Laurent Smet las@odoo.com 2020-04-17T07:43:33+00:00 beccf82e09d536255d9d9cb9bfe58ebae2559843 This commits refactors the code of the reconciliation, in order to facilitate the process of complex use cases, namely multi-currencies or cash-basis-taxes related (see details below). It also prepares the code for a second refactoring where we will save on each journal items the amount_currency and currency_id field (even in case of operation made in company currency), also in the sake of simplification. 1) Multi-currencies: - the account.partial.reconcile model now will have dedicated columns to specify the amount of the partial reconciliation in the debit_line_id currency and the credit_line_id currency. That comes in handy when dealing with journal items having different secondary currencies, but also allows some simplification. - residual_amount_currency computation changed accordingly - moved models account.full.reconcile and account.partial.reconcile in their dedicated .py file 2) Cash basis taxes - cash basis entries now handle correctly rounding errors to make sure the exact amount of gets reported when the reconciliation becomes full. - the account for the base amount of cash basis entries has to be set, now, on the company instead of on each cash basis tax. - that new 'property' field can be set at the CoA installation via the field property_cash_basis_base_account_id of account.chart.template, or going through the accounting settings. Was task task: 2243420 Was PR #50308 Related: odoo/upgrade#1121 Related: odoo/enterprise#10252 Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com> 
This commits refactors the code of the reconciliation, in order to facilitate the process of complex use cases, namely multi-currencies or cash-basis-taxes related (see details below). It also prepares the code for a second refactoring where we will save on each journal items the amount_currency and currency_id field (even in case of operation made in company currency), also in the sake of simplification.

1) Multi-currencies:
- the account.partial.reconcile model now will have dedicated columns to specify the amount of the partial reconciliation in the debit_line_id currency and the credit_line_id currency. That comes in handy when dealing with journal items having different secondary currencies, but also allows some simplification.
- residual_amount_currency computation changed accordingly
- moved models account.full.reconcile and account.partial.reconcile in their dedicated .py file

2) Cash basis taxes
- cash basis entries now handle correctly rounding errors to make sure the exact amount of gets reported when the reconciliation becomes full.
- the account for the base amount of cash basis entries has to be set, now, on the company instead of on each cash basis tax.
- that new 'property' field can be set at the CoA installation via the field property_cash_basis_base_account_id of account.chart.template, or going through the accounting settings.

Was task task: 2243420
Was PR #50308

Related: odoo/upgrade#1121
Related: odoo/enterprise#10252
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
[REF] account: remove unused actions 2020-05-20T07:29:29+00:00 wan wan@odoo.com 2020-02-24T13:47:51+00:00 576a69e29e98532aa5de78eb3fcbff0b94cea32d Task 2201948 *These actions were either unused or only used in enterprise modules. The first ones have been deleted, and the second ones have been move to the corresponding enterprise modules. * account.fiscal.year: the whole model has been moved to enterprise closes odoo/odoo#46110 Related: odoo/enterprise#8706 Related: odoo/upgrade#1083 Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com> 
Task 2201948

*These actions were either unused or only used in enterprise modules.
The first ones have been deleted, and the second ones have been move to
the corresponding enterprise modules.

* account.fiscal.year: the whole model has been moved to enterprise

closes odoo/odoo#46110

Related: odoo/enterprise#8706
Related: odoo/upgrade#1083
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
[IMP] account : remove analytic default modules 2020-05-14T07:53:18+00:00 jbw jbw@odoo.com 2020-02-21T07:31:44+00:00 26175ea7a123e2218951873f925bcd9ce00b05c7 Merge account_analytic_default into account Merge account_analytic_default_hr_expense into hr Merge account_analytic_default_purchase into purchase Prevent having to manually install default modules after activating analytics closes odoo/odoo#50816 Task: 2182900 Related: odoo/upgrade#1186 Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com> 
Merge account_analytic_default into account
Merge account_analytic_default_hr_expense into hr
Merge account_analytic_default_purchase into purchase

Prevent having to manually install default modules after activating analytics

closes odoo/odoo#50816

Task: 2182900
Related: odoo/upgrade#1186
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
[REF] account: Split big files account.py & account_view.xml 2020-04-14T06:54:14+00:00 Laurent Smet las@odoo.com 2020-04-10T12:25:59+00:00 7076b4f4d0d933d93b24e8e4c7cf21ef0b0008e5 closes odoo/odoo#49422 Related: odoo/upgrade#1068 Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com> 
closes odoo/odoo#49422

Related: odoo/upgrade#1068
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
[IMP] account,*: Improve bank statements/payments workflow 2020-04-10T09:47:24+00:00 Laurent Smet las@odoo.com 2019-10-29T12:21:27+00:00 caeb782841fc5a7ad71a196e2c9ee67644ef9074 - Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal. - Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal). - Adapt and simplify the bank reconciliation report. - Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly. - Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account. With invoicing, the payment will do that so the "in_payment" state should never be shown up. With accounting, only the statement lines have the power to move an invoice to the "paid" state. - Fix various corner cases about the management of multi-currency in bank statement lines. - Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one. - Ensure the 'reconcile' method will raise an error if the involved moves are not posted. related enterprise PR odoo/enterprise#7019 closes odoo/odoo#41301 --task: 2092096 Related: odoo/upgrade#1018 Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com> 
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
    With invoicing, the payment will do that so the "in_payment" state should never be shown up.
    With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.

related enterprise PR odoo/enterprise#7019

closes odoo/odoo#41301

--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
[IMP] base, account, l10n_ch, website_sale, payment, web: make payment QR-code generation more generic 2020-03-30T11:28:41+00:00 oco-odoo oco@odoo.com 2020-02-07T10:10:09+00:00 0eef278268d1f4cce30c97bfef723f769b1a48e0 This new modelling makes it easier to add new QR-code formats, and allows using all of them in website_sale and account.payment's form view as well (so, Swiss QR codes are now available there, while they were restricted to only invoices in the past). All barcodes are now generated as reports, from a dedicated route. This was only partly the case before : Swiss QR added a cross on top of the QR-code directly in the template, it wasn't part of the image returned by the route; now it is. [ADD] base_qr_code_sepa: new module decoupling SEPA QR-codes generation from the base module Each new QR-code generation option should thus be done in a dedicated module (or added to a localization) in the future. [IMP] base_qr_code_sepa: update the generated QR codes to version 2 of the specification Version 1 is still supported, so no need to backport this. [IMP] l10n_ch: make Swiss QR-codes compatible with the new version of the specification (the old one is deprecated) This will be backported to 11.0 and 12.0, as these QR-codes will soon replace ISR. [IMP] account: make it possible to mark manual payments as sent with a button on the form view This way, when making them directly with a QR-code (or doing a more classical wire transfer), people can keep track of what they already have asked the bank to do, and what they still have to treat. closes odoo/odoo#44839 Related: odoo/enterprise#8262 Related: odoo/upgrade#992 Signed-off-by: Laurent Smet <smetl@users.noreply.github.com> 
This new modelling makes it easier to add new QR-code formats, and allows using all of them in website_sale and account.payment's form view as well (so, Swiss QR codes are now available there, while they were restricted to only invoices in the past). All barcodes are now generated as reports, from a dedicated route. This was only partly the case before : Swiss QR added a cross on top of the QR-code directly in the template, it wasn't part of the image returned by the route; now it is.

[ADD] base_qr_code_sepa: new module decoupling SEPA QR-codes generation from the base module

Each new QR-code generation option should thus be done in a dedicated module (or added to a localization) in the future.

[IMP] base_qr_code_sepa: update the generated QR codes to version 2 of the specification

Version 1 is still supported, so no need to backport this.

[IMP] l10n_ch: make Swiss QR-codes compatible with the new version of the specification (the old one is deprecated)

This will be backported to 11.0 and 12.0, as these QR-codes will soon replace ISR.

[IMP] account: make it possible to mark manual payments as sent with a button on the form view

This way, when making them directly with a QR-code (or doing a more classical wire transfer), people can keep track of what they already have asked the bank to do, and what they still have to treat.

closes odoo/odoo#44839

Related: odoo/enterprise#8262
Related: odoo/upgrade#992
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
[IMP] account: rework name sequences 2020-02-05T13:59:43+00:00 wan wan@odoo.com 2019-11-27T15:57:42+00:00 dfd01b8c5c7e1177f37bf199790a0732a61eed78 Task 2146469 Rework the name computation: * It doesn't use ir.sequence anymore * It is an editable computed field * Add a renaming tool This allows the user to tweak the sequences more easily than having to get through the ir.sequence settings. The sequence depends on a parameter of the journal: continuous, montly and yearly restart of the sequence. Everytime a new period is started, try to make a pattern form another period. The incrementing is done by taking the previous name, ordered lexicographically, splitting it by taking the digits at the end, adding 1 and re contstruct with the prefix. ** This means there could be cases where the prefix has a big importance on the next number. For instance, if you have INVOICE/2019/0001 INVOICE/2019/0002 and then rename the last one to INV/2019/0002, don't expect the next number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because the highest number was INVOICE/2019/0001. You will then end up with INVOICE/2019/0001 INV/2019/0002 INVOICE/2019/0002 closes odoo/odoo#41485 Related: odoo/enterprise#7189 Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com> 
Task 2146469

Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool

This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.

The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.

The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.

** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002

closes odoo/odoo#41485

Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
[IMP] account: don't always allow modifying the decimal places of a currency 2020-02-05T11:53:45+00:00 oco-odoo oco@odoo.com 2019-12-17T11:55:41+00:00 31e1322b40ab33bf81d4c000f2b2a3f3eb8d0958 If accounting entries have already been generated by this currency, we now forbid setting it a lesser number of decimal places (so, higher rounding factor). We also display a warning when increasing the number of decimal places, to make sure the user is aware of the impact it'll have. closes odoo/odoo#42017 Signed-off-by: Laurent Smet <smetl@users.noreply.github.com> 
If accounting entries have already been generated by this currency, we now forbid setting it a lesser number of decimal places (so, higher rounding factor). We also display a warning when increasing the number of decimal places, to make sure the user is aware of the impact it'll have.

closes odoo/odoo#42017

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
[MOV] account: reconciliation widget 2019-10-18T12:53:41+00:00 wan wan@odoo.com 2019-10-09T13:56:00+00:00 9ba8734f15e1a292ca27b1a026e8366a91b2a8c9 Task 2034073 The reconciliation widget is now entirely part of the enterprise version as it is an advanced accounting feature closes odoo/odoo#38424 Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com> 
Task 2034073
The reconciliation widget is now entirely part of the enterprise version
as it is an advanced accounting feature

closes odoo/odoo#38424

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>