prcessing erros from BAPI_ACC_DOCUMENT_POST

[Former Member]

hello,

I have a request to write a program to create journal entries. In the past I would use RFBIBL00 and RSBDCSUB and have the user view and process the errors using SM35.

I have been told that BDC processing is not the way to go anymore and that I should start using the BAPI_ACC_DOCUMENT_POST and BAPI_TRANSACTION_COMMIT processes to create and save the entries.

this is going to be an automated process where a file will be placed onto a server and a FTP process will pick up the file and send it to SAP for procesing.

I am not sure how to handle the errors that come from the BAPI processes. I am thinking that I need to write error messages to a log which can be viewed by SLG1 and also create a eror file that could be reprocessed again.

has anyone done this before and if so, could you let me know how you handled the processing of the errors that come from the BAPIs.

thanks in advance.

[Former Member]

Hi

When you r uploading the data using BAPI. If any error occurs,at the tme of uploading BAPI will return the error messages in return parameter. This you need to capture into one internal table. Finally at the end ,this u can transfer it to file as error data or you can display.

Regards,

Raghu.

[Former Member]

Raghu,

thanks for the quick reply. after the error file is created, how would you process the errors? would you send the error file to the user for them to make corrections? after the corrections are made, would you have them process the error file using the program in foreground mode?

[Former Member]

Hello Timothy

When I do this type of processing I usually create a report to manage the messages returned by the BAPI, similar to SLG1.

Anyway, if you want to display the messages after the BAPI execution, you can use the following MF's:

BAL_LOG_CREATE - Create log with header data

BAL_LOG_MSG_ADD - Add a message to a log

BAL_DSP_LOG_DISPLAY - Display message in memory

Additionally, you can these MF's to define the way that you want the logs to be presented:

BAL_DSP_PROFILE_STANDARD_GET - Standard profile (SLG1) for a lot of logs

BAL_DSP_PROFILE_SINGLE_LOG_GET - Standard profile (SLG1) for one log

BAL_DSP_PROFILE_NO_TREE_GET - Display without tree (fullscreen)

BAL_DSP_PROFILE_POPUP_GET - Display without tree (popup)

BAL_DSP_PROFILE_DETLEVEL_GET - Hierarchy by message DETLEVEL

You can see this document to have more details about this subject.

If any aditional informations are needed, feel free to ask.

Best regards,

João Argêncio

[Former Member]

João Argêncio

thanks for the reply.

after you create the report, do you send it to the user? do you also create a file of the error records and send that with the user along with the error report?

does the user fix the errors a re-submit the file to be processed in foreground?

[Former Member]

In this type of developments, I have never had sent the file to the user. I save the execution logs with the most descriptive messages possible for the user correct the file.

This should be defined by the user as a development requisite. It all depends on the project specification.

Honestly I have never sent anything to the user... In these project it was always defined that the user had to consult the application logs always after the program execution. If a execution is planned via job, every night, there must be the consurn of checking the logs in the next morning.

One again, it depends of what is needed...

Best regards,

João Argêncio

[Former Member]

I've always thought that this is a big disadvantage of BAPIs.

One solution that you may want to consider is to process the BAPI; if it is successful, great; if it fails, use the input to create a batch input session for the error. This used to be the SAP recommended approach when using CALL TRANSACTION.

Rob

[Former Member]

Rob,

that sounds like a good idea. let me pose that to our group and see what the feedback is

thanks again

[paul_bakker2]

Hello,

That approach is so last century :-). We all have to move away from BDC sessions because soon they simply won't work anymore.

Our approach is the following:

- a nightly posting program picks up any new/unposted data & massages it into BAPI format

- if the posting is successful, mark the data as 'posted' (eg by writing an entry to a custom table, or by moving a file to a 'processed' directory)

- if the posting is unsuccessful, write a message to the user in the job log.

The next morning the user examines any errors in the log. Unlike BDC, errors in BAPI accounting doc postings are quite rare, and the error messages are usually informative (typically, a posting period is not open).

The user then must take action (eg to open the period) and rerun the posting program. This will pick up all unposted data & try the BAPI again.

Alternatively, the next night the posting program simply retries any unposted data.

We've been using this approach for the last 6 years with great success. No BDC sessions have been required to get the data posted.

hope this helps

Paul Bakker

[Former Member]

Paul

thanks for the reply

just so that I understand, the error records are written to a separate file and that will be used in the next night's run.

did you ever have a case where you had to make a change to the error file that is going to be used for the next night's run?

[paul_bakker2]

Hello,

The 'error records' (actually, unposted data) are just left where they are. The posting process picks them up and retries them every night until the error is fixed.

(The beauty of this approach is that no manual resubmission is required; retries are automatic.)

If these records were files of data, I suppose you could edit them to remove errors.

good luck

Paul Bakker

[Former Member]

All,

thanks for the answers to the questions.

we will use this information to help us discuss how to handle

[Former Member]

>

> (The beauty of this approach is that no manual resubmission is required; retries are automatic.)

But the problem is that if there is a data problem, say an invalid tax code, the problems cannot be fixed.

Rob

[Former Member]

Hi,

Did you got the solution for your query? if so what methos you sed?

-Syerra

[Former Member]

Syerra

we decided to go with the RFBIBL00 and rsbdcsub. we needed to have the ability for the users to be able to correct the errors in a timely manner. this is being used for the close process and we have a 1 day close. the users are in france and we are in the US so there is a time difference to consider.

[Former Member]

Hi,

I am also using the same BAPI for vendor invoice posting. The user is asking to process the errors of bapi to sm35 so that he can correct the errors. So inorder to implement that do i need to do recording also? and create session ?. The transaction FB60 is not allowing proper recording. That why we started using BAPI. So please advise us whetehr BAPI records can be passed to SM35 without recording? Please advise.

Syerra

[Former Member]

I was going to do that as well but we decided just to skip the BAPI.

we were going to record the errors and use RFBIBL00 and rsbdcsub to create FB01 entries using SM35. this way the user could correct the errors

hopes this helps