Duplicate invoice issue - how can we put validation using ABAP?

[ashwinipingle]

Hi Experts,

This query might belong to ABAP/PI/ Functional. However I will start with ABAP.

Scenario

We have a scenario where invoices are created in 3rd party application and passed on the SAP ECC through SAP PI (3rd party system --> SAP PI --> SAP ECC). These invoices are posted in SAP ECC. Invoices are entered in 3rd party system either manually or through xls upload. Every time 3rd party system calls SAP PI and which in turn calls SAP ECC ABAP program to post the invoice. During xls upload, we are getting the same invoice from 3rd party system twice (e.g. if 50 invoices, then we get 100 calls to PI).

Problem

Excel upload of invoices in 3rd party system

Problem is we are unable to catch when the invoice is duplicate in SAP ECC end. Hence one invoice is getting posted twice in SAP ECC. Standard BAPI is called to post the invoice.

Reason for this is that the invoices come in so fast that the standard BAPI is unable to save the first record before which even the second duplicate invoice starts getting posted. Hence we don't get the error message from BAPI.

However when there is a manual entry of invoice in 3rd party system, we don't face issue of duplicate invoice since the earlier record gets time to be saved/posted in SAP ECC so if next manual entry is duplicated, the BAPI throws the error.

Question

How can we catch the duplicate invoice issue on the SAP ECC side? We do not have any privilege to catch it on the 3rd party system. Can we do it in PI side?

[JL23]

Are you talking about invoices from vendor or invoices to customers?

In case of vendor invoices you can set the indicator for "check double invoices" in the vendor master.

[raymond_giuseppi]

If I understand correctly the attachment, you receive two invoices, before the first one is commited to database, so yes standard check won't detect it (be it vendor or customer)

Only solution I could suggest is usage of lock concept, lock the vendor, customer or other reference object available (like a sales/purchase order?) of course use the _WAIT option in the call of the ENQUEUE FM.

Regards,

Raymond

[former_member202957]

Hi,

I suggest to create a custom table which will hold the invoice no and flag ( processed)  which will save the data from PI before posting . Follow these steps.

1. Before you call BAPI save the information in this table for all the invoices which are not found.

2. Validate the flag processing = space ( invoices exits are not processed).

3. if you find invoice exists in table or already processed delete those from internal table and send it to BAPI.

[ashwinipingle]

Can we do inserts into a table from PI and add a logic in PI to check this table every time? As per my understanding (and it may be wrong), we cannot put any logic in PI.

We do not have any control on the 3rd party system and cannot make changes there.

[former_member202957]

Hi,

As you are calling ABAP program in PI, you can add logic in the calling program.

[Jelena]

The external system clearly sucks here. But other than changing the vendor there are not that many possible solutions in general - either you need to get rid of the duplicates before posting the data or you need to slow down the updates to the point where the standard duplicate check can catch them.

In the "get rid of duplicates" department I'm not sure what is possible in PI (it's ABAP forum) but maybe it could somehow "stage" the data before sending it to SAP? Perhaps there is some kind of signal that the current "batch" of data is done. Then PI could sift through the whole "batch", remove duplicates and only then make a call to SAP.

On the SAP side you can, of course, slow down the process brutally by adding "WAIT UP TO..." or a similar approach. Search SCN, there have been many options discussed on how to slow down the program's execution.

Also I'm not sure how BAPI is called exactly but there is such thing as queued RFC (qRFC) in SAP that is like RFC but serialized. I have not used it myself, but heard it suggested in the scenarios when the calls need to form a single queue (i.e. the next one must not be processed until the first one is done). Google if you need more information on this.

[former_member186746]

Hi,

Other than changing the process to first gather all of the to be made invoices before using the BAPI, your only option is to put in some kind of wait functionality.

Kind regards, Rob Dielemans

[Clemenss]

- you can (and should) do nothing about the external system except talk to them 🙂

- Catch in PI is not advisable as PI's purpose ist neither to store nor to check documents

- If you can identify the duplicate (how do you?) within any exit and stop before saving. Foe reasons of clarity it may be better to store any incoming documents (vendor/customer?) as they come and have a report detect the duplicates, cancel them an take appropriate action to inform the sender.

Regards

Clemens

[Juwin]

Isn't this an explained/known issue in SAP: SAP Note 1784381

I don't think there is a standard solution for this. I wouldn't recommend building a duplicate check anywhere other than the end system, in the interface chain - in your case it is ECC. This is because the duplicity can happen due to an error in any of the intermediate systems and ECC should be able to capture all of that.

As others have already pointed out, Locking/ Staging/ Queuing are all good ways to handle this issue. Locking mechanism allows you to keep your interface synchronous, while other methods will require you to convert the interface into asynchronous.

Thanks,

Juwin

[Jelena]

Thanks, Juwin. Text from the note: "SAP assumes that the risk of a simultaneous entry of these invoices is negligible." Under normal circumstances I agree it'd be just very unusual for the duplicate invoices to be posted in such a short time frame. But from the OP it seems as if the external system always sends duplicate invoices unless they are entered manually. And this is messed up.

@OP - if the situation was described correctly then this really needs to be raised with the vendor. It does not matter if their CFO plays golf with your CFO or something. Even if for any reason you're stuck with this system it is clearly a defect and needs to be fixed on their side.

[Juwin]

I agree, in OP's case, SAP's assumption doesn't hold good. I gave the reference to note, just to point out that SAP has not provided a standard solution for this issue.

Thanks,

Juwin

[William_Laverde]

Hello Ashwini,

The functionality 'duplicate invoice check' is considered only as a "pure online functionality", and is used in MM-invoice on-line process to prevent a (dialog-) USER from inadvertently the same invoice twice.

Please review note 394316 and consider to add FM "MRM_DUPLICATE_INVOICE_CHECK" in your own program before calling FM BAPI_INCOMINGINVOICE_CREATE or before BAPI's commit calling FM BAPI_TRANSACTION_COMMIT

I hope this helps you.

[Jelena]

This FM is not released. As already noted above, the issue is not that the duplicate check does not work, it's just the update happens too fast for it to kick in. I believe all the necessary information has already been given to OP here, so they just need to follow up.