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>
Create a standard tax that is included in the product price.
Add that tax to a product and the down payment product.
Create a sales order (i.e. 1 line, 115$ total, 15% tax incl).
Create a percentage down payment invoice, i.e. 50%.
The downpayment amount will be 50% of the untaxed amount,
i.e. 100$ @ 50% = 50$ with tax already included, so actually
lower than 50%
Forward-Port-Of: https://github.com/odoo/odoo/pull/65275
opw-2858506
closesodoo/odoo#93531
X-original-commit: 9f9c73b33924b6093e550be63786640d8bbb9e79
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Translate the product name "Down payment"
when it is created "on the fly" from wizard.
X-original-commit: 17f460587a207d708f1b9d9a0c6d080e64f9eac8
Part-of: odoo/odoo#93249
Before this commit, when cancelling a SO, the wizard opened only when
there were draft invoices or delivered picking in the order.
In order to complete the notification flow of the SO and avoid
unexpected cancellation of orders, the user must now confirm
cancellation and gets to possibility to send an email notification.
task-2660895
Part-of: odoo/odoo#81569
Steps to repoduce:
- Accounting > Customers > Invoices:
select several invoices to send
- Action > Send & Print > (deselect Print) > Send & Print
Issue:
- It sends only one invoice per company
Cause:
- the mail_compose_message sets the status of an email as `cancel` when a mail has already been sent to a specific adress mail in the batch
Solution:
- If the use of mass mailing is document-based (e.g.: sending multiple invoices) it will allow to send multiple emails to the same adress
opw-2775121
closesodoo/odoo#88992
X-original-commit: f08685020f6a00d4e10e30ccbcf70c9eb1a764d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit lighten payment onboarding form in order to take advantage
of the Stripe Connect Onboarding Flow. It integrates the Stripe
Onboarding using the IAP proxy.
Purpose
=======
Help users easily onboard with Stripe by using the Stripe Connect API.
Specifications
==============
During the payment onboarding, if the user selects Stripe, they will
start the Stripe Onboarding. (NB: The process uses a proxy that handles
the Stripe Onboarding calls and signs them with the Stripe Connect key)
1) A call is made through the proxy to get the Stripe account token;
2) A call is made through the proxy to get the Stripe account link which
contains the URL of the Onboarding;
3) The user is redirected to the Stripe Onboarding;
4) The user completes the Stripe Onboarding;
5) The user comes back to the acquirer form of Stripe and is able to get
their keys.
6) The user can directly create their webhook after having copied/pasted
their API keys.
During the website sale onboarding, the user doesn't go through the
onboarding wizard but is directly prompted to activate their account.
Note that the Onboarding status isn't stored in the database so there is
no call to Stripe API to validate the account status.
API Documentation :
- Connect Onboarding: https://stripe.com/docs/connect/standard-accounts
- Webhook creation: https://stripe.com/docs/api/webhook_endpoints/create
task-2685160
task-2691213
closesodoo/odoo#84639
X-original-commit: 085f4af4e57c43127413585a8df5b3aa47843339
Related: odoo/enterprise#24376
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Thibault Libioulle (tle) <tle@odoo.com>
Prior to this commit it was not possible to get a hook from
sale.advance.payment.inv in order to get the created invoices.
The create_invoices def returns either an action or an ir.actions.act_window_close
The introduction of the _create_invoices def will allow to get the created invoices
from the wizzard.
task-2608812
Closes: #79926
Current behavior :
When creating payment from invoice, the payment had the wrong sales team id
Steps to reproduce :
- Create atleast 2 invoices with different sales team and same partner
- Register payments for every invoice
- Go in payments list view
- Filter on partner and group by sales team
- All the payments are grouped in the same sales team
opw-2681041
closesodoo/odoo#82114
X-original-commit: 2f3ebe86b2d520dd9c7570f60056f200bb091aab
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
How to reproduce:
- Have a databas with 2 companies (A and B)
- Create and confirm a sale with company A
- Switch to company B
- Create a down payment invoice.
Bug:
When generating an invoice from a sale, the company of the invoice
should always be the one from the sale.
closesodoo/odoo#80523
Opw: 2631354
X-original-commit: a345d2f4a45179b1c3cecb5be983d3ef2435d0f8
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When a user was opening the payment_link_wizard and tried to select a
preferred payment acquirer, he was getting an AccessError telling that
he was not allowed to access 'payment.acquirer' records.
Fix PR #69334 (task-2504225)
task-2666881
closesodoo/odoo#80005
X-original-commit: 2ff580c073ac105219582dbf2108a1437645c9b5
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In this commit some reorganization is performed within mail compose message
code. Purpose is to reorder a bit methods by main usage: onchange, CRUD,
actions, values generation with rendering and template management.
Some renaming is performed on action methods, notably send_mail that has some
impact on sub-addons. Finally we also set onchange and sub-onchange methods
private.
No functional change should be implied by this commit.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Actually, salesmen have to add manually the acquirer_id to the link, and it isn't user-friendly. The dropdown will show the possibility to add the acquirer_id.
Task #2504225closesodoo/odoo#69334
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Valentin Chevalier <vcr@odoo.com>
This commit replaces the old online payments API of the `payment`
module with the new one and adapts to it all the implementing modules.
See the merge commit for more details.
task-2085989
task-2119838
task-2165982
task-2289255
Co-authored-by: Victor Feyens <vfe@odoo.com>
Steps:
- Go to Settings > Users & Companies > Companies
- Create a new company (1)
- Install a payment acquirer and Website
- Go to Website > Configuration > Settings:
- Select "My Website 2"
- Assign it to company (1)
- Add a custom domain
- Save
- Switch to company (1)
- Go to Invoicing
- Create a new Invoice:
- Add a product line
- Post it
- Click Action > Generate a Payment Link
Bug:
The base domain is used instead of the domain of the website linked to
the invoicing company.
Explanation:
The app only uses the URL on which the user has logged in to generate a
payment link. If the user has multiple companies, this can confuse
customers if they land on another domain than the one they are used to.
This commit makes the app use the domain of the website of the record
linked to the payment if it has one.
opw:2440251
closesodoo/odoo#65938
X-original-commit: 700dba53843e71f5f34c86305cc658d9273914aa
Signed-off-by: backspac <backspac@users.noreply.github.com>
- Set a customer language to a different language, e.g. French
- Create a SO, add a product and validate
- Create a down payment
The down payment invoice is partially translated in French.
This was first solved in fc659d3f78 but broken in
0e73eca1364c8e0df93cd.
opw-2365982
closesodoo/odoo#61207
X-original-commit: f10b98d1776659f291b2f7f8a4a2111e4f106667
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When generating a payment link through the payment link wizard, the
company was previously not included. This could cause accounting issues
if the acquirer displayed to the customer were not part of the same
company as the underlying document that generated the link.
This commit add a new computed field 'company_id' on the wizard model
that gets computed based on the underlying model; this field will be
included in links generated by the wizard to limit the acquirers
displayed to those of the that company, preventing extra acocunting
steps (interco reconciliation).
opw-2254011
closesodoo/odoo#51441
X-original-commit: a6fcd7e0cfec8d4c62620a53b5fa806561e239af
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
* The first tour is starting in the sale app dashboard and ensures
the user goes through the needed configuration steps
* The second tour starts in the new Quote form and shows the flow to
send a quote to a customer
TaskID: 2187222
Closes: #46167
- 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#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Before this commit, Payment URL was not encoded correctly which can compute Payment refernece Wrongly on website.
Eg,
Enter Description which contains Special Characters
Go to Payment Page using Computed URL.
There will be wrong Payment Reference on Payment page.
With this commit, We encode Payment reference before generating Payment URL.
closesodoo/odoo#47387
X-original-commit: 6ebcc43d177b9333afa73ee90e976d57111aaf3d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- In debug mode, create a SO
- Confirm the SO
- Click on "Create invoice"
- In the wizard, click on the debug logo
- Set a User default value V for Downpayment amount
- Close the wizard
- Re-click on "Create invoice"
Bug:
The default value V was not suggested.
Fine tuning of c258b8a0427bd5aface891ed1f4420174f4afde4
opw:2184367
closesodoo/odoo#45512
X-original-commit: f95550d59ddeb8a77cb7b72592cc4aafb210aa25
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before this fix, an empty sale order produced a traceback when the invoice was created.
closesodoo/odoo#42750
Taskid: 1997415
Related: odoo/enterprise#7540
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Valentin Chevalier