Open the reconciliation widget, with a statement line that has
some move lines to reconcile with
Put your browser in Fast 3G to slow down stuff
then click multiple times on a move line to add it to
the reconciliation chain of the statement line
Before this commit, as many lines appeared in the reconciliation
chain as many clicks were made
After this commit, one can only click once on the lines
linked to #35194
OPW 2042751
closesodoo/odoo#35417
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Validate a bank statement from reconciliation widget and then open the statements view from the widget and try creating a new statement. An error happens when trying to select a partner because the default journal is not set in the action
closesodoo/odoo#35418
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Task 2038326
* Tick the credit note sequence by default on the customer invoices and vendor bills journals
* Write Customer Invoice/Vendor Bill/Credit Note/Customer refund at the top of the document
* The reference field should be printed on the credit note pdf (interesting because it gives source and reason)
* If the document is a credit note, there shouldn't be any payment information on the pdf (the customer doesn't have to pay you) (currently you see the "payment communication" the customer is supposed to use)
* Rename Credit Note to Refund on dashboard
* Add tooltip on payment widget
closesodoo/odoo#35231
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
-- Create a new bank statement;
-- Add a transaction;
-- Reconcile;
-- Create a write-off with tax.
Before this commit, the tax journal item's label only contains the name
of the tax.
Now, the tax journal item's label contains the write-off label and the
tax's name. This is the same behaviour as it was in version 11
(https://github.com/odoo/odoo/blob/11.0/addons/account/models/account_move.py#L1259).
opw-2025480
closesodoo/odoo#35348
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
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
Activate analytic tags
Create an reconciliation model on which you set at least one tag
Create a bank statement and a line
Click on reconcile (or access the reconciliation widget by another means)
Quick Create a writeoff line
Click on the button corresponding to the reconciliation model
Before this commit:
The many2many tags was buggy, there was one empty tag, corresponding to nothing
clicking on the field triggered errors
validating the reconciliation by clicking on reconcile triggered a server traceback
in the real backend, opening the tag form view triggered an access error
This was because the data were not formatted the right way to be passed to the m2m_tag_field through
notifyChanges
After this commit, the reconciliation model's tag renders and behaves well
Validating the reconciliation works
OPW 2033350
As a side note, in the future, the reconciliation widget Model should fully implement basicModel
or not at all. Some of the heavy plumbing that the ReconciliationModel does (fetch records, data...)
is imitating what fetchRecord does
closesodoo/odoo#34838
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The goal of the to_check checkbox in the reconciliation widget is to set the to_check field present on the move that will be created. However since the UI is not perfect, the to_check checkbox was added on the wizard when we create a new line in the widget, which cause the following problem: what if we select to_check on line1 and then deselect it on line2, previously it was not possible to do this, a warning was thrown to tell the user that he had some line with to_check set and some other not. A better way to do this, and more user friendly is by preventing the user from deselecting the checkbox if some other line has the to_check value set.
closesodoo/odoo#33956
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
The function get_all_data_for_manual_reconciliation got an empty list instead of None. This leads to not query the db. However we want to get results in the default behavior for get_all_data_for_manual_reconciliation
closesodoo/odoo#33711
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
As we now have a new debug mode 'tests' which load a new asset bundle
containing tour-test files, we moved those files to a new folder hierarchy.
That will clean the .js files trees.
Also, those files should be included in the new asset.
Basically, the .js tour files (not test) should be inside /static/src/js/tours
while .js tour test files (test=true) should be inside /static/tests/tours next
to QUnit tests, inside a tours folder.
+ test_new_api: don't run the test in debug assets
task-1934445
Comes with https://github.com/odoo/enterprise/pull/4281Closes#33213
Since the JS is lazy loaded, the iframes in the page are already loaded
once the javascript is executed. So, waiting for the "load" event at
that moment is useless as it will never happen as it already did.
Part of https://github.com/odoo/odoo/pull/32181
task-1961045
This commit adds a new parameter on fields for list view and one2many.
The parameter name is "optional" and its values are "hide" or "show".
Columns of the list view which have the optional parameter set are
listed in a dropdown that can be toggled from the last cell of the
table header. The ones with optional set to "hide" are hidden by
default.
User choice is stored in local storage. If no saved parameter can be
found in local storage then the default value from the view is used.
Due to the overflow behavior of the responsive table, we were forced
to wrap the table-responsive div in yet another div. We changed the
o_list_view class on the table to o_list_table in order to reuse
the more generic o_list_view class on the top-most div. CSS rules
and selectors had to be updated according to this change.
Task-1902765
In the reconciliation widget, we added a to_check functionality. However in some cases, the propositions don't have a default value for
to_check, which result in a warning being thrown when doing a comparison to ensure that all lines have the same to_check value.
This commit add a default value to to_check for all propositions (when loading the data and when performing a quick create).
closesodoo/odoo#33824
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
- Create 11 invoices with the same partner but different totals like:
1.0, 2.0, 3.0 ... 11.0
- Confirm them
- Create a bank statement with 11 lines having each of them the previous
invoice amount (1.0, 2.0, 3.0 .... 11.0) and the partner
- Click on the 'Reconcile' button
- In the reconcile form, do NOT push the 'Load More' button, but push
the 'Automatic Reconciliation' button
All lines are reconciled, but a JS traceback is raised.
This is because we try to destroy a widgets which were not rendered.
opw-1985580
closesodoo/odoo#33524
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose
=======
Fields `customer` and `supplier` on `res.partner`
are mostly used in domains of many2x fields.
Those domains can confuse end users because they don't
see the partner they are looking for; and it's not obvious why.
Some identified problems:
1. It can lead to duplicated partners: the user does not find
the partner, so he creates a new one.
2. The user imports supplier contacts in the Contacts app, so they
don't get the `supplier` flag. Then the user wants to make a purchase order,
and cannot find the new suppliers in the list
3. A user removes the customer flag on a prospect, because they don't think
it's a customer yet - except now they can't make a quote for that customer...
Specification
=============
Remove the two mentioned fields.
Since fields `customer` and `supplier` have been removed, all partners
are now shown in many2one dropdowns.
But in some cases, not all partners are relevant or some are more likely
to be relevant than others. e.g. when creating a PO, top suppliers have a
higher priority than other partners.
So, adapt the places where those fields were used with the new mechanism to
display the searched the partners, according to the number purchase/sales
orders they made.
TaskID: 2031147
Co-authored-by: Yannick Tivisse <yti@odoo.com>
The onboarding modal for setting up the few base fields of a company
has now been moved to a wizard
It is accessible from the general settings, but also in the onboarding
section of sale and account modules.
The following company settings are editable with that wizard:
- Set report **layout**:
The user can chose the overall look of the report. The current choices
are : *Standard* (default), *Background*, *Boxed* and *Clean*.
- Set company **logo**:
Changes the company logo.
- Set report **colors**:
The user can set the primary and secondary colors of the report through
a newly added widget allowing to pick a custom color.
When changing the **logo**, colors are automatically set to its most dominant
colors.
> A "Reset colors" button also triggers the color calculation.
- Set report **font**:
Changes the overall font of the report. Only Google Fonts are used
for enhanced compatibility.
- Company **tagline**, also called "header"
- **Footer**
- **Paper format**
- Report **preview**:
A mockup of a final report
Automatically updates when changing **layout**, **logo**, **colors** or **font**
Co-authored by: Julien Mougenot <jum@odoo.com>
closesodoo/odoo#33863
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Since the wizard is not shown anymore (skipped to go right to file selection), we can remove it. Small refactoring had to be done for l10n_it in order to upload files with multiple invoices inside and to detect format
closesodoo/odoo#34145
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Task 2007561
We want to avoid this intermediate screen; Instead, directly open the selection files window...
Done from dashboard button + vendor bill list view & customer invoice list view.
No more modal because it's not visible and less handy. Use same behavior as
sales order portal.
Adapt the invoice style to properly adapt and align with the chatter block.
Part of task-37264
closesodoo/odoo#34360
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Pratima Gupta <pgu@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Explicitely return the extension of the listview to allow to modify it
in other modules
closesodoo/odoo#34672
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The method _renderCreate in the ManualLineRenderer was executed before
the call to super finished. Which makes impossible to create a writeoff
in the reconciliation widget.
closesodoo/odoo#33582
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Because functionnal specs changed after we merged the task...
Follow-up of task 1911260
closesodoo/odoo#32904
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Open the bank reconciliation widget
- Throttle the connection
- Click multiple times on the same move line in order to select it
The line is added multiple times to the statement line.
We mitigate the behavior thanks to a `debounce`.
Fixes#33000
opw-1978551
closesodoo/odoo#33020
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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
* = account, iap, point_of_sale
Removing the CrashManager templates from base.xml and moving
it to a new file (crash_manager.xml) to allow lazy loading the required
xml only when a crash occurs (necessary for the frontend as no xml is
pre-loaded).
All rpc errors/warnings are now displayed using the same modal system as
the backend (crash_manager.js).
CrashManager will now return the WarningDialog and ErrorDialog
in addition to the CrashManager itself.
In some cases an instance of CrashManager was created just to
display a warning/error dialog.
In the backend all rpc errors but sessionExpired will be logged.
If the exception is a warning, NotFound (403) or except_orm, it will be
a warning log. The rest will be exception log.
In the frontend all rpc errors will be logged using console.debug
instead of console.warn and console.error. This way we can trigger
rpc errors in tests without failing them. If a real error happend
during a test it will fall back on the backend logger to fail the test.
Part of https://github.com/odoo/odoo/pull/32132
task-1894820
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Florian Gilbert