Skip to main content

Chapter 5: Financial Document Posting Engine

In the previous chapter, we met our expert "data scout" who efficiently retrieved a list of financial noted items from the database. The user has seen this list, selected the items they want to process, and clicked the "Post" button. Now, the most critical part of our process begins.

The Problem: From a Simple Note to a Real Accounting Entry​

Imagine a "noted item" is just a sticky note that says, "Customer ABC owes us $100." This note is a useful reminder, but it isn't part of our official company accounting books. To make it official, an accountant has to take that sticky note, create a formal journal entry with a debit and a credit, get it approved, and file it properly. This is a meticulous, rule-based process.

Our program needs to do the exact same thing, but automatically. How do we take a single line of data and safely transform it into a balanced, official, and auditable financial document inside SAP? We need an automated accountant.

The Solution: Our Automated Accountant (post_fi_document)​

Meet the Financial Document Posting Engine. In our project, this is the post_fi_document method. Think of it as a tireless, detail-oriented robot accountant. Its one and only job is to take the information from a single noted item and perform all the steps necessary to create a real accounting document.

It's the core of our application, where a simple "to-do" item becomes a permanent financial record.

Step 1: Receiving the Job Order​

The PDC Processing Orchestrator acts as the manager. When it's time to process an item, it calls our robot accountant and hands it a single "job order"—the data for the selected noted item.

* Inside the Orchestrator's PROCESS method

" Give the job order for one noted item to the posting engine
post_fi_document(
   CHANGING
     is_cust1 = <fs> " <fs> contains the data for one selected row
).

Step 2: Preparing the Document "Cover Page" (The Header)​

Every formal document needs a header. Our robot accountant starts by preparing this. It fills out the essential information like the company code, the date, and a description.

* Inside method POST_FI_DOCUMENT

" Prepare the header information
ls_doc_head-comp_code = is_cust1-bukrs.  " Company Code
ls_doc_head-pstng_date = gv_budat.     " Posting Date
ls_doc_head-doc_date = gv_budat.      " Document Date
ls_doc_head-header_txt = 'PDC Posting'. " Description
  • ls_doc_head is a structure that acts like a form for the document's header. We're filling in the blanks with the necessary data.

Step 3: Preparing the Debit and Credit Lines​

This is the heart of accounting. Every transaction has two sides. For a customer payment, it looks like this:

  • Debit: Money is received into our bank account.
  • Credit: The customer's debt to us is reduced.

Our robot accountant meticulously prepares these two entries.

The Debit Line (Bank Account):

* Inside method POST_FI_DOCUMENT

" 1. Prepare the DEBIT line for the bank
ls_acct_gl-itemno_acc = '0000000001'.      " Line item 1
ls_acct_gl-gl_account = gv_hkont.          " Our Bank G/L Account
ls_acct_gl-pstng_key = '40'.             " Posting Key for a Debit
  • ls_acct_gl is the form for a General Ledger (G/L) line item.
  • pstng_key = '40' is a special SAP code that explicitly says, "This is a debit."

The Credit Line (Customer Account):

* Inside method POST_FI_DOCUMENT

" 2. Prepare the CREDIT line for the customer
ls_acct_re-itemno_acc = '0000000002'.      " Line item 2
ls_acct_re-customer = is_cust1-kunnr.      " The Customer's ID
ls_acct_re-pstng_key = '15'.             " Posting Key for a Customer Credit
  • ls_acct_re is the form for a customer/vendor line item.
  • pstng_key = '15' is the code that says, "This is a credit to a customer account."

Step 4: Submitting the Document Securely​

Our robot accountant doesn't have the final authority to write directly into SAP's financial books. That would be too risky! Instead, SAP provides a secure, official "mailbox" for posting documents. This mailbox is a special function called a BAPI (BAPI_ACC_DOCUMENT_POST).

We package up our header, debit line, and credit line and hand them to this BAPI. The BAPI then performs final checks and, if everything is perfect, creates the official document.

* Inside method POST_FI_DOCUMENT

CALL FUNCTION 'BAPI_ACC_DOCUMENT_POST'
  EXPORTING
    documentheader = ls_doc_head " Our prepared header
  TABLES
    accountgl      = lt_acct_gl  " Our list of debit lines
    accountreceivable = lt_acct_re " Our list of credit lines
    return         = lt_return.  " A table to get feedback

Think of this as putting your carefully prepared forms into a special inter-office envelope and dropping it in the official mail slot. You trust the mailroom (the BAPI) to handle it from there.

Step 5: Getting a Confirmation Receipt​

After we submit our document, the BAPI gives us back a "receipt" in the lt_return table. This receipt tells us if the posting was a success or a failure.

  • Success: The receipt will contain a success message and, most importantly, the new official document number!
  • Failure: The receipt will contain one or more error messages explaining exactly what went wrong (e.g., "The posting date is in a closed period").

Our code checks this receipt and updates the status for the user.

* Inside method POST_FI_DOCUMENT

" Check the receipt for any errors
LOOP AT lt_return INTO ls_return WHERE type = 'E'.
  " An error was found!
  is_cust1-msg = ls_return-message. " Record the error message
  EXIT. " Stop checking
ENDLOOP.

If this loop finds an error (type = 'E'), we update the corresponding row in our ALV grid with the error message. If no errors are found, we update it with the new document number to show the user it worked!

Under the Hood: The Posting Flow​

Let's visualize the sequence of commands when our engine posts one document.

The key takeaway is that our code never touches the core financial tables directly. It uses the official, safe, and standard BAPI interface, ensuring that all of SAP's built-in business rules and validations are respected.

Conclusion​

You've just witnessed the most critical transaction in our application. The Financial Document Posting Engine is our automated accountant that transforms a simple reminder into an official financial record.

We learned that this engine:

  • Receives a single noted item as its "job order."
  • Meticulously prepares the document header, debit lines, and credit lines.
  • Uses the standard and secure BAPI_ACC_DOCUMENT_POST to perform the actual posting.
  • Receives clear feedback on success or failure and reports it back to the user.

A new document has been successfully created. But what should we do with the original "sticky note"—the noted item? We can't leave it in the system, or we might accidentally try to post it again later. It needs to be officially cleared. That brings us to our final core task.

Let's move on to the next chapter and learn about Automated Document Reversal.