PO in continuous GTS SPL Block Loop

[former_member457182]

Hi All,

We've a scenario wherein the PO is blocked due to SPL screening check. The user is manually releasing the blocked documents. However the PO is again getting blocked for SPL. The audit trail in the PO Change history shows system adding '..' to 'Your Reference' in the PO and then removing the same to re-trigger SPL check and then the PO is getting blocked again.

User has released the PO more than 10 times but it's getting blocked again.

Any help with this regard is much appreciated.

Regards

Zuber U. Mohammed

[mouaz_benredjeb]

mmm... your mention of the field "reference" being changed to '.' stills makes me think that the issue is somehow related to the Start of the Follow-on functions...

Could you please try to temporarily deactivate the start of the follow-on functions? This can be done either by changing the GTS customizing or stopping the ECC job that processes the entries for follow-on functions (program /SAPSLL/MM0A_OBJSSF_PROCESS_R3).

The objective is to check if after deactivating the start of the follow-on functions you still have the SPL block loop. If yes, then we know that there is something to done/fixed in this area...

[mouaz_benredjeb]

Hi Zuber,

Have you activated the synchronous or asynchronous SPL checks for the document?

If you are using the asynchronous SPL check, then this is normal that the PO is getting blocked by SPL, you would get here the yellow triangle in the traffic lights of the document, to indicate that the document is awaiting to be screened (because asynchronous checks). GTS standard behavior is to consider the document as blocked until it gets screened.

That being said, I believe that you also have activated the Start of Follow-on function (I am guessing this from the change in the field "Reference" you have mentioned). If my assumption is right, then I believe the "loop" you are going through is the following:

(1) PO with changed address replicated to GTS

(2) In GTS, asynchronous SPL check is activated -> PO is blocked (soft block)

(3) User (or batch job) screens the PO replica -> the PO is released

(4) The PO release triggers the Start of the follow-on function

(5) The Start of the follow-on function triggers the change of the field "reference" with '.' in the PO

(6) As the PO reference is changed, PO is saved again and it goes to GTS again

(7) In GTS, asynchronous SPL check is activated -> PO is blocked (soft block)

(and the loop starts again from the Step 2 above)

I would suggest changing the SPL time of check (for documents) from Asynchronous to Synchronous to solve this issue,

Hope this helps.

Mouaz BEN REDJEB

[former_member457182]

Hi Mouaz,

Thanks for sharing your inputs.

For the SPL time of check (for documents), please let me know if you're referring to the configuration in the following path.

SPRO --> Global Trade Services --> General Settings --> Document Structure --> Activate Item Categories for Application Areas --> Activation for Sanctioned Party List Screening (IMORD1) --> SPL Screening Time.

If you're referring to the configuration in the above path, then I'm afraid it's already maintained as - '1 Synchronous - When Object is Updated'.

Thanks for your help and appreciate your support, unfortunately the issue is not resolved yet.

Regards

Zuber U. Mohammed

[gnishant]

The situation you mention is normal in GTS. If the address is changed in PO, it will be screened, and if it matches with sanctioned parties, the PO will be blocked. And even if you release, if the address is changed again on PO, it will be screened and blocked (if matches with SPL data).

Few points to consider:

• Are you using the SPL data with other scripts (arabic, cyrillic, ...), or only English? If you use the Arabic scripts names in the SPL data, the quality of match will be better.
• Are Name 3 and Name 4 reserved for names in Arabic only. And you would not like to screen them. You may consider to exclude them from SPL screening (in configuration).

[former_member457182]

Thanks for sharing your inputs.

Change of address triggering the SPL check again is a standard SAP behavior. However I believe once it's released in GTS, the block should be removed. Unfortunately in our case it's going into a block loop. Please note the address is only being changed once. In my opinion the document should go through 1 cycle of block and if removed, the transaction should be fine until the address is changed again.

My comments on the points you mentioned.

• Are you using the SPL data with other scripts (arabic, cyrillic, ...), or only English? If you use the Arabic scripts names in the SPL data, the quality of match will be better - No, we're not using SPL data with other scripts. Only English language is being used. Also, the hit is based on English name.
• Are Name 3 and Name 4 reserved for names in Arabic only. And you would not like to screen them. You may consider to exclude them from SPL screening (in configuration).- Name3 and Name4 are being used by the Procurement team to maintain Vendor name in Arabic.

I assume the configuration which you're referring to is 'Define comparison procedure for Address Comparison'. However I believe this configuration is not for BP Address fields but for SPL data. I've removed Name3 and Name4 and tested this as well but the issue is not resolved.
PFB the link that highlights the point that the configuration is related to SPL and not BP.

https://answers.sap.com/questions/9985891/spl-name2-field-removed-form-assign-address-check-.html

Thanks for your help and appreciate your support.

Regards

Zuber U. Mohammed

[gnishant]

Zuber, any reason, why you don't release the blocked partner.

[former_member457182]

Hi Nishant,

Thanks for your response. To answer your question, the Business Partner is not blocked in GTS.

Let me put more clarity on the issue we're facing. When the PO is getting created, the user is manually changing the Vendor address (Addition of email address etc). Since the Address is getting changed in comparison with the address maintained in GTS BP, the system is triggering an SPL check and is blocking the PO based on the hit received.

The Trade and compliance team is releasing the block however the PO is going into an SPL Block loop in the below two scenarios.

Scenario #1 : Presence of Arabic Text in Name3 is causing the PO to go into SPL Block loop. The only option right now to resolve the block loop is to manually delete the Arabic characters in Name3 in the PO. (P.S : We've asked the business to maintain Arabic letters under 'International Address' for the Vendor, however the business is adamant on maintaining the Arabic name in the Standard ADRC Name3 & Name4 Fields).

Scenario #2: Addition of secondary email address in PO Address is causing the PO to go into SPL Block loop.

Hope the scenarios are now clear.

Any help in this regard is much appreciated.

Regards

Zuber U. Mohammed