Package Studio Tutorial Part 1 - A Phone call from Purchasing
"Hello Nils, can you please provide us with the complete last year's orders for company code DAB1 in a database. Goods and invoice receipts included please. And some details about the suppliers would be great too. I hope this works out by this afternoon? Thanks!"
Who hasn't experienced it, short term and razor-sharp formulated requirements from the department, which should have been done yesterday.
But let's get started - it can't be that complex.
The first important decision
After creating the package, choosing a reasonably descriptive name and filling in a short description, we find ourselves in the Package Designer on the so-called green field.
The first basic decision to be made is which SAP system we will use to create the package. The selected system can be seen at the bottom left of the visualization area and can be changed if necessary in the menu whether under "SAP System"->"Switch to". In this case we leave it at the S/4 HANA system, because the said company code DAB1 is located on exactly this system.
The first tables
When I review my colleagues' request, the terms purchase orders, goods and invoice receipts, and vendor come up. As an experienced SAP data analyst, I immediately know which table pots I have to reach into:
- EKKO for the order headers
- EKPO for the item details
- EKBE for the purchase order history, i.e. goods and invoice receipt
- LFA1 for the vendor master data
So we press the small table icon with the plus, enter the first table name and select it from the list.
Since the colleagues have not specified exactly what information they want to have, I choose the easy way and select all fields on the right side of the table details first.
We repeat this process for the other 3 tables and then have a list of 4 tables, each with full field selection.
Everything is too much - we need to filter
Since our system contains data from both previous periods and other company codes, we need to filter our package, or tables, where possible.
dab Nexus Package Studio allows us on the one hand to filter the tables directly by applying certain values to certain fields. On the other hand this is not always possible and I want to filter tables in dependency to other tables. We do this by using so-called dependencies between tables. The basis of a dependency is always a repository, which contains a list of values or combinations of values, which are collected in one table to be used in the other table for filtering.
Let's start with the simpler part, filtering.
A filter for the extraction period
I want to create a filter for the extraction period. To do this, I press the small filter icon with the plus at the top left and assign a filter name - here "Extraction Period".
In the filter detail area on the right, I now configure the use of the filter.
We ignore the mode "Initial/Delta/Initial&Delta" for the time being as well as the options Required and Offline. An explanation of these options will be given later.
The first important option is the Type. Here we have three options with Input, Fixed Value and Well Known.
The question the package designer has to ask here is whether a filter value should be fixed when creating the task or whether it should be fixed in the package.
If the latter is the case, we select the type "Fixed Value" and define the fixed value(s).
If we want to enter the values only when creating the extraction task, we select Input and then the DataType.
If we want to limit the range of values of the input to values given by the SAP system, we use the predefined "Well-Known" filters. These are explained in more detail at the company code.
Since we want to give our package the flexibility to cover other time periods than just fixed last year, we select "Input". Then we set the DataType to "Date" and the Condition to "Between", since we want to cover a from/to period.
We use the scope "Global/System" to be able to set filters individually per system in a multi-system extraction. An extraction period is a classic global scope.
Last but not least, we need to tell the package how to use the filter. In our case, we want to filter orders by creation date, so we assign it to the EKKO table and the AEDAT field.
Company code filter
The second filter we need is a filter on the company code DAB1 requested by purchasing. Again, we want to build this package so that it can be reused in the future.
So we are not assigning company code DAB1 as a fixed filter value, but we want to be able to enter the company code(s) when we create the extraction task. dab Nexus can help us select values by providing us with a list of values from the connected SAP system from which we can select. This filter type is called "Well Known".
For Well Known we select "Company Code" for the company code, the scope is "System" because the company codes are system specific and finally we assign the filter to the field BUKRS in the table EKKO.
With this we have actually covered the basic scope. All orders (EKKO) for a certain period (last year) for company code DAB1. I.e. our EKKO table will contain all required entries after extraction.
Then we turn our attention to the "dependent" tables.
The first simple repositories
As mentioned, our filtered order header table EKKO now contains all records relevant for purchasing and we can filter the other tables based on EKKO. To do this, we use repositories. A repository collects values and then uses these collected values to narrow down the other tables accordingly.
It is important to understand which fields are used to link the relevant tables. EKKO, EKPO and EKBE have the purchasing document number as a common field and thus it is logical to request all purchasing document numbers collected in EKKO extraction from the other tables.
For this purpose we create a new repository on the left and name it accordingly.
A repository always consists of at least one field that is collected in it. However, it can also contain several fields. In our case, we want to collect all values of the purchasing document number from EKKO. Technically, the values are stored in the primary key field EBELN of EKKO.
So we add a field to the repository and name it EBELN.
Finally, I have to tell the package from which table and which field(s) the repository is fed (source tables) and which tables and fields consume from it (target tables).
In our case, these are the fields EBELN from EKKO as source and EKPO/EKBE as target.
The 'A' in the assignment indicates that the field of the repository could be automatically assigned to a technical field of the table.
So now all we are missing is the supplier details from the LFA1 table. Many extractions tend to pull master data tables like LFA1 in their entirety. However, with a large SAP system and a quite small company code in extreme cases, this can be quite a large overhead to extract unnecessarily. For this reason, we work with a second repository, since the vendor number exists as field LIFNR in EKKO and we can thus create a second repository and thus restrict the LFA1.
With this we have created our first, small extraction package for purchasing with the dab Nexus Package Studio.
Whether purchasing will now receive the data by this afternoon is now up to the size of the data. dab Nexus with its efficient and intelligent extraction algorithm will do its best.
dab Nexus also visualizes the package and the relationships between them for us accordingly.
However, as is almost always the case, purchasing needs more after an initial review of the data.
In the second part, we will continue by adding some aspects to the package.
