QPPD Documentation

Structure Customizing

Subdivision of objects should be done in multi-level master data/movement data
Functionally separate parts of an object should be outsourced and linked into separate objects so that the objects do not become too large/complex
Depending on the use case, use by copying/referencing/linking/BOMs should be implemented:
- Use of master data in transaction data by copying
- Element linking: if data does not need to be inherited, either specifying the rule name of the object as the element value (to be preferred) or a LINK to the object is sufficient. A LINK initializes more data and is therefore slower than linking with the element value.
- If data is to be inherited, the use of primary references is preferred. Here the following applies: No reference to transaction data in master data.
- Linking within master data or transaction data can also be done using LINK/BOM

The SUPER class should be used for redefinitions, if there are several redefinitions of a class, e.g. VART and generation classes.
The FACTORY should always be used for instantiation, if possible by SINGLETON
Customer logic implementations should be done only through the official APIs if possible:
- Object-related customer implementations should be performed in a VART class Z-interface that inherits from the default /SCT/QP_IF_VART interface, if possible.
- Access to QPPD functionality should be done via the VART class or BUS if possible.
- Furthermore, if possible, no redefinitions of object types, MODEL, controllers, etc. should be made.
- Further possibilities are:
  - CHECK and generation classes
  - TOE plausibility classes
  - BADI
  - VART event handlers (ON methods
- Furthermore, if possible, no redefinitions of object types, MODEL, controllers, etc. should be made

The builder should be implemented via the VART class, using the methods of the VART interface.
For example, resolving master data
The BUILDER builds nodes and the generation methods generate values
=> What happens if the values of the objects are changed dynamically? Backward calculation of operations: The user changes values on the operations, so the nodes would have to be deleted/rebuilt.

Generation methods generate values, but can also be used to plausibilize values that have dependencies on other elements of the node/object.
The plausibility check of values with dependencies should be realized by TOE if possible.

Depending on the dependencies of the elements, the check can be performed on the element by TOE/object types, by the generation classes/nodes, and by check class/BUILDER at the object level
Single values are checked by TOE

Fixed processing from "top to bottom" or "bottom to top" is preferred
As few dependencies as possible should be created between the nodes so that global generation does not have to run through too often to achieve a consistent state