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. The change pointer analysis is therefore being made smoother to improve performance. 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. You must take the following dependencies into consideration when activating the change pointer:
Logical message type that is to be sent |
Object |
Message types 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 |
Person 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 converter can retrieve the data. The recipient port for the POS outbound (transaction WE21) has to be stored under the name File for this.
Only the parameters, Outbound file and Status 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 parameter
The outbound parameters in the POS outbound can be maintained 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 you 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 this case, the outbound parameters have to be corrected.
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).