Archiving Business Partners using a custom Function Module

Perhaps you have to archive and delete some Business Partner (BP) because its creation is a mistake and you need to re-create it again with the same Business Partner Number, or you could simply need that this BP disappears from the standard BP tables and BP transactions.

Actually doesn’t exist a standard Function Module or BAPI to archive/delete BPs, and only we have available the transaction BUPA_PRE_DA (to set archive/delete flag) and SARA (to execute archive/delete background jobs).

The functional process of archiving is based on SAP Notes 2491026 and 2640553. Also, note 2599676 is relevant stating that Transaction BUPA_DEL is obsolete (instead of this we can use transaction BUPA_PRE_DA).

This article is about of ABAP approach to solve the problem of archive Business Partner using a custom Function Module that calls the transactions BUPA_PRE_DA and SARA to immediately schedule background jobs doing the expected task. The system used to build the solution was S/4HANA 1909.

So, Let’s do it!

Previous activities

As a big picture, exist three types of BP, each with its own archive object within transaction SARA:

Archive Objects

SAP notes 2640553 has a detailed step by step about how to archive and delete manually a BP generic using the archiving object CA_BUPA. I highly recommend previously test the archiving process manually using this guide because there are activities (BASIS and ABAP) to do only once per environment to be able to achieve the goal.

Customizing BASIS Activity:

For example, you need to check that the Settings for Deletion Progam basically have the right variants for every archive object.

First, go to the transaction SARA and fill the variant and click on the Customizing button:

Click on Archiving Object-Specific Customizing->Techincal Settings:

Double click on the Archiving Object:

Set the variants SAP&TEST and SAP&PROD like the picture and optionally fill the Content Repository using the Match Code:

Finally, save and assign the Customizing Change Request. Repeat the process for the other Archive Objects.

Dynpro Generator Activity:

As a requirement of the transaction SARA, maybe you need to run standard reports because some Dynpros of maintaining the archive variants previously did not exist. Simply go to se38 transaction and execute the reports BUPSELG0 y BUPSELG5:

ABAP approach:

I see the Batch Input as a simple, very helpful, and ancestral SAP Robotic Process Automation (RPA). What do you think about it…?

In fact, for this approach, I simply used the SHDB transaction to do a recording of the calls to the Archiving’s transaction BUPA_PRE_DA and SARA.

After recording, I built a Custom Function Module (FM) that lets us archive BPs Generics and BPs with Customer Integration. This is my “Beta 3.0” approach and I hope to improve this with all your perspectives.

Function Module Interface:

Through the SE37 transaction, we could build a custom Function Group and also a custom Function Module call ZBP_ARCHI.

Import Variables:

◉ I_BP: BP to archive one-to-one. It’s possible to archive in batch, but this approach was designed as a single archive BP. (We can also call ZBP_ARCHI within the loop and archive many BPs).

◉ I_CV: Classification of BP. BP Generic = 1, BP Customer = 2. (BP Vendors are not considered for this approach but can easily be reproduced).

◉ MODE: Use “N” to the background process and “A” to the dialogue process.

Export Variables:

◉ SUBRC: “0” = Successfully process. “4” = Archiving not finished.

Tables:

◉ MESSTAB: Log table.

ABAP Logic:

Basically, this FM do the following task:

i. Call BUPA_PRE_DA transaction to set Delete flag within the standard tables.

ii. Call SARA transaction for every archiving object needed in strict mode. If the BP is generic, only use CA_BUPA, but if the BP is Customer, then use first FI_ACCRECV and after that use the CA_BUPA.

iii. For every Archive Objects, first schedule jobs of archiving and then schedule delete jobs.

iv. If some error is raised, then fill the subrc variable with “4”.

v. Fill in a log return table “MESSTAB” with every message given for the Call Transactions.

Full Source Code:

Here, I shared with you my full source code approach. I hope you test and enjoy it and give to me your suggestions by doing a better solution.

The full function module source code is here:

ZBP_ARCHI

And the subroutine called within this Function Module to get message descriptions:

get_message

Test:

We can test this function module for example for a BP Generic. That case use “1” within I_CV:

After the successfully execution we have SUBRC = “0” and MESSTAB with six message:

The most important in a right execution is to get the message “073” because this allows us to know that a full delete of BP is achieved: