SAP Financials (FI)

• 
  
  
  
  Check duplicate creation of Vendor Master that have the same address data through standard SAP settings



• Validation rules in FI



• Defining Asset Number Range



• Steps to configure Document text in Customer Invoice Entry (FB70) transaction



• Understanding Lockbox



• Information on FICA (Finance and Contract Accouting)



• Comparison of FI and FICA
  
  
  
  

Check duplicate creation of Vendor Master that have the same address data through standard SAP settings

Requirement:

Check duplicate creation of Vendor Master that have the same address data through standard SAP settings.

Solution:

An information message will be shown to user when he is creating Vendor master data which will inform him that Vendors already exist with the same data in address fields. Then the Vendors with the same address will be displayed to the user. From here if he selects continue button he will be allowed to create the Vendor, if he selects the cancel button he will be given the option of making changes to the address fields.

Configuration Steps:

Goto SPRO: SAP Reference IMG:

1. Financial Accounting(New)->Accounts Receivable and Accounts Payable->Vendor Accounts->Master Data->Preparations for Creating Vendor Master Data->Change Message Control for Vendor Master Data

2. The following screen will be displayed where you can define your message for Ex:

F2 144 – Vendors found with same address; check

Set the values Online = ‘I’ and BatchI (Batch Input) = ‘I’

If you want to make this check user specific then enter the User Name else leave it blank to make it applicable for all users.

Again go to SPRO:

Financial Accounting (New)->Accounts Receivable and Accounts Payable->Vendor Accounts->Master Data->Match Code->Check Search Fields for (Vendor) Matchcodes

The standard fields on which the check is performed are:

1. NAME1

2. NAME2

3. ORT01

So when user creates a Vendor with NAME1, NAME2 & ORT01(City) fields same as an existing Vendor the system will show an Information Message. The value in these fields is automatically converted into Upper case so you do not have to worry about case- sensitivity.

When the user clicks the continue button on the message popup the Vendors having the same address data will be shown to the user & he can navigate to view the details of these vendors.

Validation rules in FI

In the SAP R/3 System, nearly all input values are validated by a program or against tables or master files. Since some types of validations cannot be standardized, you can use the validations program to create validations for your specific requirements.

The validation function enables you to check values and ranges of values as they are being entered in the SAP R/3 System. Validation rules are stored in the Rule Manager. As data is entered into the system, the Integration Manager validates the data against the validation rules. Because data is validated before it is actually posted, only valid information is posted to the FI-SL application component.

The system validates account numbers against a master file or checks that a ledger is assigned to a local company code.

You use validations when you want to create a user-defined Boolean statement to validate an entry in a way that is not defined for the standard system.

A validation can consist of up to 999 steps. You can therefore validate data against any number of Boolean statements before the data is posted.

Creating a Validation:

1. Go to transaction GGB0 and select the application area-Financial accounting from the tree menu. Select the node: Line item.

Click on the “Validation” button available on the application toolbar to create the validation and enter the following details:

Validation name: VB15_V2

Description: Validation for the tax code

Message ID: ZFGL

Call up Point: 2

Application area: FI

Click on ‘Save’.

Note: Validations can be created for all the application areas of FI available on the screen of GGB0 as shown above.

2. Now click on “Step” button on the application toolbar to create the validation step with the below details:

In the “prerequisites” sub node enter the below condition: (This validation rule should trigger only for transaction FB01,FB60,FB65,FB02,MIRO,FV60,FV65,FVB0,FBM2,FBV0,FBV2,F-01,F-44,and only for vendor line items(KOART= ‘K’)

(BKPF-TCODE = 'FB01' OR BKPF-TCODE = 'FB60' OR

BKPF-TCODE = 'FB65' OR BKPF-TCODE = ‘MIRO’ OR

BKPF-TCODE = 'FB02' OR BKPF-TCODE = 'FBM2' OR

BKPF-TCODE = 'FBV0' OR BKPF-TCODE = 'FBV2' OR

BKPF-TCODE = 'FV60' OR BKPF-TCODE = 'FV65' OR

BKPF-TCODE = 'F-01' OR BKPF-TCODE = 'F-44’) AND

(BSEG-KOART = ‘K’)

3. In the “message” sub node, enter the details of the error message that needs to be displayed.

4. Go to transaction OB28 to activate the Validation, Click on new entries and enter the following details and save:

CoCd (Company code) = VB15.

CallPnt = 0002 (Line Item).

Validation = VB15_V2

Activtn level = 1(Active).

Now Test if the validation created will trigger. Go to Transaction FB01 and try to create a vendor credit memo(With One vendor Line item: Posting Key : 21)

5. Since we have created a validation rule to trigger for company code: VB15 and only for the vendor Line item (KOART = K), the error message is displayed as below.

Defining Asset Number Range

Asset Number ranges are defined in the transaction AS08. Go to transaction AS08.

Enter the Company code and click on Intervals. Following screen appears:

As per the client requirement, we can define new number range numbers.

Now, we need to assign the number range number to asset class.

Go to transaction OAOA.

Double-click on any class.

As highlighted above, the number range has to be assigned to the Asset class.

Steps to configure Document text in Customer Invoice Entry (FB70) transaction

This article shows how to configure document header text in FB70 transaction. It uses the same text determination techniques.

Problem Statement or Requirement Details:

In transaction FB70 which is used to post Customer invoice documents, the client needs a new text id to capture the Vessel Name.

Standard SAP does not provide a screen exit for this transaction which could be used to enhance the std screen to capture the additional data in FB70 transaction.

Solution provided was to create a new document text id which can be configured in the system. This text id can be used to store the Vessel name in the text which can then be used while printing the layout.

The following screen shot shows the FB70 transaction.

As seen above, there are only three text ids currently. We will configure the third fourth text id which will appear below the “Payment Advice Information” text.

The following steps below will show how to configure the text in SPRO.

Step 1 à Goto SPRO à Financial Accounting à Financial Accounting Global Settings à Document à Document Header à Define Text ID’s for Documents.

As seen from the above screen the 3 text id selected are the ones visible on the FB70 transaction. So if you want to have your own text to be displayed click on the Create button on the application tool bar and create your own text id’s.

In our case we will create a text id with the number 0005.

Select the check box so that this text id is made available in FB70 transaction. Click on the save once done.

Since this is a customizing the system will prompt to create a customizing request.

Now if you go back to the FB70 transaction you can find the new text visible under the Document header text

User can make a entry in this field and save the document.

Click on continue and save the document.

The vessel name is now captured in the Customer Invoice document.

Understanding Lockbox

Objective of this document is to explain the meaning, purpose, advantages and disadvantages of the lockbox. This document also explains various types of formats that can be used to process the lockbox data.

What is a lockbox?

A company can create accounts called ‘lockbox’ accounts at its bank (or banks) that act as payment collection accounts for customer payments. The company then informs their customers that all open item payments for their accounts must be submitted to one of the established bank lockbox accounts. The bank collects these payments along with the customers’ remittance information that indicates what open items the customer payments intend to clear. Data entry clerks at the bank manually enter the information into an electronic file for transmission to the company to which the lockbox account belongs. These files are typically transferred nightly to the various lockbox owners (companies). The files adhere to one of two standard banking industry transmission formats: BAI, BAI2, EDI820 and EDI 823.

Advantages of Lockbox:

Lockbox process has several advantages. Some of them can be illustrated as under.

• Avoid Manual handling of checks
• Timely processing of Checks
• Easy reconciliation
• Reduction of manpower cost
• Avoid clearing Errors

What is BAI?

The standards for lockbox transmission files are defined by the Bank Administration Institute (BAI). Founded in 1924, the BAI organization is a partnership composed of its own BAI membership, a Board of Directors, various banking industry advisory groups and a professional staff. The organizational mission is “to help bank administrators achieve high levels of professional effectiveness and to help solve significant banking problems.” Activities include the definition of industry file formats, such as lockbox transmissions. BAI and BAI2 are the two defined lockbox transmission formats, however, BAI is considered ‘outdated’ by the BAI organization and is no longer supported (ie. standards are no longer updated or improved). Nonetheless, many banks still offer transmissions in the old BAI format.

BAI vs. BAI2?

BAI and BAI2 formats differ in their level of information detail. BAI does not separate out the incoming check line items by invoice subtotal reference. Instead, one check total amount simply has all invoices listed underneath it. Thus, in BAI format files, the entire check amount must match perfectly (or within configured payment difference tolerances) the total amount for all invoices listed. Otherwise, the entire check will enter into SAP as:

• an “On account” posting (if the payment and invoice totals don’t match), or
• An “Unprocessed” posting (if no customer account and documents could be identified from the transmission).

In these scenarios, your Accounts Receivable cash application clerks will have to perform manual application to clear payments against open items on the proper accounts.

Conversely, BAI2 splits the check total into separate invoice references and associated payment amounts. Thus, within a large batch, BAI2 format files will allow a “Partially applied” status in which some identifiable payments within the check total will be matched and cleared, others will land on account. As a result, your ‘hit rate’ percentage of payment-invoice matching from each transmission is likely to be higher when using BAI2 rather than BAI formats.

Electronic Data Interchange:

Network transfer of structured electronic data from one computer application to another using standard message formats. EDI is described as the interchange of structured data according to agreed message standards between computer systems by electronic means. This standard format is nothing but a Set of rules, agreed upon, accepted, and voluntarily adhered to, by which data is structured into message formats for exchange of business and operational information. Lockbox related formats are Edi 820 and 823.

EDI 820:

The 820 Payment Order/Remittance Advice transactions can be used to make a payment, send a remittance advice, or make a payment and send a remittance advice. The 820 transaction can be an order to a financial institution to make a payment to a payee. It can also be a remittance advice identifying the detail needed to perform cash application to the payee’s accounts receivable system. The remittance advice can go directly from payer to payee, through a financial institution, or through a third party agent.

EDI 823

The 823 Lockbox formats are sent by bank as confirmation of payments received from customers of lockbox owner. EDI 823 format contains information like Bank details of lockbox service provider, total quantity of checks in each format transmission, total amount involved in total checks, number of batch involved ( batch represents maximum quantity of checks in each lot). Further break up like, customer name, customer bank routing number, customer bank account number, check number and amount, number of invoices paid, amount per invoice, discounts for each invoice, deductions if any involved and credit memos etc.

Information available in these formats are generally used for clearing customer open items in SAP depends upon the business requirement. Following EDI configuration is required to read the data from corresponding format and process customer open items.

Format	Idoc type	Message type	Process code
EDI 820	Pexer2002	REMADV	REMA
EDI 823	FINSTA01	LOCKBOX	LBX

Difference between EDI 820 and 823:

In general EDI 820 formats will be used to send information to Vendor furnishing details of payment for his supplies. From business standpoint, EDI 820 information comes from customer as the business is vendor to its customer. In fact EDI 820 is not a lockbox format but can be used in place of lockbox for customer open item processing. This information however is not a real payment but only a remittance advice.

Where as lockbox format is an exclusive format that comes from bank confirming the payments received from customer. This is real payment information which got credited in business account at Lockbox /Bank. Besides this basic difference between these two formats some other differences can be summarized as under.

1. EDI 820 will have one to one information. Each customer will send remittance information to the business. EDI 823 format will have several customer information in one format.
2. Customer can not use EDI 823 format where as Bank can use EDI 820 format.
3. EDI 820 is only an advice but 823 is a payment.
4. Technical settings viz., Partner profiles, Basic type, Message type, function modules used in SAP are different between these two.
5. Level of information will be different. EDI 823 will have Total number of checks involved, total payment amount involved, break up of checks and amount per batch, per customer etc will not be available in case of EDI 820.

BAI vs. EDI in Lockbox:

Both the formats are acceptable and can be used in SAP for processing customer open items. However the earlier one is (BAI) is file based and the later format is (EDI) is idoc based. File based is batch mode and EDI is real time information. BAI can not be made as real time process but EDI can be made as batch process.

EDI technology requires mapping tool. It creates intermediate document holding the information for further process. On the other side BAI format doesn’t require this.

As far as processing and of clearing customer open items in SAP is concerned, whether the format is BAI or EDI system will follow same transactions. FB01 > FBE1 > FB05. In either of the case if information is not sufficient to clear open items, it is available for manual process.

Some additional advantages of EDI are:

• Data Accuracy
• Reduce Technical Complexity.
• Lowe Personnel needs.
• Accelerates information exchange.
• Avoid Data Entry Errors.

Lockbox Process - Data file to SAP open item clearing

What Bank will do?	Bank Receives the payments, create a data file of the customer remittance information and payment amounts, and deposit the checks into client bank account. On regular basis, Client company receives this data file for processing to update in their accounts.
What lockbox data file contain?	Depending upon the choice of services with the Bank, the lock box file will contain information viz., Customer name, Customer Number, Customer MICR number ( Bank routing and Account Number), Check amount, Invoice number, Payment date, Payment amounts and other information.
Lockbox Data Flow	As shown in the following picture, customers send their payments to a lockbox. Then bank collects the data and sends (either through EDI 820 and 823 formats) to R/3 users EDI server (standard Process). The server translates the message using as standard EDI interface into an IDOC (Intermediary documents) and sends it to the SAP Server.
What happens in SAP server	Once the message is received and stored in SAP table, a program is clicked (RFEBLB30 or FLBP transaction) to check the information stored in bank statement tables and create payment advices with Payment amount, invoice numbers and customer number.

Payment advice Processing

Matching of customer open items	The lockbox program uses detailed information from the payment advice to automatically search and match customer open items. The document number on the payment advice is matched against the document number in the customer open item file. Therefore, accurate payment data is necessary for automatic clearing to take place.
Payment Advice Status	If the checks were applied or partially applied, the advice is deleted from the system after processing. If the check was unprocessed or placed on account of customer, the advice is kept on file for further processing.
Post Processing	The post process function entails reviewing the status of the checks applied through the lock box function. User must manually clear any checks that were on-account of customer or not applied to customer account. The Lockbox overview screen details the number of checks in each category. Depending on the status of the check, the user determines what needs to occur to apply checks. On account: If the bank keyed in the correct invoice number, the Lockbox Import Program posts the payment on account. In the post processing step, you access the payment advice and correct the document number and upon saving the changes, the post process function clears the open item, deletes the payment advice and sets the check status to applied. Partially Applied: Checks that are partially applied may require further processing. Ex: Check may have paid 5 invoices, but one was in correctly keyed. The first 4 invoices would clear. The payment amount for the 5th invoice would be put on-account and would have to be post processed to clear. Unprocessed: Any payment that could not be identified either by customer MICR number (check) or the document number would remain Unprocessed. Once the payment is researched and the customer and invoice is identified, it would be applied during post processing.

What configuration needs to be done?	Control Parameters: It determines the import format BAI, BAI2 & ANSI and the types of postings generated by the lockbox program. These control parameters are needed for importing lockbox file sent by bank. Posting Data: Company code, Bank Information, G/L accounts for posting and clearing, document types and Posting keys.
RFEBLB30 or FLBP transaction	Lock Box data, Processing parameters (Procedure & Algorithm) Account assignment (Profit center), output control and Mode of call transaction.

Information on FICA (Finance and Contract Accouting)

The term FI-CA stands for “Contract accounts receivable and payable.“ FI-CA contains the range of functions needed by different industries or projects for their accounts receivable and payable management. Currently, these industries include public sector, utilities and telecommunications companies.

The common factor among these companies is a multitude of customers, which means even more open items. The number of customers in each system may go into the millions, and the number of open items several times that.

Such volumes of data can be processed by FI-CA because the memory space required for storing open and cleared items was reduced and critical activities such as posting, paying, dunning and returns processing were accelerated.



The FI-CA documents provide for the current account assignments from the following application components:

• The general ledger. Here it is the company code, business area, G/L account.
• The overhead costs Controlling and the Profitability Analysis (CO-PA). Here it is cost center, order, project, Profit Center, profitability segment.

The documents update FI-CA posting totals which are subdivided according to the account assignments named above. However, because the FI-CA documents often only differ from each other with regard to amount, business partner and contract account, a large summarization effect arises in the FI-CA posting totals. So experience from IS-U shows that several hundred thousand FI-CA document items meet on a few hundred totals records.

The FI-CA posting totals form the basis for generating G/L documents, via which not only the general ledger, but also, by transferring the corresponding Controlling account assignments, the different areas of Controlling are updated.

In addition to the account assignment characteristics of G/L accounting and Controlling, the FI-CA posting totals can be grouped according to a freely definable reconciliation key.

This reconciliation key is stored:



• in the FI-CA document header

• in the FI-CA posting totals

• in the document header of the general ledger document as external reference



This makes it possible to understand from which FI-CA documents a general ledger transfer document has been formed. This is a way in which, for instance, a reconciliation between contract accounts receivable and payable and the general ledger for a complete payment run, billing run or a given pile of FI-CA documents can be executed.

The FI-CA documents provide for the current account assignments from the following application components:



• The general ledger. Here it is the company code, business area, G/L account.

• The overhead costs Controlling and the Profitability Analysis (CO-PA). Here it is cost center, order, project, Profit Center, profitability segment.



Integration



The documents update FI-CA posting totals which are subdivided according to the account assignments named above. However, because the FI-CA documents often only differ from each other with regard to amount, business partner and contract account, a large summarization effect arises in the FI-CA posting totals. So experience from IS-U shows that several hundred thousand FI-CA document items meet on a few hundred totals records.

The FI-CA posting totals form the basis for generating G/L documents, via which not only the general ledger, but also, by transferring the corresponding Controlling account assignments, the different areas of Controlling are updated.

In addition to the account assignment characteristics of G/L accounting and Controlling, the FI-CA posting totals can be grouped according to a freely definable reconciliation key.

This reconciliation key is stored:



• in the FI-CA document header

• in the FI-CA posting totals

• in the document header of the general ledger document as external reference



This makes it possible to understand from which FI-CA documents a general ledger transfer document has been formed. This is a way in which, for instance, a reconciliation between contract accounts receivable and payable and the general ledger for a complete payment run, billing run or a given pile of FI-CA documents can be executed.



It is thus in a way a subledger of FICO. FI-CA, though not a complete subledger accounting system, it is always a component of an industry solution or a project solution.



FI-CA is first and foremost a component of the following industry solutions:



• Utilities (IS-U)

• Insurance (IS-IS/PP)

• Public sector (IS-PS)

• Tele communication (IS-T)



FI-CA mainly covers the functionality of those areas in which at least two of the industries reveal the same type of requirements. Individual requirements from exactly one industry are to be achieved as an industry solution on the basis of the FI-CA.

Difference between MTS and MTO

MTO - Make to Order

Make-to-order production with capacity checking enables vendors to trigger production of a requested product as soon as a sales order reaches the system. An automatic process checks machine capacity, schedules production, and determines the requested product’s availability date. This enables vendors to make immediate, reliable offers and commitments to their customers for the requested quantities and delivery dates. While particularly well-suited to high-tech manufacturers and makers of industrial machinery and equipment, this method also addresses the requirements of other make-to-order manufacturers.

MTS - Make to Stock

Make-to-stock production is designed for manufacturers that usually operate on the make-to-order model – configuring their finished goods after sales order entry – but that nevertheless manufacture the components of the finished goods in a make-to-stock process. The SAP best practice definition describes how manufacturers can accurately predict the future demand for components, communicate with suppliers of critical parts, and plan the production and distribution of finished goods, all based on actual material and capacity restrictions.

Comparison of FI and FICA

FI-CA: The business partner is not confined to a role on the debit side or on the credit side. This role can change in the course of time. For example: with a supplementary pension public sector there is the contribution phase and the pension payment phase.



FI: A business partner is created as a customer or vendor, which fixes its role and the functionality available with it at the outset.



FI-CA: The contract account does not automatically exist in a one-to-one relationship with a business partner and several other partners are also permitted for one account.



FI: It is only possible to have several accounts for a business partner with separate account agreements, by creating parallel customer and vendor master records.

There is no possibility of keeping one account for several business partners. A common view to the accounts of several partners is only supported in subareas (e.g. via the worklists).



FI-CA: The document of the contract accounts payable and receivable represents an all but complete business transaction relevant to accounts. It is not necessary to generate several documents if different company codes or posting data are addressed in this business transaction.

The document does not directly serve to reconcile the G/L account transaction figures.



FI: The FI document only reflects one segment of a business transaction which affects a company code and a posting date. The FI documents give a direct explanation of the general ledger transaction figures.