FINANCIALS

Handle GLPLUP Budget Upload Dump
By Rajani Putha, Accenture
Introduction: While uploading budget using Transaction GLPLUP (FI-SL: Excel Upload of Plan Data),
Sometimes we will be encountered with MESSAGE_TYPE_X’ dump errors.
Transaction: GLPLUP selection screen provided with required Plan and file path details.
Issue: When user is trying to upload Budget files by using transaction GLPLUP and this is resulting in a
dump error ‘MESSAGE_TYPE_X’.
Cause: As per standard process of this transaction GLPLUP, data has to be maintained for all the
columns in the excel file. However in current case UOM is filled only for few lines and for others it is Blank
value and hence transaction GLPLUP is throwing dump for those blank values.
Solution: To rectify this dump issue, In transaction GLGCS1 for table ‘FAGLFLEXT’ field ‘RUNIT’(Base
Unit ) we have to maintain the flag ‘Upload of initial values allowed’ as shown in below screen and this
will resolve the dump issue.
In the same way we have to maintain for other fields where the column values are initial in the budget
excel file.
Once the above configurations are performed the file will get upload successfully through GLPLUP
transaction.
FI Global Configurations
By Dheeraj Bulchandani, Accenture
Introduction:
The Documents contains the step by step procedure for configuration of FI global settings:
1. Company Code Global Parameters
2. Set Company Code to Productive
3. Maximum Exchange Rate Difference
4. VAT Registration Numbers
5. Define Document Types
6. Define Document Number Ranges for Entry View
7. Define Document Types for Ledger View
8. Tolerance Groups
9. Define Variants for Real-Time Integration
10. Assign Variants for Real-Time Integration to Company Codes
11. Account Determination for Real-Time Integration
12. Default Values
13. Default Value Date
14. Tax Procedure
Configuration Rationale
1. Company Code Global Parameters
Configuration Path:-
Financial Accounting (new) à Financial Accounting Global Settings (new)à Global Parameter for
Company Code à Enter Global Parameters (OBY6)
Configuration Screen:-
2. Set Company Code to Productive
Company Code à Set Company Code to Productive
Configuration Screen:
Comments:
We have not set the Productive Indicator of Company Code now. This will be done during the Roll-Out
phase.
3. Maximum Exchange Rate Difference
Company Code à Currencies à Maximum Exchange Rate Difference à Define Maximum Exchange Rate
Difference per Company Code
4. VAT Registration Numbers
Financial Accounting (new) à Financial Accounting Global Settings (new) à Global Parameter for
Company Code à Tax à VAT Registration Numbers (VAT Reg. No.)à Define Domestic VAT Registration
Numbers
5. Define Document Types
Financial Accounting (new)à Financial Accounting Global Settings (new) à Documentà Document Types
à Define Document Types for Entry View
6. Define Document Number Ranges for Entry View
Financial Accounting (new) à Financial Accounting Global Settings (new) à Document à Document
Number Ranges à Documents in Entry View à Define Document Number Ranges for Entry View
7. Define Document Types for Ledger View
à Define Document Types for Entry View

à Define Document Types for Entry Ledger View
Financial Accounting (new)à Financial Accounting Global Settings (new) à Documentà Document
Number Ranges à Define Document Number Ranges for General Ledger View
8. Tolerance Groups
Financial Accounting (new) à Financial Accounting Global Settings (new) à Document à Tolerance
Groups à Define Tolerance Groups for Employees
9. Define Variants for Real-Time Integration
Financial Accounting (new) à Financial Accounting Global Settings (new) à Real-Time Integration of
Controlling with Financial Accounting à Define Variants for Real-Time Integration
10. Assign Variants for Real-Time Integration to Company Codes
Controlling with Financial Accounting à Assign Variants for Real-Time Integration to Company Codes
11. Account Determination for Real-Time Integration
Controlling with Financial Accounting à Account Determination for Real-Time Integration (OK17)
12. Default Values
Financial Accounting (new) à Financial Accounting Global Settings (new) à Document à Default Values à
Enable Fiscal Year Default
13. Default Value Date
Financial Accounting (new) à Financial Accounting Global Settings (new) à Document à Default Values à
Default Value Date
14. Tax Procedure
Financial Accounting (new) à Financial Accounting Global Settings (new) à Tax on Sales/Purchases à
Basic Settings à Check Calculation Procedure
TAXGB
Basic Settings à Assign Country to Calculation Procedure
Calculation à Define Tax Codes for Sales and Purchases
We are using the SAP Standard ones for the SCOPE Template as per below screenshot
Calculation à Assign Company Code to Document Date for Tax Determination
Calculation à Tax Codes for Tax-Exempt Sales à Define Reasons
Posting à Define Tax Accounts
Posting à Assign Tax Codes for Non-Taxable Transactions
Summary:
The document explains the step by step procedure that needs to be followed for the FI Global
configuration after the individual configuration of counter parts such as Company Code , Tax Code etc is
done.
MM-FI integration in PO for handling Down Payments in SAP
Submitted by Shiva
There are new functionalities introduced by SAP from Ehp4 onwards in MM – Purchase Order.
Down Payments: User can choose to enter the DP amount or % along with the due date for the
payment. Once the PO is released, the PO can be further processed for the payment of DP w.r.t PO
using a separate report, which shows the DP against PO. The FI user can choose to change the due date
or amount, then further process the payment from the same report itself.
This functionality eliminates the manual adv. payment request or F-47/F-48transactions in SAP, which are
in isolation to PO.
This functionality eliminates the manual entries for Retention amount and helps tracking the retention
money vendor wise using a separate Special G/L indicator ‘H’.
Step1: Activate the business function: “LOG_MMFI_P2P” (Note: it’s BASIS activity)
Transaction code: SFW5
Activate the business function.
Step2: Create PO.
Transaction ME21N
Down payment can be mentioned at Header level or at item level as needed.
As of now header level DP is not fully supported, hence I am illustrating Item level DP processing.
There are 2 types of down payment categories:
a) Mandatory Down Payment – As per negotiation, down payment is must for this transaction
b) Voluntary Down Payment – Company is willing to pay down payment without any request from vendor
Select Option Mandatory Down Payment. (Note: this has no impact / control on any other transaction;
it’s only a classification of the down payment for the reporting)
Check and Save the document.
Release the PO: ME29N
Step3:
Go to the report Down payment monitoring for PO

TCode: ME2DP
This Transaction is used by FI team for monitoring and processing the DP
Use can choose the different type of selection conditions as needed.
System displays the list of PO which contains the Down payment request in PO header or item level.
Indicates DP is not yet processed
indicates DP is processed and payment made
Indicates DP is at header level
Select the required PO for processing further.

User can choose the required options
Press Enter
Save the document once Simulated.
Come back and check the status
End of process 1 Down payments in PO
Basic configuration in SAP FI to create GL accounts
By Lokesh Mohanasundaram, Wipro Tech
Introduction:
The paper gives the complete configuration required to create GL-account in SAP-FI, Right from the
definition of Company to creation of GL-account in the company code and chart of accounts with screen
shots and explanation of the entire process to make the Reader have a clear understanding of the
configuration. The process of creating an Enterprise structure begins with the definition of Company. The
various organizational units in a business are defined individually and they are assigned to each other in a
hierarchical way which forms the whole Enterprise Structure in an ERP system.
A Company:
It is said to be an organization or a corporate group which has one or many Company code under it. The
screen shots below will give the detailed step to define Company in SAP system. Most of the
configuration relating to SAP is done in SPRO (SAP Project Reference Object); follow the navigation
shown in the picture to Define Company in SAP,

The definition of the company is shown above; The Company is represented using a Four Digit numerical
character (it can also be alphanumerical) 4623 with the name Lokesh Group of Industries.
Company Code:
It is said to be the representation of an independent balancing or legal accounting entity within the
Corporate Group which can create its own financial statements; there can be ‘n’ number of company code
within a corporate group.

Choose Second option to create New Company Code and First option to Copy and create new company
with all the data from an existing Company Code.
Creation of Company Code 1000:
Company Code 1000 is created.
Creation of Company Code 2000:

Once the Creation of Company code is done they are to be assigned to the Company in SAP to achieve
the Enterprise Structure.
Company 4623- Lokesh Group of Industries

Company Code 2000- Lokesh Paper Mills
Company Code 1000- Lokesh Iron & Steel
The tabular column describes that the Company Code 1000 & 2000 are contained in the Company 4623.
The above screen shot explains the creation of the Company Code in SAP system. To achieve this
assignment of Company Code to Company the following steps are to be done
Assign Company Code to Company:

The Screen shot explains the assignment of the CC 1000 & 2000 to Company 4623. Thus a basic
Organizational Structure is achieved in the Enterprise structure. Now the Financial accounting Global
setting is explained below with configuration steps and screen shots.
Financial accounting Global Settings:
The Variant Principle:
The Variant Principle is a Three Step Method used in the SAP system to assign particular properties to
one or more objects, the steps are;
1. Define The Variant.

2. Determine Values For The Variant.
3. Assign The Variant To The Object.
Maintain Fiscal Year Variant:
A Fiscal Year or the Financial Year is usually a period of twelve months for which a company regularly
creates an inventory and financial statements. The screen shot explains the navigation and the creation of
Fiscal Year Variant. The Fiscal year variant is categorized into three types namely
1. Year Independent FYV.
2. Year dependent FYV.
3. Shortened FYV.
Year Independent:
The starting date and the ending date of the Fiscal doesn’t change according to the year, this type of
FYV is called year independent. For e.g. FY of INDIA, irrespective of the year the FYV is from APRIL 1 ST
to MARCH 31st. Creation of this type of FYV is explained below with screen shorts.
Year Dependent:
The starting date and the ending date change every year, this type of FYV which is dependent on the
year is called year dependent FYV. The FYV must be changed every year to carry out transaction. For
e.g. FY of USA, changes every year.
Shortened FYV:
This type of FYV is used to compensate the difference or the gap which occurs between FY usually this
FYV will have less than 12 periods. Usage of SFYV is shown below with business scenarios as examples.
Scenario 1: Say the FY of USA is from JAN 1 ST to NOV 31st this year (2011), and next year they use FY
from MARCH 1ST TO DEC 31ST (2012), For this type of scenario Shortened FYV is incorporated to fill the
GAP between DEC 1ST (2011) TO FEB 28TH (2012).
Scenario 2: Suppose the business of an Company starts in between there FYV say OCT 1 ST and ends at
MAR 31st so to do posting SFYV is created and used for the first year of their business.
Fiscal Year Variant ‘LO-YEAR INDEPENDENT’ is defined in the screen above, The periods of the FYV is
determined below which is a 12period & 4special posting period variant. The Fiscal year followed in India
is Year Independent which is from APRIL 1ST to MARCH 31ST irrespective of the year.
The year shift which indicates ‘-1’ is the months of last year and the year shift ‘0’ indicates the months of
the present years.
Thus the FYV is assigned to Company Code 1000 & 2000.
Note: The fiscal year variant doesn’t specify whether a period is open or closed, it only defines the
number of periods and their start & finish days.
Special Posting Period:
In order to ensure that you can compare the closing months with the other periods of the fiscal year, we
make closing posting in the special periods for e.g. 12 posting periods & 4 special posting periods. These
special posting periods could be
1. Accruals & deferrals.

2. Audit posting.
3. General meeting of share holders.
4. Adjustment Postings. Etc .
Posting Period variant:

It is responsible for the opening & closing of periods in a Fiscal year for posting to take place. You can
specify which company codes are open for posting in a posting period variant. Posting period variants are
cross-company code and you have to assign them to your company codes. The posting periods are then
opened and closed simultaneously for all company codes via the posting period variants.
Working with posting period variants is recommended if you are responsible for a large number of
company codes. Since you only have to open and close the posting period once for the variant, your work
is considerably reduced. Posting Period Variant can control posting according to the account type also.
The configuration of Posting Period variant is explained below
The Posting Period Variant is defined for the company 4623. According to the variant principle the next
step is to determine values for the variant,
Navigation is shown.
As the Screen shot explains the posting period can be maintained per account type and the year which is
to be open & closed can be easily managed. ‘+’ determines the Masked account type applicable for all the
account type, the posting is possible from 2011 to 2020 for periods 1 to 12 and the for periods 13 to 16 it
is open from 2011 to 2021.
Assign Variant to Company Code:

the variant PP46 is assigned to company code 1000 & 2000 below.
Maintain Field Status Variant:
We have to define field status outside of the master record. Mark the field status you need 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.
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 delivered system.
The variant name is the same as the company code, and each company code is assigned to this variant.
1. Maintain field status variant.

2. Determine Field status groups.
3. Assign company code to field status variant.
Definition and the navigation of the field status variant is shown below,
FS46 is created and the group are defined according to the requirement of the customer which is
explained below,
Field status group is defined according to the requirement of the customer e.g. G000 for general usage,
G001 for making cost center as an mandatory requirement at the time of posting.
Assigning FSV to Company Code:
Document Number Range:
It is defined as the specific interval within which documents should be created in SAP, Document number
range depends upon Company Code and valid only for the defined year. The configuration along with the
navigation is given below,

Document can be created from number 1 to 9999999999 for the Fiscal 2011 in CC 1000, if the
requirement of the customer is to create document number by themselves at the time of posting the
checkbox Ext (seen at the corner) must be checked. If it is not checked the system automatically picks
document number sequentially during posting.
Tolerance Group for Employees & G/L Accounts:
It is said to be the authorization given to the employees or the end user for the maximum amount
permitted per transaction. It also includes the amount of discount to be given to their customer. Normally
tolerance is created and assigned to the employees according to their designation or the authorization. It
can also be assigned to G/L accounts as well so that the maximum posting to that G/L can be restricted to
specific amount.
In the above Screen the tolerance group for CC 1000 & 2000 is seen, where the amount permitted per
line item and the discount to be given is maintained, this tolerance group is assigned to the users
accordingly.

The screen shot explains the maximum clearing difference permitted by the system per DEBIT & per
Credit and are posted automatically. Thus the basic configuration required for creating GL account is
done in the financial account Global Settings. We’ll move on the General Ledger setting for other
configurations.
General Ledger Settings:
General Ledger (G/L) Accounting is a central component in SAP Financials where monetary values
corresponding to all business transactions are recorded.
Chart of accounts:
It is a variant which contains the structure and the basic information about the general ledger accounts. It
is a list of the GL accounts maintained in an organization. We define the chart of accounts with a four digit
id. In our case COA-4623 is created and assigned to CC.
COA-4623 is created. The field Length of the G/L account number is given as 6, i.e. the maximum length
of G/L account permitted by the system for creation in this case we can create G/L from 1 to 999999.
Note: The maximum length of G/L account can be 10.
The purpose of given Automatic creation of cost elements is to create cost elements (nothing but G/L
accounts) automatically by the usage running Batch Input or else the cost elements are to be uploaded
using LSMW again.
Assign Company Code to COA:

The COA-4623 is assigned to Company Code 1000 & 2000.
Account Groups:
The process of grouping similar accounts together and assign number range to it so that it can be
identified easily is the usage of Account groups in SAP. The added advantage of this is that the Field
Status for the master data can be created at this level, so the fields which are mandatory or optional for
the creation of Master data i.e. G/L accounts can be assigned here.
The grouping of similar accounts can be seen in the above screen shot.
Retained Earnings Account:
The percentage of net earnings not paid out as dividends, but retained by the company for re-investing in
its core business or to pay off the debts is called retained earnings. It is recorded under share holder’s
equity on the balance sheet. The account in which this amount is retained is called Retained earnings
account. Creation and the navigation is shown below,
Each Profit & Loss a/c is assigned to a Retained Earnings Accounts via key. For profit and loss statement
accounts, the balance is carried forward to a retained earnings account and the profit and loss statement
account is set to zero. A key (for example, .X.) is assigned to the account to which the balance is carried
forward. You enter this key in the field "P&L Statement Type" in the chart of accounts segment.
Transaction Code = OB53 is used.
Thus the basic G/L settings is achieved by these configuration mentioned above. Now we have finished
the entire configuration required for creating GL account, so what next??
Creation of G/L Account:
The GL account is made up of two segments namely company code segment and chart of accounts
segment. Creation of G/L account can be done in three ways namely,
1. Creation of G/L account centrally-FS00.

2. Creation of G/L account in COA- FSS0.
3. Creation of G/L account in CC- FSP0.
Creation of G/L account in COA- FSS0:
This functionality gives a basic template of the GL account. The account is created with entire data
required from the COA perspective namely,
1. Account Group to which it belongs.

2. P&L a/c or Balance sheet a/c.
3. Description and other information like person created. Etc.
This can be used by all CC with same COA; in this case CC-1000 & CC-2000 can use the same GL.
Creation of G/L account in CC- FSP0:
This functionality is used to assign the Company Code relevant data to the GL account; these are
exclusively used by that CC alone namely,
1. Currency.
2. Tax relevant settings.
3. Field status group.
4. Tolerance group.
5. Authorizations. Etc.
Creation of G/L account centrally-FS00:
The purpose of creating GL account centrally is to create GL account in both the segment together, which
is shown in the screen shot below,
The creation is carried out using FS00:

Screen shot gives the overview of the field which has the COA related data.
Screen shot gives the field relating to Company Code relevant data.
A revenue account is created in CC 1000, the account number falls under the account group revenue of
4623. The Field status group G000 is assigned in the Create bank/interest tab. The G/L account-300001
revenue account of CC-1000 is created.
Result:
Thus the entire configuration required for creating a G/L account is explained with required explanations
and the relevant screen shots.
Check duplicate creation of Vendor Master that have the same
address data through standard SAP settings
By Tejaswini Das, Amaryllis Consulting Pvt Ltd
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
By Shiva Kumar Tirumalasetty, Deloitte Consulting India Pvt Ltd
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
By Vijayendra Krishnamurthy Rao, Hewlett-Packard
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
Submitted by Chandra Wipro
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
Bank Receives the payments, create a data file of the customer

remittance information and payment amounts, and deposit the
What Bank will do?
checks into client bank account. On regular basis, Client company
receives this data file for processing to update in their accounts.
Depending upon the choice of services with the Bank, the lock box
file will contain information viz., Customer name, Customer
What lockbox data file
Number, Customer MICR number ( Bank routing and Account
contain?
Number), Check amount, Invoice number, Payment date, Payment
amounts and other information.
As shown in the following picture, customers send their payments

Lockbox Data Flow
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.
Once the message is received and stored in SAP table, a program
is clicked (RFEBLB30 or FLBP transaction) to check the
What happens in SAP server information stored in bank statement tables and create payment
advices with Payment amount, invoice numbers and customer
number.
The lockbox program uses detailed information from the payment advice to
automatically search and match customer open items. The document
Matching of customer
number on the payment advice is matched against the document number in
open items
the customer open item file. Therefore, accurate payment data is necessary
for automatic clearing to take place.
If the checks were applied or partially applied, the advice is deleted from
Payment Advice
the system after processing. If the check was unprocessed or placed on
Status
account of customer, the advice is kept on file for further 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
Post Processing
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.
Control Parameters: It determines the import format BAI, BAI2 & ANSI and
What configuration the types of postings generated by the lockbox program. These control
needs to be done? 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 Lock Box data, Processing parameters (Procedure & Algorithm) Account
transaction assignment (Profit center), output control and Mode of call transaction.
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.

FINANCIALS

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FINANCIALS

Uploaded by

Copyright:

Available Formats

Handle GLPLUP Budget Upload Dump

By Rajani Putha, Accenture

1. Company Code Global Parameters

2. Set Company Code to Productive

3. Maximum Exchange Rate Difference

4. VAT Registration Numbers

5. Define Document Types

6. Define Document Number Ranges for Entry View

7. Define Document Types for Ledger View

9. Define Variants for Real-Time Integration

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

11. Account Determination for Real-Time Integration

12. Default Values

13. Default Value Date

14. Tax Procedure

1. Company Code Global Parameters

3. Maximum Exchange Rate Difference

5. Define Document Types

7. Define Document Types for Ledger View

13. Default Value Date

Transaction code: SFW5

Activate the business function.

Step2: Create PO.

Release the PO: ME29N

Go to the report Down payment monitoring for PO

This Transaction is used by FI team for monitoring and processing the DP

Use can choose the different type of selection conditions as needed.

indicates DP is processed and payment made

Indicates DP is at header level

Select the required PO for processing further.

Creation of Company Code 1000:

Company Code 1000 is created.

Creation of Company Code 2000:

Company 4623- Lokesh Group of Industries

Assign Company Code to Company:

Financial accounting Global Settings:

The Variant Principle:

1. Define The Variant.

Maintain Fiscal Year Variant:

Special Posting Period:

1. Accruals & deferrals.

Posting Period variant:

Assign Variant to Company Code:

Maintain Field Status Variant:

1. Maintain field status variant.

Assigning FSV to Company Code:

Document Number Range:

Tolerance Group for Employees & G/L Accounts:

General Ledger Settings:

Note: The maximum length of G/L account can be 10.

Assign Company Code to COA:

Retained Earnings Account:

Creation of G/L Account:

1. Creation of G/L account centrally-FS00.

Creation of G/L account in COA- FSS0:

1. Account Group to which it belongs.

Creation of G/L account in CC- FSP0:

Creation of G/L account centrally-FS00:

The creation is carried out using FS00:

Goto SPRO: SAP Reference IMG:

1. Financial Accounting(New)->Accounts Receivable and Accounts Payable->Vendor Accounts->Master

F2 144 – Vendors found with same address; check

Financial Accounting (New)->Accounts Receivable and Accounts Payable->Vendor Accounts->Master

Validation name: VB15_V2