V_LIKP_VST — Authorization Object for Delivery Shipping Point
V_LIKP_VST controls access to outbound and inbound deliveries based on the shipping point (VSTEL) stored on the delivery header, combined with the activity being performed. It is the object that most often blocks delivery creation, change, or display when a user's role is scoped to certain warehouses or distribution centers but not others.
This page covers the authorization object V_LIKP_VST, which restricts delivery processing by shipping point and activity. It focuses on where the check fires during delivery creation and processing, how to read a failed check in SU53 or the trace, and the pitfalls that make a seemingly correct role still block a user.
Reviewed by an ERPClimb SAP consultant on 16 Sept 2026· 852 words
What it protects
V_LIKP_VST guards access to the delivery document (table LIKP) at the point where the shipping point is known, which in practice means every create, change, and display operation on outbound and inbound deliveries. The structural fact that causes most confusion is that shipping point is a warehouse-level concept, not a sales-org or plant-level one, so a user can be fully authorized for a sales organization and plant and still be blocked here because their role only lists a subset of the shipping points tied to that plant. Multiple shipping points frequently sit under one plant, and delivery-relevant authorization is checked against the specific shipping point on the document, not the plant it belongs to.
Fields checked
- ACTVT - the activity attempted: 01 create, 02 change, 03 display, and occasionally other values for specific delivery-related operations such as delete.
- VSTEL - the shipping point stored on the delivery header. This is the value that must match one of the shipping points assigned in the user's role, either as an explicit list or an organizational level pattern.
Where it is checked
The check fires wherever a delivery document is touched with a shipping point already determined. It runs in single delivery create and change (VL01N, VL02N), display (VL03N), the delivery due list and collective creation transactions used to turn sales orders into deliveries, and the delivery and shipment monitors used for mass processing. It also fires during goods issue posting against a delivery, during packing and picking transactions that operate on the delivery, and during delivery split or combination. Background and batch delivery creation, including EDI or IDoc-driven delivery creation, runs the same check under the processing user's authorization, which is why a batch job can fail even though the requesting business user has no problem. The check happens after the system has resolved which shipping point applies to the document, so it is a downstream check relative to shipping point determination, not a substitute for it.
How to trace a failed check
Start with SU53 run immediately after the failure, before anyone else in the session triggers another authorization check, since SU53 only shows the most recent failed object. Confirm the object listed is V_LIKP_VST and read off the VSTEL value the check failed on and the ACTVT value attempted; compare that VSTEL against the values actually maintained in the user's role. If SU53 is empty or shows an unrelated object, because a background job or a different user session obscured it, switch to the authorization trace transaction and reproduce the failing action for the specific user, then filter the trace results to V_LIKP_VST. Hand the security team the user ID, the transaction and step being executed, the exact shipping point value from the failed check, the activity code, and whether the flow is online or from a batch job, since batch failures need the batch user's role checked, not the requester's.
Whose problem this is
This is a shared problem but usually starts functional: the consultant identifies which shipping points the user's business role should cover, based on which warehouses or plants they work with, then hands security a request naming the user, the required shipping point values, the activities needed (create, change, display), and the transactions involved.
Common pitfalls
- A role lists the correct plant-level authorizations but omits one or more shipping points under that plant, since shipping point and plant are maintained separately and do not derive from each other automatically.
- A newly created shipping point, added when a warehouse or distribution center goes live, is never added to the roles that need it, so failures appear only for that new location and are mistaken for a data setup issue rather than an authorization gap.
- ACTVT mismatch: a user with display-only access (03) attempts a change operation and the failure is diagnosed as a shipping point problem when the real gap is the missing activity value.
- Consultants fix V_LIKP_VST and consider the case closed, without noticing that an earlier check in the same flow, on a different object tied to sales organization or order type, is also failing and would block the transaction regardless.
- In derived roles, the organizational value for VSTEL is left blank or defaulted to a wildcard at the parent level and not overridden in the child, so the effective role denies everything even though the parent role screen appears to list the right values.
- People confuse VSTEL with VKORG and add sales organization values to a role expecting it to resolve a delivery access problem, which has no effect since the two fields belong to different authorization objects entirely.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-auth-objects/v-likp-vstERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.