Financial Accounting (FI)

Financial Accounting (FI)
ECC 6.0 January 2008 Unit 10 Financial Accounting (FI) - Transactions - © SAP AG and The Rushmore Group, LLC 2008

Business Process Integration
ECC 6.0 January 2008 Business Process Integration FI Transactions January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 Transaction Data Includes internal and external exchanges that describe business activities Unlike master data, aggregate transactional data is dynamic – each transaction is unique January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Financial Accounting (FI)
ECC 6.0 Financial Accounting (FI) January 2008 R/3 FI Financial Accounting CO Controlling PS Project System WF Workflow IS Industry Solutions MM Materials Mgmt. HR Human Resources SD Sales and Distribution PP Production Planning QM Quality PM Plant Maintenance SM Service Client / Server Integrated Business Solution EC Enterprise AM Fixed Assets Green ones (and blue): Logistics Start out with sales and distribution Yellow HR was added later in SAP’s life (1990) Red: Tracking side of house. (Financials) Purple:Workflow is the least understood by faculty and students Allow the movement of information in the enterprise to the people who need it. (e.g. Credit limit – s, updates) Industry Solutions: Each install is tracked by SAP and the configuration is monitored by industry. This way SAP knows the whole set of answer of how industries works with their best business practices. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Unit 10 – Overview Monthly Rent Cycle Invoice Receipt Invoice Entry
ECC 6.0 Unit 10 – Overview January 2008 Monthly Rent Cycle Invoice Receipt Invoice Entry Accounts Payable Settlement January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Monthly Rent Cycle Invoice Rental Receipt Agreement Accounts Payable
ECC 6.0 Monthly Rent Cycle January 2008 Invoice Receipt Rental Agreement Accounts Payable The monthly rent cycle is: Base upon the lease we make a payable invoice Pay it January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Invoice Receipt Invoice Receipt Invoice Verification ECC 6.0
January 2008 Invoice Receipt Invoice Receipt Invoice Verification The invoice receipt steps are as follows: The invoice receipt (bill from vendor) Verification of invoice Creation of A/P based upon the vendor master data. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Invoice Entry Vendor Information ECC 6.0 January 2008 January 2008
© SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Accounts Payable Settlement
ECC 6.0 January 2008 Accounts Payable Settlement Select payment method and bank Select items for payment Calculate the payment amount, taking account of cash discount periods Post the payment document Print payment medium Payment program configuration involves determining: What is to be paid. To do this, you specify rules according to which the open items are selected and grouped for payment. When payment is carried out. The due date of the open items determines when payment is carried out. However, you can specify the payment deadline in more detail via configuration. To whom the payment is made. You specify the payee. How the payment is made. You determine rules that are used to select a payment method. From where the payment is made. You determine rules that are used to select a bank and a bank account for the payment. The above rules and conditions must be defined if the payment program is to determine the above-mentioned information automatically. However, you can also specify this information manually. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Unit 10 – Exercises Create Vendor Master Record for Landlord
ECC 6.0 Unit 10 – Exercises January 2008 Create Vendor Master Record for Landlord Create Rent Expense Account Create Invoice Receipt for Rent Expense Display and Review General Ledger Account Balances and Individual Line Items Display and Review Vendor Account Balances and Individual Line Items Post Payment to Landlord Display and Review General Ledger and Vendor Account Balances and Individual Line Items January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Materials Management (MM)
ECC 6.0 January 2008 Unit 11 Materials Management (MM) - Rules - © SAP AG and The Rushmore Group, LLC 2008

Business Process Integration
ECC 6.0 January 2008 Business Process Integration Rules MM Rules for material management Reservations Tolerances Purchasing Goods Receipt Invoice Receipt Valuation Account Assignment Invoice Verification January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Rules Defines the parameters for Master Data and Transactions
ECC 6.0 January 2008 Rules Defines the parameters for Master Data and Transactions Determines functionality for Master Data and Transactions Relatively fixed Changes as policy changes Master data does not change very often Org data – should not change Transaction data (application data) – changes every transaction Rules are relatively fixed. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Materials Management (MM)
ECC 6.0 Materials Management (MM) January 2008 R/3 FI Financial Accounting CO Controlling PS Project System WF Workflow IS Industry Solutions MM Materials Mgmt. HR Human Resources SD Sales and Distribution PP Production Planning QM Quality PM Plant Maintenance SM Service Client / Server Integrated Business Solution EC Enterprise AM Fixed Assets Green ones (and blue): Logistics Start out with sales and distribution Yellow HR was added later in SAP’s life (1990) Red: Tracking side of house. (Financials) Purple:Workflow is the least understood by faculty and students Allow the movement of information in the enterprise to the people who need it. (e.g. Credit limit – s, updates) Industry Solutions: Each install is tracked by SAP and the configuration is monitored by industry. This way SAP knows the whole set of answer of how industries works with their best business practices. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Unit 11 – Overview Reservations Tolerances
ECC 6.0 Unit 11 – Overview January 2008 Reservations Tolerances Purchasing Goods Receipt Invoice Receipt Automatic Account Assignment Invoice Verification January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 Reservations A request to have a material ready for issue at a future date for a production order, sales order, etc. The purpose of a reservation is to ensure that a material is available when required and not assigned to another use The purpose of a reservation is to ensure that a material will be available when it is needed. It also serves to simplify and accelerate the goods issue process and prepare the tasks at the point of goods issue. It is also important that reservations are taken into account by Material Requirements Planning (MRP), which means that required materials are procured in time if they are out of stock. You enter reservations for planned receipts for either of the following reasons: to plan goods receipts from production if your company does not use the PP Production Orders component to plan goods receipts from vendors, if your company does not use the MM Purchasing component January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Purchasing Tolerances
ECC 6.0 January 2008 Purchasing Tolerances A tolerance limit is set for allowed variance before a warning/error message is displayed Price variance Compares the price in the purchase order with the valuation price stored in the material master Maximum cash discount This tolerance limit is set to assure that cash discounts do not exceed allowable discounts Now earlier created tolerances in accounting for AR/AP Now we will have some material tolerances Tolerances can be set at the material level or the vendor info record level. This allows for the tailoring of tolerances as needed. In the Customizing system for Inventory Management, you can define two tolerances for variances in the order price quantity: Tolerance for an error message: if the variance is larger than this tolerance specified, the system issues an error message, and you cannot post the goods receipt. Tolerance for a warning message: if the variance reaches this tolerance specified, the system issues a warning message during entry of the goods receipt. However, you can still post the goods receipt. The buyer receives a message pointing out the discrepancy. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Goods Receipts Tolerances
ECC 6.0 January 2008 Goods Receipts Tolerances Purchase order price quantity – there are two tolerance levels maintained per item The maximum percentage variance before a goods receipt postings is not allowed A percent variance that generates a warning message but allows posting Moving average price variance – the maximum allowable moving average price change allowed Goods Receiving personnel can confirm the receipt of goods simply by entering the Po number. By specifying permissible tolerances, buyers can limit over- and under deliveries of ordered goods. In this step, you set the tolerance limits for goods receipts. When processing a goods receipt, the system checks each item to determine whether the goods receipt varies from the purchase order or the material master data. The different types of variances are defined by tolerance keys. For each tolerance key, tolerance limits can be set per company code. The following variances are checked in Inventory Management: Variance in the purchase order price quantity For this variance, two tolerance keys are provided: Tolerance key B1 (error message) You use tolerance key B1 to define the maximum percentage variance. If the variance is greater than the maximum variance, the system creates an error message. The user cannot post the goods receipt. Tolerance key B2 (warning message) Tolerance key B2 defines the percentage variance from which a warning message is to be issued. It is possible to post the goods receipt. Variance for the moving average price of the material You use tolerance key VP to define the percentage variance from which a warning message is issued. This warning message indicates a price change. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Invoice Receipts Tolerances
ECC 6.0 January 2008 Invoice Receipts Tolerances Many tolerance limits that can be configured for invoice receipts: price, quantity, and blanket purchase orders These tolerances include: Amount for item with or without order reference Form small differences automatically Percentage Over/Under Quantity Variance Exceed amount: quantity variance Blanket purchase order – value and time limit Price variance When you enter an invoice, the system proposes certain values from the purchase order or goods receipt. If the invoice item differs from the default values, you must determine the reason for the variance by contacting the purchasing or goods receipt department or the vendor. It is too time-consuming to investigate very small variances. So tolerance limits can be defined in the system. If variances in an invoice item are within these limits, they are accepted by the system. If a tolerance limit is exceeded, you receive a system message. You can still post the invoice but it will be automatically blocked for payment if it exceeds the upper tolerance limit (see also Tolerances). If the invoice is blocked, all the items are blocked. Even if the invoice only displays variances in one item, the whole invoice is blocked for payment. If you post an invoice with a blocking reason, the system carries out two steps: The account postings resulting from the invoice are made. In the vendor item, the system enters an R in the field Payment block so that Financial Accounting cannot make payment for the invoice. The following blocking reasons exist for variances in invoice items (the relevant blocking indicator is specified in parentheses): Quantity variance (M) A quantity variance exists if the invoiced quantity is larger than the difference between the quantities delivered and those already invoiced. In the SAP System, a quantity variance is treated differently depending on the amount of the variance. The product of the order price and the variance quantity is used as the basis for determining whether the invoice is to be blocked. Lower priced items are permitted relatively large quantity differences, whereas more expensive items are allowed only very small differences. Price variance (P) A price variance exists if the invoiced price (invoiced amount divided by the invoiced quantity) is not the same as the net order price. Variance in order price quantity (G) A variance in order price quantity exists if the ratio between the order price quantity and the order quantity in the invoice differs from the ratio specified at goods receipt (or if it differs from the ratio in the purchase order, if no goods receipt has taken place). Schedule variance (T) A schedule variance exists if the date of invoice entry is before the delivery date specified in the purchase order. In the SAP system, schedule variances are treated differently depending on the value of the invoice items. The product of the invoice item value and the number of days variance is used as a basis for determining whether the invoice is to be blocked. In this way, relatively large schedule variances are allowed for lower value items, whereas only very small schedule variances are permitted for high value invoice items (When an invoice refers to a scheduling agreement, the system does not check for a schedule variance, since there is no clearly fixed delivery date in a scheduling agreement.). Quality inspection (I) If a material is defined as being relevant for quality management, goods receipts for this material are posted to stock in quality inspection. Invoices for the material are blocked until the inspection has been successfully completed. If more than one goods receipts is posted for an order item, an inspection is carried out for every goods receipt. A distinction is made between two different scenarios in Invoice Verification: Goods-receipt-based Invoice Verification has been defined in the purchase order: The invoice is blocked if the inspection has not been completed for the goods receipt. No goods-receipt-based Invoice Verification has been defined in the purchase order: The invoice is blocked if any goods receipts are still in quality inspection. If an invoice is posted before the goods are received, it cannot be blocked for quality inspection. When Quality Management is active, we recommend you work with goods-receipt-based Invoice Verification. In addition to the fact that invoices are only blocked that pertain to the exact goods receipt, this also ensures that an invoice cannot be posted before the goods receipt and subsequently before the quality inspection has taken place. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Automatic Account Assignment
ECC 6.0 January 2008 Automatic Account Assignment Automatic account assignment is created to avoid manual postings of financial transactions which follow goods movements to reflect the values of transferred materials Automatic account assignment is used across all modules to keep track of the values of materials that are being consumed (e.g., production), or transferred into other valuation areas of the company Track all transactions – Debits/Credits automatically through all transactions Receiving Movement Raw Materials Issue The stocks are managed not only on a quantity basis but also by value. The system automatically updates the following data each time there is a goods movement: Quantity and value for Inventory Management Account assignment for cost accounting G/L accounts for financial accounting via automatic account assignment The valuation area is the organizational level at which a material's stock value is managed. The valuation area can be plant level or company code level. In Inventory Management, work is basically done at plant and storage location levels. When you enter a goods movement, you only have to enter the plant and the storage location of the goods. The system derives the company code from the plant via the valuation area. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Automatic Account Assignment (continued)
ECC 6.0 January 2008 Automatic Account Assignment (continued) Automatic account assignment is a set of rules and master data which enable the financial tracking of logistics movement The G/L account to which the goods movement is posted is determined by the system through automatic account assignment. You need not enter a G/L account unless you want to post the goods movement to a different account. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Automatic Account Assignment Components
ECC 6.0 January 2008 Automatic Account Assignment Components Components of Automatic Account Assignment Chart of Accounts Valuation Grouping Code Transaction Key Modifier for Transaction Key Valuation Class This is materials management, you want to bring in the accountants to set up the accounts Postings are made to G/L accounts automatically in the case of Invoice Verification and Inventory Management transactions relevant to Financial and Cost Accounting. Example: Posting lines are created in the following accounts in the case of a goods issue for a cost center: Stock account Consumption account How does the system find the relevant accounts? When entering the goods movement, the user does not have to enter a G/L account, since the R/3 System automatically finds the accounts to which postings are to be made using the following data: Chart of accounts of the company code If the user enters a company code or a plant when entering a transaction, the R/3 System determines the chart of accounts which is valid for the company code. You must define the automatic account determination individually for each chart of accounts. Valuation grouping code of the valuation area If the automatic account determination within a chart of accounts is to run differently for certain company codes or plants (valuation areas), assign different valuation grouping codes to these valuation areas. You must define the automatic account determination individually for every valuation grouping code within a chart of accounts. It applies to all valuation areas which are assigned to this valuation grouping code. If the user enters a company code or a plant when entering a transaction, the system determines the valuation area and the valuation grouping code. Transaction/event key (internal processing key) Posting transactions are predefined for those inventory management and invoice verification transactions relevant to accounting. Posting records, which are generalized in the value string, are assigned to each relevant movement type in inventory management and each transaction in invoice verification. These contain keys for the relevant posting transaction (for example, inventory posting and consumption posting) instead of actual G/L account numbers. You do not have to define these transaction keys, they are determined automatically from the transaction (invoice verification) or the movement type (inventory management). All you have to do is assign the relevant G/L account to each posting transaction. Account grouping (only for offsetting entries, consignment liabilities, and price differences) Since the posting transaction "Offsetting entry for inventory posting" is used for different transactions (for example, goods issue, scrapping, physical inventory), which are assigned to different accounts (for example, consumption account, scrapping, expense/income from inventory differences), it is necessary to divide the posting transaction according to a further key: account grouping code. An account grouping is assigned to each movement type in inventory management which uses the posting transaction "Offsetting entry for inventory posting". Under the posting transaction "Offsetting entry for inventory posting", you must assign G/L accounts for every account grouping, that is, assign G/L accounts. If you wish to post price differences to different price difference accounts in the case of goods receipts for purchase orders, goods receipts for orders, or other movements, you can define different account grouping codes for the transaction key. Using the account grouping, you can also have different accounts for consignment liabilities and pipeline liabilities. Valuation class of material or (in case of split valuation) the valuation type The valuation class allows you to define automatic account determination that is dependent on the material. for example: you post a goods receipt of a raw material to a different stock account than if the goods receipt were for trading goods, even though the user enters the same transaction for both materials. You can achieve this by assigning different valuation classes to the materials and by assigning different G/L accounts to the posting transaction for every valuation class. If you do not want to differentiate according to valuation classes you do not have to maintain a valuation class for a transaction. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Automatic Account Assignment Valuation Grouping Code
ECC 6.0 January 2008 Automatic Account Assignment Valuation Grouping Code Valuation grouping code - groups valuation areas together Example: valuation area is plant, five plants exist in the company, all five plants use the same accounts. Multiple valuation groups are possible This is materials management, you want to bring in the accountants to set up the accounts Postings are made to G/L accounts automatically in the case of Invoice Verification and Inventory Management transactions relevant to Financial and Cost Accounting. Example: Posting lines are created in the following accounts in the case of a goods issue for a cost center: Stock account Consumption account How does the system find the relevant accounts? When entering the goods movement, the user does not have to enter a G/L account, since the R/3 System automatically finds the accounts to which postings are to be made using the following data: Chart of accounts of the company code If the user enters a company code or a plant when entering a transaction, the R/3 System determines the chart of accounts which is valid for the company code. You must define the automatic account determination individually for each chart of accounts. Valuation grouping code of the valuation area If the automatic account determination within a chart of accounts is to run differently for certain company codes or plants (valuation areas), assign different valuation grouping codes to these valuation areas. You must define the automatic account determination individually for every valuation grouping code within a chart of accounts. It applies to all valuation areas which are assigned to this valuation grouping code. If the user enters a company code or a plant when entering a transaction, the system determines the valuation area and the valuation grouping code. Transaction/event key (internal processing key) Posting transactions are predefined for those inventory management and invoice verification transactions relevant to accounting. Posting records, which are generalized in the value string, are assigned to each relevant movement type in inventory management and each transaction in invoice verification. These contain keys for the relevant posting transaction (for example, inventory posting and consumption posting) instead of actual G/L account numbers. You do not have to define these transaction keys, they are determined automatically from the transaction (invoice verification) or the movement type (inventory management). All you have to do is assign the relevant G/L account to each posting transaction. Account grouping (only for offsetting entries, consignment liabilities, and price differences) Since the posting transaction "Offsetting entry for inventory posting" is used for different transactions (for example, goods issue, scrapping, physical inventory), which are assigned to different accounts (for example, consumption account, scrapping, expense/income from inventory differences), it is necessary to divide the posting transaction according to a further key: account grouping code. An account grouping is assigned to each movement type in inventory management which uses the posting transaction "Offsetting entry for inventory posting". Under the posting transaction "Offsetting entry for inventory posting", you must assign G/L accounts for every account grouping, that is, assign G/L accounts. If you wish to post price differences to different price difference accounts in the case of goods receipts for purchase orders, goods receipts for orders, or other movements, you can define different account grouping codes for the transaction key. Using the account grouping, you can also have different accounts for consignment liabilities and pipeline liabilities. Valuation class of material or (in case of split valuation) the valuation type The valuation class allows you to define automatic account determination that is dependent on the material. for example: you post a goods receipt of a raw material to a different stock account than if the goods receipt were for trading goods, even though the user enters the same transaction for both materials. You can achieve this by assigning different valuation classes to the materials and by assigning different G/L accounts to the posting transaction for every valuation class. If you do not want to differentiate according to valuation classes you do not have to maintain a valuation class for a transaction. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Automatic Account Assignment Valuation Grouping Code
ECC 6.0 January 2008 Automatic Account Assignment Valuation Grouping Code Plant – P004 Plant – P001 Grouping Code G001 Plant – P003 Plant – P002 G002 Plant – P005 This is materials management, you want to bring in the accountants to set up the accounts Postings are made to G/L accounts automatically in the case of Invoice Verification and Inventory Management transactions relevant to Financial and Cost Accounting. Example: Posting lines are created in the following accounts in the case of a goods issue for a cost center: Stock account Consumption account How does the system find the relevant accounts? When entering the goods movement, the user does not have to enter a G/L account, since the R/3 System automatically finds the accounts to which postings are to be made using the following data: Chart of accounts of the company code If the user enters a company code or a plant when entering a transaction, the R/3 System determines the chart of accounts which is valid for the company code. You must define the automatic account determination individually for each chart of accounts. Valuation grouping code of the valuation area If the automatic account determination within a chart of accounts is to run differently for certain company codes or plants (valuation areas), assign different valuation grouping codes to these valuation areas. You must define the automatic account determination individually for every valuation grouping code within a chart of accounts. It applies to all valuation areas which are assigned to this valuation grouping code. If the user enters a company code or a plant when entering a transaction, the system determines the valuation area and the valuation grouping code. Transaction/event key (internal processing key) Posting transactions are predefined for those inventory management and invoice verification transactions relevant to accounting. Posting records, which are generalized in the value string, are assigned to each relevant movement type in inventory management and each transaction in invoice verification. These contain keys for the relevant posting transaction (for example, inventory posting and consumption posting) instead of actual G/L account numbers. You do not have to define these transaction keys, they are determined automatically from the transaction (invoice verification) or the movement type (inventory management). All you have to do is assign the relevant G/L account to each posting transaction. Account grouping (only for offsetting entries, consignment liabilities, and price differences) Since the posting transaction "Offsetting entry for inventory posting" is used for different transactions (for example, goods issue, scrapping, physical inventory), which are assigned to different accounts (for example, consumption account, scrapping, expense/income from inventory differences), it is necessary to divide the posting transaction according to a further key: account grouping code. An account grouping is assigned to each movement type in inventory management which uses the posting transaction "Offsetting entry for inventory posting". Under the posting transaction "Offsetting entry for inventory posting", you must assign G/L accounts for every account grouping, that is, assign G/L accounts. If you wish to post price differences to different price difference accounts in the case of goods receipts for purchase orders, goods receipts for orders, or other movements, you can define different account grouping codes for the transaction key. Using the account grouping, you can also have different accounts for consignment liabilities and pipeline liabilities. Valuation class of material or (in case of split valuation) the valuation type The valuation class allows you to define automatic account determination that is dependent on the material. for example: you post a goods receipt of a raw material to a different stock account than if the goods receipt were for trading goods, even though the user enters the same transaction for both materials. You can achieve this by assigning different valuation classes to the materials and by assigning different G/L accounts to the posting transaction for every valuation class. If you do not want to differentiate according to valuation classes you do not have to maintain a valuation class for a transaction. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Automatic Account Assignment Transaction Keys
ECC 6.0 January 2008 Automatic Account Assignment Transaction Keys Transaction Keys The transaction keys are used to determine accounts or posting keys for line items which are created automatically by the system. The transaction keys are defined in the system. This is materials management, you want to bring in the accountants to set up the accounts Postings are made to G/L accounts automatically in the case of Invoice Verification and Inventory Management transactions relevant to Financial and Cost Accounting. Example: Posting lines are created in the following accounts in the case of a goods issue for a cost center: Stock account Consumption account How does the system find the relevant accounts? When entering the goods movement, the user does not have to enter a G/L account, since the R/3 System automatically finds the accounts to which postings are to be made using the following data: Chart of accounts of the company code If the user enters a company code or a plant when entering a transaction, the R/3 System determines the chart of accounts which is valid for the company code. You must define the automatic account determination individually for each chart of accounts. Valuation grouping code of the valuation area If the automatic account determination within a chart of accounts is to run differently for certain company codes or plants (valuation areas), assign different valuation grouping codes to these valuation areas. You must define the automatic account determination individually for every valuation grouping code within a chart of accounts. It applies to all valuation areas which are assigned to this valuation grouping code. If the user enters a company code or a plant when entering a transaction, the system determines the valuation area and the valuation grouping code. Transaction/event key (internal processing key) Posting transactions are predefined for those inventory management and invoice verification transactions relevant to accounting. Posting records, which are generalized in the value string, are assigned to each relevant movement type in inventory management and each transaction in invoice verification. These contain keys for the relevant posting transaction (for example, inventory posting and consumption posting) instead of actual G/L account numbers. You do not have to define these transaction keys, they are determined automatically from the transaction (invoice verification) or the movement type (inventory management). All you have to do is assign the relevant G/L account to each posting transaction. Account grouping (only for offsetting entries, consignment liabilities, and price differences) Since the posting transaction "Offsetting entry for inventory posting" is used for different transactions (for example, goods issue, scrapping, physical inventory), which are assigned to different accounts (for example, consumption account, scrapping, expense/income from inventory differences), it is necessary to divide the posting transaction according to a further key: account grouping code. An account grouping is assigned to each movement type in inventory management which uses the posting transaction "Offsetting entry for inventory posting". Under the posting transaction "Offsetting entry for inventory posting", you must assign G/L accounts for every account grouping, that is, assign G/L accounts. If you wish to post price differences to different price difference accounts in the case of goods receipts for purchase orders, goods receipts for orders, or other movements, you can define different account grouping codes for the transaction key. Using the account grouping, you can also have different accounts for consignment liabilities and pipeline liabilities. Valuation class of material or (in case of split valuation) the valuation type The valuation class allows you to define automatic account determination that is dependent on the material. for example: you post a goods receipt of a raw material to a different stock account than if the goods receipt were for trading goods, even though the user enters the same transaction for both materials. You can achieve this by assigning different valuation classes to the materials and by assigning different G/L accounts to the posting transaction for every valuation class. If you do not want to differentiate according to valuation classes you do not have to maintain a valuation class for a transaction. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Automatic Account Assignment Transaction Keys
ECC 6.0 January 2008 Automatic Account Assignment Transaction Keys Transaction Keys Inventory Postings BSX Offsetting Entry for Inventory Postings GBB Materials Management Small Differences DIF Cost (price) differences (PPV) PRD Goods receipt / inv. receipt clearing acct WRX This is materials management, you want to bring in the accountants to set up the accounts Postings are made to G/L accounts automatically in the case of Invoice Verification and Inventory Management transactions relevant to Financial and Cost Accounting. Example: Posting lines are created in the following accounts in the case of a goods issue for a cost center: Stock account Consumption account How does the system find the relevant accounts? When entering the goods movement, the user does not have to enter a G/L account, since the R/3 System automatically finds the accounts to which postings are to be made using the following data: Chart of accounts of the company code If the user enters a company code or a plant when entering a transaction, the R/3 System determines the chart of accounts which is valid for the company code. You must define the automatic account determination individually for each chart of accounts. Valuation grouping code of the valuation area If the automatic account determination within a chart of accounts is to run differently for certain company codes or plants (valuation areas), assign different valuation grouping codes to these valuation areas. You must define the automatic account determination individually for every valuation grouping code within a chart of accounts. It applies to all valuation areas which are assigned to this valuation grouping code. If the user enters a company code or a plant when entering a transaction, the system determines the valuation area and the valuation grouping code. Transaction/event key (internal processing key) Posting transactions are predefined for those inventory management and invoice verification transactions relevant to accounting. Posting records, which are generalized in the value string, are assigned to each relevant movement type in inventory management and each transaction in invoice verification. These contain keys for the relevant posting transaction (for example, inventory posting and consumption posting) instead of actual G/L account numbers. You do not have to define these transaction keys, they are determined automatically from the transaction (invoice verification) or the movement type (inventory management). All you have to do is assign the relevant G/L account to each posting transaction. Account grouping (only for offsetting entries, consignment liabilities, and price differences) Since the posting transaction "Offsetting entry for inventory posting" is used for different transactions (for example, goods issue, scrapping, physical inventory), which are assigned to different accounts (for example, consumption account, scrapping, expense/income from inventory differences), it is necessary to divide the posting transaction according to a further key: account grouping code. An account grouping is assigned to each movement type in inventory management which uses the posting transaction "Offsetting entry for inventory posting". Under the posting transaction "Offsetting entry for inventory posting", you must assign G/L accounts for every account grouping, that is, assign G/L accounts. If you wish to post price differences to different price difference accounts in the case of goods receipts for purchase orders, goods receipts for orders, or other movements, you can define different account grouping codes for the transaction key. Using the account grouping, you can also have different accounts for consignment liabilities and pipeline liabilities. Valuation class of material or (in case of split valuation) the valuation type The valuation class allows you to define automatic account determination that is dependent on the material. for example: you post a goods receipt of a raw material to a different stock account than if the goods receipt were for trading goods, even though the user enters the same transaction for both materials. You can achieve this by assigning different valuation classes to the materials and by assigning different G/L accounts to the posting transaction for every valuation class. If you do not want to differentiate according to valuation classes you do not have to maintain a valuation class for a transaction. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Automatic Account Assignment Modifier
ECC 6.0 January 2008 Automatic Account Assignment Modifier Modifier – modifies the transaction key for various movement types Blank – Goods receipt from purchase order with account assignment VBR – Goods issue to consumption VAX – Goods issue to sales – post to cost of goods sold AUF – Goods receipt from a production order – post to production settlement Etc. – Many others You can break them apart. Valuation class Break them out This is materials management, you want to bring in the accountants to set up the accounts What are automatic postings? Postings are made to G/L accounts automatically in the case of Invoice Verification and Inventory Management transactions relevant to Financial and Cost Accounting. Example: Posting lines are created in the following accounts in the case of a goods issue for a cost center: Stock account Consumption account How does the system find the relevant accounts? When entering the goods movement, the user does not have to enter a G/L account, since the R/3 System automatically finds the accounts to which postings are to be made using the following data: Chart of accounts of the company code If the user enters a company code or a plant when entering a transaction, the R/3 System determines the chart of accounts which is valid for the company code. You must define the automatic account determination individually for each chart of accounts. Valuation grouping code of the valuation area If the automatic account determination within a chart of accounts is to run differently for certain company codes or plants (valuation areas), assign different valuation grouping codes to these valuation areas. You must define the automatic account determination individually for every valuation grouping code within a chart of accounts. It applies to all valuation areas which are assigned to this valuation grouping code. If the user enters a company code or a plant when entering a transaction, the system determines the valuation area and the valuation grouping code. Transaction/event key (internal processing key) Posting transactions are predefined for those inventory management and invoice verification transactions relevant to accounting. Posting records, which are generalized in the value string, are assigned to each relevant movement type in inventory management and each transaction in invoice verification. These contain keys for the relevant posting transaction (for example, inventory posting and consumption posting) instead of actual G/L account numbers. You do not have to define these transaction keys, they are determined automatically from the transaction (invoice verification) or the movement type (inventory management). All you have to do is assign the relevant G/L account to each posting transaction. Account grouping (only for offsetting entries, consignment liabilities, and price differences) Since the posting transaction "Offsetting entry for inventory posting" is used for different transactions (for example, goods issue, scrapping, physical inventory), which are assigned to different accounts (for example, consumption account, scrapping, expense/income from inventory differences), it is necessary to divide the posting transaction according to a further key: account grouping code. An account grouping is assigned to each movement type in inventory management which uses the posting transaction "Offsetting entry for inventory posting". Under the posting transaction "Offsetting entry for inventory posting", you must assign G/L accounts for every account grouping, that is, assign G/L accounts. If you wish to post price differences to different price difference accounts in the case of goods receipts for purchase orders, goods receipts for orders, or other movements, you can define different account grouping codes for the transaction key. Using the account grouping, you can also have different accounts for consignment liabilities and pipeline liabilities. Valuation class of material or (in case of split valuation) the valuation type The valuation class allows you to define automatic account determination that is dependent on the material. for example: you post a goods receipt of a raw material to a different stock account than if the goods receipt were for trading goods, even though the user enters the same transaction for both materials. You can achieve this by assigning different valuation classes to the materials and by assigning different G/L accounts to the posting transaction for every valuation class. If you do not want to differentiate according to valuation classes you do not have to maintain a valuation class for a transaction. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Material Types & Valuation Classes
ECC 6.0 January 2008 Material Types & Valuation Classes Account category reference: Builds the link between material types and the valuation class(es) 0009 – Reference for Finished Products 0005 – Reference for Trading Goods 0002 – Reference for Operating Supplies 0001 – Reference for Raw Materials Account Category Reference FERT HAWA HIBE ROH Material Type 7920 3100 3030/3031 3000/3001/3002/3003 Valuation Class The valuation class has the following functions: Allows the stock values of materials of the same material type to be posted to different G/L accounts. Allows the stock values of materials of different material types to be posted to the same G/L account. Determines together with other factors the G/L accounts updated for a valuation-relevant transaction (such as a goods movement). Indicates a grouping of valuation areas to facilitate the administration of the table of standard accounts by minimizing the number of entries. Use Together with other factors, the valuation grouping code determines the G/L accounts to which a goods movement is posted ( automatic account determination). January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Material Types & Valuation Classes
ECC 6.0 January 2008 Material Types & Valuation Classes Valuation Class 3000 (Steel) Material Type ROH (Raw Material) Acct Cat. Ref 0001 – Raw Materials Valuation Class 3001 (Paper) Valuation Class 3003 (Plastics) January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 Automatic Account Assignment Plant P001 Valuation Class 3100 (Trading Good) Grouping Code G000 Goods Movement GBB (Goods Issue) Account Modifier VBR (Iss. To Cons.) Plant P002 Valuation Class 3100 (Trading Good) Grouping Code G000 Goods Movement GBB (Goods Issue) Account Modifier VBR (Iss. To Cons.) Plant P003 Valuation Class 3100 (Trading Good) Grouping Code G001 Goods Movement GBB (Goods Issue) Account Modifier VBR (Iss. To Cons.) Account 790000 Account 790001 January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 Automatic Account Assignment January 2008 Plant Material Type Points To: G/L Account Account Modifier Transaction Event Key Valuation Grouping Code Valuation Class Represented By: Chart of Accounts Additional Information Goods Movement Valuation Area Material Where Value is recorded: Why 2: Why 1: Where Valued: What: Plant – P001 HAWA Points To: 790000 VBR GBB G000 3100 Represented By: Chart of Accounts -C000 Issued to Consumption Good Issue BPEN000 Where Value is recorded: Why 2: Why 1: Where Valued: What: This example show the valuation class is 3100 Points to HAWA (trading goods) The valuation grouping code is G000 Points to Plant P000 (may point to several plants) Transaction Key is GBB – Goods Movement Account Modifier is VBR (type of goods movement for goods consumption) The affected account is January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 January 2008 Goods Receipt Materials can be received as stock items or non-stock items Receipt is possible from external or internal sources Individually / collectively Tolerance limits can be set for goods receipt Special movement type for initial inventory load If your company uses the MM Purchasing component, deliveries from vendors are most likely the result of purchase orders initiated by the purchasing department. Stock items or non-stock items Production order or external purchase orders One at a time or as a group Tolerances as mentioned earlier Loads may have special movement types. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Goods Receipt – (continued)
ECC 6.0 January 2008 Goods Receipt – (continued) Stock items can be received into restricted or unrestricted stock Non-stock items are received into orders, projects, cost centers Materials that are usually received into inventory can also be received into orders, projects, cost centers Restricted stock is stock that is not available Non-stock does not go into inventory – Costs are used against orders, projects or cost center Material can also go against cost. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Invoice Verification Set parameters for invoice verification
ECC 6.0 January 2008 Invoice Verification Set parameters for invoice verification Quantity, price, receiving date, P/O quantity Updates material master if moving average price Automatic account assignment for price differences - if allowed Verify actual versus target Rules for price differences and where are we going to post those. Materials Management, Logistics Invoice Verification has the following features: It completes the material procurement process, which started with the purchase requisition and resulted in a goods receipt. It allows invoices that do not originate in materials procurement (such as services, expenses, course costs) to be processed. It allows credit memos to be processed, either as invoice reversals or return deliveries. January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

3-Way Match Purchase order - Target quantity - - Target price -
ECC 6.0 3-Way Match January 2008 Purchase order - Target quantity - - Target price - Purchase order is matched against the invoice against the amount of the goods receipt. Purchase order defines what is expected for price and quantity Goods receipt is the actual quantity and will be matched against the PO The Invoice received from the vendor will be matched against the expected quantity from the purchase order. Invoice receipt - Actual price - Goods receipt - Actual quantity - January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Accounts Payable Settlement
ECC 6.0 January 2008 Accounts Payable Settlement Purchase Order Debit Credit Payment Program Invoice Receipt Verification Purchase order is matched against the invoice against the amount of the goods receipt. This may vary vendor to vendor according to the vendor info record. If the 3-way match is within tolerance, the payment is sent to the payment program for processing. Goods Receipt January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 Unit 11, Group 1 – Exercises January 2008 Set Default Values for Inventory Management Reservations Maintain Purchasing Tolerance Limits Maintain Goods Receipt Tolerances Maintain Invoice Receipt Tolerances Set (Review) Valuation Control Assign Valuation Area Grouping Define (Review) Valuation Classes January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

ECC 6.0 Unit 11, Group 2 – Exercises January 2008 Configure Automatic Postings for Goods Movement Configure Automatic Postings for Taxes Set Parameters for Invoice Verification Create Default Values for Invoice Verification January 2008 © SAP AG - University Alliances and The Rushmore Group, LLC All rights reserved. © SAP AG and The Rushmore Group, LLC 2008

Financial Accounting (FI)

Similar presentations

Presentation on theme: "Financial Accounting (FI)"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Financial Accounting (FI)

Similar presentations

Presentation on theme: "Financial Accounting (FI)"— Presentation transcript:

Similar presentations

About project

Feedback