C_AFKO_AWK — Production Order Type and Plant Authorization

C_AFKO_AWK guards access to the production order header, keyed by order type and plant. It fires whenever a program reads or writes the AFKO header structure with an activity code attached: creating an order, changing one, displaying one, releasing it, or deleting it. The structural fact that explains most confusion is that this is a header-level check, separate from the operation-level and component-level checks that happen later in the same transaction. A user can pass C_AFKO_AWK and still get stopped a few screens later by a different object guarding routing operations or reservations. Because the header check happens first, failures here surface immediately, often before any data has been entered, which is the opposite of the pattern people expect from a mid-transaction authorization failure.

The check runs during order creation and change transactions (CO01, CO02), display (CO03), and mass processing tools that touch the order header such as collective release or mass change transactions. It also fires when an order is generated indirectly: conversion of a planned order into a production order, order creation triggered from a sales order line, and order creation run by MRP or a background job. In every case the check happens at the moment the header record is instantiated with an activity, before the system evaluates operations, components, or capacity data. Reports and list transactions that only read order headers (rather than opening them for change) trigger the check with a display activity. Because background and batch-triggered order creation runs under the job's own user, a missing authorization here can silently drop orders out of an MRP run without any dialog error being visible to the planner who scheduled the job.

Reproduce the failure and immediately check SU53 as the first step, since the authorization buffer it reads only holds the most recent failed check and gets overwritten by subsequent actions. Look for C_AFKO_AWK in the SU53 output and note the AUART, WERKS, and ACTVT values shown as 'checked' versus what the user's role actually grants. If SU53 is empty or inconclusive, run the authorization trace for the user and transaction, reproduce the error again, then filter the trace for C_AFKO_AWK and read off the exact field values the system tried to check at that moment. Hand the security team the order type, the plant, the activity code, the transaction code used, and the user ID, rather than a screenshot of the generic 'no authorization' popup. If the failure happened inside a background job, pull the job's authorization trace under the job user, not the planner's own user, since those two identities frequently differ.

This is a security team fix, but functional input drives it: the consultant identifies the exact order type, plant, and activity that failed, ideally from a trace rather than a guess. A good request states the transaction, the order type and plant combination, the activity code, and whether the requirement is a one-off exception or a standing business need for that user's role.

A role that appears to list the right order type and the right plant can still fail because those values sit in separate authorization lines rather than the same one; for a multi-field object like this, all field values relevant to one action must be satisfied within a single authorization instance, not scattered across two lines or two roles that each cover half the combination. A second common trap is activity granularity: a role granted display and change is not automatically granted release, since release carries its own activity code, and a user who could open and edit an order for weeks may suddenly fail only at the release step. A third is composite roles built from single roles maintained by different teams, where each single role is individually correct but the combination never produces one authorization instance covering both the new plant and the new order type together. When this check fails, the wrong conclusion is usually 'the order type is not configured' or 'the plant is not open'; both are configuration explanations for what is actually a missing authorization value, and chasing them wastes time that tracing would have saved.