Task 2075249
The commit dd627b9 added a default_get to retrieve the default analytic
values. However, it was depending on self, which cannot be done in a
api.model
In this commit, we use an editable compute in order to update the
analytic values in all the cases, and to reduce the duplication of the
code.
X-original-commit: 69bf61bbc991eee96e673316ae8c37e98e1b8a1d
PURPOSE:
Default analytic account should be used wherever possible. This wasn't
the case because the module didn't implement a default_get and only
filled the fields on product_id change, which isn't set by the OCR
task-2067097
opw-2068110
closesodoo/odoo#37389
X-original-commit: 2c450015154f8ba2384fb1f0ad1d4075785009c0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When adding an analytic tag on a sale order line, if there is
a default analytic tag defined matching the criteria, the tag
on the SO line is overwritten in the invoice while it should be
kept.
opw-2068196
closesodoo/odoo#36685closesodoo/odoo#36727
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
It was not possible to manually set a default analytic account as it was
overriden by the onchange, even if no account was returned by account_get
Apply the same logic as in _prepare_invoice_line on sale.order.line
closesodoo/odoo#30282
Signed-off-by: Martin Trigaux (mat) <mat@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
- Create an Analytic Distribution for:
Product A
Current user (e.g. Mitchell Admin)
- Sell the product in the POS, request an invoice
The analytic account defined is not used.
This is due to the invoice created as SUPERUSER.
We should first take into account the user on the invoice, then the
current user.
opw-2003935
closesodoo/odoo#33758
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Move the SO part in a new module
Add the functionality to PO
Task 1945220
closesodoo/odoo#33282
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Steps to reproduce the bug:
- Set your user in multi company
- Set a default analytic account A for product P with your company
- Create a PO with P and deliver it
- Generate the invoice.
Bug:
The analytic account A was not set on the line.
opw:1831998
[IMP] purchase_requisition : add analytic_tag_ids field in purchase requistion
[IMP] sale: set analytic tags on invoice based on the analytic tags defined on SO
[IMP] account_analytic_default: add default analytic tags to invoice lines created from SO for down payment
(#23110)
The suggested analytic account must search based on the commercial_partner_id instead of
the partner_id field.
E.g. create an invoice with 'Agrolait, Thomas Passot', the analytic account 'Agrolait' wasn't set by default.
-github issue 21401
* analytic accounts can be shared among companies
* amount on analytic lines always refer to amount in company currency of which it belongs to
* add analytic groups (hierarchical way to classify analytic accounts)
* analytic tags:
- only present on analytic lines, not anymore on analytic accounts
- can be used to distribue/split an analytic lines among several analytic accounts
- enabled by a dedicated res.group
- added on several objects (vouchers, expenses, analytic defaults...) as well as in bank statement reconciliation widget (manual counterpart and account.reconcile.model)
* bunch of fixes made related to analytic
Was PR #22124. Was task 32386. Original work by tbe.
When migrating stock, some dummies methods have been removed. Indeed those
calls make more problems than they solve by adding unnecessary complexity
around simple methods. However it seems some calls have been left in the
process :
- _get_act_window_dict which is basically an env.ref or act_window.for_xml_id
- _get_products which is basically having all product_ids from template by
iterating on product_variant_ids.
Currently there is a selection field 'account_type' on the
account.analytic.account model with 2 values : Active or Archived
Let's use an active field instead and add a Archive stat button on the
form. That way, we can remove all the domain ('account_type','=','normal')
which are implicit with the generic active field behavior
wan