With this commit, Selection fields with `required=True` which are extended via `selection_add` are given proper ondelete policies to ensure the cleanup of records containing these extended options during uninstall of the extending module. This commit also cleans up leftover uninstall hooks that were being used to handle the same set of problems prior to the ondelete mechanism being implemented for Selection fields. closes odoo/odoo#46325 Related: odoo/enterprise#9117 Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
closes odoo/odoo#36721 Signed-off-by: Christophe Simonis <chs@odoo.com>
closes odoo/odoo#36491 Signed-off-by: Christophe Simonis <chs@odoo.com>
- Create a new tax, using the 'Python Code' tax computation - In 'Applicable Code' field, use a field only available on the `product.product` model (e.g. `product.code`) - Attach this new tax to a product that is available in the eCommerce - Access the eCommerce, search for the product if not displayed. The template `website_sale.products_item` crashes at rendering because `code` is not available on a `product.template`. `product` is supposed to be a `product.product` recordset. However, the method `_get_combination_info` of `sale` is made in such a way that we can fetch the information of a template, not a product. Utlimately, methods `compute_all` and `_compute_amount` are called with the wrong object. We fall back on the first variant in this case. opw-2056722 closes odoo/odoo#36134 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
The goal is to be coherent with the user property. Actually, company_id and company_ids on the environment are no fields. Calling env.company_id returns a browse record, not an id.
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'`
- Add repartition lines on taxes - Link account tags directly to account.move.line; remove the tag_ids field from account.tag - Add a new report engine dedicated to tax reports, directly generating account tags. It is called as an alternate mode of generic tax report, with a dedicated "Use tax grids" toggle. >> The biggest change lies in the way the new tax report computes its values. Everything is now aggregated directly using the tags set on the account move lines. Thanks to that, modifying the configuration of a tax today will not impact the report for the previous periods anymore. This is a big improvement, as it means the report will keep on reflecting the values that were submitted to the state before, whatever the configuration change. - Add an audit char field to account.move.line telling with tax grids are impacted by the line, with the corresponding amount - Modify the behavior of cash basis taxes: the cash basis account is now used as the transition account, while the regular account given in tax declaration is used to store the final entry (it was the opposite before) - Modify every l10n_* module in order to keep them consistent with these changes closes odoo/odoo#32833 Signed-off-by: Quentin De Paoli (qdp) <qdp@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