BAPI_HIERA_ADDSUBCLASS — Assign a Subclass in a Class Hierarchy
Creates a direct superclass/subclass assignment in SAP Classification hierarchy management. SAP lists it as a released class-hierarchy BAPI. The class types and hierarchy rules must permit the relationship, and the caller must process validation messages before committing the new hierarchy assignment.
SAP Classification BAPI reference for BAPI_HIERA_ADDSUBCLASS, covering the released business purpose, technical identity, transaction behavior, RETURN handling, S/4HANA/ABAP Cloud implications, and common classification mistakes.
Published 20 Sept 2026· 604 words
What it does
Creates a direct superclass/subclass assignment in SAP Classification hierarchy management. SAP lists it as a released class-hierarchy BAPI. The class types and hierarchy rules must permit the relationship, and the caller must process validation messages before committing the new hierarchy assignment. SAP's Classification documentation lists this interface in the released BAPI catalog for the corresponding class, object-classification, characteristic, or hierarchy business function. Use it instead of direct updates to classification master and assignment tables.
Important parameters
Classification BAPIs are sensitive to exact technical identity. The active SE37 interface is authoritative for field names, but the recurring business inputs are class name/type, object table and object key, characteristic name/value, key date/change number, language, status, and typed value tables for character, numeric/date/time, or currency values.
- Pass object keys in the format required by the specific BAPI; SAP explicitly documents internal-format requirements for several ObjectClassification calls.
- Keep class name and class type together; the class type is part of the semantic identity.
- When values are typed into separate CHAR, NUM and CURR tables, place each characteristic in the correct table rather than coercing everything to text.
- Use key date/change number deliberately for date-dependent classification content.
Commit behaviour
BAPI_HIERA_ADDSUBCLASS changes classification master data or assignments. SAP's classification documentation explicitly notes for write BAPIs such as ObjectClassification.Create/Delete that the database change is persisted with BAPI_TRANSACTION_COMMIT. Treat the entire call as one BAPI LUW: block commit on E/A messages and use rollback handling on failure.
Return handling
SAP Classification documentation consistently states that a successful BAPI should not return messages of type E. Process the complete RETURN table, not only SY-SUBRC. For writes, also verify the intended class, assignment, characteristic, or hierarchy relationship after commit. For reads, treat empty result tables as meaningful only after confirming object key, class type, key date, language, and authorization.
- Treat E and A as blockers.
- Retain message ID/number/variables for support reproducibility.
- For multi-value characteristic processing, correlate messages with the characteristic/value that caused them.
- Do not infer configuration values from the absence of RETURN errors alone; inspect the actual exported data.
ECC vs S/4HANA
SAP still publishes these Classification BAPIs in current support documentation, and SAP's ABAP Cloud migration guidance even demonstrates wrapping BAPI_OBJCL_CREATE behind a released wrapper when classic BAPI business logic must be reused. That does not make the BAPI itself directly released for ABAP Cloud; new clean-core code should use released wrappers/APIs where required.
Common pitfalls
- Passing a material or other object key in external display format when the BAPI expects its internal format.
- Mixing class types or assuming a class name is globally unique without its class type.
- Placing numeric/date/currency characteristic values into the wrong typed value table.
- Creating a duplicate assignment instead of checking existence or current classes first.
- Changing/deleting shared characteristics or hierarchy relationships without checking where-used impact.
Whose problem this is
Master-data/classification ownership normally sits with the functional data-governance team responsible for the object being classified. MDG/data migration teams own governance and mapping at scale. ABAP/integration developers own key construction, typed value mapping, RETURN handling, transaction control, and safe reuse in clean-core architectures.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-bapis/bapi-hiera-addsubclassERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.