ANALYSE_PROFIL – analyzes the transfer profile with regard to the periodicity BESTIMMEN_ABRUF_NR – determines the version number FUELLEN_KOPF – creates new EKEK records FUELLEN_EINTEILUNGEN_NEU – creates new EKEH records for Ameng (without versioning profile) AGGREGIEREN_EINTEILUNGEN_NEU – aggregates the planning lines The system saves a transmitted version with a version number and includes the document in the version history. The system then generates the next version of that particular version type with a number increased by one. JIT forecast plans and calendars have separate number ranges. The prerequisite for automatically creating schedule lines during DEMAND scheduling is that a schedule agreement is marked as relevant to MRP in the source list. You can do this in the Purchases menu: Master Data -> Maintain the list of sources -> (transaction ME01). You must keep a record for the material here and in this register, the `DISPOSITION` field must contain the indicator `2`. Messages for scheduling the delivery dates of the agreement in the standard: Each time the system creates a version, it calculates the next transfer date for periodic transmission based on the date. As soon as the S-items are created and saved, they are not automatically transmitted to the supplier, we must release these S.lines via JIT/FRC release backlog: Quantities with a delivery date in the past, which have been transmitted to the supplier by means of a planning agreement, but have not yet been delivered Immediate request: Quantities required immediately (today or before), but not yet transmitted to the supplier by means of a release planning agreement Were. You can set the flag only once for each version type. Task `9` corresponds to the planned planning agreement and task `A` corresponds to the JIT planning agreement. Example (OMQP transaction): Release/Expediter -> Fine-Tuned Control: Forecast Delivery Schedule/Expediter. You should always use the main message type to create all versions, otherwise the system will not update the print-dependent data. This is especially important if you are using several different types of messages.
3) What is the customization path and how to configure it in both cases (with version documentation and without version documentation) A versioning profile is used to determine the period during which versions (types of planning agreements) are generated in relation to a planning agreement and passed to the provider. This also controls the frequency of versioning; the aggregation of the quantities provided for from the day following the creation of the release; and the conduct of a tolerance test. Those who work with the traditional approach to customizing scheduling agreements in SAP know that defining types and categories, as well as managing versioning profiles, can be a problem if you don`t know what you`re doing. The above information should prove useful for those working in procurement and as an introduction to those who are just starting out with SAP. Once the system has released the version with the main message type (see explanation below), the `Release Date` and `Release Time` fields are filled in. Another important detail that is updated at this point is the reset of the Modified flag in the planning agreement line. This means that once a version has been issued, the relevant planning agreement element is not considered « Modified » (compared to the overall planning agreement in the system) until you, when the system issues a message, some updates take place that mark the version as « completed and released ». If the system has not yet issued a version as a message, the last version that the system has not yet issued is replaced each time another version is generated. If there are messages for the scheduling agreement that have not been issued and you then set the « Messages per call » flag, you can still find the messages that were not -> output overload messages.
The newly created messages can be found in the version documentation (ME38 -> select the corresponding item -> the SA version documentation. -> select the corresponding version -> messages per version). You can find more details in the documentation under the following link Prerequisites for transmitting schedule agreement versions as messages to the provider: Starting with version 4.0, you must define exactly one message type as the « primary message type » for each version type in Customizing for MM, Message Determination for Scheduling Agreements. The `U` (Update print-dependent data) field must be marked for the relevant message type in Customizing for Materials Management -> Purchasing -> Messages -> Output Control -> Message Types -> Define Message Types for Scheduling Agreement 2) I have heard planning agreements with or with our release documentation, when can the publishing documentation apply `with` and when the version documentation `without` can apply. In this step, a versioning profile for planning agreements is preserved with a publishing document. This profile determines the versioning strategy and how the backlog and immediate requirements are taken into account when creating versions. To manage the versioning profile, go to IMG (SPRO) > Materials Management > Purchasing > Scheduling Agreement > Maintain Release Creation Profile for SA with Release Document. Planning agreements are defined and managed in the system as documents.
It is possible to group these documents between different types of documents according to the needs of the company. First, you need to define the document types and their attributes in Customizing. . . .
