A common development task found in every SAP core implementation project is the posting of accounting documents programmatically. Although the most popular technique to accomplish this task is batch input, sometimes it is better to use BAPIs. For example, suppose you need to implement a transactional model creating documents or even a chain of different documents in one database Logical Unit of Work (LUW) with an all-or-nothing paradigm. In that case, you cannot use batch input because once the document is created, it cannot be easily rolled back. With accounting documents, BAPI function modules are somewhat tricky. The existing documentation is very sparse and the data structure of BAPI parameters looks slightly different from what you can expect compared to well-known accounting document tables. Using BAPI function modules can be difficult if you have to create more complicated documents, such as those with tax calculations or Accounts Receivable/Accounts Payable (AR/AP) items having special general ledger (GL) indicators. I will walk through the accounting BAPI to enable ABAP developers to better understand this Financial Accounting (FI) functionality. I illustrate simple examples of the accounting BAPI and also discuss a tricky topic — dealing with taxes.

The Task and the Techniques

Accounting documents in general represent a history of money movements. Almost every event in corporate life that involves money should be represented with one or more accounting documents. If you have a well-implemented SAP ERP system, then as a rule most accounting documents are automatically generated. For example, when a company buys something, a responsible user creates a purchase order (PO), approves it, sends the PO to the vendor, and receives the purchased goods. Each step of the process can generate accounting documents (e.g., advance and final payments to the vendor, receiving a good in the form of its value amount). However, sometimes accountants need to post accounting documents manually (e.g., year-end financial adjustments). In some situations, accounting documents should be generated programmatically. For example, a company has a legacy third-party payroll system and all other operations — logistics and financial accounting — are done in the SAP system. In this case, you need to employ an interface — it can be a sophisticated middleware, such as SAP NetWeaver Process Integration (SAP NetWeaver PI) or an ABAP report — that gathers payroll data from the legacy system and posts the corresponding accounting documents into the SAP system. This was the case in one of my recent projects. Data from the third-party payroll system had to be loaded into a SAP system on a regular basis. The data files have a sophisticated structure. In addition, the company had a requirement that the interface had to have a “test run” mode — check and report all errors and warnings without posting.

Using BAPIs in Accounting

First, decide what BAPI function module you should use, because the SAP system contains many BAPI functions and they all share almost the same parameter passing technique. You can find them in the SAP Workbench Information system using the mask BAPI*ACC*POST. For my example, I chose the BAPI_ACC_DOCUMENT_POST function module. Its functionality more or less corresponds to the standard FI transaction FB01 (post document), which is often used for manual posting of FI documents. One of the complexities of generating business documents by means of a BAPI is that you have to derive many more parameters from the system than you have to when employing batch input. Often the user who is responsible for functional task specification tells you that there is no problem with configuration parameters, and that your first move should be to add some global constants with tax rates and account numbers and then to forget it. Don’t do it. Although such a solution actually works for years, business or tax legislation eventually changes and so must the FI customizing parameters. Always remember that each constant in your program code is your personal responsibility, even if it is an account number you’ve been given by an expert FI consultant. The better solution is to try to derive as many parameters as possible from customizing programmatically. The challenge here is to find a way to do so.

A Simple Example

In an elementary accounting document with only two line items, the first item is a credit item and the second one is a debit item. When performing such a posting manually in the SAP system, you have to enter the company code and document currency for a whole document. Then for each line item, you need to enter the posting key (which defines the account type and debit/credit indicator), the account number (or customer/vendor number), and the amount. The corresponding demo report showing the process of generating the simplest accounting document is ZDEMO_ACC_BAPI, which you can find at the bottom of this article. For the same operation when using a BAPI, you have to fill in at least three parameters of the function module: header (import parameter DOCUMENTHEADER of structure BAPIACHE09), account information for each item (table parameter ACCOUNTGL of structure BAPIACGL09), and currency amount information for each item (table parameter CURRENCYAMOUNT of structure BAPIACCR09). Now I’ll walk through an example of posting a simple accounting document. First, fill in the appropriate header information, such as company code, posting date, and document type. Most of the data should be supplied as external parameters of the program (e.g., report, function module, or class method). Be very careful when declaring data with literals or constants. Values such as company code, account number, or currency should never be declared as constants in the report. As business changes, those values are also subject to change. I recommend that you fill the BUS_ACT field of the header structure with the RFBU value, which corresponds to the manual posting of accounting documents. This value should fit most situations. If the RFBU value is not sufficient for your particular task, then the responsible FI person should inform you of other possible values. Also, unless explicitly instructed, you should leave the header fields OBJ_TYPE, OBJ_KEY, and OBJ_SYS empty. By default the system fills the corresponding FI document fields with BKPFF, the full document reference (document number + fiscal year + company code), and the logical system name. The code for the minimum of obligatory header parameters. This code is the beginning of the parameter preparation section before the BAPI call. However, it is not guaranteed that in your particular system, this set would be complete. If it is not, the system likely responds with an error message. You can see in the code that the DOC_TYPE field is filled with a constant value SA, which is one of the SAP standard document types for manual postings. In the real program, the document type should be a parameter and should be discussed with the person (consultant or user) responsible for the task functional specification. Next, fill the table parameters for two line items. For each line item, you have to fill at least two kinds of table parameters: main accounting data (LT_GLITEM) and currency amount data (LT_CURRENCY). Assigning the same number to both parameters — account data item and amount data item — you create a one-to-one correspondence between them. Finally, call the BAPI_ACC_DOCUMENT_POST function module. In a real program, you have to analyze the returning parameter RETURN. If it does not contain errors you must execute a COMMIT WORK statement to save the document in the underlying database. The sample report ZDEMO_ACC_BAPI can generate simple accounting documents. In this report, some of the input parameters are declared as selection screen parameters. Also I added simple error analysis and document display functionality. I used this demo report in an IDES system (SAP ECC 6.0) with Company Code 1000, currency EUR, debit account 120000, credit account 113100, and amount of 100 EUR. Figure 1 shows you the resulting document displayed in transaction FB03. Note that the system automatically determined posting keys 40 for debit and 50 for credit (column PK) for each line item.

Accounting Document with AR/AP Items

Now I will make the task slightly more complex: Suppose you have to generate a payment to the vendor or a payment from the customer. Traditionally, in accounting, customers are referred to as AR and vendors as AP. You can see the complete working example of posting accounting document with AR/AP line item in report ZDEMO_ACC_BAPI_ARAP. Each posting to the AR or AP account is also collected on a reconciliation account. The number of reconciliation accounts is an attribute of the customer or vendor master record. As different companies (company codes in accounting) can share the same business partners, each customer or vendor can have different reconciliation account numbers in different company codes. When creating an accounting document for AR or AP manually, the user enters the appropriate posting key and a customer or vendor number as a general account number (Figure 2).   The posting key makes the system interpret T-S66F05 as a customer number. From the posting key, the system determines the account type (vendor or customer), and then the corresponding reconciliation account (Figure 3). When generating an accounting document with an AR/AP line item, you explicitly place the vendor and customer numbers into the corresponding fields of the ACCOUNTRECEIVABLE or ACCOUNTPAYABLE table parameters. As a rule, customer and vendor numbers are parameters — you do not need to decide programmatically which is what. You can employ almost the same code fragment as that you used to generate the simplest FI document. The difference is that you have to fill another table parameter ACCOUNTRECEIVABLE. Figure 4 shows the code for filling the first line item.   So far the code is the same. In the next step, you enter the customer number in the ACCOUNTRECEIVABLE parameter. You then enter additional parameters in the function call in the TABLES section. In Figure 5 you can see the resulting document. Note that the system automatically determined posting key 11 for the customer line item.    

Working with the Special GL Indicator

Due to specific legislation or corporate reporting requirements, you have to report some financial operations (such as down payments or payment guaranties) separately. Such operations must be collected on a special kind of GL account. For this purpose, in the SAP system an accountant supplies an additional attribute to the document line item — the special GL indicator. This one-character indicator makes the SAP system substitute the corresponding reconciliation account with another account number depending on customizing, which allows you to report such line items separately. The system does this automatically for users when they enter documents online in dialog transactions. Both line item parameters for AR and AP (ACCOUNTRECEIVABLE and ACCOUNTPAYABLE) have a placeholder for the special GL indicator — the one-character field SP_GL_IND. In the demo report ZDEMO_ACC_BAPI_ARAP you can see a selection screen parameter for the special GL indicator and assignment of the corresponding parameter field. For my example, I used the special GL indicator E (Figure 7).   In my example, the system determined posting key 19 for AR line item. If you drill down to the AR line item details, you can see that the system also changed the reconciliation account for the line item (Figure 8).  

Accounting Document with Tax Items

Generating accounting documents with tax line items is more challenging. You have more parameters to derive from customizing, more alternatives to analyze, and more code to write. Still, it can be accomplished. See the complete working example in the ZDEMO_ACC_BAPI_ARAP_TAX demo report.

Value-Added Tax (VAT) and Similar Taxes

In many countries, each operation of purchase or sale is subject to tax collecting. For example, in most European countries such a tax is called the VAT. When you purchase something in a country in which VAT is applicable, you can see the tax amount in the bill. When posting an accounting document that is subject to tax collecting in the SAP system, you should have at least three line items. For example, when you have a customer payment of €100 with a VAT rate of 17%, the accounting document should contain the following items:

• Debit company bank account (€100)
• Credit customer account (€83)
• Credit tax account (€17)

When using a BAPI, you have to explicitly enter all three items yourself. As suggested earlier, try to derive as many parameters as possible avoiding any global constants. In the case of VAT or other similar taxes, you have to know the following parameters:

• Tax code
• Company code
• Currency
• Amount

Two standard SAP function modules (CALCULATE_TAX_FROM_NET_AMOUNT and CALCULATE_TAX_FROM_GROSSAMOUNT) should do the rest. The first module calculates tax from the amount that does not include tax, and the second one calculates tax from the amount that already includes tax. In addition to the appropriate calculations (tax rate and amount), these modules also return information sufficient for filling tax line items in the accounting document. The data is returned by the table parameter T_MWDAT. Figure 9 shows the code snippet for the function call that you use before preparing tax line items. See the example in the ZDEMO_ACC_BAPI_ARAP_TAX demo report.   In next code fragment, you enter the customer line item and appropriate tax item. For each tax item, you also have to enter one currency amount item. Note that tax items and account items must be numbered continuously. You also need to fill the tax code field (LS_ARITEM-TAX_CODE) in the customer line item (Figure 10).  

Down Payment Processing

Unfortunately, implementing tax with a BAPI is not always that easy. In some accounting operations (e.g., down payments), the calculated tax amount must not be deducted from the gross amount. In transaction FB03, another line item with the tax clearing account is added automatically to the document instead, such as in the down payment in Figure 11.   The overall scheme of this down payment looks as follows: 1          Debit company bank account (30,000.00) 2          Credit customer account with the special GL indicator A (30,000.00) 3          Credit output tax account (1,962.62) 4          Debit tax clearing account (1,962.62) The problem is how to decide programmatically if the document you are generating is a down payment or not. I’ll show you how you can do this in a program. Assume that you have to process a customer payment. You know the special GL indicator and the tax code. To do this you have to analyze the properties of three connected objects: the special GL indicator, the tax code, and the underlying reconciliation account. In your program you can simulate this by using system function modules that are not documented, but widely used in standard SAP programs that implement accounting transactions. You could also convert all these calls into a sequence of SQL SELECT statements from different customizing tables, but I prefer function modules where possible because they improve source code readability, at least in demo programs. This example involves processing a customer payment. First, you obtain the alternative reconciliation account. It is convenient to read customer data with function module RE_FI_CUSTOMER_DATA because it returns both the general view and the company code view. The return parameter must be of structure VF_DEBI (Figure 12).   Now you have the customer’s standard reconciliation account in the LS_DEBI-AKONT field. By using this account and the special GL indicator, you can obtain an alternative account number with function module FI_SPECIAL_GL_TRANSACT_DATA (Figure 13). Together with alternative account in variable L_ALT_ACCOUNT obtain a special modification key L_MOD_KEY that you use later.   Then obtain the alternative accounts’ properties with function module FI_GL_ACCOUNT_DATA. The return parameter LS_ACC_DATA must be of structure type XSAKO (Figure 14).   Finally, you need to obtain another property of the special GL indicator from table T074U. You need field UMSKS, which is known as the special GL transaction type. Because no convenient function module is available for this task, you use the SQL SELECT option (Figure 15).   Now that you have all the flags and interdependent properties, you can finally tell if you need a tax clearing item in your document. If the tax category of the reconciliation account (field LS_ACC_DATA-MWSKZ) is –B or +B and the special GL transaction type is A, then the operation is qualified as a down payment and the tax amount is not deducted from the gross amount. In this case, you have to generate another line item for your document (Figure 16).   Next you need to determine all the data for creating the tax clearing account by using the standard account determination procedure. First you need the tax code type (Figure 17).   After this, you can calculate a transaction key for the item, which depends on the previously found tax code type (Figure 18). You use constants here because no customizing connection is available between the tax type and the transaction key.   Now you employ the standard account determination procedure by means of function module FI_STANDARD_ACCOUNT_DETERMINE. It encapsulates several interdependent SQL selects from various T030* customizing tables. Here I used previously defined modification key in variable L_MOD_KEY  and transaction key (L_TRANS_KEY) as parameters (Figure 19).   Export parameters E_KONTH and E_KONTS of this function module give you the account numbers for the credit and debit sides, respectively. If you need to generate a debit line item, use E_KONTS. Otherwise, use E_KONTH. Now that you have all the required data, you can create a tax clearing item. Note that you must fill the ACCT_KEY field in the tax clearing item with the previously found transaction key. If you leave this field empty, then the document is generated but the data in the database will be inconsistent (Figure 20).   In this particular case, you are generating a debit tax clearing item, so use LS_TAX_CLEARING_DEBIT. The demo program ZDEMO_ACC_BAPI_ARAP_TAX demonstrates all the discussed functionality. The program should correctly generate different FI documents (payments or down payments) with or without tax or the Special GL indicator.

The CHECK Function Module

Function module BAPI_ACC_DOCUMENT_POST has a counterpart BAPI_ACC_DOCUMENT_CHECK, which has almost the same interface excluding exporting parameters (see its definition in the system). As proposed, the function module BAPI_ACC_DOCUMENT_CHECK only executes the necessary checks for import parameters against the actual customizing parameters and can return error messages in standard BAPI RETURN parameter. It does not actually save the document in the database. In the case of errors, the function module BAPI_ACC_DOCUMENT_POST does not post a document either. The difference is that the latter can increment the number range for the document type you were trying to generate. Sometimes accountants prefer not to work with number range gaps.