Using ALEAUD for application reply? or build a new IDOC ?

[Former Member]

Hello.

I have a scenario where a 3rd party sends me a message, that I map in my PI to an ACC_DOCUMENT IDOC.

I need to send a reply on the ACC_DOCUMENT IDOC after processing it.

The reply must contain several applicative values from the IDOC - so that the 3rd party will be able to

"understand" on what message it receives the reply.

Should I use ALEAUD in this case? I'll have to add an extension so that it will contain the applicative values.

Or should I build a new IDOC or ABAP proxy to send the reply back? will I be able to generate it when I process the IDOC?

Anyone has a Rule of thumb on this matter?

Thanks in advance,

Imanuel Rahamim.

[gagandeep_batra · Accepted solution]

Hi

According to my point of understanding ABAP Proxy should be the batter option because You want to sned application data after completion of the processing of IDOC . this require ABAP code to be implement. So ABAP proxy should be the batter option..

Thanks

Gagndeep.

[former_member184681]

Hi,

If you want to give the application response with minimal effor, you might want to change the ACC_DOCUMENT IDoc used so far to calling BAPI_ACC_DOCUMENT_POST. Actually, their data structures are identical, because ACC_DOCUMENT is an ALE interface generated for this BAPI. Thanks to this, you will immediately receive application response from your ECC system, including information like document number of the document posted, and similar.

Alternatively, if you do not want to use synchronous scenario, I recommend developing a custom ABAP Proxy that you will use to pass posting information from ECC to PI to your 3rd party system. You can call this Proxy after each IDoc is posted, or on a regular basis to collect multiple postings information into a single call. I think this will be easier to do it from scratch than to enhance ALEAUD message.

Or you can go one step further and configure FIDCC2 IDoc distribution to have the financial postings automatically sent from ECC to PI to 3rd party, immediately after the posting document is created. It is up to you to decide, based on the actual requirements and possibilities of the 3rd party system.

Hope you'll find this useful,

Greg

[Former Member]

First of all Thanks for the quick reply.

It looks that The FIDCC2 option will be great.

How can I trigger a FIDCC2 after each ACC_DOCUMENT processing?

About BAPI_ACC_DOCUMENT_POST.

I debugged the processing of an example IDOC and I got to the BAPI_ACC_DOCUMENT_POST

However it seems that when excuting the BAPI I still don't know if the IDOC processed successfully or not.

I also need to return this information to the 3rd party.

Is that possible?

Thanks again,

Imanuel.

[former_member184681]

How can I trigger a FIDCC2 after each ACC_DOCUMENT processing?

Actually, you don't do it after incoming ACC_DOCUMENT, but once a financial posting document is created (which is done by this incoming IDoc). In other words, incoming ACC_DOCUMENT and outgoing FIDCC2 are not connected directly. It would work like that:

1. Sending triggered from 3rd party -> PI processing -> ACC_DOCUMENT sent to ECC -> financial posting document created -> end of processing for this interface

2. When financial posting document is created -> trigger FIDCC2 from ECC -> PI processing -> deliver necessary posting information to 3rd party -> end of processing.

When I mentioned the BAPI_ACC_DOCUMENT_POST, I actually meant using it instead of ACC_DOCUMENT IDoc. So you will trigger this BAPI directly from PI (change receiver adapter from IDoc to RFC). This way, you will receive a real synchronous response from your ECC system.

[Former Member]

Hello.

What I'll do in the end is using an enhancement point in the end of BAPI_IDOC_INPUT1 (we use BAPI process code to process the IDOC) and send a proxy back to the 3rd party.

I didn't want to make a sync update scenario, and as our FI people wanted a reply even if the IDOC processing failed (status 51) - I couldn't rely on FIDCC2.

Thank you both for helping out.