Decision variables are unknown before the decision problem is solved. By solving the optimization problem, a value is assigned to them.
Types of variables in APO:
·continuous variables – these may take any floating-point values (real numbers) in a range, e.g., the starting time for a certain job
·discrete variables – they can only take on integer values in a range, e.g., the numbers of vehicles on a particular route
·binary (0/1-) variables – they represent binary decisions (e.g. setup decisions).
Finding a feasible solution may be difficult. The objective of SAP APO is to obtain the best feasible (= optimal) solution of a decision problem or at least a good feasible solution for a given run time.
In many practical situation there is more than only one business goal. In case of conflicting goals it is very difficult to weigh between these objectives. In APO the users can assign different weights to each goal, and they can determine interactively the value of the weights by using different scenarios.
Linear objective function: each variable is multiplied by a constant, and all terms are added together. For example, if we are trying to determine the optimum product mix of two products, A and B, which we denote as X1and X2respectively. If the profit margin derived from selling one unit of A is $100 and that from B is $400, then the overall profit would be F(X) = 100 X1 + 400 X2 which is a straight line on a graph of X1and X2.
Variable-type constraints reflect the basic properties of the variables, e.g., non-negativity or integrality of production volume. These constraints usually define the domains for the decision variables (search space). Functional constraints describe the structural relationship of activities and resources. In allocating resources to activities, the demand must not exceed the availability. Common constraints on resources include:
Market demand - The market demand ultimately determines the throughput of the firm. The marketplace dictates the product lines and production plan. Loss of sales usually is caused by the plant‟s inability to meet customer requirements at the required time, price and quality. Examples of these constraints are customer orders; sometimes there are different priorities between the customer orders. In SAP APO Optimizer, we can either enforce the prioritization of customer orders strictly (i.e., a higher prioritized customer order may not be delayed in favor of a lower prioritized customer order), or we can model these constraints as soft constraints (i.e., penalize lateness according to priorities).
Material availability – This is a fundamental requirement for production. If a vendor delivers the raw material late or the material is defective, the production process is disrupted.
Resource capacity – Machines, tools and labor must be synchronized to ensure a smooth and timely flow of the production process. Both capacity and materials may be soft constraints in the sense that extra capacity and materials can be purchased at an additional cost for mid- term planning. However, for short-term detailed scheduling, these would be hard constraints. Which resource is a bottleneck may also change over time as supply or demand changes.
Infrastructure logistics – These include temporal constraints and sequencing constraints in operations and routing. For example: after the heat treatment, a part may have to wait for a period of time before the next production step can be executed.
H – number of hockey sticks per day (x1) C – number of chess sets per day (x2)
The region enclosed by the graphs of each constraint represent the feasible solution space
(yellow). The objective function (dotted lines) is plotted at different levels. It can be calculated as
x2=-5/3 x1+ Z/4, where Z represents a fixed level for the objective value. Here, the objective function values are 32 and 64, respectively.
In case of LPs the optimal solution always occurs at a vertex of the feasible region. Here, it is reached for x1(H) = 24, x2(C) = 4, and a maximum profit of $64.
Points in the interior of the feasible space cannot be optimal, because the level
lines of the objective function may be moved to higher objective values.
Note that for some special cases the optimal solution may also occur in two
vertices of the feasible region. Then, all convex combinations between these
two vertices are optimal solutions of the decision problem. In this case, the
level line of the objective function is parallel to the ‚critical„ restriction.
In our example, this would be the case for the following objective function:
max x
1+ 3 x
2=> x
2=-1/3 x
1+ Z/3
Then, we get several optimal solutions, e.g.
x
1= 24, x
2= 4
x
1= 12, x
2= 8
x
1= 6, x
2= 10
The objective function value is always Z = 36.
Idea of the simplex method:
Change of a basis variable (here: x
3, x
4,x
5) with a non-basis variable in the way that
- the objective value increases
- the values of the basic variables remain non-negative
Candidates for change of basic: non-basic variables with negative coefficient in
objective function row
Optimal solution found if all coefficients of the objective function are
non-negative
1st Iteration:
1. Determination of Pivot Column: the variable with the lowest negative coefficient in the objective function row is chosen, because the objective value increases most by taking this variable in the basic (here:
x
2with –4 is Pivot Column).In the sequel, the pivot column is denoted by q (here: q = 2)
2. Determination of Pivot Row: In general, the increase of a new basic variable leads to a reduction of another basic variable, because otherwise the constraints would be violated. Therefore, the increase of the new basic variable is limited by the condition that the values of the other basic variables remain non-negative. The new basic variable can only be increased until the value of one of the other variables is equal to zero. This variable will be taken of the basic. For determining this bottleneck for all coefficients aiq> 0 of the pivot column q the following quotients are calculated:
i= bi/ aiq for all rows i with aiq> 0
where bidescribes the value of the coefficient in the row i of the solution column. Then, the variable in the row p has to be taken of the basic for which the quotient itakes on the lowest, non-negative value (here: 3 with a value of 10).
=> Pivot Element: a32(row p=3, column q=2)
3. Pivot step: creation of the unit vector with a 1 in the pivot row, i.e. a* pq= 1.
4. Optimality criteria: optimal solution is found, if all coefficients in the row of the objective function are non-negative. Otherwise go back to step 1 (choice of pivot column) -> not fulfilled => 2nd iteration necessary
2nd Iteration
1. Determination of Pivot Column: q = 1
2. Determination of Pivot Row: p =2
=> Pivot Element: a21(row p=2, column q=1)
3. Pivot step: creation of the unit vector with a 1 in the pivot row, i.e. a* pq= 1. 4. Optimality criteria: not fulfilled => 3rd iteration necessary
3rd Iteration
1. Determination of Pivot Column: q = 5
2. Determination of Pivot Row: p =1
=> Pivot Element: a15(row p=1, column q=5)
3. Pivot step: creation of the unit vector with a 1 in the pivot row, i.e. a* pq= 1. 4. Optimality criteria: fulfilled => optimal solution found
shadow prices -> coefficients of slack variables in objective function
u3 = 2/6 => decreasing the first restriction (resource A) by one unit would lead to a reduction of the profit by $0.333
-> 4H + 6C < 119 => Profit = 63.667 ( with optimal solution: H = 23.5 and C =4.167)
u4 = 1/3 => decreasing the second restriction (resource B) by one unit would lead to a reduction of the profit by $0.333
-> 2H + 6C < 71 => Profit = 63.667 ( with optimal solution: H = 24.5 and C =3.667)
u5 = 0 => third restriction (resource C) is not active
reduced costs -> coefficients of decision variables in objective function
since x1and x2are both larger than zero, the corresponding reduced costs are both equal to zero
If reduced costs have a positive value, then they indicate how much the corresponding coefficient in the objective function for this decision variable has to be increased in order to get this variable into the basis.
Simplex: algorithm which moves from one vertex of the polyhedron to a new vertex by advancing along one edge at a time
Interior Point Method (IPM): algorithm which moves through the interior of the polyhedron. Comparison:
1. The optimal solution to an LP problem will always lie on a vertex, i.e. on an extreme point of the boundary of the feasible region
2. An algorithm which moves through the interior of a region must pay attention to the fact that it does not leave the feasible region. Approaching the boundary of the feasible region is penalized. This penalty is dynamically decreased in order to find a solution on the boundary.
3. Interior point methods contain complicated mathematics and use advanced mathematical concepts. A large variety of IPMs has been developed. In linear programming, IPMs are well suited especially for large, sparse problems. Here, considerable computing-time gains can be achieved.
B&B is a specific enumeration algorithm. Different from complete enumeration, only a limited number of sub-problems has to be solved.
The B&B algorithm works like a divide and conquer strategy. First, the linear relaxation of the integer problem is solved. If the solution is integer, then this is also the optimal solution for the problem. Otherwise, two new sub-problems are created by branching on a fractional variable. The process is repeated until no further sub-problem can be created or all solutions are integers or infeasible.
Step 1: linear relaxation (e.g., with simplex method)
No feasible solution => MILP has no feasible solution => END
Optimal integer solution => END
Optimal, non-integer solution => step 2
objective function value of LP relaxation is upper bound for objective function value for MILP, lower bound is `-oo`
Step 2: Branching
Branching of a non-integer variable X, with g < X < g+1 and g as integer. The set of all solutions is divided into two sub-sets:
(a) solutions with Xg
(b) solutions with Xg+1
the other constraints remain unchanged. Step 3: Bounding
The two sub-problems of step 2 are solved. The objective function values of both problems are upper bounds for the objective value of both sub-sets. If there are still non-integer variables which have to be integers, then the branching must be continued. But: it is not necessary to analyze a sub-problem if
the bound of the sub-set is lower than the objective value of a feasible, integer solution
the sub-problem is not feasible
If all variables are integers, and if there is more than one sub-problem with a feasible integer solution, then the optimal solution can be found by comparing the values of the objective function.
Step 4: Optimality test
The algorithm terminates if all branches are implicitly or explicitly analyzed. Then, either an optimal solution has been found or the problem is infeasible.
SP5 ends, because integer solution is found.
SP6 ends, because objective function value (Z=14) is lower than the function value of SP5 (Z=15) which fulfills all constraints incl. discretisation and therefore is an lower bound for the overall optimal solutions. Sub-Problems which have a lower objective function value as this bound does not need to be investigated further.
End of sub-problem 5: integer solution; new bound: Z = 15
End of sub-problem 6: objective function value of solution with Z = 14 falls below bound Z = 15
Note: If there are (in at least one sub-set) variables that are not integer, then a criteria is needed to determine which sub-problem should be branched. Within the Dakin-Algorithm the `newest bound rule„ is usually applied. This means that the last generated sub-set which has not been completely analyzed is branched. If the sub-sets are generated simultaneously, then the sub-set with the higher upper bound is chosen.
Cutting-Plane methods operates by starting in the same way as B&B but then moving towards a solution by restricting the feasible region defined by the constraints of the relaxed problem. Pure cutting-plane algorithm tends to be slow to reach a solution => In APO: combination of B&B and Cutting Plane Approach: Branch & Cut (B&C) algorithm.
Branch and Cut (B&C) proceeds in steps which are similar to B&B, but at each node of the tree rather than branching on a single variable, the algorithm appends cuts to the problem which cut off parts of the LP feasible region without cutting off any valid integer solution. Standard Cuts: Gomory Flow Cover Disjunctive ...
Constraints
Transportation
transportation resource
inbound/outbound handling resource Production
production resource
storage resource Procurement
inbound handling resource Product Constraints
minimal/fixed lot sizes
safety stock
shelf life
Decision Variables
production, transportation, procurement, storage quantities
deliveries (fulfilled demands)
Production/transportation/storage capacities: Limiting the maximum availability of production/transportation/storage resources for each location.
Handling capacity: Limiting the flow in and out of a location. The optimizer may consider different handling resources for inbound and outbound.
Capacity calendar for resources: The capacity may change during the planning horizon Break calendar: Breaks can be defined for each resource, e.g. weekends (not: downtimes) Due dates/ deadlines/ maximum delay: Due dates are considered as a soft constraint, i.e. lateness is only penalized in the objective function, whereas deadlines are hard constraints, i.e. no delay is allowed. Deadlines may be modeled by limiting the maximal delay with 0. Safety stock: Falling below safety stock is considered as a soft constraint, i.e. penalized in the objective function.
Additional:
Integer lot size: production or transportation lot size is not continuous sizeable.
If setup times are small and a lot of products are on a resource per bucket, then a „global“ capacity reduction in the resource master data should be used instead of using fixed resource consumption in the PPMs of each product.
If the average lot size (derived from demand data) is considerable larger than the minimum lot size, then it is not necessary to model minimum lot sizes. For instance, with an average demand of 10 pieces, it makes actually no sense to use a minimum lot size of 1 piece for the SNP Optimizer.
Optimization from final stage in Supply Chain (customer level) to the first stage in the Supply Chain (plant level).
The optimizer has to run on a Windows Server machine. As of SCM 2007, Linux is also supported.
On a 32bit OS, the maximum main memory which can be used is 3 GB. (1 GB is reserved for operating system).
On a 64bit OS, the only restriction is the physical memory size (swapping will greatly reduce the performance).
The processor should always be as fast as possible. With the processor performance you can directly influence the run time performance of the SNP optimizer. You have an almost linear relation, i.e. if you have a run time of 3 hours when you use an 2 GHz processor, then you will get a run time of only 2 hours, if you use an 3 GHz processor of the same type (for different CPU types, the .
Important note: 112403 (addressing 3 GB memory under Windows NT/2000/2003) In case of problems with main memory (overflow), there are some specific parameters in transaction copt10 available to solve these problems. Get in touch with development (via OSS message) when you experience these kind of problems, so that development can recommend which parameter should be set. However, there are upper bounds for the number of variables and constraints for the optimizer. Benchmarks from customer cases will follow later.
How to get the sheet?
http://service.sap.com/scm
-> mySAP SCM technology -> Performance and Configuration Recommendations
For a FIXED run time with increasing model detail (i.e. complexity of the model), the gap between optimal solution and computed solution by the optimizer increases.
business will probably not accept these solutions, since they are too far away from the optimal solution (model too detailed)
if the model is too rough, then the business will also not accept the solution, since the model doesn„t correspond to their business requirements.
In the „optimal model detail“ region, the model is not too rough (i.e. it respects the important business requirements) and not too detailed (i.e. it is still solvable in an acceptable run time). Here, acceptable solutions (in terms of business requirements and run time) are found.
However, it might also be necessary to use e.g. decomposition techniques to get the right trade-off between solution quality and run time and to reach business acceptability of the computed solutions.
The customer uses SNP and PP/DS. Nevertheless, they have used a very detailed time bucket profile in SNP resulting in 82 planning periods and a huge amount of (discrete) variables and constraints. It was not possible at all to solve this model in SNP. But since the customer uses PP/DS for detailed scheduling, it actually didn„t make sense to use such a detailed time bucket profile and it was possible to convince him to use an aggregated time bucket profile with only 39 planning periods.
Additionally, the number of transportation lanes could have been reduced and the number of discrete variables as well. It was not absolutely necessary to have minimum lot sizes and fixed resource consumption, but, on the other hand, transportation lot sizes have been introduced. In total, the number of discrete variables have been reduced.
Nevertheless, it is not possible to solve a problem with such a lot of (discrete) constraints and variables without any decomposition technique. After testing a lot of problem instances with time and product decomposition (with different parameter settings), the customer uses now product decomposition. The total run time is 10 hours (including data collection and writing back of the results), pure optimization time is set to 7 hours, since such an amount of time is available. However, good results are already found after approx. 3 hours.
General remark
cost values shouldn„t differ too much range from 1 to 10^6 -10^8 is o.k.
larger differences may lead to numerical problems Central maintenance of costs
-> Master Data -> Supply Network Planning Master Data -> Maintain Costs (Table)
-> Maintain Costs (Directory) Purpose of cost profile:
global weighting of different cost factors
checking global impact of one cost factor on solution, e.g. what is the impact if capacity increases are very expensive
cost values for all corresponding decision variables are changed
to increase/decrease specific values for, e.g., producing/transporting/storing a specific product, the individual PPM/transportation/ storage costs in the master data have to be changed
Costs for increasing production capacities are defined in the resource master data (quantities/rates-definition in capacity variants).
Costs for storage expansion are defined in the resource master (in the same manner as costs for production expansion).
Single-level costs are variable (quantity-dependent) costs which are incurred when using this production process model in one bucket. For each execution of the PPM the single-level costs occur. If, e.g., an PPM is executed 10 times in a bucket, and the single-level costs are equal to 5, then the PPM costs in this bucket are 50.
Multi-level costs are not relevant for the SNP optimizer. They are only used for the scheduling heuristics in PP/DS.
The costs are calculated according to the cost function in the example as follows:
5 + 4*x for 0 < x < 10
15 + 3*(x-10) for 10 < x < 20
20 + 2*(x-20) for 20 < x < 30
25 + 1*(x-30) for 30 < x < 999.999.999,999 where „x„ represents the number of PPM executions per bucket.
Note, that the upper bound of one segment is equal to the lower bound of the subsequent segment. If the number of PPM executions is equal to these bounds, then the cheaper part of the segment is chosen. If in our example x = 10, then the costs will be 15.
In general, the costs are computed as follows:
fix costs + variable costs * (x- „from-value in cost function„)
If you want the optimizer to consider the cost function, you do not only have to maintain it in the PPM, but you also have to activate the corresponding field in the optimization profile. If the cost function for the PPM is used, the optimizer ignores the PPM costs.
Cost functions for transportation and procurement work exactly with the same logic. Again, you have to use the discrete solver if the optimizer should consider the cost functions.
Cost Functions in Inputlog:
// ET_TRANCOS (Transport Cost Functions)
// ET_PRODCOS (Production Cost Functions)
// ET_PROCCOS (Procurement Cost Function)
with
ORIGN: smallest value FIXCO: fixed cost VARCO: variable cost
In example above:
// ET_PRODCOS
// PROID ORIGN FIXCO
VARCO
< PPM name> 0,0000000000000E+00 1,0000000000000E+03 5,0000000000000E+00
< PPM name> 1,0000000000000E+02 1,5000000000000E+03 4,0000000000000E+00
< PPM name> 2,0000000000000E+02 1,9000000000000E+03 2,0000000000000E+00
< PPM name> 3,0000000000000E+02 2,1000000000000E+03 1,0000000000000E+00
Transportation costs are calculated as follows:
Trans. costs describe the variable costs for transporting a product via a transportation lane
per unit of measure.
Mns of Trsp Costs mean the distance-dependent costs of a Transport Method (per km).
The cost function can only be maintained in transaction /sapapo/snpcosf (or: SC Engineer -> Goto -> Cost functions which leads to this transaction).
Transportation costs in Input log: table ET_ARC:
TCTYP: variable transportation cost for the fleet -> calculated as: Mns of Trsp Costs * Trsp distance
table ET_ARCMAT:
TCOST: variable cost for the material at this lane = Trans. costs
Transportation Unit [TRAUNIT] is the unit maintained at the transportation resource and Base Unit of Measure [BMAT] is the unit of measure in the product master. Both have to be maintained
consistently, i.e. in the product master the conversion to the transportation unit has to be maintained. Here, both units are kg.
resulting transportation costs: 180/5000[BMAT/TRAUNIT]*2[APO-$/km]*672,576[km] + 180[BMAT]*100 [APO-$/TRAUNIT] = 18048,425 [APO-$]
The first cost term describes the distance-dependent costs associated with the usage of a transportation resource, the second term describes the quantity dependent costs of transporting the material.
If you don„t have a transportation resource, then the first cost term will simply be multiplied with the transported quantity, i.e. the default value is then 1 transportation unit [TRAUNIT]. In case of a transportation resource this implies that the Mns of Trsp Costsassociate with the complete utilization of the resource, whereas in case of no transportation resource the Mns of Trsp Costsassociate with the base unit of measure of the product.
The first cost term is bucket-dependent, the second one bucket-independent. This means, that the first cost term is taken into account in each bucket. If, e.g., a transport starts in one bucket and ends in the next buckets, then these costs will occur twice, whereas the quantity-dependent cost occur only once. If you use a cost function, then you have to specify variable and fixed costs. Note, that both cost terms are multiplied with the transportation distance. Example: If you have maintained fixed costs of 100 APO-$ and variable costs of 10 APO-$, and a transportation distance of 950 km, then the fixed costs are equal to 95000 APO-$ and the variable costs are equal to 9500 APO-$. You can check this in the Input log of the optimizer, in table ET_TRANCOS. For calculating the cost of a transport, the variable costs are multiplied with the transported quantity.
Procurement costs in Input log: in table ET_LOCMAT:
FCOST: linear procurement cost
Restricted use of shelf life in SNP. Please check notes 574321 (SNP in
general) and 579556 (SNP OPT).
The optimizer only considers shelf life when the flag ‚Plng w/ shelf life„ is switched on in the product master and a shelf life is maintained (Attributes Tab). Additionally, the flag ‚Do Not Take Shelf Life into Account‟ must not be activated in the optimizer profile.
Shelf life violating costs in Input log: in table ET_LOCMAT:
WASFL: flag: shelf life penalty is active -> WASFL = 'X'
WASTE: shelf life: penalty for wasted quantity (same values as for procurement costs FCOST)
Restricted use of shelf life in SNP. Please check notes 574321 (SNP in general) and 579556 (SNP OPT).
Settings:
Do Not Take Shelf Life into Account: the optimizer does not take product shelf lives into
account during optimization, even if the corresponding master data are maintained.
Continue Using Expired Product: the optimizer takes into account the shelf life of
products that was specified in the product master. For expired products (those that have passed their shelf life expiry date), the optimizer plans for the continued use of this product, but calculates penalty costs for this continued use.
Dispose of Expired Product: the optimizer takes into account the shelf life of products that
was specified in the product master. For expired products (those that have passed their shelf life expiry date), the optimizer plans for the disposal of this product, but calculates penalty costs for this disposal.
Use Penalty Csts that are not Prod-Dep.: This indicator can be activated in connection
with either the Continue Using Expired Product indicator or the Dispose of Expired Product indicator. By default, the optimizer considers the location product procurement costs that were defined on the Procurement tab page in the product master. If you want to enter and define different costs that are not dependent on the product, you are able to do this in the
Penalty Costs: Not Product Dependent field. In this instance, you must also activate the Use Penalty Csts that are not Prod-Dep. indicator.
Only the ending inventory for the bucket accrues an inventory cost. If you use cost per bucket, it is harder to adjust the storage cost to balance with the safety stock penalty cost which is
calculated as a cost per day. In addition, using a storage cost per bucket does not account for planning in different buckets – e.g., weekly or monthly planning buckets.
For LPs, it is not necessary to maintain storage costs to get ‚JIT behavior„ of the optimal solution. It is ensured via an internal post processing in the optimizer that planned orders are generated as late as possible to satisfy the demand. This post processing is not active for discrete problems, i.e. storage costs have to be maintained to get this JIT result.
Cost Calculation:
Average Stock On Hand: the optimizer calculates the storage costs by multiplying the following values together:
Stock on hand at the end of the bucket (period)
Storage costs that have been defined for the location product in the product master (in the Procurement tab)
Number of days in the bucket
Stock on Hand at End of Period: the optimizer calculates the storage costs by multiplying the stock on hand at the end of the bucket (period) with the storage costs that were defined for the location product.
Storage costs in Input log: in table ET_LOCMAT
HCOST: storage costs
BUCFL: storage cost: multiply by bucket length = 'X' -> if setting Average Stock On Hand is chosen
Prerequisite in location product master:
maintained safety stock (target safety stock level)
safety stock planning method Take Period Length into Account:
the optimizer also takes the period length into account when calculating the penalty costs for falling below the safety stock, which means that it multiplies the product from an absolute value (or relative value) of the stock fallen below with both the penalty costs and the period length in days. In case of weekly buckets this would mean that the resulting penalty costs would be multiplied with 7 if this checkbox is activated.
If this setting is not active, then the optimizer does not consider the number of days in a bucket (in which inventory is below safety stock).
Safety stock penalty is calculated as:
Take a Relative Deviation from the Safety Stock into Account: the optimizer calculates penalty costs when the safety stock level is fallen below. To do this, it multiplies the percentage of the amount fallen below with the penalty costs that were defined in the product master (per day).
calculation:
safety stock penalty cost * [(target safety stock – inventory)/target safety stock] * (if required) period length in days (number of days that inventory is below safety stock)
Take an Absolute Deviation from Safety Stock into Account: the optimizer calculates penalty costs when the safety stock level is fallen below. It multiplies the absolute value of the amount fallen below with the penalty costs that were defined in the product master (per day).
calculation:
safety stock penalty cost * amount of stock below the desired safety stock * (if required) period length in days (number of days that inventory is below safety stock)
Take Period Length into Account: the optimizer also takes the period length into account when calculating the penalty costs for falling below the safety stock, which means that it multiplies the product from an absolute value (or relative value) of the stock fallen below with both the penalty costs and the period length in days. In case of the example above with weekly buckets this would mean that the resulting penalty costs would be multiplied with 7 if this checkbox is activated.
If this setting is not active, the optimizer takes into account the number of buckets in which inventory is below safety stock.
Safety stock penalty costs in Input log: in table ET_LOCMAT:
The penalty cost for not satisfying the demand is interpreted as cost per unit of demand not satisfied.
The penalty cost for delay is interpreted as cost per unit of demand per day of delay, e.g., if you are working in monthly buckets, then the cost is multiplied by the number of calendar days.
Late Delivery costs, maximum lateness and non delivery costs in Input log:
// ET_DEMCLTIM (Demand Class with Penalty for Delay/Not Delivering)
LAPEN: penalty for lateness
MAXLA: maximum lateness
NDPEN: penalty for not delivering
Demand data in Input log in table ET_DEMAND: DEMCL = demand classes:
1 – highest priority (customer demand)
2 – priority 2 (corr. forecasts)
Resource utilization cost is on the capacity variant 2 of the resource. Capacity variant 2 has to be specified as the active variant of the resource. This works for mixed and bucket resources. For mixed resources, you have access to the capacity variant only if you explicitly enter the bucketed capacities.
Resource utilization cost is interpreted as cost per unit of resource above the capacity variant 1. If you are only using capacity within capacity variant 1, then no costs are considered. In APO 3.x you have to use capacity variant 1 and 2.
Costs for capacity expansion in Input log:
// ET_RESFAMC (Resource Family Calendar)
INCRF: upper bound for increasing production resource
You have to maintain non-delivery or delay costs, otherwise there will be no production at all, since the ´do-nothing-at-all´ solution will lead to minimal costs (=0).
Storage and shipping calendar are only used if the corresponding resources are not maintained. If there is a storage resource, or a handling resources, respectively, then the calendar from this resource will be used by the optimizer.
The same is valid for production resources.
The stock category group from the SNP Tab is not used by the SNP optimizer, and the deployment settings are only used by the deployment optimizer.
The shelf life parameters are on the product master. Shelf life parameter is ‚product specific„ not product-location specific (e.g., the same shelf life at the plant or at the DC). The optimizer only considers shelf life when the flag ‚Plng w/ shelf life„ is switched on in the product master and a shelf life value is maintained (Attributes Tab). Additionally the corresponding setting in the optimizer profile has to be activated. Only the shelf life field is used by optimization, any of the other fields (maturity, min/max shelf life) are not used.
In SNP, only optimization recognizes shelf life. Other SNP solvers and the interactive planning tables do not recognize shelf life. It may be misleading to see stock in the interactive planning table that is no longer useable. Please check notes 574321 (SNP in general) and 579556 (SNP OPT) for more detailed explanations.
The shelf life costs occur in the bucket where the product has to be discarded due to exceeded shelf life.
Shelf life parameters in Input log: in table ET_LOCMAT:
WASFL: flag: shelf life penalty is active -> WASFL = 'X' WASTE: shelf life: penalty for wasted quantity
Production storage capacity is a product specific maximum stock level at this location (per bucket).
The maximum lot size from the product location master is not considered during the optimizer run, but it is taken into account for the creation of orders (in liveCache).
Example: maximum lot size in location-product master data = 500
optimizer creates an order of e.g. 2000 (also displayed in interactive planning table)
4 orders of 500 are shown in the detailed view / product view
Customizing change necessary; ta: SPRO -> APO Implementation Guide -> Advanced Planner and Optimizer -> Supply Chain Planning -> Supply Network Planning (SNP) -> Global Settings for SNP Optimizer: activate checkbox „create orders“, if more than one order should be created, if necessary by location-product master data settings (for details see consultancy note 503222) To consider rounding value as lot size, the flag ‚discretisation„ in the PPM has to be activated.
Additionally, the corresponding settings in the optimizer profile for discretization (min lot size, rounding value) and production storage capacity (general constraints/capacity restrictions: maximum product-specific quantity stored) have to be selected.
Lot Size parameters in Input log:
in table ET_PROMO:
LOTSZ: rounding value or fixed lot size from location product
PMINQ: minimum production lot size (from PPM or location product)
Note: 'PMAXQ' in table ET_PROMO: maximum production lot size (from PPM)
in table ET_LOCMAT:
MAXST: maximum stock
MAXFL: flag: Constraint active -> MAXFL = 'X' (Optimization Profile)
in table ET_LOCPROD:
Within the Production Horizon (in days) / Stock Transfer Horizon (in days) the optimizer does not plan production / transfers. That is, the optimizer does not create SNP planned orders /
distribution receipts within this horizon, but postpones production / distribution to the first day beyond the specified production / stock transfer horizon.
Forecast horizon (in days) defines a horizon in calendar days when the forecast is not considered as part of total demand. Actually, the optimizer does not respect the forecast horizon. If you want it, apply note 412551. Note 443012 has also to be applied, if you are lower than SP17.
Horizons in Input log: table ET_PRODBND for production horizon, table ET_TRANBND for
stock transfer horizon.
It may happen that there is an entry in the input log even if no production / stock transfer horizon is maintained: if you have e.g. weekly buckets, and you run the optimizer on the second day of the week, then no creation of production/distribution orders in this week is possible, i.e. the horizons are active. The same is true for table ET_PROCBND (see below).
Procurement parameters in Input log: in table ET_LOCMAT:
FPERF: procurement type
FCOST: linear procurement cost (variable) SSPEN: penalty for not covering safety stock HCOST: storage costs
in table ET_PROCCOS: procurement cost function
Maintenance in Product Location Master Data -> Procurement Tab, field: Procurement Type E = In-house Production
x = maintained - = not maintained
Maintenance in Product Location master data -> Procurement Tab, field: Procurement Type F = External Procurement
x = maintained - = not maintained
Maintenance in Product Location master data -> Procurement Tab, field: Procurement Type X = In-house Production or External Procurement
P = Procurement Planning: External x = maintained
- = not maintained
GR/GI parameters in Input log in table ET_LOCMAT: RECTI: goods receipt processing time
ISSTI: goods issue processing time
CONIN: consumption of input handling capacity (goods receipt) (if inbound handling resource is maintained in location master data: Resources Tab)
CONOU: consumption of output handling capacity (goods issue) (if outbound handling resource is maintained in location master data: Resources Tab)
CACON: storage capacity consumption (if storage resource is maintained in location master data: Resources Tab)
Example: If the handling resource can handle 1000 kg per day, and you define the handling capacity consumption as 10 kg per piece, the maximum rate is 100 pieces per day.
If you want to consider the GR time for in-house production, then go to APO customizing: supply chain planning -> SNP -> basic settings -> maintain global SNP settings: HEU: Planned Order GR = processing time.
Handling and storage resources in Input log: ET_LOC (Handling resources at a location)
LOCID: Location ID, RESIN: Handling resource ID for inbound
INPEN: Penalty for increasing the handling capacity
MAXIN: Flag: Hard + soft constr. active -> MAXIN = 'X'
RESOU: Handling resource ID for outbound
OUPEN: Penalty for increasing the handling capacity
MAXOU: Flag: Hard + soft constr. active -> MAXOU = 'X' ET_LOCC: Handling resource: normal capacity
MAXHA: handling capacity
ET_LOCUC: Handling resource: additional capacity INCHA: upper bound for increasing the handling capacity ET_SUBLOC (Storage resources of a sublocation)
SUBID: Sublocation ID
INPEN: Penalty for increasing the capacity
MAXFL: Flag: Hard + soft constr. active -> MAXFL = 'X' ET_SUBLOCC: Storage resource: normal capacity
MAXSL: storage capacity
ET_SUBLOCUC: Storage resource: additional capacity INCSL: upper bound for increasing the storage capacity
Over utilization, downtime settings, minimum utilization not recognized by SNP.
There is no cost associated with using the normal capacity. The cost assigned to the resource is the cost per unit of capacity used above the normal capacity (variant 2).
Details about Cross-Period Lot Sizing will follow later.
Production resource in Input log:
ET_RESOURCE (Elementary production resources) RESID, RFAID: Resource ID and resource family ID
UNIVO: Unitary volume (=1.0, redundant entry)
ET_RESFAM (Production resources of a resource family) RFAID: Resource family ID
INPEN: Penalty per unitary volume for increasing capacity
MAXFL: Flag: Hard + soft constr. active -> MAXFL = 'X' (finite capacity)
DISCR: Flag for using discrete increase of resource-family
ET_RESC: Production resource: normal capacity (variant 1 or standard capacity) MAXRE: production capacity
ET_RESFAMC: Production resource: additional capacity (variant 2) INCRF: upper bound for increasing the production capacity
From an economical viewpoint it is sometimes sensible to require a minimum resource utilization even if the demand is not sufficient. We use capacity variants to model the utilization, and the SNP optimizer then takes them into account. If the utilization is below the minimum then the optimizer considers costs, i.e. the minimum capacity is a soft constraint. The minimum, the normal and the maximum resource consumption are realized as capacity variants of a resource.
In the capacity view of SNP planning book three capacity variants are shown. The minimum resource capacity will be shown in the new key figure SUPVAR3. The minimum resource capacity is computed by macros according to the macros of the first two resource variants (SUPVAR1 and SUPVAR2).
The choice which product(s) are selected to load the resource up to the desired (minimum) capacity depends on the overall cost situation. The decision is made in the way that the total costs are minimized.
Calculation of costs
Non-utilization (minimum capacity)
(minimum capacity – used capacity) * costs for falling below minimum capacity = (8 – 6) * 100 = 200
Resource utilization
MIN(used capacity, normal capacity) * costs for used capacity = MIN(12,16) * 1 = 12
Increased utilization (maximum capacity)
(used capacity – normal capacity) * costs for increased capacity = (22 – 16) * 10 = 60
+ Resource utilization costs = 16
For further information refer to the PDS guide in the Manufacturing section of the service marketplace.
The PPM duration is important for the finish date of an activity. Together with the bucket offset, the PPM duration determines the material availability.
The optimizer takes the fixed resource consumption only in account when the corresponding setting in the optimization profile is activated (discrete constraints: fixed consumptions: fixed material and resource consumption).
The minimum lot size is always the minimum lot size per BUCKET. This is also true for minimum transportation lot sizes.
The lot size is always the lot size per BUCKET. This is also true for transportation lot sizes. The maximum lot size is always the maximum lot size per WORKING DAY. This is also true for maximum transportation lot sizes.
Note that both, minimum and maximum lot size in the PPM, refer to the unit of measure of the location product, not to the unit of measure of the output component in the PPM.
Note 503222 describes how order splitting can be activated. In APO 3.0, you have to use an copt10 parameter, in APO 3.1 and 4.0, you can customize this.
Note that SNP heuristic and CTM only use the min./max. lot size from the location product as min./max lot sizes. The min./max. lot size from the PPM only determines the validity of an order.
Example: if there is only one PPM (or one means of transportation) with a min. PPM (transportation) lot size of 5 and a max. PPM (transportation) lot size of 10 to produce
(transport) a specific product, and we have an order/demand of 2 or 20, respectively, then this order/demand cannot be satisfied, since no valid procurement source exist to produce/procure this product.
Note: Rounding value, fixed lot size and Lot-for-Lot are only considered with selected discretisation in PPM and corresponding setting in the optimization profile.
Minimum lot size is only considered if the corresponding setting in the optimization profile (discrete constraints) is selected.
Maximum lot size in location product master is only considered for the determination of the planned production order, i.e. the produced quantity is split in planned production orders in the size of the maximum lot size in the location product master (or less). In AP0 3.0 it is only done, if all PPM of the selection have no "fixed resource consumption". If you don't want this splitting in any case - it can be switched off (see note "503222 Info on Optimizer Production Order Splitting").
Recommendation for maximum PPM lot size: If you have no specific "maximal lot size" for your PPM, don't enter a value like 9999999999 in this field. This could lead to problems in the floating point precision during optimization, i.e. it could provoke bad results and a bad performance of the SNP optimizer. In this case we recommend a value that is around
10% - 20% higher than the maximum that could be produced in one day. If a rounding value is used, then the maximum lot size should be a multiple of the rounding
value. Using the rounding value requires that Lot-for-Lot in the location product master is activated.
Output quantity means the production (planned) as displayed in the interactive planning table. The planned production in the optimizer log file describes the number of PPM executions and it can be different.
Consulting Notes: 503294 (Info on Optimizer Production Lot Size), and 448986 (Info on Optimizer Lot Sizes, collection of related notes).
Note:
If fixed lot size is maintained in location product master, then it overwrites the minimum lot size from PPM, i.e. PMINQ.
In both cases, the minimum and maximum lot sizes are not relevant, e.g. PMINQ = 0, PMAQ = 1000.
Examples illustrates interpretation of rounding value and material consumption in PPM. Note that in the first case the output rate (OUTIN) displayed in the input log is still equal to 7, but internally, the optimizer calculates with an output rate of 11.
Definition of Lot Size Profile for Transportation Lanes:
Supply Network Planning-> Environment -> Current Settings ->Profiles-> Define Supply Network Planning Lot Size Profiles (Transportation Lanes)
Example for discrete transportation method (= truck):
demand at a DC: Product A: 8 tons; Product B: 8 tons capacity of a truck: 10 tons
solution without discretisation: transportation of 16 tons solution with discretisation: planned transport of either
10 tons with 1 truck and 6 tons backlog for one of the products (for which product a backlog is created, depends on the late delivery penalty and non-delivery costs). Here transportation costs are incurred for one a full truck
or
8 tons for product A and 8 tons for product B (with 2 trucks). Here, transportation costs are incurred for 2 full trucks.
The actual result depends on the cost and master data (late delivery penalty, non-delivery costs, storage costs, warehouse capacities, and so on).
To activate discrete transportation fleets, the corresponding setting in the optimizer profile has to be selected (-> transports). Additionally, the checkbox DiscrTrMet has to be selected at the corresponding transportation lane.
To activate minimum lot sizes, the corresponding setting in the optimizer profile has to be selected (-> Transp lots).
To activate the maximum lot size, the corresponding checkbox in the optimizer profile has to be selected.
To get integer lot sizes, the following setting in transaction /sapapo/copt10 has to be entered:
Section: SNP
Name: DISCRETETRANSPORTLOTHORIZON
Switch: INTEGER
Integer Column: <number of discrete buckets>
Capacity Consumption (TCONA) describes how much capacity is used by transporting the material at this lane.
The available capacity can be found in table ET_FLEET, column TUNIA. The penalty costs for increasing the capacity are displayed in column INPEN. MAXFL describes whether the capacity is finite (-> X) or infinite.
Additional entries in Input log:
ET_FLEETC: Fleet resource: normal capacity
MAXFL: capacity measured in trucks
ET_FLEETUC: Fleet resource: additional capacity
Bucket-Offset (BO) controls the material availability in a bucket. Values between 0 and 1 can be entered.
Counterpart in optimization profile: ´rounding limit´ for production (value: 0-100%). But bucket offset from PPM is leading, i.e. if you have entered a value there, the rounding limit from the optimization profile is not considered.
Additional example: if this bucket offset factor is set to 0.5 and the optimizer is ran for monthly buckets: If the duration of the operation is less than 15 days (half the month), the material output from the operation will be available for the subsequent operation in the same month. If the duration is more than half a month, the output will only be available in the next monthly bucket. For the first scenario, the first and following operation will be scheduled in the same month. But note that since the optimizer works in buckets, both operations will have a start date set to the first of the month - not scheduled in sequence.
Notes:
Breaks (e.g. weekends) extend the length of a PPM duration
If PPM exceeds the bucket length, then the number of days in the bucket in which the PPM is finished, is relevant for the calculation.
Definition of Quota Arrangements in Master Data (transaction: sapapo/scc_tq1). Optimizer Profile:
Multiple quotas: either consider first or consider last
Defines how the Optimizer in Supply Network Planning (SNP) proceeds, if multiple quota arrangements exist for a particular period: You define that the optimizer considers the first or last quota arrangement in a period. The optimizer then ignores the remaining quota arrangements within this period.
Not maintained: treat as zero or ignore
Defines how the optimizer in Supply Network Planning (SNP) proceeds if quota arrangements have not been defined for all relevant sources of supply:
Treat as Zero: The optimizer does not plan any stock transfers from the sources of supply for which no quota arrangements have been defined.
Ignore: The optimizer plans stock transfers from all relevant sources of supply. Quota arrangements are considered for those sources of supply where they have been defined. Product-Group Assignment in Product Master data (Tab: Properties 2)
Quota arrangement constrains the total receipt of all products within the group at the given location only.
All three methods arrive at an optimal solution. The main difference in the application of these methods may be the runtime. There is no general rule known for selecting the best method for a given problem (except testing each one of them). A good measure for the application is benchmarking on a test scenario because the optimal choice of the method depends mainly on the structure of the supply chain and less on the given input data. Therefore, in a productive environment, daily benchmarking is not necessary.
Window size defines the number of periods which are fixed after each single run. In the example above, it is set equal to 3.
Standard settings / Default values:
window size is defined by the user (should be as large as possible)
overlap = window size/2 (non integer numbers are rounded down)
aggregated = remaining periods are aggregated to one bucket
Example: 52 buckets, window size = 26 => delta = 13, aggregated = 1
=> problem with 40 buckets is considered in the first optimization run
With transaction /sapapo/copt10 you can change these standard settings (Section: SNP_TIMEDECO)
parameter „MinOverlap„ defines the overlap/delta (in the example above it is equal to 3) parameter „DiscreteOverlap„ defines the discrete overlap (which is equal to 2 in the example).
It has to be defined smaller than or equal to MinOverlap. If not, it will be set equal to Min Overlap.
parameter „AggregationWindowSize„ defines how many of the remaining buckets are
aggregated into one bucket (in Example = 4)
„SWITCH“ for all parameters: Integer
Don„t change default values without talking to development/expert optimization consulting.
planning window defined by the material flow: consider all resources, intermediate materials and activities which could be used to produce a given product
reduction of complexity by considering only a subset of the materials as well as only the subset of other entities that have to be considered for these materials (e.g. resources, transportation lanes)
after each run for a sub-problem, capacities are reduced according to the individual solution, and these solutions are aggregated iteratively to a consistent solution for the whole problem
window size represents the %-value of the model size which are considered in one sub-problem (single LP run)
gliding window approach => overlaps between sub-problems (only a part of the solution of a specific sub-problem stays fixed)
Column 1 and 2 are defined by the user, taken from the prioritization profile
Column 3 results from the Bill of Materials in the PPM (or PDS). From this
BOM we get the atomic sub-problems.
Sub-problem 1 is resulting e.g. from the fact that P2 and P3 are input components to produce the output component P1.
Step 1:
Column 4, i.e. the priority for the product decomposition, is then derived from the priority of the sub-problems.
Step 1:
Column 4, i.e. the priority for the product decomposition, is then derived from the priority of the sub-problems.
Step 2:
Step 1:
Column 4, i.e. the priority for the product decomposition, is then derived from the priority of the sub-problems.
Step 2:
For sub-problems with DIFFERENT priority, there is definitely NO overlap (step 2). Step 3:
For sub-problems with the SAME priority, the standard sorting is used. E.g. if a partitioning parameter (window size) of 99% is used, all sub-problems are solved together, if a window size of 0% is used, they are all treated separately.
The iteration limit (number of improvements) should only be used for test purpose: specify an iteration limit of 1. Solve the discrete model without a runtime limit with full search. That will give you an estimate, how long the optimizer will take to find the first feasible
solution.
Note: changes in the model and/or changes in the demand pattern and quantities may
implicate a big difference for the time to solve the model!
Disable the iteration limit (set it to 0) and use a reasonable runtime limit instead (take the time you gathered during the tests with the iteration limit =1 into account and multiply it by e.g. 2) and solve the model.
Example: Take the Minimum PPM Lot Size into Account
If you have chosen the discrete optimization method, you can specify in this field that you want the optimizer to take into account the minimum lot size (that was defined in the production process model (PPM)) when running the PPM.
You can define the horizon for which you want this discrete constraint to be considered. You can either define a specific horizon (in days or weeks, for example), or specify whether the discrete constraint should be considered across all daily buckets, or across all daily and weekly buckets, and so on, based on the buckets defined in the planning buckets profile. The discretization horizon starts from today's date, even if the planning horizon starts in the future or the past.
Dependencies
You must activate Discrete Optimization in the optimizer profile header data.
You must define the minimum lot size in the PPM.
If a larger minimum lot size has been defined in the location product master, the optimizer takes into account the value from the location product master, even if this indicator is activated.
Detailed discretization for different restrictions for daily, weekly or monthly buckets (analogously for quarterly or yearly buckets)
If SNP - time buckets consist of weeks and ´days´ is chosen as detailed discretization, then in the optimization run this choice is ignored and there is no discretization at all. Analogously for monthly SNP bucket sizes: if ´days´ or ´weeks´ are activated in detailed discretization, then there are no discrete variables.
Discretization in Input log:
DISCM Discretization algorithm: K, P or V
DITER Discr.: Maximum number of iterations
DLAUF Discr.: Maximum runtime in seconds
DTRUN Discr.: Rounding-limit transportat. variables
DPRUN Discr.: Rounding-limit production variables
DISRF End bucket for increasing prod.res. discretely
DISRZ End bucket for using fix prod.res. consumption
DISTR End bucket for using discrete fleet on lanes
DISPR End bucket for using a discrete PPM
TRLOS End bucket for using transport lots of material
PRLOS End bucket for using production lots
COSTR End bucket for using transport cost function
COSPD End bucket for using production cost function
Examples:
10 D => first 8 buckets are discrete, since days 8-10 fall in the first weekly buckets; afterwards no discretization
3 Z => first 21 days are discrete; afterwards no discretization
7 Z => first 49 days are discrete; afterwards no discretization
With strict prioritization you can assign the priority of safety stock to one of the three demand classes. This is only possible for LPs.
Calculation of profit simply means to multiply the fulfilled demands of all products with the corresponding non-delivery costs and subtracting the costs from this value.
Example: 1 Product with non-delivery costs of 10,000 APO-$ and a demand of 100. The costs for producing, transporting and storing this product is 50,000 APO-$ (this is the result which you will get if calculation of profit is not activated). Then, the profit is equal to 1,000,000-50,000 =
Average Stock On Hand
the optimizer calculates the storage costs during planning, by multiplying the following values together:
Stock on hand at the end of the bucket (period)
Storage costs that have been defined for the location product in the product master (in the
Procurement tab page)
Number of days in the bucket Stock on Hand at End of Period
the optimizer calculates the storage costs during planning, by multiplying the stock on hand at the end of the bucket (period) with the storage costs that were defined for the location product on the
