Vendor Blocked in One Purchasing Org Only

A buyer reports that a purchase order cannot be created for a vendor they have used for years. The system throws an error referring to the vendor being blocked for purchasing. The confusing part is that a colleague in a different plant or company, using the same vendor number, creates a PO for that same vendor without any problem five minutes later. The requester assumes it is a system glitch because 'the vendor works fine elsewhere.' Sometimes this surfaces as a purchase requisition that will not convert, or as a source list entry that exists but cannot be used. Procurement escalates it as urgent because a delivery is due and nobody can explain why the same vendor is blocked in one plant's purchasing org and open everywhere else.

Pull the vendor master purchasing org data view for every purchasing org the vendor holds, listing the block indicator value side by side. Combine this with the change document history for the purchasing org segment, showing the user, date, and old-to-new value of the block field. Overlay the purchase order creation error log referencing the vendor and purchasing org to tie the business complaint to the exact segment carrying the flag.

If the block is a deliberate procurement decision tied to a quality or delivery issue, this is not an IT fix at all: the category buyer or procurement lead who owns the vendor relationship for that purch org must decide whether the issue is resolved, then remove the block via a master data change on the purchasing org segment. If the block was introduced accidentally through a mass change or migration, the correction is a targeted master data update reverting the flag on that specific purch org segment, ideally cross-checked against the change document to confirm what the value was before the load. If the vendor was simply never extended to the purchasing org, the fix is extending the vendor to that org with the correct purchasing data, not touching any block field. None of these paths require a transport; vendor master blocks and extensions are master data changes, not customizing. A transport is only relevant on the rare occasion the underlying blocking reason or vendor evaluation scoring rule itself needs adjustment.

The near-universal reflex is to remove the block at the general or company code level to make the error go away quickly. This clears the symptom everywhere, including in purchasing orgs where the block was never present, and defeats the purpose of a deliberate, scoped block that procurement placed there for a reason. It also erases the audit trail of why the vendor was restricted for that specific plant, so the same quality or delivery problem resurfaces later with no record of it having been flagged before.

Vendor master data and its purchasing org blocks are owned by procurement master data governance, with the block-or-unblock decision resting on the category buyer responsible for that purchasing org. The handover note states the purch org affected, the block reason and date it was set, who set it, and whether the underlying issue (quality, delivery, pricing) has actually been resolved before any unblock request is approved.