Flexible Proposal of Requested Delivery Dates
Since 2011CE, a new flexible solution to propose the default requested delivery date has been delivered in customer’s system. In this document, you will know how to propose a default requested delivery date of sales order using CPF (Configurable Parameter and Formula) framework.
1. Requested Delivery Date
Requested delivery date is the date when can decide the when to deliver the product to customer. It can be determined when creating sales documents. The default date is calculated by leading days, which can be defined in the configuration ‘Configure Sales Document Type’, e.g.:
Leading days definition per order type:
| Order Type | Leading days |
| OR | 5 |
| QT | 7 |
Requested Delivery Date on Sales Order Header:
If you want to use the requested delivery date with more flexible way not only focus on the lead time in days of customizing, there is no such configuration available in system.
2. CPF Framework
CPF (Configurable Parameter and Formula) is a framework to create flexible formulas to calculate the requested delivery date default. CPF allows to specify defaulting rules based on a broad set of parameters in addition to the order type.
Using the CPF framework, you as a configuration expert can define rules that the system uses to determine requested delivery dates for sales documents. These rules enable a flexible calculation of the requested delivery date from the factory calendar, the lead days, and the processing indicator that are controlled by one or more header fields of the sales document to be created.
3. Implementation of CPF
By mapping a formula ID to a routine number, then mapping the routine number to a sales document type, each sales document type that requires the dynamic requested delivery dates can be assigned to a different set of rules. You maintain these rules within the decision table of the formula.
The following figure shows an overview of how three different sales document types could be mapped to three different routine numbers, which in turn are mapped to three different enhancement IDs. In each case, as the enhancement ID you enter the formula ID of the formula containing the target decision table. Doing so facilitates the intended mapping between a routine number and a specific set of numbering rules within the decision table. Fore example,
To generate a decision table with flexibility, a set of customizing shall be implemented in system:
- Define Rules to Determine Factory Calendar
- Define Parameter Catalog for Requested Delivery Date
- Define Formulas for Requested Delivery Date
- Define Custom Routines for Requested Delivery Date in Sales Documents
- Assign Custom Routines to Sales Document Type
3.1 Input Parameters and Result Parameters
The rules in the decision table determine the correct calendar rule, lead days, and, optionally, processing indicator for a given sales document type by evaluating whether specific sales document header fields (represented in the formula as input parameters) satisfy conditional rules that you have specified within the rows of the decision table. The decision table can evaluate the following sales document header fields:
- Distribution channel
- Division
- Sales document type
- Sales group
- Sales office
- Sales organization
·
Please Note:
SD document category B, C, and I are taken into the implementation of CPF, other document categories are not considered in CPF.
Any custom field that has been added to the sales document header through extensibility (business context Sales: Sales Document)
You can configure the parameter in Manage Your Solution app under Configure Your Solution with path: Sales->Sales Order Management and Processing->Custom Adaptations for Requested Delivery Date-> Define Parameter Catalog for Requested Delivery Date.
3.2 Define Formulas for Requested Delivery Date in Sales Documents
A formula consists out of a set of freely configurable parameters which are needed for the execution of the formula and a set of (usage-dependent) tasks, defining what is supposed to be done. The formula-specific implementation of a task, the CPF Routine, is then the logic to be executed.
A formula contains the steps:
- Define formula ID
- Assign formula parameters
- Define usage tasks to formula
- Assign parameter priority
- Define decision table
Finally, a decision table would be generated, to determine the leading days which can be calculated to one requested delivery date when creating the sales order.
You can configure the parameter in Manage Your Solution app under Configure Your Solution with path: Sales->Sales Order Management and Processing->Custom Adaptations for Requested Delivery Date->Define Formulas for Requested Delivery Date in Sales Documents
3.2.1 Define Formula
In step ‘Define Formula ID’, you can create one formula for your scenario.
3.2.2 Assign Formula Parameters
Once formula is created, the importing parameters can be assigned to it, these assigned parameters can set the priorities to generate the decision table. The importing parameters are defined in customizing ‘Define Formulas for Requested Delivery Date in Sales Documents’.
3.2.3 Formula Tasks
In step ‘Formula Tasks’, the usage task ‘SET_REQD_DELIV_DATE’ is defined as default, this task can be used to active the CPF Routine. You can assign the parameter with priorities to this formula task.
3.2.4 Assign Parameter Priority
In step ‘Assign Parameter Priority’, set the priorities of parameter which are assigned in formula parameters. These priorities can decide the displayed sequence of decision table.
3.2.5 Define Decision Table
In this step, decision table can be generated automatically when parameter priorities are assigned. As default, Decision Table contains the columns which can determine the leading days, it can define the leading days base on parameters, factory calendar rule and Processing indicator. E.g.:
Generated Columns:
- Sales Organization
- Sales Document Type
- Distribution Channel
- Division
Default Columns:
- Leading Times in Days(leading days)
- Processing Indicator
- Factory Calendar Rule
You create your decision table by creating one table row per rule that you want the system to evaluate based on the parameter values. Each row represents a rule that the system uses to propose requested delivery dates. Each rule is a conditional expression that specifies values for some or all of the input parameters, as well as for the result parameter REQD_DELIV_DATE.
Through the input parameters, the system compares the header fields of the sales document that is being created to the values you have maintained in the decision table. It processes the rules in the decision table sequentially from top to bottom. For each parameter, you can specify an operator as follows:
- Operator = (Equal to)
If this operator is set, the system considers the corresponding parameter as a hit if the parameter value provided by the sales document field is equal to the value you have specified in the corresponding column of the decision table. If every parameter in a row provides a hit, the rule represented by the row is applied and lead time in days, factory calendar rule, and processing indicator for incoming requested delivery date are assigned according to how they are specified in that row in result subparameters.
- Operator (Do not consider)
If the operator cell is left empty (‘blank/space’), the corresponding parameter is ignored during the evaluation of that row, that is, the parameter cell is treated as a wildcard. This setting is useful when you want to treat a parameter for which ‘blank/space’ is a valid value as a wildcard.
After you have entered the rows representing the rules that you want to evaluate, the system automatically orders them based on the priority that you have assigned to each parameter in the previous step. To achieve the final order, the system sorts the rows as follows:
- First, the rows are sorted according to the parameter with the highest priority (that is, the parameter in the left-most column). Rows in which a specific value (as opposed to a wildcard) is filled for this parameter rise to the top.
- After this initial sort, the same principle is applied for the parameter with the second highest priority (second column from the left) to establish the relative order of the rows within the overarching order established by the previous sort.
- This process is repeated for each subsequent parameter to establish the final order of the rows, which ultimately dictates the sequence in which the system processes the rules that you have specified.
The system then sequentially processes the rules by comparing the supplied input parameters against the conditions defined in the rules, starting with the first row and ending with the first hit. If there is no hit, processing ends at the last row without any rule being applied.
All cells are evaluated by checking the column value against the corresponding parameter value. For each cell, a boolean result is returned. If all cells in a row are evaluated as true, the evaluation stops and the system returns the result subparameter as specified for the current row. Otherwise, processing continues with the next table row until either a matching set of conditions is found or the end of the table is reached.
Example
You fill a row so that for any sales document of type OR (using operator 😃 created for sales organization 1000 (using operator =), the system assigns 5 days as lead time with calendar rule X1.
The next row, however, assigns sales documents of type OR (operator 😃 of any sales organization (no operator, that is, wildcard, and empty parameter cell) to 10 lead days with calendar rule Y2 and indicator A.
The third row assigns sales documents of any sales document type (no operator, empty parameter cell) of sales organization 2000 (using operator 😃 to 15 lead days with calendar rule Z3 and indicator B.
If no rule is satisfied and the end of the table is reached, the standard procedure for the proposal of requested delivery dates is used. In an actual decision table, these three rows would look as shown in the following table:
Input Parameters | Result Parameters | |||||
Operator | Sales Document Type | Operator | Sales Organization | Lead Days | Processing Indicator | Calendar Rule |
= | OR | = | 1000 | 5 | X1 | |
= | OR | 10 | A | Y2 | ||
= | 2000 | 15 | B | Z3 | ||
3.2.5.1 Factory Calendar Rule
A factory colander rule can be assigned in decision table to take the working days into the lead days, please refer to different rules in setting chapter 3.3
3.2.5.2 Processing indicator
The processing indicator is used in API process, in general, the requested delivery date can be passed in the message payload, and this passed value will drive the requested delivery date when API call is finished, and sale order is created.
Usually, the date in API has the higher priority, however, the CPF based requested delivery date can overwrite the passed requested delivery date in API payload. Processing indicator has 3 values:
Blank – no process
A – overwrite the incoming date without message
B – overwrite the incoming date with message
With above combination, there are rules to determine the date on sales order, let’s use date1 (Requested date passed in API) and date2 (Requested Delivery Date calculated by CPF) as example:
- If date1 >= date2, then use date1 to determine the requested delivery date
- If date1 < date2, then check the indicator:
o If indicator is blank, then use date1 to determine the requested delivery date
o If indicator is A, then use the date2 to determine the requested delivery date
o If indicator is B, then use the date2 to determine the requested delivery date and return the message in response payload.
You can also refer to table:
| Date in API | Date from CPF | Requested Delivery Date on Sales Order | Processing indicator |
| 2020.10.20 | 2020.10.19 | 2020.10.20 | Blank/A/B |
| 2020.10.19 | 2020.10.20 | 2020.10.19 | Blank |
| 2020.10.19 | 2020.10.20 | 2020.10.20 | A/B |
3.3 Factory Calendar Rule
The leading days can be calculated as working days. In order to determine the relevant factory calendar for the working day-based calculation. a factory rule needs to be set up. The rule specifies the priority to check and select the relevant factory calendar.
For Example:
The system checks in below sequence:
- Factory calendar is determined from the factory calendar in the sales organization as priority.
- If no factory calendar is found in sales organization, then factory calendar is determined from the factory calendar which is maintained in the customer master of the sold-to-party.
- If no factory calendar is found in the customer master data, the system finally uses the factory calendar which is defined in the calendar rule.
You can configure the parameter in Manage Your Solution app under Configure Your Solution with path: Sales->Sales Order Management and Processing->Custom Adaptations for Requested Delivery Date->Define Factory Calendar for Sales Documents
3.4 Define Custom Routines for Flexible Requested Delivery Date in Sales Documents
A customer routine is entrance to enable the Formula of CPF framework, you can define new routine numbers and then assign enhancement ID to the defined routine. You can choose the default Process Enhancement Option task and select the Implementation Type B – Configurable Parameters and Form.
Please Note: Customer routine number only support the range from 3000001 to 3009999.
You can configure the parameter in Manage Your Solution app under Configure Your Solution with path: Sales->Sales Order Management and Processing->Custom Adaptations for Requested Delivery Date-> Define Custom Routines for Requested Delivery Date in Sales Documents
3.5 Assign Custom Routines to Sales Document Types
Once the customer routine is defined, it can be assigned to one sales document type, to enable CPF rules in sales document processing, the custom routine defined in previous step shall be linked to the sales document type.
The customer routine can be assigned to the document type with Categories:
- Sales Order
- Sales Order without Charge
- Sales Quotation
Please note: this input fields won’t be editable for other document categories. Currently SAP only support above three categories.
You can configure the parameter in Manage Your Solution app under Configure Your Solution with path: Sales->Sales Order Management and Processing->Sales Documents-> Assign Custom Routines to Sales Document Types
4. Requested Delivery Date in UI
Once you finish the customizing for whole CPF set up, you can create a sales order and verify the configuration, when you go the app ‘Create Sales Order’.
Let’s refer to a decision table in customizing of formula:
The customizing in ‘Configure Sales Document Types’, the leading time in days is:
Therefore, when you create one sales order on 2020.09.16, the requested delivery date is filled with default setting, and CPF is not enabled yet, the date is 2020.09.16 + 5 = 2020.09.21:
Now you can input one input the sold-to party which can determine the sales organization, distribution channel and division, the formula for determining requested delivery date is triggered, and leading days in CPF decision table would be used to calculate the delivery date.
Now, the requested delivery date is determined successfully according to your setting of CPF, as described, it's also possible to configure the custom fields into the parameter catalog and formula, then you can manage or derive the requested delivery date with more flexible way.
- SAP Managed Tags:
