7 Working with Firm Demand
This chapter contains the following topics:
7.1 Understanding Firm Demand
Firm demand requirements represent demand for material that is required for a specific future time horizon. When you create and process records for firm demand, the system uses this information to maintain the requirements, scheduling and fence information, rules, and other default information that is relevant to suppliers and customers.
For example, you can create planning schedules that enables you to retrieve plan or firm demand, and, based on fences, the system determines whether to process the data as sales orders or forecast records. You also specify how to process cartons, labels, shipments, notifications, and run reports to analyze demand information.
7.2 Understanding Shipping and Planning Schedules
When you run the Create Demand Schedule (R40R010), the system creates shipping and planning schedules based on the information stored in the demand and cumulative databases. These schedules enable you to retrieve plan or firm demand, and, based on fences, the system determines whether to process the data as sales orders or forecast records. The system also performs calculations for ahead/behind amounts, rounding to standard pack, and updates the Create SO Status field (CRTSOST) on the demand detail record.
The system uses the cumulative ID to identify demand detail records. This table describes how the system selects records for processing schedules:
| Cumulative Tracking Method | Process |
|---|---|
| Sold To Level | For each cumulative record associated with the Sold To field (where the Ship To field is blank), the Create Demand Schedule program processes all the demand details associated with the cumulative ID for that record. |
| Sold To and Ship To Level | For each cumulative record associated to the Sold To and Ship To, the Create Demand Schedule program processes all the demand details associated with the cumulative ID for the record. |
| None | If the customer (Branch Plant, Sold To, Ship To combination) does not calculate cumulative information, the Create Demand Schedule program processes all the demand details for that demand header record that do not have a cumulative ID. |
The system can decrement cumulative quantities to decrease the cumulative shipped amount. The cumulative shipped amount starts at the contract amount and is reduced by shipments until the amount reaches zero. When this value reaches zero, the customer can have all orders that are received from this point forward placed on hold until the cumulative shipped amount is adjusted.
The system uses these tables to process shipping and planning schedules:
-
F40R20
-
F40R10
-
F40R11
-
F40R23
-
F40R12
7.3 Understanding Standard Pack Calculation
Typically when a supplier ships product to customers, the product must be in an agreed upon standard pack. The standard pack is the number of pieces that the customer wants in each pack. In most cases, if the customer orders less than the standard pack, the supplier must still round up to the standard pack amount. You can ensure that the shipments are made in the prearranged quantity and adjust sales orders and forecast quantities accordingly.
The system uses the Ship Quantity Requested value, and the Branch/Plant, Sold To, and Ship To values, and determines if the amount being shipped actually fulfills the standard pack. If the Shipped Quantity Requested value is not a multiple of the standard pack amount, the system rounds the Ship Quantity Requested up to the next highest multiple of the standard pack. This quantity is then returned as the new value for the Ship Quantity.
7.4 Understanding Fence Dates
You can use schedule fences and preferences to control how the system maintains records for new releases and changed quantities. A firm shipment fence specifies the number of days of demand for which you create sales orders. The planned forecast fence specifies the number of days of demand for which you create forecasts.
When the system receives forecast releases and shipping schedules, the system interprets the transactions and messages and creates the demand detail records. Each record is identified as either plan or firm, with a period indicator as daily, weekly, or monthly.
Based on the preferences and fence settings, the system identifies the demand records to create or update sales orders or to create forecasts. The dates the system uses are a horizon start date, firm shipping fence date, and a plan forecast fence date.
For example, you can specify the number of days, beginning at the horizon start date, of firm demand to be used to generate sales orders. If the horizon start date is January 1, with six fence days, the system creates sales orders through January 7. If the customer does not transmit a horizon start date (HZSD), you can use the Release Date field (RLSDJ) for this purpose.
Firm demand that lies past the firm shipping fence is informational only. The system does not use this demand to generate sales orders or forecasts.
For planning fences, the system identifies the number of days from the horizon start date of the plan demand to be used to generate forecasts. The system does not create sales orders from plan demand. Any plan demand that lies past the plan forecast fence is informational only.
7.4.1 Example: Calculating Fence Dates
This example describes how the system creates sales orders and forecast records based on fence dates. Assume that the system received the data automatically from the EDI scheduling, planning and shipping documents (830 and 862).
Horizon Start Date: 07/10/2000
Demand Detail:
| Heading | Heading | Heading | Heading |
|---|---|---|---|
| 07/10 | 500 | Plan | Weekly |
| 07/10 | 100 | Firm | Daily |
| 07/11 | 100 | Firm | Daily |
| 07/12 | 100 | Firm | Daily |
| 07/13 | 100 | Firm | Daily |
| 07/14 | 100 | Firm | Daily |
| 07/17 | 1000 | Plan | Weekly |
| 07/17 | 200 | Firm | Daily |
| 07/18 | 200 | Firm | Daily |
| 07/19 | 200 | Firm | Daily |
| 07/24 | 1000 | Plan | Weekly |
Cum Shipped: 1000
Firm Cum Required Prior: 1000
Plan Cum Required Prior: 1000
7.4.2 Scenario 1
The system creates sales orders for the first three days of firm requirements and does not create sales orders for the rest of the firm requirements.
| Fences | Days | Sales Orders | Forecast | ||||
|---|---|---|---|---|---|---|---|
| Firm Shipping | 3 days | 07/10 | 100 | Daily | 07/10 | 500 | Weekly |
| Plan Forecast | 999 days | 07/11 | 100 | Daily | 07/17 | 1000 | Weekly |
| 07/12 | 100 | Daily | 07/24 | 1000 | Weekly |
The system then creates forecast records for all of the plan requirements.
7.4.3 Scenario 2
The system creates sales orders for the first five days of firm requirements and the rest of the firm requirements are dropped.
| Fences | Days | Sales Orders | Forecast | ||||
|---|---|---|---|---|---|---|---|
| Firm Shipping | 5 days | 07/10 | 100 | Daily | 07/10 | 500 | Weekly |
| Plan Forecast | 8 days | 07/11 | 100 | Daily | 07/17 | 1000 | Weekly |
| 07/12 | 100 | Daily | |||||
| 07/13 | 100 | Daily | |||||
| 07/14 | 100 | Daily |
The system then creates forecast records for the first eight days of plan.
7.5 Understanding Forecast Planning Dates
The system uses forecast dates to anticipate demand for customers. The information flows into forecasts automatically, based on dates that customers provide. You can establish forecast dates based on days, weeks, or months. To calculate this information, the system uses the beginning date and end date for a specific period, along with the number of workdays in the period.
Customers use their own method for generating and communicating dates. For example, these dates can occur at the beginning or end of the month, or on certain days of the week. You specify in advanced preferences a demand forecast date (type 28) to allow the system to receive planning records from customers and then convert the records into start and end dates to create forecasts.
The preference includes a week begin and end date rule, and a month calculation value. This table describes these values:
| Month Calculation Rule | Description |
|---|---|
| 0: Calendar Month (Default) | The customer uses the calendar month. The start of the month is always the first, and the end of the month is always the last day of the month. The system supports partial months. |
| 1: Day of Week Occurrence | The date received represents the begin date or end date for a given month. For example, if you receive a begin date for the second Tuesday of the month, then all months start on the second Tuesday. Likewise, if the end date is the third Saturday, then all months end on the third Saturday. |
| 2: Day of Week Anchor | Anchor rules are set up as a value between 0 and 6, representing Sunday through Saturday. This rule defines a planning period where the first occurrence of the anchor day is in the first week of a calendar month. The planning period is either four or five weeks, which ensures that the planning period complies with the anchor rule. Values are:
0: Sunday 1: Monday 2: Tuesday 3: Wednesday 4: Thursday 5: Friday 6: Saturday |
| 3: Date Pattern Month | A fiscal date pattern defines the details of the planning calendar dates. Based on the received date, the system uses the fiscal date pattern to find the start and end dates for the month. |
7.5.1 Example: Calculating Forecast Planning Dates
Monthly calculations assume that any given month starts the day after the prior month ends. Likewise, any given month ends the day before the next month starts. A month's end date can be calculated by determining the start of the next month and backing up one day.
Weekly calculations assume that any given week ends six days after it began. Likewise, any given week starts six days before it ends.
When you use the calendar or week calculations with beginning and end date rules, this table describes the possible scenarios:
| Heading 1 | Heading 2 |
|---|---|
| Calendar Month, Calculate Month End Date | You use the calendar month and receive the month begin date from the customer. The system calculates the month end date as the last day of the calendar month. |
| Calendar Month, Calculate Month Begin Date | You use the calendar month and receive the month end date from the customer. The system calculates the month begin date as the first day of the calendar month. |
| Calculate Occurrence Month, Calculate Month End Date | You base the beginning date on a day of the week and the occurrence of that day in the month. You receive the month beginning date from the customer. The system calculates the month end date by finding the next month's beginning date and backing up one day. |
| Day Occurrence, Calculate Month Begin Date | You base the ending date on a day of the week and the occurrence of that day in the month. You receive the month ending date from the customer. The system calculates the month begin date by finding the prior month's end date adding one day. |
| Anchor Month, Calculate Month End Date | You base the month on a day-of-week anchor and receive the month beginning date from the customer. The system calculates the month end date by finding the start of the next planning month and backing up one day. The system calculates the next planning month's beginning date by finding the start of that calendar month and locating the first occurrence of the anchor day of the week. |
| Anchor Month, Calculate Month Begin Date | You base the month on a day-of-week anchor and receive the month ending date from the customer. The system calculates the planning month's beginning date by finding the start of the calendar month and locating the first occurrence of the anchor day of the week. |
| Week Date Range | You use weekly beginning and ending dates. The system adds six days to determine the end date or subtracts six days to determine the beginning date. |
| Fiscal Date Pattern Month, Calculate End Date | You use the received date with the fiscal date pattern to determine the end dates, based on the values established in the fiscal date pattern for that period. In this case, the system uses the last day of the fiscal period as the ending date. |
| Calculate Fiscal Date Pattern Month, Calculate Begin Date | You use the received date with the fiscal date pattern to determine the beginning dates, based on the values established in the fiscal date pattern for that period. In this case, the system uses the first day of the fiscal period as the beginning date. |
7.6 Creating Demand Scheduling Sales Orders
This section provides an overview of and discusses demand scheduling sales orders and how to run the Create Schedule UBE (R40R010).
7.6.1 Understanding Demand Scheduling Sales Orders
A demand sales order is a sales order that is generated when you run the Create Demand Schedule program (R40R010). Created or updated sales orders reflect what items must be shipped to meet the customer's schedule. Changes that you make to a demand sales order must be done using the Demand Maintenance program (P40R10).
You can use this report to perform these types of processes:
-
Create and update demand sales orders or forecasts.
-
Calculate plan or firm fences.
-
Calculate ahead/behind amounts.
-
Calculate standard pack rounding.
You use Data Selection to specify how and when the system calculates and processes this information. For example, you can specify a time-of-day schedule (typically after the daily EDI messages have been processed into the demand tables), or whether to run this application automatically after the demand business function is finished processing, or manually from the menu.
|
Note: The system processes deleted demand records by deleting sales order entry items. On the Process tab, if you leave the F4211 Ship Date and Ship Time Update processing option blank, the system does not update the Promised Ship Date field or the Promised Ship Time field on the remaining, non-canceled sales order lines.If you enter a 1, the system updates non-canceled sales order lines with a ship time of zero, when sales order lines are canceled due to deleted demand information. |
The system recognizes a demand sales order based on the Demand ID, which links the order to its original demand scheduling record. The system also associates demand sales orders to the originating demand scheduling record using other demand related fields that you can review in the Sales Order Entry application (P4210).
|
Note: The system disables the demand fields on the SOE Additional Information form (W4210B) when the Demand ID field is populated on the record in demand scheduling, or if the Demand Scheduling (40R) system is not enabled. |
You can create demand sales orders using combinations of these values:
-
Branch/Plant
-
Sold To
-
Ship To
-
Promised Ship Date
-
Promised Ship Time
-
Customer PO
When the system creates or modifies sales orders, it also creates or modifies shipments and carton recommendations automatically for tracking orders and creating shipments.
For making deductions to backordered sales order lines, the system first deducts all the backordered lines if they exist. The system then processes the line having the least quantity backordered. If backordered lines do not exist, or backordered lines are all adjusted and canceled, the system processes the non-backordered lines with the least quantity first.
7.6.3 Setting Processing Options for Create Schedule UBE (R40R010)
Processing options enable you to specify the default processing for programs and reports.
7.6.3.1 Process
- 1. Cross Reference Customer Item Type
-
Identify the type of cross-reference set up for this customer through the user defined code of 41/DT. Examples of cross-reference types include Substitutes, Replacements, Bar codes, Customer item numbers, and Supplier item numbers
- 2. F4211 Ship Date and Ship Time Update
-
Indicate whether the system updates the Requested Ship Date and Requested Ship Time on a canceled Sales Order Detail (F4211) record. Values are:
Blank: Do not update the record.
1: Update the record.
7.6.3.2 Error Notification
- 1. Print Report
-
Specify if you want the system to print a hard copy of the report. Values are:
Blank: Do not print a hard copy
1: Print a hard copy
- 2. Send Message
-
Specify whether the system sends error messages and warning messages to the work center. Values are: Blank The system does not send messages to the work center. 1 The system sends messages to the work center.
Blank: The system does not send messages to the work center.
1: The system sends messages to the work center.
7.6.3.3 Workday Calendar
- 1. Work Day Calendar Type
-
Specify how the calendar is used through the user defined code (42/WD). For example, the calendar might be specific to an industry such as banking or it might be used to schedule delivery persons for a route. Values are:
BANK: Bank Calendar.
CARRIER: Carrier Calendar.
CUSTOMER: Customer Calendar.
DOCK: Dock Calendar.
RESOURCE: Resource Calendar
ROUTE: Route Calendar
Note:
If you use the default value of *, the system updates the value to blank even though blank is not set up as a valid value in the UDC table. - 2. Work Day Calendar Value
-
Classify values within a calendar type. For example, if the calendar type is ROUTE, you can enter a code that specifies a particular route, such as Daily or Weekend.
Note:
The system does not validate the code that you enter.
7.6.3.4 XAPI Return Call
- 1. Callback Function Name 1. Callback Function Name
-
Define the actual name of the function to be executed after the process returns from the Sales Order system. It must follow standard ANSI C naming conventions. For example, no space between words.
7.7 Setting Up Demand Spreading
This section provides an overview of demand spreading and discusses how to create a demand spreading template.
7.7.1 Understanding Demand Spreading
Demand spreading refers to the process of spreading the demand forecast quantity for a given date or date range across a specified time period. In this process, the planned dates and quantities in the Demand Detail records are consolidated, spread across a week in daily buckets, and then distributed into aggregate weekly or monthly buckets that are required for forecasting and planning.
This step is necessary because the demand information transmitted by customers to the supplier can vary. Customers can define demand in daily, weekly or monthly quantities. Customers may also consider different days as starting days for a week, or they might define a month in different ways. This table indicates how the demand information can vary from customer to customer:
| Customer | Month | Actual Time Period | Quantity |
|---|---|---|---|
| Customer A | June 2001 | June 4 - July 1 | 18,000 |
| July 2001 | July 2 - August 5 | 19,000 | |
| August 2001 | August 6 - September 2 | 20,000 | |
| Customer B | June 2001 | June 1 - June 30 | 10,000 |
| July 2001 | July 1 - July 28 | 12,000 | |
| August 2001 | August 1 - August 31 | 14,000 | |
| Customer C | June 2001 | June 4 - July 1 | 50,000 |
| July 2001 | July 2 - July 29 | 50,000 | |
| August 2001 | July 30 - September 2 | 55,000 |
To accommodate the production schedule at a given branch/plant, the supplier has to accept these varying planning schedules and transform them into a common forecast.
When you process a batch of demand records through the Create Demand Schedule program (R40R010) to transfer planned demand into the Forecasting system, the system deletes any existing detail and summary forecast records (F3400 and F3460) for any combination of item, branch, customer and forecast type that occur in the batch. After the deletion, the system processes the batch one record at a time to load a new forecast. If a time period includes multiple demand records, the final forecast for this period contains the sum of the forecasts from all the overlapping records. The resulting forecast is considered the latest forecast for the combination of item, branch, customer and forecast type.
After removing the previous forecast records, the system automatically spreads and consolidates the demand quantities across the specified time period. In the process, the system invokes a demand spreading template, if one is available, and divides the demand into daily buckets, based on the percentages specified in the template. If no template is available, the demand is spread evenly across the workdays of the date range.
After the demand is broken down into daily values, the system rolls up these daily values into a forecast based on the date ranges defined for the forecast buckets and stores the records in the F3400 table and the F3460 table. The forecast buckets can be set up for weekly or monthly forecasts.
7.8 Creating a Demand Spreading Template
This section provides an overview of demand spreading templates and discusses how to create a template.
7.8.1 Understanding Demand Spreading Templates
For the purpose of spreading the demand received from customers across a specified time period, you can use the Work With Demand Spreading program (P3470) to define demand spreading templates to meet the business needs. You can define a demand spreading template for a branch/plant, but you can also set it up for a combination of branch/plant and ship to or a combination of branch/plant, ship to and item.
Setting up a demand spreading template enables you to specify percentage values for the days on the template that represent how the total forecasted demand is allocated to the days of a week and, if needed, a prior week. The sum of all the percentage values you enter has to be 100. On the template you also define the date pattern that determines the actual week for spreading demand into daily buckets.
|
Note: If you do not set up any demand spreading templates, the system allocates the demand evenly across the specified time period. |
7.8.2 Forms Used for Creating a Demand Spreading Template
| Form Name | Form ID | Navigation | Usage |
|---|---|---|---|
| Work With Demand Spreading Templates | W3470A | Forecast Setup menu (G3441), Work With Demand Spreading Templates | Locate demand spreading templates. |
| Demand Spreading Template Revisions | W3470B | On Work With Demand Spreading Templates, click Add. | Create a demand spreading template.
Enter demand spreading percentages in the Day fields for the weekly and the prior weekly distribution. The demand for the week is spread among the days of the week based on the percentage allocated to each day. The sum of the percentage values must be 100. |
7.8.3 Creating a Template
Access the Demand Spreading Template Revision form.
Figure 7-1 Demand Spreading Template Revision form
Description of ''Figure 7-1 Demand Spreading Template Revision form''
- Item
-
Enter a number that identifies the item. The system provides three separate item numbers plus an extensive cross-reference capability to alternative item numbers. The three types of item numbers are:
Item Number (short), which is an 8 digit, computer assigned item number.
2nd Item Number, which is a 25 digit, user-defined, alphanumeric item number.
3rd Item Number, which is a 25 digit, user-defined, alphanumeric item number.
In addition to these three basic item numbers, the system provides an extensive cross-reference search capability. You can define numerous cross references to alternative part numbers. For example, you can define substitute item numbers, replacements, bar codes, customer numbers, or supplier numbers.
- Date Pattern
-
Enter a code that identifies date patterns. You can use one of 15 codes. You must set up special codes (letters A through N) for 4-4-5, 13 period accounting, or any other date pattern unique to the environment. An R, the default value, identifies a regular calendar pattern.
The information in this field determines how a week is defined for the demand spreading template.