[14.0][ADD] Module sale_stock_picking_invoicing

[mbcosta]

Module sale_stock_picking_invoicing, based in https://github.com/OCA/l10n-brazil/tree/12.0/l10n_br_sale_stock , depends #1014.

This module extends Stock Picking Invoicing implementation to Sale, you can define the Sale Creation Invoice Policy, if the invoice should create from Sale Order or Stock Picking, in this case, the information used at invoice come from Sale Order e.g.: Price Unit, Payment Terms, and others fields. Similar feature exist in v8 core.

Implementation questions when "Sale Creation Invoice Policy" is "Stock Picking" :

• When Products of Sale Order has lines where "Product Type" is "Storable Product" the button "Create Invoice" in Sale Order become invisible even when Product "Invoice Policy" defined as "Ordered quantities", is this right? Or it should be possible create invoice from Sale Order in this case? My undestand for now is as "Sale Creation Invoice Policy" is general rule should be has priority over the "Invoice Policy" defined in each Product.

• There are two similar buttons to create invoice from Sale Order, one just appear in status Sale the other appear in all status but will be open with Down Payments option selected. Should be keep the second button to allow Down Paymens?

• In the case of Sale Order has lines with Product Type "Storable Product" and "Service" will be create two separated Invoices, one created from Sale Order an other from Stock Picking, should be try to join and create only one? Or it should be a Parameter in the system?

As said this module is based in l10n_br_sale_stock, by this reason I like to ask if the License Header and the CONTRIBUTORS.MD should be keeped as the same based files?

It is possible reference mutiple sale lines in only one invoice line https://github.com/odoo/odoo/blob/14.0/addons/sale/models/account_move.py#L34, but there is a error when Posted Invoice:
Issue odoo/odoo#77028
PR with FIX odoo/odoo#77195
By this reason today the module not allow grouping stock moves when has sale_line_id, the PR above solve the problem, waiting merge to make useful here.

cc @renatonlima @rvalyi @mileo @gabrielcardoso21 @marcelsavegnago

[mbcosta]

Thanks @kittiu by your review, I'm close this PR because in my view it's important confirm with the mainteners of the repo if there are interest in include this functionality here and I think we lost the "window" to made this extraction from Brazilian Localization and will be better check this case in the future v16.

[mbcosta]

Reopen because as talked in #1672 the question about if this implementation would has interest outside Brazilian Localization project was answered, and to keep the isolation and modularization of stock_picking_invoicing will be better another module to integrate the functionality of create Invoice from Picking when it's linked to a Sale Order, some points about the implementation:

• Module is based in l10n_br_sale_stock version 14.0 https://github.com/OCA/l10n-brazil/tree/14.0/l10n_br_sale_stock the original License Header, Maintainers and Contributors was kept and also include the license in XML files ( in the beginning of the PR was based in v12.0 )

• It's possible to link one Invoice Line with mutiple Sale Lines, the main problem( the error described above in method action_post ) was solved https://github.com/OCA/OCB/blob/14.0/addons/sale/models/account_move.py#L15 but there is other problem the field qty_invoiced in sale.order.line show the quantity of invoice line without consider, in this case, that the value is the sum of others sale lines https://github.com/odoo/odoo/blob/14.0/addons/sale/models/sale.py#L1230, what can make confuse the user about the real Invoiced Quantity:

So for keep compatible with the Brazilian Localization I think will be better check this possibility to Grouping Sale Lines in the future in another PR or in versions v16, v17 or the newest.

• Test to check qty_invoiced commented https://github.com/akretion/account-invoicing/blob/14.0-NEW-sale_stock_picking_invoicing/sale_stock_picking_invoicing/tests/test_sale_stock.py#L274 to avoid error with the module sale_line_refund_to_invoice_qty https://github.com/OCA/account-invoicing/blob/14.0/sale_line_refund_to_invoice_qty/models/sale.py#L20 when run the tests as CI and both modules are install, so in the case of use the both modules should be consider this problem.

• This module should has integration with account_payment_mode https://github.com/OCA/bank-payment/tree/14.0/account_payment_mode as done in Brazilian Localization? To avoid a "glue" module.

The review and tests of people outside Brazilian Localization are important to know if there are any change that can make the module more compatible with another cases of use.

cc @renatonlima @rvalyi @mileo @gabrielcardoso21 @marcelsavegnago @kittiu @Christian-RB

[mbcosta]

About important changes made in the last two commits:

• Get fields from Sale methods to prepare invoice and invoice lines to avoid the necessity of 'glue' modules and make the Invoice created by Picking equals to created by Sale.

Other modules can included new fields in Sale Order and include this fields in the dict of creation Invoice from sale, for example:

account_payment_sale https://github.com/OCA/bank-payment/blob/14.0/account_payment_sale/models/sale_order.py#L41
sale_commission https://github.com/OCA/commission/blob/14.0/sale_commission/models/sale_order.py#L64

Example with demo data, account_payment_sale and sale_commission modules installed:

• Make module compatible with 'Down Payments' case.
  Initially to force the creation of Invoice from Stock Picking when the "Sale Create Invoice Policy" was as stock_picking, the implementation turned the button 'Create Invoice' in Sale Order view invisible, but this block the case of "Down Payments", now in this case the _get_invoiceable_lines method just return the Products with Type Service and if there is no Service raise user error. Example with demo data:

Case where "Sale Create Invoice Policy" defined as stock_picking

Create made in Stock Picking

In order to avoid errors with the tests made by CI when the enviroment are Demo the default "Sale Create Invoice Policy" defined as "Sale Order", so for test this case you need to change in Company view or Sale Settings for "Stock Picking"

The commits are separated to let brazilian community check this changes in a easy way, but if necessary I can merge all commits and let only one.

[rvalyi]

thank you for the hard work @mbcosta I promiss I'll look at that soon. If I forget please ping me again. We have to take the opportunity to modularize stock_invoice_picking indeed...

[rvalyi]

@mbcosta I would say it's a bit late for us to focus on v14 unfortunately... I mean the module is quite large and we are not going to sell any v14 project anymore for instance nor migrate customer to v14 and I think people on v14 can work their way the way it is now in the Brazilian localization...
Would it be possible to try to make the equivalent PR on v16? I know this might be some work... But honestly it has more chance to enter in v16 than v14 that is already being phased out...

[rvalyi]

not the same list as in the manifest

[rvalyi]

are you sure sale_management is required? If yes could you please just explain why? (and eventually leave a short comment why here)

[mbcosta]

Necessary to access Sale Menu

By some reason the sale module create menuitem with attribute active="False" https://github.com/OCA/OCB/blob/14.0/addons/sale/views/sale_views.xml#L8 and sale_management change for active="True" https://github.com/OCA/OCB/blob/14.0/addons/sale_management/views/sale_management_views.xml#L4

[rvalyi]

I understand you re-opened this because #1672 is for 14.0 ...
Well that sucks... Cause as you explain, if we merge #1672 we would make it even harder to make things modular in the future so merging it is bad. I'll make my best to find time and see if we can get this one merged then.

[rvalyi]

I reviewed a part of the module (all except the wirzard) and I suggest a few English changes. As for the wizard I'll review later, but eventually that's cool if you could check if all the comments are still required or if some might be dropped.

Actually the module isn't that large, I'm confident we can get it merged in 14.0

cc @marcelsavegnago @antoniospneto @renatonlima

[rvalyi]

sale_invoicing_policy would be a much better name

[rvalyi]

change the variable name and drop the string

[rvalyi]

s/be create/be created/
s/or Stock Picking/or from StockPicking/

[rvalyi]

change to default_sale_invoicing_policy

[rvalyi]

change to sale_invoicing_policy

[rvalyi]

change to When 'Sale Invoicing Policy' is defined...

[mbcosta]

Thanks @rvalyi for review, I made the changes, about the wizards it's important to check if the Refund case should not get values from "_prepare_invoice" and "_prepare_invoice_lines" of Sale module as I did, and in the _create_invoice method https://github.com/akretion/account-invoicing/blob/14.0-NEW-sale_stock_picking_invoicing/sale_stock_picking_invoicing/wizards/stock_invoice_onshipping.py#L149 I use as reference the original Sale method https://github.com/OCA/OCB/blob/14.0/addons/sale/models/sale.py#L681 to get and include the Down Payments.

[rvalyi]

s/only can be/can only be/

[rvalyi]

s/from Stock Picking/from the Stock Picking/
s/change this in Company/in the Company/

[mileo]

Could you just continue and don't add the product?

How we gonna deal with this example?

[mbcosta]

Thanks @mileo for review, the UserError just appear when there are only Lines with Product Type 'product' if there are any Service line the Invoice will be create, it's a way to inform the user about the "Sale Invoicing Policy" ( similar to the message when Product must be Delivered to be able Create the Invoice ), in the case of Services the 'product' must be defined as Type 'service'

Demo data has a Sale Order of the case of Product and Service, for now in this case will be create two Invoices, one with the Service created from Sale Order and the other from Picking,

Service Invoice

Try to create Invoice from Sale Order, there lines but the policy chosen are Stock Picking

Create from Stock Picking

This is the expected behavior in brazilian localization, but I think this can be analise, debate and if necessary change, for example:

• If Policy are Stock Picking create only one Invoice from Picking( get Services Lines in the same way of 'Down Payments' )
• If there are Product and Service lines ignore the "Sale Invoicing Policy" and allow Create from Sale Order
• Other ideas

[mbcosta]

Force-Push to remove file sale_stock_picking_invoicing/models/stock_rule.py, because it should be in stock_picking_invocing as suggest in the above Review, by this reason the CI tests fail here so this PR now depends of PR #1782 ( already with two Approves )

[rvalyi]

@mbcosta #1782 was merged. I also re-launched the failed tests as the date pricelist issue in the CI seems fixed.

[mbcosta]

Thanks @rvalyi with rebase the PR back to be green, I took a time to check the PR again to be sure everything work as well with Extract PR of l10n_br_sale_stock

[rvalyi]

you can avoid this browse here if you compare partner_id with self.sale_id.partner_invoice_id.id directly 2 lines below in if partner != self.sale_id.partner_invoice_id:
(partner_invoice_id is required so no need to check it's not False/None)

[rvalyi]

in fact, you can simplify further to just:

        if self.sale_id:
            partner_id = self.sale_id.partner_invoice_id.id

if it's the same it will affect partner_id but it won't hurt performance and the code will be simpler

or eventually something like:

partner_id = self.sale_id.partner_invoice_id.id if self.sale_id else super()._get_partner_to_invoice()

[mbcosta]

Done, the error in the tests is the problem we saw yesterday the Tests of module account_invoice_pricelist fail at a specific Date Time

[rvalyi]

OK, the PR seems OK now. I will wait a few hours, trigger the tests again and approve once everything is green again. Thank you for the awesome work and sorry for the delay. Would be great if you could port it to 16.0 as well... (you can skip v15)

[mbcosta]

I didn't saw your comment and just make a force push, I have tried to find where is the problem but not success, the clue is the problem related with Date Time, after UTC midnight the tests back to work

[mbcosta]

@rvalyi I decide to make v15 migration #1826 just to avoid the possibility of a problem for the cases of someone by some reason still using v15, after merge I'll port to v16

[rvalyi]

Ok, perfect

[rvalyi]

OK for me.

[mbcosta]

Thanks @rvalyi for your review, no problems for delay, this was important to make a better implementation

[antoniospneto]

LGTM

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[rvalyi]

and finally...

/ocabot merge nobump

[OCA-git-bot]

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 14.0-ocabot-merge-pr-1025-by-rvalyi-bump-nobump, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 7aeee74. Thanks a lot for contributing to OCA. ❤️