Even after you set a payment method in transaction FBZP asBill of Exchange or Bill of Exchange Payment Required and Bill of Exchange accepted, the Bill of Exchange Types are not appearing in transaction F.39:
FBZP transaction:
F.39 transaction:
This is because of the missing flag in check box Create a bill of Exchange Before Due Date. After this check you should be able to view this missing information in transaction F.39:
This document explains functionality of cash discount posting through SD billing document and maintenance of the clearing account.
One of the functionality in customer billing is calculation of cash discount at the time of billing. At the time of billing SAP reads payment terms from customer master data using condition ‘SKTO’. SKTO reads discount percentage and calculates cash discount amount in billing document. SKTO is a statistical condition and therefore is only for information purpose.
To show contingent liability towards cash discount some clients may want to post cash discount to accrual account and clear the same at the time of payment. Configuration to achieve this goes like this-
Journal entry at the time of billing will be:
D Customer 67,575.00
D Discount Expense A/C (assigned in VKOA) 675.75
C Revenue A/C 67,575.00 -
C Discount Accrual A/C (assigned in VKOA – as accrual) 675.75 -
Discount is recognized immediately as expense assuming that customer will pay in time. Credit with same amount goes to an accrual account.
If customer pays in time, entry at the time of payment –
D Checks/Wires in 66,899.25
D Discount Accrual A/C (assigned to T-Code OBXI) 675.75
C Customer 67,575.00 -
Amount in discount accrual account will always represent liability of the company towards cash discount. Client can accurately show its contingent liability towards unclaimed cash discount. Accrual account works as clearing account and therefore we can track cash discount right from billing to payment.
However, there is a problem in this approach. All customers not always pay within due date. In that case customer will pay full amount and at the time of payment discount accrual account will not be debited.
In that case entries should go as shown below:
D Checks/Wires in 67,575.00
C Customer 67,575.00 -
Since original discount amount is lying expense account and reversal account it need to be reversed as well. So next entry to complete this should be –
D Discount Accrual A/C 675.75
C Discount Expense A/C 675.75 -
Above entry SAP does not posts automatically and identifying line item to be reversed manually is a tedious task due to large number of entries in accrual account.
Basically at a time line items in accrual accounts can be divided into 3 categories:
Cat. 1– Lines that represent unclaimed discount. Ideally only these lines should remain in accrual account.
Cat. 2 – Credit amount at the time of billing and debit line items for on time payment. Ideally these line items should be cleared. In case these lines are not cleared it will represent a cluttered clearing account, however clearing such account is not an easy task because there are no common fields between credit amount and debit amount.
Cat. 3– Credit amount at the time of billing where payment is not made on time. Ideally these entries should be reversed against discount expense account and cleared in accrual account.
If lines under category 2 and category 3 are not cleared and accrual account is not maintained it will be difficult to ascertain correct amount of liability towards cash discount. To identify and clear lines under category 2 and 3 in accrual account we can develop 2 custom reports. One report will show line items where customer paid in time and lines should be cleared and other report will show where customer failed to pay in time and line items can be reversed.
Report 1 – Clearing information for accrual account (Customer paid in time):
When customer line items are cleared and discount is automatically posted, that document becomes clearing document for customer billing line item and payment document. It holds good when billing line is cleared at the time of booking payment (where payment document = clearing document) or when billing line and payment lines are cleared later like in case of Lockbox processing (where payment document <> clearing document).
See example below:
Typically this is how a customer account looks after customer has made on time payment.
RV line shows – Billing, DZ – Incoming payment and AB – Clearing document (that posts allowable discount as well)
Customer Account: 100099 in company code 1100.
Acc. Doc | F. Year | Description | Posting Date | Amount in LC | LC | Doc Type | Clearing doc. |
90029409 | 2013 | XYZ Customer | 6/10/2013 | 67,575.00 | USD | RV | 100118364 |
1400004854 | 2013 | XYZ Customer | 6/24/2013 | 66,899.25- | USD | DZ | 100118364 |
100118364 | 2013 | XYZ Customer | 6/24/2013 | 675.75- | USD | AB | 100118364 |
Accrual account after above postings. Please note that both lines are open as of now. Accrual account 120021 in company code 1100 -
| F. Year | Description | Posting Date | Amount in LC | LC | Doc Type | Clearing doc. |
90029409 | 2013 | Discount Accrual A/C | 6/10/2013 | 675.75- | USD | RV |
|
100118364 | 2013 | Discount Accrual A/C | 6/24/2013 | 675.75 | USD | AB |
|
If you observe in customer account that accounting document in the line where discount is posted is same as clearing document. We need to establish link between Billing document 90029409 and clearing document 100118364. This can be achieved using 2 tables i.e. BSIS and BSAD. Please see below –
If we input following information in table BSIS we should get line item from document 100118364 along with other lines but for simplicity I am showing on line from document # 100118364.
Input:
Company Code (BSIS-BUKRS)
Accrual Account (BSIS-HKONT)
Posting Date (BSIS-BUDAT)
Output:
If we send above information to table BSAD we should be able to fetch billing document number and clearing document number:
Joining condition between table BSIS and BSAD should be:
BSIS-BELNR = BSAD-AUGBL
BSIS-BUDAT = BSAD-AUGDT
BSIS-BUKRS = BSAD-BUKRS
Input
Output:
You will observe that you will get Billing document - 90029409, Payment document - 100118364 and Clearing document - 1400004854.
By subtotaling field BSAD-SKNTO and BSAD-WSKTO on clearing document you can have zero for cash discount amount (you will have to make them +ive or –ive by using field SHKZG). If your total is zero these accounting documents can be cleared. If total is not zero it means that customer paid amount after due date and therefore not claimed discount. Such discount need to be reversed against expense account.
We can have a nice custom report to show above output:
Again, clearing above lines is a manual task, however a custom program can be further extended to update assignment field in selected line items based on same clearing document number. Based on assignment field a match-code can be configured for automatic clearing of Discount Accrual account.
Selection screen for the above report will look as shown below:
Company Code (BSIS-BUKRS)
Accrual Account (BSIS-HKONT)
Accounting Document (BSIS-BELNR)
You have to follow steps below to develop a query report:
Create InfoSet (SQ02) by joining tables BSIS and BSAD as shown below:
Query will show duplicates in its output, you will have to insert following code to remove duplicate. You may have to take help of ABAP consultant:
To show amount according to +/- sign you will need 2 ‘Local Fields’ – One for document currency amount and one for local currency amount.
Configure Local fields as shown below:
Layout for the report can be designed as shown below:
Report 2 – Report to reverse expired discount (Customer not paid yet and discount expired):
For invoices where customer has not made payment in time entry for discount should be reversed. Example –
D Discount Accrual A/C 675.75
C Discount Expense A/C 675.75
Above entry SAP does not posts automatically and identifying line item to be reversed manually is a tedious task due to large number of entries in accrual account.
A report can be developed to identify each customer line where discount is available as per billing document. This report can show whether individual line can be reversed or no.
In the above report last column shows traffic lights, red light means line cannot be reversed, green light means amount can be reversed. On the date of executing report total of all amount under green light can be reversed and cleared against individual lines.
From table BSID (Customer open line items) for lines generated using document type ‘RV’ (SD Billing) program will check whether on the date of execution line item is overdue or no.
Example –
Payment terms - 60 days, discount percentage = 1%.
Baseline date is 04/28/2014; Run Date is 08/10/2014; Days overdue = 104 which is more than 60 days and therefore customer is not eligible for discount. Therefore for this line green light should be indicated and amount can be reversed.
In my example I am comparing days overdue with value in field BSAD-ZBD1T (i.e. highest number of days any discount is available). Amount to be reversed will be calculated as a local field by multiplying discount percentage with discount base.
Selection screen for above report –
Table BSID has all the relevant information to generate this report. You can use query shown below to produce above shown report –
InfoSet (SQ02)
You will need 3 local fields in this report –
Days Overdue, Reversal Amount and Traffic light indicator.
Local fields should have calculation steps as shown below –
ZDPDUE - Days overdue
Formula – Run date (variable %DATE) – Baseline date (BSAD-ZFBDT)
REVAMT - Reversal Amount
Formula – BSAD-SKFBT (Discount base) * (BSAD-ZBD1P (Disc. Percent 1)/100)
XREVRS - Can be reversed?
Formula –
If BSAD-ZBD2T (Days 2) <> 0 AND BSAD-ZBD2T < ZDPDUE then green light. (If value in field days 2 exist then compare it with ZDPDUE)
If BSAD-ZBD2T (Days 2) = 0 AND BSAD-ZBD1T < ZDPDUE then green light. (If value in field days 2 is 0 then compare field ZBD1T with ZDPDUE)
Else, red light
With the help of above 2 reports, user should be able to maintain discount accrual account, also he/she should be able to show discount accrual amount correctly.
This document is useful to those who are interested to improve their technical skills in addition to the functional skills.
This document is explaining the process of creating a module pool for the SAP CO Month End Process. The objective is to provide a simplified screen to the end user to complete the month end process. Normally this process will be done by an ABPER, but it can be done by a functional consultant with a little bit knowledge on coding which is very simple.
Note: The document is appears to be lengthy because of adding detailed screens for every step.
I have provided the detailed steps to complete the process. Before going into the details, end result of the screen to be developed is as follows:
We will start the process:
ABAP Development Screen:
For developing a module pool Program, PAI Module, Screen is required
We need to create a custom program there by PAI module and a Screen so that we will get the end result as mentioned above. It is possible to give our own Transaction code to get the output.
Transaction : SE80
First we will create custom program: Transaction Code: SE80:
Input the name of the program to be created,as an example I have given ZPAVAN03 as a program name, which is to be created.
Mention the description of the the program to be created in the Title tab and Save.
System prompt for a package...provide the package name later save the program.
After saving system prompt for a workbench request. Provide the details and save the request.
After saving the request the following screen will be displayed:
We have successfully completed the creation of a custom program.
We will look into the 2nd part: Creation of a PAI Module.
We need to add PAI Module for this the screen to be in change mode. We will go to change mode by clicking change button (or) Ctrl + F1
Screen changed from display mode to change mode.
Keep cursor on the Program ( ZPAVAN03) then create PAI Module:
Specify the name of the PAI Module.
The next screen we will be as follows to write a code:
Technical coding part will come into picture now, here we need to add our code.
Insert the code in between Module ‘ZPAVAN03 Input’ and ‘End Module’:
Code is :
CASE SY-UCOMM.
WHEN 'BTN_DC1'. CALL TRANSACTION 'KSV1'.
ENDDCASE. " ZPAVAN02 INPUT.
Explanation: The said code is for
tab on the module pool.
BTN represents button.
Call Transaction Represents link to the T code KSV1
Same way we can insert more buttons like:
WHEN 'BTN_DC2'. CALL TRANSACTION 'KSV2'..
WHEN 'BTN_DC3'. CALL TRANSACTION 'KSV3'.
After completing the code we need to mention End case.
I am mentioning the complete code for the module pool in the following screen:
After completing the code click on save button. PAI Modules will be added to your program.
We have successfully completed the 2nd phase.
Now we are into the 3rd Phase, need to design a custom screen :
System will prompt for a screen number:
Click on continue and provide the screen details.
Click on Flow logic tab to remove a * before MODULE USER_COMMAND_9010.
After removing the * before MODULE USER_COMMAND_9010. It will go to color in blue.
That means our module is in active
We need to activate the program after saving.
After activation click on screen then click on layout to design a screen:
Layout: While processing the layout we will get following screen the layout will be displayed.
Click on save then activate. We have created one Tab same process is applicable to add more tabs on our custom screen.
We have successfully completed the 3rd phase.
We are into the final stage:
Creating a custom transaction code for our module pool.
I have given transaction code as ZPAVANCOME and given sort description then save.
We have successfully completed all the process which is required to create a module pool.
We will execute the module pool with our own T code:
End Result:
Module Pool for CO Month End Process is Ready to use.....................Thank you
Automatic Payment Program (F110) is used to do the clear the invoices and post the payments.F110 is the standard t-code for doing the same.
In addition to the above there also forms sent to customers and vendors about the Payments done which are called Remittance Advices and Payment Advices based on the payment method configured.
For payment advices we can use all the three kinds of forms .In this document configuration and the calling logics for all the 3 kinds of forms.
SAP SCRIPTS:
Use payment medium work bench :
Use classic print programs :
SMARTFORMS:
Adobe Forms:
Standard adobe forms for the F110 would be F110_AVIS_INT
Any Inputs are highly appreciated.
Overview on New G/L Accounting
New G/l is a very competitive in increasingly global economy and increased the demands for varied reports due to various regulatory changes and related businesses. New G/L overcomes shortcoming of traditional accounting by providing single robust application with unified interface which caters both the needs of financial and management accounting.
The New G/L approach is developed to accommodate the numerous requirements for legal, managerial, country, and local accounting needs. Basically, it brings together much of the reporting and analysis which earlier used to done separately by different components in classical G/L system like FI-CO reconciliation, special purpose ledger, COGS.
SAP incorporates additional functionality in New G/L that will offer information on the go which otherwise were obtained by other components in classic SAP like Cost of Sales Ledger, reconciliation ledger to reconcile between FI and CO data, Special Purpose Ledger.
In this way, the New G/L Accounting serves as a complete record of all business transactions. Central and up-to-date component for reporting where all posted transactions can be checked in real time.
Benefits with New General Ledger Accounting
New G/L provides new and improved functionality, flexibility with document splitting, parallel accounting, segment reporting, and real time improved integration with other applications and SAP modules.
New G/L and Classic G/L
In the classical approach, users had to retrieve information through various areas or applications, such as the special purpose ledger, COGS ledger.
Below picture gives you a view how SAP has moved/transformed from Classical G/L to New G/L with taking all the multiple application to one unified world i.e. New G/L Accounting. Sap has integrated all the application to save time, money, efforts and more important to provide reports and information as required for various internal and external purposes.
(1) Flexibility
SAP consolidated multiple totals table (GLT0, GLPCT) in classic G/L into a single Totals table named FAGLFLEXT in New G/L. With one Table, it provides flexibility and faster response time for reporting.
(2) Reconciliation Automated
Reconciliation in classical G/L used to take several weeks or months but with New G/L many reconciliation process has been automated like reconciliation of FI-CO.
(3) Segment reporting
New G/L has document splitting functionality that enables segment reporting. Segment Reporting functionality is not available in Classic G/L.
(4) Real Time Integration between FI and CO in New G/L
(5) Parallel Accounting
New G/L provides Leading and Non-leading ledgers for parallel accounting like IFRS and GAAP so as to have financial statements as per different legal and accounting regulations.
(6) Faster Period Closing
Faster Period Close with New G/L such as,
a. Reconciliation Ledger is not required
b. Financial Statement adjustment are no more required
d. Activities related to Special Purpose Ledger are not required
e. Depreciation posting can be done online
(7) Flexible Drill-down Reporting in New G/L
Totals Table
Totals table is a database table in which totals records are stored. In New G/L SAP delivers the totals table FAGLFLEXT in the standard system.
Once New General Ledger Accounting is activated, totals records in G/L are updated in the totals table FAGLFLEXT.
FAGLFLEXT updates more entities than that of the classic totals table (GLT0). FAGLFLEXT has total of 142 fields which include all majorly used fields like Company Code, G/L Number, Cost Center, Profit Center, Business Areaand many more in one table.
Configuration Steps:
Configuration Steps:
1. Create Company Code
IMG Menu: Enterprise Structure --- Definition --- Financial Accounting (New)--- Edit, Copy, Delete, Check Company Code
Click on New Entries button:
Click on Save.
New tab will come up, fill the details as below:
Click on Save.
2. Activation of New G/L
For new implementation projects, new General Ledger Accounting is activated by default in SAP system. Whereas, if existing customers want to use New General Ledger Accounting, they first need to migrate from classical to New G/L which is a separate project in itself.
Just to show you how to activate New G/L if it is not yet activated, but do not try this in a production system.
This is the first activity which you need to do for new G/L accounting. In the case of existing customer this must be last step after completion of new G/L migration project. As you activate new G/L, it results in wide changes to the SPRO customization path and table structures.
Continuing to New G/L Accounting Part-2, the next level of configuration is Ledger. Follow the next link New General Ledger Accounting Part-2
Appreciate to have your views, comments and suggestions.
Thanks and Regards,
Mukesh Sharma
Incoming payment advice notes Electronically payment can be received from a partner (payment advice note/note about a debit memo/note about a bank collection) or from a bank (credit memo/debit memo).The payment advice note is stored in the note data bank and is then available to clear open items. Note can be used to generate an advice note for cash management and forecast or to clear the open item automatically. Below mentioned customization needs to be performed for the processing of incoming electronic payment advices and to clear the open item.
Step 1 – Partner Profile need to be set up (for each relevant customer/ vendor account, a partner profile needs to be set up) and configured. Following selections must be made for each profile:
• Partner number = customer/ vendor account number
• Partner type: LI for vendors and KU for customers
• Inbound parameters:
o Message type: REMADV [standard SAP IDoc for EDI payment advice]
o Process code: REMA (No further processing)/ REMC (Automatic further processing)
o Syntax check (activated) o Trigger immediately (activated)
T-code: WE20
Step 2 - Set up selection rules per customer/ vendor individually to define the criteria that shall be used to search the open items in customer/ vendor sub ledgers Path - SPRO => Financial Accounting => Accounts Receivables and Accounts Payable => Business Transactions => Incoming Payments => Incoming Payments Global Settings => Payment Advice Notes (Incoming)
Step 2.1 - Define payment advice types – In this step, following attributes for the payment advice types are define by the system:
1. Minimum retention period in the system - In this case, user can specify the number of days a payment advice note must be in the system before it may be deleted
2. Authorization group – In this step user can assign authorizations for entering, changing, displaying and deleting payment advice notes. Payment advice type -06 is being used for the electronic payment advices
Step 2.2 - Choose selection fields for payment advice notes - In this step, User can specify the fields via which the system is to make selections when displaying payment advice items.
Step 2.3 - Choose External Selection Fields for Payment Advice Notes - In this step, user can define external selection fields. These are used for identifying invoices, such as from delivery note numbers, for which no fields exists in Financial Accounting.
Step 2.4 - Define selection rules - In this step user can define the identification for the clearing.
Step 2.5 – Allocate Selection fields – In this step user can assign internal selection fields, that is, selection fields the system knows, to external selection fields (data the customer sends you, such as a delivery note number) under a certain selection rule. This assignment is necessary to ensure the correct identification of the open items.
Step 2.6 - Payment Advice Overview: Define Line Layout - In this step, User can determine which information is to be made available on the screen for the payment advice overview (such as payment advice item, document number, selection.
Step 2.7 - Payment Advice Overview: Choose Standard Line Layout - In this step, User can define standard default values for the line layout.
Step 3 - Define Posting Keys and Posting Rules for Manual Bank Statement - In this activity user can define posting keys and posting rules. Posting rule will be used in next step. Path - SPRO => Financial Accounting => Bank Accounting => Business Transactions => Payment Transaction => Manual Bank Statement => Define Posting Keys and Posting Rules for Manual Bank Statement
Step 4 – Define Further Processing of Payment Advice Notes – This step is used to define further processing of payment advice notes (to either process the payment advice note automatically or to park the payment advice). In this activity, user can determine which further automatic activities should take place for electronically transferred payment advice notes. Posting rule for the clearing document is determined from this customization.
Step 5 – Define Ports for processing incoming electronic payment advice. T-code: WE21
Step 6 - EDI profiles in vendor and customer master data need to be activated. In field status groups of all vendors and customers the field “Payment advice via EDI” needs to be set to required or Optional.
Step 7 – “Pmt adv. By EDI” check needs to be checked for Customer / Vendor master data
Conclusion – Incoming payment advise can be posted with the clearing of open item by maintaining the above customization.
For all customer debit and credit items, maximum cash discount is always considered.
The reason for this, is that the customer should not be penalized for carrying out the automatic payment after the due date. Thus max cash discount should be granted.
SAP Note 31345 explains this behavior.
Credit memos are always paid with the maximum cash discount if they do not have reference to the corresponding invoice in REBZG field.
If you post a credit memo with reference to a certain invoice (or set this reference via FB02) the credit memo will be paid with the same payment conditions as the invoice.
Or if you want the net due date to be calculated according to the payment term you have entered in the document, you need to enter a 'V' in the 'Invoice reference' field (BSEG-REBZG).
Regarding to Vendors, please check customizing of the payment program in your system:
transaction FBZP -> All Company Codes -> your Company Code -> the checkbox 'Max. cash discount'
According to F1-help to this field:
"Vendor Payments Always with Maximum Cash Discount" Means that the maximum cash discount is always to be deducted when automatically paying vendor invoices.
You set the option "Transfer days" in transaction OB82 but this is not being considered when running Item Interest Calculation (program RFINTITAR).
This is because Transfer days are only deducted for incoming payments. If you do not select them (by using dynamic selections) or when the clearing document is not an incoming payment, transfer days are not deducted.
When you select only invoices and clearing items are not selected, the program cannot determine, whether this is a payment or not or take the document date into account.
When no clearing item is selected, the interests for the invoices are calculated till the clearing date.
For considering the transfer days, you can also use BADI FI_INT_CUS01 in method INT_CHANGE_ITEMS.
Automatic Payment Program (F110) is used to do the clear the invoices and post the payments.F110 is the standard t-code for doing the same.
In addition to the above there also forms sent to customers and vendors about the Payments done which are called Remittance Advices and Payment Advices based on the payment method configured
For payment advices we can use all the three kinds of forms .In this document configuration and the calling logics for all the 3 kinds of forms.SAP SCRIPTS:
Use payment medium work bench :
Use classic print programs : 
SMARTFORMS:
Adobe Forms:
Standard adobe forms for the F110 would be F110_AVIS_INT
Any Inputs are highly appreciated.
This document will help you to display a check register for vendor payments. Whenever you have check related problems, you can use t.code FCHN to see a list of checks written, outstanding, cleared.
SAP Easy Access Menu: Accounting-Financial Accounting-Banks-Envoirment-Check balance-Display-Check Register
Transaction Code: FCHN
Start the transaction using the menu path or transaction code. The Check Register screen displays
Enter Paying company code, house bank and account
Select With Line Items 
radio button.
Perform one of the following:
If |
Then |
|---|---|
You wish to displayinvoices paid on the check | Select With Line Items radio button |
You wish to display summarized check list | Select W/out Line Items radio button |
Click on Execute button. The Check Register screen updates
Double-click the desired Check Number .
The Display Check Information screen displays
Click Payment document. The Display Document: Data Entry View displays.
Payment document will be display. Goto Enviroment-Payment Usage. It will give information about document number against which check issued.
Additional information from SAP Help Portal – The central place for SAP documentation is given below:
Program RFCHKN10 is a continuation of program RFCHKN00. The user can configure the output of the list. The program generates a list of all check registers belonging to one paying company code, (prenumbered checks), if they fulfil the given selection criteria. The list is sorted by payment method and check number with manually voided checks at the start and manually issued checks at the end. This order of output is the default, but can be altered by the user.
You can create various lists. For example:
You only enter the company code. Further selection conditions could include the specification of a bank account or the creation period.
2. Complete List with Line Item Information
In addition to 1., you have to select the parameter that controls the output of the paid items.
3. List of Outstanding Checks
If, in addition to 1. you select "List of Outstanding Checks" those checks that are not yet cashed are listed.
4. Payment Summary for a Payment Run
The run date of the paying company code, and, (if the run is not clearly indicated by the date), run ID of the payment run have to be entered. If the check register with the print run of the payment program is scheduled, a variant must first be created in order that the paying company code be specified. The remaining parameters (date and identifier) are entered by the payment program if program RFCHKN00 is entered with this variant before the start of the print programs under "Lists".
5. Payment Summary for an Extract Run
If, for the purposes of an external data transfer, a data extract is created with a database update, a list can then be called up showing all checks for which information is contained in the extract. In addition to the paying company code, the extract date must be entered, and, (in the event that several extracts were created on one day), the time when the extract was created.
6. List of all Genuine Checks
Here you enter the initial value of the void reason code in the selection options (single value SPACE or 00).
7. List of all Voided Checks
Similarly, you have to keep the initial value out of the selection option for the void reason code.
8. List of Payroll Checks
If prenumbered checks are used in the Human Resources department, it is possible to generate a list that is seperate from Financial Accounting. You can also choose between list types such as complete lists, lists of outstanding checks, lists per payment run or extract.
9. In addition, you can select according to issuing amount or issuer, (also in conjunction with the aforementioned variants).
10. The user can display line items for checks for all listed possible entries. In this case, choose the indicator "With line items" After setting the indicator you can enter display variants. These have to be maintained prior to this. The organizational possibilities offered by the output list can be called up in program RFCHKN10 using the ABAP List Viewer. You can find a comprehensive description of user-relevant tool operation in the SAP Library under CO Controlling -> Cost Center Accounting -> Information System Cost Center Accounting -> ABAP List Viewer.
Please let me know if you have any doubts.
Hi Team,
Under OB52 We have option to Open Interval 3 as like Interval 1 and 2.
Interval 3 Activation In OB52 :
Changes using SPRO:
1. Transaction code SPRO
2. Select (highlight, don't execute!) the voice 'Financial accounting --> Financial Accounting Global Setting --> Document --> Posting
Periods --> Open and Close Posting Period'
3. From menu select: Edit --> Display IMG activity
4. Select the page 'Maint. Objects' into 'Assigned objects' area
5. Double click on object V_T001B
6. Change the value of field 'Transport' (from Automatic to not required)
From SAP ECC 6.0, Enhancement Package 4, Business Function New General Ledger Accounting 2, you can still post CO transactions in the preceding period even when this period has been closed for FI postings. For this, you can use the additional period interval 3 in the Customizing settings for the posting periods; this period interval is only relevant for postings from Controlling (CO) to Financial Accounting (FI) (New). It is valid for postings created with the real-time integration as well as for postings created using the CO-FI reconciliation ledger during closing operations.
When you create an entry for period interval 3, only postings that were transferred from CO to FI are checked against this interval. All other posting transactions are controlled with period intervals 1 and 2.
If you do not create an entry for period interval 3, the settings for period intervals 1 and 2 are also valid for postings from CO to FI.
Note
You can only define the period interval for account type +.
You make the settings for this function in Customizing for Financial Accounting (New) under Financial Accounting Global Settings (New) -> Ledgers -> Fiscal Year and Posting Periods -> Posting Periods -> Open and Close Posting Periods.
For more information, see the central Release Note for the New General Ledger Accounting 2 business function.
Single Euro Payments Area (SEPA) Implementation of DD(Direct Debit)(Technical)
Sep, 2013
Introduction
SEPA stands for ‘Single Euro Payment Area’. It’s a system that is designed to create financial efficiency for countries using the currency Euro by providing a unified system in which to perform financial transactions. The SEPA seeks to create a better system for credit transfers, an improved debit system and a cheaper way for individuals and firms to make transactions within member countries or regions. Implementation of SEPA makes the customers life easier. Irrespective of the national area customers will be able to use the same card for all euro payments and also they need only one bank account in euro area.
Introduction to SEPA process:
The below mentioned should be done for Implementation of SEPA business in any SAP system:
1. SEPA_Activation_Mandate_Management
Following are the activities which are to be done as part of this:
i. SEPA mandate management has to be activated for the usage with SDD CORE and SDD B2B from FI-AR payment processing. Apart from activating the SEPA Mandate management we need to maintain the SEPA Mandate management modifiable fields.
Below is the path for activating the SEPA Mandate Management and maintain the modifiable fields.
IMG -> Financial Accounting -> Accounts Receivable and Account Payable -> Business Transactions -> Incoming Payments -> Management of SEPA Mandates -> General Settings.
IMG -> Financial Accounting -> Accounts Receivable and Account Payable -> Business Transactions -> Incoming Payments -> Management of SEPA Mandates -> Define Modifiable Fields
ii. Creation of new DMEE Payment Format tree for SEPA credit transfer and SEPA direct debit.
· SEPA_CT and SEPA_DD are the DMEE formats provided by SAP.
· As we will be dealing with multiple countries it is always better to copy the DMEE formats and create new ones. If there is any custom requirement for any country create a user exit and assign to the field that needs to be changed dynamically.
2. Pre Notification with payment run :
With a direct debit pre-notification, Markets can inform a payer in writing in advance of the debiting of his account. To do this, one has to schedule a run for the creation of direct debit pre-notifications before the payment run, meaning before clearing the open items and creation of payment media. These correspond in structure to the payment advice notes, and therefore contain details of the run date, the amount to be collected, mandate ID, Unified Creditor Identifier etc.
Following are the SAP notes to be implemented for SEPA Pre-notification.
SAP Note | Description |
1679118 | F110: Custom Selection for Batch Input |
1760564 | F110S: Selection Check for Customers and Vendors |
1770425 | F111/SEPA: Mandate rejected as invalid after change |
1771071 | FBCJ : Reversal possible despite cleared item |
1776076 | F110/F111 : BADI for SEPA Mandate usage |
1780941 | SEPA: Direct debit Pre-Notification |
1792691 | Valid SEPA mandate is not found in the system during payment proposal processing |
As part of the Note implementation 1780941, we need to implement manual steps given below for importing the Standard SAP Form.
· SAP has provided text file by using this file we need to import the object F110_DD_PRENOTIF into SAP by executing program RSTXCRP. This is standard SAP form which will be used for sending PreNotifications.
· SAP has provided XML file by using this file we need to import the object F110_DD_PRENOTIF into SAP using SFP transaction code. Once it is uploaded, activate the form.
Once all the relevant OSS Notes are implemented for SEPA Direct debit pre-notification, we will get option of checkbox for Pre-notification in F110 transaction and also pre-notification relevant standard program RFFOAVIS_DD_PRENOTIF and script form (F110_DD_PRENOTIF) available in the system.
The above check box is checked if we need to do SEPA prenotification.
RFFOAVIS_DD_PRENOTIF: This is the payment advice print program that is used to print the pre-notifications the pre-notification
F110_DD_PRENOTIF: This is the standard SAP script which is used to send the pre-notifications.
Based on the user requirement, the form name can be changed
· The new "direct debit pre-notification" object is visible in the payment run (F110), in the document display (FB03), in the line item display (FBL5N) and in mandate display (FSEPA_M4). It can be deleted again if the direct debit pre-notification customer objects to it (for example, because the customer pays the bill himself). Otherwise, the posting run and the payment medium creation are performed after the end of the specified wait time based on the direct debit pre-notifications.
3. Creation of SEPA Mandates for payment transactions :
· Before doing any transaction for any SEPA customer we need to have a mandate create for the Customer.
· Before creating a mandate the Customer Should have IBAN number.
· Transactions used :
Creation | FSEPA_M1 |
Change | FSEPA_M2 |
Display | FSEPA_M3,FSEPA_M4 |
NOTE: Mandates can also be created from the payment tab of the Customer Master XD01, FD01, XD02,FD02.
NOTE: Mandate Number can be either External or Internal Number.
· To make our work easier technically we can use the below procedure using the below BAPI's:
· The table that is Master for all the SEPA mandates is SEPA_MANDATE.
· SEPA_MANDATE: This is the Standard Smart form used to print the mandate details for any customer.
· Assume a file with the Customer and mandate Information is available
Ø Check if the customer is created by checking in the KNB1 table.
Ø If the Customer is present then check if the Customer has IBAN and BIC number.
Ø Check if the mandate is not created for Customer with the mandate number using the BAPI SEPA_MANDATES_API_GET.
Ø For the BAPI SEPA_MANDATES_API_GET pass the customer number in the importing parameter to check if there is any mandate information present for the Customer SEPA_GET_CRITERIA_MANDATE-snd_id = Customer Number .
Ø ET_MANDATES contains the mandate information that is fetched from BAPI based on the Customer Number.
NOTE : SEPA_MANDATES_API_GET FM cannot be used for multiple mandate scenario. We can write take MGUID from REGUH table and go to SEPA_MANDATE table and get the IBAN number and mandate number.
Three BAPI'S are majorly used to Creation and updating of the mandate details of the Customer.
To fetch the Mandate information for a particular Customer from the table SEPA_MANDATE table | SEPA_MANDATES_API_GET |
Create the Mandate for a Customer | BAPI_SEPA_MANDATE_CREATE1 |
Modification of Mandate details for a customer | BAPI_SEPA_MANDATE_CHANGE1 |
· Mandate Creation:
Ø Use the BAPI BAPI_SEPA_MANDATE_CREATE1 to create the mandate .
Ø BAPI_S_SEPA_MANDATE_COMMON structure which is importing parameter to the above mentioned BAPI has to be filled with the mandate information .This contains both the Sender (Customer Details ) and receiver details (Company code data ).
Ø Then collect all the address information either from the file provided or from the customer master data and fill the Sender information in the structure BAPI_S_SEPA_MANDATE_COMMON.
Ø Then based on the company code fetch the address details of the Company code and fill the Receiver information in the structure BAPI_S_SEPA_MANDATE_COMMON.
Ø ES_MANDATE_CREATED exporting parameter in the above BAPI gives a success message if the mandates are correctly created for the customer.
Ø Error handling can be done with the return exporting parameter.
· If the mandate already exists then check if there is any change in the mandate information.
Mandate modification:
Ø Use the BAPI BAPI_SEPA_MANDATE_CHANGE1 to change the already existing mandate.
Ø BAPI_S_SEPA_MANDATE_CHANGE structure which is importing parameter to the above mentioned BAPI has to be filled with the mandate information .This contains both the Sender (Customer Details) and receiver details (Company code data ).
Ø In case ofupdation is failed it can handled by return parameter of the BAPI
Display of Mandates :
Ø The created mandates can be checked by FSEPA_M3 Give the Mandate number or Customer Number and check for the Mandate information.
On Click on Enter the below Screen appears which displays all the information.
Ø We can also check the Mandate information through Customer master display using transaction fd02,xd02,xd03,fd03.
Click on the Tab to check and create the mandate Details from Customer master
Display the List of Mandates:
Ø Use the transaction FSEPA_M4 to display a list for customers for a particular company code.
Ø Mention the company code in the below transaction and then execute all the mandates present for the company code will be displayed.
Ø A list of mandates will be displayed as shown in the below screen shot.
The above lights depicts different status of the mandates below are the differnent status of mandates.
0 | Entered |
1 | Active |
2 | To Be Confirmed |
3 | Locked |
4 | Canceled |
5 | Obsolete |
6 | CompletedCompleted |
Ø If we need to print a particular mandate information then select the Print mandate button on the top right corner of the list .
Ø For this SAP has provided a smartform SEPA_MANDATE.This can be customized at central level and the thus the mandate can be created and mandate information can be printed.
All the inforamtion related to the mandate is available in the table SEPA_MANDATE.
During the payment system will always pick the first House Bank and Account ID that is suitable for the payment.
The House Bank is picked automatically regarding your customizing settings in Customer/Vendor Master Data (the first system choice) and in transaction FBZP -> 'Bank determination'.
In FBZP you should define a ranking order, bank accounts and available amounts for the payment methods.
For the assignment of of House Bank and a Payment Method go to transaction FBZP > Bank Determination:
By standard you will not be able to change the rank order you should use a BTE in order to achieve your business requirements.
Consider the usage of the following business transaction event (BTE, in another words OPEN_FI):
For additional documentation about this can be found in transaction FIBF. There you can use the info system for processes (Environment > Infosystem (Processes) and do a search for selection attribute FI.
To change the House Bank order the event 1810 can be used.
Search String Functionality- based on unique text in the note to payee lines for EBS.
EBS is used to enhance the efficiency of bank reconciliation process in the organization. There are different standard EBS bank formats available, e.g. BAI2 and MT940, Multicash etc. While importing the EBS, system identifies the business transaction codes from the file and post the documents on the basis of the settings already configured for EBS global settings.
As per the business scenario, either information in the note to payee may be incomplete or the desired result cannot be achieved through standard algorithm mechanisms provided by SAP. Therefore to overcome such lacunas, we use search string functionality to achieve the business requirement.
The Search String functionality can further be elucidated using the below-mentioned example:
Scenario: Bank provides one External Bank Transaction Code (BTC) for multiple transactions relating to incoming payments. However, the requirement of the business is to capture them in different GLs.
BTC | Multiple Transactions | GLs |
165 | GE Capital | 11111 |
165 | American Express | 11111 |
165 | Amazon | 11111 |
165 | Paypal | 22222 |
Please find the below screenshot depicting BAI2 file format for better understanding:
As per the standard config of EBS, system won’t allow us to assign more than one posting rules for a single business transaction code (BTC) in T-code OT83.
As per the aforementioned screenshot, the posting rule “ZAUP” is mapped against BTC “165” to post the note to payee lines for GE Capital, American Express and Amazon. However going by the business requirement, Note to payee line “Paypal” needs to be posted separately using different GL “22222”.
The desired business scenario can be achieved by following the below-mentioned steps:
Srch strg name: Enter a text to identify the search string.
Description: Enter Description.
Search String: Enter unique text “PAYPAL”.
Remove “PAYPAL” manually from target field as highlighted above and populate it using newly defined posting rule “Z001”.
Save the screen.
Now select “Search string use” from the Dialog Structure and do the requisite mapping as depicted in the below-mentioned screenshot:
In the column “Target Field”, select “Posting Rule” from the drop down and save the screen.
Import EBS file into the system using T-code FF_5.
Regards,
Mohammed Kalim.
In order to have the field LFB1-XVERR available on modifying the vendor master record, there are five conditions that should be fulfilled:
The same conditions should be fulfilled for the field KNB1-XVERR.
To perform the clearing between a Customer and Vendor, follow the SAP help below:
Clearing Between a Customer and Vendor - FI Accounts Receivable and Accounts Payable - SAP Library
Hello Reader,
I would like to share the knowledge I gained around Electronic Bank Statement (aka EBS) processing. After avoiding it for several years, finally the time turned on me. What appeared as cumbersome all these years, is actually very interesting and logical
To begin with, I would like to start with a very basic topic - Interpreting the BAI2 file. There are many other prevalent formats for EBS like MT940 / Multi Cash Format, etc.
The BAI2 file is a plain text file (.TXT Format), which contains values / texts one after the other. Hence, interpreting that becomes a bit tedious. Usually, one should request a BAI Statement Guide from the Bank / End Client to interpret the BAI2 file. A Sample BAI2 Statement Guide is attached at the end of this document
For now, I will make an attempt to explain what and how does a BAI2 file contain. Other Bank statement formats (MT940, etc.) also have a similar science surrounding them
This is how a BAI2 bank statement file looks like.
With the help of colour coding, lets understand how to interpret the key elements in the above file.
The data records in the screenshot above are depicted in the below excel sheet. With different colour coding for various key elements, I shall try to explain what do they mean
The file records with 01, 02 and 03 contain the basic information with regards to Bank Routing No (Bank Key). Statement generation date, Statement date, Bank Account no., Opening Balance, etc
The file records with 88 always contain some extra information about the preceding record. In the above screenshot, the records with 88 after the 03 record, contain information about Closing Balance, Total Debits and Total Credits
The file records beginning with 16 contain the transactional information - Checks In / Out, Wires In / Out, Bank Charges, Bank Interest, etc. Each one of these transactions is represented by a unique transaction type. For example, 475 for Checks Out, 354 for Interest Income, etc. We use these transactions to trigger the various postings in the FI - General Ledger
If some extra information is there about a particular transaction, the data record 16 will follow with a 88 data record (See below). The 88 record usually serves the purpose of "Note to Payee" wherein Invoice Reference or some Unique reference about the transaction is stored. Using this information, for example, an incoming check from a customer can be used to clear the invoice
The records 49, 98, 99 appear at the end. These signify the closure records of the Bank Statement.
I hope this simple explanation helps you to understand the basics of BAI2 file.
The link to download the BAI2 Statement Guide is here: BAI2 File Format Guide 091208.doc - Google Drive
Please do share your feedback on the same and we can improve it
SAP ERP Financials - ControllingSAP ERP Financials - Asset Accounting
Regards
Ajay Maheshwari
Visit my Facebook page www.facebook.com/madaboutsap
--Came accross one more issue I faced for one of my substitution rules, hence adding the same--
Hello Readers,
We use substitutions for various requirements quite frequently in SAP and face lots of issues while using them.
The objective of this document is to show the best practices, provide some useful tips while creating substitutions and to address some common issues. This document deals only with Substitutions in FI.
Always simulate the substitution in the development system before it is transported to the Production System. SAP provides this beautiful functionality to simulate the substitution. This will bring out the errors in development system itself before it is transported to Production.
Click on the main Substitution Set and not individual step and then simulate as below
Activate Trace is similar to Simulation. Activate Trace works at the time of posting the document. If the pre-requisites are met and fields are substituted, it will give the results as TRUE and also provide value of substituted field. If pre-requisites are not met, it will show result as FALSE.
Activate Trace as shown above. Then try to post a document (with FB01 for e.g.). If trace is activated for header level substitution, then as soon as you enter the header data, a screen will pop up which will show all substitutions at header level.
Activate total trace is similar to activate trace. The difference is that with Activate Total Trace all the substitutions (irrespective at header / line item( will be checked at the time of posting the document while in Activate Trace you can simulate specific at header / line item level.
Expert trace is like debugging facility. You need to click on individual step and then activate expert trace. While posting the document, it will take you into the debugging mode if that substitution is triggered. This is an important functionality to analyze the substitution.
This program should be run in the target system once the substitution is transported. It re-generates the ABAP coding for Substitutions, Validations and rules. It is a good practice to run this program to avoid any issues.
1.XXXX field not available for Substitution:
This is the most common issue faced my many of us. Standard SAP does not allow all the fields at header and line item level to be substituted since it can lead to inconsistency of data in other modules like MM, CO etc. The fields which are available for substitution can be seen in the table below,
GB01 - Classes for Boolean Formulas:
In the last column exclude,
- if it has X, then it means it is not available for substitution
- if it is blank, then it can be substituted
If you want to make the field available for substitution, then it can be done by removing the X from exclude field in table GB01. This can be done by making changes in the view VWTYGB01 using SM30 transaction code
Precautions:-
2. Substitution XXXX not found - Error No GB 127
I would call this error as fatal since this will not allow posting of any FI documents in SAP.
There are two TR's created when you create the substitution for the first time
a. Customizing TR - for assignment of Substitution to the company code
b. Workbench TR - for transport of the substitution
You need to ensure that both the TR's are transported and not only one. Also run the program RGUGBR00 once it is transported. Further all the related TR's like for set, user exit etc. should be transported as well. This will avoid such kind of an error.
3. User exit assignment is missing after the transport has moved:-
Below are some of the common reasons because of which the user exit assignment might be missing in the substitution in target system.
a. The transport for user exit was not moved to Production system. This is the most common mistake.
b. Any transport related to changes in table GB01 (fields made available for substitution) was not transported along with substitution TR's. Once this is transported, the assignment will appear.
4. When you double click on the user exit, it says 'object not found'
Even though you execute program RGUGBR00 after transport movement, sometimes you get the error 'Object not found' when you double click on the user exit. In such a scenario, you need to execute below command in the program where all user exits for Substitutions are stored
Please provide your comments / reviews for any changes to improve the document so that it can be helpful to many.
Thank you!
Best Regards
Aman Goel
Payment order is a Standard SAP tools used in payment process .. its firstly assign a payment order number against the open item paid with no payment entry generated then when processing bank reconciliation if the payment order appear in bank statement the system generates the payment entry and close the open item.. assignment of payment order number is preventing from duplicate payment ..
The configuration steps is:
T-code: OT84
- ( Create account symbols) Y12 “Payment Order”
Posting Area 2 “Sub ledger posting “
Document Type: KZ
Posting Type : 7 “clear Debit Sub ledger account
Interpretation Algorithm : 29 “Payment order”
You have to add the payment order to variant
Note that the payment order will not appear in FBL*N report due to standard SAP behavior .. you may refer the below link to insert the payment order number in FBL*N report
How to insert Payment Order in FBL1N or FBL5N
Regards
Mahmoud EL Nady
call function 'RKE_CREATE_BATCH_INPUT'
exporting
erkrs = p_erkrs
group = p_sesion
user = sy-uname
tables
ep_tab = it_batchinput
fieldtab = it_dbtable
exceptions
no_ep_found = 1
others = 2.
submit rsbdcsub exporting list to memory
with bis = sy-datum
with mappe = p_sesion
with von = sy-datum
with z_verarb = true
and return.
Cons of using the FM 'RKE_CREATE_BATCH_INPUT'
call function 'BAPI_COPAACTUALS_POSTCOSTDATA'
exporting
operatingconcern = i_erkrs
testrun = i_testrun
tables
inputdata = t_dat
fieldlist = t_field
return = t_return.
The above BAPI provides the below advantages for postings :
f_dat-record_id = w_recno.
f_dat-fieldname = 'WWTP'.
f_dat-value = w_bukrs.
append f_dat to t_dat.
clear f_dat.
f_dat-record_id = w_recno.
f_dat-fieldname = 'WWACT'.
f_dat-value = <fs_final>-wwact.
append f_dat to t_dat.
clear f_dat.
f_dat-record_id = w_recno.
f_dat-fieldname = 'WWAT'.
f_dat-value = <fs_final>-wwat.
append f_dat to t_dat.
clear f_dat.
f_dat-record_id = w_recno.
f_dat-fieldname = 'VRGAR'.
f_dat-value = 'J'.
append f_dat to t_dat.
clear: f_field.
f_field-fieldname = 'WWTP'.
append f_field to i_field.
clear: f_field.
f_field-fieldname = 'WWACT'.
append f_field to i_field.
clear: f_field.
f_field-fieldname = 'WWAT'.
append f_field to i_field.
clear: f_field.
f_field-fieldname = 'VRGAR'.
append f_field to i_field.
Call function 'BAPI_COPAACTUALS_POSTCOSTDATA'
exporting
operatingconcern = i_erkrs
testrun = i_testrun
tables
inputdata = t_dat
fieldlist = t_field
return = t_return.
If the posting is successful
if sy-subrc is initial .
call function 'BAPI_TRANSACTION_COMMIT'
exporting
wait = 'X'.
Endif.
SAP standard Report for testing the above BAPI:
Incoming payment advice notes Electronically payment can be received from a partner (payment advice note/note about a debit memo/note about a bank collection) or from a bank (credit memo/debit memo).The payment advice note is stored in the note data bank and is then available to clear open items. Note can be used to generate an advice note for cash management and forecast or to clear the open item automatically. Below mentioned customization needs to be performed for the processing of incoming electronic payment advices and to clear the open item.
Step 1 – Partner Profile need to be set up (for each relevant customer/ vendor account, a partner profile needs to be set up) and configured. Following selections must be made for each profile:
• Partner number = customer/ vendor account number
• Partner type: LI for vendors and KU for customers
• Inbound parameters:
o Message type: REMADV [standard SAP IDoc for EDI payment advice]
o Process code: REMA (No further processing)/ REMC (Automatic further processing)
o Syntax check (activated) o Trigger immediately (activated)
T-code: WE20
Step 2 - Set up selection rules per customer/ vendor individually to define the criteria that shall be used to search the open items in customer/ vendor sub ledgers Path - SPRO => Financial Accounting => Accounts Receivables and Accounts Payable => Business Transactions => Incoming Payments => Incoming Payments Global Settings => Payment Advice Notes (Incoming)
Step 2.1 - Define payment advice types – In this step, following attributes for the payment advice types are define by the system:
1. Minimum retention period in the system - In this case, user can specify the number of days a payment advice note must be in the system before it may be deleted
2. Authorization group – In this step user can assign authorizations for entering, changing, displaying and deleting payment advice notes. Payment advice type -06 is being used for the electronic payment advices
Step 2.2 - Choose selection fields for payment advice notes - In this step, User can specify the fields via which the system is to make selections when displaying payment advice items.
Step 2.3 - Choose External Selection Fields for Payment Advice Notes - In this step, user can define external selection fields. These are used for identifying invoices, such as from delivery note numbers, for which no fields exists in Financial Accounting.
Step 2.4 - Define selection rules - In this step user can define the identification for the clearing.
Step 2.5 – Allocate Selection fields – In this step user can assign internal selection fields, that is, selection fields the system knows, to external selection fields (data the customer sends you, such as a delivery note number) under a certain selection rule. This assignment is necessary to ensure the correct identification of the open items.
Step 2.6 - Payment Advice Overview: Define Line Layout - In this step, User can determine which information is to be made available on the screen for the payment advice overview (such as payment advice item, document number, selection.
Step 2.7 - Payment Advice Overview: Choose Standard Line Layout - In this step, User can define standard default values for the line layout.
Step 3 - Define Posting Keys and Posting Rules for Manual Bank Statement - In this activity user can define posting keys and posting rules. Posting rule will be used in next step. Path - SPRO => Financial Accounting => Bank Accounting => Business Transactions => Payment Transaction => Manual Bank Statement => Define Posting Keys and Posting Rules for Manual Bank Statement
Step 4 – Define Further Processing of Payment Advice Notes – This step is used to define further processing of payment advice notes (to either process the payment advice note automatically or to park the payment advice). In this activity, user can determine which further automatic activities should take place for electronically transferred payment advice notes. Posting rule for the clearing document is determined from this customization.
Step 5 – Define Ports for processing incoming electronic payment advice. T-code: WE21
Step 6 - EDI profiles in vendor and customer master data need to be activated. In field status groups of all vendors and customers the field “Payment advice via EDI” needs to be set to required or Optional.
Step 7 – “Pmt adv. By EDI” check needs to be checked for Customer / Vendor master data
Conclusion – Incoming payment advise can be posted with the clearing of open item by maintaining the above customization.