Hierarchy
FI-CA (Software Component) FI-CA⤷
FI-CA (Application Component) Contract Accounts Receivable and Payable⤷
FKKTOOLS (Package) FI-CA Tools (Application Basis)
Basic Data
| Data Element | CFC_OBJAP_INHERIT |
| Short Description | CFC: Application object from which another object inherits |
Data Type
| Category of Dictionary Type | D | Domain |
| Type of Object Referenced | No Information | |
| Domain / Name of Reference Type | CFC_OBJAP | |
| Data Type | CHAR | Character String |
| Length | 4 | |
| Decimal Places | 0 | |
| Output Length | 4 | |
| Value Table | CFC_APPLOBJ |
Further Characteristics
| Search Help: Name | ||
| Search Help: Parameters | ||
| Parameter ID | ||
| Default Component name | ||
| Change document | ||
| No Input History | ||
| Basic direction is set to LTR | ||
| No BIDI Filtering |
Field Label
| Length | Field Label | |
| Short | 10 | InhAObject |
| Medium | 15 | Inh appl.object |
| Long | 20 | Inherit appl. object |
| Heading | 6 | Inh.AO |
Documentation
Definition
This application object represents a clarification worklist process that has already been carried out using the clarification controller.
It is possible to transfer such processes (that is, application objects). The application object represents the parent object in a transfer hierarchy as it exists in relationship to another application object.
This application object transfers all functions for such events that are not defined as events in the control object of the receiving application object.
Additionally, all statuses, the note object, and the role of the parent object are transferred.
Abstract example:
Application object A2 inherits from application object A1. A2 uses control object C2, and A1 uses C1. C1 defines events Z1 and Z2. Control object C2 only defines Z2.
If the process of application object A2 reaches event Z1, which in not defined in the control object, it inherits the complete event from application object A1, that is, all event functions for Z1 are executed here.
Practical example:
You have a clarification worklist for processing a payment stack with various events, which themselves are assigned to various function modules.
You need to be expand this clarification worklist process to include a new event ENew for a branch or customer without modifying the existing elements. Additionally, the existing elements need to be used and all changes to the existing clarification worklist process should also be effective for the expanded process.
To accomplish this, a new control object with a new control process is defined. This control process is the same as the old one, although expanded to include the new event ENew. The control object is entered into the control objects table. The new control object only defines the event ENew and no other events.
A new application object is then entered in the application object table. This newly created object is defined as the control object. The parent application object (from which the new one inherited) is entered as that of the old clarification worklist process.
In this process, the new clarification process inherits all events from the old process and only new events are defined.
If other events are to be used differently, they merely have to be defined when a new clarification object is created. The redefined events no longer inherit from the old clarification process and you can assign function modules to them.
The same applies to the status of a parent object. All newly defined statuses are not transferred, but non-defined statuses are.
The role that can be defined for an application object is similar. Roles are also transferred by the parent object if they have not been redefined in the receiving object, but the active indicator for the role must be set in the receiving object. If the evaluation of a role that was defined by the parent object is to be avoided in the receiving object, the indicator should be deactivated.
The transfer of the note object is similar.
History
| Last changed by/on | SAP | 20050224 |
| SAP Release Created in |
