Type of Object – Enhancement

Description – Configuration of bill of exchange Adobeforms in SPRO

Process – FI

Document Purpose

Under the check/bill of exchange procedure, the customer and not the vendor uses the bill of exchange for refinancing. This is shown in the figure below:

The chain of events is as follows:

1. The customer pays for goods with a check. At the same time, he draws a bill of exchange on which he is named as the drawee and the vendor as the drawer. He sends the check and the bill of exchange to the vendor.
2. The vendor signs the bill of exchange as the drawer and returns it to the customer.
3. The customer passes on the bill of exchange to his bank to be discounted. Although the bill of exchange is drawn on him, he uses it himself for refinancing: he is credited with an amount that he himself owes to his vendor. The bank credits him with the bill of exchange amount minus the charges and discount interest.

This document says how to configure adobeform of bill of exchange in SPRO.

Transaction FBZP

Click Payment Methods in country

For country code FR, Double click on Pmt method = 1.

In the Payment Medium, Click on Use payment medium workbench and enter Format BOE or ZBOE. We can copy BOE as ZBOE as below configuration and SAVE in Customized Request.

Financial Accounting (New) -> Accounts Receivable and Accounts Payable -> Outgoing Payments -> Automatic Outgoing Payments -> Payment Media -> Make Settings for Payment Medium Formats from Payment Medium Workbench -> Create Payment Medium Formats.

Transaction FBZP

Click Pmnt methods in company code

Double click on the Payment Method ‘1’ for the company code for which we want to do the Adodeforms

Click on Form Data

Enter the Adodeforms name and SAVE in Customized Request.

Planning function in General Ledger Accounting is use to have forecast values for Profit & Loss GL Account & Balance Sheet Accounts. Planning can be done with combination of Profit Centers against GL Accounts for a given period or for a particular fiscal year.

Steps:

A) Plan Periods:

Plan Period determines the posting periods allowed for entering plan data. Plan periods are assigned to Co. Codes.

B) Plan Versions:

Multiple Plan Versions can be created for comparision of Plan datas.

C) Assign Plan Versions to Fiscal Year & Co. Codes:

D) Activation of Line Item Planning: Activation is required for updating plan values in “FAGLFLEXP/FAGLFLEXT” table.

E) Creating Planning Profile: Planning Profile defaults the parameters for which planning is to be done. Before executing any GL Planning Planner Profile is mandatory to be assigned.

Standard Planning Profile “SAPFAGL - Planner Profile for Planning in Gen. Ledger (New)” can be copied for creating Client specific Planning Profile.

Before creating Planner Profile – GL Tables needs to be activated as below:

Tcode: GLPLINSTALL

F) Document Type for Planning:

G) Number Ranges for Plan Documents:

Above steps are the Configuration part for GL Planning with Combination of Profit Center.

TRANSACTION CODE FOR GL PLANNING:

For Setting Planner Profile Default:

Execute T Code: GP12N

Enter the Plan Values:

Document would get generated.

Table:

FAGLFLEXP/

FAGLFLEXT

gets updated with Record Type:1

Report for Plan Vs. Actual:

S_PL0_86000029

Dear All

Here I am going to create shortened fiscal year variant in SAP.

The period from which the financial records are maintained is called Fiscal Year and it is divided into posting period and each posting period has a start date and finished date and when you post any document you must have to give a valid open period to post the document.And you can also define for the year end closing.

Important Points:

A fiscal year can have maximum 12 posting periods and 4 special periods and in general purpose ledger you can define up to 366 posting periods and defining fiscal year variant is mandatory part and you can  have a fiscal year variant for several company codes.

SPRO>IMG>Financial Accounting New>FA Global Settings(New) >Fiscal Year and Posting Periods>Maintain Fiscal Year Variant (Maintain Shortened Fisc. Year)

To meet the requirement of business scenarios, we need to perform the following changes in SAP:

1. Creation of New Fiscal Year Variant, we need to copy a SAP provided Standard Variant, here we have copied from R1 TO R2

2. New variant to be made year dependant. Year dependent status to be extended for required number of past and future years to create the           number of periods in terms of month

    R2 is year Dependent, No of posting period is 12 and number of special period is 4

Click on periods

Some organizations maintain records from April to march and some from January to December and depending on requirement some make in other way.Here month column is calendar year,(English year) day is number of days in that month, period is your financial  posting period  here April is first month.After making this setting come back

Click on period text.

Click on Shortened Fiscal Years.

3. The new Fiscal Year Variant to be shortened on the basis of number of periods under consideration

Click on back button

Select the variant and click on periods

Now here give the year for which you will be going enter i.e. coming financial year

Click back button

Click on back button

Specify number of posting period, here its 6.

4. The Fiscal Year Variant to be assigned to all Co Codes involved(OB37)

Assign company code to fiscal year variant.

5. Change of Fiscal Year Variant in Controlling Area(OKKP)

6.Fiscal Year to be shortened for depreciation areas in asset accounting customization(OAYP)

7. Table T093C to be viewed to check whether the field XRUMPF(Shortend Fiscal Year) has been activated with “X”, if the field is found to be          blank then we need to refer to SAP Note 123026 and then execute program ZRUMPF, that will activate XRUMPF IN T093C

    SE11

Executive

XRUMPF(Shortened FYear) to be X means it is active now. Else we have to run note  123026

8) Recalculate Depreciation to be executed (AFAR). This will adjust the planned depreciation according to  the number of periods  in the shortened fiscal year.

9) After checking  the recalculated depreciation , Depreciation run (AFAB) and other closing activities  to be performed as per normal procedure.

RELEVANT SAP NOTES:

SAP Note 123036 to be applied for activation of field XRUMPF ( Shortened Fiscal Year ) in Table T093C.  Some of the related notes are 672255, 506622 , 484048 , 183546 , 26891 etc . SAP Note 373894 is a very important master note.

Run OBH2 and copy Number ranges to New Year and then close FI and MM Period and open new MM Period

Regards

Ashish Mishra

Contents of the Document:

This document is an attempt at analyzing the functionality of sort key in SAP.

This document provides a framework for understanding:

• What is a Sort Key

• What is the functionality of a sort key

• What are the uses of Sort Key

• General process flow for using sort key

• Example for illustrating the sort key functionality

Sort Keys:

Sort Keys are used to populate the Assignment number field in the line items of customers or vendors or general ledgers.

The content of this Assignment number field can be populated in a customer or vendor or general ledger document when the document is created:

• either manually
• or automatically by the system

Whenever a document is created, the Assignment number field in the document line items will be populated automatically, if the requisite sort keys are assigned to the customers or vendors or general ledgers master record.

Use of Sort Key - Benefits of Automatic Population of Assignment Field:

Whenever any standard reports are executed for displaying the line items of customers or vendors or general ledgers, SAP uses the content of the Assignment number field as one of the criteria to sort and display the line items.

What are the contents that can be populated automatically in the Assignment number field:

The Assignment number field of a customer or vendor or general ledger document line item can be populated automatically with the contents of one or more fields which are:

• Either the data derived from the header of the document
• Or the data derived from the line item of the document

The only requirement is that the above mentioned data proposed to be populated automatically in the Assignment number field should be available in one of the database tables – BKPF or BSEG or BSEC or BSED.

Can partial contents be populated in the Assignment number field:

The contents of the fields available in the database tables – BKPF or BSEG or BSEC or BSED can be populated automatically in the Assignment number field of the document, either completely or partially.

This can be controlled by mentioning the length of the field to be transferred in the fields – Length and Offset.

Applicability of the Sort Key logic:

The logic defined in the Sort Key is applicable across the client.

General Process Flow Describing Sort Key Functionality:

Illustration of Sort Key Functionality:

Step 1:

SAP Configuration - Define Sort Key:

The standard sort keys provided by SAP can be used to automatically populate the Assignment number field.

But custom sort keys can also be defined if the requirements of the client cannot be met with the standard sort keys available.

For example, if the standard sort key – 002 is assigned to the customer or vendor or general ledger master record, it would populate the Assignment number field of the document with the document number (BELNR) followed by the fiscal year (GJAHR).

Similarly, the standard sort key – 001, would populate the Assignment number field of the document with the posting date.

Parameters of standard sort key 002 - Screen Shot:

Parameters of standard sort key 001 - Screen Shot:

Step 2:

Master Data maintenance - for illustrating Sort Key Functionality:

Assigning Sort Key in the customer master:

In the example, the standard sort key – 001 has been assigned to the customer master.

Assignment of Sort Key in Customer Master Record - Screen Shot:

(Similar assignment can be made in the case of vendor or general ledger master record also)

Step 3:

Transactional data - for illustrating Sort Key Functionality:

Post Invoice against customer:

An invoice is posted against the customer referred above, without entering anything in the Assignment number field.

After the document is saved, if the Assignment number field is checked, it can be seen that the field is automatically populated with the posting date of the document.

In the example below, the sort key assigned in the customer master record is 001 - Posting Date.

Since the posting date of the customer invoice - 7500205569, is 07/20/2012, the Assignment number field in the document is automatically populated with the posting date in the format YYYYMMDD (20120720).

Automatic population of Assignment Number field in the customer invoice - Screen Shot:

Similarly, for subsequent documents posted, the posting date would automatically get populated in the Assignment number field.

In the example, the posting date of the document 7500208207 is 08/03/2012, and hence the Assignment number field is automatically populated as 20120803.

Similarly, the posting date of the document 7500210765 is 08/17/2012, and hence the Assignment number field is automatically populated as 20120817.

Step 4:

Transactional data - for illustrating Sort Key Functionality:

Customer Line Item Display:

When the transaction code is executed to display the customer line items, it can be observed that the line items are displayed sorted on the basis of the content of the Assignment number field.

Customer Line Item Display Report - Screen Shot:

Step 5:

Transactional data - for illustrating Sort Key Functionality:

Modify Assignment number field of the customer invoice:

The Assignment number field of the customer invoice - 7500205569 is modified manually and the content is changed from 20120720 to 20120920

Modification of Assignment Number field in Customer Invoice - Screen Shot:

Step 6:

Transactional data - for illustrating Sort Key Functionality:

Re-run Customer Line Item Display:

When the transaction code is re-executed to display the customer line items, it can be observed that the line items are displayed sorted on the basis of the content of the modified Assignment number fields.

The customer invoice - 7500205569 which was previously displayed as the first invoice in the report is currently being displayed as the third invoice, because the content of the Assignment number field has been modified.

Customer Line Item Display Report after modification of Assignment number field - Screen Shot:

Conclusion:

Based on the above discussion, it can be concluded that:

• The Assignment number field of a customer or vendor or general ledger document, if not manually populated, will be automatically populated with the data from the header or line item of the document as per the sort key assigned to the customer or vendor of general ledger master record.

• The content that will be populated in the Assignment number field will be derived from the database tables – BKPF or BSEG or BSEC or BSED.

• The customer line items are displayed in standard SAP reports after being sorted on the basis of the content of the Assignment number field.

Introduction:

When I was sent on my first assignment on starting out my career as an apprentice with an Auditing firm, the first instruction that was handed out was to cross check all the Invoices with their Purchase orders and the GR documents.

If all the documents were in place they had to be marked with a green tick. And if by any chance any instance was noticed wherein all the documents were not in place, it was a probable duplicate invoice posted in the system and it had to be marked with a red mark to be digged in further.

At that time, I used to wonder if there was any automated system to do this manual task or even better to prevent any of this from happening, it would have been great.

SAP has an answer to address this issue.

Object of the document:

This document is an attempt to analyze the issue of duplicate invoice postings and ways to prevent them.

The document covers:

• Brief introduction to Duplicate Invoices

• Possible reasons for Duplicate Invoice Postings

• Holistic approach to be adopted to prevent Duplicate Invoice Postings

• Detailed overview of the processes available in SAP to prevent Duplicate Invoice Postings

• Example illustrating the duplicate invoice check process in SAP

Duplicate Invoices:

Duplicate Invoice postings happen when a single invoice received from a vendor is posted in the system more than once and consequently paid more than once.

Reasons for Duplicate Invoice Posting:

Duplicate Invoices might be posted in the SAP system because of various reasons such as:

• Vendors sending invoices more than once because of delay in payments or misplacement of invoices
• Invoices posted twice because of simple inefficiency of accounting staff
• Duplicate Invoices posted by staff with an intention to defraud the organization

Duplicate Invoice Posting which can be prevented:

Duplicate invoice postings and consequent payments made as a result of AP staff colluding with vendors with an intention to defraud the organization would require targeted efforts to detect and prevent.

In cases other than the above, duplicate invoice postings can be prevented by adopting the inbuilt features and processes in SAP.

Holistic Approach to Prevent Duplicate Invoice Postings:

Implementing the inbuilt processes in SAP for checking Duplicate Invoice Postings will not eliminate the risk of duplicate invoice posting arising because of collusion of AP staff to commit fraud.

But it will certainly help in making the system more robust and reduce the chances of duplicate entries because of reasons other than fraud.

A holistic approach to mitigate the risk of duplicate invoice postings includes:

• Restricting the access to create vendor masters to authorized people only and preferably staff from non-AP functions
• Putting in place framework for preventing creation of duplicate vendors
• Creating a framework for identifying and blocking vendors that do not have any transactions in say, previous three months
• Making certain fields like Bank Account Number, Alternate Payee etc. in the vendor master as sensitive fields, requiring approval by authorized persons, for making changes
• Use the PO process for most, if not all procurements
• Use the three way check (Purchase Order, Goods Receipt and Invoice Verification)
• Limit the usage of Non-PO processes for procurement
• Adopting the process of parking, posting and approving of invoices by different users, to record invoices.
• Making the Header Reference Number field as a mandatory field for all the document types used for posting vendor invoices
• Making requisite configuration settings to achieve the duplicate invoice checks in case of Logistics Invoices.
• Finally, creating programs for identifying duplicate payments which have passed through despite the best efforts

Processes to be adopted in SAP to carry out a check for Duplicate Invoice Posting:

In SAP there is an inbuilt check for ensuring that duplicate invoices are not posted.

The check can be achieved by a combination of the following:

• Vendor Master data maintained with Indicator for duplicate invoices and credit memos checked
• Message to be displayed on entering a duplicate invoice should be maintained as - Error Message Type
• Additional parameters configured in SPRO to control the fields to be checked in case of Logistics Invoice Verification
• Making the Reference document number field as a mandatory field for all the document types used for posting vendor invoices
• Maintain the field - Check Flag for Double Invoices and Credit Memos (LFB1-REPRF), as mandatory, for the account groups being used for vendors

Duplicate Invoice Check – Relationship with Invoice Type:

The Duplicate Invoice check carried out by the system will depend upon whether the invoice is a:

• FI Document or
• Logistics Invoice document

Process Flow of Duplicate Invoice Check depending upon Invoice Type:

Fields checked in case of Logistics Invoice Verifiaction:

In case of Logistics Invoice, the following six fields would be checked to identify duplicate invoices in standard SAP:

• Company Code
• Vendor
• Currency
• Gross Invoice Amount
• Reference document number
• Invoice Date

Out of the above fields, there is an option available to skip the checking of any of the following three fields while trying to identify duplicate invoices:

• Company Code
• Reference document number
• Invoice Date

This can be acheived by carrying out the requisite configuration in the transaction - OMRDC.

Whether the duplicate invoice checks would consider the fields Company Code, Reference Document Number and Invoice Date would depend upon whether these fields are configured as activated or deactivated in OMRDC.

Screenshot of Duplicate Invoice Check Configuration:

Fields checked in case of FI Invoices:

The fields to be checked to identify duplicate invoices in the case of FI invoices depend upon whether the reference document number is filled or not.

Reference document number is NOT filled up:

In the cases where the reference document number field is not filled up, the following fields would be checked to identify duplicate invoices:

• Company Code
• Vendor
• Currency
• Invoice Date
• Amount in document currency

Reference document number is filled up:

In the cases where the reference document number field is filled up, the following fields would be checked to identify duplicate invoices:

• Company Code
• Vendor
• Currency
• Invoice Date
• Reference document number

Illustration of Duplicate Invoice Check:

SAP Configuration - Define the field Double invoice validation as mandatory field:

Maintaining the field status of the field - Double invoice validation as a required entry field will ensure that whenever a vendor master is created the field Check Flag for Double Invoices or Credit Memos in the Payment Data tab of the company code segment of the vendor master is always checked.

Screenshot of Field Status of Double Invoice validation field marked as mandatory:

Master data - Maintain Vendor Master:

Screenshot of Vendor Master Data:

SAP Configuration - Change Message Control:

Maintain the message - Check whether document has already been entered under number & & & as an Error message type.

This will put a hard stop to the process of duplicate invoice being posted in the system.

If the message is not maintained as an error message the system will display the message as a warning or information and allow the user to go ahead and post the duplicate invoice.

Screenshot of Error Message maintained:

SAP Configuration - Maintain Document Type:

Maintain the field - Reference Document Number (XBLNR) in all the document types used for posting vendor invoices as requiring an entry while posting invoices.

This will make the user mandatorily enter a Vendor Invoice number in the field. This will aid in the process of duplicate invoice check in the system.

Screenshot of Document Type with Reference document number field marked as mandatory:

Transactional data 1 - for illustrating Duplicate Invoice Check process:

Post an Invoice against a vendor.

In the example an invoice is posted against a vendor with the following parameters:

• Company Code - 0001
• Vendor - TESTVENDOR
• Currency - EUR
• Invoice Date - 19.12.2012
• Reference document number - DUPL1

Screenshot of Document entered

A document is posted with number 1900000005 as displayed above.

Transactional data 2 - for illustrating Duplicate Invoice Check process:

Try to post a Duplicate Invoice against the same vendor with the same parameters as already mentioned above.

In this example an invoice is tried to be posted against the same vendor with the identical input parameters as already entered for document - 1900000005:

• Company Code - 0001
• Vendor - TESTVENDOR
• Currency - EUR
• Invoice Date - 19.12.2012
• Reference document number - DUPL1

After entering the input parameters when the save button is clicked an error message is displayed - Check whether document has already been entered under number 0001 1900000005 2012

Error Message Screen Shot:

For further details and illustrations please refer to the SCN document - http://scn.sap.com/docs/DOC-35424

Introduction:

As discussed in the document - Duplicate Invoice Check - Part 1 (http://scn.sap.com/docs/DOC-35459), the duplicate invoice check is performed on the basis of a combination of configuration settings and master data maintained.

This document is an attempt to analyze the importance of checking the field - Check Flag for Double Invoices or Credit Memos in the Vendor Master, in the entire process of Duplicate Invoice Checks.

The FI Invoice posting process has been used for illustrating the importance of checking the field - Check Flag for Double Invoices or Credit Memos in the Vendor Master.

The fields to be checked to identify duplicate invoices in the case of FI invoices depend upon, whether the reference document number is filled or not.

In the example taken, the reference document number is filled up.

When a document is tried to be posted in the SAP system, in the cases where the reference document number field is filled up, the system would check the values entered in the following fields to identify duplicate invoices:

• Company Code
• Vendor
• Currency
• Invoice Date
• Reference document number

Expected Results:

If identical input parameters are tried to be entered in the system:

• If the duplicate invoice check settings are in place, then an error message will be displayed and the document would not be posted in the system

• If the duplicate invoice check settings are not in place, then the duplicate invoice would be posted in the system

Step 1: Master Data Maintained - for illustrating the Duplicate Invoice Check:

The field Check Flag for Double Invoices or Credit Memos in the Vendor Master taken in the example is Unchecked as shown in the screen shot below:

Step 2 - Transaction Data for illustrating the Duplicate Invoice Check:

An Invoice is entered in the system with the following input parameters:

A document is posted in the system under the number - 1900000006

Step 3 - Transaction Data for illustrating the Duplicate Invoice Check:

Another invoice is tried to be entered in the system with following input parameters which are identical to the input parameters used in Step 2 above:

When the Save button is clicked after entering the above mentioned input parameters, the document is saved with the number - 1900000008 as shown in the screen shot below:

Reasons for Duplicate Invoice Check Failing to prevent duplicate invoice posting:

The system has allowed the duplicate invoice to be posted because the field - Check Flag for Double Invoices or Credit Memos in the Vendor Master has not been checked.

Step 4 - Master Data maintenance for illustrating Duplicate Invoice Process:

The field - Check Flag for Double Invoices or Credit Memos in the Vendor Master has been checked as shown in the screen shot below:

Step 5 - Transaction Data for illustrating the Duplicate Invoice Check:

Another Invoice is tried to be entered in the system with the identical input parameters as used in Step 2 and 3 above after the field - Check Flag for Double Invoices or Credit Memos in the Vendor Master has been checked:

Error Message:

An error message is displayed and the duplicate invoice is not allowed to be posted in the system as shown in the screen shot below:

Conclusion:

The duplicate invoice check would identify a duplicate invoice only if the field - Check Flag for Double Invoices or Credit Memos in the Vendor Master has been checked.

The best way to ensure that the field - Check Flag for Double Invoices or Credit Memos in the Vendor Master is always checked is to make the field - Double invoice validation a mandatory field in the SPRO configuration as discussed in the SCN document -http://scn.sap.com/docs/DOC-35459.

What is Tolerance?

Minor differences between the Invoice amount and the amount received from the customers/amount paid to the vendors are a very common occurrence.

In such scenario, the following options can be adopted:

• The receipts/payments can be posted by partially clearing the invoices and creating a residual item for the difference, if the amount of difference is beyond a certain limit and is hence material

• The receipts/payments can be posted by clearing the invoices and creating a separate entry for the difference amount, if the amount of difference is within a certain limit and is hence immaterial

The above mentioned limit which controls whether a difference amount is material or immaterial is determined by the tolerance limit defined in the SAP system.

Functioning of Tolerance in SAP:

The way SAP system handles such a scenario can be controlled by carrying out relevant configurations and master data maintenance.

Step 1 - The main activity to be done for using the concept of Tolerance in SAP is:

• Analyzing the requirement for creating tolerance group

• If as per the business requirement there is a need to provide for tolerance in case of payment differences, then tolerance groups would have to be created as required

• Grouping together customers/vendors who should be assigned same tolerance limits

• Creating as many Tolerance Groups as there is a need to classify customers into different groups entitled to different tolerance limits

If there is no need to classify the customers/vendors into different groups, who are entitled to different tolerance limits, the requirement to assign tolerance group to customers/vendors can be met by creating blank tolerance group (as shown in the screenshot below).

Thus whenever any customer/vendor master is created the tolerance group in the master data can be left blank.The blank tolerance group would become automatically applicable to the customer/vendor.

Step 2 - Define Tolerance Group:

The tolerance limits would have to be defined by way of tolerance groups.

Tolerance Groups contain the details that control the way the system processes the cash discount and payment differences.

Further, the tolerance limits can be defined:

• Either as an absolute amount

• Or as a percentage of the amount received/paid

But the applicable tolerance limit would be the lower of either the absolute amount or the amount arrived at by calculating the percentage.

Tolerance Group would have to be created for Customers/Vendors and Users.

Step 3 - Assignment of Tolerance Group:

The tolerance limits would have to be assigned to the customers/vendors for each company code separately.

The tolerance limits would have to be assigned to the employees/users.

Determining the Tolerance Amount Applicable:

The tolerance which would be applicable in any scenario would be the least of the following:

• Either the absolute amount or the amount arrived at by calculating the percentage of the amount received/paid up to which payment differences are allowed to be posted for the customer/vendor as specified in the tolerance group applicable for the customer/vendor

• Or the absolute amount or the amount arrived at by calculating the percentage of the amount received/paid up to which payment differences are allowed to be posted by the user posting the invoice specified in the tolerance group applicable for the user

The maximum amounts would have to be defined separately for revenue as well as expenses.

Posting of Payment Differences:

The way the payment differences would be posted would depend upon whether:

• The payment difference amount is within the allowed cash discount tolerance amount and is a gain or

• The payment difference amount is within the allowed cash discount tolerance amount and is a loss or

• The payment difference amount exceeds the allowed cash discount tolerance amount

If the payment difference is within the maximum discount adjustment for gain/loss from payment differences, then the difference amount would be posted to the Cash Discount Adjustment account.

If the payment difference exceeds the maximum discount adjustment for gain/loss from payment differences, then the difference amount would be posted to the Payment Difference account.

Step 4 - Automatic Determination of G/L Accounts to be posted to:

The payment differences irrespective of, whether it exceeds or is within the permitted payment difference as per the tolerance groups, would have to be posted to G/L Accounts.

The G/L accounts to be posted to in both the abovementioned scenarios can be automatically determined as per the configuration settings in the SAP system.

Step 4 A - Account to be posted to in case of payment differences beyond defined cash discounts:

The General Ledger Account to which the payment difference should be posted in case it exceeds the permitted payment difference amount is assigned here:

Step 4 B - Account to be posted to in case the payment difference gain is within defined Maximum Discount Adjustment Amount for Gain from Payment Differences:

In the scenarios where the payment difference is a gain and should be adjusted to the Cash Discount Gains account, the General Ledger Account to which it should be posted is assigned here:

Step 4 C - Account to be posted to in case the payment difference loss is within defined Maximum Discount Adjustment Amount for Loss from Payment Differences:

In the scenarios where the payment difference is a loss and should be adjusted to the Cash Discount Loss account, the General Ledger Account to which it should be posted is assigned here:

Step 5 - Specification of Customer/Vendor Tolerance Group:

For each company code, the specifications for the tolerance groups for customers/vendors would have to be configured, which would control:

• the permitted payment differences in terms of either absolute amounts for gains or losses or

• the permitted payment differences in terms of percentages for gains or losses and

• the limit till which the cash discounts can be adjusted for gains or losses for customers/vendors

Step 6 - Specification of User Tolerance Group:

For each company code, the specifications for the tolerance groups for user would have to be configured, which would control:

• the permitted payment differences in terms of either absolute amounts for gains or losses or

• the permitted payment differences in terms of percentages for gains or losses and

• the limit till which the user is authorized to adjust the cash discounts for gains or losses

Step 7 - Assignment of Tolerance Group to Customer:

The tolerance group configured above shall have to be assigned to the customer master.

Step 8 - Assignment of Tolerance Group to Users:

The tolerance group configured above shall have to be assigned to the User.

Illustration of Functioning of Tolerance in SAP:

Illustration Step 1 - Post Customer Invoice:

An invoice is posted:

• against the above customer who is assigned the Blank tolerance group

• by the user shown above who is assigned the Blank tolerance group

Permitted Payment Difference as per Tolerance Group - Blank:

As per the tolerance group assigned to the customer master as well as the user, the following payment differences are permitted:

• Payment difference of an amount upto 5 EUR(as per absolute amount specified)

• Payment difference of an amount upto 10 EUR(as per % specified)

Hence the maximum permitted payment difference as per the tolerance group assigned to the customer master as well as the user is 5 EUR.

Illustration Step 2 - Post Incoming Payment with payment difference exceeding the permitted amount as per the Tolerance Group Blank:

The customer is entitled to a 2% cash discount which is EUR 40 as per the payment term assigned to the customer.

• Amount of Invoice                                                      =  EUR 2000
• Cash Discount entitlement as per payment term - 2%  =  EUR 40
• Correct amount to be received for clearing the invoice   =  EUR 1960
• Permitted payment difference                                     =  EUR 5

An incoming payment is posted against the above customer for EUR 1940 (with a payment difference amount of EUR 20, which is beyond the permissible payment difference amount or EUR 5, as per the tolerance group - Blank).

When the document is tried to be saved an error message is displayed:The difference is too large for clearing

Illustration Step 3 - Post Incoming Payment with payment difference within the permitted amount as per the Tolerance Group Blank:

Once again an incoming payment or EUR 1956 is tried to be posted against the same customer for the same invoice, but this time with a payment difference or EUR 4, which is within the permissible payment difference of 5 EUR.

The incoming payment is successfully posted against the customer, clearing the invoice.

Conclusion:

Hence it can be concluded that:

• if the payment difference exceeds the amount defined as maximum permissible payment difference as per the tolerance group assigned to the customer and user, the system will display an error message.

• if the payment difference is within the amount defined as maximum permissible payment difference as per the tolerance group assigned to the customer and user, the system automatically posts the difference to the payment difference account configured in transaction code OBXL as described above.

This article is in continuation of the matter discussed in the SCN document - Tolerance Limit - Customer or Vendor Payment Differences(http://scn.sap.com/docs/DOC-36324)

Objective of the Article:

This article is an attempt to analyze the relationship between Cash Discount Amount and the Tolerance Limits for Payment Difference.

Payment Difference Tolerance Limit - Cash Discount Amount Relationship:

The tolerance limit specified in the Tolerance Groups configured, control the Maximum Payment Differences for Revenue/Loss which will be automatically written off.

While writing off the differences the system will:

• First check whether the customer/vendor is entitled to any cash discount

• If yes, then the system will check whether the payment difference is lesser than the cash discount amount and is within the permitted payment difference, specified in the tolerance group.

• If yes, then the system will adjust the payment difference by decreasing the cash discount amount and there will be no posting to the Payment Difference Account.

• If the payment difference is greater than the cash discount amount and is within the permitted payment difference, then the system will write off the difference to the Payment Difference account.

The below mentioned illustration clarifies this concept further:

Specify Maximum Amount up to which Cash Discount should be adjusted:

The maximum amount up to which the cash discounts can be adjusted can be specified in the:

• Customer/Vendor tolerance group as well as

• User Tolerance Group

As discussed in the SCN document - Tolerance Limit - Customer or Vendor Payment Differences(http://scn.sap.com/docs/DOC-36324), the maximum permitted payment difference would be the lower of:

• the permitted amounts specified in the tolerance group assigned to the customer/vendor and

• the permitted amount specified in the tolerance group assigned to the user

As per the screen shot below the maximum amount up to which the payment difference will be adjusted against the cash discount as per the Customer/Vendor Tolerance Group is 2 EUR.

As per the screen shot below the maximum amount up to which the payment difference will be adjusted against the cash discount as per the User

Tolerance Group is 10 EUR.

Computation of amount up to which Cash Discounts will be adjusted in case of Payment Differences:

Hence in the above case, the maximum permitted amount up to which the payment difference will be adjusted against the Cash Discount Amount is the least of the following:

• the permitted amounts specified in the tolerance group assigned to the customer/vendor i.e. 2 EUR and

• the permitted amount specified in the tolerance group assigned to the user i.e. 10 EUR.

Hence when a incoming payment is posted against any customer who is assigned the Customer/Vendor Tolerance Group - Blank, by a User who is assigned the User Tolerance Group - Blank is 2 EUR.

Implications of Payment Differences exceeding/within the Cash Discount Adjustment Amount:

If the Payment Difference is:

• less than equal to 2 EUR, then the payment difference will be adjusted against the Cash Discount Adjustment amount

• greater than 2 EUR, then the payment difference will be posted to the Payment Difference Account

Post Customer Invoice:

Two identical Customer Invoices - 1800000014 and 1800000015 are posted for identical sum of EUR 1000 against the same customer who is entitled to 2% Cash Discount.

Customer Invoice 1 - 1800000014

Customer Invoice 2 - 1800000015

Customer is entitled to 2% Cash Discount if the payment is received within 14 days.

Hence if the payment is received within 14 days, then the customer is entitled to a cash discount of 20 EUR.

Incoming Payment - 1

With Payment Difference of 4 EUR (exceeding the maximum permitted amount up to which cash discount amount can be adjusted):

When and incoming payment is received against the Customer Invoice 1 (1800000014):

• within 14 days of the baseline date and

• with a payment difference which is more than the maximum permitted amount upto which the Cash Discount Amount can be adjusted,

then the payment difference will be posted to the Payment Difference Account configured.(Please refer Step 4A of the SCN document - http://scn.sap.com/docs/DOC-36324)

The payment difference amount of 4 EUR is posted to the Payment Difference Account as shown in the screen shot below:

Incoming Payment - 2

With Payment Difference of 2 EUR (within the maximum permitted amout upto which cash discount amount can be adjusted):

When and incoming payment is received against the Customer Invoice 2 (1800000015):

• within 14 days of the baseline date and

• with a payment difference which within the maximum permitted amount upto which the Cash Discount Amount can be adjusted,

then the payment difference will adjusted against the cash discount amount.

The payment difference amount of 2 EUR is adjusted against the Cash Discount Adjustment Account as shown in the screen shot below:

In this case the payment Difference of 2 EUR is adjusted against the Cash Discount Amount of 24 EUR by reducing it to 22 EUR.

No posting is done to the Payment Difference Account.

Conclusion:

While writing off the payment differences the system will check whether the payment difference is lesser than the cash discount amount and is within the permitted payment difference, specified in the tolerance group and:

• if the answer is YES, then it will adjust the payment difference by increasing/decreasing the cash discount amount and there will be no posting to the Payment Difference Account.

• if the answer is NO, then the payment difference will be posted to the Payment Difference Account.

Purpose

In this Document we will capture GL Planning/ Budgeting Process, Scenarios and requirement of an Organization.

This component is used to handle GL accounting transactions that you can Prepare Future forecast, Allocation in a Particular Department.

You can use the planning function in General Ledger accounting to enter and distribute plan data to create budgets, forecasts, and other reports.

You can quickly and easily enter large amounts of plan data. You have the following options for plan data entry:

1. You can enter amounts as plan totals that are (automatically or manually) distributed to the planning periods.
2. You can enter amounts as period amounts that are automatically totaled.
3. You can enter a combination of both totals and period amounts.

Features

Planning in General Ledger Accounting comprises the following functions:

1. You can perform planning locally. When setting up planning, you provide a framework for the individual planners and assign authorizations. You can also adapt the entry screen layout.
2. For balance sheet accounts, you can choose between planning balance sheet change values or balance sheet values.
3. For each fiscal year, you can post plan data to multiple versions.
4. You can compare actual and plan data
5. You can display totals records of your plan data.
6. You can display individual plan documents.
7. You can use allocations to allocate/distribute plan data

Planning

Planning is generally part of controlling. However, we can plan for the general ledger accounts in finance module of sap. This can be done to prepare the variance analysis within financial accounting.

Cost Center Planning

The planning application "cost center planning" enables the planning of the necessary budget of cost centers in the organizational structure of your company. You identify and value the relevant cost drivers, define manually entered prices (also called "political prices") for the internal activity allocation and enter primary and secondary costs.

Cost center planning involves entering plan figures for costs, activities, prices or statistical key figures for a particular cost center and a particular planning period. You can then determine the variances from these figures when you come to compare these plan values with the costs actually incurred. These variances (see: Variance Calculation) serve as a signal to make the necessary changes to your business processes.

Cost center planning forms part of the overall business planning process, and is a prerequisite for standard costing. The main characteristic of standard costing is that values and quantities are planned for specified time frames, independently of the actual values from previous periods.

Prerequisites

You have to activate the delivered planning application. For more information

Process Flow

The general process flow of cost center planning covers the following steps:

• Preparation: Planning cost drivers for externally related activities and the manually entered prices for internal activity allocation
• Planning of primary costs
• Planning of secondary costs
• Analysis of results in the SAP Business Information Warehouse
• Optional: Returning the plan data into the operational Cost Center Accounting of the R/3 System

Profit center Planning

Profit center planning forms is a part of corporate planning. For this reason, planning integration and reconciliation are particularly important.

Planning is a combination of top-down/bottom-up planning on several aggregation levels. The different roles of the persons involved in the planning process are reproduced with the help of various Planning Profiles, which enable a role-specific view of the existing planning objects.

Process Flow

Process Flow

The persons responsible for planning for their respective company call up their planning folder and plan revenue cost of sales, working capital, investments, and depreciation corresponding to the sequence suggested in the planning folder.

Master Data

The following profit center master data is maintained in the central master data maintenance system and distributed from there to the local systems:

1. Profit centers
2. Profit center groups
3. Account groups

Planning Program Update

Cost Center Planning

Define versions

Maintain fiscal Year -Select Version “0” and double Click on Settings for Each Fiscal Year .

Define Defined Planner Profiles

You use planner profiles to control the way planning is carried out. In a planner profile, you specify per planning area which planning layout is to be used with which default values. Per planning area, you can create as many planning layouts as you require. The profile item determines the order of the planning layouts within a planning area and can be used to assign the same planning layout to a planner profile in multiple areas, but with a different default setting each time.

Define Plan Versions

In this activity you can maintain plan versions for each ledger. For each fiscal year, you can post plan data to an unlimited number of versions.

Assign Fiscal Year to Version

In this activity, you can specify fiscal-year-dependent parameters for the plan versions of your ledgers. In so doing, you assign the desired fiscal year and posting period to your plan versions and activate them. You can also lock a plan version.

Define Plan Period

In this activity you can determine the posting periods allowed for entering planning data. You can create permitted posting periods in the form of variants, which can then be assigned to company codes.

Define Number Ranges for Plan Documents

In this IMG activity, you define the number range for your planning documents in General Ledger Accounting. You specify the following number range details for each company code:

• A number interval from which the document numbers are to be chosen
• The type of number assignment (internal or external)

Activate Line Items for Planning

In this activity you determine in the planning if summaries as well as plan line items are to be written.

And execute to update

User-Defined Planning Layouts

To be able to plan for cost elements, you first need to define the planning layout. In the planning layout, you specify the format of the planning screens.

Planning data

Display Plan Data F.01

Here Plan Version “0” used for display Plan data

Restricting/Unrestricting Fields for Substitutions and Validations

Note

This document explains the situations for FI Substitutions/Validations exclusively. The situations may or may not apply for substitutions and validations in other application areas

Introduction

Validation consists of perquisite, check and message. If the prerequisite is met and the check is not fulfilled, the message is displayed. The validation rules are activated at company code level. They are used to examine settings, say, postings from company code to business area are made or not.

Substitutions are used to substitute a document field value and consist of a prerequisite and substitution. A substitution is enforced if the prerequisite is met. Substitutions are also activated at the company code level and can be a constant value, a user exit or field-field assignment

Call-up Points and Boolean Class

There are 5 call-up points which can be used for Substitution or Validation.

1. Document Header
2. Line Item
3. Complete Document
4. Cost of Sales Accounting
5. Cost of Sales Accounting (New)

The set up for the call-up points and which Boolean classes are used for FI Validations/Substitutions details can be found in table GB31 in the system.

As seen above, the table has entries for other application areas also like Asset Management (AM), Controlling (CO) etc, but we will be only looking at the 5 entries for FI.

The 5 call-up points mentioned a little while earlier, can be found in the table for the 5 FI entries highlighted. The VALEVENTTXT gives the call-up point details corresponding to the number in the field VALEVENT.

The RCLASS or WCLASS field can be referred to know the Boolean Class for an application area and call-up point. For example, for application area FR and call-up point 2 (Line Item), Boolean class is 009. Knowing the Boolean class for an application area and call-up point combination will be necessary for reading the table GB01, explained later.

The fields GBVALUSE and GBSBSTUSE are used to define which call-up points will be used for Validations and Substitutions respectively. If the field value is blank, the call-up point does not appear in the screen to define Validations or Substitutions. The fields can have the following values:

Generally, only the values blank and X are used.

The GB31 data entries for FI look as below:

As seen, GBVALUSE has selection only for 3 call-up points with X. The value is blank for Cost of Sales Accounting and Cost of Sales Accounting (New) call-up points. Hence, when defining validations, only 3 call-up points will be available. For FI Substitutions, all 5 call-up points will be available, since, all the 5 entries have X in the GBSUBSTUSE field. This can be observed in the screen shots below:

Table GB01

Situation faced: We were trying to create a substitution that modifies the payment block field at the document line item level based on certain criteria. The development and unit testing went fine in the development system. When we transported to the test system, the pre-requisite part was displaying correctly, but, the substitution part was appearing as blank.

The above situation was because, somehow, the entries in GB01 in the development and test system were different.

The Boolean class which was read from table GB31 will be used here. For application area FI and call-up point line item, the Boolean class is 09.

The class type refers to RCLASS or WCLASS or both from GB31. The class type in GB01 is ‘B’ for Validation, ‘S’ for Substitution and ‘A’ for both Validation and Substitution.

BCLTAB, for FI application area, generally refers to tables BKPF or BSEG, the standard SAP document header and line item details tables or system fields like client, transaction code, user ID etc. The BCLFIELD has the table fields for each of the tables in BCLTAB.

BEXCLUDE determines whether the table field in BCLFIELD of BCLTAB can be used in substitutions and validations or not. The value can be blank or ‘X’. If the value is ‘X’, the field BCLFIELD of table BCLTABLE is not allowed for that particular CLASSTYPE and BOOLCLASS. If the value is blank, it is allowed.

The above screen shot shows which table and fields of the table that will be allowed for Validation and Substitution definition for the call-up point Document Header (Since the BOOLCLASS = 09). As seen, all fields (BCLFIELD = *) of table BKPF (BCLTAB = BKPF) are available (BEXCLUDE = blank) to be used in FI Validations (CLASSTYPE = B). For Substitutions (CLASSTYPE = S), in table BKPF (BCLTAB = BKPF), field BUDAT (BCLFIELD = BUDAT) is excluded (BEXCLUDE = X), whereas, field BKTXT (BCLFIELD = BTXT) is available (BEXCLUDE = blank). So, from BKPF table, field BTXT can be used for substitutions, but, BUDAT cannot be used.

In our case, the field ZLSPR (Payment Block) had BEXCLUDE = X in test system and BEXCLUDE = blank in development system for BOOLCLASS = 09 (FI application area and line item call-up point). So, the substitution worked fine in development system. But, when the transport moved to test system, since, the payment black field was not allowed in substitutions, the substitution data in the step became blank.

Modification of GB01

In order to make BUDAT field of BKPF table available for substitutions, the BEXCLUDE = X needs to be modified to BEXCLUDE = blank for that particular entry.

In standard SAP system, direct modification of GB01 is not allowed through SM30. For modifying entries of GB01, a maintenance view exists in standard SAP. The view is VWTYGB01.

The view entries are the same as GB01 and can be modified in SM30. Whatever modification is done for VWTYGB01, reflects in GB01 table.

Both GB01 and VWTYGB01 are cross client. Also, when modification is done and VWTYGB01 transported, only those entries are picked up in the TR which are changed during modification. The TR does not transport the whole table. In the system where the TR gets imported, the changes in VWTYGB01 directly reflect in the GB01 table.

So, to restrict fields or remove restriction on fields or add new tables and fields to be included in Substitutions and Validations, VWTYGB01 should be used.

Cross-Company/Inter-company transactions

Several company codes are involved in a cross-company code transaction. In a cross-company code transaction, the system posts a separate document with its own document number in each of the company codes.

Individual documents are linked by a common cross-company code number. The system generates line items automatically (receivables and payables arising between company codes) in order to balance the debits and credits in each document.

At times one company code makes purchases on behalf of another company code or makes payment on behalf of another company code. This needs entries to be passed in both company codes.

If cross company code settings are done, entry in one company code would generate the entry in the other company code also.

In this example, we have already two company codes 1009 and 1011 in country USA.

1.1 Check whether Doc type SA allows cross company postings

Select Position button and give Document type SA and press Enter

Make sure Document type SA allows Inter-company postings

1.2 Create Clearing G/L account in both company codes in FS00

Create below G/L accounts in respective company codes

1.3 Prepare Cross company code Transactions

   Provide below details and save Click on Save

Note :Alternatively, you can use Customer and vendor Posting Keys and give Inter-company Customer and Vendor numbers

1.4 Prepare Cross company code for Manual Payments

Click on New Entries

Click on Save

1.5 Prepare Cross company code for Automatic Payments

Select company code 1011 (second created Company code) and give below details:

Click on Save

1.6 Post a cross company transaction

Provide below details

Make sure to use co code 1009 on the header and co code 1011 on the line item.

Select Simulate and then Save

Click on Continue. Cross Company code document is posted.

To Display the cross company Document

Provide Cross company code document number or select from document list

Press Enter

Other Cross Company transactions i.e. Change/Display Reverse Cross Company document

1.7 Process Manual payment on behalf of other company code

Prerequisite: Make sure that there are some open items for a vendor in company code 1011 or process a vendor invoice in 1011 using FB60/F-43

Go to F-53 and provide the below details

Click on Process Open Items and Select the invoice to be paid

Document-->Simulate-->Save

Note : Alternatively, you can run Automatic Payment Program (F110) as well.

Hope this document helps

Best Regards ,

Venkat Emani

Accrual methods are normal function modules which define the logic to calculate the accruals; it can be linearly, degressively etc. SAP provides standard function modules which can be used as accrual methods in the processing of accrual objects.

How to find the standard accrual methods

The following path in IMG (transaction – SPRO) can be used to find the existing standard accrual methods.

Custom accrual method

The function modules that are used as accrual methods must have a common interface. This interface is same for all accrual methods.

Common interface parameters in accrual method

IS_ACE_KEY– This structure contains the unique key of the accrual item in the database tables of the accrual engine.

IT_GENERAL_PARAMS – This table contains the time dependent values of the accrual sub-object. 

• AMOUNT - The total value which is to be accrued.
• QUANTITY - The total quantity which is to be accrued.
• VALITY_FROM and VALITY_T – Thelife time of the accrual sub-object.
• FY_VARIANT - Fiscal year variant.

CT_PERIOD_VALUE– The entries in this table should be populated by the accrual method. Three important fields :

• VALACT  - This field has to be filled with the value that has to be accrued between the dates DATE_FROM and DATE_TO
• VALCUM - This field has to be filled with the value  that has to be accrued during the time before DATE_FROM
• VALREMAIN - This field has to be filled with the value that remains to be accrued after DATE_TO.

IT_PARAMS – This table contains the customer defined parameter values. These parameters can be used to calculate the accrual values.

• PARAM_NAME - Name of the parameter
• CONTENT -The value of this parameter

IT_COMP_SIMUPARAM_RANGES – This is used for the simulation of periodic accruals. We can use additional input fields on the entry screen of the periodic accrual report. This table will contain the entered values for these fields.

• FIELDNAME - Name of the additional input field.
• FIELDRANGE - Table with the entered select-options

ET_RETURN –This table is used to display the information and warning messages after the processing of accrual objects.

Enter Transaction code SPRO ( sap project reference object ) in the command field.

In the next screen Select SAP reference IMG( Implementation Guide )

In next screen Display IMG follow the menu path
SAP Customizing Implementation Guide – > Enterprise Structure -> Definition – > Financial Accounting – > Define Company

In the next Screen

• Press New Entries

In the next Screen Enter the Company Details :

1. Enter a unique Company Id for the Company within your corporate group.
2. Enter the Company Name.
3. In the Detailed Information Section Enter the Company Address details such as Street , PO Box, Postal Code, City.
4. Select Country code for country the company is established.
5. Select Default language for the Company for Print forms and Default Texts.
6. Select a Local Currency for the Company.

After completing all the required information , press save

Enter your customizing request number

Introduction

Bank reconciliation is a process whereby you are matching your accounting records with the bank record. At a particular point in time, your accounting record may or may not match the bank record. This is due to the time difference between recording transactions in the company’s books of account and the bank’s transaction postings. At the end of the month or at a particular time interval agreed to with the bank, the bank sends a bank statement to the company.

The company compares the bank statement with the transactions recorded in its books of account. This process may bring up the true balance with the bank, a transaction the company failed to record, or a transaction recorded by the bank that does not pertain to the company. Because of these differences the bank account as per the books of accounts may not exactly match with the bank statement.

When the company passes these entries, the main bank account balance will agree with the bank balance as per bank.

Important acronyms

BRS is Bank REconciliation Statement.

MBS Manual Bank Reconciliation Statement

EBRS is Electronic Bank Statement

BRS and MBS are one and same, these terms are used synonymously. In this document we are going to cover BRS/MBS but not EBS. 

In case if bank provides the bank statement manually or physical copy, we use manual bank reconciliation. Here we need to do the reconciliation for each transaction by transaction manually.

In case if bank provides the bank statement in electronic form, we use Electronic bank statement. In this case we can directly uploaded the statement in SAP and reconciliation happens automatically based on the configuration and predefined parameters.

Prerequisites: Before configuring Bank reconciliation statement/Manual Bank Statement, we need GL Accounts, House Bank and Check lots

Configuration

1.2 Define posting keys and posting rules for check deposit

    Provide Chart of Accounts

Click on Save

Double click on "Assign Accounts to Account symbols"

Click on New Entries and  update below details and press Enter

Alternatively, you can mask the GL accounts (e.g +++++0 for main bank account )

Click on Save

Double click on "Create Keys for Posting Rules" 

Click on  New Entries update below details and press Enter

Double click on  "Define Posting rules"

Click on  New Entries update below details and press Enter

Click on Right Arrow and update below information

Click on Right Arrow and update below information

Click on Right Arrow and update below information

Click Save

1.3 Create and assign Business Transactions

Click on  New Entries update below details

Click on Save

1.4 Define Variants for Check deposit

Place the cursor on Standard and click on Copy

And give Variant name as 1009

Click on 3-digit check number and click on Delete.

Similarly, delete 8-digit bank key and invoiced amount

Double click on “10-digit check number” under “Possible fields” as below

And change the length to 06

Variant will look like one below:

Click  Save and change description as below

Click Save and Click on activate Variant

1.5 Create and assign Business Transactions

Click on  New Entries update below details

Click on Save

Note the following when assigning the business transactions:
The +/- sign
You can further differentiate external transactions by setting "" or "-" signs for them. If the external transaction code has a "+" sign in front of it, it is a cash receipt; likewise, a "-" sign represents a cash disbursement.

Interpretation algorithm
In addition to specifying posting rules, you must also specify which interpretation algorithm should be used. The interpretation algorithm determines whether (and with which algorithms) the system should search for clearing information.

1.6 Create Variants for Manual Bank Statement

Place the cursor on Standard and click on Copy

Change the description

Click  Save and Click on Activate Variant.

2 Check Deposit Process Flow

2.1 Sales invoice posting

2.2 Manual Check Deposit

Select Settings-->Specifications and provide details

Press Enter and provide below details

Press Enter

Click on Save

Executing Batch Input

Go to Batch input session (SM35) as below

Select your Session name and click on "Process"

Select and Click on "Display Errors Only" , then select exist session 

Go to FBL5N and see whether Customer open item is cleared 

Double click on Document type DZ to see document

2.3 Manual Bank Statement

Select Settings --> Specifications and provide below details

Press Enter and provide below details

Press Enter

Click on Save

System Message : Statement/List Saved

Click on Save again

System Message : Statement/List Posted

Executing Batch Input

Go to Batch input session (SM35) as below

Select Session name and click on Process

Select and Click on "Display Errors Only", and click on Process . then click on  Exist session 

Go to FBL3N and see the posting with Document type SA

Double Click on SA document type to see document posted

3 Check Payment Transactions flow

3.1 Vendor Invoice Posting

3.2 Vendor Outgoing Payment

  Check number 100502 issued to Vendor . If you use F-53, then go to FCH5 and issues Check manually.

3.4 Manual Statement

Go to Settings --> Specifications and Provide below information

Press Enter and provide below details

Press Enter

Click on Save

System Message : Statement/List Saved

Click on Save again

System Message : Statement/List Posted

Executing Batch Input Session (SM35) as below:

Select Session name and click on Process

Select "Display errors Only"and Click on Process, then select exist session 

Go to FBL3N and Observe that Citibank Check issue account is cleared

Double click on Document type SA and see below document

3.5 Posting Bank Charges

Note: Make sure that the status of text field for Bank charges account as optional, if it is mandatory, you are going  to get an error while procession the bank charges.

Click on New Statement

Opening balance will be defaulted by the system and fill the closing balance. In this example, we want to post 1500 as bank charges. So closing balance will be

45000-43500=1500.  

Press Enter and provide below details

Note that Bank charges amount should be entered with –(minus) sign.

Click on Save

Executing Batch Input Session as below

Select Session name and click on Process

Select "Display Errors Only" and Click on Process, then select exist session

Go to FBL3N/FS10N and observe document posting in Bank charges account

Double Click on document and select overview to see document

Note1: To understand what are errors encountered during the bank statement procession, you can use transaction FEBA or FEBAN.

Note2: In case if you not sure about the opening balance of the statement to be entered in FF67, you can go to FEBA/FEBAN and see what was the closing balance of last statement. The closing balance of last statement becomes opening balance of the current statement.

Note3: There are no standard reports available on BRS in SAP similar to one given below:

Bank Statement balance                                xxxxxxxxx

+ Checks Deposited but not cleared                   xxxxxx
- Checks Issues but not cleared                         xxxxxx

Book Balance                                                xxxxxxxx

If you want a report like this, you may have to develop this report using ABAP development.

A few simple step to add new currency (ISO) code to your system.

The first you need to do is to go to SPRO >> General Settings >> Currencies >> Check Currency Codes

This is where the system stores all the currencies which required in your business transactions.

Standard settings: In SAP standard system, all currencies are defined according to the international ISO standard.

It is recommends that you use the ISO standard for your additional entries.

Entries that do not correspond to the ISO standard, will not be able to use standard data exchange in international communication (e.g. bank clearing transactions).

Let say you're required to add new currencies to the system, for example:-

Currency    CZK

Long Text   Czech Krona

Alternative key 203

Once done, save the entries

1.      1. OVERVIEW:

         The transaction FD15 is used to transfer customer master data maintained in a source company code to other target company codes. Due to run time considerations there is a selection option to select only those customers for whom company code dependent data has changed since a specific date. Only data Fields that are ready for input may be transferred, so it is recommended that the field control be the same. Execute the program in direct transfer mode and a batch input session is created and ready for processing. Customer master data can be written to a sequential and processed via transaction FD16.

F      The document is guide how to copy Customer master data from one client to another client within system.

2.      2. PROGRESS:

         - In the sender client: (Example: 500):

         Go to tcode FD15: fill your customer, company code, the change date, and specify the export file’s name

         If the file is not generated, check you change date again. It should be before the date customer is created.

         After running, the message is “File … was generated”

         - In the receiver client: (Example: 800)

         + Go to tcode FD16: fill the exactly name of file which is export from FD15, your company code as well.

         There are two method of running:

** Test Run: tick on “Check file only” option and press F8 or Execute button to execute it.

** Production Run: un-tick “Check file only” option and press F8 or Execute button to execute it.

The batch input will be generated with message:

         + Go to tcode SM35 to execute batch input.

         Check the job log after executing:

         + Check whether customers can be created in receiver client:

3.

         3. RELATE NOTES:

         Note 117464 - FK15,FK16,FD15,FD16,FS15,FS16:Log.file name missing

         Note 1180017 - Data distribution: Data loss when copying

         Note 910857 - Incorrect characters (#) in batch input session

         Note 96312 - Data distribution: Error message 00344

         Note 315362 - RFBIDE20: problem when transferring industries

1     Basis Customizing

1.1    Define and assign Credit Control Area

1.2    Define Credit Groups and assign to Order and Delivery Types

SPRO--> Sales and Distribution--> Basic Functions--> Credit Management/Risk Management--> Credit Management--> Define Credit Groups	These are SAP default values, but you may create your own as well
SPRO--> Sales and Distribution--> Basic Functions--> Credit Management/Risk Management--> Credit Management--> Assign Sales Documents and Delivery Documents	Credit limit check for order types:   D: Credit management: Automatic credit control 01: Credit Group for Sales Order
	Credit limit check for delivery types   You can add the credit group control at delivery and / or good issue level

1.4    Define Risk Categories and maintain automatic credit control

1.5.1   Prerequisites for the Automatic Credit Control

Introduction:

Whenever you use a transaction in the SAP system to process specific business transactions, it often makes sense to adjust processing flow to mirror these business activities. This can be done by hiding all information not pertinent to the business. More important information should be placed in a better position creating a transaction variant alters the layout of the screen. Transaction variants are actually made up of a series of screen variants. The field values and settings for each screen in the transaction variant are stored in a screen variant.

Transaction variants used for the below purpose:

1. Changing fields to read only(Display)
2. Making master data / transaction fields to required/Invisible
3. Inserting default values for the fields etc..

Here we will discuss with 2 simple examples:

1. Making Cost centre responsible user required while creating/changing master data
2. Making FV60/FBV2 (parked invoice) payment method field display only

Configuration:

1. Making Cost centre responsible user required: There will be always requirement for the Master data field control. In this example in order to make cost centre user responsible required we are using the transaction variant.

In the screen you have 3 tabs:

• Standard Variants – used to assign Transaction Variants to standard transaction; create and assign

Variant Groups to specifics users; this tab will be used for activating transaction variants.

• Transaction Variants – create Transaction Variants and assign Screen Variants; while process if creating transaction variants screen variants will assign automatically.
• Screen Variants – create Screen Variants. Screen variants will be created at the time of recording transaction.

Press on Create button.

Provide controlling area and other details including screen variant short text as well.

Click on enter and provide cost centre and valid from details

Press on Enter and provide screen variant text and press on enter

Provide some test data and press on enter again. You may get one more screen for screen variant short text here, Please enter short text and press on enter.

Here you will get the screen variant for user responsible. Please select ‘User Responsible’ field required.

Press on Enter till you get main screen and save.

Provide short text and save the variant in Package along with transport which you have created.

Save and press on back arrow.

Here you can see the screen variants created for the transaction variants.

We need to activate above transaction variant by going to ‘Standard variants’ tab from the same transaction.

Press on activate button and ignore warning message. Please note that this step should be performed in each client.

Do the same configuration for the transaction KS02 (Change cost centre) when anyone try to remove user responsible system say that cost centre user responsible is mandatory.

Now go to KS01 and check for new master data creation whether ‘Cost Centre user responsible field is required or not.

2.  Making FV60/FBV2 (parked invoice) payment method field display only: Sometimes business may require option that user should not modify some fields from the particular transaction. Posted document field changes can be controlled through standard configuration (document change rules) but parked document is not possible. This can be achieved through transaction variant.

Create screen variants for the transaction variant same as example1.

Record all screen variants till you get for payment method screen and make ‘payment method’ field display (Output Only).

Save screen variant in your package (transport) as mentioned in example1.

Activate created Transaction variant

Do the same config as above for the transaction FBV2 (Change parked document) and activate transaction variant.

Now you go and check for the transactions FV60 and FBV2 for the field ‘payment method’. The field should be in display only.

Note: Transaction variants should be configured in development or Golden client with the package. As a functional consultant if you have any issue in creating package please contact abaper. Transaction variants should  be activated manually in each client.

Thanks & Regards,

Prasad

Business Scenario

As we know, the Cash journal is an online cash book in SAP system. It allows you to post cash documents viz. Receipts, Payments, etc. After the posting of that journal it calculates the balance of cash remaining on hand.

Business Requirement

The company has multiple project sites and each project site is having its own Petty cash box, where day to day cash transactions are being posted.  The project sites are quite far from the HO. So they want to have a proactive measure in order to keep their cashbox full to meet their expenses.  So the requirement are as follows:

• Minimum Balance for each cash journal (based on the project site)
• Alert to HO when it reaches the Minimum Balance
• Daily Cashbook report to HO

How We Implemented

1. Define the minimum balance in Cash Journal itself.

2. Function to get the Balance

3. Report Program and Put it background to send it as email.

1. Define the minimum balance in Cash Journal itself.

As such there is no place to define the minimum balance, we used the Cash journal table 'Additional Data' field as my minimum balance data. 

Go To SPRO and

Financial Accounting (New) --> Bank Accounting --> Business Transactions --> Cash Journal --> Setup Cash Journal

There you will find a column called 'Additional Text'

2. Function to Get Balance

Use the following function to get the latest balance (as on date).

a)  Get a table of all Cash journal defined.

SELECT a~comp_code a~cajo_number b~cajo_name a~text
       FROM TCJ_C_JOURNALS as a INNER JOIN tcj_cj_names as b on a~comp_code = b~comp_code and a~cajo_number = b~cajo_number
       INTO CORRESPONDING FIELDS OF TABLE it_output where a~comp_code = '1000' and b~langu = 'EN'.

b)  Update in the internal table

Loot at it_output into wa_output.

      wa_minbal =  wa_output-text.                                     "wa_output-text  stores the minimum value you defined in cash journal (additional text).

      CALL FUNCTION 'FCJ_GET_BALANCE'

            EXPORTING

                   I_COMP_CODE           = wa_output-comp_code

                   I_CAJO_NUMBER       = wa_output-cajo_number

                   I_DATE                        = sy-datum

           IMPORTING

                  E_BALANCE                = wa_balance.

     Update the internal table with actual balance (wa_balance)  and  minimum balance (wa_minbal).

Endloop.

3. Report program and Put it in a background to send it as mail.

Write the following logic in your report program.  Define that program in SM36 in order to execute on a defined interval ( say daily ).

LOOP at it_output INTO wa_output.
wa_balance = 0.
wa_output-limit = wa_output-text.

CALL FUNCTION 'FCJ_GET_BALANCE'
  EXPORTING
    I_COMP_CODE         = wa_output-comp_code
    I_CAJO_NUMBER       = wa_output-cajo_number
    I_DATE              = sy-datum
IMPORTING
   E_BALANCE           = wa_balance.

     wa_output-balance = wa_balance.

     if wa_output-balance <= wa_output-limit.
       APPEND wa_output to it_output_final.
     endif. 

ENDLOOP.

Using the Mail function - 'SO_DOCUMENT_SEND_API1'  send it to the defined recipients.

Any company in international business today must deal in international transactions. Until a few years ago, overseas payments originating out of the US were sent via wire transfers or checks. Automated Clearing House (ACH) is an electronic fund transfer network in the US that enables financial institutions and organizations to deal in electronic payments. Domestically in the US, there is one clearing system, with standardized settlement times and initiation formats. Internationally, however, not all countries have an ACH-like clearing system, and those with clearing systems have different settlement times and formats. Earlier ACH payments used to be difficult as the sender needed to have a foreign banking relationship with the bank at the other end of the transaction, which, in turn, should have been a member of the foreign country’s clearing system.

Over the past few years, the National Automated Clearing House Association (NACHA) has worked with the Office of Foreign Assets Control (OFAC) to amend ACH operating rules, minimize vulnerabilities in the ACH network and prevent entities banned by OFAC from using the network as a conduit to send or receive overseas funds. In 2009, the NACHA International ACH Transaction (IAT) rule change included a new kind of payment system – IAT which made international payments easier, more cost effective and more secure. All participants in the ACH network – from financial institutions, ACH Operators and corporate practitioners had to comply to the new system by September 18, 2009 with the regulatory mandate.

Now international payments from and to banks in US are easily possible without having a foreign bank account. If more than a particular number of international payments are made to countries with ACH clearing systems, business can save money by making / receiving payments via IAT. Though wire transfer still remains the best payment method for immediate, non-urgent payments, IAT payment method was introduced to enhance the security of the international transactions. In addition to potential cost savings and payment security aspects IAT payments can also be used for following purposes:

• Negotiate better payment terms with vendors
• Provide better, more reliable and predictable cash flow projections
• Eliminate the necessity of maintaining multiple country specific payment formats
• Ability to combine payment categories (payroll, accounts payable and royalties) into a single payment file
• Integrate with an ERP system or in-house treasury system, providing a single-point of data entry and a single vendor / payroll master database to maintain

Key Concept

Rules and regulations governing the ACH network are established by NACHA and the Federal Reserve. An International ACH Transaction (IAT) is a debit or credit entry that is part of a payment transaction involving a financial agency not located in the territorial jurisdiction of USA. A financial agency / institution is said to be involved in the IAT transaction if it satisfies at least any of the following conditions:

• Holds an account that is credited / debited as part of a payment transaction
• Receives funds or makes payment directly as part of a payment transaction
• Serves as an intermediary in the settlement of any part of a payment transaction

This new rule applies to all ACH participants and simplifies the process of identifying international transactions by requiring that IAT entries include specific data elements defined by the Bank Secrecy Act’s (BSA) “Travel Rule”. Travel Rule ensures that specific information is provided with each payment, including the identity of all parties relevant to that transaction. This information enables a Receiving Depository Financial Institution (RDFI) to easily identify the transaction’s origin and ensures that it meets the existing requirements for file processing and complies with all applicable policies. OFAC violations regarding implementation of IAT transactions can result in judicial proceedings against the ACH receivers and originators as well as blocking of the payment itself by the originating company. Violations can also result in substantial financial implications.

This paper demonstrates the implementation process of IAT payment method in SAP R/3 ECC 6.0 system. The approach had to deviate from the standard SAP recommended solution in several aspects to get the desired results. This required several trial runs of the IAT file with the corresponding bank.

Figure 1: ACH IAT payment process

Implementation Steps of ACH IAT payment

SAP had introduced several OSS Notes for ACH IAT payment method listed below:

• SAP Note : 1343600
• SAP Note : 1362993

The overall configuration steps emphasize on the introduction of the following information in the final DME (output) file which will be eventually processed by the bank:

• Name and physical address of the originator
• Name and physical address of the receiver (beneficiary)
• Originating bank name, identification number and branch country code
• Correspondent bank name, identification number and branch country code (if applicable)
• Receiving bank name, identification number and branch country code
• Reason for the payment

SAP recommends use of Payment Medium Workbench compared to Classic Payment medium as it provides superior control, verification of the payment procedure and better performance with mass payments. It also makes it easier to adapt to a customer or bank specific formats.

Note to Payee

A new “Note to Payee” is introduced for the payment medium workbench. It suggests checking the following structures for the note:

• Note to payee layout using Customizing
• Note to payee layout using function module

As mentioned in the SAP note 1343600 the function module suggested therein - "FI_PAYMEDIUM_ACH_DETAILS" was evaluated to see whether it would meet the requirements. It may be noted here that this FM is used for processing payroll data. It was observed that this FM was suppressing the generation of a particular piece of information in the final output file – “no. of addenda record”. The payment process was attempted without this FM and was observed that the missing information was now available.

Figure 2: Note to payee configuration

IAT entries will accommodate the transmission of optional remittance information which will be used in the optional remittance addenda record. SAP note 1343600 suggests a maximum of two optional addenda records to accompany an IAT entry. In accordance with the note two line items were created with types '1' and '2' with the desired text as the default note to payee. These two line items would have been populated in the final output file as 717 record types with the desired text. As our bank wanted only a single instance of a 717 record type, only one record was retained eventually.

Figure 3: Addenda records for optional remittance information

Event Module

The DME file format – final ACH IAT output file is determined with the help of event modules. They are implemented using various function modules stacked up together to form a payment pattern. The events to call these modules are defined in the payment program (event 00) and in the payment medium program (all other events). Interfaces are determined using the various function modules. Only those parameters that are required for the DME file creation are maintained as shown below.

Figure 4: Maintenance of Event Modules

This functionality is nothing new, and has been present in SAP since DMEE was first introduced. However, it was essential to mention this feature as such, before we attempt to explain what IAT has changed, where, how and why – which is what the rest of this paper is all about.

Format parameter

The IAT method makes it mandatory for the payment transaction to state the information about the foreign correspondent bank in the output file. This bank is to be used as an intermediary between the originator and receiver’s bank through which the payment has been routed. This information will be populated in a 718 record type in the final DME file. It may be noted here that this line information (a 718 record type) is not mandatory for all banks and it would depend on whether your banking partner requires it or not. In our case, the bank made this information mandatory in the file.

Configuration of this information is not mentioned in any SAP note and this required substantial trial and error from a configuration perspective. Eventually, we figured out that all information pertaining to the foreign correspondent bank would not be populated from the payment run, but rather would have to be maintained in a variant for the payment program. This information would then be auto-populated in all the files generated out of that payment run. For our file, the mandatory fields to be maintained were:

• Company Identification
• Foreign Correspondent Bank Branch Country Code
• Foreign Correspondent Bank Name
• Foreign Correspondent Bank ID
• Foreign Correspondent Bank ID Qualifier (This field identifies the numbering scheme used in the Foreign Correspondent Bank Identification Number field.  Values for this field are :

a.    01 - National Clearing Number System

b.    02 - Business Identifier Code (BIC)

c.    03 - IBAN

Maintaining all the above as required fields in this format specific parameter would make them mandatory whenever a variant is maintained for the print program. They are maintained using transaction OBPM1. So the final DME file generated will be having these information in the line item 718 record type.

Figure 5: Format Parameter Required Fields

The information to be provided in the particular variant is shown in the section 'Variant Selection' below.

Payment method Configuration (FBZP)

In this step, the regular payment medium workbench configuration settings have been maintained for the new payment method in Country and Company Code (FBZP) referred to as ‘J’. The ‘Note to Payee’ for a payment medium is dependent on a number of factors. It is used to cover the various contents and structure requirements. The note to payee is assigned to a payment method for a certain application area. The data origin which has triggered this payment is generally highlighted in the note to payee configuration. In this case, the origin - together with the payment method - determines the structure of the note to payee. The following Note to Payee are maintained in the configuration in accordance to the specific requirement for this DME file:

• FI-AP - Note to payee for payments of vendor invoices and credit memos (such as invoice number and date)
• HR-PY - Note to payee for payment of wages (such as item text only)

Figure 6: Note to Payee by Origin

Appropriate payment advice DME structure scripts are also maintained in the payment method configuration.

Figure 7: Payment Advice script and DME scripts maintained

Instructions

Instructions help the originating company to exactly state the purpose of the international transaction. For automatic payment transactions this field along with house bank country and particular payment method control the information given to banks for carrying out the payment process. Instruction keys are maintained either in customer/vendor master record or in the system configuration for house bank. The following rule holds true: If instruction key is maintained in the vendor/customer record (sub-ledger account) then this record is preferred (gets populated in the output file) over house bank record. If no instruction key exists in the master record then default one maintained in the house bank is used. If the instruction keys are maintained in the master record during the F110 process the system will prompt for these instructions during vendor selection and proceed with the payment.

Instruction keys for house banks are maintained per country and payment method using transaction OB47. The instruction key have been maintained for country US and payment method ‘J’ – ACH IAT. Instruction key is maintained as 01 for this payment method. This has to be maintained in the first place in order to maintain the range of payment instructions for the DME file. 

Figure 8: Instruction key format for the payment method

Instruction keys 1,2,3,4 are used to cater to the requirements of specific countries like Germany, Austria, Japan and Netherlands where additional information are required mostly for foreign payments. They can also be used to generate additional information for other transactions as well. They are only used for additional information and may not be maintained if not required. These four fields can be overridden by giving instruction keys while posting a document (“Additional Data” screen in the customer/vendor line)

Actual reasons for the payments – the range of instructions are needed to be maintained per country. They are not pre-configured but have to be maintained for each country defined previously. For bank country US the following instructions are maintained:

Figure 9:  Instructions for payments

These instruction keys are used during document creation. Only one instruction key is allowed per invoice. Its’ corresponding information will be transferred to addenda record 7 in the final DME file. It is to be noted that we may need to adjust field status for the additional screen in case the keys are not already available.

Variant Selection

The payment program is run using a variant which needs to be maintained for the ACH payment. This variant is maintained for the particular Company Code and the House Bank from which payment needs to be made. In this example payment is made using sample Company Code – US01 and sample House Bank - BNYDL. Thus in OBPM4 screen variant TEST is maintained accordingly.

Figure 10: Creation of variant for the payment run

While maintaining the payment medium format the system asks for the Corresponding Bank Information to be maintained simultaneously (which have been earlier maintained as mandatory).

Figure 11: Maintenance of Foreign Correspondent Bank Information

The important parameter is “Company Identification” which is generally the tax number or some other free number used by the company. One particular identification number is agreed between the company and the bank. The pre-agreed information is populated real time in the output DME file during program execution.

Along with the maintenance of the payment medium format some other important parameters are maintained simultaneously as shown below:

• Data Medium Exchange
• Payment Summary
• Error Log
• Appropriate file path for the output file storage
• Form for the payment medium

Payment Transaction

During document (invoice) entry, an appropriate reason of the invoice should be given. In most real-world setups that we analyzed, this instruction function was found suppressed during invoice entry. Instructions can be defined at any of the following places:

• The (invoice) document
• The customer/vendor master record using an instruction key
• The house bank DME data using the default instruction key

The instructions specified in the document over-ride any other instruction keys available from any master data, provided that one of the four fields (see figure no. 12 below) has been filled out. The instruction key is linked with the corresponding GL account involved with this transaction. In the case of a vendor invoice document, this GL would be the corresponding reconciliation account. When the field status of the instruction key is modified for the reconciliation account category (see figure no. 11 below), then the instruction key will appear on the payment screen.

Figure 12: Instruction Key field made optional

Now appropriate instructions given during the document entry process.

Figure 13: Appropriate payment instructions provided

Download Settings

After a successful payment run when the output file was downloaded it was observed that the output file is coming in the following format:

Figure 14: Initial IAT output file

Here the system is adding an unwanted space between each character of the file. Eventually, I figured out that appropriate character encoding system needed to be set up for the downloadable DME file. In this case, UTF-8 (UCS Transformation Format – 8 bit), which  is a variable-width encoding representing every character in the Unicode character set needed to be defined. In SAP, the UTF-8 character encoding has code page number 4110. Once this was maintained in OBPM3 as shown below, the extra spaces disappeared.

Figure 15: Appropriate Code Page maintenance for the format

Output File

Finally after the document payment process the final output file gets created in the appropriate location in the directory. A sample final DME file is shown below:

Figure 15: Appropriate Code Page maintenance for the format

The final output DME file gets its data from various master and transactional tables. Like any other regular payment process in SAP, after a successful payment process all the related information gets populated in the REGU*tables. The file refers master data tables like T001, ADRC, LFA1 and KNA1. Information related to the payer and receiver’s banks are populated using the BNKA table. The information related to Foreign Correspondent Bank is populated real time during file generation. Some information is hardcoded by the standard SAP program. Detailed analysis of each line item of the file is shown below. Although a general ACH IAT file format exists, the required information varies depending on the actual Bank involved. For certain banks, certain fields and in some cases complete line items are omitted as those data fields are not necessary for that bank. I will cover some of the important data fields in the line items along with how they get populated. This will help in trouble-shooting for the reader

Header: File header record introduces the file. It designates the physical file characteristics and identifies the sender and the receiver of the file. This record starts with record type 1.

• Position 4-13 is the bank routing number or the house bank number populated from table REGUH (field UBNKL)
• Position14-23 gives the company identification which is used for creating the ACH file. The particular identification to be used is mutually decided between the bank and the company. This information is maintained in the program variant which gets populated real time to the output file
• This record also introduces the date, time and the file identification fields to specifically identify a particular file. They are populated from REGUT table (fields TSDAT and TSTIM)
• It also populates the immediate originating bank name from BNKA (field BANKA) and the originating company name from T001(field BUKRS)

Company / Batch Header Record: Identifies the originator and briefly describes the purpose of the entry. This record starts with record type 5.

• Position 41-50 populates the originator bank id
• Position 54-63 gives the description of the purpose of the entry. In this case it is "VENDOR PMT" (Vendor Payment). These values are maintained in the program variant and gets populated real time during program execution.
• Position 64-69 gives the ISO 4217 code for the originating and destination currency.
• Position 80-87 incorporates the routing number or the bank number from REGUH (field UBNKL) but here only first eight characters get populated

IAT Entry Detail record – Original Entry: This record contains information about the receiver and receiver’s financial institution. It starts with record type 6.

• Position 04-12 contains the routing number that identifies the US RDFI in which the receiver maintains the account. It populates from REGUH table(field ZBNKL)
• Position 13-16 gives the number of addenda records with the entry details record i.e. the number of line items starting with 7 and 8 present in the file. This value was getting suppressed when the function module "FI_PAYMEDIUM_ACH_DETAILS" was activated as mentioned previously
• Position 30-39 gives the document amount from REGUH table(field RBETR)
• Position 40-74 gives the foreign receiver’s account number from REGUH table (field ZBNKN)
• Position 80-94 is the trace number assigned by ODFI to uniquely identify each entry within a batch.

Receiver Information 1: IAT Addenda Record 710 identifies the receiver of the transaction and the dollar amount of payment.

Position 04-06 identifies the type of transaction which gets populated from the instruction field while submitting an invoice. The instruction codes get stored from the REGUH table in field DTWS1. It takes this value and goes to table T015W1 and matches this value with value in field DTWSX for the specified application area. Then the system populates the corresponding information in field CODE. For inbound payments along with the options available a secondary SEC code may also be used.

Position 47-81 populates the name of the receiver / vendor from the REGUH table(field KOINH) 

Originator Information: Addenda Records 711 and 712 contain information related to the originator of the entry. They contain the originator name and it's detailed address. To populate these two rows system links two tables - T001 and ADRC. For the originator company code the system goes to the master table T001 and picks up the value from the field ADRNR. The system maps this value in table ADRC with field (ADDRNUMBER) and populates the relevant fields in the output file.

Originating Financial Institution: Fourth IAT Addenda Record line item is populated with record 713. This contains information of the financial institution originating the entry.

• Position 04-38 contains the name of the foreign originating DFI for an inbound IAT entry.
• Position 41-74 contains the original DFI Identification number
• Position 75-77 contains the identity of the country in which the bank branch where the entry originated is located.

All the entries are populated from the BNKA table.

Receiving Depository Financial Institution: Fifth IAT Addenda Record line item is populated in record numbers 713 and 714. These contain information of the financial institution holding the receiver's account. All the records are populated in a similar manner as the originating financial institution fetching the information from the BNKA table.

Receiver Information 2: Record No. 715 and 716 contain information related to the receiver of the payment. They contain the receiver name and detailed address. All the information here gets populated from the vendor details table - LFA1.

Remittance Information: IAT entries will accommodate the transmission of optional remittance information. Record No. 717 contains free form text as desired which highlights the transaction details. Maximum of two optional addenda records will be able to accompany an IAT entry.

Foreign Correspondent Bank Information: Record No. 718 gives information about the Foreign Correspondent Bank through which the payment gets routed from the originator to the receiver. It contains the following information:

• Foreign Correspondent Bank Name
• Foreign Correspondent Bank Identifier Number Qualifier
• Foreign Correspondent Bank Identification Number
• Foreign Correspondent Bank Branch Country Code

All these information are directly maintained in the program variant. When the payment program is executed with that particular variant, the Foreign Correspondent Bank information is populated in the output DME file real time. Position 84-87 represents the addenda sequence number. This number is consecutively assigned to each Addenda Record following an Entry Detail Record. The first addenda sequence must always be "1". Each Foreign Correspondent Bank Involved in the processing of an IAT entry must be identified with an Addenda Record for IAT Foreign Correspondent Bank Information.

Batch Control Record: The Company / Batch Control Record (Record Type 8) summarizes the information in the file. This record shows the number of transactions and the total value of all transactions in a particular IAT batch file.

• Position 05-10 indicates the tally of all entry records and addenda records processed in this file. The count here is "30" because the file has 27 addenda records (beginning with "7") and 3 entry records (beginning with "6"). If multiple payments are made in the same file then this value will increase accordingly.
• Position 11-20 indicates the Routing Number of the vendor bank which accepts only 8 characters.
• Positions 21-32 and 33-44 give the total debit and credit amounts respectively in the file.
• Position 45-54 convey the same information contained in the original identification field of the Company/Batch header record.
• Position 80-87 incorporates the routing number or the bank number from REGUH (field UBNKL) but here only the first eight characters get populated.

File Control Record: The File Control Record summarizes the information carried in the Company / Batch Control Records. It contains the amount, entries and total accumulations of the Company / Batch control records in the file. It also contains count of the number of blocks and the number of batches within the file.

• Position 02-07 gives the value of the batch count field equal to the Company / Batch header records in the file.
• Position 08-13 gives the number of transaction blocks within the file.
• Position 14-21 gives the tally of each Entry Detail and Addenda Record processed within the batch.
• Position 22-31 indicates the Routing Number of the vendor bank and accepts only 8 characters.
• Positions 32-43 and 44-55 give the total debit and credit amounts in the file respectively.

Conclusion

ACH IAT payment medium has seen several new incorporations in it's payment rules. NACHA had decided to introduce modifications to the IAT file in a phased manner identifying three dates to complete these implementations of the changes.

Effective March 16, 2012: Changes incorporated to clarify and enhance the rules to support more efficient processing of IAT entries.

                         Table 1: Changes to be incorporated in ACH IAT – Mar 16, 2012

Effective September 21, 2012: Changes to clarify minimum descriptive standards and addition of transaction type code to identifying IAT entries carrying remittances.

                         Table 2: Changes to be incorporated in ACH IAT – Sep 21, 2012

Effective March 15, 2013: Changes to clarify the return code and notifications of change code which applies to IAT in certain situations. They primarily impact gateway operators.

                          Table 3: Changes to be incorporated in ACH IAT – Mar 15, 2013