Many documents in an SAP ERP system are uniquely identified by more than one piece of information. This is referred to as a key.
For example, a material document has a document number and a year, which is two pieces of information. A journal entry is even uniquely identified by three pieces of information: its company code, its document number, and its fiscal year.
That’s just how things go
In ABAP programming, one repeatedly sees that such information for the unique identification of a document is handled as individual fields (variables). This has several disadvantages.
- The logical belonging together is not obvious because each variable stands completely on its own.
- Passing multiple variables to identify a document bloats the signature of methods or class attributes.
- When they are variables rather than objects, they cannot be provided directly bundled with practical operations.
How it could be done better
The minimum is the use of a structure in which each field represents a part of the necessary information to identify a document. Several variables thus become a single variable behind which a structure is hidden. The belonging together becomes clear, and passing them in method signatures becomes easier.
How it could be done even better
Unfortunately, a structure still consists only of data. It lacks associated operations for a consumer to be able to do something useful with the data.
Therefore, an object is optimal because it unites data and operations. As a reminder: computer science is algorithms and data structures.
The object could contain only the key and a method that provides the corresponding document object when needed.
Alternatively, a document object can be created directly, meaning one has an object-oriented representation of the respective document. The key information of the document can, for example, be public, read-only attributes of this object. Methods provide the data of the document when called or allow other operations.