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.