This chapter contains the following topics:
Demand Scheduling Execution enables you to capture the raw EDI demand requirements that are sent by customers to suppliers. Typically, you send and receive information using the JD Edwards EnterpriseOne Electronic Data Interchange system (47). This demand scheduling information includes cumulative quantities and supplier release scheduling. You can determine which transactions and messages are sent to the supplier, and how to use them.
A supplier might receive the same type of information on several different transactions or messages, depending on the mix of customers with which they conduct business. The translator can interpret and process this data consistently and map the information to the database, based on the user-defined translation rules.
For example, demand information can be received by an 830, 850, 862, 866, DELJIT, DELFOR, or ORDERS document. The third-party translator then maps the data from the EDI transmission to EDI system (47) demand tables, based on the trading partner, the EDI transaction, and the data that was received.
Occasionally, customers use the 850 (purchase order) document for planning and forecasting, or for spot buys. Other customers use it as a blanket purchase order. For the customers that use the 850 for planning and forecasting, this document flows through the demand tables as a planning requirement. For spot buys, the system processes the 850 as a firm type of requirement. If the 850 document is used as a blanket purchase order, the system maps it to the PO System/47 tables and processes it as a typical 850 document.
You can also enter and revise this information manually and direct this information to customers or suppliers.
The JD Edwards EnterpriseOne Demand Scheduling system enables you to maintain demand requirements that you receive from the customer. Demand rules include demand data and cumulative quantities that you set up at the customer and ship to level. These rules define how requirements are updated during the shipping process.
For example, demand rules enable you to:
Specify the day on which a customer's week begins, which enables you to determine whether a demand record is associated with the current week or the prior week.
Adjust shipment dates for nonworking days.
Increase or decrease cumulative quantities when updating the cumulative quantity that was shipped.
Replace the existing demand with the new demand that is associated with a particular ship to record.
Calculate ahead or behind values to adjust the demand before you create the sales order.
Establish shipment and delivery times based on the values for Branch/Plant, ship to, or sold to time zones.
You use demand records to maintain all of the demand information. Demand records include these types of information:
Supplemental data that is stored at the demand header and detail level.
Current schedules for creating forecast records and sales orders.
Preferences for setting up fence dates, tolerances, pack rounding, and so forth.
Address and contact information.
Packaging information.
Historical data of each schedule change or release.
Net variance changes through inquiry and alerts.
Activity data for analyzing inactive or obsolete items.
In the context of Demand Scheduling, customers might have two types of requirements, firm and planned. Planned requirements represent demand for items that are not needed right away and must not ship immediately, but are items for which the supplier must plan because the customer anticipates needing the material within a specific future time horizon.
After customers have communicated their requirements to their suppliers, typically using EDI, the requirements are transferred from the EDI demand tables to the F40R11 table by running the EDI Inbound Demand Edit/Update program (R47171). The resulting records in the F40R11 table are characterized as planning or firm demand by the value in the Demand Type field. Each record also contains a demand period indicator that specifies the period for the demand record (daily, weekly or monthly).
|
Note: You can also enter firm or planned demand into the system by using the Demand Maintenance program (P40R10). Set a processing option to start the Create Demand Schedule program (R40R010) automatically.You transfer planned demand values into the JD Edwards EnterpriseOne Forecast Management system by running the Create Demand Schedule program. Based on the schedule fence that you defined in the preferences for a customer and item combination, the system determines whether to create a forecast record from the demand record. If the demand record is within the time frame that is specified by the horizon start date (the release date or the date that is provided by the customer), the system creates a forecast record; otherwise, the data is used for information only. After the system sends a demand detail record to the JD Edwards EnterpriseOne Forecast Management system, the Create SO Status is set to 0 in demand detail. |
Demand scheduling enables a supplier to use demand information from the customer as a way to create forecasts for the company's own production schedule. If the release that is sent by the customer is in the time period between the horizon start date and the plan forecast fence date, the system considers it planned demand and processes it into a forecast.
When working with large customers, you might want to consider the demand for each customer separately and plan production quantities accordingly. You can set up the system to net forecasts and sales orders for a particular customer separately so that you can plan more accurately for the specific demand from individual customers. When you are netting forecasts against sales orders, the results can differ depending on whether you compare aggregate forecast and sales order values or whether you compare the values for each individual customer.
When you run the MRP/MPS Requirements Planning program (R3482), you can set up the program to use forecast consumption by customer. You can use this functionality for items that are defined with planning fence rule C, G, or H. You cannot use forecast consumption logic for process items.
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 planning dates and quantities in the Detail Demand records are consolidated and then distributed into forecasting buckets in aggregate weekly or monthly values. The JD Edwards EnterpriseOne Forecast Management system supports two methods of demand spreading:
Template spreading
You create a demand spreading template to indicate how to spread planned demand quantities across a week. You can specify a different percentage for each day. The percentages that you specify in the template must add up to 100.
Even spreading
When no demand spreading template exists, the system automatically distributes demand quantities evenly across the days of the week. This is the default method.
You use cumulative processing to communicate firm and forecasted requirements for accumulated quantities of goods from the start of a blanket purchase order to a particular future date. For example, you can send and receive notifications regarding year-to-date quantities received, quantities required, and quantities shipped.
Each demand detail record is associated with a unique cumulative record. The system receives cumulative data when you enter it manually using the CUM Maintenance program (P40R12), or through the EDI Demand Header program (P47171) using the EDI Inbound Demand Edit/Update program (R47171). You can also adjust cumulative information using the adjust demand process and CUM Rollback program (P40R421), which automatically resets cumulative quantities to zero.
You can create shipping and planning schedules based on demand and cumulative information. This table describes how you work with schedules.
| Schedule | Comments |
|---|---|
| Decrementing CUMs | You use decrementing CUMs to decrease the cumulative amount that was shipped and to place orders on hold when the CUM shipped reaches zero. |
| Fences | You can use schedule fences and preferences to control how the system maintains records for new releases and changed quantities. Two kinds of fences exist, firm and plan.
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. |
| Standard Pack | You use standard pack and rounding rules and cumulative calculations to determine order quantities. You set up standard pack information at the customer and item level to ensure that shipments are made in the correct quantity. Customers can request shipments that are not using standard pack. |
| Ahead/Behind | You can determine whether a supplier is over-shipped, under-shipped, or even. You calculate this amount by subtracting the cumulative shipped amount from the cumulative required amount. If the amount is positive, the supplier is behind (under-shipped). If the amount is negative, the supplier is ahead (over-shipped). If the difference amount is zero, the supplier is on schedule. |
| Forecast Dates | You create forecasted schedules and transmit them from the trading partner to the supplier to cover a forward period, usually in a days/weeks/months format. The schedules are often given in a series of year-to-date cumulative totals. |
| Schedule Revision Preferences | You set up a preference to specify how the customer sends their planning demand. |
Firm demand represents the demand requirements for items and material that are needed for a specified, future time. You can create and process records to manage firm demand. These records store the information that you use to maintain the requirements, including schedules, sales orders or forecasts, maintenance rules, and other default information that is relevant to suppliers and customers. You can also specify how the system processes cartons, labels, shipments, and notifications, and you can run reports to analyze all of the demand information.
A demand sales order is a sales order that is generated from the JD Edwards EnterpriseOne Demand Scheduling Execution system when you run the Create Demand Schedule program (R40R010). The sales orders that are created or updated reflect what items must be shipped to meet the customer's schedule.
The system automatically creates shipment records to organize the daily shipments. The demand sales orders are linked to the originating demand scheduling record by demand-related fields that you can review in the Sales Order Entry program (P4210) in the JD Edwards EnterpriseOne Sales Order Management system.
You can store detailed information about each carton on a shipment for tracking, carton charges, and the Advanced Ship Notice (ASN).
Carton information includes:
Serial numbers.
Weight information.
Scanning information.
Third-party or custom modifications for data collection and scanning.
Manual processing.
Carton recommendations.
Recommendations for packing.
Next numbers for label serial number.
Carton reorganization for changes.
The ASN enables the sender to describe the contents and configuration of a shipment. The ASN lists the contents of a shipment of goods, and information that is related to the shipment, such as:
Order information.
Product description.
Physical characteristics.
Type of packaging.
Carrier information.
Configuration of goods within the transportation equipment.
The system prints the bill of lading from shipment and carton detail with detail and summary carton information. Customers control the format for the bill of lading number, which uses next numbers and is not customer-specific.
The system gathers label data from various tables into an outbound document and sends this information to a third-party to format and print the labels. You can send label information from these programs:
Demand Maintenance (P40R10).
Sales Order Entry (P4210), if you are not using Demand Scheduling.
Carton Detail Inquiry (P4621), if the carton detail was created from carton recommendations.
The system uses inbound scanned label data to create or update carton detail and to create the ASN. The system requires detailed carton information on the ASN and the Bill of Lading to describe the shipment. Labels must have standard data from the inbound EDI message.
You can generate label serial numbers based on the branch/plant value using label next numbers. You can also generate labels externally. Label serial numbers are stored and validated by the third-party vendor. The system stores these numbers after you scan the number to verify quantities of shipment items with the quantities of carton detail items. You can correct discrepancies as necessary.
When reconciling shipments, you validate that a shipment quantity for an item matches the carton detail quantity. You can reconcile shipment information when entering and scanning labels. The system links the labels to the carton detail and matches the values for shipment number, item, ship to, and quantity. If you are using smart labels, the system compares the information for each container label that is linked to the scanned label. When a match is found, the system updates the information with the correct master/mixed and container label numbers. The system also creates a record for the master/mixed label in carton detail.
After you reconcile and load a shipment, you can confirm the shipment. You can enter last-minute ASN information, such as seal numbers or freight authorization codes. You can also specify whether to automatically extract the ASN.
Shipping reports display information that is useful for pick slips, packing slips, carton recommendations and packaging requirements for shipping, bill of lading information, cumulative amounts, and shipment analysis. These reports are available:
Document Batch Print UBE (R49590).
Transportation Bill of Lading Build (R49110).
Transportation Bill of Lading Print (R49118).
Shipment Analysis (R40R030).
ASN On Time Analysis (R470361).
Acknowledgement Accuracy Analysis (R47191).
This table describes how the system processes notifications for demand scheduling:
| Notification | Comments |
|---|---|
| ASN | ASN are electronic messages that provide product and shipment information to a customer before delivery.
EDI tables maintain ASN data, and this enables you to quickly change ASN data to send timely messages to customers. If the changes must also be reflected in the demand and shipping tables, you can make those changes through the appropriate application at a later time. You can also roll up totals and updates to related records. You can set up customer rules and preferences to specify whether to perform ASN tracking. The rules and preferences determine how long the system waits for an ASN acknowledgment to be received before sending a message, and the workflow process name to be initiated. For example, to be informed that an ASN was not acknowledged within twenty minutes, the customer rules specify twenty minutes. If the wait time expires, the system sends an E-mail to the designated personnel. |
| Acknowledgments | When you receive an EDI acknowledgment or application advice, the System/47 ASN database is updated with the acknowledgment date and time, and the status. The system processes these transactions for the ASN and the invoice.
You use customer rules to determine what type of activity takes place at each status. Statuses are:
Each of these statuses can optionally initiate a workflow process that can send a message or an email. You can correct any required data or mapping issues and resubmit the ASN for transmission. |
| Demand Adjustments | When a shipment is confirmed, the system issues an XAPI message with shipment information and adjusts the demand to handle remaining, partial requirements if the actual amount that is shipped is less than the amount that is required.
Demand is adjusted after the system receives the inbound demand and processes the associated order. The system uses the shipment confirmation message to communicate the actual quantity that is shipped to the rest of the system. The system uses the quantity shipped (including cartons) to adjust the original demand request and the associated cumulative quantities. For product messages (sales order detail lines), the system sends this information:
For carton messages, the system sends this information:
The system uses the statuses of the ahead and behind calculation to determine whether to perform the update. The system also updates cumulative shipped amounts for products and cartons if you have activated cumulative tracking. |
| Demand Workflow Notification | The contents of EDI and the way it is transmitted, varies from customer to customer. To accommodate those differences, a default workflow has been created that contains known business processes used by many trading partners. Each activity in this workflow represents a business process. The user has the option to use this default workflow, or copy the workflow and modify the activities. When modified, the user can define which Branch/Plant, Sold To, and Ship To combinations should use the new workflow. The user has the option to not launch a workflow for a particular customer, in which case the user does not define a workflow for the Branch/Plant, Sold To, and Ship To combination. |
| Demand Net Variance Workflow Notification | The Net Change Variance Workflow initiates a single messaging function activity to alert production or other personnel about a net variance change that exceeds the user-defined tolerance. Parameters passed in the data structure of the workflow permit the customer to customize the workflow or messaging as business practices may require. |
| Invoicing | The system creates the invoice after shipment confirmation. The system uses the Print Invoices program (R42565) to collect the required data from the related system files, and then converts the data into Electronic Commerce (47) system files.
The system then uses the EDI Invoice Extraction Conversion program (R47042C) to create a flat file. The translator maps the flat file into an 810 or INVOIC format, which you send to the customer. |
When you process sales orders using the Sales Update program (R42800), the system generates a shipment number for invoices that are stored in the F03B11 table. The system can select invoices and apply cash against invoices based on the shipment number, similar to using values like the invoice number, sales order number, customer reference, or statement number for processing and matching invoices and receipts.
Some suppliers are not required to generate an invoice, so the system enables you to issue payments based on the ASN.
You can run a variety of reports to analyze demand scheduling information. For example, you can print bills of lading or print information to analyze discrepancies for shipments, review demand activity, or analyze the efficiency of the advance ship notice process. These reports are available:
Shipment Analysis (R40R030).
CUM Reconciliation (R40R1010).
Demand Inactivity Analysis (R40R1020).
ASN On Time Analysis (R470361).
EDI ASN Update as Sent (R47037).
Acknowledgment Accuracy (R47191).
Transportation Bill of Lading Print (R49118).