Ease the way invoice report is selected for rendering.
We now only rely on `_get_name_invoice_report()` to decide
the report, and it is automatically selected in the report template
`report_invoice` that is extended by localizations.
Task-id:3492033
closesodoo/odoo#136389
Related: odoo/enterprise#47812
Signed-off-by: Laurent Smet (las) <las@odoo.com>
In this viewtiverse, the heroes remove the context dependencies for
`get_views`, from the views and python fields (such as domain). To reduce
inconsistencies and the number of rpc.
Current issues:
* There may be inconsistencies in views at the JavaScript level. Some
overrides modify the behavior of get_views or domains on fields via
context keys, therefore by changing the action, the rendering may be
different. However, these views are cached. However, the cache key
(Javascript) does not reflect the entire context, and requires additional
post-processing from the server.
* Multiple rpc for the same rendering. get_views being dependent on the
context, as soon as it changes, a new rpc is performed. In most cases,
when JavaScript needs the same view, there is no change depending on the
context, the rpc is useless.
* Inconsistency when rendering subviews, some views could be different
depending on the context, this context can be modified in the view itself
via the context attributes. However, the JavaScript client does not redo
an rpc for each change of these sub-contexts. Therefore the result may be
inconsistent.
Solution:
Limit as much as possible the number of context keys provided when calling
get_views, and use the context provided as a cache key. The authorized
keys are 'lang' and '*_view_ref'. For the cache key, options are added in
the get_views method.
Instead of using the context, it is inserted into python expressions.
This will be evaluated by JavaScript and thus avoids inconsistencies.
task-3414108
task-3414068
closesodoo/odoo#135145
Related: odoo/enterprise#47584
Signed-off-by: Raphael Collet <rco@odoo.com>
Only duplicate emails used to be checked when sending a mass mail.
However it is possible (e.g. using templates) to send a mass mail
to the same person containing different information.
The existing functions to allow models to specify emails
processed in the past by some other means are kept.
A new check is added in the processing that checks the full contents
of the message, subject and attachment ids.
The strings are not hashed as most situations are:
- Sending the exact same mail to everyone
-> Only need to check against one message
-> Same complexity as hashing
- Sending all different emails
-> Checking inequality of str is usually very fast
For attachments, as we cannot compare them easily.
They are ignored for the purpose of equating emails
whenever there are the same number of attachments
in the email values as there are on the composer.
This is because each email should receive its own copy
of the composer attachments. If they have a different
number of attachments, they were generated dynamically
through reports and we assume they are all different.
We can thus remove the 'document based' information
as it is implicitly infered from this check.
-------------------------
Test utils are also updated for two purposes:
1. Add optional body and attachment_name discriminents
assertMailMail assumed all emails could at least be
differentiated by subject. Our test breaks that
assumption, so we use body and attachment to find the
best-fitting email based on the data passed in.
2. Check email_formatted on recipients
When using assertMailMailWEmails, we first find the
email using the non-formatted email of the recipient.
This does not match assertSentMail which checks against
the raw email_to value, which would often be formatted.
Task-2826811
closesodoo/odoo#99541
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the fiscal position is not used to determine account.
closesodoo/odoo#135559
X-original-commit: 57f71fa2666af591a8d3d28af65fcfab8a7d3785
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Co-authored-by: Miquel Raïch <miquel.raich@forgeflow.com>
If a bank account is added through the onboarding step and the user creates one instead of linking it,
the dashboard is not reloaded to show the completion of the step and the new account.
To make sure that the view is reloaded to show new data,
the easiest fix would be to return a reload action in `validate`.
task-3431961
closesodoo/odoo#135170
X-original-commit: cc793b303da5ea2dbe931bac1da266a121429ede
Related: odoo/enterprise#47302
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
In 16.1 and before, when you used the Send & Print, you could manually remove the attachments when using
the Send by Email. Even though the use case is weird (sending an invoice by email without attaching the document),
we have feedback of user actively using that option before.
Also, prevent the deletion of the PDF report from the wizard:
- Create and invoice and send it by mail
- Open again the send & print, remove the PDF and send by mail
=> The PDF is deleted from the invoice
closesodoo/odoo#135101
Task: 3476700
Opw: 3378840
X-original-commit: 00dc68955c8e4c35fab29617eed7f03e45fc6643
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
MailTemplate model has a 'partner_to' field is dynamically rendered to contain
partners being recipients. After rendering it should hold a comma-separated
list of partner IDs.
However as we are unsure it was correctly written better be defensive. We now
check that we can effectively transform items to IDs using 'isdigit()'.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@a4e7f9b9dd
Part-of: odoo/odoo#134934
This traceback raises when user tries to create payment without payment date.
To reproduce this issue:
1) Install 'account'
2) Open any existing invoice (not a DRAFT one)
3) Click 'REGISTER PAYMENT' button.
4) Now remove 'Payment Date'
Error: 'Expected singleton: account.payment.term()'
Note:- 'TypeError: unsupported operand type(s) for +=: 'float' and 'NoneType''
is also produced for some invoices.
When user removes 'payment_date' '_compute_amount' method will be called, In which
'_get_total_amount_in_wizard_currency_to_full_reconcile' method is used.
In '_get_total_amount_in_wizard_currency_to_full_reconcile' method,
'_get_total_amount_using_same_currency' is used to get total amount.
On '_get_total_amount_using_same_currency' method payment_date is passed as an
argument for '_is_eligible_for_early_payment_discount' method.
See: https://github.com/odoo/odoo/blob/ed2e26633458f1284437286f71eba43c8d1818a7/addons/account/wizard/account_payment_register.py#L490-L498
On '_is_eligible_for_early_payment_discount' method if no reference date,
its returning True. which leads to above traceback
See:
https://github.com/odoo/odoo/blob/ed2e26633458f1284437286f71eba43c8d1818a7/addons/account/models/account_move.py#L1902-L1905
sentry-4337953422
closesodoo/odoo#134721
X-original-commit: a05be50b9cf75fb0226f7b464b3a8f580465d462
Signed-off-by: Laurent Smet (las) <las@odoo.com>
If a web-service after the PDF generation failed but does a cr.commit(), the attachments should not be generated.
closesodoo/odoo#134237
X-original-commit: 5d343598c2ce03698aa686965ec3887df610ec9a
Signed-off-by: Josse Colpaert <jco@odoo.com>
This traceback raises when user tries to send an invoice without attachments.
To reproduce this issue:
1) Install 'Accounting'
2) Open any existing 'Invoice'
Note:- Invoice should not be in 'Draft'
3) Click 'Send & Print ' button an wizard will be opened.
4) Click on 'Send & Print' button of wizard.
5) Now repeat the step 3
6) This time delete the Invoice Attachment and click on 'Send & Print' button
of wizard.
Error: 'A traceback appears': 'can only concatenate list (not "bool") to list'
On '_get_mail_params' method 'attachment_ids' is getting
values by concatenating 'mail_attachments_widget' and
'invoice_extra_attachments_data'.
See:-
https://github.com/odoo/odoo/blob/27c1384e1209339158f56c82bebf99a5b64811f4/addons/account/wizard/account_move_send.py#L434-L448
Because of user delete the 'Invoice attachments' in wizard, 'mail_attachments_widget'
will return false and it leads to above traceback.
Sentry-4305060652
closesodoo/odoo#133953
X-original-commit: f08da6fdfa881ec3e80d6fc14dddaa8df3c529ed
Signed-off-by: William André (wan) <wan@odoo.com>
The traceback arises when a user deletes an attachment that the referenced in
the `account.move.send` model's `mail_attachments_widget` field, and
subsequently, the cron uses `mail_attachments_widget` to send invoices.
Steps to produce:
- Install account.
- Open Invoicing > open any invoice > click on SEND & PRINT > click on SAVE.
- Add an attachment > refresh the page.
- Go to attachments > delete the attachment which you have uploaded.
- Let the cron `Send invoices automatically ` run automatically.
ERROR: Traceback will appear MissingError Record does not exist or has been
deleted.
A `mail_attachments_widget` is a `JSON`storable field (Line 1) of the
`account.move.send` model. `mail_attachments_widget` carries data like the
attachment's ID, name, and mime type. Cron utilized the
`mail_attachments_widget` field to retrieve attachment data when sending an
email with attachments. `seen_attachment_ids` is a list of IDs (Line 2) of
attachments prepared using `mail_attachments_widget`.
This commit fetches only existing attachment records from the 'ir.attachment'
model for the attachment IDs present in the `seen_attachment_ids` list.
Line [1]- https://github.com/odoo/odoo/blob/0c95e064ca6384f57154bb12d3b4ef55ee1b4da3/addons/account/wizard/account_move_send.py#L76-L80
Line [2]- https://github.com/odoo/odoo/blob/d87dc624c33c8edd0eafc130b02a95fd91e58094/addons/account/wizard/account_move_send.py#L433-L439
Sentry-4315708399
closesodoo/odoo#133951
X-original-commit: 2486300538bc68075cba530bec481909af1aeb0d
Signed-off-by: William André (wan) <wan@odoo.com>
When adding a bank account via the setup wizard,
an User Error is raised ("Incompatible companies on records")
Since 0479b2b594,
`check_company` is set to `True` on
`SetupBarBankConfigWizard.linked_journal_id`, but
the model has no `company_id` field.
Therefore in `BaseModel._check_company()`, no
company is found and we raise the error.
Steps:
- Go to accounting dashboard
- Make sure the "onboarding" banner is not removed from the view
- Click on "Add a bank account" on the banner
- Try to create a new one (bottom right of the wizard)
- Enter an account number, select a bank and validate
-> Error is raised
opw-3473184
closesodoo/odoo#133214
X-original-commit: 8d9c0c27d389ecd21a5c32ebba1e8da14316b6c0
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
This traceback raises when user tries to send an invoice without email template.
To reproduce this issue:
1) Install 'Accounting'
2) Open any existing invoice (not a draft one)
3) Click Send & Print button, an wizard will be opened
4) Make 'Use template' blank and give any subject
5) Click on 'send and print' button of wizard.
Error: "Expected singleton: mail.template()"
Note:- This traceback also appears when cron job
(model._cron_account_move_send(job_count=20)) runs.
On '_send_mails' method 'mail_template' variable is getting value from
'self.mail_template_id'. When user removes the template from wizard,
'mail_template' will be false.
See:
https://github.com/odoo/odoo/blob/ce2140fc73e46906acf3963d8bdf9694a499008a/addons/account/wizard/account_move_send.py#L461-L473
In the above usecase 'mail_template' is passed in 'get_default_email_from'
method as an argument, which is used to return
'_get_mail_default_field_value_from_template' method, in that
'mail_template' is used to 'render_field', in which ensure one is used.
It leads to above traceback.
sentry-4364692484
closesodoo/odoo#132847
X-original-commit: dde276cdac5124a5333d03e7a985a2c690d84080
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce:
- Create two Bills with different payment terms with one having no "early_discount" such as '30% Now, Balance 60 Days'
- Select the Bills and click on Register Payment (make sure the payment is not grouped)
Issue:
Server Error
Cause:
We try to Register Payment for all the Bills at once, but the "early_discount" is not defined for all the Bills.
So, whenever there is a move with an early discount, the mode is always considered as "early_payment".
Therefore, we call `_get_invoice_counterpart_amls_for_early_payment_discount` with an empty list since there is no early discount
https://github.com/odoo/odoo/blob/0ffaaebfa5c25c4bf71fb0e02288767dbfac959d/addons/account/wizard/account_payment_register.py#L750-L755https://github.com/odoo/odoo/blob/0ffaaebfa5c25c4bf71fb0e02288767dbfac959d/addons/account/wizard/account_payment_register.py#L760
Causing the "local variable 'aml' referenced before assignment" error.
Solution:
We only iterate through moves belonging to the batch. This way, we avoid setting the mode to "early_payment" and entering the confition.
opw-3378445
closesodoo/odoo#132113
X-original-commit: 9bba9576d3365500a5c1eda0cfd57457fd999878
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Improve Send & Print general usability by making it more streamlined overall.
Options are not activated but preemptive problematic partners are shown,
and skipped during the sending process.
closesodoo/odoo#131448
Task-id: 3336623
X-original-commit: 4105994e778459c869d885d017118492ffcd2064
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yosua Nicolaus (yoni) <yoni@odoo.com>
When having a python format in the ref (or memo) of a payment, going to journal
items, select the move and doing an automatic entries, when changing the account
a traceback appears.
In the _format_new_transfer_move_log, we create a format that will be put in
the chatter. In this message we use python format without considering the
possibility that we can have one in the link of the move.
By putting the python format before formatting the link, the issues is solved.
task: 3434131
closesodoo/odoo#130091
X-original-commit: 12e0e6a492a010d61a8a1f763c72e25765654511
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Currently, errors occur when the 'Send invoices automatically' cron
is run this is because the related invoice is deleted and we receive an
empty record in move_to_lock when executing the query.
Step to produce an error:
- Install 'Invoicing'
- Create an invoice e.g. 'INV/2023/00001'
- Click on confirm > Click send & print
- Now in wizard don't click 'Send & print'
- Now go to home screen or close current window
- Open 'INV/2023/00001' invoice and click 'Reset to draft' and delete it
- Go to scheduled action and open 'Send invoices automatically'
- Click on 'Run Manually' >> error occur
This commit fixed the above issue by not the query
from executing when move_to_lock has an empty record.
sentry-4291237277
closesodoo/odoo#130021
X-original-commit: a2c855970ab56f5ef7acf08eeaf8ff45c1eca8c9
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Steps to reproduce:
1. Create an invoice with an Invoice Date in the past
2. Confirm the invoice
3. In Journal Items tab, click cut-off and then create journal entries
4. Traceback
opw-3369709
closesodoo/odoo#129689
X-original-commit: 219f9f929bb18f60a85e7fa3eb6868f954931f55
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
The logic of the send & print wizard is to generate all EDI documents and PDF at the same time
to ensure the consistency between all business documents.
In some localizations, we need custom references to the generated EDI documents inside the PDF.
The problem is the current PDF engine is not designed to easily extend such PDF template and provide
custom values to render it. Also, you absolutely need an ir.actions.report to use the PDF rendering.
To make such customizations less paintful, this commit adds a hook on the send & print wizard allowing
to provide a custom template inheriting the standard one and custom values for the rendering.
Task: 3069324
Part-of: odoo/odoo#128395
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
Before this commit, when an invoice is reversed we used to put the message
"this entry has been duplicated from XXXX" but the message that we log in the
chatter was not very clear and also to have the info on the invoice that it has
been reversed you add to go on the credit note itself.
Now when an entry is reversed, the link to the credit note is put in the chatter
of the invoice and the message on the credit note has been changed.
closesodoo/odoo#124060
Task-id: 3326780
Signed-off-by: William André (wan) <wan@odoo.com>
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
We added another hook to call the web service after the pdfs were rendered.
It would be clearer if the first hook was renamed to remain consistent.
closesodoo/odoo#125536
Signed-off-by: Laurent Smet <las@odoo.com>
Currently, we call the web service before the PDF is rendered. This is often required for some localizations, for example Mexico.
However, in some other cases, we need to embed the pdf document in the xml file, like in Peppol. In this case, we need to call the proxy after the pdf has been rendered.
This commit adds an additional hook that is being called in the end of `_generate_invoice_documents`, after all the documents have been generated and postprocessed. `account_peppol` will use the new hook instead of the old one.
closesodoo/odoo#125438
X-original-commit: dd56297e8b462539c913803eeb23a224fc9e93ac
Signed-off-by: Laurent Smet <las@odoo.com>
When using the Send & Print wizard in invoice_single, the error is raised if any
making all changes rollbacked including the update of the 'peppol_move_state'.
closesodoo/odoo#125302
X-original-commit: ec1209c2853ead82bcf27728612d1a7efc6dc97a
Signed-off-by: Laurent Smet <las@odoo.com>
- Create an invoice
- Sent it using the Send & Print wizard
- Remove the PDF manually
=> The Send & Print button is still secondary instead of primary
X-original-commit: ef9e266c86cbc4abc24e2a6f597a2014e6e3439a
Part-of: odoo/odoo#125302
When creating the attachments for the mail.message, copy the attachments
instead of linking the existing ones.
That way, even if the user deletes the PDF or another business documents,
the history remains the same and can be retrieved easily.
X-original-commit: 7434cbe47ec58695a2dde40bcf4bd3bdaf6f1964
Part-of: odoo/odoo#125302
In case of error, the send & print wizard is crashing or log an error on the invoice chatter.
In that case, nothing is sent to the end-customer.
This is problematic for all flows in which we want to send a mail to the customer automatically.
For example, e-commerce with automatic invoicing or subscription/recurring invoices.
To avoid that, the current logic of the send & print has been reshaped. In case of error, a proforma
PDF is sent instead. This is exactly the same document as the PDF but without the legal layer.
To do that, a lot of refactoring has been necessary to always provide the cumulated data for invoices
to be able to access the generated proforma report and to allow the overrides to know exactly in which
mode the hooks are called.
Also, this commit renames the method by something less generic about invoices. Indeed, this wizard needs to be
usable for others documents than invoices. That's the purpose of the invoice_single/invoice_multi mode.
For that reason, all methods about invoices are now expricitely prefixed by 'invoice'.
Fix also a performance issue on multi-invoices since the invoice_pdf_report_id document was invalided for the
whole model instead of the current record. When dealing with X invoices, the whole model was invalidated X times.
Fix the managment of attachments:
- The manual attachments wasn't send when sending a mail 'invoice_single' mode.
- When changing to another mail template, the manual attachments were lost.
Fix the double generation of PDF using a web-service.
When opening again the send & print wizard, the PDF must not be regenerated but reloaded from the previous one.
Task: 3339352
X-original-commit: e9e90811aeee46989a83b21f9b59071a9c7bc362
Part-of: odoo/odoo#124436
Expected singleton: res.currency() when currency not provided
also when remove company in invoice.
Steps to Produce:-
- While go to invoice and click on `REGISTER PAYMENT`
- Remove currency from wizard
Traceback will be generated.
Applying this changes will resolve this issue.
sentry - 4149615534
closesodoo/odoo#123031
X-original-commit: 3e2bbb3c6d84688ab628a7559f1f5329d2172339
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, if you use the automatic entry wizard to change the period of
a journal item dated prior to the lock date, you'll just get blocked
with a UserError, with no workaround.
This commit changes the date of the adjustment entry to be the first end
of month after the lock date. As a result, the adjustment entry can be
created.
Based on PR #92439closesodoo/odoo#122997
Taskid: 2823170
X-original-commit: fdeaff0a879bdf1242ed0a8d85e3e0363dd3276b
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Description of the issue/feature this PR addresses:
simplification of the credit note wizard
Current behavior before commit:
First users select reverse option (3 radio buttons):
1) refund
2) cancel
3) modify
The reverse action is triggered when the users clicks on the "reverse" button
After commit:
radio button are removed. There is now two buttons that trigger directly the reverse action with the desired option (refund or modify, cancel is not available anymore)
Also, for refund, posting the draft reverse move will also reconcile with reversed move.
task id: 3244377
closesodoo/odoo#117961
Related: odoo/enterprise#40919
Related: odoo/upgrade#4667
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The manual reconciliation widget is too complex. We completely remove it and
replace it with a simple wizard `account.reconcile.wizard` that opens when
selected lines can't be directly/silently reconciled (then we need a
write-off whose data will be filled in the wizard).
To do so we had to refactor reconciliation methods to allow to shadow some
values and fake reconciliation to get correct values.
We also now use of the _reconcile_plan instead of the previous reconciliation
which should be more efficient and correct.
Refactored a bit common between `test_account_reconcile_wizard` and
`test_account_move_reconcile` to avoid duplication.
In this process of simplification we also separate the previous `automatic_entry_wizard`
in two separate interfaces from the user's perspective: one only handle the change of
period and the other will handle complex transfer that are not possible through regular
reconciliation process (i.e. through the wizard we are creating in Enterprise related PR).
closesodoo/odoo#120832
Task: 3060792
Related: odoo/upgrade#4674
Related: odoo/enterprise#40510
Signed-off-by: Laurent Smet <las@odoo.com>
Currently, the UBL/CII format (if enabled on the invoice) is checked by
default, which will trigger the validation checks upon generation. This
can be annoying (feedback: "error message when we want to send invoices
to customer. For some customer, there is a problem with the xml file. To
be able to send the invoice, we uncheck the box for the xml invoice. See
video:
https://drive.google.com/file/d/12IkhqQtHw0EUF3srqRX8uZjCXU2DYpns/view?usp=sharing)
To solve the issue, we add a new field `invoice_is_ubl_cii` to check or
uncheck the UBL/CII checkbox by default.
In addition, rename the field `invoice_is_print` to
`invoice_is_download` since it corresponds to the checkbox 'Download'.
Finally, make the `company_id` of account.move.send a computed field
instead of using the `_default_get`. Indeed, when creating the wizard
and passing a `move_ids` key, this key will not be detected as missing
by the `default_get`, and we will not enter the statement in the
`default_get` in `account_move_send.py` to set the `company_id`. As a
consequence, the `company_id` will not be set, and the subsequent
computed fields will not be correct (e.g.
`wizard.company_id.invoice_is_ubl_cii` will always be False inside
`_compute_checkbox_ubl_cii_xml` if `company_id` is not set).
task-3297308
closesodoo/odoo#119397
Related: odoo/upgrade#4581
Signed-off-by: William André (wan) <wan@odoo.com>
This commits adds `account_peppol` module that allows:
- Registering as an account edi user and send an application to the peppol proxy,
where the participant can be approved or rejected after reviewing the documents attached.
- Sending invoices by selecting 'Send via Peppol' option in the send & print wizard.
- Receiving peppol documents.
task-3159912
closesodoo/odoo#119120
Signed-off-by: Laurent Smet <las@odoo.com>
Sending invoice in emails to customers now display View Journal Entry in
v16.2 instead of view Invoice.
Steps to reproduce the error :
1- Install accounting
2- Go to accounting/customers/invoices
3- Create an invoice and send it by email to the customer
4- View The email on mailhog
The reason of the error was becayse we didn't provide model_descirption
to the function of sending the email, so it will take the one by default
whch is Journal Entry.
opw-3289880
closesodoo/odoo#120480
X-original-commit: 21cab7ffa6a71a67b64d3a7e7a62a6599127343d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
When the `account.journal.bank_statement_source` field is validated at that time
it won't be able to find the `file_import` value in the options of this selection
field as they are dynamically generated and the `file_import` value is generated
in the `account_bank_statement_import` module which is not installed.
So, it will cause Error.
Steps to reproduce :
1. Install only `account` module
2. Click on Configuration > Add Bank Account.
3. Fill up the details. The `Journal` field should be left empty.
4. Click on Create.
closesodoo/odoo#120923
Sentry: - 4042261837
X-original-commit: eda822ce7c3884350ecfb8bbb10accfe7ff5acf4
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
We want to propagate the analytic breakdown on the accrued
entries that user can already create from the PO/SO list views.
task-3096126
closesodoo/odoo#120864
X-original-commit: d4d92029bf7c2a2c6a670170d3207b457dda5c68
Signed-off-by: William André (wan) <wan@odoo.com>
In the resequencing, if an account.move new name
correspond to an old name, it could trigger
the unique constraint ValidationError.
This temporarily rename the concerned moves to avoid triggering the constraint
Task-3280680
closesodoo/odoo#119427
X-original-commit: 18d73e235908b63534105434c78b3a637b827e10
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Bug:
Currently, creating an intra-community bill and reconciling it with an
early payment can break the tax report.
Steps to reproduce:
1. install the Austrian localization (l10n_at)
2. set `Cash Discount Tax Reduction` to `On early payment`
3. create a €1000 intra-community bill (you can just use the tax called
`IGE 20%`)
4. set the payment term to`2/7 Net 30` and confirm
5. reconcile the bill with a payment within the discount period
(2% discount: €980).
6. check the Tax Report: line 5.4 of the report should be €196. If you
reconciled the bill with a back statement directly, sections
`Innergemeinschaftliche Erwerb` and `Bemessungsgrundlage` will be
wrong as well.
Cause:
Since the intra-community applies here, the bill will produce two tax
lines. And because `Cash Discount Tax Reduction` is set to `On early
payment`, those two tax lines will be reduced when an early payment is
made.
However, because of the way the `is_refund` property of
`account.move.line` field is computed on moves of type `entry`, one of
those *tax reduction line* will be considered a refund and the other
will not. Furthermore, the computed tags are correct only because the taxes
are recomputed again when creating the payment.
After removing this extra taxes computation, both tax_tag_ids/tax_tag_invert
are invalid.
So the solution is to fix the method computing the taxes for cash discount lines.
Note: This commit also fixes the cash discount engine not working with multiple tax repartition lines since:
https://github.com/odoo/odoo/commit/9c134ec379819053e3fdd1e252e3a7ae8a949f42
opw-3112197
Enterprise PR: odoo/enterprise#39181closesodoo/odoo#118588
X-original-commit: de0db2429f7c47d52c1bad37b9d35d425c8d5b74
Related: odoo/enterprise#39775
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Co-authored-by: Laurent Smet <las@odoo.com>
When using message_post, the body format must be explicitly specified.
If html is expected, a Markup object should be used.
If text is given, the content will be escaped.
Before this PR:
message_post was unaware if the content of a message was HTML or
text. This lead to multiple situation where the content was
incorrectly considered as HTML and led to display errors.
In
self.message_post(body="Hello %s!" % self.name)
if the name contained HTML, it would be evaluated.
In
self.message_post(body="Contact Raoul <raoul@caramail.be>")
the email would not be displayed as considered as unknown HTML and
discarded by the sanitizer
Now each call must explict the type of content.
Use the escape() helper to properly combine Markup and translations.
It would also be acceptable to use Markup() to wrap a static
translation but escape is better as one can not guarantee the content
of a translation.
closesodoo/odoo#111850
Related: odoo/documentation#3612
Related: odoo/enterprise#36728
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
_* = sale_timesheet, account
In this commit, we have replaced the cancel button string with discord instead
of cancel.
task-3216495
closesodoo/odoo#115693
Related: odoo/enterprise#38341
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, the invoices were marked as sent only when
sending them via email or post.
After, it is mark as sent once the PDF is being generated via the
send&print wizard, as it becomes computed based on the presence of
the PDF.
Rational, we want to consider a generated invoice via the
send&print wizard as being sent as it can be printed/downloaded.
This also makes the invoice available in the portal.
closesodoo/odoo#117085
X-original-commit: 9e656aabe4f6840ee5c200a21832dad958ea6892
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Detry Thomas (det) <det@odoo.com>
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Odoo does not have much in terms of payment protection; you can create
payments to any account you want without many checks.
This changes it by requiring users with the right groups to trust an
account before allowing it to be used for payment methods requiring.
Also adds some warnings on the bank account view, and checks at the time
of creating a payment.
Task id # 3210415
closesodoo/odoo#114278
Related: odoo/enterprise#37789
Related: odoo/documentation#3737
Related: odoo/upgrade#4397
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Claire Bretton (clbr)