The concept is used primarily by developers and teams within SAP. The teams (such as the Package Architecture Team and the Decoupling Team) carry out global modularization, while individual developers or groups of developers are responsible for structuring local functions (of a transaction or application area, for example).

Local namespaces (identical names in different packages) have nothing to do with the package concept. These are two separate topics.

The application component hierarchy is a method of splitting up the R/3 System from a logical or business point of view. This technical modularization can, but need not, match the logical division of the system. Assignments should be made however between these two views.

It is impossible to give a detailed yet brief answer to this question. SAP packages correspond roughly to UML packages. (The SAP use access concept is roughly equivalent to the UML "dependency relationship"). The only difference is that SAP packages do not have namespaces.

No. This is neither technically feasible nor semantically desirable, since each function group should group a set of functions that belong together logically. This indivisibility principle also applies, for example, to programs and screens. Screens must be assigned to the package containing the program with which they are associated.

No. Given the differences in goals, priorities, and resources, this would not be feasible. It is simpler to decouple parts of the R/3 System step-by-step. To ensure that users do not face problems when a developer revokes visibility for an element, you can set various parameters and attributes to prevent programs terminating.

There are two ways to do this. One option is nesting, since elements of embedded packages can never use elements of their surrounding packages. The other is a chain of one-way use accesses. In contrast to use accesses, nesting allows you to "hide" many elements.