Skip to Content
Technical Articles
Author's profile photo Jürgen Creyaufmüller

How to create a package interface for a SAP package

Dear all,

we dared to switch on the package check in check mode “R3ENTERPRISE”. Doing this, we struggled with visibility of SAP objects w/o appropriate package interfaces.


Assuming you have the following package structure:

  • An own Z-Structure package, beneath a
    • Z-Main package
      • Z-development package

Could look like this


Inside the Z-development package, you wan to use the data element /SCDL/ADF_CHK_ARCH in a program. Running a package check for your program leads to several errors:

  1.  Used object from external structure package not visible
  2. The object DTEL /SCDL/ADF_CHK_ARCH is not exposed in package interfaces.

First error, is because of a missing / useable package interface on structure package level in package /SCWM/COMMON_CORE_STRUC, second error occurs as package /SCDL/ADAPTER_DF is encapsulated.

Looking at the package interfaces /SCWM/COMMON_CORE_S4APPL_ESIF seems to be made for re-usage of the objects in other applications.

But unfortunately, /SCWM/COMMON_CORE_S4APPL_ESIF has a restriction of client packages. So we cannot reuse it.

Solution for that create an own package interface for the SAP structure package level and its sub packages to grant visibility in your Z-Packages, from structure to development package.

  • /SCWM/COMMON_CORE_STRUC:     Structure package
    • /SCWM/STRUCTURE:    Structure package
      • /SCDL/MAIN:    Main package
        • /SCDL/ADAPTER:    Development Package
          • /SCDL/ADAPTER_DF:    Development Package
How to create a PIF for a SAP package.

  1. Go to SAP Package
  2. Right click on package and choose “Create->Package->Package Interface”
  3. Fill the Name (Your Namespace), description and Type (default Standard Package Interface). Do not change the Package here
  4. Confirm
  5. And now the magic occurs and you can assign the PIF to your own package.


For in the given example you have to execute the following steps

  1. Create a package interface for each SAP package; from SAP structure package down to SAP development package.
    SAP Package Example PIF
  2. Add development object, in this example DTEL /SCDL/ADF_CHK_ARCH, to the visible elements (TAB Visible Elements) of your PIF ( e.g. ZSCDL_ADAPTER_DF) for the SAP development package interface.
  3. Add visibility (TAB Visible Elements) to your PIFS of the superordinate SAP packages up to top SAP structure package using button “Add Package Interface”.
  4. Add your PIF of the SAP structure package to your structure package for your own developments (TAB “Use Accesses”, “Create”).
  5. Add this PIF to your sub packages (TAB “Use Accesses”, “Copy from Superpackage”).








Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Peter Inotai
      Peter Inotai

      Hi Jürgen,

      "we dared to switch on the package check". Welcome to the club 🙂

      We also used package check in my previous company and it was really a HUGE effort to make it work for us.

      I would emphasize that what you did is almost "cheating". I don't know the mentioned objects and packages, but generally speaking there is a reason why only certain objects are available in the package interfaces. Creating a new package interface just to make them accessible might potentially break something, which was not intended.

      For me it's almost like accessing a private method in a class via a new wrapper method.

      Best regards,


      Author's profile photo Jürgen Creyaufmüller
      Jürgen Creyaufmüller
      Blog Post Author

      Dear Peter,
      I have been in contact with SAP development about this, and the solution (for S/4 2020) was to create own PIFs for SAP objects, as the PIFs provided by SAP are not to be considered as an interface for customer developments, but rather for SAP internal use.

      PIFs for customer developments have "never been pursued with any vigor as a goal in the application" until now. But that is expected to change in the future. We have therefore currently severely restricted the authorization for packages and PIFs in these systems and creation or modifying packages is no longer available to a "normal developer".

      Since I didn't find any post about it, I wrote this blog. And so we can have a good discussion about it. 😊


      Author's profile photo Peter Inotai
      Peter Inotai

      Dear Jürgen,

      Thanks for the additional info. Now the picture is more clear why it was done this way. 🙂

      Best regards,


      Author's profile photo Peter Inotai
      Peter Inotai

      Sorry, just noticed that there is a typo in the title (crate instead of create).

      Author's profile photo Thales Batista
      Thales Batista

      And here was I, thinking for many years that PIFs were exactly for customer developments (since classes doesn't really have a true "released for customer" mechanism).

      I agree that is almost cheating, but then when you have some time to debug Package Check program and flying-by a bunch of hardcoded exemptions (maybe they "fixed" by now) then you won't blame yourself much for having the upper hand by manipulating cards. Yet you can also be picking the wrong cards just to have a green check instead of refactoring to pick the right ones. We don't know for sure which are the right ones.

      Author's profile photo Marco Beier
      Marco Beier

      Hey Jürgen,

      great read, nice post! Especially the conversation between you and Peter helped clarify a few things, that I was wondering about for quite some time now. Although I'm barely ever using PIFs it is nice to know a little more about 'em. 😊

      cheers 🍻