MRP Planning Engineby OpenValue http://www.openvalue.cloud
• Inventory (stock)
• Purchase (purchase)
• Invoicing (account)
|Lines of code||2650|
|License||See License tab|
MRP Planning Engine
The “MRP Planning Engine” provides a full comprehensive tool for managing material requirements planning.
The two basic material planning types have been implemented:
· Push logic with backwards scheduling and requirements explosion (where BoM is defined); that’s the classical MRP tool
· Pull logic, that’s Reorder Point with forward scheduling for automatic stock replenishment
MRP planning parameters
In only one master data all necessary attributes are to be entered to define the product planning behavior at warehouse level. Therefore, different planning logics can be assigned to a product in different warehouses. In shorts, the planning area is defined at warehouse level.
A responsible planner has to be assigned to each planning master data. In case of errors issued in performing the planning run, exception messages are addressed to the responsible planner.
The MRP Type indicator is to assign to a product at warehouse level its planning logic:
· MRP, that’s PUSH logic
· Reorder Point, that’s PULL logic
Several replenishment method are supported and automatically determined through the routes assigned to a product in its master data; this attribute is shown in the supply method indicator as follows:
· Stock Transfer
The replenishment lot quantity is calculated according to the following procedures set in the lot method quantity indicator:
· Lot for lot so the lot quantity is determined as the shortage quantity
· Fixed lot to replenish with a fixed quantity or multiple of it
· Supply coverage days by grouping requirements and fulfill them in through an only one replenishment element; this is available for push planning type only
· Replenishment at maximum stock level to fill up the stock at its maximum possible level; this is available for Reorder Point planning type only
The following lot quantity constraints are available;
· Minimum order quantity
· Maximum order quantity
· Multiple quantity
For push planning type only, two options are available for reduce the risk of stockout:
· Safety stock as stock buffer
· Safety time in calendar days as time buffer by scheduling backwards the replenishment proposals
For pull planning type only, the replenishment triggering can be forced by taking into account requirements also by the requirements method indicator which can be set up as follows:
· No requirements (standard static reorder point logic)
· Confirmed requirements with planned date in the procurement lead time
· All requirements with planned date in the procurement lead time
The following Demand Management Strategies are supported:
· MTS Anonymous: the sales order is not relevant for planning and the demand is reduced at sales goods issue (sales order delivery)
· MTO: no independent demand items can be entered
· Planning production by lots: the sales order and the demand items are planned together; it is important to choose a lot method for grouping the demand; the demand is reduced at sales goods issue (sales order delivery)
· Planning with final assembly: the demand reduction is at sales order confirmation so overplanning is taken into account
· Planning without final assembly: as the “planning with final assembly” for the planning topics; planned orders are created for planning purposes only so they cannot be converted, that means the last stage of production process can be performed with sales order.
The Demand Backward Redaction Days is the number of days for searching demand items in the past for sales order in demand reduction process.
The frozen period is calculated in MRP List as support for the MRP Planner.
MRP Demand Management
Independent demand is represented by sales order and forecasted demand to be entered manually. A sales order reduces forecast demand lying in the past as shown in the following picture.
As per the requirements method indicator, the demand and the sales order can force the reorder point calculation.
MRP Planning Engine Run
The planning run is performed at warehouse level; therefore, it is possible to set the proper replenishment sequence in planning supply chains. For example, local warehouses have to be planned before the central ones because these are the internal sources for the local warehouses.
In case of errors, an exception message is posted on the mrp planning parameters master data and assigned to the responsible planner.
In the same run both MRP and Reorder Point procedures are performed.
Planned Orders are created by the planning run as replenishment proposals and listed by Release Date. This list represents the workload of the responsible planner.
Planned Orders can be fixed by the planner responsible, so to be not removed by the next planning run. A Planned Orders can be created manually also and automatically fixed.
Planned Orders can be finally converted massively and a new document is created as per the supply method indicator:
· new Requests for Quotation line for “buy” or “subcontracting” products either
· new Manufacturing Orders for “make” products
· new Stock Transfers for refurbish a warehouse from another one
After converting it, a Planned Order is automatically removed from the list.
Replenishment proposal scheduling depends on planning type assigned to the product at warehouse level in its planning master data, as follows:
· PULL mode in forward scheduling
· PUSH mode in backwards scheduling
The following times are taken into account:
· Request for Quotation
o days to purchase (working days)
o delivery lead time (calendar days)
· Manufacturing order
o manufacturing security lead time (working days)
o manufacturing lead time (working days)
· Goods transfer movement:
o Transfer lead time (working days)
MRP Planning Engine List
The planning results can be evaluated by listing over the time all procurement elements and all requirements; the projected stock is calculated also.
This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software. You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module
- The author can leave a single reply to each comment.
- This section is meant to ask simple questions or leave a rating. Every report of a problem experienced while using the module should be addressed to the author directly (refer to the following point).
- If you want to start a discussion with the author or have a question related to your purchase, please use the support page.