When enable, this new feature adds the possibility to set a PDF header, footer and some product
documents to the quotation report.
These PDF can contains forms that'll then be filled using Odoo database.
This replace the previous sale quotation builder feature.
task-3249142
closesodoo/odoo#133773
Related: odoo/upgrade#5168
Related: odoo/documentation#5863
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Morgane Demesmaeker <edm@odoo.com>
This previous commit : https://github.com/odoo/odoo/commit/d197efa60cf7c00168847ce7afcfa1741410aee1 aimed at ventilating rounding error corrections on multiple lines. But this would introduce errors or unbalanced moves if the rounding amount/lines quantity was smaller than the rounding of the currency. E.g. à 0.01€ error divided on 3 lines would add 0.00333 on each line, and when the amount is rounded, it would vanish.
closesodoo/odoo#136366
X-original-commit: 0627b4609e8b1b3d15651d6cde0ff4cfdc85c5d6
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
When a user creates a downpayent with a fixed amount, the amount is tax included. This can generate rounding issues as sometimes the amount is impossible to be reached by any base amount / tax combination. (fixed amount = 100€, tax is 21% -> 100/1.21 = 82.64 -> 82.64 * 1.21 = 99.99). This can lead to up to 1 rounding error per downpaylent line.
Until now the total amount delta was added/removed on one tax line, one receivable line and one product line. While the total amount was correctly corrected, the amount on the individual lines would be off.
On a SO with :
base | tax | tax incl
1000€ | tax_21%_a | 1210€
1000€ | tax_21%_b | 1210€
Generate 1 DP for fixed amount 200€
Invoice lines :
BEFORE:
tax | balance | price_total
base lines ----------------------
tax_21%_a | -82.64 | 100.01 <-- 0.02 correction
tax_21%_b | -82.64 | 99.99
tax lines -----------------------
| -17.37 | 0.0 <-- 0.02 correction
| -17.35 | 0.0
receivable line -----------------
| 200.0 | 0 <-- 0.02 correction
AFTER:
tax | balance | price_total
base lines ----------------------
tax_21%_a | -82.64 | 100.0 <-- 0.01 correction
tax_21%_b | -82.64 | 100.0 <-- 0.01 correction
tax lines -----------------------
| -17.36 | 0.0 <-- 0.01 correction
| -17.36 | 0.0 <-- 0.01 correction
receivable line -----------------
| 200.0 | 0 <-- 0.02 correction
closesodoo/odoo#135698
X-original-commit: d197efa60cf7c00168847ce7afcfa1741410aee1
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Before this commit, the payment providers (e.g., Stripe, Adyen...)
available for payment were displayed on the payment forms. The customer
had to select one to process their payment. After that, the customer had
to select their preferred payment method (e.g., Credit Card,
Bancontact...) from a list of payment methods supported by the selected
provider over which the website administrator had close to no control.
This was making the payment forms confusing because the payment methods
were displayed sometimes more than once, if at all, in a non-controlled
order, and behind the selection of a payment provider that customers
should not have to deal with.
As the payment method was selected in an iframe or directly on the
provider's website, the information on the selection payment method was
not available in Odoo. This posed many problems, among which were the
impossibility of assessing whether a specific feature (e.g.,
tokenization, refunds, manual capture...) was available, not being able
to easily identify payment tokens through the payment method logo,
listing available payment methods on the website, sorting and
fine-grained configuration of the available payment method, subpar
payment method-specific display on the payment form (e.g., PayPal that
requires displaying a "Pay with PayPal" button), etc.
In this commit, the payment providers are thus replaced by the payment
methods on the payment forms. All contextually available (depending on
the country, currency, requested feature...) payment methods are
displayed one after the other on a single-level list and in the order
configured by the website administrator. Each payment method is
"powered by" (i.e., linked) to a single payment provider: the first one,
by model order, to support it. This allows, for example, offering the
PayPal payment method through Mollie, which charges low processing fees,
while also offering Klarna through Stripe, which supports more payment
methods but charges higher processing fees.
While doing so, the two different payment forms, "Checkout" and
"Manage", are also merged together in a new, configurable case-by-case,
payment form that is entirely redesigned to offer a better user
experience.
After payment, the information on the selected payment method is saved
on the transaction and eventual payment record and updated with the
information received from the provider.
task-2882677
closesodoo/odoo#120446
Related: odoo/upgrade#5103
Related: odoo/documentation#5717
Related: odoo/enterprise#40666
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Anita (anko) <anko@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Valeriya (vchu) <vchu@odoo.com>
Some businesses requires customers to pay a down payment in order
to confirm the order. In the case of odoo today this implies to:
- sending a payment link
- waiting & checking if the payment has been done
- confirming the order
- creating the down payment invoice
A lot of time consuming manual operations with a high risk of errors.
This commit introduces the functionality for sales orders to be
confirmed on down payments and automatizes the flow to minimize the
errors due to human manipulation.
Task - 3087716
Part-of: odoo/odoo#124297
Co-authored-by: Victor Feyens <vfe@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>
When rendering the sale order cancellation message,
the rendering should apply the current user record rules,
for instance the count of the partner sale orders should
match the count of what the salesman can see in his ui.
Otherwise he doesn't understand why he has a different count
in the UI and in the cancellation message.
In case you want the behavior of seeing all records
and not just the current salesman records only,
then you apply within the template itself the
`sudo()`.
Applying the `sudo` where you actually need it in the template,
and not computing the full subject/body as sudo,
offers more granularity.
closesodoo/odoo#135233
X-original-commit: 5d49a08f60b1f299784e2e983e87cdec178642c1
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When possible, use 'email_formatted' field on partner, instead of calling
'format_addr'. That way management of corner case input (multi emails and
double encapsulation) is managed by the computed field itself.
When 'format_addr' has to be used, ensure email part is normalized to avoid
formatting issues.
Also use tools to extract emails instead of 'email_re' regex when possible.
That way all code extracting and managing emails go through the same stack.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1c06014531
Part-of: odoo/odoo#134934
Create [TAX] as 21% included in price tax
Create a Sale Order with the lines:
- Product A, qty 1, unit price 900$, tax [TAX]
- Product B, qty 2, unit price 90$, tax [TAX]
- Product C, qty 4, unit price 49$, tax [TAX]
Confirm order
Create a downpayment with fixed amount of 550$
Go to the downpayment invoice
Issue 1: price total on the downpayment line is 549.99
when we make the downpayment we convert the fixed amount in percentage
and then compute the downpayment amounts.
This result in some rounding issues that are only partially corrected
The price total on the product line was not corrected
Confirm the downpayment invoice
Go back to SO
Hit create invoice again
Issue 2: 'Already invoiced' amount will be 549.99
When the make invoice wizard is created we operate on virtual records of
SO and invoices.
In particular, when the amount_to_invoice is recomputed, instead of using
the value saved in DB the system recompute the total of the downpayment
invoice from the lines, introducing a rounding error which is
manually corrected only when creating the downpayment
opw-3466409
closesodoo/odoo#133836
X-original-commit: e1c85283736deac7dd523f115e6ba9033b656ade
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
before this commit, if there is multiple sale order for a
customer, and if we try to create new invoices for this
orders from the tree view, it creates one invoices for
all the orders.
there will be cases, where we have to create separate
invoices for each orders.
after this commit, a boolean will be introduced in the
wizard, by which user can decide one invoice or multiple
invoice by grouping sale order.
closesodoo/odoo#128351
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
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>
* = 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
Following 78ae3da902 names were added to improve the view inheritance.
But some names were duplicates. This commit will ensure every name is unique to facilitate
inheritance.
closesodoo/odoo#122270
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
When creating payment links for the customer, the user can now decide on a partial amount to be
paid at the time.
Use case: when the customer cannot pay the SO amount with one payment, e.g. limit on the credit
card, the user will now have the possibility to set a partial amount on the payment links.
The order will be automatically confirmed when the amount chosen is equal to the remaining amount
to be paid.
Additionally, the customer will be notified by email for each payment done instead of only at the
confirmation of the order, which will happens only once the total amount is paid.
Task - 2672713
closesodoo/odoo#109661
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Horacio Tellez <hote@odoo.com>
Co-authored-by: Morgane Demesmaeker <edm@odoo.com>
This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
When converting a quotation to an invoice with a fixed down payment
amount and the total amount of the quotation is zero, a float division by
zero error occurs. This is because the total amount is zero, and it tries
to divide the fixed amount by the total amount.
This commit solves the above issue by dividing a fixed amount
by one when the total amount is zero and added the test case.
sentry-4079147910
closesodoo/odoo#119957
X-original-commit: 41d3bf23770ef1716e9d34e7930adad58a17c7de
Signed-off-by: Ansari Mahamadasif (maan) <maan@odoo.com>
## Summary
Currently, when using both an early payment discount (upon invoice) and
price-included taxes, the invoice totals are not calculated correctly.
## Steps to Reproduce
1. Set `Cash Discount Tax Reduction` to `Always (upon invoice)`.
2. Create an invoice with the payment term set to `2/7 Net 30`.
3. Add an invoice line with a price of 100 and a 21% price-included tax.
4. Save the invoice: The `Untaxed Amount` should be 100, but it
incorrectly shows 100.35 instead.
## Cause
When calculating the totals, the price-included tax is applied to one of
the early payment discount lines. Since the tax is price-included, the
system recalculates a new base price for the EPD line, which ultimately
leads to an incorrect `Untaxed Amount`.
opw-3239904
Enterprise PR: odoo/enterprise#39007closesodoo/odoo#119892
X-original-commit: 43b78a96a8961b83cf1c18f58bd549dabc90c50f
Related: odoo/enterprise#40404
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Co-authored-by: Laurent Smet <las@odoo.com>
The goal is to take into account the confirmed
and un-invoiced sales orders in the total receivable of a client.
It will be useful in the scope of the credit limit trigger.
This is broken down in 3 steps:
1. Add the Remaining Amount to Invoice (RAI) in the
Invoice creation wizard of the Sales Order and store this data.
2. Add the RAI in the Total Receivable of the client.
3. The Remaining amount to invoice goes to optional="hide"
in the list view of "Orders to invoice" list view.
task-3122390
closesodoo/odoo#112905
Signed-off-by: William André (wan) <wan@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>
When cancelling a confirmed order the message displayed on the chatter was en English, regardless of the language set for the customer or the user.
After this commit the correct language will be used.
opw-3175301
closesodoo/odoo#114162
Forward-port-of: odoo/odoo#113977
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Break down payments down per tax. When creating a down payment for a sale order, create one line per tax instead of one line for the enire order.
[Sale Order]
Product Qty Unit price Tax Subtotal
Product1 1 1000 10% 1000
Product2 1 1000 5% 1000
====
Untaxed 2000
Tax 150
====
Total 2150
Make a 50% (1000) down payment :
[BEFORE]
Product Qty Unit price Tax Subtotal
Product1 1 1000 10% 1000
Product2 1 1000 5% 1000
Down pay 1 1075 0
====
Untaxed 2000
Tax 150
====
Total 2150
[AFTER]
Product Qty Unit price Tax Subtotal
Product1 1 1000 10% 1000
Product2 1 1000 5% 1000
Down pay 1 500 10% 0
Down pay 1 500 5% 0
====
Untaxed 2000
Tax 150
====
Total 2150
closesodoo/odoo#105177
Task: 2678531
Related: odoo/enterprise#36331
Signed-off-by: Laurent Smet <las@odoo.com>
Show alert on make invoice wizard if any invoice is still in draft state as draft invoices (and downpayments) will be taken into account into the computing of the amount when creating a new invoice
Task: 2678531
Part-of: odoo/odoo#105177
This commit reworks the display of the default SO values
in the settings to make it clear to the users what those
settings impact and that they are overridden by the quotation
template when specified.
task-2880950
Part-of: odoo/odoo#97565
Allow the feature activation by company instead of database.
It wasn't logical to specify the days by company but enable/disable
the feature by database.
task-2880950
Part-of: odoo/odoo#97565
'email_from' fields are not necessary on 'sale.order.cancel' and 'survey.invite'
as anyway we always use the current user's email and field is not present in
form view. Override of default_get to raise about invalid email_from is not
necessary as anyway it raises when posting the message. Giving author_id to
message_post is sufficient as it computes email_from based on author when given.
Add 'render_model' in views, as it is part of the domain given to 'template_id'
field of composer mixin. When missing, also add 'lang' and 'template_id' that
come from the render mixin.
Use '_render_field' when possible instead of '_render_template' as its API
is simpler and uses field definition for rendering parameters.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
before this commit, the documentation link was missing for shipping connectors in the sales and website settings.
after this commit, the documentation link will be shown for each connectors as it is currently displayed in the inventory settings.
closesodoo/odoo#109885
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
For a lot of clients, the number of quotations is big, and canceling
them one by one is time-consuming.
task-2991744
closesodoo/odoo#104531
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The tooltip for the setting module_product_email_template refers to a setting in the Sales tab of the product, but this has been moved to the Accounting tab in v15. Due to stable policy, this is fixed in master
task-3095455
closesodoo/odoo#107634
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Cleanups and fixes/improvements extracted from another task
on the settings of sale.
* indentation
* code simplification
* privatize method not meant to be called by rpc
* double quoted strings for strings shown to users, single quoted for
technical strings
* translate onchange warning message
closesodoo/odoo#107897
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Update addons
* in purchase and sale: context key update should be done at message_post
level, especially this is not used in mass mailing mode;
* in website_sale: code to update sale order to avoid sending recovery
emails several times belongs to a "post hook" method on sale order model;
* in loyalty: remove a deprecated / unsupported 'mark_coupon_as_sent' key;
Task-2792146 (Mail: Move model-dependent code from composer / template)
Part-of: odoo/odoo#106658
We can call ``_render_field`` on template model directly. In this commit
we also add the dynamic language computation through ``_compute_lang``.
It will use the field defined in template.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106072
Due to recent improvements (Jinja -> Qweb, safe rendering) rendering API
supports several ways of giving options to the rendering process. Those
have mainly two usage
* ``preserve_comments`` : keep comments in rendered HTML, used notably
in mass mailing or digest to keep browser-specific comments;
* ``post_process`` : perform a post processing on rendered HTML, used notably
to process local links and add tracking to shortened links;
All those are now given directly inside an optional ``options`` parameter
given to ``_render_field`` and its sub-method ``_render_template``.
They can also be defined as field level, using ``render_options`` field
parameter. Some fields are updated
* composer mixin body (which impacts all inheriting models, notably
mail composer, survey and elearning invite wizards as well as appraisal
and appraisal feedback): post processing is now always done by default.
It was already done manually in calls that can be simplified;
* mail template body_html: post processing is now always done by default. It
was already done manually in calls that can be simplified;
* mailing body_html and preview are now post processed by default. It was
already the case in testing wizard. Preview is updated to avoid post
processing of links, as it was before. Remaining use case is the sending
which uses the mail composer, therefore was already post processed;
Finally some 'compute_lang' are explicitly added in _render_field calls in
order to be explicit on what we want, instead of being unsure.
Task-2710804 (Mail: Clean MailThread API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#106072
Purpose is to try to have code easier to read and to update by having a
common way of sorting / writing code. Reorder some fields definitions and
dictionaries, update docstrings, ... in mail applications or when invoking
mail thread API.
Additional stuff worth noting here
* add some tagged in tests helping debugging / choosing tests to execute;
* in a test about mail generation with server action: correctly check
body_html field, not body which comes from the mail.message inheritance
(currently filled due to a side effect but actual field to check is the
html one);
* add same check on input for ``_render_template_qweb`` as done on other
rendering methods (even if rendering on [False] should be supported);
* move code translation update from specific tests into main test class
(code update due to new translations, followup of odoo/odoo@f8c2b02abe);
Some test linting done here
* reorder mail_render tests, remove some duplicated tests;
* reorder mail_template tests, remove some duplicated tests;
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#106025
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The goal of this commit is to get rid of the analytic tags as they were confusing, serving tag purposes as well as distribution on analytic accounts.
Everywhere analytic tags were used as a distribution have been replaced with a new widget that will dispatch distribution on analytic accounts. If there was an analytic account field next to the tags, it has been included in the distribution.
Analytic tags that were used simply as information tags have been removed.
To fill the new widget, there are now 2 kind of rules that will help fill and prefill it.
The first are applicability: previous groups have been removed, and have by replaced by plans. Each account is required to have a plan. These plans define when they are available in the widget: a default applicability per plan and applicability lines that can specify rules following the context of the widget.
The second one are distribution models, that will replace previous default rules but follow the same principles. The accounts (and so the plans) that will be given by the distribution model can override the applicability rules from before.
closesodoo/odoo#98914
Related: odoo/upgrade#3885
Related: odoo/enterprise#30743
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: Habib (ayh) <ayh@odoo.com>
Purpose :
Improve multiple use cases while handling the Accounting part of Cash Discounts in Odoo.
When creating a Payment Term, the user can now specifically design an early payment discount for each payment term lines.
The user can choose between three different kind of tax computation for the discount. If the conditions for the cash discount are fulfilled, the tax will either be:
- included : the tax and base amounts will be discounted.
- excluded : the tax will be left untouched, the base amount will be discounted.
- mixed : the tax is durably discounted, the base is discounted if the early payment occurs.
The discounted amount and the conditions to fulfill are printed below the invoice PDF if the option to do so is checked.
Took the opportunity to improve the display of the payment terms on the invoice in general.
Registering a payment while filling the condition for an early payment discount will prefill the fields accordingly.
The Journal Items in the account.move, the payment and the reconciliation are modified as needed to take the discount into account.
Reconciliation --> In the reconciliation widget, the logic of Early Payments Discounts is also applied to allow as often as possible for an automatic reconciliation.
Related : odoo/enterprise#28607
Task-2968644
closesodoo/odoo#99572
Related: odoo/enterprise#31225
Signed-off-by: Laurent Smet <las@odoo.com>
Changing the name of model payment.acquirer to payment.provider
and everything that it touches. It is technically incorrect to
use the term "acquirer" for systems that only provide a service
of payment.
After this commit the model payment.acquirer and all related to
it will be renamed to payment.provider.
Task - 2842088
closesodoo/odoo#90899
Related: odoo/upgrade#3542
Related: odoo/documentation#1981
Related: odoo/enterprise#27131
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
1) Invoicing wizard refactoring
* reduce the use of context in the business logic,
store the orders being invoiced
* factorize invoice creation values, using the correct method from
the sale.order model
* switch from default fields to computed fields, and avoid computing
unnecessary fields when the wizard is opened to invoice multiple
orders together (most fields are only used for down payments)
* Rely on python constraints instead of error messages scattered
accross business methods to notify the user that the invoice cannot be
created.
* Clean the code to make it easier to follow, understand and maintain
2) Distinguish Down Payment Invoice lines from standard ones
(with a dedicated field)
Allows to stop relying on the dumb property,
not specifically reliable, e.g. if the down payment product is modified
in the settings after down payments orders were already created.
closesodoo/odoo#98600
Related: odoo/enterprise#30653
Related: odoo/upgrade#3799
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Until now, there was no way on a given sales order to distinguish
draft, cancelled and posted down payments.
This commit makes sure the down payments state is clearly
shown as draft or cancelled when the linked invoice is
in the corresponding states.
Also remove those draft and cancelled down payments from the sale
portal & report as it can be confusing for customers to see line(s)
of down payments they never heard of.
Lastly, follow the existing behavior of invoices, where the down
payments were shown in a separate section. Now a dedicated section
will be added to the sales order and propagated to the invoice,
if there are down payments to deduct.
Task - 2702407
closesodoo/odoo#82376
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
