Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ADD] account,*: Merge account.invoice & account.move #33797

Closed
wants to merge 2 commits into from

Conversation

@smetl
Copy link
Contributor

commented May 31, 2019

[ADD] account,*: Merge account.invoice & account.move

Before this commit, an invoice had no journal entries until it was post. As there is no
synchronization between an invoice and its journal entries, it becomes very difficult for
fiduciary companies to deal with Odoo. Furthermore, it implies there is no possible reporting
based on draft invoice journal entries.

==== models ====

  • account.invoice has been merged with account.move. So, when creating an invoice, you are
    creating a journal entry as well. account.invoice no longer exists.
  • account.invoice.line & account.invoice.tax: Both models has been removed. A journal item
    (account.move.line) is created instead in both cases.
  • account.invoice.confirm: This wizard has been removed has the 'post' action already works
    in multi.
  • account.invoice.refund: This wizard has been removed and its functionalities are handled
    by account.move.reversal used to reverse the entries.

--task: 1917430

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

@smetl smetl requested a review from oco-odoo May 31, 2019

@robodoo robodoo added the seen 🙂 label May 31, 2019

@smetl smetl force-pushed the odoo-dev:master-acc-pocalypse-las branch to dfb569a May 31, 2019

@fmdl

This comment has been minimized.

Copy link
Contributor

commented May 31, 2019

Dear @smetl I think idea is a good idea, can you check this :

  • access right : a purchase user have access to account.move, he have access (by UI or RPC) to all account.move (and account.move.line) (include : capital value, revenue, employee pay, ...) or only account.move linked to a purchase.order
  • acces right to post (a purchase user can only post invoice purchase)

cc @sla-subteno-it @alexis-via

@nhomar

This comment has been minimized.

Copy link
Collaborator

commented May 31, 2019

this PoC will generate an Invoicegedom!!!!!!

Did you at least check the border cases where an invoice IS NOT a move and viceversa?

@nhomar

This comment has been minimized.

Copy link
Collaborator

commented May 31, 2019

cc @qdp-odoo @antonylesuisse

For example:

account.invoice.refund: This wizard has been removed and its functionalities are handled
by account.move.reversal used to reverse the entries.

There are at least 5 use cases where a refund IS NOT a reversal of an invoice.

  1. Early payment.
  2. Partial returns.
  3. Cancelled Invoices (In some cases there is not account move reversed).

Viceversa [Income is a move but not an invoice, tax and lines are different]

  1. Daily PoS sessions (1 move several invoices/tickets).
  2. Picking in/out. [Interim move that in some counties generate the receivable/payable provisioned 'till the invoice is actually done]

Since the begining of times, conceptually speaking invoices are an extension of moves (but a different model) why? in order to achieve such border cases that must be supported.

  1. Border cases where sync is not possible between lines and move lines:

a. Same product - Different prices/accounts/deals (then they should be summed).
b. Generic expenses vs moves [An expense that should affect different moves, now we can sepparate them by simply manually split the account.move]

I mean... I love the fact of use a model alike, BUT I think invoice should be an inherit(s) of account move [A la product/product/template] not the same model.

If this is merged as it is conceptually v13.0 will become a huge mess :-(

Regards.

@nhomar

This comment has been minimized.

Copy link
Collaborator

commented May 31, 2019

Other point:

Security:

We need to have a set of hard/solid test environments, open account.move to a portal environment will give problems in both directions.

  1. Things customer MUST NOT READ EVEN BY MISTAKE will be open.
  2. Things customer MUST READ will be broken by default.
@mohamedhagag

This comment has been minimized.

Copy link
Contributor

commented May 31, 2019

Invoices are accounting documents that may or not generate accounting entries.

The current implementation of invoices is the most accurate and flexible one.

Please don't merge this as it is not flexible for accountants and financial stuff.

Draft invoices should not generate accounting entries, same for proforma invoices.

Sales/purchase orders can not represent draft invoices from accounting pov .

@rvalyi

This comment has been minimized.

Copy link
Contributor

commented Jun 1, 2019

Many of the critics above are valid but also as some said on Twitter, you should also consider grouping: today a detailed invoice may have invoice lines grouped together into a single account.move.line according to some overridable criteria (like partner, account_id, date...). How would that work if account.move.lines represent invoice.lines? This feature is important, POS orders for instance do not generate an account.move.line per item sold, but there are many other use cases. Another for instance is selling n items each with a different serial number that you will display on different invoice lines (for warranty for instance) while they will be grouped in the account move line...

@fclementic2c

This comment has been minimized.

Copy link
Contributor

commented Jun 1, 2019

If you go in that direction (I know you will)
you must create a canceled entry status so users can print/view journal entries without all cancelletion noise.
In France, the FEC entries export must excludes reversed entries for correction purposes but not provision reversal.

@anajuaristi

This comment has been minimized.

Copy link
Contributor

commented Jun 1, 2019

What about journals and secuences? In spain we need different secuence by journal on invoices but a single secuence (usually by year) in account move. We should have to review how it works for spanish localization

@anajuaristi

This comment has been minimized.

Copy link
Contributor

commented Jun 1, 2019

Another concern...
If accounting will be full enterprise on v13... even invoicing will be erased from community version? Could someone in odoo, please, explain how it will be done?

@jon-willdooit

This comment has been minimized.

Copy link

commented Jun 1, 2019

Another problem is with historic invoices imported from an old accounting system. With the current model it is easy to stop these affecting the account.move* models and allows customers to have historic invoices for analysis etc. Not in favour of this one.

@nhomar

This comment has been minimized.

Copy link
Collaborator

commented Jun 2, 2019

@anajuaristi

This is a really delicate (technical) topic.

About:

If accounting will be full enterprise on v13... even invoicing will be erased from community version? Could someone in odoo, please, explain how it will be done?

Technically this is being done on Community, and few invoicing localization are done in Community, AFAICS this will remain on community, let's stop such topic here and discuss in a different thread.

For me it can be in a lunar repository... I am absolutely worried is about the technical / functional /legal aspects.

@nhomar

This comment has been minimized.

Copy link
Collaborator

commented Jun 2, 2019

If accounting will be full enterprise on v13... even invoicing will be erased from community version? Could someone in odoo, please, explain how it will be done?

Good catch there.

@nhomar

This comment has been minimized.

Copy link
Collaborator

commented Jun 2, 2019

Use case:

Payment terms:

Now:

  1. 1 element (the payment term) generate 3 account move lines with the proper due date.

With this?

Will we loss the payment term functionality?

@wtaferner

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

Uff, I kinda understand the idea behind it, but I am not sure about the simple execution as there are quite a lot of concerns as others already stated. I think it would have been better to just create the account.move already in draft state and keep the separation of models.

I really want to see a clear rationale and a long list of PROS to push such a change. Of course, in terms of less code and business logic it makes somehow sense, but it was not anymore needed after repartition lines for taxes are finally introduced and the risk of such a refactoring is super high. Don't do it for v13...I think 4 months of publicly working on it is too little to do such a move. Fine for me, if you see it as a mature feature for v14 and now take the right amount of time for such a move, but this needs soo much more than just making v13 to a BETA nightmare.

@wtaferner

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

It also feels a bit like, hey, all the accounting software is handling it like this for invoices, so we need to do it again like them which is wrong IMHO b/c so far I was seeing a big advantage in the invoice models abstraction and the solution for your missing draft moves is not so difficult. I really see too little advantages to do such a move even on the technical side.

@i-vyshnevska

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

in CIS countries invoices doesn't create account entries at all, from this moment customization will be much more harder for that region
generally invoice and entry are not the same, historically entry appeared earlier, and invoice is extension of it

@fmdl

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

I think to have one model account.move (for move and invoice) is a good idea, but I think we need to have a distinction between invoice line and move line.

It is quite the same behavior between stock.move, stock.move.line and stock.picking.

class AccountMove()
    _name = 'account.move'

    line_ids = fields.One2many('account.move.line', 'move_id')
    invoice_line_ids = fields.One2many('account.invoice.line', 'move_id')

Question : how are you going to manage migration, because the migration cannot change the existing accounting entries ?

Please don't merge in V13, in V11 we have wait 8 months the migration script for the new stock module.

@fpodoo

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

in CIS countries invoices doesn't create account entries at all

@i-vyshnevska
Can you provide more information about your use case? Which country? Are you talking about pro-forma invoices or real invoices?

To all, here are the two reasons for this change:

  • we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature, and the reason alone for this change. (Of course, we respect legal rules, e.g. if an invoice is validated, you can not change what's visible on the invoice like the price, but you can still update account, date_due, or tax grids). Being able to modify easily picking & moves has been a game changer for Odoo Inventory. We expect the same for accounting. And it's nearly impossible to implement with the current data model: too much redundancy difficult to sync both ways.
  • it was the opportunity for a big cleanup of the code: thousands of lines of code removed, for more features. (which is usually the sign than the tech architecture is better) We expect significant performance improvements too.

The branch also brings several UX improvements; accountants will appreciate the difference. Some examples:

  • accountants used to work in journal items, not in invoices: they'll like to see the actual journal entry (with debit, credit, tax grids) and fix it before validating the invoice.
  • when your are in the GL, if you click on an entry, you always have the right view (invoice or journal entry)
  • in the future, accountants will not record invoices manually, but instead only validate them (the OCR creates everything automatically, they only need to validate the entry). For this purpose, it's key to have a clear journal view with all invoices to validate, and their journal entries.
  • accountants will be able to work in views similar to the legal statements they are used to work with, and update entries from there: general ledger (journal items list view, grouped by account_id), journal (journal items group by move_id), partner ledger (journal items grouped by partner_id).

It's difficult to explain the big picture, without going into the details of all related tasks, as this branch is just a piece of a bigger puzzle.

We will provide more info once all related branches / tasks are ready to be demonstrated. (And there are a lot of tasks in accounting for v13; a huge step forward)

@jon-willdooit

This comment has been minimized.

Copy link

commented Jun 3, 2019

@fpodoo Q1: How to import historic invoices without affecting GL balances (this is easy now)? Q2: a journal generally has more lines on it than the invoice (e.g. tax), or can be split over several journals for complex payment terms - how will this be handled?

@fpodoo

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

@jon-willdooit
A1: you just import draft moves of type invoices. (Or you import confirmed moves, and do your opening balance after, which allow reconciliation for future payments.)
A2: the move has two fields: line_ids, invoice_line_ids: the second is just a domain over the first one, allowing you to just see "invoice lines".

@anajuaristi

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

Thank you @fpodoo for your explanation. We will wait about more info as you said but meantime... after thinking a little bit about the question this is my2cent resume:

  1. Mandatory for spain: To have a secuence by journal on invoice view + a single secuence by year on account move view. We also need invoice data and account move data to be different so we would need 2 date fields on account move.
  2. Improvement idea: To split payment due dates from one move line to several due dates ( today, duplicating the move line is causing several usability troubles and difficulties and too much steps to mantain due date changes: set move to draft, change date, revalidate account move... and so on) If the model is one line several due dates... maintenance on dates and amounts to pay would be made on correct model in a very simply way but... reconcile process would be heavily impacted I think.
  3. Mandatory: to mantain invoicing functionality on community version
  4. Question: It will be very hard to adapt all the reports based today on account.invoice depending on how many of them we have got. I think most of spanish localization reports are obtained from account move but we will have to check.
  5. Opinion: I like the change. But I also agree that V13 is maybe to early to have it ready, fully working... but who knows.
    As said: my2cents🤗
    Thank you:
    Ana
@sswapnesh

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

Mandatory: to maintain invoicing functionality on community version

@fpodoo Can you please confirm this one ?

(More people are eager to know this apart from all other technical/functional discussion)

Thanks

@anajuaristi

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

@fpodoo I don't understand this one -->
A2: the move has two fields: line_ids, invoice_line_ids: the second is just a domain over the first one, allowing you to just see "invoice lines".

So... are you duplicating the lines on move? Having invoice lines and move lines on the same move? What for? I thougth the invoice line info and the move line info was also in a single line otherwise the integrity question between them is not solved. Am I missing something?
How do you link both kind of lines?
Thank you...

@sswapnesh

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

@anajuaristi

A2: the move has two fields: line_ids, invoice_line_ids: the second is just a domain over the first one, allowing you to just see "invoice lines".

Based on field exclude_from_invoice_tab
https://github.com/odoo/odoo/pull/33797/files#diff-dd671a54296b170ea1393dca1a5f7798R181

(ans also most Imp is type of Move https://github.com/odoo/odoo/pull/33797/files#diff-dd671a54296b170ea1393dca1a5f7798R181 _

@sswapnesh

This comment has been minimized.

Copy link
Contributor

commented Jun 3, 2019

Isn't is a good chance to make overridable default methods as well As we are refactoring/rewriting all these ?

Reference to: #33049 #29588 #29646

@robodoo robodoo removed the CI 🤖 label Jun 28, 2019

@qdp-odoo qdp-odoo force-pushed the odoo-dev:master-acc-pocalypse-las branch 2 times, most recently Jun 28, 2019

Laurent Smet and others added some commits May 29, 2019

[IMP/REF] accounting-pocalypse yeaaahh
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
[FIX] web: BasicModel: don't update default one2many records
Let's assume a one2many field in a form view with a default value
with commands 4 (link to). Before this rev., when saving the record,
the BasicModel generated a command 4 and a command 1 (update) for
each record, with the values of the record (directly coming from DB).
This can cause an issue when the related record can't be edited
(e.g. a posted journal entry in accounting).

@qdp-odoo qdp-odoo force-pushed the odoo-dev:master-acc-pocalypse-las branch to c0c70a8 Jun 28, 2019

@robodoo robodoo added the CI 🤖 label Jun 28, 2019

@qdp-odoo

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

@robodoo r+ rebase-ff p=0

robodoo pushed a commit that referenced this pull request Jun 28, 2019

[FIX] web: BasicModel: don't update default one2many records
Let's assume a one2many field in a form view with a default value
with commands 4 (link to). Before this rev., when saving the record,
the BasicModel generated a command 4 and a command 1 (update) for
each record, with the values of the record (directly coming from DB).
This can cause an issue when the related record can't be edited
(e.g. a posted journal entry in accounting).

closes #33797

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
@robodoo

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

Merge method set to rebase and fast-forward

@celm1990
Copy link
Contributor

left a comment

Please take into account suggestions before merge

@@ -11,7 +11,9 @@ class PortalAccount(CustomerPortal):

def _prepare_portal_layout_values(self):
values = super(PortalAccount, self)._prepare_portal_layout_values()
invoice_count = request.env['account.invoice'].search_count([])
invoice_count = request.env['account.move'].search_count([
('type', 'in', ('out_invoice', 'in_invoice', 'out_refund', 'in_refund', 'out_receipt', 'in_receipt')),

This comment has been minimized.

Copy link
@celm1990

celm1990 Jun 28, 2019

Contributor

For get domain can call to function??, see #22121

DIFF c3e3770


domain = []
domain = [('type', 'in', ('out_invoice', 'out_refund', 'in_invoice', 'in_refund', 'out_receipt', 'in_receipt'))]

This comment has been minimized.

Copy link
@celm1990

celm1990 Jun 28, 2019

Contributor

Same here, call to common function to get domain


inv = invoice._convert_to_write({name: invoice[name] for name in invoice._cache})
new_invoice = Invoice.with_context(local_context).sudo().create(inv)
move_vals = {

This comment has been minimized.

Copy link
@celm1990

celm1990 Jun 28, 2019

Contributor

Please keep function _prepare_invoice or rename to _prepare_account_move for purpose of inheritance on other modules

This comment has been minimized.

Copy link
@sswapnesh

sswapnesh Jul 10, 2019

Contributor

@celm1990 I would suggest you to add these comments on #34766 as its seems for the Fixes/Imp

This comment has been minimized.

Copy link
@william-andre

william-andre Jul 11, 2019

Contributor

@celm1990 what do you mean?

@robodoo robodoo added merged 🎉 and removed merging 👷 labels Jun 28, 2019

@robodoo

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

Merged, thanks!

@robodoo robodoo closed this Jun 28, 2019

odony referenced this pull request Jun 28, 2019

[IMP/REF] accounting-pocalypse yeaaahh
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
@nhomar

This comment has been minimized.

Copy link
Collaborator

commented Jun 28, 2019

@bealdav

This comment has been minimized.

Copy link
Contributor

commented Jun 29, 2019

In term of usability, it seems the result is very good.

Thanks a lot

@qdp-odoo qdp-odoo deleted the odoo-dev:master-acc-pocalypse-las branch Jul 2, 2019

@wtaferner

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

@qdp-odoo @fpodoo and all others involved
Thank you for moving forward that fast and explaining a lot in the final commit message and here. Unfortunately I was packed with work myself, so I had no time for any contributions or deeper checks in the end.

Anyway, I think it was the right thing to do finally, although I follow @nhomar in terms of praying 😝

Let's hope we will find all the nasty things asap which will make life hard during stable or downstream in general...

@qdp-odoo

This comment has been minimized.

Copy link
Contributor

commented Jul 11, 2019

thanks for your support @wtaferner !

FYI, we will migrate our own production instance on saas-12.4 asap, in order to tackle as many problems as possible. :-)

@moylop260

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2019

@qdp-odoo @smetl

product_id many2one is not possible to open it from account.invoice.line after confirm invoice.
Is it an expected behavour?

  • invoice product

I mean, after confirm the product you don't know what product was used, for MX configuration it could be a problem since that we are using a confirmed invoice to fix product data to fill correctly the XML (using retry button) so we won't know what product should we fix it.

cc @nhomar @luistorresm

@qdp-odoo

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2019

@moylop260 nope, it's a bug. Thanks for notifying

@okuryan

This comment has been minimized.

Copy link

commented Jul 16, 2019

Guys (@qdp-odoo, @smetl, @nhomar, @moylop260),

I missed this thread. But is it about merging invoice object and account move object? So no more invoice object?

If it is true, to me it sounds like bad idea. Reason:
invoice is for business people. Account moves, for accountants. That are different roles. And technically mixing everything in one object makes things more complex. In some countries (like France) there is law that you cannot change invoice after it is sent to customer. But accountants should have possibilty to correct account move records (if manager done invoice not properly (for example, put into incorrect account ). So now everything is mixed...

If Odoo strategy is to stop it's usage as accounting software, than step is ok. But if it's strategy to be an accounting software also, than this PR sounds to me weird.

Well, for one-man company it will also work for sure. But is it target of Odoo?

@Yenthe666

This comment has been minimized.

Copy link
Collaborator

commented Jul 16, 2019

@okuryan I think you should read the whole thread & try it functionally on the test instances too. It might look like an apocalypse but I bet you didn't even test it. ;)

@okuryan

This comment has been minimized.

Copy link

commented Jul 16, 2019

@Yenthe666, already installing. :) Will test myself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.