Error log for FM POST_DOCUMENT

[Former Member]

Hi Experts,

I have used 'POST_DOCUMENT' FM for uploading recurring documents, but there is no return structure fot the FM.

Is there any way I can get the error log?

I read somewhere to use 'BAL_DSP_LOG_DISPLAY' for getting the log.

Please suggest what is the best solution to get the return messages, without which the implementation is futile.

Best Regards and thanks,

Sumit

[Former Member]

Hi Sumit,

The FM is update function module this usually will be called at the end of transaction in update task hence expected all the basic validations are done before calling the FM. Inside the FM it will directly raise the E or A message.

As work around you can try with calling exception ERROR_MESSAGE, you can catch message of type E or A raised in the FM. Lets wait for experts opinion.

Thanks & Regards,

Arun

[Former Member]

Hi Aruna,

Thanks for the prompt response.

Yes.. I am calling it in update task. But when I have to load bulk documents, in case of error I need to track the error for reloading the erroneous entries.

I checked SQL trace to see if it updates the error mesaages somewhere. But no luck..

Regards,

Sumit.

[Mohamed_Mukhtar]

Hello Sumit,

If the FM is called in update task, it means that FM will be executed in update work process.

If there is any error encountered and then update termination will happen and can be seen in SM13.

THe update FM's are called after all validations checks . The error handling needs to be done before update FM

Thanks

[Former Member]

Hi Always learner,

thats was really helpful.

this is how I think i'll go-

->vbhdr/vberror tables -> key is VBKEY. there I get the message class and message number. I can read that easily.

So only thing is to get the VBKEY for update FM run.. Where will I find it @runtime?

Regards,

Sumit

[Mohamed_Mukhtar]

Hello Sumit,

The runtime information of update FM cannot be determined since a separate work process will be created.

So you better follow approach suggested by . It will be easy to track messages since the FM's will return the error log.

Thanks

[raymond_giuseppi]

This FM is an update FM and must not be used, as it wont update many tables and wont perform most of the check included in standard. You could look at include MF05AFF0_FCODE_BEARBEITUNG to get an idea on missing calls...

Better use a BAPI like BAPI_ACC_DOCUMENT_POST or FM like POSTING_INTERFACE_DOCUMENT that generates BDC.

Regards,

Raymond

[Former Member]

Hello Raymond,

Thanks a lot for the suggestion.

The thing is that I have already tried the above BAPIs, but unfortunately they either dont create recurring documents or if at all they do, the interface parameters are very complex. I searched a lot over the net for their usage but all they create is normal FI docs but not recurring docs(tcode FBD1)

(I am very new to FI scenarios so unaware of actual FI terminologies)

FM POST_DOCUMENT has the exact intf. parameters required.. like BKDF, BKPF and BSEG tables.

I am able to create them properly in the system too.

Therefore request you to help with the same approach.

Probably I could run another program separately after the update program to get the log data.

Regards,

Sumit

[raymond_giuseppi]

I am able to create them properly in the system too.

Of course, using this FM you may have bypassed many controls...

I cannot suggest you to use this FM as I won’t do it myself, if you actually want to get error, try some TRY/CATCH/ENDTRY syntax or use generic EXCEPTIONS error_message = n clause in the case (but vs an "Abort message, not much solution.) AT YOUR OWN RISKS...

Nevertheless if you called it in update task, you should be able to find errors with transaction SM13 or analyze code of FORM load_upd_records(sapmsm13).

Regards,

Raymond

[Former Member]

Hi Raymond,

Thanks

Can you please give more details about the generic exception handling.

Also if I could read the error log for SM13.

I see it in VBHDR and VBERROR tables, but do not know how to get the key.

Regards,

Thanks.