Preliminary Analysis
Procedure
Before you begin infotype creation (or migration), you must perform a preliminary analysis to consider the business logic of the corresponding infotype, as well as the role that the infotype will play (or plays) in your system landscape. To this end, you must first examine the proposed (or existing) flow logic of the infotype at hand. Examining the flow logic alone, however, does not provide all the information you need for your preliminary analysis; once you have examined the (explicit) flow logic, you must also determine the implicit checks to ensure that the check class considers the flow logic and the implicit checks alike.
Note
From this point forward, unless otherwise explicitly stated, the present guidelines limit themselves to discussing the creation of new infotypes in th is release.Nonetheless, the information presented in the remainder of this document applies equally to the hypothetical migration of existing infotypes from prior releases.
Therefore, in conducting your preliminary analysis, we recommend that you consider, along with the flow logic, the following implicit checks:
-
Fields that cannot accept input, because the screen logic has disabled them
Fields that are not visible on the screen, but which reside in the P-structure
Values that can only be filled by special means, for example:
Checkboxes
Furthermore, you should attempt to determine whether other unique conditions exist in the infotype – for example, dynamic measures, the update of tables that lie outside the
PAnnnn
name range
, the import or export of special data, and so on.
In the flow logic itself, we recommend that you consider the following points.
How default values are filled
How additional infotype data is read
How table PS (if applicable) is manipulated
How other infotypes (where applicable) are accessed
Dynamic measures that manipulate infotype records without user interaction
Processing behavior that depends on global variables
Export/Import memory issues