Document blocked due to SPL >> corrupt business partner (BUT000)

[Former Member]

Hi GTS folks,

in our GTS system we have the current constellation which results in several incident tickets per month:

Document in GTS is blocked for SPL. When we check for the business partner who caused this block we can see that the business partner itself is not created properly in GTS.

During master data transfer from R/3 (standard report) the BP will be created in table /SAPSLL/PNTBP but not in the corresponding tables like BUT000.

If we try to retransfer the BP from R/3 again there is a error message:

"Of 1 selected partner(s), 0 were processed successfully"

If we check BP transfer log in GTS (/SAPSLL/PARTNER_APPL) it also says:

Activity: Change 2799844

Business partner 2421423 does not exist

Business partner  does not have GUID 001871ECE4C11EE385D83A7135B49A12

Workaround: Delete corrupt data set from /SAPSLL/PNTBP via debug&replace and re-transfer the BP from R/3, then re-transfer the sales/purchase document itself. SPL block is gone.

I guess there are also other customers who face this issue.

Is there maybe a OSS note for this?

Best Regards

Greg

[former_member215181 · Accepted solution]

Hi Greg,

Take a look at KBA Note 1824797.  There the support team have described exactly the symptoms you are experiencing, although unfortunately give no real information about the cause.

I would start by checking the logs for the initial transfer of those Business Partners - do they give any clues?  I wonder if some code list entries are different between your ERP and GTS systems: it might be worth checking through the customizing settings in the Cross-Application Components > SAP Business Partner area to ensure that both systems are aligned.

You don't mention which version of GTS you are using, but since you seem to have the problem with Sales and Purchasing documents, presumably the symptoms affect both Customers and Vendors?  That fact may help you narrow down the search for the answer.

Regards,

Dave

[Former Member · Accepted solution]

Hi Dave,

Thanks a lot for your feedback!

(Sorry for my very belated reply though)

The SAP note really helps even though I do still have some issues with the solution itself.

The solution is to execute the report /SAPSLL/BP_DATA_CLEANUP.

When I first executed this report in our test environment it had a runtime of 15 or 16 days. Our tech guys told me that the report didn't perform any action for most of the running time (idle).

Some days ago I had a new issue with another corrupt business partner in GTS.

I executed the report with one single business partner in our production system and it took exactly 11.565 seconds (more than 3 hrs).

The is what the spool gives as an output:

Business Partners	Remarks	Table Name
123example	Archive the listed objects manually	/SAPSLL/CORPAR
123example	The entry has been successfully deleted	/SAPSLL/PARMA
123example	Archive the listed objects manually	/SAPSLL/SPLAUD

Did anyone else ever work with this report before and can report similar issues regarding the immense runtime?

Cheers

Greg

[corinne_stevens · Accepted solution]

Hi Dave,

We are experiencing the same issue in our system. Multiple customers that didn't get transferred. First they were showing up in the System monitoring. Towards the end of the day, weirdly, the were all gone - log was clear. However, when I try to select one of these partners in e.g. Display blocked business partners, it says it doesn't exist.

We have done the clean up thing earlier this year, but my problem is with the recently loaded data. These will start getting used when we go live in New Zealand. And I would prefer to have the data in as best shape as possible.To avoid delays when they start using the data.

So my question is: is there any way of finding out which of the records we manually transferred will cause issues? Like I said, the log is clear, so that's no source. In BUT000 the GUID is there (I was expecting blanks maybe, but unfortunately not). So that's no source either.  Maybe you have something?

Thanks in advance!

[former_member215181 · Accepted solution]

Hi Corinne,

That sounds like a pretty bad situation!

I would start by comparing the BUT000 records with the ones in /SAPSLL/PNTBP.  You might have to write a simple report, but should be able to do it with SQVI, using a "left join", reporting the entries in BUT000 that don't have a counterpart in the GTS table - those are the ones that will cause problems.

Delete those records in BUT000 using Transaction BUPA_DEL, then re-transfer those partners again.  Hopefully the second transfer should work correctly.  Maybe I've been lucky, but I've never encountered those issues in the past.

Good luck!

Regards,

Dave

[Former Member · Accepted solution]

Hello Gregor,

we have experienced the same. The standard report has really "slow" selects in the code. Its not the best code ever. At the end when you have entries in corpar or splaud it wont fix pntbp anyway.

To be fair we didnt have this so often so edit in debug was kind of workaround with firefighter user in p-system. We were also trying to debug and find out what is causing this issue, but at the time we find the issue the test case was already gone.

Kind regards,

Gabriel.

[Former Member · Accepted solution]

Hello Corinne,

What is your set up? Do you have more systems in one logical system group? In case yes, do you use anything like transcoding of partner numbers in case the number is the same but partner is different?

Kr,

Gabriel.

[corinne_stevens · Accepted solution]

Hi Dave,

Thanks very much. Can't write that code myself, but will find somebody who can!

Cheers, Corinne

[corinne_stevens · Accepted solution]

Hi Gabriel,

No, we only have one logical system group. So no transcoding .

Thanks!

[Former Member · Accepted solution]

Hi Corinne, Greg,

Whenever I`ve seen this error it was always due to the lack of awareness that after deleting BP in GTS with BUPA_DEL, the pointer table cleanup program /SAPSLL/BP_DATA_CLEANUP was not executed with the same partners - this then also relates to the runtime duration of the cleanup report : If somebody deletes say 10 BPs and then puts the same 10 into cleanup report, this will all happen in 3 minutes... If this is followed properly by gts master data team.

As mentioned, The BP transfer program first check if the the entry exists for the Cust/Vendor number in the pointer table and if its there tries to update BP with a guid from pointer, but this guid does not exist in BUT* tables because it was deleted, hence the error

What Dave suggested, cleanup of all BPs in GTS with BUPA_DEL and the cleanup report, then subsequent repeat of initial customer/vendor transfer to GTS is a long term fix, and as you are not live yet this should be possible in your dev/qa ? Especially if you`re validating data loads before golive

One way to avoid this in future, is to only set the 'deletion flag' on BP and dont actually delete, or include the cleanup report in archiving/deleting sequence.

Best Regards,

Branio

Branislav Petricek