Parking / Holding a G/L Document Posting

In SAP ,User can be provided with Limited Authorization Amount for Posting .

For example ,an Accounting  clerk has authority to post documents to a maximum amount $5000. While feeding document he finds that the document amount is $10000  for which he does not have the authority .
In such cases, SAP has provided Park Facility for the document which allows the user to save the document but the amount is not posted in the G/L Accounts .The document can be later reviewed by High Authority Personnel who has appropriate posting amount authorization. Once approved , the document is posted in G/L Accounts. Parking documents is used when we need to get any clarification regarding some account.

Parking of document does not update the accounts. It stores the document while posting will update the accounts

The Transaction code  for Parking Documents is F-02 -> enter the required details ->go to the menu (at top )  ->Document-> Park.

To post a parked document : FBV0-> go to the menu Document-> Post.

Other TCs used pertaining to Parking of Documents are :

FV50 : Post / Delete : Single Screen Transaction
FBV2 : Change
FBV3 : Display
FBV4 : Change Header
FBV5 : Display Changes
FBV6 : Refuse 

Hold a G/L Document Posting

It is for short term and is used when transaction Dr or Cr is uncertained and generally its is used for external purpose.  eg: Advance from potential customer

A user may want to temporarily save the document under following conditions

• G/L Document is not complete
• User does not has complete or accurate information
• User wants to complete or correct the document at a later stage

Under such situations, a  document can be kept on hold without posting the document  amount in the G/L Accounts.

 

Alternative Payee

It is a payee defined at company code level, i.e. whenever any payment is made, it will go to alternative payee always in that particular company code

The payment program can make payment to a vendor other than the one to which the invoice was posted. Payment is made to an alternative payee, which must be specified in the master record.

You can specify an alternative payee in the general data area and in the company code data area. The alternative payee specified in the general data area is used by every company code. If you specify an alternative payee in both areas, the specification in the company code area has priority.

To always make vender payments to an alternative payee, proceed as follows:

• Create a vendor master record for the alternative payee. Block this account against posting.
• Specify the account number of the alternative payee in the Alternative payee field within the payment transactions section of the vendor master record.

When making payments for this vendor, the payment program will always access the name and address of the alternative payee.

In some instances it may be better to specify a payee in the document. To do this, you have to activate this function by selecting the Payee in document indicator in the general data area. When you enter documents for this account, the system displays a field in which you can enter an alternative payee.

The system always uses the payee which is most specific. This means that when you enter a payee in a document, it has priority over payees specified in the master record.

Field Status Group and issues

Error Message: Field Text is a required field for G/L account AB01 987654

While posting or reversing a MIRO transaction the above error was received.

There are two ways to solve the issue:

• Enter some text in the basic data in MIRO screen
• To avoid this error in MIRO screen, Go to FS00 and go to Create bank/ Interest and Identify the Field Status Group . Enter transaction code OBC4 and select on the Field Status Group. Click on change display icon .In the general data tab, make the text as optional and save it. The change will generate transport.

Field Status Group:

Field status groups are independent of company code, attaching instead to the field status variant. A separate variant exists in each company code for field status groups in the standard system. The name of the variant is identical to the company code. Each company code is assigned to the variant with the same name.

We are advised to work with the same field status groups in more than one company code, as outlined below:

1. Maintain field status variants
2. Assign a company code to the field status variant

Define field status outside of the master record. Mark the field status as needed for each field or field group under a field status group. Then assign the field status group to individual G/L accounts in the G/L account master records.

Integration of FI-CO

SAP is fully integrated system,therefore knowing the integration points enables  users to understand the modules in a better way

• The organization units are not only defined in FI (Company Code),It is also defined in Purchasing as Purchasing Organizations, plants and storage location. The SD modules requires the set up of Sales Organizations and Distribution Channels. The Controlling modules requires a Controlling area to be defined.
• To transfer data between FI(Financial Accounting) and CO (controlling) as well as other modules, a Company Code must be assigned to each of the Modules. 
• Document postings are automatically posted in the year and periods that you created in the Fiscal Year variant set-ups based on the month, start and end dates to which postings are allowed within a given period as defined.

Integration between FI and CO can be conducted in real time. As a result of real-time integration, all Controlling documents that are relevant for General Ledger Accounting are transferred from Controlling to Financial Accounting in real time. This means that Financial Accounting is always reconciled with Controlling. From ECC 6.0 onwards, you need not activate reconciliation ledgers in controlling.

Through this single integration solution we can avoids any need for separate cost-center ledger, reconciliation-ledger and profit-center ledger. The result is high transparency of data at all times, eliminating data redundancy and faster period-ends closings.

These are the configuration steps for Real time integration of controlling and financial accounting.

1. Define Variants for Real-Time Integration

2. Assign Variants for Real-Time Integration to Company Codes

3. Define Account Determination for Real Time Integration CO

4. Define Account Determination for Real-Time Integration


**shared as read**

SAP Customer Account Groups vs SAP Partners Function

In very broad terms:

•       Business partners are all the people or companies involved in a transaction. They may be customers, vendors (such as carriers), employees (such as CSR’s or sales people), contact people.

•       When you create a new customer master, you have to select a customer account group [master data]

•       Once the customer master is created, you assign them a partner function that identifies their roles and responsibilities within the sales transactions (transaction data)

When you create a new customer master, on the initial screen, you have to select a customer account group.

Typically, there are 4 major customer account groups important in sales

• 0001 – Sold-to Party
• 0002 – Ship-to Party or Goods Recipient
• 0003 – Payer
• 0004 – Bill-to Party

There may be and are typically more account groups. For example:

• Sales Person
• CSR
• Affiliates 

Customer Account Group----What is it?

Customer account group determines lot of things:

·         The number assigned to it

·         The customer number assigned - internal or external

·         Screens and fields status: Required, Optional or hidden

Partner functions

• A partner function refers to the rights, roles and responsibilities a business partner can take on in a business transaction. A customer account group is configured to take on one or more partner functions

Examples:

•       Sold-to party

•       Bill-to party

•       Payer

•       Ship-to party

•       Sales Budget Owner

•       Sales Rep

A customer that is created as a Sold-to party (customer account group 0001) can play different roles in a transaction.

•       They can act as the Sold-to [SP]

•       They can also act as a Ship-to [SH]

•       They can also act as a Payer [PY]

•       They can also act as a Bill-to [BP]

Partner Functions required to complete a Sales Transaction

Sold-to Party

In SAP this is the master customer. It is typically on the Order, Delivery and Billing document. A lot of data on the order defaults from the sold-to party master. Only 1 sold-to can be on an order.

Ship-to Party / Goods recipient

In SAP this is the main partner for shipping (deliveries, return deliveries, shipments). It determines where the goods will be delivered. Only 1 Ship-to can be on a delivery.

Payer

In SAP this is the main partner for billing (invoices, credit memos,..). It is also the party responsible for paying the bill. So they are important from an AR and credit management perspective. Only 1 Payer can be on an invoice.

Bill-to Party

In SAP, the Bill-to is the address that the invoice is sent to (physical or electronic). So the bill-to is also a main partner for billing. It is typical for the Bill-to to equal the Payer (but does not have to be).

Payment term: Explanation on fields

Terms of payment involves the time frame in which we pay to customers and discount rates. The configuration of terms of payments is the same for both AR and AP. The same terms of payment can be used by both Customers and Vendors. Payment terms are created at the client level and can be used across any company code.

The explanation of fields in payment terms new entry screen are as follows:

Payment terms: A four digit alpha-numeric identifier for payment term key.

Sales Text: This is the short text explanation of payment term. The entry is limited to 30 characters.

Day Limit: This field is valid only if the payment terms depend on the day of the month. For Example, The field has numeric 10 added. This means ,any invoice, billed on or before the 10^th of the month is due on the 25^th of the same month and any invoice billed after the 10^th of the month is due on 5^th of the next month.

Own Explanation:This field is used for the detailed explanation of the payment terms. This field should be used only if the system generated explanation to be overridden.

Customer: The indicator is selected if the payment term is to be used for Customer accounts (AR Module)

Vendor: The indicator is selected if the payment term is to be used for Vendors accounts (AP module)

Fixed Day: This field is used to override the system generated baseline date. Any calendar day can be added which will overwrite the system generated baseline date and be used as this date as baseline date

Additional Months: This field is used in conjunction of Fixed day field. The field is added with number of additional months to be used with the proposed fixed date as baseline date. The baseline date becomes the combination of the fixed day field and additional months field.

Block key: This field is used when the payment term propose a block key-which blocks goods issue for delivery A/R or A/P

Payment method: The field usage is to specify a specific payment method with this term of payment.

Default for Baseline Date: Select the radio button that corresponds to the baseline date we want to use when using this term of payment. You can choose between No Default, Document date, Posting date(the date that the document posts in the system, it can vary from document date or can be same),or Entry Date(The system prompts you for the baseline date when the document is entered)

Percentage: The percentage rate that is used for discount

No. Of days: Enter the number of days out from the baseline date for which the percentage discount is valid.

Fixed Date: Enter the day of the month the discount ends if the baseline date is not used

Additional Month: If we want to add month to the baseline date month to determine the length of time the discount is valid

Explanations: The system defaults an explanation of the payment term in this field based on the percentage discount and length of time the discount is valid. An entry in the Own Explanation field overwrites the system derived explanation.

GRIR account -Why it is needed

***Shared as read***

**Shared as Read **

 

The GR/IR – the goods receipt/Invoice Receipt account is used to post to whenever goods that are not yet invoiced have been received or when invoices arrive before the delivery of goods.
During the time between the invoice being created and delivery of goods, there can be a timing difference, in order to accommodate this timing difference, a GR/IR account
is maintained temporarily to record the flow .
The GR/IR clearing account is usually cleared at the end of a period or fiscal year for those order items that no further goods receipts or invoices are expected for.

Choose Logistics- Materials Management - Logistics Invoice
Verification - GR/IR Account Maintenance -Maintain GR/IR
Clearing Account.

Enter data as required on this screen in the Document header
data frame. The Automatic clearance function is intended for processing
in the background .the individual purchase order items that have quantity
variances and match your selection are now listed. Select the order items that you want to clear.
Clear the GR/IR clearing account for the selected purchase orders by choosing List - Post clearing.
The offsetting entry to clear the GR/IR account is the same as the posting made when you enter an invoice for a purchase order.
The GR/IR account is cleared against the stock account, unless no stock coverage exists. If the material stock is smaller than the quantity to be cleared, only the actual stock quantity is debited or credited proportionally. The remaining amount is posted to a price difference account.
The offsetting entry is posted to a price difference account. The offsetting entry is made to the cost or fixed asset account shown in the account assignments in the purchase order.

 

Financial Statement Version-configuration

Financial statement versions group together related accounts into Balance Sheet and Income Statement format for financial purposes.SAP uses the FSV assigned to the Company Code statement reports in the system. FSV items are similar to hierarchy nodes.

There are 4 main configuration settings that can be grouped under the heading general specification.  They are as follows

Maint. Language :The maintenance language determines the language in which FSV is kept

Item keys Auto.: This indicator specifies whether item keys are assigned automatically or manually.it is recommended that this indicator is set so that item keys are assigned automatically.

Chart of Account:Enter the Chart of Account to which this FSV relates to.

Group account number: we shall set this indicator if we wish to assign numbers from group chart of accounts instead of operating Chart of Account . Group chart of accounts are part of consolidation function. This setting is only valid if you are using the consolidation functionality of SAP.

The IMG Path for the creation of FSV is given below:
Financial Accounting->General Ledger Accounting->Business Transactions-> Closing->Documents->Define Financial Statement Versions

Transaction code : OB58


Rules for creating the financial statement version

1. The following special items (highlighted in red in the structure maintenance) have to be assigned on the second hierarchy level (directly below the root node with the description of the financial statement version):

     o  Assets
     o  Liabilities
     o  Not assigned


2. The following special items  have to be assigned below the special item Liabilities in the hierarchy:
    o  Net result: loss
    o  Net result: profit

3.The special item P+L result  can be assigned as required. However, it must not be assigned as a subnode of another special item

 

Explaination of General ledger fields:Part 2

Field Status Group: The Field Status group controls the account assignments that are made to the account. It also controls postings to cost centres , internal orders, are required, not allowed or optional.

 

Post Automatically Only: This field indicator is selected if we don’t want users posting manually to this account. When the indicator is selected, the system can only post the transactions based on configuration in the account assignment tables. Once the posting is made to this account, we need to avoid deselecting this account. If you deselect it on your inventory accounts, it could cause your G/L account to become out of balance with the material ledger.

 

 

Supplement Auto. Postings: With this indicator selected, the account assignments for line items that are generated automatically by the system  will be manually updated.

 

Rec. Acct. Ready for Input: This field denotes that recon account is ready for posting when you’re creating a document. The indicator is used for Fixed Asset reconciliation accounts.

 

Planning Level: The Planning level indicator is used in displaying the cash management position in the Treasury sub module.

 

Relevant to Cash Flow: This indicator tells the system that the account affects cash flow(receives incoming payments or sends outgoing payments)

 

House Bank: If you are creating G/L accounts for a bank account select the house bank that the G/L Account  belong to in this field.

 

Account ID: If the house bank is selected in the preceding field, the account id for the house bank to which GL belongs to is selected in this field

 

Interest indicator: If we want to calculate interest on the G/L account, select the indicator ID for the interest calculation

 

Interest Calculator Freq.: Select the ID for the interval at which the interest calculation should be run.

 

 

Key Date of Last Int.Calc.:The system updates this field with the date at which the last interest calculation was run.

 

Date of last Interest Run: The system stores the last date that interest was posted to this account.

 

 

Explanation of General Ledger Fields

Fields  that appear on the GL account company code segment are explained below:
Account currency: account currency is the currency in which account is managed.
This field should be filled with company code currency. By doing so, the account allows to post entries in any other currency in that account. If at any case, any other currency is used apart from company code currency,  the posting is restricted to that currency only.

Asset accounting : Briefing

Asset Accounting

 

Like AP and AR, Asset Accounting  is the subsidiary ledger of Financial Accounting. The appropriate general ledger are updated each time we post. There are various accounts maintained on Fixed Asset like Appreciation and Depreciation, Asset purchasing, Asset Selling , Scrapping, Transfer of Asset etc 

Procurement of services without Purchase order(related to GST)

This process is related to passing of invoices in the Finance module where the Material Management department is not involved. Invoices that will be routed through FI include insurance and other miscellaneous services.

·         These invoices will be passed through the T-code F-43 or FB60.

·         The Finance department will verify the document and update the Payables a/c that is, creating a liability. Finance will process the payment through the automatic payment program.

·         In GST regime, while booking such expenses where PO is not created, depending on the type of expenses, SAC / HSN code should be given in the input screen. For every transaction business place has to be captured, apart from business place below objects should also be captured in input screen.

Ø  GST Partner: Vendor code with whom purchase transaction is made. This is required to capture the vendor GSTIN.

Ø  Place of Supply: This is the place where actual supply of service is taken place.

Ø  Tax Code: This is required to calculate tax automatically and post into relevant GL accounts.

Ø  All the above fields will be made mandatory in FB 60 transaction code.

 

Flow of Entries:

 

Accounting entry in case of Intrastate:

 

CGST Input A/c   Dr

Expense A/c           Dr

SGST Input A/c                  Cr

 Vendor A/C                                      Cr 

  

Accounting entry in case of Interstate:

 

IGST Input Credit                              Dr

Expense A/c                                       Dr

Vendor A/c                                        Cr

Exchange Rate and Translation Ratio

This article describes the posting of invoices  in multiple currencies for the same entity. The system need customization and configuration of the conversion rate and translation ratio of currency in SAP .

Before that we need to understand about Exchange rate type. We can define exchange rate for each currency pair. The exchange rate can be differentiated through different exchange rate type.

The exchange rate type is defined in Customization under General Settings ->Currencies->Check Exchange rate types

The following exchange rate types exist

·         Buying Rate

·         Bank Selling Rate

·         Average Rate

·         Historical Exchange Rate

·         Key Date Exchange Rate

The system normally uses exchange rate type (M) average rate.

Further to this, we need to understand more about Translation Ratio. The translation ration between two currencies means how a currency can be related with each other.

SAP normally recommends 1:1 ration for each currency pair. However, in some cases, SAP has inherent round off difficulties. This generally happen when one of the currency is strong and stable and other is too weak owing to the inflationary trends and other factors prevailing in the country. 

Exchange Rates are used to maintain the relationship between two currencies and to translate an amount into other currency. It is defined at client level and therefore applies for all company codes.

Exchange rates are defined for following purposes

·         Posting and Clearing

·         Exchange Rate Differences

·         Foreign Currency Valuation

Define Translation ratios

IMG: SAP NetWeaver ->General Settings -> Currencies -> Define Translation Ratios for Currency Translation Transaction: OBBS Table: TCURF

To enable an entity, post invoices in multiple currency, after translation ratio, exchange rates need to be maintained It is very important to lock the table entries during exchange rate maintenance as per basic database design principles to avoid any data record access during update.

Exchange rates are used to find the value of a given currency with respect to other currency.      

Define Exchange rate

IMG: General Settings -> Currencies -> General Settings -> Currencies -> Enter Exchange Rate Transaction: OB08 Table: TCURR

After all these necessary configuration, we are able to receive or post invoices with Multiple currency