Skip to Content
Author's profile photo Grzegorz Glowacki

Copying test IDocs from another system

There are times in a project when you have to copy an existing solution from one system to another. Or you develop a solution in a sandbox instance, that has no connectivity to other systems in the landscape. Or even you simply develop a scenario similar to the one you have already implemented in the past, and want to reuse previous experiences. In all these situations, finally, with your developments ready, you want to start testing and realize that you need some test message for that purpose. With Proxy interfaces your task is easier, because you can copy-paste an XML message directly into the testing tool. But what about IDoc-based connections?

Let us assume a model situation. You have system A, where certain IDoc inbound solution is up and running, and system B, where you are expected to develop a similar one, in particular, based on the same IDoc message. System B is a sandbox, and therefore is not (yet) connected to any other tools over RFC (i.e. PI or system A). You just finished your developments and now want to test, but have no test IDoc message for that purpose. What you can do is create a test IDoc with the test tool (t-code WE19), but this can be extremely time consuming, especially with IDocs with multiple segments, complex structures or mass loads. So why not just copy an example IDoc from system A? With no RFC connection (and ALE settings) between systems A and B it might not be that simple, but still you can use this small trick to save yourself from a few minutes or hours spent on writing data into IDoc.

At high level, the process is as follows:

IDoc in system A -> file in AL11 of system A -> file on your desktop -> file in AL11 of system B -> IDoc in system B -> your highly desirable test 🙂

Let’s have a closer look at each of those steps.

Step 1. System A. Export IDoc to file in AL11

There are two possible ways to export an IDoc to a file. You could create an IDoc port of type File (WE21), then outbound your IDoc to that port to have it written to a file. But you can also use a little trick that will help you avoid doing any ALE configuration. For that purpose, enter transaction WE19, put your source IDoc number, choose the “Inbound file” option, type a file path and name (on SAP server!), make sure to unmark the “Start IDoc inbound processing of file immediately” and confirm. As a result, the file will be written to a file on SAP server.

  It is important to notice that this action will result in another IDoc being created in the system, in status 68 “Error – no further processing” “Pattern IDoc written to database. Not defined for processing”.


Step 2. System A. Copy file from SAP server to your local station

In most cases, you can do this using transaction CG3Y:


However, this transaction is not available in some systems like PI or CRM. In such case, you can execute Function Module ARCHIVFILE_SERVER_TO_CLIENT instead:


Step 3. System B. Upload file from your local station to server

Similar to previous step, you can use transaction CG3Z (whenever available) or Function Module ARCHIVFILE_CLIENT_TO_SERVER.


Step 4. System B. Process IDoc from file

The final step is simply to process your IDoc from file, using standard transaction WE19 and pointing your newly created file as a payload source.


I hope some of you will find this information useful. Personally, I already had a few situations when this saved me a lot of manual work and helped me streamline my testing.

Assigned Tags

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

      Usefull blog. Thx

      Author's profile photo Grzegorz Glowacki
      Grzegorz Glowacki
      Blog Post Author

      Thank you Vladimir, I'm happy you like it 🙂 I hope it will get useful for some people, I myself really needed it a few times before I finally found a solution.

      Author's profile photo Harish Mistri
      Harish Mistri

      Thanks Grzegorz Glowacki to share. It is very useful.

      Author's profile photo Agasthuri Doss
      Agasthuri Doss

      Thanks Grzegorz Glowacki for sharing..

      >>>I already had a few situations when this saved me a lot of manual work and helped me streamline my testing.

      I agree



      Author's profile photo Former Member
      Former Member

      Useful blog. Thanks Grzegorz Glowacki.

      Author's profile photo Sank b
      Sank b

      Hi Glowacki,

      Thanks for this post. One question please .. I have saved an IDOC using WE19 transaction however some of the segments are not copied in there. eg; E1EDKA1.

      Is there any restriction on the segments to be copied ?

      Please advise



      Author's profile photo Grzegorz Glowacki
      Grzegorz Glowacki
      Blog Post Author


      To my knowledge, this method should not introduce any limitations to the IDoc content exported.



      Author's profile photo Monika Eggers
      Monika Eggers

      This really helped, thank you!

      Author's profile photo Anirban Bardhan
      Anirban Bardhan

      This really helped, thank you!

      Author's profile photo Jose Manuel Benito
      Jose Manuel Benito

      Thanks Grzegorz Glowacki to share. This really helped, it is very useful.

      Author's profile photo Denis Rossi
      Denis Rossi


      very interesting help to export one idoc.

      Do you also think about a way to export for example one month of idoc?

      for example in order to compute your carbon footprint with a month of shipment xml idoc files?