This commit changes the way transactions linked to a document (sales
order, invoice...) are created in a payment flow. Rather than receiving
and trusting the transaction values from the controller, they are now
read from the linked document, and the payment flow is rerouted to use
the document's module's controllers instead of that of `payment`.
This ensures that no unexpected value can be passed to the `create`
method of a transaction, and simplifies the implementation of the
payment flows of linked documents.
task-3136240
closesodoo/odoo#126425
Related: odoo/enterprise#43212
Related: odoo/upgrade#5124
Signed-off-by: Antoine Vandevenne (anv) <anv@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>
before this commit, on calling the fields_get method of
payment.link.wizard model from xmlrpc is raising exception,
instead of returning the data
after this commit, without any traceback the requested
data will be returned to the user.
closesodoo/odoo#129927
X-original-commit: 290210d1da38b7ee19f441117aa1448a43bcc8f5
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
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>
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>
This commit adds the possibility to define a maximum payment amount that
a given acquirer can process. If the payment amount exceeds the value,
the acquirer is filtered out of the available acquirers listed on the
payment forms.
While we're at it, the field `country_ids` is renamed to
`available_country_ids` to better depict that it is not a property of
the acquirer, but a configuration option. It will also be coherent with
the field `available_currency_ids` that is expected to be added soon.
Task - 2162165
closesodoo/odoo#82411
Related: odoo/enterprise#24412
Related: odoo/upgrade#3703
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Delete code that is not useful anymore and was introduced in
task-2666881 (PR #78334)
task-2694027
closesodoo/odoo#80051
Related: odoo/upgrade#3050
Signed-off-by: Antoine Vandevenne (anv) <anv@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>
This commit brings back the possibility to pass invoice ids in payment
links, a feature that was lost with commit 573ed74c. If such an id is
present in the payment link URL, the transaction that is created must
have a reference starting with the name of the invoice, and must be
linked to it.
task-2494916
closesodoo/odoo#72992
X-original-commit: 6c13a361400332955cdf5ac5a14bd1970b4f66ef
Signed-off-by: Victor Feyens (vfe) <vfe@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:
- Install account,payment
- Go to Invoicing
- Create an invoice
- Click Actions > Generate a Payment Link
- Follow the generated link
- Pay
Bug:
The transaction is not linked to the sale order in the link table
`account_invoice_transaction_rel`
Explanation:
This fix is broadly mimicking the behavior of the sales module regarding
the link of an order to a transaction, adding `invoice_id`s where they
are needed throughout the payment process in order to link the
transaction to the invoice.
opw:2451534
closesodoo/odoo#67296
X-original-commit: 7c6d06fa5858f79f3b22cdeaf74cdc26a642742f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: backspac <backspac@users.noreply.github.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>
In Sales, in Payment Link generation wizard, when entering manually the total of the quotation
as Amount, it can happen that the Validation Error asking to set an Amount smaller than the total
is triggered.
opw-2287794
closesodoo/odoo#54309
X-original-commit: a7034b75383f23f309d97a86cbde7d9f8176ed6d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
As some payment acquirers require the email to be set,
a warning is shown when generating a payment link if
the partner does not have an email.
OPW-2254011
closesodoo/odoo#51857
X-original-commit: 6f61e89ab9b947ca54cfd8dbd5470083a625d24e
Signed-off-by: Damien Bouvy (dbo) <dbo@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>
- 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>
When generating a link for a payment through the website_payment/pay
route, including the partner_id 'blindly' is somewhat of a security
issue since it means you could potentially create payments for any
partner of your choosing.
This commit instead introduces an access token mechanism where the
partner_id, amount and currency_id are used to generate a unique access
token that can be checked upon accessing the payment page. This token
is only checked if the partner_id field is set (otherwise this is just
an anonymous payment like any other).
Purpose of the task is, there is no easy way to request custom online
payments on sales orders or invoices. The only way is to create an
URL manually: /website_payment/pay?reference=inv-008&amount=123¤cy_id=1
So added menu 'Generate payment link' in action in sales order and invoice.
while making payment pass the partner so reconcilation account flow should not
break as partner_id on account payment is reauired to reconcile.
co-authored-by: sza-odoo <sza@odoo.com>
Task-1938635
Closes: #31575
Anita (anko)