While sending payment request to acquirer
the amount used was the amout_residual_signed
This amound is in the currency of the company
and may be negative.
The currency send to the acquirer is the
currency on the invoice so you expect the
amount to be in the same currency and
being positive
amount_residual is exactly that amount
Solution: user amount_residual
instead of amount_residual_signed
closesodoo/odoo#46082
X-original-commit: 1d1d5e27b4ad9f5ecbca60d8dacd4620d25dda99
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- 'partial' payment state corresponds to invoices whose payable/receivable move line has been partially reconciled with some other line.
- 'reversed' payment state corresponds to entries that have been cancelled by the creation of a single reverse entry (using the dedicated button on the form view). This state can be set on invoice as well as on regular entries.
=> To stay consistent with the naming conventions, this commit also renames invoice_payment_state field to payment_state, since it's no longer only applicable on invoices.
closesodoo/odoo#41723
Related: odoo/enterprise#7202
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Activate option to pay invoice on the portal
Activate an acquirer with the mode: handle payments in Odoo
Make an invoice for a partner
Access that invoice through the route with the access_token
You should not be logged in !
Try to pay, with stripe for example
Before this commit, there was a cryptic error syaing that the credit card ID was invalid
This was because the transaction token was created on the public user
While we tried to access it as the invoice's partner
After this commit, there is no error as the transaction token is on the invoice's partner
OPW 2034691
closesodoo/odoo#34919
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Some leftovers of
https://github.com/odoo/odoo/commit/beaa30a3d1843de43a45f419bfbc1bfa7613a920.
Fields have been renamed according to the following mapping:
residual_signed -> amount_residual_signed
reference -> ref
State 'open' does not exist anymore, use 'posted' and combine it with
'invoice_payment_state' instead.
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
purpose of this commit is to show modal with proper height
before this commit:
currently, the modal structure was not correct, so it is displaying
modal-content twice in the modal that's why it shows modal with full height.
after this commit:
correct modal structure to show it properly, so payment modal in the portal view
looks like as expected.
task-2025869
closes: https://github.com/odoo/odoo/pull/34334closesodoo/odoo#34334
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
- Activate online payment of invoices
- Activate and configure Stripe
- Create an invoice, access it through the portal
- Pay it with Stripe
The user is redirected to `/my` instead of `/my/invoices/<id>`.
The root cause is because Stripe creates 2 transactions, the second
being created at:
https://github.com/odoo/odoo/blob/43295c2a3741fb98f9c5d1a506652442efed0a82/addons/payment_stripe/static/src/js/stripe.js#L108
This second transaction, which is used to record the payment, doesn't
contain the appropriate `success_url`.
The best fix would probably be to either:
- prevent the creation of the second transaction by refactoring
`stripe.js`
- pass the appropriate `success_url` to the `stripe_form` template
- reuse existing draft transactions instead of creating a new one
None of these solutions is really suitable for stable since it might
require some heavy modification. However, a simple workaround is to
change the fallback `success_url`since we have all the necessary information
to build it.
opw-1997283
closesodoo/odoo#33404
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Thibault Francois