Schedule agreement release processing

-1-

Schedule agreement release processing

As of SAP R/3 Release 4.5 Overall process In simplified terms, scheduling agreement processing consists of three main steps: Material requirements planning Release generation (FRC/JIT) Output/Transmission of releases

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. Therefore the field EKPOETDRK will get a value unequal space. Is the value 1, then this does mean that the delivery schedule was created via MRP, is the value 2, then the delivery schedule was created via ME38. 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. We will not go into more detail on the individual steps of MRP here.

Schedule agreement release processing

-2-

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.) If a scheduling agreement was created under these customizing settings, the field EKKO-LPHIS has got the value X. Via this check you see very fast if you are working with LPA or LP.

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. There are the following 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 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 in the scheduling agreement item. (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.

Schedule agreement release processing

-3-

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 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. Table: EKEK (Header Data for Scheduling Agreement Releases) EKEH (Scheduling Agreement Release Documentation) When creating releases, the system reads extensive control parameters from the creation profile.

Creating a release: You can create releases using a report (RM06EFLB up to Rel. 4.5X) (intended for regular releases). Please see also note 182210 which describes which report is valid for the appropriate Release. 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. The backlog determination is only active if it is defined in the creation profile. When creating releases the function module ME_CREATE_SCHEDULE_DOC will be called (this is independent if transaction ME84 oder ME38 is used). If a creation profile is maintained in the scheduling agreement item and in this creation profile the flag Determine backlog is set, then the routine Backlog_IM_Requirements will be called.

Schedule agreement release processing

-4-

To check how a release was created (e.g. via report RM06EFLB or via transaction ME38) it is possible to look in table EKEK. In field STAAB there could be the following entries: Space: this does mean via ME38 1: this does mean via ME84 2: this does mean MDXX (transactions like MD03, MD04)

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.

Schedule agreement release processing

-5-

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). Attention: RSNAST00 can process only datasets with dispatch time 1 and 2. The report does not process data sets with dispatch time 4. You create message condition records in the Purchasing menu by choosing Master data -> Messages -> Sch. agmt. schedule -> Create. When the system outputs a message (function module ME_UPDATE_FROM_PRINTING is therefore responsible), certain updates take place that designate the release as completed and output. Therefore it is necessary that in customizing in transaction OMQP the field for Update print-dependant datafor the appropriate message type is set (T161N-DRUAB). 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 (EKPO-ETDRK is changed into space) 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. If the R/3 system is customized in that manner then we talk about message determination on release level. With this customizing setting NO change messages can be created. Technical explanation for that: Change messages can only be formed when in table NAST already an entry exists with the same objectkey. This means you can only work with change messages when in customizing the message determination is maintained at header level. Messages created under message determination at release level can be displayed in transaction ME38 by selecting

Schedule agreement release processing

-6-

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 Alle Abrufe mssen immer mit der Hauptnachrichtenart erstellt werden, da das System sonst die druckabhngigen Daten nicht aktualisiert. Dies ist insbesondere dann wichtig, wenn Sie mit verschiedenen Nachrichtenarten arbeiten. Set the flag Update print-dependant data or not? In Release 4.6B you will get an error message if you try to set this flag several for the same operation type. In Release 4.6C you get a warning message. Background for this different systembehaviour is the following: If you are working with message determination on release level then several message types for one operation could be flagged. If you work with message determination at header level then only one message type per operation should be flagged.

Schedule agreement release processing

-7-

Recommendation: 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 (e.g. main message with medium 6 for EDI and another message for medium 1 for printing which is not maintained as main message. 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) 9 9 A A LPH1 LPH2 LPJ1 LPJ2 x x main message type for FRC additional message type main message type for JIT 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). Please note: Messages which arent the main message are called auxilliary messages. These are all messages which have not set the flag for update print-dependant data. Auxilliary messages must always be output before the main message is output, when you work with message determination at header level. 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

Schedule agreement release processing

-8-

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 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.

Schedule agreement release processing

-9-

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. This means by working with transaction ME84 with the scope of select = blank determines the maximum number of scheduling agreement items. The settings in the release creation profile restrict the selection then once more. 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.

Schedule agreement release processing

- 10 -

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. Indicator: Determine backlog/imm.reqt: This indicator is also taken into account while creating a release via transaction ME84. When the flag for Determine backlog/imm.reqt is set in the release creation profile, then in table EKEK the field RUSKZ is unequal space. Explanation to the settings of the above screenshot: In the JIT schedules is the presentation of backlog/imm.reqt activated, in the forecast schedules cut off. Basically is recommended by SAP, that backlog and immediate requirement should only be presented in the delivery relevant release. Indicator: Backlog creation-relevant: This field is only relevant when transaction ME84 is used. Please note: If transaction ME84 is executed without restrictions then the settings in the release creation profile are effectless. Only the settings concerning aggregation horizons und the settings concerning internet are checked.

Schedule agreement release processing

- 11 -

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. 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 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.

Schedule agreement release processing

- 12 -

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

Schedule agreement release processing

- 13 -

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 Hints: 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. There is a User-Exit to change the results of the tolerance check, please have a look at note 506600.

Difference between individual and overall check: The example below contains the following schedule lines Old schedule line --------------------------Day Quantity old xx.xx.xx 20 xx.xx.xx 30 xx.xx.xx 40 90 Schedule line changed to the following values: -----------------------------------------------------Quantity new 40 30 36 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.

Schedule agreement release processing

- 14 -

Internet: Specifies whether the type of release created is an Internet release. Use: Internet releases are not made available to the vendor in the conventional manner as printouts of EDI or fax messages. Instead, if the Supplier Workplace is used, the vendor can view them via the Internet and acknowledge them if necessary. Dependencies: If you wish to use Internet releases, you must implement the Supplier Workplace and enable your vendors to access it via the Internet. Internet releases are displayed in the Supplier Workplace and can be acknowledged there by your vendors. Via the Acknowledgment by vendor indicator, you can specify that the Internet release does not count as "outputted" until it has been acknowledged by the vendor. If you do not set this indicator, the Internet release counts as "outputted" immediately it is created or itself released (approved). In both cases, the output date and time are updated and the Internet release is included in the release documentation. When the next release creation cycle takes place, a new release number is generated.

Schedule agreement release processing

- 15 -

Programs: SAPLEINL RM06EFLB

main program for release documentation Release generation report as of release 4.5

Function group MEDE (Scheduling Agmt. Schedule Lines from MRP): ME_UPDATE_SCHEDULES_DISPO Create scheduling agreement schedule lines from MRP

Funktionsgruppe EINM (EDI Message Output: Purchasing): IDOC_OUTPUT_DELINS Ausgabe Lieferplaneinteilungen LAB (neu ab 4.0)

Funktionsgruppe EINL (Scheduling Agreement Releases): ME_CREATE_SCHEDULE_DOC ME_READ_LAST_RELEASE fixieren des auszugebenden Lieferplanabrufs Lesen des letzten bermittelten Abrufs (hier ist insbesondere Kennzeichen FABKZ wichtig. Wenn FABKZ gesetzt, dann bringt er den letzten Feinabruf (FAB), wenn nicht gesetzt, dann ist der letzte Lieferabruf (LAB) relevant. dieser FB luft bei der Toleranzprfung, FB wird durchlaufen, wenn man sich den neueste Abruf ansieht Verbuchung der fixierten Abrufdaten; wird bei der ME84 direkt aufgerufen. Bei der ME38 wird er indirekt aufgerufen, d.h. in ME_UPDATE_SCHEDULE_DOC wird ME_UPDATE_DOCUMENT aufgerufen. Fortschreibung des nchsten bermittlungsdatums. Wird nur bei der ME84 aufgerufen und ist zustndig fr das nchste LAB/FAB Datum. Dieser FB wird nur durchlaufen, wenn mit einem Erstellungsprofil in der Lieferplanposition gearbeitet wird.

ME_SIMULATE_SCHEDULE_DOC

ME_UPDATE_SCHEDULE_DOC

ME_UPDATE_SCHEDULE_EKPO

Schedule agreement release processing

- 16 -

Funktionsgruppe MEDRUCK: Include LMEDRUCKF17 is important, because here does the output for the release takes place. Funktionsgruppe EINL: ME_CHECK_TOLERANCE Toleranzprfung bei Lieferplanabrufen

Printprogram: SAPFM06P Program ENTRY_LPHE should only be used for LPAs and not for LPs. Beginning with Rel. 4.0B the field EKPO-DRUNNR is no more longer used, but rather the field Feld EKEK-ABRUF => Therefore no gaps can exist in the release docuemdadurch.

Tables: EKET EKEH EKEK

Schedule agreement release processing

- 17 -

FAQ: While using transaction ME84 messages can drop away. Via ME84 you create at the same time JIT and forecast delivery schedules. This phenomenon can only occur when message determination is customized at header level. Solution: So that no messages can drop away you have to execute the ME84 one time for JIT and a second time for forecast delivery schedules.

Specific messages cant be output: You work with several messages at the same time and you have maintained the message determination at header level. Solution: The main message (that message which has got in customizing the flag for update print-dependant data must be printed last. Therefore you should work with dispatch time 3 for this mainmessage to make sure that this message is printed last. This difficulty concerns only LPAs. For LPs you dont work with mainmessages and auxilliary messages.

Is there a possibility to repeat printout for a release? If you are working with message determination at release level, then a repeat printout is always possible. Are you working with message determination at header level, then auxilliary messages can be repeated output as long as the main message is not output. As soon as the main message is output, then the auxilliary messages can no longer be output. A main message cant be repeated, there is only the possibility for a testprint.

When do you work with change messages for delivery schedules? Change messages could only be generated if you work with message determination at header level. You can only generate a change flag for the message if there is already existing an objectkey in table NAST. By using message determination at release level the objectkey is always unique and therefore it cant happen that there is existing the same entry yet. The objectkey is established as follows: XXXXXXXXXXYYYYYZAAAAAAAAAA X stands for purchasing document (10 digits) Y stands for item (5 digits) Z stands for release type (1 means forecast schedule line, 2 means JIT)

Schedule agreement release processing

- 18 -

A stands for release number (10 digits) Example: In table NAST we have got the following entry: 55000006270001010000000001 It is scheduling agreement 5500000627 Item 10 Release type 1 => Forecast delivery schedule Release Number 0000000001