Implement Master Planning practice questions

Set the Positive days to 0.

Why it fails: Positive days control how long existing supply can cover future demand before a new supply order is suggested. Setting this to zero forces new supply for all demand regardless of existing inventory, which does not address the logic for handling past-due requirements in the planning engine.

Set the Coverage period to 0.

Why it fails: The Coverage period defines the time bucket for grouping requirements into a single planned order. Setting this to zero does not impact how the system treats demand dates relative to the current date; it only changes how requirements are aggregated during the planning run.

Enable the 'Include past receipts' checkbox.

Why it fails: This setting allows the planning engine to consider inventory receipts that have already occurred but are still in transit or processing. It does not control the logic regarding how past-due demand is handled or how shortages are calculated relative to the current system date.

The requirement will be satisfied by existing supply within the 2-day window.

Why it fails: The requirement is four days past due. Since the negative days parameter is set to 2, the system does not view this requirement as eligible for fulfillment by late receipts or existing inventory. It must trigger a new supply signal immediately to meet the demand.

The requirement will be marked as invalid and ignored by Master Planning.

Why it fails: Master Planning does not ignore invalid requirements unless they are specifically excluded by a filter or a planning horizon constraint. The system is designed to trigger a replenishment action for any requirement that falls outside the negative days window to ensure fulfillment.

The system will extend the negative days to 4 to accommodate the date.

Why it fails: The planning engine does not dynamically adjust coverage group parameters based on the age of the demand. It strictly adheres to the configured negative days value defined in the coverage group assigned to the item, resulting in a triggered planned order for this late demand.

Create an intercompany agreement and enable automatic invoice posting.

Why it fails: Intercompany agreements and invoice settings are related to the financial settlement and operational workflow of intercompany transactions. They do not trigger the planning engine to see requirements across legal entities. The link must be defined at the item-vendor relationship level for planning visibility.

Use the Master Planning 'Copy' functionality.

Why it fails: The Copy plan functionality is used to replicate planning scenarios within the same company for analysis purposes. It does not facilitate the cross-company communication necessary to trigger a planned purchase order based on a sales order requirement located in a different legal entity.

Configure a Global Address Book entry for both companies.

Why it fails: The Global Address Book is essential for managing entity data, but simply having both companies in the same address book does not establish the supply chain relationship needed for Master Planning to propagate demand signals between the two legal entities during the planning run.

Planning Optimization Map.

Why it fails: While Planning Optimization is the engine for calculations, there is no UI element specifically named 'Planning Optimization Map' that displays pegging. The visualization is performed within the standard Net requirements inquiry forms available for any item under the Master Planning module.

Forecast demand overview.

Why it fails: The forecast demand overview is designed to display anticipated sales figures and statistical trends, not the actual supply chain pegging. It lacks the ability to trace specific supply orders to the original demand source, which is the core function of the Net requirements inquiry.

Master plan comparison report.

Why it fails: The master plan comparison report is used to evaluate the differences between two distinct planning scenarios, such as a pessimistic versus an optimistic plan. It does not provide the item-level graphical pegging information required to see the connection between specific supply and demand records.

Batch order priority.

Why it fails: Batch order priority is used during the production scheduling phase rather than the Master Planning phase. While important for manufacturing sequencing, it does not impact the logic of how requirements are calculated or how supply orders are initially triggered during the planning engine's execution.

Forecast reduction key.

Why it fails: The forecast reduction key manages how demand forecasts are consumed by actual sales orders. While it is important for demand planning accuracy, it is a secondary setting relative to the core Master Planning performance parameters like negative and positive days, which govern the entire replenishment calculation.

Default ledger account.

Why it fails: Ledger accounts are configured for financial integration and accounting purposes. They have zero impact on the mathematical logic or the performance of the Master Planning engine, as the engine focuses on quantities and dates rather than the financial dimension postings at this stage of the process.

Master plan parameters.

Why it fails: Master plan parameters are global settings that affect the entire planning run, such as the planning horizon and performance logs. They do not hold item-specific data like lead times, which are managed at the product or order setting level for each specific item in the catalog.

Coverage group configuration.

Why it fails: Coverage groups determine how requirements are calculated and aggregated, not the lead time of the items themselves. While they impact when an order is created, they do not contain the lead time data needed to calculate the delivery date of a planned purchase order.

Forecast plan settings.

Why it fails: Forecast plan settings are used for demand forecasting and statistical analysis. They do not influence the lead time logic of supply orders. Lead times are operational constraints tied to items and vendors, whereas forecast settings relate to anticipated sales volume and market demand patterns.

Automatically firming all planned orders.

Why it fails: The system does not automatically firm planned orders during a regeneration run, as this would be highly disruptive to operational workflows. Firming must be done manually or via a batch job to convert the planned orders into actionable production or purchase orders for the warehouse.

Updating the General Ledger accounts.

Why it fails: Master Planning is a supply chain calculation and does not trigger financial postings. Updating the General Ledger only occurs when orders are processed, received, or invoiced. Therefore, the planning run itself has no direct impact on the financial balance sheets or the accounting records of the company.

They will be deleted and replaced with new planned orders.

Why it fails: Firm-planned orders are considered committed supply and are not automatically deleted by a Master Planning run. The system recognizes these as valid, fixed inputs to the plan, ensuring that the planner's manual scheduling decisions are respected and not overwritten by the automation process.

They will be moved to the Dynamic plan instead.

Why it fails: There is no automated process within a Master Planning run that moves firm-planned orders between plans. The plan is a defined scope, and firm orders are associated with the specific plan they were created in. Moving orders requires manual intervention or a specific administrative copy function.

They will be modified to match the new calculated requirements.

Why it fails: Once an order is firm-planned, the system treats it as a fixed requirement. The planning engine will not modify the quantity or dates of a firm-planned order. Any remaining shortages resulting from the new plan will instead be addressed by creating new planned orders.

The Coverage period is too long.

Why it fails: The coverage period is used by the 'Period' code, not the 'Min/Max' code. For Min/Max coverage, the engine evaluates current stock against the threshold, not a time period. Therefore, the coverage period setting is irrelevant to the issue of excessive order generation in this scenario.

The vendor lead time is too short.

Why it fails: Vendor lead time affects the delivery date of the purchase order, not the decision to trigger one. Even with a short lead time, the system would not trigger an order if the inventory levels were sufficient and the coverage parameters were configured correctly to recognize that stock.

The safety stock level is set to zero.

Why it fails: Safety stock is a buffer requirement. Setting it to zero would likely decrease the number of orders, not increase them. If the system is generating too many orders, the problem stems from the logic used to evaluate existing stock, not from a lack of safety stock requirements.

Enable the 'Include inventory' checkbox on the master plan to filter by transit status.

Why it fails: The 'Include inventory' checkbox is a global toggle for the entire plan and does not provide the dimension-level granularity required to exclude specific statuses like in-transit. Applying this global setting would inadvertently ignore all inventory, leading to massive over-purchasing across all warehouse locations regardless of their actual status.

Set the 'Coverage group' to exclude the 'In transit' warehouse dimension.

Why it fails: Coverage groups control parameters like time fences and negative days but do not directly allow for the exclusion of specific inventory dimensions like transit. While they influence how replenishment is calculated, they lack the underlying logic to filter inventory dimensions from the planning net requirements calculation process directly.

Modify the 'Plan parameters' to set the 'Safety margin' to zero for all transit warehouses.

Why it fails: Safety margins are used to buffer lead times for receiving or issue processes and do not affect the inclusion or exclusion of physical inventory balances. Adjusting these margins would only impact the timing of the planned orders rather than the actual calculation of required quantity based on existing inventory.

The PositiveDays value is too high for the item.

Why it fails: Positive days determine how long current inventory is considered to cover future demand before a new supply order is required. Setting this to 30 days is standard and would not cause a failure to generate a replenishment order; it would simply influence when the next order is suggested.

The CoverageGroup is set to Manual.

Why it fails: Setting the coverage group to 'Manual' simply means the system will not automatically generate planned orders for the item, regardless of the planning parameters. While this causes the missing demand issue, the root configuration issue that prevents automatic replenishment is the restrictive NegativeDays parameter for the specific planning run.

The StaticPlan is not configured for calculation.

Why it fails: A static plan is designed for long-term planning and is fully capable of calculating requirements. The plan type itself does not prevent the generation of replenishment orders; the logic within the coverage parameters linked to the plan is what determines whether or not a specific order is created.

Assign a 'Resource group' to each item in the product catalog.

Why it fails: Resource groups are assigned to routes and operations, not directly to item master records. Assigning them to items is not possible in the product catalog and does not configure the planning engine to look at capacity constraints during the explosion of the bill of materials and the route.

Set the 'Planning time fence' to zero.

Why it fails: A planning time fence of zero would tell the system not to look ahead for any requirements, effectively stopping all planning activities. This would not activate capacity planning; rather, it would prevent any planned orders from being generated, which is the opposite of the desired outcome for capacity-aware scheduling.

Configure the 'Warehouse management' parameters for production.

Why it fails: Warehouse management parameters govern inventory movements, picking strategies, and storage locations. They have no impact on the scheduling of production orders or the capacity calculations performed by the Master Planning engine, which relies instead on route definitions and resource calendars to determine if work can be completed on time.

Configure vendor lead times.

Why it fails: Vendor lead times are relevant for purchase orders, not for internal production scheduling. While production scheduling requires material availability (which may depend on purchased items), the lead times of those raw materials are handled separately from the capacity scheduling logic of the production operations themselves.

Set up warehouse zones.

Why it fails: Warehouse zones are relevant for warehouse management (WMS) put-away and picking strategies, but they do not impact the master planning engine's ability to schedule production. Production scheduling is concerned with resource availability and route operations, whereas warehouse zones are concerned with the physical storage and movement of inventory.

The coverage code is set to 'Requirement'.

Why it fails: The 'Requirement' coverage code is the standard setting for demand-driven replenishment. It is not the cause for ignoring the incoming supply; rather, it is the interaction between the requirement date and the available supply date, mediated by the negative days parameter, that determines if the supply is used.

The static plan does not allow for Purchase Order consumption.

Why it fails: Static plans are fully capable of consuming existing purchase orders. There is no configuration within a plan type that would selectively block the consumption of purchase orders while allowing other types of supply, as the planning engine treats all firm supply orders equally during the net requirements calculation.

The item is not configured for automatic firming.

Why it fails: Automatic firming is an execution-level function that converts planned orders to firm orders. It does not influence the planning engine's ability to see and use existing supply orders. The decision to create a new order is made before the firming stage, based solely on availability and timing parameters.

Period

Why it fails: Period coverage groups multiple days of net requirements into a single bucket based on the specified period length. This strategy reduces the number of planned orders generated over time but fails to reserve a dedicated stock buffer specifically for unpredictable demand surges.

Requirement

Why it fails: Requirement coverage creates a direct one-to-one pegged planned order for every single demand transaction. This approach minimizes on-hand inventory holding costs in a lean environment but provides no dedicated buffer quantity to absorb sudden and unexpected demand spikes.

Min/max

Why it fails: Min/max coverage monitors total inventory positions against predefined lower and upper limits to trigger replenishment orders. While it maintains stock levels within a range, it does not function as an isolated safety buffer specifically designated for demand volatility.

Activate plan versioning to archive historical master plans automatically.

Why it fails: Plan versioning is designed to track changes and maintain historical iterations of master plans for auditing and comparison purposes. It does not alter execution algorithms or improve the calculation speed of the master planning batch job.

Change the default coverage code on all item coverage records to Requirement.

Why it fails: Switching coverage codes to Requirement forces the system to generate individual planned orders for every single demand line. This increases database transaction volume and creates more processing overhead, ultimately degrading master planning performance rather than improving it.

Disable the action message generation on all active coverage groups.

Why it fails: While disabling action messages can marginally reduce calculation overhead, it does not provide the substantial performance gains achieved by configuring parallel processing and helper tasks within the core master planning parameters.

Freezing time fence

Why it fails: The freezing time fence prevents the master planning engine from automatically creating, modifying, or deleting planned orders within the defined timeframe. It protects existing orders from churn but does not control the calculation horizon for net requirements.

Explosion time fence

Why it fails: The explosion time fence determines the timeframe within which bill of materials explosion occurs for planned production orders. It governs multi-level component requirements rather than controlling the overall net requirement calculation horizon for master scheduling.

Capacity time fence

Why it fails: The capacity time fence specifies the period during which operations scheduling takes resource capacity constraints into account. It is used in advanced manufacturing scheduling scenarios rather than general procurement requirement horizon control.

The negative days parameter on the item coverage group was set to zero, preventing cross-period pegging.

Why it fails: Negative days govern whether existing supply outside the requirement date can be used to cover demand within a specific window. This setting does not dictate whether unapproved purchase requisitions are recognized as valid supply sources by the planning engine.

The item coverage code was set to Requirement, which forces a new planned order for every single demand transaction.

Why it fails: Requirement coverage generates a separate planned order for each demand transaction when no valid supply is found. If a valid supply source like a purchase order were recognized, it would be pegged regardless of the Requirement coverage code.

The master planning timeout parameter cancelled the processing of purchase requisition supply transactions.

Why it fails: Master planning timeout parameters terminate batch jobs that exceed maximum execution durations to prevent system lockups. They do not selectively filter out specific supply document types like purchase requisitions during normal calculation runs.

Set the 'Minimum' value to 350 and the 'Maximum' value to 350.

Why it fails: Setting both minimum and maximum to 350 would force the system to always maintain exactly 350 units, but this is not the intended fix. The issue is that the Min/Max logic triggers replenishment when inventory drops below the minimum; with on-hand at 350 and minimum at 100, it should not trigger. Changing these values would not resolve the underlying misconfiguration causing unnecessary orders.

Change the coverage code to 'Period' and set the coverage period to 1 day.

Why it fails: Changing the coverage code to 'Period' alters the replenishment logic entirely; it would group demand into a period and may still generate orders based on net requirements, not necessarily eliminating the issue. It does not directly address the Min/Max behavior where the system replenishes up to the maximum when inventory falls below the minimum. This change would not guarantee that no unnecessary purchase orders are created for the given scenario.

Disable the 'Min/Max' coverage code and use 'Requirement' instead.

Why it fails: Switching to 'Requirement' coverage would change the planning logic to generate orders only for specific demand, potentially ignoring the Min/Max replenishment strategy. This does not fix the reported issue of unnecessary orders under Min/Max; it merely avoids the symptom by changing the coverage method, which may not align with the company's inventory policy. The correct approach is to diagnose why Min/Max is triggering incorrectly.

In the item's default order settings, set the 'Production' order type to 'Formula' and enable 'Plan co-products'.

Why it fails: There is no 'Plan co-products' setting in the default order settings. The production order type for process manufacturing is typically 'Formula', but that alone does not enable co-product planning. The co-product planning behavior is controlled by the formula's co-product setup and the co-product item's coverage group, not by a checkbox in default order settings.

On the formula, set the co-product's 'Burden category' to 'Co-product' and specify the planned quantity.

Why it fails: The burden category is used for cost calculation, not for master planning co-product generation. While co-products are defined on the formula, the burden category does not control whether Master Planning considers them as supply. The correct setup involves the co-product's coverage settings and the formula's co-product configuration, not the burden category.

On the formula, specify the co-product with a negative quantity and link it to the co-product item.

Why it fails: Co-products are specified on the formula with a positive quantity, not negative. A negative quantity would indicate a by-product or a consumed item. The sign convention is important: co-products add to supply, so they are positive. Specifying a negative quantity would cause the plan to treat it as a consumed material, which is incorrect.