cancel
Showing results for 
Search instead for 
Did you mean: 

PO is not blocking in SUS

Former Member
0 Kudos

Hi Guru's,

Scenario: When vendors are created in ECC are replicated through some program to SUS and creates a Business Partner to that vendor in SUS.

Case1: While creating the PO for that vendor in ECC its get replicated in SUS and mails will triggers to the suppliers who are there in BP and it is in success state in SXMB_MONI..

Case2: If that Vendor is not present in SUS it has to block the PO creating in SUS side it will in error state in SXMB_MONI.

Case3: This case is Very important, If you created a vendor and that is not replicated in SUS and this vendor number is similar to the one of the BP number in SUS, this is happened unfortunately, Now if you create a PO with this vendor and this PO is passing successfully to SUS. Why it is allowing in SUS side even though that vendor is not present in SUS side.While checking in SXMB_MONI it is showing success message.

Is this vendor comparing with vendor's in SUS and vendor is not there then is it comparing with BP ?

Here is there any setting to make to stop that PO and in SUS side they are using Proxy to create a PO and this is  Standard Code and they are using standard FM unable find through debugging.

Proxy class      :  CL_BBPX1_SUSPO_IN

FM in this class : BBP_SAPXML1_SUSPO_CREATE_IN

                

Thanks in Advance.

Regards,

Sairama.

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi,

I would have assumed that inbound logic uses table VENMAP for validating if a vendor exists or not.

This table references the ECC vendor to the SUS partner guid and also has the logical system of the ECC system as key.

Without such a mapping logic, you would always get a lot of problems if more than one ECC system is connected.

So what you should do first is to check if an entry exists in table venmap for the vendor in case 3.

If it doesn't exist then open an OSS message.

Of course you could also block the PO creation within a BAdi, but it clearly should be handled by standard.

Markus