Previous versions of this action had a domain. It was removed at 2d3e6d7383
Set explicitly an empty domain to force the removal when upgrading the module
Similar to 2d03ed43a5closesodoo/odoo#34581
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose
=======
While cleaning the stat buttons across all modules, we
decided to move the (un)archiving from stat button to
actions in the 'Action' dropdown.
Specification
=============
Remove the 'active' stat buttons in all views
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 the `purchase.order` is added as an embedded tree view on a model
without a `state` field, a crash occurs.
The existing condition doesn't make sense on a PO (while it would make
sense on a PO line), so we simply remove it. Since the condition implied
that the field `invoice_status` was always hidden, we keep it that way.
opw-2005768
closesodoo/odoo#33827
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit removes some groups that are now useless since their
only purpose was to allow the user to hide or show some fields
depending on its value, but those fields are optional now.
Task-1902765
closesodoo/odoo#31944
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Modify purchase report in order to make it consistent with
sales report.
For the RFQ it will show the Order Date and for the Purchase order
menu it will display the Confirmation Date.
Also rewrite a bit the SQL view in order to compute every purchase
order in the company currency.
Technicaly rewrite the SQL alias in order to have a report more
readable in the future.
Task ID : 1857130.
closesodoo/odoo#28248
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.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
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>
Enforce the domain of the UOM not by an onchange but by a domain.
Exemple of issue if the domain is enforce by an onchange:
- create a picking
- add a move
- select the product
- select an uom
> the uom presented are the one from the product category.
-Save
- edit
- select an uom
> all UOM are presented even the ones of other categories
This commit enforce this new logic at most places.
task: 1886272
closesodoo/odoo#33083
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The activity view has been added on multiple models (invoice, fleet
contract, vehicles, leads, employee, contract, expense, expense sheet,
leave, leave allocation, applicant, partner, product, task, purchase
order, sale order) to ease the creation and the management of
related actvities.
Task 1894990
Purpose :
========
Maintain the uniformity between the sales and purchase menus
closesodoo/odoo#31482
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Before this commit, when the PO was locked:
- the button create bill did not appear on the form view
- on the invoice form view, the field autocomplete did not mention the PO
After this commit, the button create bill is present, and the PO appears in
the auto-complete field of the Vendor bill
OPW 1970537
closesodoo/odoo#32794
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Purpose
=======
If the activities are available on a model (i.e. inherits mail.activity.mixin),
add a progress bar based on the activities if nothing is defined yet.
closesodoo/odoo#24777
This commit change widget to many2one_barcode in these views:
- sale_order
- purchase
- invoice
- expense
In the fields register 'many2one_barcode' is mapped to many2one as fallback.
many2one_barcode is implemented in odoo enterprise
Task ID: 1924766
closesodoo/odoo#31018
The labels Request for Quotation and Purchase Order were not displayed.
opw:1958631
closesodoo/odoo#32281
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
On the PO form view, change the order_lines inline view:
- the tree becomes not editable
- allowed modes are tree,form
Add a new order line, the form view of order_lines opens up
Modify some stuff, then save and new
Before this commit, it crashed because some fields were expected in the tree view
that were not defaulted in the form view by the JS framework.
After this commit, this flow doesn't crash because we make sure every field
in the tree view is present in the form view
OPW 1917111
closesodoo/odoo#30219
If a user is at the same time purchase user and billing manager
he can't create a new payment terms from the PO and he has to
navigates throws multiple menus instead of just using the create
and edit function.
taskId 1868555
Closes#28280
This commit synchronises the editable tree view and the form readonly view of
the following objects:
- account.invoice.line
- purchase.order.line
- sale.order.line
- repair.line
Task-1912608
Closes : #29566
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This will fix UI glitch for fields added in form view side by side
to get fields on same line and also to get space between
two fields use o_row oe_inline is used to put two elements
on same line but it is used mostly where 1 element is field
and second one is static string maybe in span, oe_inline on
two field creates glitch in UI, to have two fields or divs on
same line we should use o_row class, o_row class meant to do that
task-31003
In described Modules, there are some fields label like Unit of measure, Discount,
Ordered Quantity, etc... in views(list,form), report and portal, that are messy
and barely readable when lots of features are installed.
Purpose of the task is to shorter that all fields label to make clean view in
order to make it more readable without getting labels uselessly spread out on
several lines
Related to task #1933746Closes#31962
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When a user accesses a PO through the portal thanks to an access token
(without being connected), the product image on each order line is
rendered using the image placeholder with a size of 48x48.
This raises a 403 Forbidden at image retrieval since the access token is
not passed as a parameter. This commit corrects that behavior by sending
the resized image along with the rendering of the template instead of an
url.
Another solution could be to generalize the access token check to any
model in:
https://github.com/odoo/odoo/blob/12.0/odoo/addons/base/models/ir_http.py#L303-L311
But this seems overkill regarding this specific error.
opw-1902741
closesodoo/odoo#28479
The received quantity on Purchase Order line can be compared
to the delivered qty on Sales Order line. It is now time for
both to share the same mecanism (introduced in
3bf8a62e0d).
This commit sets `qty_received` as a computed field, depending
of a method (`qty_received_method` field) to compute it. The
value can be computed based on
- manual value; for services (all the time), and consummable
products (when stock is not installed).
- stock moves; for stockable and consummable products (when
stock is installed)
This is now easier to extend the way the received quantity
need to be computed (like in sale).
Task #1850689closesodoo/odoo#27663
Martin Trigaux