This program prepares data for POS systems and supplies the data in IDoc format.

This program is necessary for daily business and must be planned at regular intervals, preferably after the day-end closing on a daily basis.

Master data can also be prepared for transfer to the POS systems with the help of the assortment list. However, this method is considerably more complex than preparing master data using the POS interface - outbound, since considerably more data (for example, purchase order and allocation table data) has to be processed. The assortment list is recommended if additional retailing functions (such as the entry of a goods receipt) also have to be carried out in a store retailing system.

The program analyzes the changes made in the system since the last time data was correctly prepared, then prepares the changed data, and transfers it to these POS systems.

Plan the program RWDPOSUP to be executed at regular intervals in the background. It should run every day at day-end closing.

To increase the throughput you can parallel process the preparation of the data. In this case, the system uses all the servers or a group of servers for your system to prepare the data for POS outbound.

As a rule of thumb, you should plan one job for every available server and CPU available. You can display the number of CPUs available for each server using transaction ST06 (section CPU, sub-heading Count). This way, you can calculate the maximum number of jobs available. The total number of stores to be prepared divided by the number of jobs gives you the average number of stores to be prepared for each job.

You should use manual parallel processing if the parallel processing indicator has been set (available as of Release 4.5), as the IDoc preparation in one store runs in parallel, but not in several stores.

As of R/3 Enterprise (Release 4.7) you only need one job for every distribution chain which replaces the manual parallel processing.

For this, the change message has an additional parameter, Display Stores per Parallel Task. This controls how many stores should be prepared in one job (the same as in manual planning). The more CPUs there are available, the smaller this value is.

Then set the parameter to the upper average number that was calculated from the stores to be prepared in each job. Gradually increase the value and check the program runtime in order to keep the runtime as short as possible.

If parallel processing is not possible, the system automatically carries this out as a sequential process. If an error occurs during parallel processing, the system prepares the faulty objects again sequentially. This ensures the POS outbound processing is complete.

Should problems occur, which require an error search in the POS outbound processing algorithm, you can use the test mode (program RWDPOSSI) to locate the problem. The simulation mode functions just like the normal sequential change message, although it does not make any changes to the database. It is perfectly safe to use the simulation mode in any production system.

You cannot parallel process in simulation mode.