If several specification types are dependent on each other, build on each other, or refer to each other, they must also be able to interact or access each other.

Prerequisites:

• Requirements for the implementation of specification types (P)

• Initial creation of a class for specification types (P)

Updating a dependent specification object

Several specification types belong to a defined process in the system and build on each other step by step.

An example of this is the rule types MATERIAL, PRODUCTION, and PRODUCTION_VERSION in the metal template.

It can now happen that a change to the MATERIAL, for example, requires the corresponding PRODUCTION objects to be updated. 

For this purpose, an UPDATE method should be defined in the customer superclass (example /sct/zqp_if_vart).

Specific specification type classes can then redefine these with update logic.

The method then only needs to be called at the desired points for the relevant objects.

Importing key elements for dependent specification objects

Specification objects usually map their dependencies via assignments of identifiers.

It makes sense to combine the different idents within a process chain (i.e. across several specification types) in one structure.

Implement process construct

• Define superclass

• Implement update method

• Implement read methods for dependencies