Odoo Changelog — 2019-06-11

Tuesday, June 11, 2019

4 changes

Refactoring(4)

Code cleanup and technical improvements

Reorganize website classes

Coremasterwebsite

The website module’s code has been reorganized into several focused files instead of one large file. This internal cleanup makes the system easier for developers to maintain and should not change how users experience the website features.

Original PR description

Split class from file addons/website/model/website.py in multi files.

Make several commit:
   new file,
   move code,
   merge 
by class to keep history clean.

#website#maintenance#code-organization

[MERGE] stock_account, related addons: stock valuation layer

PR #33935

Coremasterstock_accountaccountproductpurchase_stockmrp_accountpurchase_mrp_subcontractingsalepurchasepoint_of_salemrpevent_saleMEDIUM

This update restructures how inventory value changes are recorded, preparing Odoo to use dedicated stock valuation layers instead of older price history records. It also improves consistency when valuing purchase returns and makes required accounting setup clearer for users.

Original PR description

task-1875873

#inventory valuation#accounting#stock#returns

[REF] mrp_mps

PR #4551

Enterprisemastermrp_mpsHIGH

The master production schedule has been redesigned to better reflect real demand, replenishment already in progress, and warehouse-specific planning. This helps planners adjust forecasts after procurement starts, plan across multiple warehouses, and use clearer schedule views with improved guidance.

Original PR description

The purpose of this commit is to redo master production schedule
with the purpose to:
- Have a better integration with existing records. For demand forecast
and replenishment it adds a tools in order to show the actual demand and
the actual replenishment. Also running the replenishment will deduce the
value to replenish with the existing replenishment already in progress.
- Flexibility on already launched forecast. If the user modify the
demand forecast or the quantity to replenish after the procurement
creation, it will allow the user to relaunch the cell in order to
complete replenishment.
- Multiple warehouses management
- Allow to define a custom number of periods. It would allow use case
with long manufacturing process
- The rules lead time is added to manufacturing and suppliers delay. It
is usefull if the transfer are long between 2 warehouses as example.

Visual effect for the end user:
- Remove the period from the control panel because the user could modify
it without modification on the min and max replenishment for each
schedule, it would completely modify the future forecast and create a
lot of inconsistent documents. (Still available in configuration).
- Use the total width on the screen in order to shpow the information
more clearly on the screen
- Apply button on schedule with a BoM linked to other MPS is replaced
by a direct reload on impacted schedule.
- Hover on replenish button that highlight the forecast that will be
run. The replenish button in control panel is based on lead time, the
replenish button on row, will run the next forecast.
- Tooltips on each row in order to explain the purpose.

#manufacturing#planning#forecasting#replenishment

[REF] stock_account_enterprise: adapt to valuation layer

PR #4534

Enterprisemasterstock_account_enterprisesale_subscriptionaccount_sepa_direct_debitMEDIUM

Inventory value reporting now uses valuation layer data so reported inventory values better reflect the current financial valuation. Subscription access is adjusted after product price history removal, and SEPA direct debit payment processing is fixed for invoices opened under the updated flow.

Original PR description

Use the valuation layers instead of move.value.
"Inventory value" should always contain the valuation right now.

task-1875873

#inventory valuation#reporting#subscriptions#payments

The purpose of this commit is to redo master production schedule with the purpose to: - Have a better integration with existing records. For demand forecast and replenishment it adds a tools in order to show the actual demand and the actual replenishment. Also running the replenishment will deduce the value to replenish with the existing replenishment already in progress. - Flexibility on already launched forecast. If the user modify the demand forecast or the quantity to replenish after the procurement creation, it will allow the user to relaunch the cell in order to complete replenishment. - Multiple warehouses management - Allow to define a custom number of periods. It would allow use case with long manufacturing process - The rules lead time is added to manufacturing and suppliers delay. It is usefull if the transfer are long between 2 warehouses as example. Visual effect for the end user: - Remove the period from the control panel because the user could modify it without modification on the min and max replenishment for each schedule, it would completely modify the future forecast and create a lot of inconsistent documents. (Still available in configuration). - Use the total width on the screen in order to shpow the information more clearly on the screen - Apply button on schedule with a BoM linked to other MPS is replaced by a direct reload on impacted schedule. - Hover on replenish button that highlight the forecast that will be run. The replenish button in control panel is based on lead time, the replenish button on row, will run the next forecast. - Tooltips on each row in order to explain the purpose.