Enhancing the DS Optimizer

You can incorporate special constraints or specific requirements into the optimization data that is sent to the optimization algorithm via a Business Add-In (BAdI). You can use the Business Add-In /SAPAPO/CDPS_OPTDATA (user changes to optimization data) to change the planning data from the optimizer as required. At the start of the optimization run, the optimizer downloads the planning data from the SAP liveCache and uploads it to the liveCache again on completion of the optimization run.

The BAdI does not execute any consistency checks of the user-specific changes. This means that every one who implements the BAdI is responsible for ensuring the consistency of the changed data. The BAdI provides the following methods:

• SET_BEFORE_DATA_DOWNLOAD: Accessed before the data collection process.
• SET_AFTER_DATA_DOWNLOAD: Accessed after the data collection process.
• SET_BEFORE_DATA_UPLOAD: Accessed before recording the data in the liveCache.
• SET_AFTER_DATA_UPLOAD: Accessed after recording the data in the liveCache.

To activate the Business Add-In, you must create an active implementation.

You can use this BAdI to change the planning data after the download and before the start of the optimization run. The largest number of uses of this BAdI are available by using the method SET_AFTER_DATA_DOWNLOAD. This method can be called after the data collection process. The planning data can be changed, for example, in the following ways before the optimization run:

• Changing the pegging structure: Should you require a special pegging result for an optimization process, it may be necessary to change the pegging amounts of the receipt and requirement elements using a heuristic. One option is to create this special pegging structure using a fixed pegging heuristic. However, you can also change the pegging structure locally for the optimization call. If you do not require the pegging structure in the application, you can run the optimizer without using a special heuristic and implement your logic in the BAdI.
• Changing order priorities: It may be necessary, to change the priorities for the optimization run only but not in the system. You can use this BAdI to change the priorities after downloading the planning data from the SAP liveCache.
• Changing requirements and deliveries data: It may be necessary to consider extra buffer for a material in the optimization run depending on the current planning situation. It may also be necessary to separate the buffer from the current planning situation, such as the pegging situation. You can use this BAdI to simulate this buffer by changing the data of purchase requisitions, forecasts or sales orders. This data is only changed in the optimization data and not in the system data. This avoids any falsification of the actual planning situation.
• Ignoring constraints or orders: Some complex scenarios cannot be processed in one planning step. Therefore, it may be necessary to reset constraints and restart a new optimization run to take any reset constraints into account. You can use this BAdI to execute such a reset after downloading the planning data.
• Influencing the optimization result per pegging area: You can use the table ET_PEGID_AVAILDATE to influence the optimization result in two ways: You can define your own replenishment lead time for components produced in-house and components procured externally. Optimization then takes this user-defined replenishment lead time into account as the planned delivery time or in-house production time for missing components for which the system has not created any receipt elements. In this way the system avoids a situation where superordinate orders are scheduled too early. As a prerequisite, you must have set the Consider Planned Delivery Time indicator in the optimization profile. It is possible to exclude certain pegging relationships from the optimization problem. To do so, a setting must be made for the pegging area. Once this setting has been made it is no longer necessary to exclude each individual pegging relationship from the table ET_PEG_INFO.
• Changing the planned delivery times: You can use the table ET_BANF_SCHED_TIME to change the planned delivery times per purchase requisition. Optimization then uses the planned delivery times defined by the user. As a prerequisite the Consider Planned Delivery Time indicator in the Optimization Profile must have been set.
• Synchronizing orders: You can synchronize the start or end of orders by adding (external) relationship links between activities of different orders. Assume, that you have orders for tables and chairs and you typically sell them in bundles (one table and four chairs). Then you may want to also produce them for example on the same day. In this case, you can create a maximum relationship link between the table order and the chair order with a maximum of 24 hours.

Enhancing the data sent to the optimizer or changing the data returned from the optimizer provides you with a powerful option to include specific planning constraints that cannot be modeled in the application itself.

You can activate more features of the DS optimizer by specifying parameters in transaction RCC_PARAM. These parameters control the behavior of the optimizer and are typically recommended to you via support incidents or expert consulting (SAP Note 689101), if your business scenario or planning problem requires special features that are available in the optimization algorithm, but for various reasons not available in the optimization profile. Reasons why these parameters are not publicly available include that these parameters may not resonate with specific other settings or only work in special situations, such that a general application could do more harm than good to the solution quality of the algorithm. Therefore, these parameters should always be used with caution.

How these parameters must be maintained in the system is explained in SAP Note 578044. Each line in the table maintained in transaction RCC_PARAM represents a parameter that is transferred to the optimizer as an extra parameter. The following information is required for each parameter:

• Application

  Using the Appl. attribute, select the application in whose optimizer you want to add the extra parameter. The relevant applications are DPS for the DS optimizer and PPO for the PP optimizer.

• Optimization Server

  If the parameter should only be relevant for a specific optimization server, you can select a connection to a suitable server under the Dest. ID attribute. The default for DS optimization is DPS01 and for PP optimization PPO01. If you do not select an identifier, the parameter is sent to all optimizers of the relevant application.

• Dependency on profiles

  A parameter is always sent to the optimizer if no profile is specified. If the parameter has a profile and an optional Customizing ID, the parameter is only sent to the optimizer if the optimizer is called with this profile. SAP Note 924973 describes how wildcards (*) can be used in the profile name to be able to address several profiles at once.

• Parameter structure

  A parameter is identified using the two entries Section and Name. The Section is often described with square brackets. For example, [dps]DummyParameter describes the parameter with Section="dps" and Name="DummyParameter". A type specification is also set for a parameter in the Switch attribute. In this attribute, the parameter can be specified as a string, a Boolean value, a floating point number, or an integer.

• Parameter value

  To assign a value for the parameter, enter a value in the fields Char. string, Integer, or Float. Pnt, depending on the type specification. If the type Boolean is set, use the Char. string field. "X" stands for true and no entry stands for false.

  The system does not make a distinction between uppercase and lowercase characters in the Section, Name, and Char. string fields.

• Short text

  You can also add a short text to the parameter. This is for maintenance purposes only and is not analyzed by the system.

For example, if you are asked to add the integer parameter [da]answer=42 to each PP/DS optimization call and you only use one optimization server in its default state, then insert a line with the following values:

Module: DPS (check F4-value help)

Identifier: DPS01 (check F4-value help)

Section: da

Name: answer

Type: Integer

Integer: 42

Some of these parameters are explained here.

The first parameter addresses the following need. One of the objectives of the DS optimizer is the minimization of setups. Therefore, the optimizer tries to calculate a good setup sequence for most of the run time of the algorithm. However, sometimes it is also important that orders are not scheduled too early regarding their requirement date. In this case backward scheduling can be activated in the optimization profile. The figure illustrates such a case. In the first chart, orders are sequenced as early as possible in the optimal setup sequence. However, most orders are scheduled too early in this solution. The second chart illustrates a solution, in which all orders are scheduled closer to their due dates, but not in their optimal setup sequence.

The question is: Should the backward scheduling algorithm be allowed to move orders from their "good" setup position to their "better"(?) due date position? With standard settings, the backward scheduling is not allowed to deteriorate the setup sequence. With this parameter, you can allow this with the value of the parameter being a measure of the extent that the setup sequence can be deteriorated by backward scheduling.

The parameter is defined in RCC_PARAM as follows:

Module: DPS

Identifier: most likely DPS01 (check F4-help)

Profile/Cust ID: Fill in the name of the optimization profile to restrict that the parameter is only used when the optimizer is called with that profile.

Section: dps_jit

Name: WorsenSetupPerAct

Type: Float

String/Integer: leave empty

Float: The higher the value, the more setup deterioration is expected.

Another parameter can be used to define what should be the source of the priority, if the algorithm is to optimize different delay costs based on order priority. The default behavior is that the DS optimizer uses the priority of the pegged requirement element, for example, it uses the priority of the customer (sales) order to calculate the delay of a planned or production order. With this parameter being active, you can change this behavior to use the priority of the production order instead, if you want to prioritize production orders directly.

The parameter is defined in RCC_PARAM as follows:

Module: DPS

Identifier: most likely DPS01 (check F4-help)

Profile/Cust ID: Fill in the name of the optimization profile to restrict that the parameter is only used when the optimizer is called with that profile.

Section: dps_livecache

Name: ConsiderCustomOrderPriority

Type: Boolean

String/Integer/Float: leave empty

The final parameter that is explained in this context is a parameter to define that activities should be rescheduled by the optimizer even if they are not completely inside the optimization horizon. The standard behavior of the optimizer is to only reschedule those activities that are completely within the optimization horizon. If you want to reschedule in addition activities that are partially inside the optimization horizon, but that end after the end of the optimization horizon, you can use this parameter.

The parameter is defined in RCC_PARAM as follows:

Module: DPS

Identifier: most likely DPS01 (check F4-help)

Profile/Cust ID: Fill in the name of the optimization profile to restrict that the parameter is only used when the optimizer is called with that profile.

Section: dps

Name: DeleteRightBorder

Type: Integer

Integer: 3

String/Float: leave empty