Migration to version 9.0

[pedrobaeza]

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-9.0

Modules to migrate

• mail_quotation
• product_customer_code_sale
• sale_validity - By @lreficent - [9.0][MIG] sale_validity #447
• account_invoice_reorder_lines
• sale_order_force_number
• sale_journal_shop
• sale_order_add_variants
• sale_jit_on_services
• product_special_type_sale
• sale_order_back2draft - Removed as it's a native feature now
• sale_procurement_group_by_line
• sale_condition_text
• sale_sourced_by_line - By @SerpentCS - [ADD] migrated sale_sourced_by_line & sale_procurement_group_by_line to v9 #350
• sale_order_type - By @nicomacr - [MIG][9.0] sale_order_type #340
• sale_cancel_reason - v9 Migration of sale_cancel_reason #261
• product_special_type_invoice
• sale_partner_order_policy
• partner_prospect
• product_special_type
• sale_order_revision
• sale_exception_nostock
• sale_quotation_sourcing
• sale_multi_picking
• sale_start_end_dates - By @alexis-via - [9.0] Port sale_start_end_dates and sale_rental #353
• sale_quotation_number
• sale_dropshipping
• sale_owner_stock_sourcing
• partner_prepayment
• sale_exceptions > sale_exception - Assigned to @SodexisTeam - [MIG][9.0] sale_exception #279
• sale_delivery_term
• sale_product_set - By @Olivier-LAURENT - [MIG][9.0][sale_product_set] migrate to V9 #329
• sale_product_set_layout
• sale_quotation_sourcing_stock_route_transit
• sale_sourced_by_line_sale_transport_multi_address
• sale_last_price_info
• sale_reason_to_export
• sale_order_price_recalculation - By @cubells - [9.0] [MIG] sale_order_price_recalculation module #377
• sale_rental - By @alexis-via - [9.0] Port sale_start_end_dates and sale_rental #353
• sale_payment_term_interest
• sale_stock_global_delivery_lead_time
• sale_order_line_description
• pricelist_share_companies
• sale_fiscal_position_update - Not needed anymore (in core) - Deleted in RM sale_fiscal_position_update #349
• sale_order_lot_selection - By @florian-dacosta - [9.0] Migration : sale_order_lot_selection #319
• sale_service_project
• sale_service_fleet
• sale_payment_method_automatic_workflow → sale_automatic_workflow_payment_mode [WIP][9.0] Add sale_automatic_workflow_payment_mode #297 (@guewen)
• sale_quick_payment
• sale_allotment
• sale_automatic_workflow - Assigned to @SodexisTeam - [MIG][9.0] sale automatic workflow #291

[jaredkipe]

Records for 'workflow.transition' require fields 'act_from' and 'act_to' like the following.
<field name="act_from" ref="act_draft"/> <field name="act_to" ref="act_sent"/>

[SodexisTeam]

@pedrobaeza
These 2 modules are not available in the Modules to migrate list. Why?

• sale_payment_method_automatic_workflow
• sale_exceptions

I need these 2 modules to be ported for OCA/connector-ecommerce.

[pedrobaeza]

That's because they were added after this issue was created. I have added them and assigned to you.

[stephankeller]

@pedrobaeza Thanks.

[yajo]

I'm starting with sale_packaging_price

[guewen]

@SodexisTeam sale_payment_method_automatic_workflow is replaced by sale_automatic_workflow_payment_mode in #297

[nicomacr]

I've propose migration of sale_order_type in this pr #340

[LoisRForgeFlow]

Migration of partner_prepayment might be not needed as the feature provided is covered in #434. What do you think?

[LoisRForgeFlow]

sale_validity is in #447

[AMhadhbi]

@pedrobaeza what about module sale_quick_payment. it should be migrate or it is already merged with other module? thanks

[pedrobaeza]

@AMhadhbi modules that weren't present in the repository when the 9.0 branch was created are not populated automatically in this list, but if it deserves to be migrated, we can add it.

[florian-dacosta]

@AMhadhbi you can check this : #403

[AMhadhbi]

@florian-dacosta Thank you. I check it, you are right sale_quick_payment depend on sale_payment_method. also sale_payment_method not already migrated.
@pedrobaeza should migrate sale_payment_method? then migrate sale_quick_payment. and we will migrate to version 10 and v11. or we will work on this pull request #403 and merge them with sale_payment. what do you suggest?

[pedrobaeza]

Well, I don't know both, but it seems that #403 is in good shape, and accounting has changed a lot in v9, so probably go for this PR is a better option.

[florian-dacosta]

sale_payment was meant to replace sale_quick_payment + sale_payment_method.
I should have notified that here actually, my mistake.

@AMhadhbi sale_payment_method should not be migrated, because the sale.payment model has been replaced by account.payment.mode, which is implemented here : https://github.com/OCA/bank-payment/tree/9.0/account_payment_mode

[AMhadhbi]

@florian-dacosta very good. you already answer my question how to replace object payment.method thank you very much.
sure your PR is a good way. sale_quick_payment will be replaced with sale_payment and sale_payment_method already migrated with account_payment_mode. Perfect !

[StefanRijnhart]

Can I just ask how you all like the convergence between the old payment.method from sale_payment method and account.payment.mode as per this edition's migration? We are running a multi-company Magento site migrating away from version 8.0. For us, the payment.method is just a label determined in Magento by the payment provider that we can use in Odoo to apply the ecommerce import_rule, workflow_process_id and days_before_cancel settings. These settings are the same across our entities so these payment.method's don't have a company set. For us, this payment.method model does not have anything to do with the actual payment.

In our migration, because of the convergence with account.payment.method, I'm having trouble assigning all kinds of required fields that are company dependent (not in the first place the required company_id itself). Expanding this table with separate entries for each individual company would ruin the usability (we have a lot of entries already).

Do you agree that this old payment.method could maybe return as a new ecommerce.payment.method with just these import related settings? We could add a payment_mode_id on this model to optionally set the sale order's payment_mode_id. I would be proposing a proof-of-concept for version 12 that could be included in the code for version 14.

[github-actions]

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

[daramousk]

Is the sale_order_merge module not used anymore? I do not see any references to its migration or any other reference to it.