Hierarchy

⤷

⤷

IMG Activity
ID | _CRD_VC_CRD_RQTYP | Configure Requirement Types |
Transaction Code | S_PRN_53000395 | (empty) |
Created on | 20070102 | |
Customizing Attributes | _CRD_VC_CRD_RQTYP | Configure Requirement Types |
Customizing Activity | _CRD_VC_CRD_RQTYP | Configure Requirement Types |
Document
Document Class | SIMG | Hypertext: Object Class - Class to which a document belongs. |
Document Name | _CRD_VC_CRD_RQTYP |
Use
In this activity, you can configure requirement types. This lets you determine the characteristics of a certain type of requirement.
- You define here whether the requirement type is a simple requirement or a combined requirement.
- You also define whether the requirement type requires you to store a combination algorithm for it.
- Finally you have the option of defining requirement types that deviate from those of the standard delivery.
Note that although the version management function from Incentive and Commission Management (ICM) also applies to the underlying table, table TCRD_RQTYP, the effective start and end dates cannot be changed. The system sets the dates to default values. New versions can be generated only by changing the attributes.
Since the requirement types are some of the fundamental configuration settings in the system, we recommend that you do not make any changes of this kind, especially if there are already requirements that depend on requirement types.
If none of the requirement types meets your needs, you should create a new requirement type instead of changing an existing one.
It may be advisable to create the same requirement type more than once, since the requirement type is a filter for BAdI CRD_REQ_FACTORY.
Note that if you create a filter in this way, you must then assign it to a BAdI implementation. Implementations are provided for all requirement types that are part of the standard delivery.
Requirements
By copying the client-specific Customizing, the most important requirement types should be available to you.
Standard settings
If ICM is integrated with CRD, only those requirement types can be used that can be combined, or that you defined yourself. For those that you created yourself, you must make sure that their requirements return a check result when they are checked against a partner. If you use the associated requirements in combinations, you must define the requirement type as a combinable requirement type.
Activities
If you have implemented your own requirements, assign a suitable implementation of BAdI CRD_REQ_FACTORY to the filter that is defined by the requirement type.
Example
Business Attributes
ASAP Roadmap ID | 204 | Establish Functions and Processes |
Mandatory / Optional | 2 | Optional activity |
Critical / Non-Critical | 1 | Critical |
Country-Dependency | A | Valid for all countries |
Assigned Application Components
Documentation Object Class | Documentation Object Name | Current line number | Application Component | Application Component Name |
---|---|---|---|---|
SIMG | _CRD_VC_CRD_RQTYP | 0 | PRN0000071 | Credentialing (CRD) |
Maintenance Objects
Maintenance object type | C | Customizing Object |
Assigned objects | ||||||
---|---|---|---|---|---|---|
Customizing Object | Object Type | Transaction Code | Sub-object | Do not Summarize | Skip Subset Dialog Box | Description for multiple selections |
CRD_APPL_08 | T - Individual transaction object | CRD_APPL_08 |
History
Last changed by/on | SAP | 20070515 |
SAP Release Created in | 700 |