A scheduling agreement is a longer-term arrangement with the vendor covering the supply of

materials subject to predetermined conditions.

The conditions are valid for a predefined period and predefined total purchase quantity. Scheduling
agreement s has several advantages:

1. Using scheduling agreements enables you to reduce processing times and the amount of
paperwork within the enterprise. A delivery schedule issued against a scheduling
agreement can replace a large number of standard purchase orders or contract release
orders.
2. Scheduling agreement delivery schedule lines do not constitute an independent
document but are part of the scheduling agreement.
3. Procurement via scheduling agreements thus enables to reduce the volume of document
used.
4. Volumes of stock on hand can be reduced to a minimum through application of the Just-in-
Time (JIT) principle, involving the specification of exact delivery time-spots. The vendors’
lead times are reduced. It is not necessary to deliver the entire quantity covered by
the scheduling agreement at once; instead, a series of smaller quantities can be delivered
in accordance with the delivery schedule lines.

In this case, the vendors can receive due notification of such required quantities and delivery dates
and times well in advance
Scheduling agreement release
documentation
Purpose

The purpose of this wiki is to introduce the Scheduling Agreement Release processing.

Overview

Overall process
Scheduling agreement processing consists of three main steps:
-Material requirements planning
-Release generation (FRC/JIT)
-Output/Transmission of releases

The main points of this wiki are:

 1. Material Requirements Planning

 2. Release types / Release generation
 3. Output / transmission of releases
 4. Creation Profile
 5. Programs
 6. Related SAP Notes/KBAs

1. Material Requirements Planning

The current overall delivery schedule for a material that is procured via scheduling
agreement releases changes continuously during an MRP run due to the requirements for
that material (dependent requirements and so on). This results in quantities and delivery dates
that are to be transmitted to the vendor in the form of releases against the relevant scheduling
agreement.

The prerequisite for automatic creation of schedule lines during requirements planning is that
a scheduling agreement is flagged as MRP-relevant in the source list. You can do this in the
Purchasing menu: Master data -> Source list -> Maintain (transaction ME01).
You must maintain a record for the material here and in this record, the field 'MRP' must
contain the indicator '2'.

The schedule lines created by the MRP run are assigned creation indicator 'B' and are
contained in table EKET in field ESTKZ.
In contrast, manually created schedule lines are assigned creation indicator 'R'.
Another difference between manual schedule lines and schedule lines from requirements
planning is that you can only enter a time for manual schedule lines.
2. Release types / Release generation

Basically, release generation 'translates' the current overall delivery schedule in the system
into a release. Releases inform the vendor of which quantities of a material are to be
delivered on which date. The individual releases are recorded using the release
documentation and can therefore be displayed at any time.

You can only create releases for scheduling agreements with release documentation.
(Document type in the standard system is LPA or the Release docu. indicator must be flagged
in Customizing for Purchasing -> Scheduling Agreement -> Define Document Types.)

Note:
There is no release documentation for stock transport scheduling agreements. Even if the
Release docu. indicator is flagged for document type LU in Customizing, it has no effect.

Types of releases

Forecast delivery schedule (FRC)

Provides the vendor with information over the longer term about which quantities of a
material are to be delivered on which date. Delivery dates are usually specified as calendar
months or weeks.

JIT delivery schedule (JIT)

Provides the vendor with information about which quantities of a material are to be delivered
at which point in time in the near future. Exact delivery dates (calendar days) or even
delivery times are usually specified.

The suggested quantity for goods receipts is based on the last delivery relevant release
transmitted. If you use both types of release, the system suggests the data in the JIT schedule.
If you use only the forecast schedule, the system suggests the data in the forecast schedule.

Note:
In order to work with JIT delivery schedules, you must have set the JIT schedule indicator
in the material master record (MARC-FABKZ) and this will be copied in the item while
creating a scheduling agreement. (You do this on the 'Purchasing' view or on the 'MRP 2'
view of the material master record.) This indicator controls whether JIT delivery schedules
can be created for a material in addition to forecast schedules.
It is also possible to enter the field FABKZ manually on the additional data screen in the
scheduling agreement.

Tables:

EKEK (Header Data for Scheduling Agreement Releases)

EKEH (Scheduling Agreement Release Documentation)

Possible cause of error: Customer cannot create any JIT schedules

If you have set the JIT schedule indicator in the material master record and the scheduling
agreement had, however, already been created, you cannot create any JIT schedules for this
scheduling agreement. Check if there are any change documents in the material master record
for the JIT schedule indicator and check when the scheduling agreement item was created.
You can also enter this indicator manually in ME32L on the additional data screen.

You can use creation profiles to influence the quantities and dates transmitted. You
configure a creation profile in Customizing for Purchasing by choosing Scheduling
Agreement -> Maint. Rel. Creation Profile for Sched. Agmt. w. Rel. Docu. (transaction
OMUP). We will go into more detail on these Customizing settings later.

The system stores a transmitted release with a release number and includes the document in
the release 'history'. The system then generates the next release of that particular release type
with a number increased by one.
Forecast schedules and JIT schedules have separate number ranges.

Creating a release:

You can create releases using a report RM06EFLB (transaction ME84).

You can also create releases manually. You can do this from the scheduling agreement
delivery schedule by choosing Edit -> Generate JIT sched. or Generate forc. schd. as well as
from the item overview screen of transaction ME38 by choosing Edit -> Generate JIT sched.
or Generate forc. schd.

Note:

You must note that the system does NOT carry out a tolerance check or backlog
determination when you manually create releases.
The system only aggregates scheduled quantities.

In table EKEK, field STAAB (Status of release), you can see how a release was created,
manually or by report RM06EFLB.

Release creation basically consists of the following steps:

 Conversion of the current overall delivery schedule in the system into aggregated release
dates and quantities where applicable (see also 'Creation Profile' for more information on
this)
 Creation of a release (FRC/JIT) in accordance with a particular creation strategy (for example,
next creation date reached, current overall delivery schedule has changed). You use both the
'General parameters' and the 'Creation periodicity' in the creation profile to control this. You
can prevent release creation based on a change in the current overall schedule by means of
a tolerance check, if necessary, so that minor changes compared to the last release do not
necessarily lead to the creation of a new release.
 Optional calculation or statement of backlogs and immediate requirements, if this function
is active.
 In the case of release creation 'Based on changes', optional tolerance check that only allows
creation of a release only if changes that lie outside a defined tolerance limit have occurred
since transmission of the last release.

If the system creates a release, it also creates a message record at the same time. This
message record is a prerequisite for the output and transmission of the release to the vendor.
3. Output / transmission of releases

You can process the message records for the newly created releases either immediately or in
a subsequent collective output. Messages are output immediately if transmission time '4' is
set.
Collective processing is possible if you are working with transmission time '1' (output via
RSNAST00) or '3' (output via the application-specific output program).

You create message condition records in the Purchasing menu by choosing Master data ->
Messages -> Sch. agmt. schedule -> Create.

When the system outputs a message, certain updates take place that designate the release as
'completed and output'. If the system has not yet output a release as a message, any
generation of a further release will cause the last release, which the system has not yet
output, to be overwritten.

After the system has output the release using the main message type (see below for an
explanation of this), the fields 'Output date' and 'Output time' are filled.
Another important detail that is updated at this point in time is the resetting of the 'Changed'
indicator in the scheduling agreement item. This means that after a release is output, the
scheduling agreement item in question is no longer regarded as 'Changed' (as regards the
overall delivery schedule in the system) until you

process the schedule again manually or by means of the MRP run.

The system can create a separate message for each release for a scheduling agreement item.
This means that the vendor receives one document for each release. This lets you output
releases individually or re-output releases that have already been transmitted.
In order to have the system create a separate message for each release, you must set the
indicator 'Rel. mess.' (message per release) in Customizing for Purchasing, by choosing
Messages -> Message Determination Schemas -> Define Message Schemas for Scheduling
Agreement Release/Expediter -> Assign Schema to Scheduling Agreement
Release/Expediter. You can display the messages created under these Customizing
requirements in transaction ME38 by selecting the relevant item and choosing SA Release
docu., then selecting the relevant release number and choosing Messages per release, NOT
via ME38 -> Header -> Messages.

Note:
You can only output messages created at release level via the Purchasing menu, by choosing
Outline agreement -> Scheduling agreement -> Delivery schedule -> Print/transmit
(transaction ME9E).

If there are messages for the scheduling agreement that have not been output and you
subsequently set the 'Messages per release' indicator, you can still find the messages that have
not been output via Header -> Messages. You will find newly created messages via the
release documentation (ME38 -> select the relevant item -> SA release docu. -> select the
relevant release -> Messages per release).

The system stores the messages for a release in table NAST using the following key:
Object key (this means the document number)
Item
Release type (FRC or JIT)
Release number

Prerequisites for the transmission of scheduling agreements releases as messages to the

vendor:
As of Release 4.0, you must define exactly one message type as the 'Main message type' for
each release type in Customizing for MM, Message Determination for Scheduling Agreement
Schedules. Field 'U' (Update print-dependent data) must be flagged for the message type in
question in Customizing for Materials Management -> Purchasing -> Messages -> Output
Control -> Message Types -> Define Message Types for Scheduling Agreement

Release/Expediter -> Fine-Tuned Control: Forecast Delivery Schedule/Expediter.

You must always use the main message type to create all releases, otherwise the system does
not update the print-dependent data. This is particularly important if you use several
different message types.

You can only set the indicator once for each release type. Operation '9' corresponds to the
forecast delivery schedule, and operation 'A' corresponds to the JIT delivery schedule.
Example (transaction OMQP):

Operations for Message Type U (Update Print-Dependent Data)

LPH1 x main message type for FRC

9 LPH2 additional message type
A LPJ1 x main message type for JIT
A LPJ2 additional message type

After determination of the message type that updates the print-dependent data for each
release type (that is, for each operation), you must make sure that releases are always created
with this message type (called 'main message type').
You are allowed to create a second message type in parallel, whereby the main message type
should be the one that is created first (such as LPH2 as the second message type for LPH1).

The messages for scheduling agreement delivery schedules in the standard system:

 LPH1 for FRC; updates data relevant for printing

 LPJ1 for FAB; updates data relevant for printing
 LPET for conventional scheduling agreements without release documentation
 LPMA for scheduling agreement expediters

4. Creation Profile

The extensive configuration options in the creation profile allow you to produce the most
varied results within the scope of release generation.

The creation profile is assigned to an SA item. (SA release item overview screen -> Item ->
More functions -> Additional data)
You create creation profiles in Customizing for Purchasing via Scheduling Agreement ->
Maint. Rel. Creation Profile for Sched. Agmt. w. Rel. Docu.

Creation profiles are plant-dependent and consist of the following:

 General parameters
 Aggregation horizons
 Creation periodicity
 Tolerance profile

General Parameters:

In the general parameters, you specify the following for each release type:

 If and, if so, under which conditions, the system creates a release of this type (Creation
strategy)
 If backlogs and immediate requirements are to be calculated and identified

Backlog: Quantities with a delivery date in the past that were transmitted to the vendor by
means of a scheduling agreement release, but which have not yet been delivered
Immediate requirements: Quantities that are required immediately (today or earlier) but
which have not yet been transmitted to the vendor by means of a scheduling
agreement release.
Notes on Creation Strategy:

The settings for the creation strategy in the profile of the scheduling agreement item act as a
filter for the creation strategy of the creation run.
This 'filter function' is necessary, since it makes more sense to execute the creation run using
the strategy 'Changed or next date'. This selects all scheduling agreements in the plant in
question that either indicate a change in the overall delivery schedule in the system or for
which the next transmission date is the same as or earlier than the current date.
The creation strategy in the profile now controls if, and if so, on the basis of which events the
system has to create a forecast schedule and/or a JIT schedule for each scheduling agreement
item.
Only in this way is it possible, for example, to prevent creation of both a forecast schedule
and a JIT schedule during the creation run if the overall delivery schedule for the scheduling
agreement is changed. In the example, the system should only create the forecast schedule
based on the next creation date.
Aggregation horizons:
In the 'Aggregation horizons' area, you specify for each release type which time horizon the
system uses to determine release quantities and for which periods the system aggregates the
quantities to 'period quantities', where applicable.
The example below shows how you would set the parameters in the 'Aggregation horizons'
area to transmit monthly requirements quantities for the next nine months in the forecast
schedule and daily quantities for the next ten days in the JIT schedule.

The data entered in this example results in the system determining daily quantities for the
next ten working days in the JIT schedule.

The system determines monthly quantities for the next 180 working days (= 9 months, each
containing 20 working days) in the forecast schedule.
Comment:
In the field 'Plan. ca' (Planning calendar), you can store a planning calendar. You maintain
this planning calendar in Customizing -> Materials Management -> Consumption-Based
Planning -> Master Data -> Maintain Planning Calendar.

Creation Periodicity:

In the 'Creation Periodicity' area, you specify for each release type if, and if so, at what
intervals, the system is to create a release of that type.

Every time that the system creates a release, it calculates the next transmission date for
periodic transmission based on the date.

Example:

The system is to create a forecast schedule once a month and at least one JIT schedule per
week. You need to set the parameters in the 'Creation periodicity'.

Tolerance Profile:

In the 'Tolerance Profile' area, you specify for each release type if the system checks by how
much the current release to be created differs from the last release transmitted, and if so, how
it carries out this check.

The purpose of the tolerance check is to limit the frequency of schedule updates.

Notes:

 During the tolerance check, the system compares the release schedule lines in table, not the
schedule lines in table EKET and of the latest transmitted delivery schedule (not necessarily
to the last generated delivery schedule).
 During the tolerance check, the system does not check backlogs and immediate
requirements.

Difference between individual and overall check:

The example below contains the following schedule lines:

Old schedule line Schedule line changed to the following value

Day Quantity old Quantity new

xx.xx.xx 20 40
xx.xx.xx 30 30
xx.xx.xx 40 36
-------------------------------------------------------
Total: 90 106

In the tolerance check, upper and lower tolerance limits for this period are set to 20%.
If you make these changes to the schedule lines, with a basic overall check with 20% as the
upper and lower tolerance limits, the system does not create a new release. The overall
quantity of the schedule lines was 90 pieces and after the changes the total of the new
schedule lines is 106. Therefore, the change does not exceed the 20% upper limit. 20% of 90
pieces = 18 pieces and the quantity has changed by only 16 pieces.

In this example, if you check the schedule lines individually, the system would create a
release because you have changed the quantity in the first line by more than 20% and it
therefore exceeds the tolerance limit.

5. Programs

Programs, Reports

SAPLEINL - main program for release documentation

RM06EFLB - Release generation report as of release 4.5
RM06EFAB - as of release 4.0
RM06ELAB - as of release 3.x

Function groups

MEDE - Schedule lines from MRP

EINL - release documentation

Tables

EKET - schedule lines (created by MRP, manual, BANF)

EKEH - schedule lines of the delivery schedule
EKEK - header data of all delivery schedules
EKPO - item data of the purchasing documents

Function modules

ME_CREATE_SCHEDULE_DOC - Creates FRC and JIT delivery schedules

ME_CHECK_TOLERANCE
ME_UPDATE_FROM_PRINTING - makes an update to the print relevant data
ME_UPDATE_SCHEDULE_EKPO - update of the next transmission date
ME_READ_LAST_RELEASE
ME_COMPARE_SCHEDULES

Routines (SAPLEINL) called from ME_CREATE_SCHEDULE_DOC

ANALYSE_PROFIL - analyses transmission profil regarding periodicity

BESTIMMEN_ABRUF_NR - determines release number
FUELLEN_KOPF - creates new EKEK records
FUELLEN_EINTEILUNGEN_NEU - creates new EKEH records regarding ameng (without
Release Creation Profile)
AGGREGIEREN_EINTEILUNGEN_NEU - aggregates schedule lines
MRP Source determination using
Scheduling Agreement
Purpose

The purpose of this WIKI is to explain to implement the source determination using a
scheduling agreement.

Overview

This should be an executive summary of the content and argument being made in the
document. Basically a summary (not repeat) of the information you are explaining.

S/4 HANA

The information from this WIKI is not relevant for S/4 HANA, since the source
determination logic was simplified. Refer to Note 2268069 - "S4TWL - Simplified Sourcing"
for more information about the Simplified Sourcing for S/4 HANA.

Scheduling Agreement

The first step is the creation of a scheduling agreement, that can be done on transaction
ME31.

Source List

In the source list, we must ensure that there is a reference to the scheduling agreement and
that the field 'Source List Usage in Materials Planning (MRP)' is set to '2 Record relevant to
MRP. Sched. lines generated automatically' if we want to have schedule lines created
automatically.
Frequent issues on the source determination using a Scheduling Agreement
MRP does not create schedule lines:

The most frequent causes for this issue are the following:

 Problems with validity: As explained on the WIKI https://wiki.scn.sap.com/wiki/x/mxGGGg,

MRP checks the source list validity according to the requirement date. The same logic is used
to check the scheduling agreement validity, therefore, in order to be considered for source
determination, the scheduling agreement must be valid on the requirement date;
 Flag SC Vendor is checked on the agreement: The flag SC Vendor should be used on a very
specific scenario (third party processing) and when it is set, the agreement is nor considered
on the source determination at plant level;
 Agreement with an incorrect item category: The scheduling agreement item category must
match the special procurement type defined on the material master, otherwise, the
scheduling agreement is not considered for source determination;

The following KBA provides more information about the mentioned issue and how to check
each one of the possible causes for this issue:

1967840 - MRP does not create schedule lines

The Target Quantity is not considered by MRP:

As explained on SAP Note 83343, MRP does not check the agreement target quantity and it
can create replenishment proposals exceeding this quantity: The workaround to limit the
quantity is to use a quota arrangement with a maximum quantity.
MRP Source determination using a quota
arrangement
Purpose

The purpose of this WIKI is to explain to implement the source determination for a planned
order or purchase requisition using a quota arrangement.

Overview

This WIKI will explain how to activate the automatic source of supply determination for
external procurement(vendor selection) during the MRP run using a quota arrangement. It
will also explain the most common causes for problems in this area and how to resolve such
problems.

S/4 HANA

The information from this WIKI is not relevant for S/4 HANA, since the source
determination logic was simplified. Refer to Note 2268069 - "S4TWL - Simplified Sourcing"
for more information about the Simplified Sourcing for S/4 HANA.

Quota arrangement:

A quota arrangement can be also used for the source determination on the MRP run and it is
generally used when it is necessary to split the procurement between two or more vendors.

The quota arrangement is created on transaction MEQ1 and it provides more options than the
source list, such as a quota, a maximum quantity or a minimum/maximum lot size for each
source of supply.
After the creation of the quota arrangement, a very important step to have it considered
during the MRP, is to define a proper value for the field Quota Arrangement Usage
(MARC-USEQU) on the material master.

If the quota arrangement is correctly selected by MRP, the replenishment proposals will be
directed to the different vendors, according to the percentage defined on the quota
arrangement.

Frequent issues on the source determination using a quota arrangement:

A quota arrangement is not considered by MRP:

The most frequent causes for this issue are described on the following KBA:

1508647 - MRP does not consider the quota arrangement

Quota arrangement is not selected on an MRP area:

For design reasons, MRP does not consider quota arrangements under MRP areas, however,
the system behavior can be changed with the implementation of the following note:

505667 - Modification: Reversing Note 406672