Scheduling Agreements for Component Suppliers

• Scheduling agreements for component suppliers
• What is unique?
• Constraints
• Scheduling Agreement with Delivery Schedules
• Scenarios
• Scheduling agreement with delivery schedules (no external agents)
• Scheduling agreement with delivery orders
• Delivery by an external agent (consignment issue)
• Consignment pick-up for external agents
• Scheduling agreement returns (no external agents)
• Schedule line category
• Schedule line type
• Packing proposal
• Returns for Scheduling Agreements
• Correcting Cumulative Delivered Quantities
• Intermediate Documents
• Intermediate Documents for Scheduling Agreements
• Determining Notification Recipients
• Assigning a Sold-to Party
• Delivery Intervals
• Special Features for Delivery Schedules
• Delivery Intervals
• Delivery Schedule
• Delivery Schedule Types
• Just-in-time delivery schedules (JIT)
• Planning delivery schedules (PLN)
• Delivery orders
• Combining Delivery Schedules
• Setting Requirements and Delivery Relevance
• Functions 
• Shipping Functions
• Billing functions 
• Standard self-billing
• Self-Billing with Invoice Creation
• External Agent Functions
• Special Features for External Agents
• Process flow
• Document types
• Delivery Order Processing (MAIS)
• Process flow
• Cumulative Quantity - Delivery Orders
• Intermediate Documents for Delivery Orders
• Delivery Orders
• Planning Delivery Schedule Processing
• Maintaining Instructions in Customizing
• Requirements and Delivery Relevance in Planning Delivery Schedules
• Useful information
• 515337 - Identical scheduling agreements can be created w/o message
• 399819 - IDoc: Go-ahead starts are not updated
• 378144 - Scheduling agreements with third-party order processing
• 719913 - Product allocation with scheduling agreements
• 2004476 - Possible causes of incorrect requirement transfer from SD scheduling agreements
• 1817442 - Customer consignment stay time report
• 1050646 - EDL customer consignment with external service provider (classical) - plant level
• 1050468 - Smart external service provider (customer consignment) - special stock partner level 
• 787530 - VMI processing with EDI integration in Sales and Distribution
• 687513 - EDL customer consignment with external service provider (classical) - special stock partner level
• 633508 - Delivery service level reporting in Sales and Distribution
• 2670422 - No BOM explosion occurs in scheduling agreements for suppliers
• 633503 - Third-party: Third-party order processing with scheduling agreements

Scheduling agreements for component suppliers

What is unique?

There are two important differences between standard scheduling agreements and scheduling agreements for component suppliers. Scheduling agreements with delivery schedules:

• Contain schedule lines in the delivery schedule, not in the actual scheduling agreement item
• Can be influenced by the customer who requests the release of a specific quantity of materials on a specific day

What are the Constraints?

• Scheduling agreements with delivery schedules are not supported in assembly processing or third-party order processing.
• Also, copying control for sales documents does not support copying data from a preceding document into scheduling agreements with delivery schedules.

Scheduling Agreement with Delivery Schedules

In the scheduling agreement section for new entries, you can set:

• The delivery type for correction deliveries used to correct deviations in cumulative quantities
• The use indicator, such as replacement, sample, or series
• Block 07 to block deliveries when the system determines that a tolerance limit in the scheduling agreement was not reached or exceeded after comparing the old and new delivery schedules

Scenarios

The SAP System contains the following document types for component suppliers:

• LZ - Scheduling agreement with delivery schedules (no external agents)
• LK - Scheduling agreement with delivery schedules (external agents)
• LZM - Scheduling agreement with delivery orders
• ED - Delivery by an external agent (consignment issue)
• EDKO - External agent correction
• RZ - Scheduling agreement returns (no external agents)
• KAZU - Consignment pick-up for external agents
• KRZU - Consignment returns for external agent

Schedule line category

The schedule line category controls whether schedule lines in delivery schedules are relevant for planning and/or delivery. The system determines this category on the basis of the planning indicator in the forecast delivery schedule, then in the just-in-time (JIT) delivery schedule.

Schedule line type

The schedule line type is for information purposes only and does not in any way influence processing.

Packing proposal

In the component supplier industry, there are normally regulations on how and in what quantity a material is to be packed. The packing proposal function allows you to quickly and flexibly pack materials for delivery. If a packing proposal is not sent by the customer in the intermediate document (IDoc), you can enter the proposal manually in the scheduling agreement:

• In the Rounding quantity field in the item overview screen, specify how much of an item is to be packed in one shipping unit. The system will then round quantities so that only complete shipping units are delivered. If you do not want to round up to complete shipping units, set this quantity to zero.

Returns for Scheduling Agreements

When processing returns for scheduling agreements with delivery schedules, note the following:

1. Use document type RZ for returns
• To ensure immediate pick-up, the system automatically creates an immediate delivery when you save a return with this document type.  
2. Use document type KRZU (consignment returns) or KAZU (consignment pick-up) for returns involving external agents . Create returns with reference to the relevant scheduling agreement.
3. When the customer posts goods receipt, their system automatically updates the cumulative quantities. For this reason, you may want to correct your cumulative quantities only when the customer sends the items back without having posted goods receipt.
4. Cumulative quantities are not updated automatically. You must correct them manually.
5. Choose Goods issue to book goods receipt.

Correcting Cumulative Delivered Quantities

You correct cumulative quantities in scheduling agreements:

• In case of returns
• When there has been a processing error
• When there has been a year change
• When you are transferring initial quantities from a legacy system into the SAP System

To do this, you create a correction delivery within the delivery schedule itself. This delivery is not relevant for requirements planning, shipping, goods issue, or billing.

Correct cumulative quantities only when the customer has not posted goods receipt.
To create a correction delivery (document type LFKO ).

Intermediate Documents

Intermediate Documents for Scheduling Agreements

It uses criteria in the IDoc to determine the sold-to party and the related scheduling agreement.

Determining Notification Recipients

If the system finds this partner function, it sends an electronic mail to the partner using the personnel number that you have assigned.

Delivery schedules (function module IDOC_INPUT_DELINS)
Delivery orders (function module IDOC_INPUT_ORDERS)

There is another method, different from the above standard, to specify a notification recipient for an incoming document that you have just processed. With user exit EXIT_SAPLVED4_004, you can use the IDoc message type as import parameter, or the IDoc control record and data record as table parameters.

Transmit a user type in export variable E_USRTYP and a user name, or number, in export variable E_USRKEY. If you do not maintain both export parameters, the system does not take the user exit results into account.

Assigning a Sold-to Party

• The vendor number you enter here must have ten digits. If the number from the master record does not have this many, you must enter as many zeros before the number as necessary.
• The system uses the partner field (PARTN) from segment E1EDKA1 as the customer plant. 
• In this case, the field PARVW must be "WK". At item level, the system uses the field for the customer plant (KWERK) from segment (E1EDP10). Make sure you enter the sold-to party plant as partner description for the ship-to party.
• You can leave the unloading point blank if the customer does not usually send this information in the delivery schedule.
• The sold-to party number is your number for the customer.

Special Features for Delivery Schedules

• Special features for delivery schedules allow you to define for each sold-to party or combination of sold-to party/unloading point how delivery schedules are to be processed
• Using a version, you can designate how the system should react to errors during checks on the incoming delivery schedules of a particular sold-to party.

Delivery Intervals

• You define delivery intervals by assigning a key to the customer and marking the required delivery days for the key.
• You assign an automobile manufacturer delivery interval key 01. They have asked that you deliver materials only on Mondays, Tuesdays, and Wednesdays. You mark these days in the key. Soon after, you receive a delivery schedule with a weekly schedule line for 60 pieces. The system automatically divides the quantity and assigns them to the three days according to key 01. Result: The automobile manufacturer receives 20 pieces each on Monday, Tuesday, and Wednesday.

Self-Billing Document

Self-billing documents (function module IDOC_INPUT_GSVERF)

The system recognizes what type of self-billing document is sent by the customer from a status set in the intermediate document:

• 0 = invoice
• 1 = credit memo for retro-billing
• 2 = debit memo for retro-billing
• 3 = cancellation document
• 4 = credit memo for quantity corrections

For self-billing documents, the system takes the personnel number from the delivery header instead of the sales document header.

The recipient determination function is not available for self-billing with invoice creation. This is because the customer can send several deliveries in one EDI document, resulting in some cases in the system determining several personnel numbers for one item. Workflow, however, only allows you to send a notification to one person.

Special Features for Self-Billing

Make settings for self-billing

• Defining sales document types for credit and debit memo requests that the system creates when it receives a self-billing document from the customer requiring a credit or debit to the customer's account.
• In the standard system, sales document type G2 is for credit memo requests and L2 for debit memo requests.
• Activating a special rule for an automobile manufacturer
• You can use this field to refer to any of the various user exits that you program for EDI processing. The system will then take the user exits into account when processing billing documents for the automobile manufacturer that you designate.
• Specifying whether an employee should be notified if general texts are sent in a billing document

Make settings for self-billing with invoice creation

• Defining billing document types for invoices, and credit memos sent in by the customer to correct quantity differences
• Defining retro-billing document types for credit and debit memos sent in by the customer to correct prices
• Specifying whether an invoice is to be created for every external invoice sent in by the customer
• The system normally creates an invoice in the SAP System exactly as it is received from the customer. This may not always be possible, for example when there are items not relevant for billing, or when the document requires an invoice split. In these cases, the system does not create an invoice.
• By setting this indicator, you can create invoices for testing purposes even in those circumstances when the system normally would not.
• Specifying the default values of an invoice in case the system cannot determine this information from the delivery, or other internal referenced document, referred to in the intermediate document (IDoc)

Assign external conditions to internal conditions

• For only those conditions that you enter here, the system compares the value of the internal condition with that of the external condition sent in the external invoice.
• You can specify that the system should take these differences into account by setting the related indicator. If there are differences in these values, the system updates the IDoc status records and sends a mail to inform you. It continues processing the IDoc and, if no serious errors occur, creates the invoice anyway. This function is only available for the self-billing procedure with invoice creation.
• With user exit EXIT_SAPLVED5_003 , you can design your own tolerance checks.

Define tolerance levels for differences between external and internal conditions

• In the standard self-billing procedure, the system compares the values in the credit advice with those in the existing internal invoice. If the system finds any differences in these values, it terminates processing.
• With this function you can define differences that the system tolerates. In this case, even if the system determines differences in the external and internal condition values, it ignores them and continues processing the IDoc.

Delivery Schedule

The delivery schedule contains information on delivery quantities and dates. A new delivery schedule replaces, in part or completely, the previous delivery schedule with regard to date and quantity.

Delivery Schedule Types

1. Forecast delivery schedules (FRC)
• You can use the forecast delivery schedule as a basis for planning production and sales, and for controlling shipping. The forecast delivery schedule can refer to a scheduling agreement or purchase order.
2. Just-in-time delivery schedules (JIT)
• You can use it for fine-tuning production and shipping.
3. Planning delivery schedules (PLN)
• The planning delivery schedule is an internal schedule based on the forecast delivery schedule. It is used to fine-tune requirements planning by:
• Limiting the planning period of schedule lines in forecast delivery schedules
• Breaking down the weekly or monthly schedule lines sent in by the customer into daily requirements
4. Delivery orders. They are used in a similar way to JIT delivery schedules

Combining Delivery Schedules

The customer regularly sends in new delivery schedules that replace old delivery schedules. In some cases, however, the customer may want to combine old and new delivery schedules. To inform you of this special case, they send a special indicator in the delivery schedule.

There are two indicators designed for this purpose:

The requirement status key

• When the customer sets this key to "B", schedule lines in the old delivery schedule that come before or after the validity period of the new delivery schedule are copied to the new delivery schedule.
• The requirement status key has been designed for JIT delivery schedules that meet standards defined in VDA 4915, a requirement of the German Automobile Industry Association. This key is displayed in the delivery schedule header .

The forecast delivery schedule key

• When the customer sets this key to "1", schedule lines in the old delivery schedule that come before the validity period of the new delivery schedule are copied to the new delivery schedule.
• The forecast delivery schedule key has been designed for delivery schedules that meet Odette standards. This key is not displayed anywhere in the delivery schedule

Setting Requirements and Delivery Relevance

To decide which type of delivery schedule is currently relevant for requirements and delivery, the system uses the JIT delivery schedule horizon and the material requirements planning indicator in the scheduling agreement header.

If there are planning delivery schedules in the scheduling agreement and you have entered a planning delivery schedule instruction, the system determines requirements and delivery relevance according to different criteria. If this is the case, see the requirements and delivery relevance section on planning delivery schedules .

The SAP System contains the following settings for the requirements and delivery relevance indicator:

• Blank - Delivery schedules are not used.
• A - Only forecast delivery schedules are relevant for requirements planning.
• B - Forecast delivery schedules and JIT delivery schedules are relevant for requirements planning and delivery.
• C 
• Only forecast delivery schedules are relevant for requirements planning. 
• Only JIT delivery schedules are relevant for delivery.
• D - Forecast delivery schedules and JIT delivery schedules are relevant for requirements planning. Only JIT delivery schedules are relevant for delivery.
• E - JIT delivery schedules are not used.

The system determines the relevance for requirements as follows:

• MRP indicator B or D
• Up to the JIT delivery schedule horizon, the JIT delivery schedule is relevant for requirements
• After the JIT delivery schedule horizon, the forecast delivery schedule is relevant for requirements
• MRP indicator A or C
• The JIT delivery schedule is not relevant for requirements
• The forecast delivery schedule is relevant for requirement

The system determines the relevance for delivery as follows:

• MRP indicator A or B
• Up to the JIT delivery schedule horizon, the JIT delivery schedule is relevant for delivery
• After the JIT delivery schedule horizon, the forecast delivery schedule is relevant for delivery
• MRP indicator C or D
• Up to the JIT delivery schedule horizon, the JIT delivery schedule is relevant for delivery
• Schedule lines occurring after the JIT delivery schedule horizon are not relevant for delivery

Note the following when setting requirements planning and delivery relevance:

• When a schedule line in a forecast delivery schedule begins within the JIT delivery schedule horizon and ends outside of it, the horizon is reset and the forecast delivery schedule becomes relevant for requirements planning and delivery according to the planning indicator you have set.
• If, for example, a JIT delivery schedule horizon ends on 04/02 and the schedule line in the forecast delivery schedule begins on 04/01, the system sets the JIT horizon back to 03/31. The forecast delivery schedule is then relevant for planning and delivery as of 04/01 for planning indicator "B", for example.
• Relevance for requirements planning and delivery may change automatically when you make changes to the scheduling agreement. For example, when you move the date of the JIT delivery schedule closer to the current date, schedule lines in the forecast delivery schedule drop out of the JIT delivery schedule horizon and become relevant for delivery.

Functions 

Shipping Functions

You use standard shipping functions to deliver materials in delivery schedules. Schedule lines in the scheduling agreement due for shipping appear in a shipping work list from which you create a delivery, pick, pack, create shipping documents and post goods issue.

• You can specify that the system is to schedule deliveries only backwards from the schedule line date. No forward scheduling is carried out. This ensures that schedule lines from the previous delivery schedule can be copied unchanged to the new one.
• When creating a delivery, the system proposes packing instructions from the scheduling agreement
• When creating a delivery, the system takes an engineering change into account. You can change an engineering change or serial number up until goods issue is posted.
• To deliver materials in delivery schedules using KANBAN, choose the Shipping tabstrip in the scheduling agreement and set delivery block 08 (KANBAN delivery). The system will not take this scheduling agreement into account when creating a delivery due list. You can then create deliveries manually with reference to the scheduling agreement when you receive a KANBAN delivery schedule.

Billing functions 

Scheduling agreement processing offers you and your customer the flexibility to bill deliveries based on delivery schedules in a variety of ways.

Standard self-billing

• Credit advice: The credit advice sent in by the customer is converted to an IDoc and compared to the invoice that you have already created in the SAP System. This is to ensure that there are no differences between how the customer thinks a transaction should be billed, and how you think it should be billed.
• Credit memo requests for quantity corrections: The customer sends in a credit memo request when you have billed a larger quantity of material in the invoice than what was actually delivered. If the credit memo request corresponds to data in the SAP System, the system creates a credit memo request and then the corresponding credit memo.
• Credit and debit memo requests for retroactive billing: The customer sends in a credit or debit memo request to balance out retroactive price adjustments.

When the customer receives a delivery from you, they price the materials based on:

• Prices from the customer's purchasing department
• Differences between the delivery note and goods receipt
• Differences due to the quality of the material, for example
• Retroactive price adjustments

The customer uses materials and prices to prepare a credit advice that they send to you by Electronic Data Interchange (EDI). The system converts this advice into intermediate document (IDoc) GSVERF.

Once the system has determined the corresponding delivery and invoice, it compares items in the credit advice, in IDoc form, with items in the corresponding internal delivery and invoice.

The system compares the following condition values for each item:

• Net value
• Cash discount
• Surcharges/Discounts
• Value-added tax (VAT)

Check's result:

• If the values in the credit advice match the values in your invoice, the system assigns the credit advice number as a reference to the open items in the accounting document.
• If the system finds any differences in the values, it terminates processing of the IDoc and sends a mail to the employee responsible. The employee can then correct the problem manually, or inform the customer to send one of the following correction or retro-billing documents:
• Credit memo requests for quantity corrections
• Credit and debit memo requests for retroactive billing

If the values in the customer credit memo request ( quantity correction ) match the values in your delivery, invoice, and the existing credit memo, the system automatically creates the corresponding credit memo request, then the credit memo. The system always enters "EDI" as the order reason. It also copies the related credit advice number to the Purchase order number field in the purchase order section, and to the Assignment field in the accounting section.

Credit or debit memo requests based on return deliveries , are treated just as credit memo requests for quantity corrections, except that the system carries out pricing only for those materials that are returned. Also, instead of comparing each condition value, the system determines an overall difference per item and compares it to the overall correction value.

In the case of retro-billing , the system reprices all documents in the transaction before comparing the condition values of the items. It calculates the difference between the old and new prices in the delivery, invoice, and existing credit or debit memos, and compares it to the difference calculated by the customer in the credit or debit memo request. The difference calculated by the customer is copied to condition type EDI2, and the one that you calculate to condition type PDIF.If these values match, the system automatically creates a credit or debit memo request, then a credit or debit memo.

The customer sends a payment advice note based on their credit advice. The credit advice number that they include with the payment advice note indicates whether there are several deliveries per credit advice number or only one:

• The customer sends payment for a number of deliveries. 
• These deliveries are covered by one credit advice, the number of which is sent with the payment.
• The customer sends payment for a number of deliveries. There is, however, only one delivery per credit advice. 
• In this case, the customer groups the advice numbers and assigns a collective number, such as the EDI sequential number or vendor posting number. Payment, then, is for the total of the credit advices represented by this collective number. To compare open items, you must refer to the individual credit advice numbers.

Self-Billing with Invoice Creation

The customer uses materials and prices to prepare an invoice on your behalf that they send to you by Electronic Data Interchange (EDI). The system receives and converts this invoice into intermediate document (IDoc) GSVERF. It then forwards it to function module IDOC_INPUT_SBINV, which determines the reference delivery and items based on the internal delivery number, or external deliv ery number , sent in the external invoice.

In this self-billing procedure, you cannot create an invoice for the delivery: no original invoice exists. However, the system simulates invoice creation to determine internal prices and their conditions.

If the values in the external invoice match the values in the simulated invoice, and the delivery, the system creates an invoice in the SAP System exactly as the customer has prepared it. Note that the system does not use the standard billing transaction here, but rather a special billing interface (GN_INVOICE_CREATE). The external invoice number, in the External number field, is used in the settlement process.

If the system finds any differences in the values, it updates the IDoc status records, and sends a mail to the employee responsible. It continues processing the IDoc and, if no serious errors occur, creates the document anyway. The employee then informs the customer to send one of the following correction or retro-billing documents :

• Credit memos for quantity corrections
• Credit and debit memos for price corrections in retroactive billing
• Cancellation documents

Exits

EXIT_SAPLVED5_002

With this customer function, you can analyze and process warnings that the system collects when processing self-billing documents. You can, for example create a special message for a particular recipient or design a workflow that is different from the standard.

Additionally, you can process general data sent in the external billing document. For example, you can include this data in messages to give the recipient/customer more detailed information about the problem.

EXIT_SAPLVED5_003

With this customer function, you can program your own tolerance checks on internal and external conditions.You can, for example:

Design condition value tolerance checks for a specific customer

Perform tolerance checks based on quantities, for instance, a larger tolerance for larger quantities

EXIT_SAPLVED5_004

With this customer function, you can review and change data in the external billing document IDoc and data for the billing document interface before creating the document in the SAP System.

User Exits for Standard Self-Billing

EXIT_SAPLVED5_001

With this customer function, you can perform fine checks on internal and external condition values for credit advices (action 0 in E1EDK01).

When you receive an advice, the system determines internal condition values and compares these to the external values sent in by the customer. If they differ, the system transfers delivery items from the credit advice one by one.

EXIT_SAPLVED5_005

The system collects warnings in table XVBFS that occur when processing self-billing documents. For each entry in this table, the system creates a status record in the IDoc, and notifies the employee responsible by electronic mail.

EXIT_SAPLVED5_006

In EDI processing for incoming self-billing documents, the system transfers sets of data to screens in the SAP System by batch input.

With this customer function, you can include billing or other data not covered by the standard transfer program, for example.

External Agent Functions

External agent functions have been developed for just-in-time processing. 

The external service agent is a forwarding agent who normally has a warehouse in direct proximity to a customer manufacturing plant. To improve delivery times, the component supplier delivers materials to the external agent, who in turn makes frequent deliveries to the customer.

With this function, you create or receive documents in the SAP System for processing scheduling agreements involving external agents.

External agent delivery notes (function module IDOC_INPUT_EDLNOT)

Special Features for External Agents

You can set the system to:

• Automatically send a mail informing the employee responsible that packaging data is available for processing
• Send a mail, and copy the data as text into the scheduling agreement
• Ignore packaging data altogether
• Copy data into the scheduling agreement with no mail
• Specify whether an employee should be notified if general texts are sent in an external agent delivery note
• Specify the sales document type with which you create delivery by external agent documents
• This is sales document type ED , delivery by external agent (consignment issue), in the standard system.

Process flow

1. You have an existing outline agreement with the customer, in this case a scheduling agreement for external agents.
2. You have defined the external agent in the scheduling agreement as a forwarding agent and special stock partner.
3. On the basis of this scheduling agreement, the customer prepares data for a delivery and sends it to you in a forecast or just-in-time (JIT) delivery schedule.
4. An Electronic Data Interchange (EDI) system receives the incoming delivery schedule and converts it to an intermediate document (IDoc) which is then processed in the SAP System.
5. A forecast or JIT delivery schedule is created from the data records in the IDoc. The system determines the related scheduling agreement and generates schedule lines in the delivery schedule according to the customer's requirements.
6. You create a delivery and post goods issue to transfer stock to the external agent warehouse as schedule lines become due.
7. The customer requests material directly from the external agent by sending the external agent a sequenced JIT, or standard JIT delivery schedule .
8. The external agent delivers the material from the consignment stock, and sends you a copy of the delivery note (by fax or EDI) so that you can compare it to your delivery to the external agent. The system automatically creates an immediate delivery.
9. On the basis of the external agent delivery note, the system creates a delivery by external agent document (consignment issue) with reference to the scheduling agreement.
10. You create an invoice with reference to the delivery by external agent.

Document types

Document Type	Description
LK	Scheduling agreement with delivery schedules
ED	Delivery by external agent (consignment issue)
EDKO	Correction
KAZU	Consignment pick-up
KRZU	Consignment returns

Delivery Order Processing (MAIS)

In the MAIS procedure, the customer transmits information to the component supplier and forwarding agent in a pick-up sheet (similar to a just-in-time delivery schedule).

Delivery order processing has been designed to optimize shipping control by providing:

• An efficient source of information for the customer, component supplier, and forwarding agent
• A simple process for ordering and receiving materials from the component supplier
• A secure basis for planning

Because of the high volume of quantities managed in KANBAN, we recommend you do not use KANBAN with delivery order processing.

Process flow

1. You have an existing outline agreement with the customer, in this case a special scheduling agreement for delivery order processing.
2. On the basis of this scheduling agreement, the customer prepares data for a delivery and transmits it in a pick-up sheet to you (and the forwarding agent).
• An Electronic Data Interchange (EDI) subsystem receives the incoming pick-up sheet and converts it to an intermediate document (IDoc), which is then stored in your SAP System.
3. You create a delivery order from the IDoc. 
1. Information in the delivery order is supplied either by the IDoc or entered manually from the pick-up sheet. The system determines the related scheduling agreement from this data and generates schedule lines in the delivery order according to the customer requirements. The delivery order is processed in the same way as a standard order.
4. You create a standard delivery to prepare the items for pick-up.A delivery is created for each unloading point.
5. The customer’s forwarding agent picks up the materials at the scheduled time.
6. The delivery is invoiced . The customer refers to the pick-up sheet number in the billing document to settle payment.
   

The pick-up sheet is used in a similar way to a just-in-time (JIT) delivery schedule. There are, however, several important differences:

• Pick-up sheets can contain more than one material from one or several scheduling agreements.
• Unlike the JIT delivery schedule, which is continually updated, the quantities and dates in the pick-up sheet are fixed. This means that the pick-up sheet must be delivered in full before it can be set to complete.
• The pick-up sheet is the central source of information for the customer, component supplier, and forwarding agent. It is the sole document that accompanies materials - making shipping douments, delivery notes, and goods issue slips unnecessary.
• JIT delivery schedules are transmitted daily. Pick-up sheets are transmitted weekly, up to three weeks before the required delivery.

Cumulative Quantity - Delivery Orders

The cumulative quantities on the left-hand side of the forecast delivery schedules are based on all of the delivery orders for the scheduling agreement. These are the:

• Total cumulative quantity
• Cumulative quantity received by the customer
• Cumulative quantity in transit

The cumulative quantities on the right-hand side of the forecast delivery schedule are calculated on the basis of the Pick-up sheet field that contains the pick-up sheet number from the latest delivery order only. These are the:

• Cumulative quantity according to the pick-up sheet number
• Cumulative quantity in transit according to the pick-up sheet number

When maintaining cumulative quantities, note that:

• The system does not adjust the cumulative quantity when you cancel an item in the forecast delivery schedule, or create a return based on a delivery order. You must do this manually. 
• The standard system contains a sales document type and two item categories for this purpose:
• Sales document type MAKO
• Item category MAK for positive corrections
• Item category MAK1 for negative correction
• When the customer posts goods receipt, their cumulative quantities are updated. For this reason, you should correct your cumulative quantities only when the customer sends the items back without having posted goods receipt.
• For a year change, you must post cumulative quantities to a different period to the one in which they are reported. To do this, change the cumulative quantity date to match the pick-up date. A new field, Cml qty date (cumulative delivery order quantity date), has been designed for this purpose in the delivery order header for sales.

Cumulative quantities in the scheduling agreement are based on delivery orders, not deliveries.

If you are correcting cumulative quantities on the basis of a return, use the special return for delivery orders (type RM ). Correct cumulative quantities only when the customer has not posted goods receipt.

Intermediate Documents for Delivery Orders

ORDERS 03 is the pick-up sheet IDoc used in delivery order processing.

Delivery Orders

• Sales document type TAM
• Item category TAMA

Planning Delivery Schedule Processing

The planning delivery schedule is an internal delivery schedule that has been designed to help you:

• Plan requirements for future periods not covered by forecast and JIT delivery schedules
• Plan requirements when weekly or monthly delivery schedules sent in by the customer are not detailed enough, and are therefore unsuitable for planning
• Plan requirements independently of inaccurate or unreliable forecast delivery schedules sent in by the customer
• Plan requirements in advance, before having even received forecast delivery schedules from a customer

We create planning delivery schedules 

1. manually from internal data or 
• You can, however, use sources other than the scheduling agreement, such as data from Sales and Operations Planning (SOP) .
2. by splitting weekly and monthly schedule lines sent in by the customer into daily schedule lines tailored to your company's shipping and planning processes.
• Later, the customer sends in a forecast delivery schedule, which is entered manually or introduced into the scheduling agreement by intermediate document (IDoc). 
• You use the forecast delivery schedule to generate a new planning delivery schedule. Here, the system overwrites schedule lines in your previous planning delivery schedule with actual customer requirements. This is done only for schedule lines within a specific time frame, which you specify. You can reuse schedule lines from the previous planning delivery schedule in the new one for periods not covered by the forecast delivery schedule.

In addition to this main feature, planning delivery schedules have the same standard functions available in the forecast and JIT delivery schedules. 

Maintaining Instructions in Customizing

 The planning delivery schedule instruction contains the set of characteristics that control how planning delivery schedules are created. You must enter an instruction in the scheduling agreement in order to create or change planning delivery schedules.

In Customizing for Sales and Distribution, choose Sales Sales Documents Scheduling Agreements with Delivery Schedules Maintain planning delivery sched. instruct./splitting rules

User Exits for Planning Delivery Schedules

EXIT_SAPFV45L_001

This user exit enables you to change schedule lines once the system has generated a planning delivery schedule. You can:

• Even out the results of the planning delivery schedule generation (for example, by averaging schedule lines)
• Project data into the future (for example by using known trends in dates and quantities)
• Introduce data into the planning delivery schedule that is external to the scheduling agreement, such as data from Sales and Operations Planning (SOP)

EXIT_SAPFV45L_002

• Using holiday rules, which you assign to each splitting rule, you can control how the system handles schedule lines that fall on a holiday.
• Schedule line dates are requested delivery dates. For this reason, the system checks each generated schedule line against the ship-to party calendar to determine if it falls on a holiday. The system uses the calendar stored in the scheduling agreement item for the unloading point.
• With this user exit, you can set the system to access another calendar at the start of the splitting process. 
• This user exit is useful when there is no calendar available (for example, when no unloading point has been specified for the item).

Requirements and Delivery Relevance in Planning Delivery Schedules

Requirements and delivery relevance in delivery schedules is influenced by the document type , and the schedule line category , which the system determines using the requirements planning indicator specified in the scheduling agreement header.

The SAP System contains the following settings for the requirements and delivery relevance indicator:

• Blank - Delivery schedules are not used.
• A - Only forecast delivery schedules are relevant for requirements planning.
• B - Forecast delivery schedules and JIT delivery schedules are relevant for requirements planning and delivery.
• C - Only forecast delivery schedules are relevant for requirements planning.Only JIT delivery schedules are relevant for delivery.
• D - Forecast delivery schedules and JIT delivery schedules are relevant for requirements planning.Only JIT delivery schedules are relevant for delivery.
• E - JIT delivery schedules are not used.

Planning delivery schedules replace forecast delivery schedules for requirements and, in some cases, delivery relevance when you enter a planning delivery schedule instruction in the scheduling agreement item. 

• For this reason, we recommend that you remove the instruction if you do not regularly create or maintain planning delivery schedules in the scheduling agreement. This ensures that schedule lines in the planning delivery schedule do not affect the requirements and delivery relevance of the other types of delivery schedules in the scheduling agreement.

To decide which type of delivery schedule is currently relevant for requirements and delivery, the system uses the JIT delivery schedule horizon, the material requirements planning indicator in the scheduling agreement header, and the delivery relevance indicator in the planning delivery schedule instruction. A more precise method for determining relevance is not yet available.

When there is a planning delivery schedule in a scheduling agreement, the system determines the relevance for requirements as follows:

1. MRP indicator B or D
• Up to the JIT delivery schedule horizon, the JIT delivery schedule is relevant for requirements.
• After the JIT delivery schedule horizon, the planning delivery schedule is relevant for requirements.
2. MRP indicator A or C
• The JIT delivery schedule is not relevant for requirements.

The planning delivery schedule is relevant for requirements (independent of the JIT delivery schedule horizon). 

The system determines the relevance for delivery as follows:

1. The delivery relevance indicator has been set to “yes” in the planning delivery schedule instruction
• Up to the JIT delivery schedule horizon, the JIT delivery schedule is relevant for delivery.
• After the JIT delivery schedule horizon, the planning delivery schedule is relevant for delivery.
2. The delivery relevance indicator has been set to “no” in the planning delivery schedule instruction – MRP indicator A or B
• Up to the JIT delivery schedule horizon, the JIT delivery schedule is relevant for delivery.
• After the JIT delivery schedule horizon, the forecast delivery schedule is relevant for delivery.
3. The delivery relevance indicator has been set to “no” in the planning delivery schedule instruction – MRP indicator C or D
• Up to the JIT delivery schedule horizon, the JIT delivery schedule is relevant for delivery.
• Schedule lines occurring after the JIT delivery schedule horizon are not relevant for delivery.

Useful information

515337 - Identical scheduling agreements can be created w/o message

The check for identical scheduling agreements is triggered if you change field VBAK-KTEXT.

Another result of the attached corrections is that the following fields are saved in uppercase letters when you save the document:

• VLPKM-ABLAD Unloading point
• VLPKM-KDMAT Material belonging to the customer
• VLPKM-KNREF Customer description of partner (plant, storage location)
• VLPKM-KTEXT Search term for a product proposal

Remark:

• In the case of a mixed update of one of the above fields by using uppercase and lowercase letters, you must reorganize index table VLPKM by using report RVV05IVB ('Sales documents' box: 'Scheduling agrmnts/UnloadingPt'). You can reorganize the index for individual sales documents.

399819 - IDoc: Go-ahead starts are not updated

If you use IDocs of base type DELFOR01 and logic output DELINS, you have two options to transfer the end of go-ahead for a material or production:

1. Direct transfer of the end of material or production go-ahead

2. Calculation of the end from the start and the runtime of the go-ahead

Ad 1: Direct transfer of the end of go-ahead

           The end of material or production go-ahead (VBLB-ABMDE or VBLB-ABFDE) is transferred directly in field ABMDE or ABFDE in segment type E1EDP10 ('IDoc: Item data LAB/FAB component supplier). This transfer has priority compared to the calculation of the end from the beginning and the runtime of the go-ahead.

Ad 2: Calculation from the beginning and the runtime of the go-ahead

           If the end of the go-ahead is not transferred directly, the system calculates the end of the material or production go-ahead providing the runtime of the go-ahead is transferred.

Since the start of the go-ahead (VBLB-ABMDA or VBLB-ABFDA) cannot be transferred in the IDoc, this is copied from the order date of the IDoc (segment type E1EDK09, 'IDoc: Header data LAB/FAB for component supplier plus user field', field BSTDK) which also supplies the go-ahead date (VBLB-ABRDT). The runtime of the go-ahead (VBLB-MFLAUF or VBLB-FFLAUF) and its unit (VBLB-MFEIN or VBLB-FFEIN) are transferred via the corresponding fields of the IDoc (segment type E1EDK09, fields MFLAUF or FFLAUF and MFEIN or FFEIN).

If no unit is transferred for the runtime, it receives the default value '3' ('Month').

378144 - Scheduling agreements with third-party order processing

As described in the documentation for the sales and distribution processing in chapter "Scheduling agreement for component suppliers (SD-SLS-OA-SCH)" there are following restrictions when you work with scheduling agreements: The scheduling agreement with releases is not supported in the assembly or third-party order processing.

For the third-party order processing in scheduling agreements with releases there is meanwhile a consulting solution in the automotive. You will find all relevant information in Note 633503.

719913 - Product allocation with scheduling agreements

The product allocation is not supported for component supplier agreements.

2004476 - Possible causes of incorrect requirement transfer from SD scheduling agreements

To avoid incorrect requirement transfers, observe the following recommendations for maintaining SD SAs.

1. Make sure that forecast delivery schedules (FDSs) and JIT delivery schedules are always compatible with each other. That is true especially for SAs with release MRP indicator A ("Requiremnts acc. to fore.dlv.sched/Delivery acc. to validity"), B ("Requirements and deliveries according to validity"), and D ("Requirements acc. to validity/Deliveries acc. to JIT"). 

The FDS and JIT delivery schedule are mutually compatible if the cumulative released quantities of both delivery schedules are identical at the time of the JIT delivery schedule horizon. 

This compatibility ensures that the requirement quantities that have been reduced by the deliveries and the open delivery quantities that have been reduced by the deliveries from both delivery schedule types match each other at the time of the JIT delivery schedule horizon. 

That enables correct requirement transfers from the FDS after the JIT delivery schedule has been delivered completely and loses its relevance. If you do not maintain the compatibility between the FDS and the JIT delivery schedule, requirements that are slightly too high may be issued (to guarantee the delivery capability of the component supplier).

2. Generate planning delivery schedules (PDSs) in a timely manner after creating a new FDS, if you have not specified automatic generation of the PDSs in customizing. This is true especially for SAs that contain all three contract release types (FDS, PDS, JIT delivery schedule) and for planning delivery schedule instructions (PDS instructions) that do not transfer the delivery relevance to the planning delivery schedule lines (the indicator TVZP-PLALI is not set in the PDS instruction customizing). 

Otherwise, the FDS and the PDS do not match each other, which may lead to inconsistencies in requirement transfers, especially after the expiration of the JIT delivery schedule horizon. Generally, the system issues requirements that are too high (to guarantee the delivery capability of the component supplier). The easiest way to solve this problem is to set the automatic generation of the PDS in the PDS instruction after the arrival of the FDS (the indicator TVZP-ASPAU is set in the PDS instruction customizing).

3. Always maintain FDSs and JIT delivery schedules with reference to the proposal for the cumulative quantity received by customer (cumulative received quantity) right away. 

If, in the past, the customer always sent a cumulative received quantity in IDoc but no longer does that, the system considers the current cumulative received quantity to be zero. 

The five most recent IDocs are checked to determine whether the customer normally sends cumulative received quantities and really means the number zero. However, the customer may make a change so that the cumulative received quantities are no longer sent, and the system must produce a cumulative received quantities proposal. 

Instead, the system transfers only one contract release type. If this is the case, another old cumulative received quantity may still exist in another contract release type. That can cause one delivery schedule type, but not the other, to use the cumulative received quantities proposal function. That must be avoided because the cumulative received quantity directly influences both quantities in transit and open quantities, and the inconsistencies in open quantities cause incorrect requirement transfers. Always make sure that the function for proposing cumulative received quantities is activated either in both contract release types (FDS and JIT delivery schedule) or in neither. If need be, you can use the cumulative received quantity proposal button to activate this function on the screen of the delivery schedule concerned in transaction VA32. See SAP Notes 197774, 202505, 212794, 440140, 458965, and 488958 as well. They contain significant consultation sections that are also applicable to higher releases (than indicated in the validity of these SAP Notes).

4. Create a dummy delivery schedule for each contract release type used if you change the fiscal year change variant. The customer may have sent JIT delivery schedules in the past but no longer sends them. Now you change the fiscal year change variant (for example from A to B or C) and continue working only with FDSs. FDSs are then entered without fiscal years, but the outdated JIT delivery schedule still has fiscal years. This constellation may lead to incorrect requirements. After changing the fiscal year change variant, create a dummy JIT delivery schedule manually so that JIT delivery schedules also contain no more fiscal years. The same is true the other way around. If the customer has sent an FDS but now sends only JIT delivery schedules and you change the fiscal year change variant, you must create a dummy FDS so that the FDS switches over to the new logic as well.

5. When you change an FDS, adjust the PDS as quickly as possible. If you change an FDS manually in transaction VA32 and also have a PDS for it, the PDS is not adjusted when you save the SA. That is also the case when the PDS is automatically generated because no new FDS was created. That may lead to incorrect requirement transfers, especially if the PDS instruction does not transfer the delivery relevance to the PDS schedule lines (indicator TVZP-PLALI is not set in the PDS instruction customizing). The system expects that the PDS is always a copy of the FDS that has been adjusted for internal purposes. If, for instance, you change a schedule line quantity in the FDS, you must make a corresponding change in the PDS as well. Otherwise, the quantities deviate from each other, which may cause inconsistencies in requirement transfers.

1817442 - Customer consignment stay time report

Classical processing with external service agents (ESA):

- Mapped between the OEM, the component supplier, and an ESA

- The supplier receives forecast delivery schedules from the OEM and enters them into its sales scheduling.

- The forecast delivery schedules provide the basis for requirements planning and supply to the ESA's warehouse.

- The ESA is presented in SAP ERP as a special stock partner.

- The goods are withdrawn from the ESA warehouse and delivered to the OEM.

Stay times

- The length of time that the goods of a shipment involving external service agent stay in the ESA storage

Calculation logic of stay times

- Match unrestricted-use stock with the shipments according to the FIFO principle.

- Calculate stay times if there is a rest quantity from the shipment involving ESA

- Stay times = current date - posting date of shipment involving ESA

1050646 - EDL customer consignment with external service provider (classical) - plant level

You want to use the process of the classic processing with external service agents (ESA) between an original equipment manufacturer (OEM), a component supplier and an ESA/ESP. Delivery schedules that are received by OEM are processed in the sales scheduling agreement, and the MM procurement scheduling agreement is used to transfer delivery schedules to the delivering plant. Here, the delivery schedules are the basis for materials planning and consignment fill-up of the ESA/ESP warehouse. ESA/ESP is mapped as individual "PLANT" in the SAP system. The service agent/service provider can transfer the following:

- Notifications of goods receipt

- ESP withdrawal messages

- Stock reports

The notification of goods receipt can be used for the comparison with the data of the consignment fill-up of the ESA/ESP warehouse and is the basis for mapping of transit quantities. Due to the ESP withdrawal message, the stock of the ESA/ESP warehouses is reduced and the billing to the OEM is initiated. To synchronize the stock situation, you can use the stock report.

Selection of functions:

Monitor for inbound shipping notification

- SAP standard processing

Monitor for inbound ESA/ESP of goods receipt confirmations

- SAP standard processing

Monitor for inbound ESP withdrawal messages

- Individual processing logic by "Z" function module

Monitor for inbound ESA stock reports

- Individual processing logic by "Z" function module

1050468 - Smart external service provider (customer consignment) - special stock partner level 

The process "smart External Service Provider" is to be mapped between OEM SMART, a component supplier and an ESA/ESP. Forecast delivery schedules received from SMART are included in the sales scheduling agreement of the component supplier. The current stock situation, the agreed VMI minimum limits and maximum limits and the forecast delivery schedules are the basis for the materials planning and the consignment fill-up of the ESA/ESP warehouse. ESA/ESP is mapped as special stock partner in the SAP system.

From the ESA/ESP or SMART, the EDI messages are transferred to the component supplier using various posting keys, for example for the following:

Goods receipt confirmations, stock reports, stock removal quantity from ESA/ESP to the SMART tape, SMART parts consumption confirmation (ESP withdrawal reports) and so on

to the component supplier.

This solution provides automatic processing for SMART and ESA/ESP EDI messages.

The goods receipt confirmation is used for the comparison with the data of the consignment fill-up of the ESA/ESP warehouse and is the basis for mapping transit stocks.

To synchronize the stock situation, you can use the stock report for ESA/ESP.

For automatic stock posting during removal from ESA/ESP warehouse to the SMART tape, the ESA/ESP stock removal message confirmation is used.

Due to the smart parts consumption confirmation/withdrawal confirmation from the SMART tape stock, the SMART tape stock is reduced and the internal billing document for the self-billing procedure is created.

You want that various stocks in the component supplier system can be displayed and monitored (for example, ESA/ESP stock/SMART tape stock/ and so on)

For a VMI consignment fill-up (in line with the minimum and maximum limits) at the ESA/ESP warehouse, an SAP ACS is available for SMART, for example for taking transit stock, ESA/ESP stock and tape stock into account.

Selection of functions:

Monitor for inbound ESA/ESP of goods receipts

- Individual processing logic by "Z" function module

Monitor for inbound ESA/ESP removals

- Individual processing logic by "Z" function module

Monitor for incoming smart parts consumption confirmations

- Enhancement of SAP standard processing of withdrawal confirmation

Monitor for inbound ESA stock reports

- Individual processing logic by "Z" function module

VMI processing for taking into account the minimum and maximum parameters

- Individual processing logic

787530 - VMI processing with EDI integration in Sales and Distribution

Process description:

Process "VMI Processing with EDI Integration" allows automatic processing of VMI information using EDI. The following processes:

1. Consignment fill-up of the ESA/ESP warehouse to the customer consignment stock (ESA, ESP, LSP)

2. Direct shipment without consignment

can be mapped using this solution.

Forecast delivery schedules (optional) that are received by the customer are included in the sales scheduling agreement of the supplier. VMI information that is received by the customer (IDoc PROACT) can be automatically stored in a VMI master data table. Due to the stock situation at the component supplier or the customer/ESA/ESP and taking into account adjusted parameters (for example, minimum stock level, maximum stock level), the component supplier carries out the consignment fill-up of the ESA/ESP warehouse.

You can specify VMI parameters, for example, minimum stock level, reorder point and maximum stock level, in a VMI master data table for each sold-to party/ship-to party/material. Various fields can be automatically updated using IDocs after the VMI message by the customer. You can use a program to select all VMI-relevant scheduling agreements (you can restrict according to planning delivery schedule instruction, for example), and to create a planning delivery schedule from the forecast delivery schedule. Here, the data is copied from the forecast delivery schedule and enhanced with a 'VMI schedule line'. The quantity for this "VMI schedule line" is calculated on the basis of the stock information that is made available by the customer and on the basis of your own stock at the ESA/ESP and the VMI parameters. You can use the MRP relevance and the delivery relevance of the "VMI schedule line" to enrich the materials planning with requirements and to enable a consignment fill-up (delivery creation).

Selection of functions:

- Flexible process control (sold-to party, material, planning delivery schedule instruction)

- Including/ overriding the backlog/immediate requirements from the forecast delivery schedule during the planning delivery schedule generation

- Two calculation logics (stock/range of coverage)

- Dynamic calculation of consumption with range of coverage logic

- Fixed replenishment quantity or rounding, for example, due to lot size/handling units

- Various stock key figures can be individually taken into account to map the total stock in accordance with the customer logic (customer stock free, in quality, locked; consignment stock free, in quality, locked).

- You can optionally include your "own customer consignment stock" for customer consignment processes (ESA/ESP).

- Stopping functions during inbound processing of the VMI message, for example, when the customer changes the minimum/maximum parameters.

- Simulation of processing

- Extensive results log

687513 - EDL customer consignment with external service provider (classical) - special stock partner level

Implement the "Customer Consignment with External Service Provider (classical)" Automative Consulting Solution.

You want to use the process of the classic processing with ESA/ESP between an original equipment manufacturer (OEM), a component supplier and an ESA/ESP. 

• Delivery schedules received by the OEM are included in the sales scheduling agreement of the component supplier. 
• These delivery schedules are the basis for materials planning and consignment fill-up of the ESA/ESP warehouse. 
• ESA/ESP is mapped as "special stock partner" in the SAP system. The service agent/service provider can transfer

- Notifications of goods receipt

- ESP withdrawal messages

- Stock reports

to the component supplier. 

• The notification of goods receipt is used for the comparison with the data of the consignment fill-up of the ESA/ESP warehouse and is the basis for mapping transit stocks. Due to the ESP withdrawal message, the stock of the ESA/ESP warehouses is reduced and the billing to the OEM is initiated. To synchronize the stock situation, you can use the stock report.

Selection of functions:

• Monitor for inbound ESA/ESP of goods receipts
• - Individual processing logic by "Z" function module
• Monitor for inbound ESP withdrawals
• - Enhancement of SAP standard processing
• Monitor for inbound ESA/ESP stock reports
• - Individual processing logic by "Z" function module

633508 - Delivery service level reporting in Sales and Distribution

Implementation of the 'Delivery service level - self-evaluation (SD)' Automotive Consulting solution

The reportings for the "Delivery Service Level" do not offer the option to make your own transparent statements with regard to the supplier delivery performance rating/overdue items. The reportings can be used, for example, as part of

- Certifications (ISO9000, ISO/TS 16949)

- Self-evaluation in comparison to the vendor evaluation (quantity reliability/schedule reliability) of the customer.

- Evaluations of plant deliveries in a group.

- Determination of delivery potential/sales potential.

The term "delivery service level" is a synonym for "delivery reliability", "measurement of delivery fulfillment", "vendor self-evaluation delivery service", delivery quota calculation", "delivery performance", "KPI delivery performance".

Concept of the solution:

- When you create the delivery, the system logs the "current state" of the schedule line in a separate table. This way, you can ensure that, for example, the "current state" at the time of the delivery creation is also logged with changed schedule lines (quantities and dates) due to a forecast/JIT delivery schedule inbound.

- With the help of an additional program, the system valuates the individual scheduling lines records occurs according to criteria that can be set in the subsequent processing (performance). You can also perform a "revaluation", for example, due to changed valuation criteria.

- You can use a display transaction to display different views (summarization) on the valuated data records. ACTUAL quantities and dates can be compared to the TARGET quantities here. This way, you have the option to compare the goods issue date and the goods issue quantity with the schedule lines (quantity and date) from the relevant SD document.

Assessable delivery scenarios

- Delivery of standard order, rush order, sample order, and so on.

- Delivery of the delivery order

- Delivery of scheduling agreements without delivery schedules

- Delivery of scheduling agreements with delivery schedules (forecast/JIT/planning delivery schedules)

- Delivery of scheduling agreements with reference to outline agreements

- Delivery of summarized JIT calls

- Delivery of sequenced JIT calls

- Delivery of the external service provider/logistics service provider (filling of the external service provider/logistics service provider warehouse)

- Delivery in intercompany sales.

- Delivery for third-party order processing with scheduling agreements/standard orders via SAP ACS -> measurement possible. Delivery for the third-party order processing with standard order in the SAP standard measurement because there is no delivery.

- Delivery of stock transport orders

- Delivery of stock transport scheduling agreements

Selection of functions

- Measurement of the date requested by customer and/or person confirming the date (ATP).

- Measurement delivery service level with or without backorder processing.

- Output/selection for overall delivery service level (quantity and schedule), quantity reliability and schedule reliability

- Excel download

- Reevaluation of the data, for example due to changed Customizing or subsequent master data maintenance possible.

- Summarization according to, for example, sold-to party, sales organization, plant.

- Basis for the evaluation with SAP BW created (SAP BW evaluations are not delivered in the the scope of SAP ACS).

- Delete program, for example for evaluated/cumulated data records.

- Performance aspects taken into account, for example 5000 deliveries with an item are created each day. Deliveries with 500 items each are created. In return each delivery item may reference to 50 scheduling lines in the order.)

- Customizing partially to the level of the sold-to party/ship-to party

- Supersession (product replacement)

2670422 - No BOM explosion occurs in scheduling agreements for suppliers

The BOM explosion is not supported in scheduling agreements with delivery schedules. The reason for this is the impossibility of correct counting the cumulative quantities in scheduling agreements with delivery schedules in the case of configuration and assigning these quantities to sub-items in the case of BOM.

633503 - Third-party: Third-party order processing with scheduling agreements

Implement the 'Third-party order processing with scheduling agreements' Automotive Consulting solution

The process of the third-party order processing between an OEM supplier and a third-party vendor should be implemented with sales and purchasing scheduling agreements from the viewpoint of the component supplier and third-party vendor. 

• The forecast/JIT delivery schedules received from the OEM are included in the sales scheduling agreement of the component supplier and transferred from the purchasing scheduling agreement of the component supplier to the third-party supplier by means of forecast/JIT delivery schedules. 
• The deliveries of the third-party supplier (shipping notifications) to the OEM must be processed with reference to the purchasing/sales scheduling agreement in the component supplier system. 
• The monitoring and possible troubleshooting can occur by means of a 'Monitor for third-party order processing'. 
• An invoice creation to the OEM occurs in the component supplier system based on the shipping notification of the third-party supplier.

Supported scenarios:

- Third-party order processing with scheduling agreements (forecast/JIT delivery schedules)

- Third-party order processing with scheduling agreements and summarized JIT calls

- Third-party order processing with scheduling agreements and sequenced delivery schedules

- Third-party order processing with scheduling agreements and subcontracting

- Third-party order processing with scheduling agreements and external service agents/LDL

- Third-party order processing with scheduling agreements, summarized JIT calls and external service agents/LDL

- Third-party order processing with scheduling agreements and external service agents/LDL as subcontractors

- Third-party order processing with scheduling agreements and SAP APO (CMDS)