Updating zfield of table BSEG using BTE

[Former Member]

Hello guys,

here is our issue:

Our business requirement is to modify BSEG fields of accounting documents when reversing them using Tcode FB08.

For that, first, we thought of using a substution rule but in our SAP solution, based on our previous experience, such solution has huge impact. Therefore we thought of using the BTE solution of the following guideline:

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/207835fb-0a01-0010-34b4-fef1240ba...

We used the sample SAMPLE_PROCESS_00001120. You will find below the code we implemented:

IF t_bkpf-tcode = 'FB08'.
     LOOP AT t_bseg INTO i_bseg .
 
       IF NOT i_bseg-zzidoc_gen IS INITIAL AND NOT i_bseg-zzidoc_num IS INITIAL.
 
         READ TABLE t_bsegsub WITH KEY tabix = sy-tabix.
         CLEAR t_bsegsub-zzidoc_gen.
         CLEAR t_bsegsub-zzidoc_num.
         MODIFY t_bsegsub INDEX sy-tabix.
 
       ENDIF.
     ENDLOOP. 

The fields which are supposed to be modified (BSEG-zzidoc_num and BSEG-zzidoc_gen) should be blank at the end of the process.

To test this code, we created an accounting document which we reversed using FB08. In debug mode, we see that we pass through our BTE code and the table t_bsegsub is properly updated in the end of our function module (the two fields in question are blank) but when we check the two fields in SE16n, we see that they are not blank in the table BSEG.

Therefore, we wonder whether:

- There is a step missing in the implementation of our BTE ?

- the BTE solution is adapted to our business requirement?

Thanks for helping 

[Former Member]

Dear Oscar,

Could you try the below logic :

DATA : lv_tabix TYPE sy-tabix.

IF t_bkpf-tcode = 'FB08'.
     LOOP AT t_bseg INTO i_bseg .

         lv_tabix = sy-tabix.

       IF NOT i_bseg-zzidoc_gen IS INITIAL AND NOT i_bseg-zzidoc_num IS INITIAL.

         READ TABLE t_bsegsub INDEX lv_tabix.

         IF sy-subrc = 0.
             CLEAR t_bsegsub-zzidoc_gen.
             CLEAR t_bsegsub-zzidoc_num.
             MODIFY t_bsegsub INDEX lv_tabix.

         ENDIF.

       ENDIF.
     ENDLOOP.

ENDIF.

Regards,

Yance

[ricardo_bellashermida]

Hi,

In our company, we have implemented this BTE but in the code we use a workarea to modify the table t_bsegsub like this:

MODIFY t_bsegsub INDEX l_index FROM lwa_bsegsub.

I don't know if this is the solution of your issue, but in our company works fine.

Regards,

[Former Member]

Hello all,

thanks for your responses. We will try the BTE and let you guys know if that works.

Have you guys already implemented BTE in the past?

If yes, have you managed to create two function modules for a same process, say 1120? It seems that the customization does not authorized it (FIBF --> Settings --> Process module --> To a Customer)

Regards,

Aimé

[iklovski]

Why would you need two modules?

[Former Member]

Because we already have one BTE implemented for a different purpose.

Therefore, it is either we use two BTE but it seems it is not possible... or we put the two BTE in the same process.

[iklovski]

Just integrate the new logic in your existing module

[iklovski]

Hi,

Can you please elaborate on your fears about 'huge impact' of substitution in order to achieve your goal?

By all means, it would be better to use this functionality for this particular issue.

Regards,

Eli

[Former Member]

Hello Eli,

thanks for your response.

By huge impact, I mean that we have already lots of substitution implemented in our system. Based on the feedback of the client and on our experience in substitution implementation in our system, it seems that the addition of a new one is likely to have side effect on the behavior on the other ones. Therefore we chose the BTE solution to minimize these impacts.

Do you know why this BTE does not achieve it is purpose? It looks as simple as a substitution

Thanks a lot.

Kind regards.

[iklovski]

Hi,

I'd strongly recommend a substitution. There will be no impact on other steps, if all the steps are defined correctly and don't have failure in logic. Frankly, never used this particular BTE (didn't have any need to), but I wonder if it works on the same principle as substitution. I.e., please, check that in table GB01, these fields are marked as 'substitutable' or, in other words, 'exclude' flag is switched off.

Regards,

Eli

P.S. Also, I'd check if these fields are included in BSEG_SUBST structure.

[Former Member]

Hi,

substitution shouldn't work for reversing, I remember that a note exists, after which obbh stop working for reversing...

Regarding BTE1120, after you update fields in BSEG_SUBST this values transferred to accit by 'move-corresponding' , so you have to have the same fields name in BSEG and ACCIT

[iklovski]

"substitution shouldn't work for reversing" ah, yeah? Don't recall such a note... But, on the second thought, it makes sense: SAP could have blocked this functionality for reversal in order to maintain integrity. I wonder if BTE will equally work in this case