How Soft Constraints Work with Soft Constraints Days’ Supply and Safety Stock Penalty Costs

Posted on by

Background

The topic of the use of days’ supply in a cost optimizer like the SNP optimizer is an interesting one. We begin by looking at what SAP has to say on this topic.

You can also use safety stock for static days’ supply planning with the SNP optimizer. When using static days’ supply planning, it should be ensured that there is at all times at least as much on-hand stock of a product as is required within the days’ supply horizon.

To do this, define a safety stock method for the appropriate product on the Lot Size tab page in the location product master (SZ, MZ, SM,or MM) and enter either a safety days’ supply that is not period-dependent in the location product master or a safety days’ supply that is period-dependent in the interactive planning table. Note that for safety stock methods SM and MM, the SNP optimizer only considers independent requirements as well as dependent and distributed demands caused by fixed orders, since these demands and the demand locations are already known before the optimization run.

The optimizer uses the days’ supply planning results as a basis for creating the safety stock. – SAP Help

The codes that SAP is referring to is the safety stock method that is being used. SAP is using this term, but it is not the “method” as generally understood in supply planning generally, where it for instance states whether the safety stock is dynamically calculated. Instead, when SAP states method, they mean essentially where the system looks in order to derive the safety stock. As can be seen below, the Safety Stock value and the Safety Days’ Supply are interrelated fields.

There is an option to populate either or both of these fields. When both are populated, the Safety Stock Method becomes SM. SM means that the greater of either the Safety Days’ Supply or the Safety Stock as entered in the bottom field will be used to calculate the safety stock. This is advantageous because the safety days’ supply varies as it is a forumla. This formula is shown below:

Days’ supply = Total Inventory / Average Daily Consumption

On the other hand, the Safety Stock is “hard coded” and does not vary. This keeps the safety stock above a minimum level, which is useful when for instance the sales orders or forecast is low. However, when the forecast or sales orders increases, this allows the system to increase above the minimum Safety Stock. This essentially replaces the dynamic safety stock which is available to the right in the screen shot below and which changes depending upon the variability in supply and demand. Many companies would like dynamic safety stock, but simply find it to be too much master data to maintain.

How Days of Supply Actually Works

In a cost optimizer, everything must be broken down into a cost. When Days’ Supply Planning is used (that is a Days’ Supply value is set in the field above), this allows the optimizer to leverage the penalty cost for violating safety stock. When the optimizer is setup it is assigned different costs for both implicit and explicit costs. (this is described in the post below)

http://www.scmfocus.com/inventoryoptimizationmultiechelon/2011/05/how-costs-are-really-set-in-cost-optimization-implementations/

The cost assigned to safety stock violation (which can be set globally or at a product location combination), is the cost the optimizer incurs when it violates the safety stock. Safety stock is a soft constraint, which means it can be violated, but at a penalty cost. This would contrast to a hard constraint, which would be something like a production constraint, which absolutely caps how much can be scheduled per day at a number which the optimizer may not violate. Hard constraints do not require costs to be associated with them because there is not option to exceed them. Things like transportation costs are not constraints, they simply scale with the units of transportation scheduled. The same applies for storage costs. In SNP, storage costs are incurred on a daily basis per unit. Another example of a soft constraint is the cost of unfulfilled demand. The objective function of SNP is to minimize costs, so the unfulfilled demand is declared as a penalty cost, to encourage or direct the optimizer to meet as many demands as is feasible, given the hard constraints.

Getting back to how the safety stock is leveraged, anytime the planned Days’ Supply is lower than the target Days’ Supply, the safety stock soft constraint is violated and the safety stock penalty cost is incurred.

Day’s Supply in Practice (with the optimizer)

Companies are generally good about entering a Days’ of Supply, however, where they tend to fall down is in setting the penalty costs for safety stock violations. The optimizer will emphasize maintaining a Days’ Supply value only to the degree that it has to in order to minimize costs. If the penalty costs are set low relative to other costs (which they tend to be for some reason), one can expect the system to frequently depart from the Days’ Supply desired by the company at each product location combination.

Conclusion

How Days’ Supply works with optimization and safety stock penalty costs has been described above. This is important to understanding how significantly the system varies from the Days’ Supply. As with any other cost, the SNP cost optimizer will only respond to, and perform activities that help it achieve its objective function, which is to minimize costs.

References

http://help.sap.com/saphelp_scm70/helpdata/en/79/70833c8b079c2ee10000000a114084/content.htm

 

Use of the Rounding Value Versus the Lot Size

Posted on by

Background

The way these two fields control the procurement is fairly simple but important to know. The Minimum Lot Size is used to essentially make SNP wait until enough requirements have been gathered before an order is placed. This prevents material being shipped in uneconomic quantities. The Rounding Value essentially does the opposite, it round up the order quantity. Minimum Lot Sizes and Rounding Values can be of course be used in conjunction with one another. The Minimum Lot Size is the minimum quantity which the product can be ordered in. The Rounding Value the quantity multiple which the order is rounded to. However, if the Rounding Value is higher than the Minimum Lot Size, the Rounding Value can act to increase the order quantity above the requirement.

Both of these values can be seen in the screen shot below which is Lot Size tab in the Product Location Master.

Comparative Value Analysis

A good exercise is to show different examples of Minimum Lot Sizes (MOS) with Rounding Values (RV) to demonstrate how SNP would respond.

  1. MOS = 0, RV = 15 : In this case as soon as the first requirement for 1 is generated that is not covered by planned Stock on Hand, an order for 15 would be generated. This would be the type of setting useful for high profit items.
  2. MOS = 5, RV = 15: Any MOS which is lower than the RV makes the MOS essentially unused. In order for the MOS to contribute to the ordering in anyway, it must be higher than the RV. Therefore, this setting would behave the same as the example above.
  3. MOS = 5, RV = 3: In this case the purchase order minimum becomes 6, which is 2 x the RV of 3. In this scenario the MOS effectively becomes 6, and order quantities are possible in the sequence of 6, 9, 12, etc..
  4. MOS = 10, RV = 1: A RV of 1 would make no sense as the system is already required to order only in integer quantities. Therefore, for the RV to have any effect on ordering, it must always be above 1.
  5. MOS = 10, RV = 10: When the MOS is set equal to the RV, it means that that the RV has no effect for the lowest order amount, but then controls the order increment after the MOS.

Where The Rounding Value Can be Set and How it Can be Recognized

There are several places to set the Rounding Value, as the quote below from SAP Help describes.

The following applies for optimization-based planning: If you do not enter a rounding value or enter the value 0, the system uses the rounding logic of the production process model (PPM).

If you specified a rounding profile in the location product master, the system uses this profile instead of the rounding value. The SNP optimizer, deployment and the TLB all ignore the rounding profile.

You have to choose the discrete optimization method in the SNP optimizer profile and enter a discretization horizon in the Integral PPMs field of the Discrete Constraint tab page for the SNP optimizer to be able to take the rounding value into account.

So that the SNP-TLB can use the rounding value, you must set the corresponding indicator in Customizing for SNP under Basic Settings -> Maintain Global SNP Settings. Otherwise the SNP-TLB uses only the rounding value from the transportation lane. - SAP Help

Conclusion

The Rounding Value is a consumption logic parameter, and with all consumption logic parameters should be set per product location / or grouping of product locations by understanding the interaction with the other consumption parameters. This is best accomplished by displaying a spreadsheet or table of product locations and their consumption parameters to those with the business knowledge to intelligently provide feedback on what the parameters should be. After this initial meeting, the consumption parameter results should be analyzed to fully understand what the implications are for what the agreed upon settings are and socializing that analysis among a broad group of decision makers. This continues not to be done in companies, which is why they still have problems with ensuring that their consumption logic parameters are internally and externally consistent.

References

http://help.sap.com/saphelp_40b/helpdata/en/7d/c27259454011d182b40000e829fbfe/content.htm

Incremental Optimization and Pre-Existing Orders as Fixed Constraints

Posted on by

Background

As with CTM, the SNP Optimizer can be run in net change mode. This allows the fixing that occurred in the previous optimization run to be maintained. This is well described in the quote below:

“Incremental optimization defines how to deal with results from previous planning runs. If the Do not delete any orders indicator is not set (see below) or if fixed orders exist the algorithm might run into infeasibilities if the existing orders are considered as hard constraints that need to be fulfilled. To influence this, demand originating from fixed (and existing) orders can be treated either as a hard constraint, a pseudo-hard constraint…a corrected forecast, or a forecast. - Real Optimization with SAP APO

However, in most cases this indicator is disabled and the optimizer recreates all orders during every run. This of course takes longer, than if this not performed. The authors do a good job of explaining the fixed orders themselves as constraints.

References

“Real Optimization with SAP APO,” Josef Kallrath, Thomas I. Maindl, Springer Press, 2006

 

Using an External System to Check Optimization Results

Posted on by

What This Article is About

  • What limits the understanding of a system? 
  • Why is properly supported interpretation so important to understanding complex systems? 
  • Why are external prototyping systems generally not used? 
  • What have been the problems with cost optimizers generally? 

Background

I recently worked on a project where the company was concerned as to whether the costs that it had placed into its cost optimizer were correct. It turns out that it had setup its costs, and then changed its costs over time primarily based upon the output of the system. The company wanted to know how the optimizer actually worked did not think that it got very good information from SAP on this topic. I realized from my interactions with them that because they did not actually understand how the optimizer worked in detail, they were not as able to control it. Secondly the setting of costs was very much trial and error. Thirdly, I did not read in the configuration documentation or in discussing with the client that the implementation partner had properly explain what the optimizer was doing. I have been using an application for prototyping forecasting and augmenting DP for some time, but I had not considered finding an application to triangulate a cost optimizer against. However, it is an excellent idea. One of the reasons that companies have a problem with visibility to the optimizer’s workings is that most enterprise solutions are deliberately hidden by the vendor. The next quote explains why:

Programming or computer science approaches use a programming language such as FORTRAN, C, or C++ to combine the model and the data and either produce a matrix or either input file for a commercial solver, or even include the solution algorithms in one program. In standard business software this approach is quite common because there is minimal to no need of changing the model in a client specific way and keeping the model, business logic, and probably the solver together in one development environment reduces development complexity. Another advantage is keeping together application design and optimization development in one tool results in seamless applications.

Disadvantages are the difficulty to understand and to be read by others, the difficulty to maintain the code, and the dependence on operating systems and compilers, to mention a few. - Real Optimization with SAP APO

This is very well said, but I take issue with the orange text in the quotation above, as I have had several clients communicate an interest to me to see the mathematics of the SNP Optimizer and to possible adjust it. The reason it is not available is explained very specifically in the following quote:

The detailed mathematical model formulation is not revealed by SAP, which is understandable from the commercial and intellectual property points of view, but it may create a disadvantage because it makes the interpretation of the results very difficult. - Real Optimization with SAP APO

Exactly. This makes external validation more important, because the optimization mathematics cannot be tinkered with. I have had very good success in testing DP against a prototype environment, certainly a similar external optimization simulator could bring similar benefits. This brings benefits in the area of extra functionality, transparency as well as the ability to verify functionality in DP.

Why External Prototyping and Validation Tools Are Generally Not Used?

In discussing this with topic with an executive at one of my clients, I was told that he had never thought of using anytime of tool to test the results, and that they had never used such a tool for ERP. This many be why tools of this type not generally used, because the model is ERP, and with ERP the supply chain complexity is sufficiently low that it is mostly unnecessary. However, even with ERP I can see a benefit to externally modeling MRP and DRP, but again because these are simpler methods that the planning methods available within APO, the necessity may not be as great, but it is still valuable. Cost optimization is however a perfect candidate for an external system to run because there is general confusion as to how it works. What is becoming increasingly useful is optimizers which can work with spreadsheets. Applications like MatLab have a spreadsheet connector, however, if that is not used then it is necessary to enter data arrays into the modeling application. The following is an interesting quote on the development of spreadsheets that combine with optimizers:

Before spreadsheets became popular, optimization was available as stand alone software, it relied on an algebraic approach, but it was often accessible only by technical experts. Decision makers and even their analysts had to rely on those experts to build and solve optimization models. Spreadsheets, if they were used at all, were limited to small examples. Now, however, the spreadsheet allows decision makers to develop their own models, without having to learn specialized software, and to find optimal solutions for those models using solvers. The spreadsheet has become almost ubiquitous, as least in the business world. The spreadsheet has come to represent a common language for analysis. Second, the software packages available for spreadsheet based optimization now include some of the most powerful tools available. The spreadsheet platform need not be an impediment to solving practical optimization problems. – Optimization Modeling with Spreadsheets

The Problem with Cost Optimization Historically

Cost optimization as a way of performing supply chain planning in multiple areas (supply, production, transportation) back in the mid-1990′s. At the time it was assumed that cost optimization was simply a better way to perform planning and that it would eventually take over. This did not happen, and clients ran into many problems with cost determination. This is the short version of events. There is a longer story to this, which I have documented here.

http://www.scmfocus.com/scmhistory/2010/07/the-rise-and-decline-for-supply-chain-optimization/

Understanding the history of cost optimization, and the concerns of this client I was working with it lead me to consider how often cost optimization projects have run into problems because the business did not have it fully explained to them how to develop costs because they did not understand how the optimizer actually dealt with costs. This has led to an interest to replicate the SAP optimizer in a general optimization tool such as MatLab or Oracle Crystal Ball (with their respective optimization plug-ins). This will allow me to show people how the optimizer is working with a small data set for basic cost estimation, and can even be used for other simulation purposes, such as supply network redesign (that is what happens if certain transportation lanes are allowed). I presented this idea at one session, and one concern voiced was how the optimizer could replicate what is inside of SAP. Firstly, SAP never originated any work in optimizers, what it added was the optimizer mathematics, but this work was most likely taken from published papers with a few tweaks based upon the needs of some clients.

The engine the SNP Optimizer uses is CLEX which is available to anyone to buy. CPLEX actually integrates with MatLab with a product called TomLab. However, also MatLab has its own optimizer plug-in, and the optimization mathematics for the various optimizations in different supply chain spheres is in the public domain. There are problematic cost optimization projects all across the country that could be improved in this way. The issue of course is that it would take time and cost more in the beginning and most clients probably won’t have the patience for this approach. More details on understanding the difference between enterprise optimizers and general solvers can be seen at the link below:

http://www.scmfocus.com/supplychainsimulation/2011/10/12/understanding-the-difference-between-enterprise-optimizers-and-modeling-languages/

Prototype Environments Generally

However, the opportunity is not limited to cost optimization. I currently use an external prototype tool to troubleshoot and improve SAP DP, and will be relying upon the same tool to model MRP in an external was as well. The more that I discuss with different clients, the more I am able to explain that modeling outside of the production system can bring significant benefits. In my experience, clients are never exposed to the “single solution approach” this in the large consulting companies, because they don’t understand the concept of simulation and what is and what is not a good simulation environment.

Multi-Purpose Uses for General Optimizers

Checking the results of a production system is not the only use of an external optimizer. Another is to perform sensitivity analysis for strategic planning. This is described in the post below:

http://www.scmfocus.com/supplychainsimulation/2011/10/25/a-sensitivity-analysis-approach-for-supply-chain-optimization/

Conclusion

There are very significant benefits to using external prototype environments to both help explain what the application logic is doing to the business, to help tune SAP and to assist in the setting of values. The cost optimizer in particular should be externally modeled outside of SAP to make the functions transparent and to be able to simulate quickly. This is something I will be working on in the future, and which I plan to write about extensively. However, the benefits of using flexible simulation environments generalizes outside of the cost optimizer into other areas of the supply chain such as demand planning and MRP.

References

“Real Optimization with SAP APO,” Josef Kallrath, Thomas I. Maindl, Springer Press, 2006

“Optimization Modeling with Spreadsheets,” Kenneth Baker, Wiley, 2011

 

 

 

 

 

SNP Optimizer Sub Problem Division and Decomposition

Posted on by

Background

In finding a way to segregate the problem, cost optimizers are typically programmed to process material supply network by material supply network. This is called “decomposition,” which means to “decompose” the problem as described below:

Decomposition in computer science, also known as factoring, refers to the process by which a complex problem or system is broken down into parts that are easier to conceive, understand, program, and maintain. – Wikipedia

SAP has the following comment on decomposition in its help:

Decomposition is a flexible tool for balancing the tradeoff between optimization quality and required runtime. When runtime is unrestricted, the SNP optimizer usually provides a better (optimal) solution without decomposition; however, when a fixed runtime has been specified, using decomposition could assist the optimizer to find a better or, in fact, feasible solution. - SAP Help

Decomposition can take place along a number of dimensions. For instance in SAP SNP, decomposition can take place upon the following dimensions:

  1. Time
  2. Product
  3. Resource

This can be found on the Solutions Methods tab of the SNP Optimizer Profile.

Time, product and resource are all stated differently from one another.

Time Decomposition

Time asks for a window size. SAP recommends using time decomposition and says that it improves solution quality (which is not surprising as problem division tends to improve solution quality). Time is a relatively easy to dimension on which to decompose due to the lack of problems with interdependence. The number of windows breaks down the planning horizon into buckets.

Product Decomposition

The product decomposition is entered as a percentage. This divides the problem into product groups.

Resource Decomposition

This is the only decomposition method in SNP requires more master data in order to implement. The master data of resource priority profiles is then assigned when this is engaged. Of the different decomposition methods, resource decomposition is the least frequently used and the most difficult to understand.

Resource decomposition speeds up the solution process by analyzing the material flow and basic optimizer decisions about production, procurement, and transportation to determine a resource sequence. The optimizer can then create sub-problems for the individual resources, which are solved in sequence. The optimizer makes decisions in every sub-problem that cause the resource to be loaded.- SAP Help

However, one important issue here is how SAP has designed SNP with respect to resources versus how the resources, and more specifically the categories of resources that are used. SAP’s resource setup allows a wide variety of resources to be used, as can be seen from the screen shot below:

However, while many resource categories are possible, the vast majority of SNP implementations only actually constrain on production constraints. Optimization only focuses on or uses constraints which are set to finite. (If not finite, the resource can be used for information purposes, to allow planners to see what weeks are over capacity.)

Because of this fact, the complexity involved in as SAP says “analyzing the material flow and basic optimizer decisions about production, procurement, and transportation to determine a resource sequence,” is a lot more simple than it sounds. This is because if the only resource to be analyzed are production resources, then it really just comes down to combining products that share the same resource together as a sub-problem. Without this, a sequential run of each product (each product that shares the resources as a separate sub-problem, as in the case with product decomposition) would result in one product receiving the resource allocated to its production before another simply based upon the “luck” of the sequence of the product sub-problem being run through the optimizer.

Using Both Product and Resource Decompostion

There are a few interesting things about this comment from SAP with respect to using both product and resource decomposition at the same time.

It is particularly advisable to use resource decomposition if the production processes always load the resources in a similar sequence. Resource decomposition does not reduce memory requirements. If you want to use product and resource decomposition together, the system carries out the resource decomposition first. The product decomposition then tries to improve upon the results of the resource decomposition. – SAP Help

The portion in orange is of course very interesting. It is also surprising, at least to me. If I had been designing the decomposition method with developers at SAP, I would have requested that when both resource and product decomposition are selected, would mean that the system would look at both at the same time. This would in effect increase the size of the sub-problem, as products with shared resources would be included as part of the same sub-problem. This conceptually would be described below:

This type of decomposition solves the issue of resources that are shared across products. It does have the disadvantage of creating a larger sub-problem, however, shared entities that have inter-relationships should be in the same sub-problem. However, SNP does now work that way. Instead, it processes the decomposition sequentially. This cannot possible be as good a solution as the design described above. However, this would seem to be an issue with CPLEX rather than SAP, as CPLEX is the solver doing the work behind the scenes, but this is SAP’s setup, and I have to say, the fact that one optimization does not respect a previous optimization, makes this design looks quite strange to me. In fact, I am unsure if I would use it. This would lead one to perform the decomposition by manually breakup the problem into different runs, which is of course less desire-able and requires extra maintenance effort. Furthermore, the more resources there are, the less feasible this solution would be. Interestingly, I have never read any post or book which criticized SAP’s resource decomposition method before.

Decomposition Benefits

The following quote is instructive with respect to the benefits of decomposition:

Since the existence of many restrictions or – to a higher extent – discrete variables can lead to high computational efforts, SAP APO offers various possibilities to reduce the storage and runtime requirements by dividing the problem into parts. Particularly in the case the supply chain model results in a MILP (mixed integer linear program) problem solver runtimes can get very high; integer models are a consequence of discrete decisions such as modeling lot size intervals. As the implementor does not have direct access to SAP’s mathematical model formulations these methods of handling the solution times are the approximate way of influencing the behavior of the SAP APO optimizer (apart from changing master data that define the coefficients in the model equations). Especially when dealing with large MILP problems the runtime of the algorithm might be cut by decomposing the problem into smaller subproblems. - Real Optimization with SAP APO

Optimization with Integers and Integer Relaxation

While it may appear to be a minor issue, in fact setting a number of the variables to integers in fact greatly lengthens out the run-time, and APO does not have an option for relaxing integer constraint as most other optimizers that I have worked with do.

Here is an example of integer relaxation within the Frontline Solver for Excel. It is set as a default to 5% of integer optimality. This allows the solver to still find a very good solution, but to spend much less time calculating it. Because Frontline Solver is much more frequently used for calculating strategic objective functions with far fewer outputs, relaxing the integer requirement is a much more simple matter than doing so in a supply planning enterprise optimizer which calculates a tremendous number of value as output, all that would have to be adjusted post-optimizer in order to be actionable in the real world.

The concept to integer relaxation is one to solve the problem more quickly for testing, and secondly all of the output (such as purchase orders) could be relaxed within the optimizer, bringing much faster solution times, but with internal rounding. Therefore, 45.3 units would become 50 units in order to meet both the lot size quantity and the integer requirement. (sending .3 of a unit makes great sense from a mathematical perspective, but does not make much sense in the real world. APO could accomplish this with a post optimization rounding routine, but evidently the developers preferred not to go down this track, which means much more hardware is required to run SNP than would have been required if this approach was taken. I am currently writing an article on integer relaxation and I will insert the link to that article here when it is complete.

Josef Kallrath, Thomas I. Maindl go on to describe how the problem decompositions changes depending  upon the decomposition selected.

Resource decomposition is based on the analysis of the material flow and the basic decisions about production. After the analysis, sub-problems are developed for the individual resources according to which the resource assignment is generated. With product and resource decomposition priority profiles can be established to determine the sequence in which the optimizer aggregates and plans product groups and resources. - Real Optimization with SAP APO

Time decomposition on the other hand divides the optimization problem by the time horizon.

Finally, there is an option for vertical and horizontal aggregation of planning data where the optimization is dealing with aggregated data.. Vertical aggregation is concerned with product demand and horizontal aggregation deals with subgroups of the supply chain network - Real Optimization with SAP APO

More on Problem Division

While decomposition sounds comprehensive. In fact, this is only one method, and the most automated method of dividing the optimization problem. Another way is to manually divide the problem into different optimization runs. For instance, some companies may use product decomposition, but then divide the problem by product attribute, so that product with similar attributes are run together. This can overlay with how many production facilities there are that produce each type of product. In general the topic of both decomposition and run division is one of the most all encompassing and complex of all the optimization decisions.

Conclusion

Different optimizers have different ways of decomposing the problem. The selection is actively made during the design stage based upon either time, resource or product. Of the three product is the most common, which breaks each sub-problem into a sub-network per product within the overall supply network.

References

“Real Optimization with SAP APO,” Josef Kallrath, Thomas I. Maindl, Springer Press, 2006

http://help.sap.com/saphelp_ewm70/helpdata/en/01/bc044017355c0ce10000000a1550b0/content.htm

SAP Help

Firming Types of the MRP Types and the Planning Time Fence

Posted on by

Background

There are a number of different MRP Types in the SAP ERP that are simply related to different fixing types. Here are several of the different MRP “MRP Types.”

P1 MRP, fixing type -1-
P2 MRP, fixing type -2-
P3 MRP, fixing type -3-
P4 MRP, fixing type -4-

“Fixing types” control several features of the MRP run. Some of the functions of the fixing type are documented in the SAP Help, and some are not. One of the most important which does not appear to be documented is if PReqs can be created in the past in the system. The graphic is the full description of firming types that I have compiled from SAP Help combined with observation of how the system works.

Planning Time Fence

A main component of how the Firming Types work is within the context of the Planning Time Fence. SAP’s definition of the Planning Time Fence is listed below:

You can protect the master plan from any automatic changes to master schedule items in the near future by using a planning time fence. Within the planning time fence, the system does not automatically schedule or change the procurement proposals. Therefore, the MRP controller has time to plan the master schedule items manually. However, to support the MRP controller, the system can create necessary procurement proposals and schedule them for the end of the planning time fence. You can then schedule these procurement proposals manually as you wish. – SAP Help

This point here is to twofold:

  1. Either do not auto-create any procurement proposals at all (this happens to be fixing type
  2. Or create new procurement proposals at the end of the planning time fence

In order to visualize the Planning Time Fence and how it interacts with various MRP Types, the graphic below has been included:

The Planning Time Fence can be set per product location combination.

Conclusion

Its interesting that so many funationalities are included in the MRP Type. The article below describes how the MRP Type was misnamed from the beginning.

http://www.scmfocus.com/sapplanning/2011/10/11/was-the-mrp-type-field-named-correctly/

For instance, one MRP Type is turns off the planning method so an external system can apply its own planning method, and only explodes the BOM. However, why try to combine BOM explosion and the planning method in a single field? This issue comes up again with respect to the different MPS MRP Types. One problem is that one of four factors of the MPS is that the BOM is not exploded. However, it does not explicitly state this in the MRP Type as it does with the X0 MRP type. SAP has tried to control too many factors with one field which leads to a lack of visibility with respect to everything that is controlled by the field. For instance it would have made more sense to have a separate field that controlled for BOM explosion that would have looked like the following: