GETWA_NOT_ASSIGNED in EWM RF Picking: The Authorization SU53 Does Not Show

The fix itself is small. Finding it took time, because the failed check did not show up in SU53 or in the authorization trace. This article describes how we read the dump, what did not work, and how we found the cause in the debugger.

The symptom

Warehouse workers confirmed picking tasks on handheld scanners in /SCWM/RFUI. For some tasks the session ended with a short dump:

Runtime error: GETWA_NOT_ASSIGNED (field symbol not assigned)
Program: /SCWM/SAPLL03A, include /SCWM/LL03AFGP, routine STOCK_CHANGE_CONF
SM21 entry: message AB0, "Runtime error GETWA_NOT_ASSIGNED occurred"

Three things narrowed it down:

Only tasks that referenced a posting change warehouse request (document category SPC) were affected.
Only some users were affected: RF users with a limited role. The same task confirmed fine with a user who had other roles.
SAP note 3581835 ("Dump during WT confirmation") looked related, but the dump came back unchanged after it was implemented.

Reading the dump

The dump pointed to authorization from the start, but only in the system fields. STOCK_CHANGE_CONF reads the posting change document with the delivery query, then takes the first item of the result:

READ TABLE lt_items_to ASSIGNING <item_to> INDEX 1.
" no SY-SUBRC check
... <item_to>-addin-productid ...   " dump here

In every dump, the item table was empty and SY-SUBRC was 4. The system fields also held message /SCDL/AF 061 with variable "Display": "No authorization for warehouse request or delivery and activity Display".

This is how an authorization error turns into a dump:

The delivery query checks the user's authorization for the posting change document and is refused.
The framework does not raise the refusal as an exception. It writes it into a message object with MESSAGE ... INTO, which also fills SY-MSGID and SY-MSGNO.
STOCK_CHANGE_CONF only takes the item table from the query, not the message object. The refusal is lost.
The READ TABLE finds nothing, the field symbol stays unassigned, and the next statement dumps.

So the user never sees an authorization message. The only trace of the cause is the message ID in the dump's system fields.

What did not work

The usual tools gave no answer:

Adding /SCWM/DLV2. This is the warehouse request object in S/4HANA. We first added it with display (ACTVT 03) for the posting change document category, then with * in every field. The dump stayed.
SU53. No failed check for the user.
STAUTHTRACE. Run across all application servers while the user reproduced the dump. No failed check either.
Where-used lists. The where-used list for message /SCDL/AF 061 returned no hits. The message text belongs to exception class /SCDL/CX_AF_AUTHORITY (text ID AC_ACTVT_NO_AUTHORIZATION), but the where-used list for that constant only found code that reads the message afterwards, not code that raises it.

With a clean trace and full values in /SCWM/DLV2, it looked as if authorization was ruled out. It was not.

Finding it in the debugger

The debugger found the cause in one session. We reproduced the scenario in a test system with one of the affected RF users:

Set an external breakpoint for the RF user in include /SCWM/LL03AFGP, on the line that calls the delivery query in STOCK_CHANGE_CONF.
Had the user confirm a posting change task on the scanner until the debugger opened.
Added three breakpoints:
- Message: ID /SCDL/AF, number 061
- Method: /SCDL/CX_AF_AUTHORITY, method CONSTRUCTOR
- Statement: AUTHORITY-CHECK
Continued with F8 and read the call stack and variables at each stop.

The message breakpoint is the one that matters. It stops exactly where the framework decides the user is not authorized, whether or not an AUTHORITY-CHECK statement is involved. From there, the call stack and local variables showed which object was evaluated.

The cause and the fix

The refusal came from /SCWM/DLV, not /SCWM/DLV2. In this flow, the system evaluates both objects, and the user needs both.

Object	Description	Status in SU21	Needed here
`/SCWM/DLV2`	EWM Warehouse Request with Warehouse Number	Current	Yes
`/SCWM/DLV`	(Obsolete) EWM Warehouse Request	Obsolete	Yes

The check on /SCWM/DLV did not go through an AUTHORITY-CHECK statement. That is why it appeared neither in SU53 nor in the trace.

The fix was to add /SCWM/DLV with display (ACTVT 03) to the RF role, next to /SCWM/DLV2. After a new logon, the users confirmed the posting change tasks without a dump. If you open both objects with * while testing, restrict them again afterwards to the values the users need.

Takeaways

Read the system fields of a dump. An authorization message in SY-MSGID can be the real cause, even when the dump is a field symbol error.
A clean SU53 or trace does not rule out authorization. Some EWM delivery checks do not use AUTHORITY-CHECK and leave no trace there.
Obsolete does not mean unused. Keep /SCWM/DLV in EWM roles alongside /SCWM/DLV2, and check what SU24 proposes before removing it.
When the tools show nothing, debug on the message. A breakpoint on the message ID and number stops where the decision is made, whatever the coding style.

The dump itself comes from a missing SY-SUBRC check in SAP's code. A proper authorization message would have saved a lot of time, so this is worth reporting to SAP as well.

How MTC helps

Authorization design for S/4HANA and embedded EWM, including RF and warehouse roles.
SU24 maintenance, so that objects such as /SCWM/DLV are proposed where the code still checks them.
Troubleshooting authorization errors that SU53 and the trace do not show.
Role reviews before go-live, so that this kind of issue shows up in testing rather than on the warehouse floor.

On large programs we work alongside leading global audit, risk and technology consulting firms, with a senior Swiss-based team responsible for the security work.

References

3581835: Dump during WT confirmation. Looked related, did not fix this case.
/SCDL/AF 061: No authorization for warehouse request or delivery and activity &1.
/SCDL/CX_AF_AUTHORITY: exception class carrying the message, text ID AC_ACTVT_NO_AUTHORIZATION.
/SCWM/DLV2 and /SCWM/DLV: EWM warehouse request authorization objects (SU21).

Frequently asked questions

What causes GETWA_NOT_ASSIGNED in /SCWM/SAPLL03A when confirming a warehouse task?

In the case described here, a missing authorization. Routine STOCK_CHANGE_CONF in include /SCWM/LL03AFGP reads the posting change warehouse request through the delivery query and takes the first item of the result without checking SY-SUBRC. When the user is not authorized for the warehouse request, the query returns an empty item table, the field symbol stays unassigned and the next statement dumps. The authorization refusal only shows up as message /SCDL/AF 061 in the system fields of the dump.

Is the authorization object /SCWM/DLV still needed in S/4HANA EWM?

Yes, in some flows. SU21 marks /SCWM/DLV as obsolete and /SCWM/DLV2 (EWM Warehouse Request with Warehouse Number) is its successor, but confirming warehouse tasks for a posting change warehouse request (document category SPC) in embedded EWM on S/4HANA evaluated both. The RF users needed /SCWM/DLV with display (ACTVT 03) next to /SCWM/DLV2.

Why does a missing EWM authorization not appear in SU53 or STAUTHTRACE?

SU53 and the authorization trace record AUTHORITY-CHECK statements. The check on /SCWM/DLV in this flow did not go through an AUTHORITY-CHECK statement, so it left no entry in either tool, even with the trace running on all application servers while the user reproduced the dump. A clean SU53 or trace does not rule out an authorization cause in EWM delivery processing.

How do you find an authorization check that SU53 and the trace do not show?

Debug on the message. Set an external breakpoint for the affected user before the failing call, then add a breakpoint on message ID /SCDL/AF number 061, a breakpoint on the CONSTRUCTOR of exception class /SCDL/CX_AF_AUTHORITY and a breakpoint on the AUTHORITY-CHECK statement. The message breakpoint stops where the framework decides the user is not authorized, whatever the coding style, and the call stack and local variables show which object was evaluated.

Does SAP note 3581835 fix the GETWA_NOT_ASSIGNED dump during warehouse task confirmation?

Not in this case. Note 3581835 (Dump during WT confirmation) looked related, but the dump came back unchanged after it was implemented, because the cause was the missing /SCWM/DLV authorization, not the code the note corrects.