SAP FI Document Configuration | http://sapdocs.info
•
24 gefällt mir•14,303 views
DOWNLOAD THIS PRESENTATION AND OTHER 29 SLIDES FROM http://hotfile.com/dl/21484810/fc876b9/SAP-FI-Training-Presentations.rar.html Want to get more SAP Downloads ? Visit http://sapdocs.info
![Chapter 10 Document Configuration ,[object Object],[object Object],[object Object],[object Object]](https://image.slidesharecdn.com/104-6fidocumentconfiguration-091222065802-phpapp01/85/SAP-FI-Document-Configuration-http-sapdocs-info-1-320.jpg)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Mehr von sapdocs. info
Mehr von sapdocs. info (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (14)
SAP FI Document Configuration | http://sapdocs.info
- 2. The Document Principle Document - FI Number: 9999999999 Line items: DR. ABC Sandwiches $60 CR. Sales Revenue $60 One financial transaction generates one FI document with a unique Document Number. Invoice - SD Number: 999 To: ABC Sandwiches From: Fruits & Vegetables Ltd. 1 box of tomatoes $60 Total $60
- 3. Structure of a Document Debits = Credits Document Header Document Number Document Type Posting Date Company Code Document Date Currency Line Item 1 Posting Key Account Amount Line Item 2 Posting Key Account Amount
- 5. Special Document Types Document Type Net Vendor Invoice . . . Account Types . . . Net Document Type Document Type Billing Document . Transfer from SD . . Account Types Reverse Document Type . . . ASK KN ADS RV AB
- 7. Posting Key Posting Key Description Debit/Credit Account Type 01 Invoice Debit Customer 40 Debit Entry Debit G/L Account 50 Credit Entry Credit G/L Account 15 Incoming Pmt Credit Customer
- 8. Examples of Posting Keys G/L Accounts Debits Credits 40 Debit entry 50 Credit entry Vendors Debits Credits 21 Credit memo 31 Invoice 22 Reverse invoice 32 Reverse credit memo 25 Outgoing payment 35 Incoming payment Customers Debits Credits 01 Invoice 11 Credit memo 02 Reverse credit memo 12 Reverse invoice 05 Outgoing payment 15 Incoming payment
- 9. Default Values for Document Processing Transaction Doc. Type Post. Key F-02 Enter G/L Account Posting SA 40 F-64 Park Customer Invoice DR 01 F-66 Park Vendor Credit Memo KG 21 F-67 Park Customer Credit Memo DG 11
- 10. Default Values for Enjoy Postings Company Code Acct type Doc. Type XXPH G/L Accounts SA XXPH Customers DR XXPH Vendors KR DOCUMENT TYPES FOR ENJOY TRANSACTIONS POSTING KEYS FOR ENJOY TRANSACTIONS Transaction Debit Credit SAK - G/L account posting 40 50 AGD - Cust. item - outgoing invoice 01 31 AGS - G/L item - outgoing invoice 40 50 ETC.
- 11. Field Status G/L Account is assigned to Field Status Group Field Status Group is assigned to the Field Status Variant Field Status Variant is allocated to Company Code G/L Account Field Status Group 113000 Citibank-Checks G005 420000 Office Supplies G004 . . . Fld Status Group Text G004 Cost Accounts G005 Bank accounts . . . CC Company Name City Fld. Stat. Var. 0001 SAP Inc. Philadelphia 0001 US01 Company Template New York 1000 . . .
- 13. Screen Layout Link Rules Posting Key Field Status Group vs. G/L Account Master Record Field Status Group If a conflict occurs Then link rules are applied Link Rules Suppress Sup. N/A 1 Sup. Required N/A 1 Req. Req. Optional Sup. Req. Opt. Suppress Required Optional
- 14. Enjoy Postings - Screen Variants
- 15. Intercompany Transactions Example: Central Payables ALPHA bills……….. Company Code 9999 $3000 Company Code 1234 $2000 Company Code 9999 pays both bills Company Code 1234 owes CoCd 9999 $2000 1 2 3 Company Code Account Debit Credit 9999 Alpha 3000 1234 Alpha 2000 9999 Internal Receivable 2000 9999 Cash 5000 1234 Internal Payable 2000 Resulting Journal Entry………..
- 16. Intercompany Transactions Example: Central Payables Company Codes 9999 1234 1234 9999 Company Codes Internal Receivable Internal Receivable Internal Payable Internal Payable
- 17. Validations and Substitutions Ensuring Data Integrity Validation/ Substitution Document System Check Data Entry
- 18. Validation and Substitution Example If Company Code = 9999 Then Business Area = BS01 If Company Code = 9999 Then Business Area <> BS02 Company Code 9999 Business Area BS02 Substitutions (Data Entry) Validations (Data Entry) Validation Substitution Substitution (Result) Company Code 9999 Business Area E: Company Code ‘9999’ cannot post to Business Area ‘BS02’. Company Code 9999 Business Area BS01
- 19. Integration Application Area/Callup Point AM FI PC CO KC GL GR PS GS GU LC MC Validations and Substitutions
- 20. Validation Steps Condition A Account= 56000 Condition B Cost Center =3300 Message Exit/ Document Posted True False False True Transaction Data If false, then a message results. Different types of messages can be configured. Prerequisite <BSEG>$HKONT=‘56000’ Check <BSEG>$KOSTL=‘3300’
- 22. Substitution Steps Prerequisite: If the Account is 123000 and the Business Area is 202 If prerequisite is met, then substitute Cost Center 501
- 24. User Exits Exit
- 25. Trace Function Results of Validation W: Account 123000 must be... One starts the Trace function from the IMG and can be started in a parallel session. FB01: Posting Doc. Date Comp. Code Posting Date PK Account W: Account 123000 must be...
Hinweis der Redaktion
- As a result of this chapter, you should be able to: Understand the Document Principle , its purpose and how it is used Understand the Structure of a document Provide descriptions of and uses for various Document Types Create the appropriate document layout for a Document Type by configuring parameters for the following: Document Types and their Number Ranges Posting Keys Screen layouts for the above (called the field status) Data integrity
- The Document Principle: In the system, a document is created for every business transaction. Each document receives a unique Document Number. A document can consist of one screen (or page) or many screens (or pages), each containing different levels of detail.
- Every document consists of: A Document Header , which contains general data that applies to the entire document such as: Posting Date : the date that G/L account balances or the customer/vendor balances are updated. It determines the posting period. Document Date : issue date of the original document (not necessarily the same as the Posting Date). In invoices it is called the Invoice Date . Document Number Document Type Currency Document Header Text At least two line items, a minimum of one debit and one credit, and at most 999 line items. Every line item contains a: Posting Key (can be hidden for some line items, e.g.customer, vendor ) Account Number Amount Since it is posted at the Company Code level, where balanced financial statements are ensured, a document can only be posted if the debits equal the credits. An exception to this rule is a noted item which contains only a debit or a credit; it serves as a reminder and does not affect the financial books. Examples of noted items and their uses can be found in Chapter 26 (Special G/L Transactions).
- Each document is characterized by a Document Type. The Document Type is a two-character alphanumeric key that identifies documents. The Document Type: Distinguishes between types of business transactions that are posted SA: General Ledger Accounting Document DR: Customer Invoice DZ: Customer Payment Controls the Account Types that may be used in the posting with this Document Type D: Customer Accounts K: Vendor Accounts S: G/L Accounts A: Assets Accounts M: Material Accounts Is assigned a Number Range, which controls how Document Numbers are assigned Can be used as a sort criteria It is possible to restrict user access to a Document Type by using authorizations.
- In the standard system, the following Document Types have a special use: KN: Vendor Net Invoice RV: Billing Document Transfer from SD When posting a vendor invoice net, the system posts the expense net, without tax and cash discount line items. Net vendor invoices can only be posted if a special Document Type marked as &quot;Net Document Type&quot; (standard Document Type KN) is used. If Sales and Distribution (SD) is being implemented, a Document Type to transfer customer Billing Documents from SD to FI is needed. When using both modules, generally the SD module creates the customer bill (invoice). This information must be recorded in FI for reporting purposes and for accounts receivable tracking.
- Document Number Ranges are defined per Company Code and are assigned to each Document Type in the system. Document Number Ranges can be maintained by: Maintaining intervals: Create and change Number Ranges Changing the status: Intentionally change the Current Number field Number Ranges are valid based on the fiscal year. If year specific Document Numbers are not desired, a future year must be specified in the Year field. The following Number Ranges, for which no Document Type entries exist, are reserved (further explanation of these can be found in Chapter 12 - Reference Documents): X1: Recurring Entries X2: Sample Documents Document Numbers uniquely identify documents in the system. The Number Ranges used to control Document Number assignment can be defined to assign them internally (the system assigns the Current Number to the document) or externally (the user must enter a Document Number manually when creating a document).
- The Posting Key is a two-digit numeric key that controls how document line items are entered and posted. The Posting Key: Specifies whether the line item is a debit or credit Specifies the Account Type: Customer, Vendor, G/L Account, Asset, Material Determines other properties: Sales related: Indicates the line item is used in the calculation of sales Special G/L Transaction: Indicates the Posting Key relates to a special G/L transaction (see Chapter 27: Special General Ledger Transactions) Reversal Posting Key: Indicates the posting key used to reverse line items made with the current posting key Payment Transaction: Indicates marked if the Posting Key is relevant to transactions related to incoming or outgoing payments Contains Field Status definitions that are used as a factor in determining the screen layout when posting transactions (configuring Field Status is discussed in further detail later in this chapter).
- This slide lists the most commonly used Posting Keys.
- In the IMG, Default Document Type and initial Posting Key values may be defined for posting transactions. When a posting transaction is executed, the Document Type and initial Posting Key are defaulted by the system. These can be changed prior to posting the document. Caution should be used when updating this information as the table containing this data is client independent (i.e., All Clients within the system instance will be affected).
- In Release 4.6, SAP introduced a simplified way of posting called “Enjoy” posting. Enjoy postings are more user friendly than the standard postings (now called Complex or General postings in Release 4.6) not only because of a simplified data entry screen but also because of defaulted document type and posting keys for multiple line items. Unlike the default posting keys in a Complex Posting, the defaulted posting keys in an Enjoy Posting cannot be changed. The defaults for posting keys and document types have to be defined in IMG. The document types are defined per company code, account type and possibly transaction (e.g., invoice, credit memo). The posting keys are defined according to the transaction (G/L account posting, outgoing invoice, incoming invoice, etc.) and the item within the transaction (customer, vendor, G/L).
- The Company Code is assigned a Field Status Variant, which contains a set of Field Status Groups . Many G/L Accounts require the same screen layout for posting. In this case, a Field Status Group for the screen layout can be defined and assigned to the appropriate G/L Account master records. The following factors must be configured to define the document screen layout: Field Status Group of the G/L Account master record. In the case of customers and vendors, the G/L reconciliation account is used. Field Status of the Posting Key Link Rules, discussed later in the following slides, determine which of the factors above take priority. Screen Variants impact the way a posting screen is displayed in Enjoy Postings; however, they function differently than the Field Status. Screen variants will be discussed later in this chapter.
- The term Field Status refers to the definition of a data field as being suppressed, required or optiona. For Complex Postings, configuring the field status ultimately defines the screen layout when posting a transaction. Enjoy Postings may also be impacted by a Screen Variant. The Field Status Group Is a collection of field statuses that is assigned to similar G/L Account master records at the Company Code level. Is a factor used to determine the screen layout during transaction postings using the respective account. To define the Field Status Group in the IMG, a group must be selected. Each field within the group can then be assigned a Field Status: Suppressed: The field is not displayed on the screen for entry Required: Data must be entered in the field Optional: Data can be, but is not required to be, entered in the field. When configuring Field Status Groups: A list of all groups within a Field Status Group can be displayed by selecting the Edit Field Status push-button. Each Field Status Group is divided into groups of fields, such as general data and payment transactions. All fields in all of the groups within a Field Status Group can be displayed by selecting the Subgroup List push-button.
- During document entry, the properties of a field are determined by link rules. Link rules determine the field status of a field if they differ for the following: Field Status Group of the G/L Account master record (including Customer/Vendor reconciliation accounts), which are defined at the Company Code level Field Status of the Posting Key (defined at the Client level) 1 When attempting to post an entry with these conflicting rules, an error message appears requiring one of the rules to change.
- For Enjoy postings, entry screen variants can be used to simplify data entry and make only the necessary fields available for entry Since all line item fields are on one screen for Enjoy postings, posting keys and field status groups of G/L accounts are not able to determine directly the screen layout for line items. Even if the posting keys or field status groups define fields as suppressed these fields will be displayed on the default entry screen even though not available for entry (as opposed to complex postings when these fields are hidden). To avoid having to scroll though such a great amount of fields the user can utilize a customized entry screen. The entry screen can be customized and selected through a menu path directly in the entry screen. This customization simply determines which fields will be invisible. The fields defined this way will be hidden. If these fields are required (according to the posting key or field status group) the system will still ask for an entry even if the entry screen variant defines them as invisible.
- Intercompany transactions occur when the same transaction impacts two or more company codes. For example, when there is a central payables process, a company remits payment for itself and for other Company Codes within the same Client. This process clears the open items and creates new open items between the company codes. Intercompany payable and receivable accounts must be set so that the companies can generate transactions with each other. Three documents are generated when you have an intercompany transaction: one at the first Company Code, one at the second Company Code and one representing the intercompany transaction, which appears in both company codes. The intercompany transaction number is assigned one of two ways: Automatically by the system Manually by the user When automatically assigned by the system, the number is structured as follows: First 10 digits: Document number of the first Company Code document Next 4 digits: First Company Code Next 2 digits: Last two digits of the fiscal year the document was created To eliminate intercompany transactions for financial reporting purposes, documents related to the transactions must be cleared against each other utilizing the Legal Consolidation module.
- In order to post intercompany transactions, the intercompany payable and intercompany receivable accounts must be configured so that they reference each other. For each combination of Company Codes, one clearing account for receivables and one for payables must be specified in each Company Code. Depending on the posting key selected, the intercompany accounts can be either General Ledger Accounts or Customer/Vendor Accounts. For example, Posting Key 40 results in G/L Accounts and Posting Key 01 results in Customer accounts.
- To ensure the integrity of data, you can validate and/or substitute data at the time of transaction entry. Validations and substitutions can be configured in FI so combinations of information will be checked for validity before posting. Validations : Using Boolean logic, the system checks any combination of specified criteria (e.g., an Account/Cost Center combination) for validity before posting a document. Substitutions : Using Boolean logic, the system replaces values of assigned fields according to user-defined specifications. A Boolean logic statement is a logical structure that can be either true or false. Statements can be linked together using operators (such as AND, OR, NOR) to create complex statements. Boolean logic uses truth tables to determine the truth value (TRUE or FALSE) of statements. A truth table assigns the value of T(True) or F(False) to each part of a complex statement, and then determines whether the combined statement is true or false. The system performs substitutions before validations so that substituted values can also be validated.
- Example of a Validation (depicted above) If a document is being posted for Company Code 9999 then the Business Area responsible for that expense cannot be BS02. If a user then enters a document with Company Code 9999 and Business Area BS02 then a message will result. Example of a Substitution (depicted above) If a document is being posted for Company Code 9999 then the system will substitute the entered Business Area with BS01. Only one Validation and one Substitution can be activated at a time per Company Code and Callup Point. However, each may contain multiple steps (‘if / then’ statements).
- Validations and Substitutions can be an integration point between applications; therefore, they are configured for an Application Area and Callup Point. The Application Area is a two-character code, which specifies the general Application Area where the Validation/Substitution occurs. The Callup Point Code is a four-digit code, which specifies the instance where the validation/substitution occurs. The combination of Application Area and Callup Point determines the exact location where a validation/substitution is invoked. To use the same Boolean logic statement in multiple places, assign a name to the Boolean expression. This name for the Boolean expression is known as a Rule. A Rule can be used as a stand-alone condition or check, or it can be used as part of another Rule.
- A Validation can consist of up to 999 steps; therefore, you can validate against any number of Boolean statements before the data is posted. A Validation Step contains the following statements: Prerequisite Statement: Determines if the entered value(s) should be checked. In this example, the Account 56000 will be checked. Check Statement: Determines if the entered value(s) are valid. If the Check Statement is true, then the value is valid and the transaction continues. If the Check Statement is false then the system displays a message. In this example, the only valid Cost Center is 3300. Any other Cost Center will result in a message.
- Steps to create a Validation: 1) Enter the Application Area and Callup Point for the Validation. 2) Define the Prerequisite Statement, which determines whether or not the data should be checked. 3) Define the Check Statement, which validates the data. 4) Determine the messages that will appear if a Check Statement is not met during validation. Once a Validation is created, it must be activated by: 1) Entering the Callup Point and Company Code for the Validation in the applicable table, and 2) Activating the validation (entering ‘1’ in the Activation Level column in the table) Validations can have the following message types: Informational Warning: the user has the option of bypassing the warning and continuing to post the entry. Error: the user cannot continue processing the transaction until the error is corrected. Abend: the system will end all processing; the program is abnormally terminated.
- A Substitution can also consist of up to 999 steps. Therefore, you can substitute data using any number of Boolean statements before the data is posted. A substitution step contains the following main components: Prerequisite Statement: Defines the conditions that must be met before the substitution takes place. If the prerequisite is false, the transaction continues with no substitution. If the prerequisite is true, the transaction continues with the substituted value(s). Substitution Value(s): Numerical or character value with which an incoming value should be substituted. Substitution Exit: The substitution may be performed in a Substitution Exit. A Substitution Exit Number refers the system to a user-defined ABAP program. When values are substituted using a Substitution Exit, you can define more complex situations, allowing more than one value to be substituted.
- Steps to create a Substitution: 1) Enter the Application Area and Callup Point for the substitution. 2) Define the Prerequisite Statement that should be used for selecting data for substitution and value with which the data should be substituted. 3) Activate the Substitution by: Entering the Callup Point and Company Code for the Substitution. Assigning the Substitution Name to the Callup Point/Company Code combination and setting the Activation field.
- For complicated Validations, Substitutions, or Rules that cannot be supported by Boolean algebra statements, you can define a user exit to calculate and/or replace values. A user exit is a break in the ABAP program in which the user codes a check of data.
- If a Validation and/or Substitution is not returning the expected message, a trace function exists to determine when and why it is not working. The trace is activated from the Validation Editor Window (Menu path: Extras>Switch on Trace). When the posting transaction is started, the values of all elements used in the Validation are displayed when the Validation is called. The same applies to Substitutions and Rules. The trace function is activated for each user for one Validation, one Substitution, or both. When activated, the trace function stays on for the entire session or until it is turned off.
- Document Principle - a document is created for every business transaction. This document receives a unique Document Number . Document Structure - every document has a Document Header and at least two line items. Document Header - contains general data that applies to the entire document (e.g., Posting Date, Document Date, Document Number, Document Type, Currency, Document Header Text). Posting Date - a date that identifies in which Accounting Period the document is posted. Document Date - the issue date of the original document. It is not necessarily the same as the Posting Date. Document Type - a two-character alphanumeric key that distinguishes between business transactions. Posting Key - a two-character numeric key that controls how a line item is entered. Noted Item - a one-sided entry that acts as a memo; it does not affect the financial books.
- Document Number Range - defines a range of numbers that will be used to identify each Document Type; reserved Number Ranges exist for some Reference Documents (see Chapter 12 - Reference Documents). Account Type - an alphanumeric key that identifies the type of account - each type of master record is also a type of account (e.g., D = Customer, K = Vendor). Field Status - the definition of a field as being suppressed, required or optional during transaction entry. Field Status Group - a collection of field statuses that is assigned to similar G/L Account master records. Link Rules - when a transaction has accounts and posting keys with different field statuses, link rules determine whether a field will be suppressed, required or optional. Screen Variant - controls the appearance of Enjoy Posting screens and works independently of Field Status settings. Default Values - for standard transactions, the Posting Keys and Document Types are automatically populated during data entry. Intercompany Document - Represents intercompany transactions and appears in both Company Codes.
- Validation - the system checks data for integrity before posting the document using Boolean logic Substitution - the system checks data for integrity when posting the document using Boolean logic. If data is different from the criteria set, a substitution is made. Rule - the assigned name of a Boolean logic statement, which enables the statement to be used in multiple places. User Exit - a break in the ABAP program, which enables the user to insert code that checks or modifies data. Callup Point - specifies where a validation/substitution occurs Trace Function - functionality used to determine why a Validation / Substitution is not performing as expected. Enjoy Posting - A user-friendly screen characterized by a single data entry screen, tabs, and push buttons Complex/General Posting - Traditional SAP screen characterized by multiple data entry screens.