Skip to main content

Examples

Hint

These examples will show you the process on how to set up Extraction Packages. We've 'extended' the exercise for a clearer introduction. The interface and colours have been adapted in more recent versions. Therefore the look in the screenshots can be slightly different from your version.

Example 1 - simple Package​

What data would we like to know or extract?​

  • Extraction of all positions already posted
  • Of all productive Company Codes

What do we need for this extraction or where do we get this data from?​

  • Table with Company Codes
  • Table with already posted positions from the FI-Dictionary
  • Filter on the indicator whether Company Code is productive

What package elements do we need?​

Let's start with the integration of T001 (SAP table of Company Codes) as a table. Then we select all fields. We also use the BSAK table to extract the balanced items - this is also included as a table. Since we only want the Company Codes that are already in productive use, we create a filter - for this example we call the filter Is_Prod. Finally, we create a repository in which these Company Codes are saved after the first step (extraction of all productive Company Codes) in order to be able to carry out the next extraction - in this example we call the repository BuKrs (the German equivalent of CCode).

After these steps, we have the following elements on the left:
nexus_ps_example_1

Filter​

In the next step, we set the filter. We specify in this filter that the XPROD field in the T001 must be active, i.e. must contain the value X, we enter the Type Fixed Value. As this is a character, the DataType is String and the Condition is Equal, as we are looking for exactly the value X. We now enter the value X and in the table relations we specify that this filter is set onto the table T001 for the XPROD field.

The Detail Area in the right-hand area now looks as follows (when selecting the filter on the left):
nexus_ps_example_2

Repository​

We now filter all entries from table T001 whose Company Codes are active (XPROD = X). We need to store this data temporarily for further use. We do this in the BuKrs repository. We insert into the repository which fields it should contain, where these contents come from and for which other tables these values are used.

Therefore, we first insert a CCode field - if we would call this field BUKRS, the auto-mapping would take effect for the source and target tables. In this example, however, we will do this manually first. We then specify that the source table is T001 - this is where our data comes from, which we store in this repository. Last but not least, we specify that the BSAK table is the target table. The values from this repository will continue to be used in this table.

You will see a ⚙️ next to the respective table names on the right. This ⚙️ stands for Custom Mapping, which means that you have to link the field from the respective table with the field from the repository.

In the end, the detailed view of the repository looks like this:
nexus_ps_example_3

Clicking on ⚙️ opens a window with the option of linking the values manually.

Tables​

Let's now take a look at the detail area of tables T001 and BSAK:
nexus_ps_example_4

Here for T001 you can see the selected fields, the first two are the Primary Keys and the third is the indicator for whether the Company Code is used productively. The filter targets the XPROD field and the filtered Company Codes end up in the Target Repository BuKrs.

The situation is somewhat different in the detailed area of the BSAK. Here, the data is filtered depending on the dependency of the data from the BuKrs repository:
nexus_ps_example_5

Result​

At the end, the Element Overview in the middle looks like this:
nexus_ps_example_6

The short explanation for this is: The filter named Is_Prod filters the entries from the T001. These filtered entries end up in the BuKrs repository, which is used to filter the entries from the BSAK. At the end, you will receive a list of the posted positions from the BSAK that are assigned to a productive Company Code.


Example 2 - advanced Package​

What data would we like to know or extract?​

  • Search for all Purchase Orders (PO) from the EKKO table
  • By extracting all POs with open or already paid invoice documents
  • From one or more Fiscal Year(s)
  • From German vendors

What do we need for this extraction or where do we get this data from?​

  • Tables:
    • Vendor Master Data
    • Accounting: Secondary Index for Vendors (Cleared Items)
    • Accounting: Secondary Index for Vendors data (Open Items)
    • Accounting Document Segment
    • Purchasing Document Header
  • Filters:
    • Vendors from Germany
    • Fiscal Year
  • Repositories (we add them during the creation of the Package):
    • ...

What package elements do we need?​

Let's start with the tables we need:

  • LFA1: Vendor Master Data
  • BSAK: Accounting - Secondary Index for Vendors (Cleared Items)
  • BSIK: Accounting - Secondary Index for Vendors data (Open Items)
  • BSEG: Accounting Document Segment
  • EKKO: Purchasing Document Header

Next, we'll create the filters and name them accordingly:

  • LFA1_DE: Filter for German vendors
  • GJAHR: Fiscal Year

Now, the element list on the left should look like this:
nexus_ps_example_7

Filter LFA1_DE​

Let's set the filter LFA1_DE and specify which tables and fields we want to filter on.

We set a Fixed Value, as we are looking for vendors of a specific country (that doesn't change). The Condition is set to Equal, as we are looking for the exact value. The DataType is string, because the value are characters. As Value we set DE, the Country Key for Germany. And in the end we add the Table Relation to LFA1 and the field LAND1 as we want to filter there.

Now the filter LFA1_DE should look like this:
nexus_ps_example_8

Filter GJAHR​

Now we set up the second filter for the Fiscal Year. As we have a specific Filter Type called Fiscal Year, we can use it. In this case we don't need to enter the desired Fiscal Year's in the package itself but later in the Task. We also set two Table Relations here. One for BSAK and one for BSIK, both with the field GJAHR.

Now the filter GJAHR should look like this:
nexus_ps_example_9

Repository LFA1_Kred_DE​

Now that we have successfully created the tables and filters, let's turn our attention to the repositories that are needed to save the intermediate results with which we can then continue working.

We create the repository LFA1_Kred_DE to temporarily store the results from filtering the table LFA1 with the filter LFA1_DE. We define the following settings for the Repository:

  • Fields
    • LIFNR: Vendor Number of the German suppliers
  • Target-Tables
    • BSIK: automatic assignment for the fields via LIFNR
    • BSAK: automatic assignment for the fields via LIFNR

We now have our first repository that contains all Vendor Numbers of German suppliers. It should look like this:
nexus_ps_example_10

Repository Belnr​

Now we create another repository and call it Belnr - here we want to store the Document Numbers found in the BSAK and BSIK tables. We get the Document Numbers by filtering these tables for the Vendor Numbers just found (and stored in the repository LFA1_Kred_DE) and with the Fiscal Year(s) entered in the Task.

But now we have to be careful. Saving only the document numbers here would mean that we would either not receive all document numbers or have numerous duplicate entries. This is because the document number can be repeated in the Company Codes and the Fiscal Years. To counteract this, we not only safe the document number in the Repository, but also the Fiscal Year and the Company Code.

As we get this information from the BSAK and BSIK tables, we specify these two as our Source Tables. With the Custom Mapping we can check, if the fields are mapped correctly.

We now have the Document Numbers of German Vendors from the desired Fiscal Year(s) in our repository Belnr. It should look like this:
nexus_ps_example_11

Table BSEG​

Now we look for the POs from the BSEG table. This means that the BSEG is filtered as a Dependency of our Repository Belnr. Due to the different spelling of the field for the Company Code, the Custom Mapping must also be carried out here again:
nexus_ps_example_12

Repository EBELN​

We now write the data obtained from the BSEG to this final repository, which we call EBELN. As the PO numbers are unique in our example, we only need one field here, which is also called EBELN.

We specify that the data stored here comes from the BSEG table (therefore as a source table):
nexus_ps_example_13

And as we have now paid attention to the correct spelling of upper and lower case, the automatic mapping takes effect again.

Table EKKO​

At the end, we want to filter the EKKO table with the POs found in BSEG in order to obtain all other order header information. Therefore we now include the EKKO. As we want to extract all available information here, we now select all fields with the All button. This table is filtered again depending on the Dependency of the previous Repository EBELN:
nexus_ps_example_14

Result​

And et voilà! In the end, we have all the relevant order header data from the desired Fiscal Year(s) from German vendors.

When we take a look at the Element Overview in the middle, the whole thing looks like this:
nexus_ps_example_15

With this configuration the Task will create the following Result Tables:

  • LFA1
  • BSAK
  • BSIK
  • BSEG
  • EKKO

If you are really only interested in the order header data, you can also change the LFA1, BSAK & BSIK and BSEG tables to Virtual Tables. These are then no longer saved as Result Tables at the end of an Extraction Run.