CRHD table — Work Center and Resource Header Table

One row in CRHD represents a single capacity-relevant object: a production work center, a PP-PI resource, a PM or QM work center, or another object type maintained through the CRxx object framework. The row does not carry the object's description or its capacity data directly; it holds the identifying and administrative attributes only - plant, usage indicator, responsible person, and the internal object key that every other capacity-planning table uses to reference this object. The visible, human-typed work center code (what a planner types into CR03) lives here too, but it is not the key other tables use to link back. CRHD is shared across PP, PM, QM and PP-PI, which is why the object type field matters: the same table structure serves work centers created in different applications, and a query without an object type filter can quietly mix them.

CRHD is a small master table in most systems, a few thousand rows even in large landscapes, so full scans are rarely a performance problem on their own. Always restrict on MANDT and, wherever possible, on WERKS plus OBJTY - filtering by ARBPL alone across plants returns unrelated objects that happen to share a code in a different plant. Because OBJID is an internal, non-meaningful key, it cannot be typed in from memory; it has to be looked up starting from the readable ARBPL/WERKS pair or pulled from a referencing table like AFVC or PLPO. Treat OBJID as the join key and ARBPL/WERKS as the search key - conflating the two produces wrong joins that still return rows, just the wrong ones.

Symptom: an order operation appears to be scheduled or capacity-loaded against the wrong work center. Pull the operation from AFVC and note ARBID. Select CRHD where OBJTY equals the work center object type and OBJID equals that ARBID, restricted to the expected plant. If the row's ARBPL does not match what the planner expects, the operation is pointing at a different object than assumed - check whether the routing was changed after order creation, since orders keep the ARBID that was valid at the time of order creation or last operation update, not necessarily today's routing work center.

CRHD is unchanged in structure moving into S/4HANA; work centers are not one of the objects redesigned as part of the simplification list. Newer work center maintenance apps in Fiori are typically built on CDS views layered on top of CRHD and its companion tables, but the underlying persistence and the OBJID-based join pattern into AFVC, PLPO, and the capacity tables remain the same as in ECC.

Work center master data is owned by the production planning master data team for manufacturing work centers, and by plant maintenance or quality management master data owners for their respective work center variants. A question about why an object ID resolves to an unexpected work center is a master data question first, routed to whichever functional team owns that object type, not a routing or order team issue.

CRTX carries the description text for the same OBJID. CRCA and KAKO carry capacity allocation and capacity header data for the object. AFVC and PLPO reference the work center from order operations and routing operations respectively through ARBID. Maintenance transactions are CR01, CR02, and CR03 for individual work centers, and CA80 for mass changes across many work centers at once.