Creation of IDoc extension for Basic type INVOIC01 – Step by step and real Business Scenario

In this blog post, I will describe the steps I have followed to create an extension for the basic type INVOIC01. I will also illustrate the actual business requirement and what was requested.

First, I know that there are a lot of materials out there for how to create an IDoc extension and I won’t get into very tiny details and will focus more on my problem.

So, to give a general background in transaction NACE we have done the configuration for Application V3 (Billing), OutputType (ZRDO), and Processing routines: Medium – EDI, Program – RSNASTED, FORM routine – EDI_PROCESSING. But surely you know this part well. Anyway here is a print screen:

Now the Basic type INVOIC01 can be configured in transaction VF03 where we create billing documents for a customer. In the images to follow I will show the output configuration in VF03 and the IDoc from transaction WE02

You can see that above I have highlighted the value of field BELNR = ‘0090072614’ for one of the segments E1EDK02 and more exactly the one where QUALF = ‘087’ (you can check it for yourself what that means, but to avoid you the pain it is ‘Reference Document Number Billing Doc.’). The above image is important because there lies the problem.

The document I have shown in transaction VF03 that generates this IDoc is a Credit Memo and is generated following the Invoice ‘0090072614’. Yes, you are right: “The one in the segment E1EDK02”, but this image will help you get a more clear idea:

The customer requested two additional fields (a document number and its date), except the number of the invoice and this information, was to be added to a child segment under E1EDK02. The value of the fields had to be retrieved following this rule:

◉ If in a custom tab “Additional fields” the values were entered use those, otherwise use the number and date of the accounting document.

And again the image shows that the first check is true and so the values are taken directly from the invoice without needing the accounting document.

Now, the steps to create this extension, without going very much into detail as the material out there is plenty to help you. So, I will just list the list of steps. In the end the most interesting part for the ABAP enthusiasts and the end result.

1. Creation of the custom segment Z1EDK02 in WE31

2. Creation of extension IDoc ZINVOIC1 in WE30 from the basic type INVOIC01

3. Creation of the Logical Message Type ZINVOIC in WE81

4. Assigning Logical Message Type ZINVOIC to Extension IDoc Type ZINVOIC1 in WE82

5. Assigning the Logical Message Typer to the Partner Profile in WE20

6. Finding and implementing the Customer Exit to write the logic to add the new segment

Now, for the last two points, I will make an exception and go into more detail as it helps to find where to implement our custom logic.

In WE20 we have done this configuration for our partner profile:

If you double-click on the Process code we can find the Function Module to generate the IDoc and where we should insert our code, but don’t worry as I have provided below all the screens from one step to the other:

As we are the INCLUDE I have implemented the code to add this new segment and I think that the logic is quite simple. First we check for the additional data in the invoice and if they aren’t there to be found we check in BKPF. Only if found in any of them is the segment added.

* Extension of IDoc INVOIC01 - Logic to populate the new segment 'Z1EDK02'

DATA: lv_nr_fapiao   TYPE zznr_fapiao,

      lv_dt_fapiao   TYPE zzdt_fapiao.

DATA: ls_edidd TYPE edidd,

      ls_z1edk03 TYPE z1edk02.

IF int_edidd-segnam = 'E1EDK02'.

  CLEAR: e1edk02, bkpf.

  MOVE int_edidd-sdata TO e1edk02.

  IF e1edk02-qualf = '087'.

    ls_edidd-segnam = 'Z1EDK02'.

*   Invoice data for new additional custom tab

    CLEAR: lv_nr_fapiao, lv_dt_fapiao.

    SELECT SINGLE zznr_fapiao zzdt_fapiao

      INTO ( lv_nr_fapiao, lv_dt_fapiao )

      FROM vbrk WHERE vbeln = e1edk02-belnr.

    IF lv_nr_fapiao IS NOT INITIAL AND lv_dt_fapiao IS NOT INITIAL.

      ls_z1edk03-belnr = lv_nr_fapiao.

      ls_z1edk03-bldat = lv_dt_fapiao.

      MOVE ls_z1edk03 TO ls_edidd-sdata.

      APPEND ls_edidd TO int_edidd[]. "Addition of a new segment under 'E1EDK02'

    ELSE.

      "Read from BKPF to find the accounting document

      SELECT SINGLE * FROM bkpf

        WHERE awtyp = 'VBRK' AND awkey = e1edk02-belnr.

      IF sy-subrc = 0.

        ls_z1edk03-belnr = bkpf-belnr.

        ls_z1edk03-bldat = bkpf-bldat.

        

        MOVE ls_z1edk03 TO ls_edidd-sdata.

        APPEND ls_edidd TO int_edidd[]. "Addition of a new segment under 'E1EDK02'

      ENDIF.

    ENDIF.

  ENDIF.

ENDIF.

 

Normally the user exit should be activated in its project in transaction CMOD and then we are good to go. To test my change I repeated the output in VF02 and generated a new IDoc that now contains the new information:

If you want to test what you have done (hopefully for fun and not because your modification didn’t work as predicted) you can follow these steps:

1. When you repeat the output in VF02, select the new row that was created and press “Further Data”.

2. Change the dispatch time to “1 – Send with periodically scheduled job”.

3. Open the program RSNAST00 and fill in the input values in the selection screen.

4. Enter debug mode by typing /H in the command line.

5. Happy debugging