V_VBAK_VKO — Sales Document Sales Area Authorization Check

V_VBAK_VKO guards who can create, change or display a sales document based on the sales area recorded in the document header - sales organization, distribution channel and division - together with the activity being performed. The structural fact that causes most confusion: this object is checked independently of V_VBAK_AAT, which restricts by sales document type. SAP evaluates both. A user can hold full authorization for the document type and still be blocked because the sales area combination on that specific order falls outside their V_VBAK_VKO authorization, and vice versa. Consultants troubleshooting an authorization failure on a sales order almost always need to check both objects, not just the one that happens to show up first in a trace, because the two failures look identical from the user's side - a generic 'no authorization' message with no indication of which object stopped the transaction.

The check runs inside the standard sales order processing transactions - order create and change, quotation and contract maintenance, scheduling agreement processing - at the point where the document's sales area is read from the header and matched against the user's authorization before any line-item processing or ATP check occurs. It is also checked on document display, including drilldowns from delivery or billing document displays back into the originating order, which is why a user can sometimes bill a document but not open the order that generated it. Custom programs and BAPIs built on the standard sales document processing logic inherit the same check if they call the standard function modules underneath; custom Z-transactions that bypass those function modules and go straight to table access do not enforce it, which is a common gap flagged in security audits.

Start with SU53 immediately after the failure, run by the affected user in the same session, since SU53 only shows the last failed check and a delay or intervening transaction overwrites it. If SU53 is inconclusive or the user has already moved on, use the authorization trace (ST01 classic trace or STAUTHTRACE where available) filtered to the user ID and object V_VBAK_VKO, then reproduce the exact transaction and document. Confirm which field failed - VKORG, VTWEG, SPART or ACTVT - and read off the actual value on the document header, not the value the user expects to be there; a document created under the wrong sales area is a frequent root cause and looks identical to a genuine authorization gap. Hand the security team the user ID, the transaction code, the document number, the failing field and value, and the activity attempted. Do not ask for 'full access to VKORG' as a blanket fix; that broadens the role far beyond what the incident requires.

This is a security team change once the functional side has identified the exact field, value and activity that failed. A good request names the transaction, the document's actual sales area values, the activity code, and states whether the gap is a missing sales area assignment or a missing activity, so security can add a precise authorization rather than widen an entire role.

A role that appears correct in PFCG often fails because the organizational values were maintained against a different sales area than the one actually used on the document - a new distribution channel added to the sales area configuration but never added to any role's V_VBAK_VKO authorization is the single most common cause. Consultants also assume a display failure means the user needs create access, when the real gap is display authorization for a sales area they have never been granted at all, even though they were never expected to create documents there. Another recurring case: the user has full authorization for the sales area but the failure is actually on ACTVT, because a role grants 03 (display) only and the user is attempting 02 (change) on an existing order. Finally, because V_VBAK_VKO and V_VBAK_AAT are checked separately, fixing one without checking the other leaves the transaction still blocked, and the second failure is often misread as the first fix not having taken effect.