The assortment list type divides articles subject to the same message creation cycles (for example, the intervals in which a message is created and the lead time required) into groups. An article is assigned one assortment list type at client level. The exact date on which an assortment list is created is calculated from the last creation date for the site plus the cycle time defined for the relevant assortment list type.

The recipient (site) of the message is assigned an assortment list profile that controls the assortment list mode (this determines how the message is used - for version management or for data interchange). You have the option of creating only an IDoc, passing data only to Version Management, or both.

Control parameters for creating an assortment list are grouped together using the assortment list profile. Profiles are assigned to sites.

When master data is changed, change documents are created that track every change to every field. This allows changes to master data to be identified and passed on to the proper recipient during master data distribution. It is also possible to activate the creation of change pointers that only point to objects that have been changed.

An IDoc structure is assigned to a logical message category. There is a relationship between every field in an IDoc structure and the corresponding field in the change document. This enables you to select the relevant master data changes for every message category. The assortment list generation status is contained in the application log. For change messages, the system selects all the change pointers that were created since the last correct assortment list generation. This prevents duplicate selection of change pointers.

Change pointers created for the assortment list are analyzed by the system. The system then reads the master data for the articles and recipients involved and creates the necessary IDocs. These IDocs are then transferred to the IDoc interface for export to external systems. The data is converted outside R/3 and transmitted.

Change pointers are the triggers used to identify the objects for the change versions. During generation of an assortment list, the system selects those change pointers that were created after the last successful assortment list generation. When a change is planned for a future date, only those change pointers are selected that will have been activated by the end of the validity period of the assortment list. The system also has to select all older changes that had not been activated by the end of the last validity period but will be activated during the current period in question. (This occurs without change pointers for conditions that were created at a point in the distant past.)

The following figure illustrates how change pointers are analyzed by the system:

In analyzing the change pointers, the system produces a list of recipients, articles and dates.

When a full version is created, you have the option of limiting the articles selected not only to those relevant to the recipient but also to those relevant to a particular assortment list type. When you make a manual request, articles can be selected in accordance with even more criteria. The period of validity is determined in both cases by the parameters valid for the assortment list type.

You can assign price list types to merchandise categories at store level. When assortment lists are being created, the analysis program for changes also takes price changes into account. If the price of an article is changed at price list level, all the stores that carry this article and that use this price list type for this merchandise category are informed of the price change for this article.

If you then assign a different price list to a merchandise category in the store, this store receives the new prices for all the articles in this merchandise category.

This simplifies the central maintenance of sales prices for stores and store groups. If one or more articles in a price list are changed the analysis program for changes automatically specifies all the stores that should receive the price changes. The data is then distributed accordingly.

A listing check is made of articles and recipients before the data is read. When an assortment list is generated, data that will become valid within the period in question is also read. A complete data record is prepared for each article and each recipient for each day for which a change is made to the master data. This data is then entered in the Intermediate document (IDoc). Segments in the intermediate document that are not required can be flagged as not required for preparation. No data is then prepared for these segments.

You can fill further segments you define yourself in a customer enhancement (user exit). This enables you to incorporate user-specific data into the assortment list.

So that IDocs do not become too large (10,000 segments maximum), a number of intermediate documents can be created per recipient. Depending on the assortment list mode, the IDoc is either made available for transmission and/or passed to Version Management.

Assortment lists can be created in parallel. A single batch report is generated on a server for all assortment lists, that then triggers parallel tasks on several application servers. This distributes system resources more evenly and considerably reduces the length it takes to create assortment lists.

1. Processing, which is the same for all assortments results from a single task on a single server (for example, analysis of changed data for change versions).

2. RFC (Remote Function Call) triggers asynchronous, parallel tasks on several application servers. Each of these tasks creates new IDocs for an assortment list.

You have the following options when specifying which server is to be used:

• a particular group of application servers

• all available servers

If the highest total of parallel tasks is reached, a new task is started when another one finishes. The report output provides an overview of all tasks in process, of error messages from the RFC and of created IDocs and versions.

Because assortment lists are usually generated in the background on a periodic basis, information and warnings about the data preparation are contained in an application log.

Using the POS Monitor you can access the application logs for stores. Alternatively, you can display assortment lists and then branch to the corresponding application logs. To do this, drill down into the assortment list hierarchy until you get to the version level. The application log number is displayed on the right side of the screen. Click on this number to jump to the corresponding application log.

You can also access the application logs by displaying the assortment list cycle. When you select a desired line, the system displays the assortment list generation history (that is, the most recent assortment lists for the selected customer and assortment list type). Every line in this list refers to a generation of the corresponding assortment list, even in cases where a change version contains no entries because no relevant changes to the data had been made. Here again you can click on the application log number to access the application log itself. Within the application log, you can do either of the following:

• If an IDoc (intermediate document at the ALE/EDI level) was successfully generated, you can display the IDoc data.

• If the system encountered problems during data preparation (in which case no IDoc was generated), you can click on the message number to obtain detailed information.

From here you can also jump to the general application log for the entire run. This way you can see all messages that were generated, not just those restricted to a particular customer.