Show TOC

 Changing the Keys for HR Master Data (PSKEY) Field During Checks

Use

Under certain circumstances, you may want your infotype to change the Keys for HR Master Data (PSKEY) field upon performing its checks. Although it is technically possible to do so, two constraints apply to this function.

Prerequisites

Under the first constraint, it is not permissible to change either the Infotype (INFTY) or the Standard Selections for HR Master Data Reporting (PERNR) fields. Under the second constraint, any changes thus performed must adhere to the revised framework that exists in this release for creating infotypes; specifically, any changes must comply with the following implicit checks, all of which are enforced in the standard system within method ASSERT_CLEAN_DATA .

  • Technical field contents must be fulfilled; for example, numeric fields may only contain numbers.

  • The subtype at hand must be permissible for the country grouping assigned to the personnel number.

  • The start date must precede the end date.

  • The entry in the Name of subtype (NAMST) field must be valid.

  • Depending upon the entry in the Maintenance permitted after leaving (NAUST) field in the Infotypes: Customer-Specific Settings table (T582A), the system may not permit the record to be maintained in inactive periods.

  • For time constraints 1, 2, and 3, it is not permitted to create records that precede the date of birth.

Procedure

Because they are implicit, all of the checks summarized above are processed before all infotype-specific checks. Therefore, if any condition established by these checks is violated, the system considers the corresponding discrepancies to arise from the business logic, rather than the user. For this reason, when any of these checks is violated, the system issues an exception, rather than an error message.

Example

Suppose your infotype features a new, specific date field of its own, with the technical name MYINFTYDATE, which is mapped to the Start Date and End Date fields (BEGDA and ENDDA, respectively). Because the latter fields do not appear on the infotype screen, and because the MYINFTYDATE field does, the only date that any user can enter is in that field. Now suppose that the user enters a date that precedes the date of birth. Because the Start Date and End Date fields are hidden, these fields will not be processed, and the error initially will not be detected, because the infotype’s business logic populates BEGDA and ENDDA with MYINFTYDATE. However, upon processing the business logic, the system would determine that the start date is too low, then issue a corresponding exception, which would result in a short dump. (The system cannot issue an error message in this case, because it can only refer to BEGDA, rather than MYINFTYDATE.)

To prevent the system from issuing the exception in this example, the business logic of your infotype should first check the MYINFTYDATE field entry in relation to the date of birth, and only then populate the Start Date field with the user entry. This approach is easily implemented by calling method COMPUTE_GBDAT . With this method in place, your infotype can easily issue an error message – for example, The specified entry precedes the date of birth.