Customizing in the ALE Layer 

Change pointer analysis and message types

Unlike standard ALE master data distribution, POS outbound does not work with one, but with nine message types simultaneously. For performance reasons, the change pointer analysis therefore uses change pointers multiple times. If, for example, a change has been made to the main EAN/UPC that is, according to the settings in the ALE layer, assigned to message type WP_PLU (article master), then this change pointer is also used in the analysis for message type WP_EAN (EAN/UPC references), WPDSET (set assignments), and WPDNART (follow-on item). This multiple processing of the same change pointer for different message types means you do not have to create numerous change pointers (for each message type).

It is important to be aware of this fact if you do not want to send certain message types. In this case, note the following correlations for the activation of change pointers:

 

Logical message type that is to be sent	Object	Message type to be activated
WPDWGR	Merchandise categories	WPDWGR
WP_PLU	Article master	WP_PLU
WP_EAN	EAN/UPC References	WP_EAN WP_PLU
WPDSET	Set assignments	WPDSET WP-PLU
WDPNAC	Follow-On Items	WPDSET (!) WP_PLU
WP_PER	Personnel Data	WP_PER
WPDTAX	Taxes	No activation required as no change pointer analysis is necessary
WPDCUR	Exchange rates	No activation required as no change pointer analysis is necessary
WPDREB	Promotion discount	No activation required as change pointers are created directly from the application and not using the ALE layer

 

Outbound port

POS outbound processing stores data as files in a file system from which the POS converter can retrieve the data. The recipent port for the POS outbound (transaction WE21) has to be stored under the name File for this.

Only the parameters Outbound file andStatus file must be maintained. You only need to specify the directory in the status file. For the outbound file, you also need to specify a function module that calculates the file name at runtime.

Enter function module EDI_PATH_CREATE_POS_UNIX_DOS unless there are any particular reasons why you should not.

Ensure too that the directory path specified in both parameters is one and the same.

Alternatively, you can also use the standard ALE procedure (using the distribution module) for distributing POS data. In this case, you have to install a transactional RFC port. You also need to make settings for the distribution model in ALE Customizing, and set the parameter in the POS outbound profile to determine the recipient (see section POS Outbound Profile).

Outbound parameter

Maintain the outbound parameters in the POS outbound using the ALE transaction, WE20. Then you have to define the partner number of the store (corresponds to the customer number of the store) with the partner type CU (customer).

Then create the outbound parameters for this header entry. Every one of the logical message types listed in the table above has to be defined if it is to be sent to the POS systems.

Ensure that you have the correct setting for the output mode. You have to make the setting for it using the options Collect IDocs and Do Not Start Subsystem, as the POS outbound takes charge of sending itself.

This output mode must be defined as of Rel. 4.0A for all the partner numbers that need to be supplied with it. This is particularly important if the POS outbound was already used in an earlier release. In the latter case, correct the outbound parameters accordingly.

Alternatively, you can also use the standard ALE procedure (using the distribution module) for distributing POS data. Select partner type LS for this (logical system).