Skip to Content

After upgrading SRM to new release, sometimes you may find out some contact persons cannot be edited due to the error “Relationship XX XX XX do not exist”. They can not be saved in portal (SRM administration–> contact person) or edited in t-code BP.
/wp-content/uploads/2015/08/time_3png_780320.png
This error (R1 733) is raised from include LBURSF19, and system failed to find out relationship from FM BUB_BUPR_BUT050_LM_READ:

time-2.PNG
In the above coding, it will try to retrieve the relationship from BUT050, and here the date_to is set as ‘99991231’.
However this contact person has some specific value in date_to field instead of max date.

/wp-content/uploads/2015/08/time_6_780321.png

So the relationship can’t be found, and error message was raised to stop the save action.

Why is the date_to field set with value “99991231”?
This is a long story. Before upgrading, SRM system is set time dependency parameter TIMDP as ‘4’ which means BP relationships, such as contact person, is set up as time-dependent, so the date_to is stored with specific date.

time-1.PNG

However after upgrading SRM release, one component ‘MDM_TECH’ is introduced to SRM system.
MDM system makes use of Partner Functions and since they are time-Independent, BP relationships should also be time-independent.
MDM components should ideally be installed in systems that are not using contact persons in a time-dependant fashion.

So the time dependence parameter is always set to ‘0’ even if customizing (t-code BUBA) is set as ‘4’.
And maximum date 99991231 is set as search parameter to retrieve relationship. This is hard-coded, and cannot be changed for the moment.

time-4.PNG

Workaround:

If you unfortunately have such kind of problems, you need to identify these time-dependant contact relationships in BUT050 master table.

Search the BUT050 table with relationship type = BUR001 and check the validity of the records.

(i.e contact persons whose validities are different from

  valid_from = 01.01.0001

  valid_t0 = 31.12.9999 )

Modify these records so that they have the valid_from and valid_to values as shown above.

Do take a back up (in form of a text file or excel sheet) before modifying the records.

Change a single record first and check if this resolves the issue first.

Hope this would be of help for you, and welcome to any feedback about this.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply