Enhancements for POS Analytics (POSDM) Datasources

The below documentation explains the enchancement approch on POS Analytics datasources,

Refer the Customer Enhancements from the POSDM structure /POSDW/EXTENSIONS (FIELDGROUP, FIELDNAME and FIELDVALUE).

Modify with the Enhancements in the BADI /POSDW/OUT_BW.
(T-code: /n/POSDW/img). The path of the BADI object as shown below:

Enhance 0RT_PA_TRAN_CONTROL in RSA6 + append structure.

Adding and extending customer-specific fields

If you want to update your own information, for example, from the EXTENSIONS segment, into data targets, proceed as follows:

Extend the relevant extract structure

First, add the fields you require to the extract structure used to transfer the information into the data targets. For example,
the segment for customer enhancements to the POS transaction could be used to transfer your own total type for total transactions. In this case, you would,
for example, extend the /POSDW/BW_TOTAL extract structure with a customer-specific Include structure with the totals fields.

To avoid conflicts with fields delivered by SAP at a later stage, we recommend that you use a separate namespace for the field names.

Fill the fields in the /POSDW/OUT_BW BAdI exit:

reate an implementation for the /POSDW/OUT_BW BAdI.

Note that the data is already formatted in the extract structures and only has to be enhanced. The sorting of the tables transferred with CHANGING parameters can be changed using the the Business Add-In implementation if necessary.

  The IT_TRANSACTION table is sorted according to the following keys:

                      
RETAILSTOREID
BUSINESSDAYDATE
TRANSINDEX

The transactions in the extract tables have the same sequence.

    Therefore, all read accesses to internal tables should use a binary search (“BINARY SEARCH”).    It is also theoretically possible to filter out record
types during extraction, for example, to reduce the data volume where necessary.
However, you must ensure that no data that is relevant for the update is deleted from the tables.

   If customer-specific record types are also requried for the update, use the alphabetical names for the record types (as described
above). In the example, above, you would indicate the customer-specific total type as record type ‘S001’.

0RT_PA_TRAN_CONTROL

0RT_PA_TRAN_TOTALS

0RT_PA_TRAN_GDS_MOV

0RT_PA_TRAN_MOV_FIN

In POS Data Management, data can be processed for different business transactions. The data is processed in the same data structures and stored in the database. To enable improved classification of the different instances, there is a syntax for determining which substructures can be filled with a certain business transaction.

Unfortunately, BW does not process any hierarchical data structures but, instead, expects that the data that is to be updated to be delivered in a flat table (which does not contain any additional tables).

To transfer the data to BW in a suitable format

without having to use too many different data structures, the information is sent using relatively broad structures, which contain information for both the

header data and the item data.

The large memory requirement of these structures is a disadvantage but, on the other had, it is no longer necessary to locate the correct assignment of item data to header data in the update routine

because this is transferred in the same structure.

Since some POS transactions may have no items and each POS transaction may contain a very large number of items and subitems, all segments of a POS transaction must be transferred as a separate record type and indicated by a qualifier so that all

of the information is available within the update routine.

To restrict the width of the structure and because different business transactions contain very different information, there are four different DataSources that transfer information for different business transactions (see also note 786421).

Thanks and Regards,

Ramesh D