This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Task 2034073
The reconciliation widget is now entirely part of the enterprise version
as it is an advanced accounting feature
closesodoo/odoo#38424
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This commit introduces back the value by location feature dropped in v11.
The feature was dropped because we implement financial fifo, thus the
value by location does not make sense for this cost method.
This commit introduces an estimation of the value by location in fifo.
Task: 1880379
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 new code was sitting next to the old one, now that everything is
adapted (minus the cost method changes), we can remove the old one.
We also adapt the valuation wizard to use the stock valuation layer
action, now that the others are removed.
task-1875873
This commit brings the model, views and compute method for the value and
the quantity valued. An ir rule prevents to read the value of another
company. Stat button are added on done picking to access the generated
layers.
Further commits will adapt one by one the cost method to actually use
the stock valuation layer when
As the goal is to move the valuation fields away from the stock move, we
set the necessary fields on the layer. Note the absence of `remaining_value`.
task-1875873
Commit 98ee15977a made the Stock Interim accounts reconciliable,
and introduced auto-reconciliation of related entries. This has the
advantage to clean-up entries in these accounts. However, since these
accounts are reconciliable, the entries will show up in the manual
reconciliation widget (expected) and the bank reconciliation widget (not
expected).
There are 2 cases where it causes issues:
- after migration from v11, the entries were not reconciliced. Although
this will be fixed in the near future, it is too late for already
migrated databases
- using MRP. A list of components i costing Xi might be used to create a
finished product of cost Y != sum(Xi). Indeed, the routing cost has to
be taken into account. In this case, the entries are not fully
reconcilied.
The result is that the bank reconciliation widget ends up with an
growing number of unreconcilied lines, and in the end making it
impossible to use.
In order to work around the issue, we prevent any account used as a
stock interim account to be included in the bank reconciliation widget.
For performance reasons, we directly search the `ir.property` table for
the corresponding accounts instead of filtering AML thanks to
`excluded_ids`.
Closes#32611
opw-1963025
opw-1967462
closesodoo/odoo#32957
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The approach we tried with the current implementation lead to a replay
of all the next moves since a move had to be corrected, and posting an
account entry with the valuation difference.
This proved to be slow and complicated, and moreover the resulting
account entry could be very difficult to understand and justify.
So we moved away from this strategy and implemented the following points:
For FIFO
* If a move goes into negative (sent more than availabale, we do not
counterpart directly at the next in move: we valued it at the last
fifo price and only when running `_fifo_vacuum` (which is called at
every openning of the valuation report), we use some units currently
in stock and post an account entry with the difference between the
fake value and the real one used.
* When editing a done move and increasing its quantity, the new quantity
is available now and will be used at the next move out. We do not try
to replay the history to make the new values go away directly.
* When editing a done move and decreasing its quantity, it acts as a
return to the supplier at the price unit of the move.
On average price:
* Don't replay anything, if we fall under the negative stock usecase,
value at the last average price.
We restore the previous code that set the average price on the standard
price and we slightly patch it to continue to update the average price
if quantity in stock is negative.
We also add a link between stock moves and account moves. A stat button
on the stock move's form redirect directly to them. It's therefore a
little easier to understand what happened.
We remove the separate fifo and average price fields that were added in
saas17, we keep the single standard price (that should be renamed
cost_price for consistency). In the same idea, remove the cumulated
value that was stored on the move. If we need it, just recompute it
(it's not a frequent operation). We remove last_done_move_id,
last_done_remaining_qty and last_done_qty that were added in saas17 to
help in the replay method, as we just got rid of it. We also remove the
code that compensate the negative stock directy at the next in.
What the fifo vacuum does is essentially the same thing as what an out
move do: find a candidate and take units from it. In this case, the
candidates are newer than its concerned stock move. We stored on the
concerned stock move the value at which we sent it (remaining_value) and
post the difference with the real value on a real product.
Arnold Moyaux