The payment.transaction type field allows filtering some potential
payment methods down the line of a transaction being created; e.g. if a
subscription product is present in a quote, the payment's type should be
`form_save` to save the payment token for future use on the subscription
that will be created at confirmation.
The transaction that got created by sale flows did not set the type of
the transaction correctly, and this value was not propagated to the
rendering values of the acquirer. It now is.
This is necessary as part of task 2275051, where we need to know which
payment methods to enable in Stripe depending on a need for tokenization
or not (since some methods are not tokenizable).
closesodoo/odoo#54426
X-original-commit: 09dbbd77d83332c48f62b1c36c3b33ddbfa3a4eb
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
There is a discrepancy between what country is used to compute the
fees for a transaction depending on where we are in the payment flow.
At rendering, the country of the order's shipping partner is used (since
it is set as the main partner in the rendering values dict through
`render_sale_button`).
At creation, the country of the partner is used (since the
`payment.transaction` record is created with the order's main
`partner_id` in `_create_payment_transaction`).
This is unfortunate and can cause issues with payment flows if there is
a mismatch between countries of the shipping/invoice/main partner, as
the fees may be computed as 'international' in one case and 'domestic'
in another - this causes the values sent to Paypal to differ from those
saved on the transaction, which causes the transaction to be rejected
upon return from Paypal because of an amount mismatch.
Since the transaction is created using the main partner of the order,
I believe it is preferrable to use it for the rendering as well. Some
may dislike this choice, as it means that if you use these fees to
manage your delivery fees, a customer with a shipping address to is not
the same as the company's country will pay domestic fees, while they
should pay international ones. However, this is mitigated by the fact
that:
- this did not work before this commit (hell of an argument)
- the delivery module is there to handle those cases with much higher
configurability
- having a consistent computation is more important than managing this
case
opw-2225023
closesodoo/odoo#48519
X-original-commit: a8689769afa22fb633f2e911f1a4dea6caa193d3
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This code adapts all business code instances of calls to
`resolve_2many_commands` and replaces them by calls to `new` which
returns a record-like object whose api is more familiar than the
`resolve_2many_commands` api.
- In an e-commerce with automatic invoice set;
- Buy something as public user;
- Pay the order;
Before this commit, the client don't receive the invoice confirmation
email.
opw-2176506
closesodoo/odoo#44494
X-original-commit: 684e678e1240f444ccdcd31939456fe57177b5b2
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
No need for selection fields
If in global variable, the _lt should be used instead
closesodoo/odoo#31211
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
- When validating a payment an "expected singleton" exception is
raised due to the fact that we are using a recordset with multiple
record instead of a recordset with a single record.
OPW-1981632
closesodoo/odoo#33767
Signed-off-by: Christophe Simonis <chs@odoo.com>
Purpose is to make field use more obvious by correctly stating in the
name it should contain an xml id to a qweb layout used for email
notifications. This renaming is propagated through various calls and
addons.
Related to task 1943901
Linked to PR #32404
Purpose of this commit is to send the order and payment details email to user
when they purchase any order from ecommerce or when do the payment from
portal. Currently it was sending quotation mail when the payment is processed.
Now it send an email for quotation, and one email for sale confirmation that
may contain more detailed content if coming from website (eCommerce).
In sale
* create new confirmation template and set the default template in sales
settings;
* when payment enabled in sales settings then display template option to send
default confirmation mail when payment is processed or order signed;
* add tool method to find the right template to use when sending the
quotation / SO by email;
* ensure email is sent everytime SO is confirmed;
In website_sale
* add option in website setting in order, to set the confirmation mail
template;
* ensure email is sent everytime SO is confirmed;
Related to task ID 1873634
Linked to PR #28781
Purpose is to prepare improvements in emails sent in confirmation and payment.
A context key forcing email used only once in the code is removed. Method
used to send email is inlined. It allows to better understand flow.
Related to task ID 1873634
Linked to PR #28781
Commit d139e92c62 set the force_send to True
unless there is an explicit mail_notify_force_send set to False in the context.
The _get_eval_context puts mail_notify_force_send to False in the context,
but it might be lost before reaching that method call.
Launch a cron that starts a transaction, see if it goes through,
and rollback if it didn't,
then the mails send inbetween will be sent every time the cron restarts.
E.g. _cron_post_process_after_done.
opw 1921112
opw 1945953
closesodoo/odoo#31605
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Purpose
=======
The method named "action_invoice_create" in the sale_order model did not make sense:
- this method is not an action (it returns the ids of created invoices)
- it is not used as an action on any xml buttons
- it has no reason to be private
This was probably a "real" action somewhere in the past but now it's just too confusing.
(The method in repair.order was also renamed for the same reasons).
Purpose of this task is,
Default payment ref for wire transfer is confusing and not really helpful as it will induce encoding errors customer side
So, I removed modulo part in payment reference
Task Id : 1946656
Closes : #31853
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Configure custom payment instructions
- Create a SO, send it by email to the client (do not validate)
- As the client, open the link received by email and 'Accept & Sign'
- Click on 'Pay Now', choose 'Wire Transfer'
The page reloads and shows the message:
> Pending... The order will be validated after the payment.
along with the custom payment instructions. However, no communication is
provided for the payment.
First, the `reference` is never set when calling the
`payment_confirmation_status` template, as it is done in
`portal_invoice_page_inherit_payment`. Moreover, in this workflow, the
reference is never set on the SO because of an incorrect filtering in
`_set_transaction_pending`.
opw-1906464
closesodoo/odoo#28466
The email sent after an electronic payment is sent using the
quotation template instead of the order template.
This PR changes the way payment are done in the backend so
the order has the correct state before sending the email.
opw-1894258
closesodoo/odoo#27847
This commit aims to improve the user experience when using payment acquirers. There currently are no error feedback with some acquirers, which leaves the user wondering what is going on and what is the real status of its payment.
In some cases, the user is currently being redirected to the home page even though the payment has failed. We want to make it more obvious to the user that something unexpected has happened by redirecting to an intermediate page that will provide good feedback on payments status.
Another goal of this commit is to order acquirers by sequence instead of by flow and to select the first acquirer by default. This feature was already implmented in commit fe294fd43e521bd2d339e962f43acf46c3d4cb97, some UI adaptations were needed though.
Related to task #36680Closes#26958
Like invoices, a reference is now computed on sales orders.
The configuration of such reference is done through the Wire Transfer acquirer.
The usability of the communication feature (on invoices/SO) has been a bit improved to be more clear.
Was task: 1870121
Was PR #26152
[MOV] move sale_payment into sale
=================================
Almost all use cases of sale require sale_payment down the line.
There is only one case which does not: using sale_management without website_sale or website_quote.
However, since we want to move most of the features of website_quote into sale_management, moving sale_payement first will make the task easier.
[MOV] move website_quote into sale and sale_management
======================================================
We want to use some features of website_quote without having to install the whole module.
The main issue with website_quote was that it had a requirement on website.
What is common to website_sale and sale_management has been moved into sale. This is primarily the sales order portal view.
What is only related to sale_management has been moved into it. This is notably: sales order templates, optional products, sign and pay, ...
Everything that requires website has been moved into a new module named sale_quotation_builder. This is related to using the HTML builder to customize the quotation view.
Models, files and routes have been renamed to better convey their purpose and to follow guidelines more closely.
[IMP] merge sales order portal views
====================================
The old sales order view on the portal has been merged into the one from website_quote. The new view contains features of the two.
A lot of fixes and improvements have also been done, related to BS4 issues but also to improve the sales order view in general.
[IMP] add new settings
======================
The commit adds new settings related to activating the features that previously were activated by installing website_quote.
PR: #26345
Task: 49205, 1838924
Florent de Labarre