We have our own html2plaintext, already used in lot of use cases instead of
just a few for the html2txt library.
Notably for emails: most emails going through Odoo stack use our simple
html2plaintext to format the body alternative. When no body alternative
is given to ``build_email`` an alternative is built using the library to
remove. Using our own parser allows to have the same results compared to
using ``MailMail.send()``. Difference lies in spaces and new lines as well
as markdown. Our html2plaintext is a bit simple and does not try to generate
Markdown but generates a simple plaintext version.
This also helps solving some issues with depending on that library.
Task-2702034
closesodoo/odoo#82486
X-original-commit: b3b9627b655cd7cb928925affed6cc8d92661e8d
Related: odoo/enterprise#23364
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce :
- Create an invoice for a customer (ex $100)
- Create a payment for the invoice (ex $100)
- create a bank statement with a line item for $200
- In reconciliation, add either another journal entry or a manual operation without partner to reconcile the remaining $100
Issue:
All lines receive the partner from the invoice
opw-2691196
closesodoo/odoo#82517
X-original-commit: 6cda0780fdccf666f5a3fb0f39db59fcb0bd45c8
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
By searching on account.move.line parent_state instead
of move_id.state, we avoid a join in many circumstances
and allow the database to benefit on an index on
company_id+parent_state to optimize several
queries, such as the default filter on the Journal Items
menu which shows posted items.
closesodoo/odoo#82504
X-original-commit: ef61db1cf8ebf1ab11e5dfdd439256d0607edba8
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
The aim of this commit is to allow EDIs to create and save account move
even if a supplier reference is duplicated.
This is achieved by delaying the moment to which the constrains is
triggered.
Before this commit:
A user can only upload a bill once. (xml ubl format for instance)
If he needs to upload it a second time, he will be forced to find a
workaround.
After this commit:
User will be able to upload as many bill as he wants but will receive a
ValidationError when trying to post the invoice if the reference is
duplicated.
The user will be able to post the bill very easily by changing the
reference a bit if he wants to pursue.
closesodoo/odoo#82303
Community-pr: https://github.com/odoo/odoo/pull/81748
Enterprise-pr: https://github.com/odoo/enterprise/pull/23255
Task: 2612299
X-original-commit: 200614876e62192e1a5ce2f30ec7aa8a1de77672
Related: odoo/enterprise#23281
Signed-off-by: William André (wan) <wan@odoo.com>
As the query results are set in a list of dicts relying on the
position of the dicts inside the list, the SQL query must ensure
the results returned by postgres are ordered properly so that it
will match the order in which the dicts are defined inside the list.
closesodoo/odoo#81978
X-original-commit: bac93bf56ff67a89f9381137b0c67642a302e6bb
Signed-off-by: Laurent Smet <las@odoo.com>
When reversing the CABA entry, the CABA tax account was replaced by the transition tax account if not set on the repartition line.
To reproduce:
Set up a CABA tax with ACC1 as transition tax account and ACC2 as tax account.
When creating the CABA entry, there is a line on ACC1 and another on ACC2.
When reversing the CABA entry, both lines are now on ACC1.
Introduced by https://github.com/odoo/odoo/pull/79556closesodoo/odoo#82004
Issue: 2718413
X-original-commit: 2f6a35eb73978ce0638765fd0981c7e95d9df696
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to reproduce:
- Create an account group for a range for example from 100000 to 200000
- Now edit the group to have a range from 100000 to 150000
Issue:
The accounts with code > 150000 are still in the account group
Solution
Adding an other intermediary table to the query in order to take into
account the accounts which have no group_id
opw-2695533
closesodoo/odoo#82023
X-original-commit: 05c3cb8dbb7a9bf0f438d5ee687b92e8d934f26b
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
It's possible to confirm an invoice with an archived bank account of
the recipient. But it's not making any sense, since the bank account
is archived.
It's why we need to raise an error if the user want to confirm an
invoice with an archived bank account.
opw-2704605
closesodoo/odoo#81939
X-original-commit: 8b9ff034cb67b132cdb6736a5f18d70beb63c253
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Bruno-brsy <brsy@odoo.com>
Steps to reproduce:
- Create two bank journals Bank-1 and Bank-2
- Create one Oustanding Payments and one Outstanding Receipts account for each bank journal
- Create and confirm an internal tranfer from Bank-1 to Bank-2 for 100$
- A second payment is created
Issue:
The account on the line in the second payment is the Outstanding Payments account of Bank-1,
it should be the Outstanding Receipts account of Bank-2.
After this commit, the second payment will take into account the account set on bank journal,
and if not set, the one set on company. Otherwise, an error is raised.
opw-2711252
closesodoo/odoo#81938
X-original-commit: 51b5a9d4e56d8d2300cf1ee91f8030c57a41a856
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
Consider this example:
- Create a 42% tax, price-included, with two tax repartition lines doing +100 -100
- Create an invoice of 100€ using this tax, and look at the move lines generated
==> Only a base line of 100 and a receivable/payable line of 100 have been created; no tax line.
This is wrong, as we'd expect to see:
- 100 in payable/receivable
- 100 for the base line
- 42 for the +100 tax repartition line
- -42 for the -100 tax repartition line
The two tax lines are missing because the compute_all considers the tax as a 0% one, because of the +100 -100 stuff.
OPW 2716083
closesodoo/odoo#81771
X-original-commit: 9d24e3cf002bacb09d6e955b26124dda09c15f18
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson <oco@odoo.com>
When no partner is set on a statement line, the reconciliation models try to find candidates using the payment reference or the partner name.
This was not working well when using reconciliation models configured to match on notes and/or reference. Only the default match on label was working.
As an example, consider the following case:
1) setup an invoice-matcing reconciliation model as such:
- Partner Is Set and Matches = False
- Match Invoice/bill with = Reference
2) Create an invoice with payment reference 123, for 100€
3) Create a statement line of 100€, with reference ('ref' field, inherited from account.move) = 123, label='test', and no partner set.
4) Try to reconcile the statement line
=> not match is found
OPW 2701729
X-original-commit: 74894b0da82f5f71cd22a3c9bb405696f908ef5c
Part-of: odoo/odoo#81730
Renamed the 'Other' account type into 'Non Trade' to enhance clarity and coherence
Changed the filtering system in the accounting search view to improve coherence with the filtering system available in the reports.
It is now possible to filter the trade/non trade accounts in the accounting views.
This change may be overriden by default selections already in place.
Renaming Receivable/Payable to Trade Receivable/Trade Payable could have turned out to be confusing for accustomed users.
They are now renamed Receivable/Payable, though the Non-Trade option is still present.
task-2669128
closesodoo/odoo#79752
Related: odoo/enterprise#21773
Related: odoo/upgrade#3004
Signed-off-by: Laurent Smet <las@odoo.com>
Have an MX database set up
Activate multicurrency (MXN and USD)
Have several rate for USD
- yesterday 0.047939098170
- today 0.048486729180
Make an invoice, dated yesterday for USD 116, tax 16% (cash basis)
Create a received payment dated today, for USD 116
Reconcile invoice and payment
Jounal items will be created for the invoice, for the exchange
difference and for the cash basis entries, but there are redundant
entries addressing the tax.
This occur because when reconciling the payment with the invoice the
system create the cash basis moves and reconcile them. During this inner
reconciliation exchange difference move are created (1) just for the tax
line.
Then the outer reconciliation flow continue and compute the exchange
difference moves, considering all cash basis items created before. A new
couple of journal items will be created to account for the difference in
tax, but this is redundant since it was already covered before (1)
opw-2685570
closesodoo/odoo#81624
X-original-commit: 03bf311bfde98f28a9b8e73953869a42b828c5e3
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Currently Bank Suspense Account has "Current Liabilities" type, while it should be "Current Assets"
Task ID: 2702804
closesodoo/odoo#81491
X-original-commit: c6d2a50499744a9ddbb09a9974d6ab52116ef542
Signed-off-by: Laurent Smet <las@odoo.com>
When the Reconciliation Model had a tax on the writeoff,
the journal_id wasn't populated by widget.get_reconciliation_dict_from_model(),
preventing the reconciliation from happening.
opw-2689002
closesodoo/odoo#81396
X-original-commit: 17a1c960cc3cce1850a6009ebf9641174e0304fb
Related: odoo/enterprise#22891
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
This commit:
1) fixes the customer invoice/vendor bill outstanding debit/credit warning anchor link
2) improves the customer invoice/vendor bill outstanding section
3) fixes the customer invoice/vendor bill outstanding debit/credit warning messages when viewing an account move reversal
4) modifies the order of the 'invoice lines' tab for mobile view
1) The anchor link did not work when pointing to a field (the id of a field is not propagated into the DOM).
Hence,the target field is put inside a div with the correct id.
2) The outstanding section is placed to the right, below the amount due and next to the description for clarity purpose.
The 'Add' button is turned into a secondary button (s.t. it is more noticeable). Each entry name is now a link to to the corresponding account move.
3) The warning messages are modified because they were not consistent and confusing when viewing an account move reversal.
4) Previously, the order on the 'invoice lines' tab was: narration>total>widget, now it is: total>widget>narration
task-2669132
closesodoo/odoo#78550
Signed-off-by: Laurent Smet <las@odoo.com>
When paying an expense, we should take the bank accounts from partner instead of the ones set on the company.
Also, the computation of the partner bank account is different on the wizard and the payment.
To unify both models, the 'available_partner_bank_ids' should also be put on account.payment.
see https://github.com/odoo/odoo/pull/79737closesodoo/odoo#81236
X-original-commit: 89d8c0a1ea03919e9f3085ea0d05aa80ad443ff7
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
By searching on account.move.line parent_state instead
of move_id.state, we avoid a join in many circumstances
and allow the database to benefit on an index on
company_id+parent_state to optimize several
queries, such as the default filter on the Journal Items
menu which shows posted items.
closesodoo/odoo#80815
X-original-commit: c2a72c268e6a28d7448b6dbf96fed4e36d24b3fe
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
When using account control on a journal, line_section and line_note do not
block the process even though they are not in the allowed accounts (they
don't have an account at all).
But when adding new accounts in the account_control_ids field, the
constraint is triggered by those lines.
This PR makes the constraint ignore those lines when assessing if
there's an issue.
opw-2677597
closesodoo/odoo#80313
X-original-commit: 9a42ebf1d9d482b031bc5bb7839cc9a8a09090ea
Signed-off-by: Florian Gilbert <flg@odoo.com>
Prevent calling _get_sequence_format_param() with None as parameter in _is_end_of_seq_chain() when sequence is empty.
Would cause an error when deleting an invoice with an empty sequence.
closesodoo/odoo#80467
Task: 2697771
X-original-commit: 6a5aab047c1e540505ba84a1ef2dcc3356e89708
Signed-off-by: William André (wan) <wan@odoo.com>
Before this fix, all moves of type “entry“ were considered as misc operations in regard to repartition tags and the tax report. And only moves of type “out_refund” and “in_refund” were considered refunds.
Now reverse entries with sale/purchase taxes get their tags set accordingly to repartition lines.
Account D C Tax Tax Grids
700000 Ventes en Belgique (marchandises) 0 1000 21% +03
451000 T.V.A. à payer 0 210 +54
400000 Clients 1210 0
Was reversed to:
Account D C Tax Tax Grids
700000 Ventes en Belgique (marchandises) 1000 0 21% +03
451000 T.V.A. à payer 210 0 +54
400000 Clients 0 1210
Is now reversed to:
Account D C Tax Tax Grids
700000 Ventes en Belgique (marchandises) 1000 0 21% +49
451000 T.V.A. à payer 210 0 +64
400000 Clients 0 1210
closesodoo/odoo#80427
X-original-commit: a337d5d5b3886eabbdc8de95eb615dffc91d5d8e
Related: odoo/enterprise#22532
Signed-off-by: Olivier Colson <oco@odoo.com>
Allow log date changes tracking by adding chatter on company and tracking lock date fields.
closesodoo/odoo#78730
Task: 2651834
Related: odoo/enterprise#22479
Signed-off-by: Laurent Smet <las@openerp.com>
- set journal_id, tax_ids, analytic_account_id, analytic_tag_ids & force_tax_included as optional hide
- fix _get_write_off_move_lines_dict to make clicking a reconciliation model button have the same result as doing the operation manually :
- add journal_id parameter
- use reco line label in new aml name
closesodoo/odoo#80176
Task: 2611348
X-original-commit: 4514f0ec4a1eebb4652c34c4926d0cd1ff336e17
Related: odoo/enterprise#22435
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Laurent Smet <las@openerp.com>
Purpose is to have tracking methods beginning with ``_track``, indicating
those are tool methods used for tracking. It helps organizing the mail thread
file and having short but precise method names.
We also remove the usage of ``mail_track_log_only`` context key that is not
used anymore in the code. It allows to shorten a bit the code and make it
easier to read.
Task-2671709
Part-of: odoo/odoo#78648
- Create a partner with 2 bank accounts: BNK1 and BNK2
Wrong flow with vendor bill:
- Create an vendor bill => BNK1 is set by default
- Change BNK1 to BNK2
- Register a payment
=> BNK1 is proposed by default instead of BNK2
Wrong flow with customer invoice:
- Set BNK3 on your company
- Create a customer invoice
- Register a payment
=> BNK1 is suggested instead of BNK3
closesodoo/odoo#80175
Issue: 2683197
X-original-commit: ec0d807b2b6ff3596d9b591bd8ec7d8889d41d8a
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@openerp.com>
Steps to reproduce:
- Create a journal with a custom currency
- Create a statement line
- Create a reconciliation model button putting the residual to a random account
- Reconcile the statement line using the button
=> The amount lands inside the debit/credit instead of amount_currency
Introduced by:
https://github.com/odoo/odoo/commit/5ad660877f485d741a0120e07eb73178f59d2dfc#closesodoo/odoo#80173
X-original-commit: fc9b8dc6611d761f2c8778254dcbad52091404dc
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@openerp.com>
Editable computed fields need to have their own compute
method.
Otherwise, when providing one of the two fields at create/write time
will not be taken into account because the compute method will be
triggered for the other field.
closesodoo/odoo#77912
X-original-commit: e35dc4c87821bbb668657eed99bb51c1f853c208
Related: odoo/enterprise#21685
Signed-off-by: William André (wan) <wan@odoo.com>
Expected Behaviour
When clicking on the "XX Unpaid Invoices" link on the main dashboard of the accounting app, we should get to a list view with only unpaid (and partially paid) invoices
Observed Behaviour
When cliking on the link, we get all the invoices, even the paid ones.
Reproducibility
This bug can be reproduced following these steps :
1. Create some invoices
2. Make sure some of them are paid and some are not
3. Go to the main dashboard
4. Click on the "XX Unpaid Invoices" link in the "Customer Invoices" app
Problem Root Cause
The problem comes from a change in the filter name from V14 to V15 ("unpaid" category has been replaced by "open").
Related issues
opw-2681099
closesodoo/odoo#79643
X-original-commit: 9212d07c5919470361b638f0e70c2069957c7d6f
Related: odoo/enterprise#22221
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Hendrickx Anthony (anhe) <anhe@odoo.com>
Since we don't have other docs for `account.tax.report.line`, let's just improve
source readability
closesodoo/odoo#79696
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- On a company with multi currency
- Set the company currency rate to 1, and the foreign currency
to 0.273748
- Create a vendor bill
- Set first the foreign currency, then select a product with a
tax to 21% and a price unit of 155.32
- Go to 'Journal Items', the 'tax paid' line debit is computed to 119.15
- Reselect the foreign currency on form.
- Now the 'tax paid' line debit is computed to 119.16
The total is also impacted as the tax changed.
Explanation:
Before this commit, the taxes was both computed in foreign currency and company currency. However, when setting a new currency or changing the date, the taxes wasn't recomputed but the new conversion rate was applied.
This commit is fixing the issue by applying the same logic as in 14.0: the taxes are always computed only the foreign currency, then the conversion rate is applied to get the accounting balance.
opw-2569668
closesodoo/odoo#79618
X-original-commit: 11f5fcfb577b117b279f5d96095e9c0798d78bbd
Signed-off-by: Laurent Smet <las@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
RATIONALE
Currently we can specify email used for notification layouting through context
use in mail composer. It is then propagated to message_post, stored on
mail.message and used to encapsulate emails sent based on posted messages.
SPECIFICATIONS
Get rid of context usage (``custom_layout``) and use a real field on composer
model: ``email_layout_xmlid``. Use now a default value coming from context
(default_email_layout_xmlid) instead of custom_layout.
Support old context key in composer for backward compatibility, working like
a default value for the field itself.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer)
UPG odoo/upgrade#2829
Part-of: odoo/odoo#76418
In some flow like subscription, invoices are sent by mail automatically to the customer.
Sometimes, the invoice must be approved by the government before sending the mail like the Mexican EDI.
This commit aims to add a custom method to detect when an invoice is ready to be sent to the customer.
PR (community): https://github.com/odoo/odoo/pull/78714
PR (enterprise): https://github.com/odoo/enterprise/pull/21809closesodoo/odoo#79504
X-original-commit: 3a29371eb70309f46e3b8938434287fefc23b351
Related: odoo/enterprise#22171
Signed-off-by: William André (wan) <wan@odoo.com>
Issue:
When trying to print a Suisse QR bill, if multiple images are presents
in document and they have a url as src, some pictures will not be
displayed.
(Same issue may occur with simple QR code)
Cause:
It's a known issue with wkhtmltopdf: https://github.com/odoo/odoo/commit/2949138a7d84cd6c925ea1745d62f25ef077bb8b
Also, adding css class to body by js break wkhtmltopdf.
Solution:
Replace link by base64 image value (use a function to retrieve base64
image instead of image_url).
Remove class 'l10n_ch_qr' added by js (no need since CSS file didacted
to this report).
Move `_get_qr_code_base64` and `_get_qr_code_url` logic/flow
(since generic) to account module.
Move specific logic like `_get_qr_vals` and
`_get_qr_code_generation_params` to specific module (ex: l10n_ch).
extra: Alter some css for better rendering + update unitest.
opw-2620082
closesodoo/odoo#77643
X-original-commit: 699b6eeac993e3a8d97ae7949170f7e18ca05831
Signed-off-by: Olivier Colson <oco@odoo.com>
Reproduce :
1. Add a default analytical rule: if Coin Gourmand partner then Administrative analytical account
2. Create a PO at the Coin Gourmand supplier, add a product, and select the Internal analytical account.
3. Bill for this product.
Result :
Internal analytical account has disappeared from the invoice line. It has been replaced by Administrative.
Issue :
AccountMove.create() computes an account in the move and this causes the analytic account to be reset at its default value from the rule.
Fix :
Since the account pocalypse in 13.0, account.move is making magic things during the creation of the invoice to create dynamically the invoice lines like account.invoice did before this huge refactoring.
The create is making a 'New' record to simulate the onchange but this code is a hack triggering unexpected recomputation like the analytic account.
To avoid that, we ensure to assign the minimum number of fields to preserve fields like the analytic account.
closesodoo/odoo#79321
X-original-commit: 876e2d1073312fe65cb6b2e3038235aeaa082c8a
Related: odoo/enterprise#22074
Signed-off-by: Laurent Smet <las@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>
In case the address of the company is in a different country as its fiscal country, the taxes available as "source tax" on the fiscal position lines were not the right ones (the country of the address was used to fetch them).
closesodoo/odoo#79144
Signed-off-by: Laurent Smet <las@openerp.com>
Steps to reproduce:
- On bank journal set the outstanding payments accounts and the
outstanding receipts accounts, respectively to 101403 and
101402
- In Accounting > Configuration > Settings > Default Accounts,
let the two outstanding accounts empty.
- Customer > payment > create a payment : payment type "Receive",
amount 5 for example. Save it.
- Edit the payment and change the payment type to "Send".
- Click on Save.
Issue
Got an UserError "Cannot create unbalanced journal entry"
Since the payment_type has changed, the computed outstanding_account_id on the payment is recomputed.
When splitting journal items using the _seek_for_lines() method, odoo is not able to retrieve the liquidity lines since outstanding_account_id has changed.
opw-2620046
closesodoo/odoo#78866
X-original-commit: 865c5d7741ca1bf003b4181d06484cc4ecaf8fcb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
For clarity purpose, tooltips for the 3 accounts in Tax Group (Configuration > Tax Group) are added.
task-2602730
closesodoo/odoo#78453
Related: odoo/enterprise#21725
Signed-off-by: William André (wan) <wan@odoo.com>
Thibault Delavallée