Enabling Customer Delivery Schedules

Outcome

The CDS is created and processed so that customer order lines are updated according to the current customer demands. If the CDS is linked to JIT Call-Off Management, JIT demands will be created, processed and ready for the packing process.

Application messages are created and sent to the responsible user based on events, errors and deviations that occurred during CDS processing.

Finally, the delivery schedules are archived when they are no longer needed in the production environment.

The CDS is used as the demand source for a company's planning and execution processes. How it is used depends on the level of commitment (call-off or forecast) and time period (daily, weekly or monthly) of each demand. Eventually, the CDS will be used for material planning and the outbound dispatch process.

The responsible user takes the manual actions that are necessary for completing CDS processing, depending on any application messages about events, errors and deviations during the CDS process.

The archived schedules are used for historical analysis. If they are needed again, they can be retrieved back into the production environment.

For a description on how the system is affected by each activity, see related documents listed in the "See Also" section.

Before you start

• Partner structure must be defined in the following programs:
  • 'Customer. Open' (CRS610)
  • 'Customer. Connect Addresses' (OIS002)
  • 'Customer. Connect Delivery Specification' (OIS004)
  • 'Business Chain. Open' (OIS038)
  • 'Customer Address. Connect Replacing' (RSS040)
• Item and inventory must be defined in the following programs:
  • 'Item. Open' (MMS001
  • 'Item. Connect Warehouse' (MMS002)
  • 'Item. Connect Facility' (MMS003)
  • 'Item. Connect Alias Number' (MMS025)

Description

1. Create partner and partner alias repositories

   • Create partner type

     Along with the partner category, a partner type defines internal and external partners. Examples of internal partners are divisions, facilities or warehouses. Examples of external partners are customers, customer addresses or suppliers. The partner identity is used to translate itself into a partner alias identity. This is performed when an outgoing EDI message is created by using the API CRS886MI.

     'Partner Type. Open' (CRS883)

   • Connect to partner alias type

     A partner alias is an alternative identity to a M3 internal identity, such as a division, a facility or a warehouse. Partner aliases also apply to external identities. Examples of external identities are customers, customer addresses and supplier numbers. The partner alias identity is used to translate itself into a partner identity. This is performed when an incoming EDI message is received by using the API CRS886MI.

     'Partner Alias Type. Open' (CRS884)

   • Create partner

     Partner is a M3-defined identity of an internal or external trading partner on different hierarchical levels, such as customer ID, supplier ID, customer address ID and warehouse ID. The partner identity is used to translate itself into a partner alias identity. This is performed when an outgoing EDI message is created by using the API CRS886MI.

     'Partner Repository. Open' (CRS885)

   • Connect to partner alias

     A partner alias is an externally defined identity of a trading partner on different hierarchical levels, such as plant code, gate code, EAN location code and supplier number. The partner alias identity is used to translate itself into a partner identity. This is performed when an incoming EDI message is received by using the API CRS886MI.

     'Partner Alias Repository. Connect' (CRS886)

2. Enabling partner agreement

   You enable a partner agreement by creating a schedule type and partner settings.

   • Define delivery schedule type

     The delivery schedule type determines how to create the orders, how much automation should occur in the scheduling process and how to display data in the programs.

     'Delivery Schedule Type. Open' (RSS010)

     'Dely Schedule Type. Update Field Control' (RSS011)

   • Define partner settings

     You define settings per partner and connect partners to a delivery schedule type.

     'Settings – Partners' (RSS015)

3. Define default sales facility and warehouse

   Default warehouse and facility are used when you create a delivery schedule and connect items to this delivery schedule. These items are then issued from the default facility/warehouse.

   'Default Sales Facility. Define' (RSS005)

   'Delivery Warehouse. Open Default' (MMS058)

4. Enabling cumulative reconciliation

   The purpose of cumulative reconciliation is to match the supplier's cumulative figure with the customer's cumulative figure sent in the delivery schedule. Cumulative reconciliation is the reconciliation method that is most frequently used.

   'Settings – Summary Inventory Statistics' (CRS716)

   'Settings – Partner' (RSS015)

   'Item. Update Cumulative Quantities Delivered' (MMS072)

   'Item. Update Cum Qty Delivered/Lines' (MMS073)

5. Enabling date calculation - Two different ways

   Date calculation calculates the departure date/time and requested date/time.

   Date calculation is used in customer delivery schedules (CDS) and when CDS interfaces the customer batch order entry.

   There are two different ways to choose from when enabling date calculation. They are:

   • CDS Date Calculation (no route management possible)

     You can do CDS date calculation in two ways:

     • Calculate date based on delivery pattern. CDS date calculation based on delivery pattern can be used when there is no EDI support for delivery plans and you enter (RSS102) manually, or when there is EDI support for delivery plans and JIT call-off management is used.

       'Delivery Pattern. Open' (RSS025)

       'Delivery Pattern. Connect Days' (RSS026)

     • Calculate based on delivery calendar. Use CDS date calculation based on delivery calendar when you want to have a unique calendar per customer address. This allows you to have customer-specific departure dates or customer-specific goods receiving dates, and also move delivery dates backwards when it is necessary.
   • TPL Date Calculation (route management possible).

     TPL date calculation must be used when route planning is used.

     You can choose between using dispatches by delivery number or by shipment (transportation management).

     If you use dispatches by delivery, you must at least set up route, route departures and route selections.

     You can also define unloading places and departure exceptions.

     If you use dispatches by shipment you must also set up rules for managing shipments.

     Settings for routes and shipments are listed in the following:

     .

6. Define deviation management

   By performing a deviation check, you will make sure that there are no unacceptable deviations within the delivery schedule before the creation of the net schedule, which is the next step in the processing of the delivery schedule.

   A deviation check is based on a deviation model, for which you choose the delivery schedule fields you want to check.

   'Delivery Schedule Deviation Model. Open' (RSS020)

   'Deviation Model. Connect Period Types' (RSS021)

7. Define split management

   A split is necessary when the received demands are aggregated for a specific demand bucket (such as monthly demands) and you want to break them down to weekly or daily demands. The reason for doing this is to create a more detailed planning overview and a more correct replacement between forecast and call-off DS.

   'Delivery Split Model. Open' (RSS055).

   'Split Model. Connect Period Types' (RSS056)

8. Define customer and customer alias deviations

   These deviation settings per customer/customer alias/delivery specification/ item can be used if you want to override the settings already done.

   'Customer Item. Open Info/Customer Addr' (RSS050)