This article examines how simple variables, structure variables and table variables can be created.

Simple variables

The declaration of a variable in ABAP looks like this:

DATA dIMyVar TYPE I.

In this declaration dIMyVar is the variable name and I indicates the type of the variable which defines in this case an elementary integer.

Another method can be used to define indirectly the type of a variable by inheriting it from an existing variable:

DATA dIRefVar TYPE I.
DATA dIMyVar LIKE dIRefVar.

This code will result in elementary type I being used to type variables dIRefVar and dIMyVar.

Obviously, you are not limited to elementary data types to define your variables and you may (and should) take advantage of the integration of ABAP with the Data Dictionary to define meaningful variables business wise (more on this in our next article dealing with data typing).

To access the data storage memory of a simple variable, it is sufficient to mention the name of the variable wherever it is needed. A direct access to the corresponding memory zone will result from that specification. Example:

DATA dIMyVar TYPE I.

dIMyVar = 13.
WRITE dIMyVar.

Structure variables

Variables with a complex data type can be created as well in ABAP to allow the manipulation of data structures from a single variable name.

Structure variables are declared in the following way:

DATA:
  BEGIN OF dwDocument,
    bukrs(4) TYPE C,
    belnr(10) TYPE C,
    gjahr(4) TYPE N,
  END OF dwDocument.

We have here declared a variable named dwDocument which has a structure made up of 3 components (primary fields).

Note that each component of a structure can itself be a structure so that a deep structure is created:

DATA:
  BEGIN OF dwDocument,
    bukrs(4) TYPE C,
    belnr(10) TYPE N,
    gjahr(4) TYPE N,
    BEGIN OF dwAmount,
      wrbtr(13) TYPE P DECIMALS 2,
      dmbtr(13) TYPE P DECIMALS 2,
      dmbe2(13) TYPE P DECIMALS 2,
    END OF dwAmount,
  END OF dwDocument.

In this example, we have defined a variable dwDocument with a deep structure containing an additional component compared to the previous example which is itself a structure.

The access to structure components is made using the operator -. So an access to the the bukrs component is done with dwDocument-bukrs and an access to the wrbtr sub-component of the dwAmount component is done with dwDocument-dwAmount-wrbtr.

Table variables

Variables can be used to store internal tables. Internal tables look a lot like structures but differ from structures in that an internal table may contain multiple instances (records) of the same structure. Internal tables are conceptually similar to the more common arrays supported by many other programming languages. However they functionally differ from classic arrays in many ways as their objective is not purely short term (mass) data storage like arrays but rather to provide a database compatible short term data storage that can be easily made persistent (actually stored in the database).

As internal tables aim at representing an in-memory snapshot of database tables, their defintion, behaviour and access is closer to that of database tables than to that of arrays. For this reason it makes no sense to try to access a specific element of an internal table using the [] operator common to many languages as this is just not supported in ABAP. Instead the internal table variable must be accessed using dedicated instructions very similar (sometimes even identical!) to those used to interact with the database tables.

Let’s define a very simple table of integers first:

DATA dtTable TYPE TABLE OF I.

Compared to the declaration of a variable of type I, the definition of a table of elements of type I simply requires the addition of the keyword TABLE OF.

Initially our table has been created empty. You can verify this using the instruction IS INITIAL as follows:

IF dtTable IS INITIAL.
  WRITE 'Table is currently empty!'.
ENDIF.

Let’s create entries in our table by appending integer elements to it and let’s display its content afterwards to check that entries are well recorded as expected.

DATA dIElt TYPE I.
DATA dtTable TYPE TABLE OF I.

DO 5 TIMES.
  APPEND SY-INDEX TO dtTable.
ENDDO.

LOOP AT dtTable INTO dIElt.
  WRITE:/ 'Entry:', SY-TABIX, 'Value:', dIElt.
ENDLOOP.

This program uses two loops to, first, create 5 records in the internal table dtTable using the instruction APPEND and, second, read sequentially and display the content of the internal table.

Let’s create now a table of a complex type, i.e. a table of structured elements. For this purpose, let’s take again our definition of a document and let’s create an internal table of documents:

DATA:
  BEGIN OF dwDocument,
    bukrs(4) TYPE C,
    belnr(10) TYPE N,
    gjahr(4) TYPE N,
  END OF dwDocument.

DATA dtDocuments LIKE TABLE OF dwDocument.

With this definition the variable dtDocuments is defined as a table of elements of the type of dwDocument. If you are focused enough you may have noticed that the table variable dtDocuments has been declared using the statement LIKE TABLE OF and not TYPE TABLE OF. This is because dwDocument is not a type in itself but a variable and cannot consequently be used directly in place of a type. However its typing information can be referred to using the LIKE statement as previously seen and dwDocument can be used to store elements (one at a time) of the table dtDocuments as in the example below.

DATA:
  BEGIN OF dwDocument,
    bukrs(4) TYPE C,
    belnr(10) TYPE N,
    gjahr(4) TYPE N,
  END OF dwDocument.

DATA dtDocuments LIKE TABLE OF dwDocument.

dwDocument-bukrs = '0001'.
dwDocument-belnr = '1'.
dwDocument-gjahr = '2012'.
APPEND dwDocument TO dtDocuments.

dwDocument-bukrs = '0002'.
dwDocument-belnr = '2'.
dwDocument-gjahr = '2012'.
APPEND dwDocument TO dtDocuments.

LOOP AT dtDocuments INTO dwDocument.
  WRITE:/ 'Company code:', dwDocument-bukrs.
  WRITE:/ 'Document num:', dwDocument-belnr.
  WRITE:/ 'Fiscal year :', dwDocument-gjahr.
  WRITE:/ SY-ULINE.
ENDLOOP.

Reading sequentially internal tables is just one method to access table records. Direct access is also possible and different operations are possible on such table variables. However this goes behind the scope of this article which gives an overview of ABAP variables usage and will consequently be treated in a dedicated article.

In our next article we will see how to declare types as we have seen that types constitute the foundation of variables and are always referred to even when not explicitely declared.

However, I have recently had a hard time figuring out how currency translation works with Report Painter. As I finally found out I am sharing it here hoping it will spare some time to you.

With Report Painter the currency translation is performed using Currency Translation Keys which define some translation settings amongst which the Exchange Rate Type is the most critical.

Don’t loose your time (like I did) to try to find a way to assign those Currency Translation Keys to your report or your report columns while designing it (e.g. in KE32 or KE35 for a COPA report if you maintain a form for your report). There exists no such possibility! The currency translation settings are maintained at execution time! So run your report and proceed as follows to create references to your Currency Translation Keys:

• To translate all columns of the report, simply click the currency translation icon from the report toolbar while nothing is selected in the report. You should then see appear a popup dialog box asking you for the Currency Translation Key to use for the translation.

  

• To translate a specific column of the report, click the column header (or any cell of the column if it belongs to a form) in order to select the column and click the currency translation icon from the report toolbar. A dialog like the following one will then invite you to select a Currency Translation Key to translate the figures of the column mentioned in the Area of validity.

  

Once the currency translation settings have been defined, you should store them if you want them to be persistent. Otherwise you will have to define them each time you launch the report since they are not done as part of the report design. To do so, simply go in the Report menu and select the Save Definition menu command.

I have been searching for such a rebuild function because the derived flows we use to post automatically tax on interests earned on Money Market fixed term deposits are not correct anymore since the withholding tax conditions have changed as per law. The rebuild function delivered with SAP Treasury was a perfect fit in this particular situation but it could be useful as well in many other situations. In fact it should be used each time an SAP Treasury environment setting (understand a setting that is not directly part of the treasury deal) affecting the deal cash flows is changed (it can be a customizing setting, a market data value, …).

The functionality is offered by transaction TMFM (program RFTMFIMA) which can be found in the application menu Transaction Manager / Money Market / Tools.

Once you have run this transaction, all the relevant cash flows will be reconstructed and corrected in the deal cash flow view and in the TBB1 posting transaction among other things.

It usually makes most sense to base Treasury payments on payment requests and to clearly separate those payments from the customers and vendors payments. This is because Treasury payments are so specific with regard to their nature, the type of partners involved, the amounts exchanged, the operators processing them, …

Obviously the retained approach will impact the posting rules set-up and the payment related information that is required to be maintained at transaction and Business Partners levels to process payments properly.

It must be noted that house bank and house bank account identifiers must be provided if you want to perform a payment or if your posting rules definitions rely on bank account information (i.e. your account symbols use masks to derive G/L bank clearing accounts from actual G/L bank accounts). This latest situation is most likely to happen if you opt for the posting approach based on payment requests.

If for whatever reason you choose not to maintain the house bank account information, you should note that the reporting in Cash Management will be affected in the following way: the corresponding cash flows will be reported as cash forecast (instead of cash position) associated to a specific planning level (specified in customizing as the planning level to use for such treasury transactions when the bank information is unknown) and to the planning group of the customer that is linked to the Business Partner with whom the deal has been done.

No matter the approach retained, a dedicated payment method is usually required. The format to be associated to the payment method is to be confirmed with the house banks. It could very well be S.W.I.F.T. MT101 which is supported in standard SAP since release 4.5A.

Depending on the approach you choose, you have to fill in the single payment method field (valid for approach based on F110) or the multi payment methods field (valid for approach based on F111) in the treasury transaction and in the Business Partner master data.

In customizing, the posting rules are associated to so-called update types. This specification of the posting rules can be specialized for each of the two possible approaches. For this purpose a payment flag is found in the customizing screen used to allocated posting rules to update types. When this flag is set it means that the specified posting rule applies to the classic payment program approach.

In such situation, you must first activate the business extension Financial Services (EA-FS) using the Switch Framework. Basically this operation will activate some code and interface elements that are already present in the system but not executed so far due to the switch being turned off.

This operation can be carried out using transaction SFW5. However some prerequisites are required. You should review at least following OSS notes before proceeding:

• Note 532670 – Activating the R/3 Enterprise Extension EA-FS
• Note 535003 – SAP R/3 Enterprise Extension Set 1.10: Activation switch
• Note 588364 – Prerequisites for activating extensions
• Note 538887 – SAP R/3 Enterprise 47×110: Software architecture/maintenance
• Note 598937 – Termination w/ error for inactive indicator EA-FINSERV

Note 588364 is particularly important since it specifies that the client role should be set as ‘Test’ instead of ‘Production’ (transaction SCC4) while activating the extension.

Note that this activation is cross-clients and it does not require the execution of SGEN afterwards.

Before starting the implementation of SAP Treasury, it may be wise as well to check the support package and/or enhancement package the ERP is running on and identify the need for more recent packages. SAP Treasury functionalities are regularly enhanced as enhancement packs are delivered. However there is not always a need to install the latest enhancement packs as ECC6 without any enhancement packs already offers a lot of functionalities treasury wise. It must be noted that while activating Financial Services (EA-FS) is a low cost operation (with a very low risk of impact on the existing ERP implementation), installing enhancement packs may turn out to be a much more costly operation involving non-regression testing.

From my own experience, it is not a good idea to bind the implementation of SAP Treasury to the implementation of enhancement packs and to try to deliver both activities within one single project. If a specific level of enhancement packs is absolutely required, their installation should be considered as a prerequisite project in itself. A SAP Treasury implementation project is already complex enough by itself not to add additional technical and planning constraints.

Initial Treasury customizing

You might encounter the situation where no initial standard SAP Treasury customizing is available in your customizing client. It doesn’t mean you have to start it from scratch because such customizing is in fact delivered by SAP but in the reference client 000. So before starting to implement SAP Treasury, you might want to “copy” this reference customizing from the client 000 into your customizing client. The safest way to proceed is to go into each of the relevant customizing activities for your implementation and to perform a customizing adjustment (this functionality can be found in the Utilities menu of any customizing transaction).

Once the reference customizing is present in your customizing client, you have a sound foundation to start elaborating your own implementation modifying the required settings to match your specific requirements.

Business Partners can either be created manually from scratch (using transaction BP for example) or from customers and / or vendors master data (using transactions FLBPD1 – Create Business Partner from Customer and FLBPC1 – Create Business Partner from Vendor). In this latter case, a logical link will be established between the Business Partner and the corresponding customer or vendor master data. Note that in case this link would not be created initially (because the Business Partner is initially created manually from scratch or because the Business Partner is created before the corresponding customer or vendors master data), it can still be created at a later stage using transactions FLBPD2 – Link Business Partner to Customer and FLBPC2 – Link Business Partner to Vendor.

Business Partners are role-based. SAP Treasury relies on Business Partner role TR0151 (Counterparty) to define general settings of the partners as well as so-called standing instructions.

From a Treasury perspective, key general information includes the partner identification data, its address and its bank account information.

Standing instructions are key company code dependent settings affecting how partner’s payments and correspondence should take place and defining what Treasury transactions are allowed with the partner and what derived flows should be applied (typically used to compute and post tax amounts on interests earned).

So today let’s try to answer this simple question: What is SAP?

SAP is both a company and a products suite. And most people refer to both the company and its main product (the ERP solution) using the SAP acronym.

SAP as a company

SAP is an international company with its headquarters in Germany (in Walldorf) which develops business software that supports most of the operational processes of its customers (mainly large and midsize companies).

It has been funded in 1972 by former IBM engineers and has now around 50.000 employees.

It is today considered as the world’s largest business software company.

SAP as a product

SAP’s flagship product is the ERP (Enterprise Resource Planning) solution. An ERP is a business software that addresses most of the operational processes of a company covering enterprise functions like Finance, Purchasing, Ordering and Billing, Human Capital management, Project management, Analytics, … through the implementation of software modules. Main SAP ERP modules include:

• SAP FI (Finance)
• SAP CO (Controlling)
• SAP MM (Materials Management)
• SAP SD (Sales and Distribution)
• SAP HR (Human Resources)
• SAP PS (Project System)
• SAP PP (Production Planning)
• SAP CS (Customer Service)

and most of those modules contain sub-modules in order to address specific areas of the functional domains. For example, in SAP FI you will find sub-modules covering General Ledger, Accounts Receivables (i.e. customer accounting), Accounts Payables (i.e. vendor accounting), Asset Accounting, Banking, Treasury, …

Next to ERP, SAP is also offering:

• SAP BW (Business Warehouse) to cover Business Intelligence needs together with SAP Business Objects
• CRM (Customer Relationship Management)
• SRM (Supplier Relationship Management)
• PLM (Product Lifecycle Management>
• SCM (Supply Chain Management)

Most of these products run on a common technical platform currently known as Netweaver which provides common technologies and interfacing techniques to the functional modules ensuring a certain degree of uniformity of those modules.

In the document header, different line item independent fields are defined among which a document status field. This field is used to indicate documents which have a special status with regard to the way they impact (or not) the account balances.

Following FI document statuses exist in ECC6:

•  (SPACE) – Normal document

An empty document status value indicates that the document is a normal document affecting account balances as indicated by the document line items.

• A – Clearing Document

 The FI document status value A is associated to clearing documents. Clearing documents are special documents since they serve the purpose of clearing (other documents) open items by creating a link between those items. They don’t primarily serve the purpose of updating account balances but they affect the status of account items.

• B – Reset clearing document

FI documents with status B are reset clearing documents. Reset clearing documents are FI documents that are used to reset (reverse) clearing documents. Regarding their impact on accounts balances, they have the same behaviour as the clearing documents they reverse.

• D – Recurring entry document

A recurring entry document has the status D. Recurring document entries do not affect account balances as recurring documents  are only templates for the creation of normal documents. Documents created based on recurring document entries have the status of normal documents.

• L - Posting Not in Leading Ledger

Used by the new G/L Accounting framework to indicate documents whose bookings are not made to the leading ledger. As such the leading ledger balances are not affected by those documents.

• M - Sample document

Documents with status M represent sample documents and are similar to recurring document entries (status D) because they represent also templates which do not affect account balances. Account balances are only affected by normal documents that are created based on the sample document.

• S Noted items

A document with status S comprises only noted items which do not affect account balances. Noted items are associated to special G/L indicators and are used to provide information without affecting actual financial figures.

• V Parked document

FI document status V refers to FI documents that are in preparation. Such documents do not affect accounts balances because they are not necessarily complete so they represent drafts of future normal documents.

• W Parked document with change of document ID

Status W is assigned to follow-on documents of parked documents. Such follow-on documents are parked documents themselves and behave like classic parked documents (status V).

• Z Parked document which was deleted

 Document status Z identifies deleted parked documents. Obviously these documents do not affect financial accounts balances.

Finally, note that the document status field is only visible in the document header when its value is not blank (so when the document is not a normal document):

Document status field

SAP techies often start searching for line items in the SAP database on the clearing document number field. This is a workable solution but not suitable for end users. End users should use the payment usage functionality which is directly available in the display document transaction (FB03 or other document display transaction) of clearing documents.

SAP Payment Usage menu

This function triggers the display of a list of the line items cleared by the current clearing document.

Enjoy!

Home › Forums

Next enhancements ahead: improvements in the troubleshooting section… Stay tuned.

ABAP runs on the SAP application server which lies between the presentation server (responsible for managing the data input from and the data output to the end user) and the database server (responsible for managing the data input from and the data output to the database).

ABAP is not a system or generic purpose programming language like C, C++ or Java. It was clearly designed to be a business oriented development language (nearer to COBOL language) which means practically that it provides natively advanced instructions and functionalities that facilitate the development of business applications (e.g. built in memory management, database interface, …). It also means the language does not offer the same level of flexibility that a more generic language usually offers (pointers, advanced memory management, types casting, …).

The limitations of ABAP being understood in the context of its objectives, the language (together with its accompanying development environment) proves to be a robust and stable tool to develop business applications.

Lately, the original language has been extended to support object oriented programming. Not all features of object oriented programming are supported by the object oriented version of ABAP but the set of functionalities proposed by the language is usually sufficient to cover most business oriented developments.

Using RANGES instead of SELECT-OPTIONS NO-EXTENSION will have no effect on the selection-screen.

The flexibility of the input offered by SELECT-OPTIONS NO-EXTENSION lies between the one offered by PARAMTERS which allows only the input of a single value and the one offered by SELECT-OPTIONS (without the addition NO-EXTENSION) which allows for the input of tables of RANGES.

I start with a very classic one yet very efficient one in order to kill your SAP system: transporting the number ranges. These are maintained generally with SNUM or more specific transactions like FBN1 for accounting document. Although it may be tempting to store these in a transport (you save time since you don’t need to reproduce their creation in the target systems), never do that! Even at creation time since you are never sure that a transport will not be re-imported in case something goes wrong.

However, if you are not happy anymore with your current employer and want a quick way to get out for new challenges, this is a method to be considered seriously!

This function module accepts as import parameters the value (a variable in fact) to be rounded, the number of decimals to take into account for the rounding and a sign mentioning whether a round up (sign = ‘+’), a round down (sign = ‘-’) or a commercial rounding (= to nearest figure) (sign = ‘X’) is to be performed.

It provides the rounded value as output parameter.

As simple as that!