The two main components of a document are: Document Header Document Line Items Posting is the act of saving a document, which results in the on-line, real time update of the accounts involved. This term is often used interchangeably with the term “Enter” when discussing this subject. To reduce errors, users can view the document that is about to be posted by using the simulate function. This function will display the document as it will be posted and allows changes to be made if data was keyed incorrectly.
Documents are entered in the system to represent business transactions. In this chapter, document entry will be illustrated using a Customer Invoice. In the Document Header, information is entered that is valid for the entire document including: Document Date: identifies the date on which the original document was created (informational data). Document Type: defines the business transaction to be entered. Company Code: identifies the company in which the business transaction is to be entered. Posting Date: determines the posting period in which the document is entered. The Document Header displayed in this slide is for entering customer invoices. Note the following: The Document Date, Posting Date, Company Code and Currency fields require an entry. (Note: A “check in a box” symbolizes a required entry). All other fields are optional. Note also that the system entered the current date in the Posting Date field by default. This entry may be changed. The Document Type field was populated as DR because this is the Default Value for customer invoices (see Chapter 10 - Document Configuration, pg. 9). After the required fields are entered, a user can select the Act Assignment Model or G/L Item Fast Entry push-button to simplify repetitive postings (these are covered in Chapter 12: Reference Documents and Chapter 16: Line Item Configuration respectively) . At the bottom of the screen, preliminary information regarding the first line item of the document is entered. Note: For Customer Invoices, the default Posting Key is 01. The user is required to enter the Customer Account Number. Once all of the header information is entered, press “Enter” to proceed to the first line item screen.
The screen layout for entering the first line item above results because, as discussed in the previous chapter, the Field Status of the Posting Key (01) and the Field Status Group of the Reconciliation Account (121000) for this customer determine which fields are required, optional, or suppressed. Entering a different business transaction will likely result in a different screen layout because the Posting Key and the Field Status Group of the Account will probably be configured differently. In the slide above, information that has defaulted into the fields comes from the Customer master record. This information can be changed and additional data can be input in the other fields. Organizational structures such as Business Area can be assigned to a Line Item. In addition, text and other identifying information may be added. The Assignment field (alphanumeric, up to 18 characters) is updated automatically with the data from the field referenced in the Sort Key field of the G/L Account, vendor or customer master records. The system uses the Assignment field to sort Line Items during G/L Account display (see Chapter 15 - Display Accounts & Documents) and system activities such as clearing. The user can manually enter a value in the Assignment field. At the bottom of the screen, preliminary information regarding the second Line Item of the document is entered. Note that nothing defaults for the Posting Key or Account because the user determines the next Line Item based on the particular entry being made.
The screen layout for the second Line Item is different from that of the first because the new Posting Key (50) and G/L Account (DK8000) have different Field Status Groups than the first Line Item. A document can have up to 999 Line Items. In this example, a basic Customer Invoice containing only two Line Items is entered: Account Number Account Name Debit Credit 6 Athlete’s $5,000 410000 Sales (Revenue) $5,000 Note: The offsetting(credit) amount is noted with a “*”. The asterisk indicates that the credit entry should receive an amount that causes the document to be in balance (i.e., debits = credits)
Utilizing the Simulate function, a user is able to see the document that will be entered. This slide depicts what the user sees. If the Post function is selected, this screen will not be seen. Instead, the user will receive a message stating the Document Number of the entered document. If the user attempts to post a document that is not in balance or contains invalid data, an error message results.
In version 4.6 SAP introduced a new way of posting called Enjoy posting. The goal of the new posting is to provide a simpler interface and quicker links to important information. All line items can be entered on just one screen and instead of determining posting keys for line items,users only need to decide whether the line item is a debit or credit entry. Note: For customer and vendor line items, the user does not even determine whether it is a debit or a credit. In the example above a Credit entry is expected since the user is entering a customer invoice. Unlike the Complex Posting, the document header information is not separated from the line items; however, the line items are in a separate area. Quick links are provided to display relevant details about the customer’s master record and account. A Tree structure is available, which allows the user to select Screen variants and other items that have been pre-defined or saved from earlier sessions.
Simulate function in the Enjoy postings works the same way as in the complex (general) postings.
There are 5 steps that the system follows when a document is posted: Data is entered and the Save / Post push-button or simulate command is selected. User-defined Substitutions are executed. Any derived characteristics are brought into the document. Derivations are values that the system automatically finds for unfilled characteristic fields (see CO-PA submodule) based on characteristic fields that are known (e.g., Profitability Segments). The Coding Block is checked for master data availability and compatibility (e.g, an account might be blocked for posting) Finally any user-defined Validations are carried out. For example, a validation may exist that limits the G/L accounts for which a data entry clerk can process a transaction. If there is a problem in any of the above steps, the system returns a warning or error message depending on how the desired system response is configured.
Posting - the act of saving a document, resulting in the on-line, real time update of the accounts involved. This term is often used interchangeably with the term “Enter” when discussing this subject. Simulate - this action is similar to posting in that the system performs the same validation and check steps, however, the document is not actually posted. System Checks for Document Posting - Data is entered and the Save / Post push-button is selected. User-defined Substitutions are executed. Derived characteristics are brought into the document. The Coding Block is checked for master data availability and compatibility. User-defined Validations are executed.
SAP FI Document Entry | http://sapdocs.info
Chapter 11. Document Entry <ul><li>The previous chapter defined the configuration needed for the entry of business transactions into the system. This chapter discusses the application side of the system where users actually enter the documents in the system. </li></ul><ul><li>Chapter Objectives </li></ul><ul><ul><li>Provide a detailed understanding of two ways how a document is entered in the system. </li></ul></ul><ul><ul><li>Enter/Post several types of documents </li></ul></ul>
The FI Document Document Header Document Date Document Type Company Code Posting Date Currency/Rate Document Number Line Item 1 Posting Key Account Amount Line Item 2 Posting Key Account Amount