Import/Export Interface of the Article
Hierarchy 
Use
Extraction to SAP BW
You can extract the data in an activated article hierarchy into SAP BW provided BW extraction is set for the article hierarchy (property of the hierarchy).
There are two ways of extracting article hierarchy data to SAP BW:
· CDT
You can extract a maximum of seven CDT levels here:
¡ CDT1 (Category) with strategy and role
¡ CDT2 (Subcategory) with strategy
¡ CDT3 (Segment) with strategy
¡ CDT4 (Subsegment) with strategy
¡ CDT5 (Sub-subsegment) with strategy
¡ CDT6 (Product group) with strategy
¡ CDT7 (Brand) with strategy
¡ CDT8 (SKU), the articles with the CDT path to category
· Hierarchy
Here you can extract a maximum of 10 levels and the SKU level scheduled.
You determine the type of extraction in Customizing for the article hierarchy. If the relevant indicator is activated, the master data for the article hierarchy is updated to SAP BW. The update to SAP BW must be activated for the article hierarchy. If the indicator is not activated, the master data for the article hierarchy (up to ten levels) is updated to SAP BW. If the indicator is activated, only the master data for article hierarchies for which scheduling is deactivated is updated.
BAPI Inbound/Outbound
There are three BAPIs available for transferring structure data from external applications and for creating new article hierarchy objects, or for changing existing article hierarchy objects, so that this data can be posted to in the SAP system.
· If the hierarchy is created completely in the legacy system and is posted in the SAP system using an interface, there is an interface that enables structure information to be imported into the article hierarchy. The structure data is copied using the BAPI BAPI_WRF_MATGRP_CREATE. The data can be transferred to the hierarchy using mass update.
· If the article hierarchy already exists in the SAP system, you can copy new nodes that were defined outside the SAP system or already exist in a legacy system to the existing article hierarchy using a BAPI interface. The new nodes are updated via the article hierarchy interface. The BAPI BAPI_WRF_MATGRP_CHANGE serves as an import interface. In the standard delivery, you can import each level of the structure using this interface. You can decide which levels you create.
· Using BAPI BAPI_WRF_MATGRP_GET_DETAIL it is possible to read structure and article data from the article hierarchy for a hierarchy ID.
BAdI Outbound
In article hierarchy maintenance, you can jump to other transactions, programs, reports, and so on, from each hierarchy level of the article hierarchy using the BAdI BADI_MATGRP_HIER_LEV. You can realize the jump using this pushbutton into every other program or every other transaction (for example, the site master) using a customer enhancement without modification. On the category level of the article hierarchy, you can jump from maintenance to shop creation to maintain department store-shop assignments.
IDoc
The formatting of the article hierarchy data, which is always store-independent, is controlled by the message type WMATGRP (IDoc type WMATGRP01). Information about article assignment is not considered in this distribution. By assigning filter objects (VKORG and VTWEG) to the message type, you can configure which recipients are responsible for which distribution chains in the distribution model. The article hierarchy IDocs created by this interface are distributed to the relevant store retailing systems using the standard ALE outbound processing, where they are saved.
In addition to the pure hierarchy data (E1WAH01 to E1WAH02), the language-dependent texts of the hierarchy ID, hierarchy level (tree level) and hierarchy node are transferred. Additional text segments (E1WAH04 to E1WAH06) are added to the IDoc. You can also send the text segments using a reduced message type. The texts are always sent in all available languages as standard. You can use the BAdI WRF_MATGRP_X_DLD using the method MODIFY_SPRAS for all downloads (initial, direct dispatch, and change case) using a separate implementation of individual languages. For the customer enhancement E1WAH03, you can copy additional data for each node using a separate implementation; the intended method for this is ADD_SEGMENT.
In the case of an initialization or change, the transmission date is updated in an index file INDX under the RELID = ‘WM’(abbreviation for WMATGRP) with a key (key field = SRTFD) in the field AEDAT. This date is used as a trigger for the change analysis.
Each IDoc consists of a header segment (E1WAH01) and any number of item segments (E1WAH02). A separate IDoc is created for each article hierarchy ID. For performance reasons, each IDoc should only contain around 5000 segments.
· Initialization
Report RWRF_MATGRP_INIT_DLD or transaction WRF_MATGRP_INIT_DLD is available for distributing the article hierarchy.
The initialization is used to download the article hierarchy that is currently valid.
In the initial download, you can send all article hierarchies that have been maintained as being application-relevant. This is not the case with the direct request. You can also enter the distribution chain, but this is not mandatory. If you do enter a distribution chain, the function module looks in WRF_MATGRP_HIER for a hierarchy ID for this distribution chain that is flagged as being application-relevant. If it does not find an entry, it searches in WRF_MATGRP_HIER for a hierarchy ID that is valid across clients and is flagged as application-relevant.
Note the following requirement of the POS system:
In order to avoid problems with the sequence during the initial construction of the article hierarchy data in the store retailing system, there must be no plausibility checks during the initialization in the store retailing system. If there are plausibility checks, the transfer cannot take place in the correct sequence.
If changes have been made to the hierarchy itself, and this already exists in the store retailing system, you must first delete the entire hierarchy in the POS system and then recreate it by importing the IDocs.
· Direct request
The process for direct requests is very similar to the process for initialization.
You can use report RWRF_MATGRP_REQ_DLD or transaction WRF_MATGRP_REQ_DLD for the direct distribution of the article hierarchy. Unlike with the initial dispatch, only one application-relevant article hierarchy is ever sent with the direct request. This can either be processed for a whole client or for a certain distribution chain. The distribution chain is a mandatory entry.
The direct request does not delete change pointers. If the article hierarchy is not sent for the date that is currently valid, the next change run would modify the status in the target system negatively. For this reason, a warning is issued if you enter a key date that is later than the current date.
Note this requirement of the POS system:
With the direct request, the first node must first be deleted from the IDoc with all subordinate nodes in the POS system, and then this part of the hierarchy has to be recreated.
· Change case
Changes to the article hierarchy are forwarded to the store retailing system by the report RBDMIDOC or transaction BD21. This report calls the function module MASTERIDOC_CREATE_SMD_WMATGRP and is scheduled as a background job according to the periodicity of the POS outbound.
In addition, the asynchronous dispatch of currently valid article hierarchy IDocs with the relevant change information takes place (not in chronological order). Changes have to be updated within the application (transaction WMATGRP01/02) in the form of change documents with various information. Change pointers are then generated from this change document information.
As the preparation does not take place in chronological order, the change information can be compressed before processing. For example, if a node name is changed several times, the relevant table entry is still only sent once.