Custom BP Relationship Category and KNVK synchronization
This post starts my Business Partner blog series. It will include several posts about small and big enhancements that can be made to BP using standard tools.
Chapter 1: Custom BP Relationship Category
Using BDT Transaction it is possible to create a custom relationship category, that can help you in better description of relationships between business partners. That is also valid for Contact Person.
Contact Persons are no longer just entries in KNVK table but are Business Partners.
There are several posts how to create, assign, handle the relationships but none of them shows the problem that happens when you create your custom relationship category.
To see if you have custom roles call transaction BUPT and find transaction BUBA:
This is the place where you define possible categories – if you want to use your category for contact person, then copy the standard category BUR001 to your custom one – like I did:
That customizing (rest is copied from standard category BUR001 ) is enough to see and assign new relationship between BPs:
However, when you save the data system is not automatically creating a link in KNVK table. That is standard behavior stated in In OSS Note 2822189 – Contact person assigned to custom relationship category cannot be found in table KNVK
That’s strange isn’t it? Normally there should be a customizing table for that in SAP, however this time it is hardcoded.
Chapter 2: The KNVK situation
Having learned that SAP just does its own way in terms of KNVK situation, you could contact OSS Support but they would redirect you to that one sentence in the abovementioned note, which says:
“Make enhancement with BADI CVI_CUSTOM_MAPPER.”
Pretty straight forward and useful, isn’t it?
So you could dig out the method MAP_BP_REL_TO_CUSTOMER_CONTACT and think that you’re done – just lets do some straightforward mapping here and you’re home.
Unfortunately real life is a little bit more complicated.
The custom BADI method MAP_BP_REL_TO_CUSTOMER_CONTACT is called insdide standard class CVI_MAPPER in method MAP_BPS_TO_CUSTOMERS.
That method controls the assignment of Relationships and what should be passed to KNVK table.
If you go with method suggested by SAP and use your custom BADI implementation you would need to make sure that following situations are handled explicitely in your code:
- Insert of new lines
- Update of existing lines
- Deletion of existing lines
- All field mapping from Contact Person to KNVK entry
That does not sound very scary but if you look inside standard code that is executed before BADI method is called you can see that over 700 lines of code in front of your eyes. That is something would need to replicate in your custom code.
A second thought crosses your mind then – if SAP says they limited the category to BUR001, then that limitation must be somewhere in the code.
During code analysis of method MAP_BPS_TO_CUSTOMERS usage of constant of cvi_ka_bp_customer=>rel_type_contact can be quickly spotted – bingo!
Now you only need to look in which places that constant is used and make a modification of standard code removing the unnecessary limitation.
Please be aware that this constant is used many times in this method so you must change several lines. Still that is easier than rewriting standard code in your custom method.
Afterwards create a BP relationship using your custom category and see if it is updated both in BUT051 and KNVK:
In such way with just a simple modification you have enabled standard functionality for KNVK replication from any kind of BP Relationship Category.
Chapter 3: My ask to SAP
Hardcoding such customizing options like above in such a flexible solution as BDT is ( which is an awesome tool ) should not really take place. Because of that lot of custom code of modifications must be made.
Please introduce a customizing table in which you can flexibly control which relationship categories are replicated to KNVK.
Great blog! I agree that hardcoding here is a mistake and should be corrected.
I just wonder - without digging through the code - if you remove the check on relationship BUR001 - would't that create KNVK entries for any relationship category? There are many where it is not ideal.