In Lockbox Data Overview, transaction FLB1, you can set manually lockbox checks as status applied but you cannot track all checks that were manually changed, no log is created in system. This is a standard behavior and this functionality is not available.

Automatic Payment Run Scheduling (T-Code: F110S or Program: RFF110S)

F110S report is used to schedule payment program SAPF110S in the background. Program: RFF110S offers the same parameters as in transaction F110S. You need to create a variant so as to schedule F110 at background.

The selection screen gives you the essential parameters for the payment program SAPF110S. This is where you enter your payment run parameters as in transaction F110, and save them as a variant.

Output: The report first creates a parameter record for the payment run. After this, depending whether you have set the parameter as Proposal or payment run it will be started. If you select the flags 'With Lists' or 'With Print Programs' then after the payment program the list or data medium programs are started. You can view the output of the report in the job log with T-Code: SM37). The status of the payment run is displayed online in transaction F110 from the time at which the parameters were generated by report RFF110S.

Step 1: Run TCode: F110S or program RFF110S in TCode: SE38

Execute the program RFF110S or Transaction: F110S, both will take you to the same screen.

Maintain the input parameters as below:

Note: The job to schedule Proposal and payment run in the background is the same Program " RFF110S" but the only difference which makes it either a Proposal or a Payment run is the tick in the second block in Execution in "Proposal Run".

So if you have ticked Proposal run only the proposal will get executed, but Payment Run please check that the Proposal run should not be ticked as it is Payment that you want to run this time.

Go to Program »Execute in Background

Input the Print Parameters as below:

Enter

Click on

You can schedule the job immediate or for schedule date and time for the future with Date/Time option.

Click on and a background job gets created as below:

Check the Job Log with TCode: SM37

You can access the log of the scheduled payment run and also the lists generated both via job administration (the update run is scheduled under F110 - 'Date' 'Identification').

Best Regards,

Mukesh Sharma

This document explains capabilities of search strings in electronic bank statement processing

Electronic Bank Statement is one of the most widely used functionality to automate bank reconciliation and related posting. It can be further optimized by use of ‘search strings’. Search strings by reading strings in “Note to Payee” can help EBS further automate functions like changing posting rule, populating values from EBS file to assignment field in accounting document, skip processing of bank code for specific house bank etc. We will see all these functionality in detail.

Passing values from EBS file to assignment field in accounting document

Once electronic bank statement is posted it becomes difficult to match accounting document with physical bank statements based on just amounts and date. Using search string we can pass specific string (e.g. reference number) from electronic file to assignment field in line item of “Wires/Check in clearing” account. This value in assignment field in line item of “Wires/Check in clearing” account can be useful in setting up automatic clearing of “Wires/Check in clearing” account. For example where receivables (Non-Lockbox) are post processed after posting of EBS (e.g. inter-company receivables), line items in clearing account can be cleared by background job for T-Code F.13.

1. Incoming Electronic Bank File (BAI format):

Electronic Bank file can be in many formats like MT940, MULTICASH, BAI etc. Shown below is one sample file in BAI format where reference number generated bank is in specific format. We want to pass reference number for each bank code in Assignment field in line item of clearing account –

2. Configuration of Search String -

To pass value from ‘Note to Payee’ to accounting document we need 2 search strings.

a) First one to identify the target field in accounting document for search string and,

b) Second one to pass bank reference value in assignment field.

Search String definition-

For configuration follow path - SPRO > Financial Accounting (New) > Bank Accounting > Business Transactions > Payment Transactions > Electronic Bank Statement > Define Search String for Electronic Bank Statement.

Configuration of first search string (BANK REF. IDENTIFIER) to identify the target field in accounting document:

Please note that there is no mapping for this search string as it is only used to identify the target field in accounting document. In our example in BAI file bank reference comes in format “IA123456789012” or IA1234567O9012 where first 2 characters are constant (IA) followed by 12 numeric values where 8^th character can be alphabet “O” or a number. In SAP performance assistant you can see how to configure search strings. I have configured search string as follows:

First 2 characters I and A as constant.
Next 7 characters as numbers. Numbers in search strings are identified by sign ‘#’.
8^th character as (#|O), which means 8^th character can be an alphabet ‘O’ or a number. System will identify string in both the cases.
Last 4 characters as numbers.

For different banks format of reference value can be different. However, it should have some unique identification like in our example it starts with ‘IA’, so that system can uniquely identify the string.

Configuration of second search string (BANK REF. POSTING) to pass bank reference value to assignment field –

Please note that here I have configured search string exactly as the first one but it has mapping. If search string has mapping it means that value will be passed to accounting document.

Search String Use-

Search strings are assigned to combination of Company Code/House Bank/Acct ID/Bank Code. To pass value to specific field in accounting document we will use BDC Fields.

BDC fields work as follows (Excerpt from SAP Performance Assistant) –

The BDC fields are a means of filling screen fields if there is no suitable target field in the bank data store. You must know the technical name of the relevant screen field (if you do not know it, use the F1 help to find it out).For example, if you want to transfer a control indicator in the event that the key word "TELECOM" appears in the note to payee, you can proceed as follows:

Use the search string TELECOM with mapping " " (all blanks) for the three target fields "BDC Field Value 1", "BDC Field Name 1" and "BDC Account Type 1". The constants to be entered in the individual BDC fields are always stored in the "Mapping Basis" field:

BDC Field Value 1 = "V1"

BDC Field Name 1 = "BSEG-MWSKZ"

BDC Account Type 1 = "0"

If you want to transfer the content of only one particular line, you can use the "BDC Account Type" field to control the process. If you enter the constants 0, 1, 2, or 3 in this field, the transfer only takes place as specified. The constants here mean the following:

0: First line, posting area 1

1: First line, posting area 2

2: Second line, posting area 1

3: Second line, posting area 2

If you do not control the transfer in this way, the system tries to transfer the screen field defined under "Field Name" in all the posting lines in posting areas 1 and 2. This cause an error on the grounds that the field does not exist (for example, because a control indicator for a particular account does not accept input.

In the control indicator example, note that you must set the "Calculate Tax" indicator too, so that the posting can be made automatically. You then need the following settings in addition:

BDC Field Name 2 = "BKPF-XMWST"

BDC Field Value 2 = "X"

BDC Account Type 2 = "0"

Continuing to our configuration proceed as follows-

1. For relevant Co Cd/House Bank/Acct ID/Bank Code combination assign first search string (BANK REF. IDENTIFIER) to “Target Fields” “BDC Field Name 1” and “BDC Account Type 1”.

2. For same combination in step 1 assign second search string (BANK REF. POSTING) with target field “BDC Field Value 1”.

3. Assign following values to fields “Mapping Prefix”:

BDC Field Name 1 - BSEG-ZUONR (Target field)

BDC Account Type 1 - 2 (Target line)

BDC Field Value 1 - IA000000000000 (Target value)

Once above configuration is ready, for that specific Company Code/House Bank/Acct ID/Bank Code system will read any search string with format IA############ or IA########O#### and pass that value to assignment field of clearing account. Of course you will have to configure your search string according to your requirements.

3. Changing the posting rule for same bank code:

It may be possible that a bank code is posting to specific set of GL accounts via a posting rule; however we want to change GL account posting for the same bank code. It may be possible for example bank uses same code for ACH OUT and ACH RETURN. We will want system ACH OUT to post by debiting ACH OUT account and crediting Main Bank Account. However when there is ACH return we want to reverse the posting. In case bank uses same bank code however in note to payee gives information in the form of string “ACH RETURN”, we can configure a search string to identify such returns and change the posting rule for reversal. Example:

Bank Code for ACH OUT – 169

Posting rule for ACH OUT - WF08; debits ACH clearing account, credits bank account

Posting rule for ACH RETURN – WF10; debits bank account, credits ACH clearing account,

BAI file comes as shown below for ACH out –

BAI file comes as shown below for ACH return –

For ACH out posting would have been gone through posting rule WF08 which is configured as shown below –

We want to substitute posting rule WF08 with posting rule WF10 for bank code 169 if note to payee has string “ACH RETURN”. For ACH RETURN search string can be defined as shown below –

Assign search string configured above in node “Search String Use” as follows:

Assign search string “ACH RETURN” to relevant Company Code/House Bank/Acct ID/Bank Code combination. Select target field as “Posting Rule”. Assign “Mapping Prefix” as WF00. When substituting posting rule WF08, system will take “WF” from mapping prefix and “10” from search string definition. Mapping prefix works as follows (Excerpt from SAP help) –

A string of characters you can define yourself to have the funds center found "filled out" in the event of a successful search if it is too short.

The prefix should be the same length as the document numbers being searched for in the system. The later part is then replaced with the search string found.

If a "hit" is longer than, or as long as, the relevant prefix, the hit overwrites the whole prefix.

Use

This function is particularly useful for filling in redundant parts (such as leading zeros) when the reference information is incomplete.

Example

Prefix "1800000000" and hit "12345" results in number "1800012345".

Once above configuration is in place any file with bank code 169 assigned for house bank and account when loaded with string ACH RETURN will replace the posting rule WF08 with WF10.

Email Sending Functionality for Different Business Process in Sap

Nov, 2013

Introduction

Every Business Process in SAP Follow different communication types to communicate with its Business partners like Print and send via post, Fax, and Email (Internet).Several E-mail communications need to be sent to Vendors & Customers who are the business partners for the organization which contains several Business Processes like Payment Advice, Dunning forms and PO’s etc., with PDF and Excel as attachment, which is a very eco-friendly way. Presently many are using the process of taking a print out and sending it through the post. This Process has lot of paper wastage. So instead of this we can send a mail which saves lot of paper wastage .This process enables the Go green Initiative and reduces lot of manual effort. With the recent releases in SAP all the Business process are enhanced with Email sending functionality.

Introduction to Email Processes

Every Standard FI process like Dunning and Payment and collection advice has a default way of sending there notices to the customer or vendor by post. Sending a mail is not a standard SAP functionality; in order to achieve this nonstandard Functionality we have BTE. This is an enhancement technique (Open FI) that was developed for Financial Accounting component. This functionality is primarily used in FI in the areas of dunning, Payment advice Customer and Vendor Statement etc. Each of them has their own Function modules which will not interfere with each other.

Each of these has a BTE’s enabled to fill the FINNA-NACHA structure to determine whether the output should be sent as fax, print via post or email, i.e., if FINAA-NACHA = 1 - print via post and FINAA-NACHA = ‘I’ its email and if its ‘2’ FAX.

This Document contains how this mail functionality can be achieved by using the BTE’s for Different applications in FI.

1. Application Area: FI - Accounts payable and Accounts receivable – Dunning

Application of the process BTE event '00001040' -

· This process BTE is useful during a dunning run when a dunning notice needs to be sent to the customer by the medium of an electronic form (EMAIL).
As a default property, the dunning notice gets printed and is sent to the customer either by scanning the copy or via 'POST'.

· This same dunning notice could be a very beneficial if it is sent by means of electronic form directly after the dunning has been carried out.

· So, to achieve this non-standard functionality we need to enhance the standard process.

Transaction - FIBF -> Environment -> Info systems (Processes)

· Click on execute,

· Select the BTE 00001040 as it deals with the Output device/medium

· Change the Already Present function module to Z function Module.

Now, technically the BTE is ready to work as we have registered the BTE.

As a functional aspect, the following things are needed to be taken care of.

· Standard communication option - to 'EMAIL' in the 'General' Tab in customer master 'XD02/01'.

· After configuring these basic steps, the BTE is complete to trigger for dunning run for this particular customer.

Dunning Run

· SAPF150D2-This Program can be used to execute the Dunning form by giving the Run date and identification and the logic in the FM's can be checked by placing the debugger.

· Best way is to check in the debugger,

Ø FINAA-NACHA - For Communication Medium (I- Internet, 1-Print Out, 2-Fax)

Ø FINAA_INTAD – Email Address to send the PDF

Ø Process the next step by confirming the 'Send to mail' dialog,

Ø If 'C_FINAA-INTAD' is left blank the system will pick from the customer master 'Clerks internet', else it will take from the value 'C_FINAA-INTAD'. This enables the PDF sending functionality which enables is standard process and the logic to send excel can be written in the above FM only. Also if you need to fill the Subject of Email use itcpo-tdtitle structure which of 50 characters. If we need to send the Body also Maintain the standard text as mentioned in the below screen shot.

NOTE: If we need to send many attachments other than PDF we have to write the code in the above FM call the common mail sending functionality. In this case first a mail will be sent with Excel or some other as attachment then the standard PDF functionality is called.

This is a very eco-friendly means of informing the customers for their over-due items.

2. Application Area: FI – Payment Advice and Collection Advice:

Application of the process BTE event '00002040' –

This BTE is called in the standard include RFFORI06 as shown below.

· In the transaction FIBF Select the BTE 00002040 as it deals with the Output device/medium sample_process_00002040 will be assigned.

· Since this is not a standard functionality we need to enhance the FM so copy the

sample_process_00002040 into Zsample_process_00002040.

Logic in the FM

Check if customer or Vendor has Email Maintained in the Master Data. If it’s maintained then

· The structure c_finna included the internet address.

We set the transmission medium to ‘I’ as below.

c_finaa-nacha = 'I'.

c_finaa-intad = l_smtp_addr(130). [The email Obtained from the master data]

· Later the mail sending functionality can be called after the close_form as shown in the below screen shot or By OTF data and excel can be created using the tab_regup structure in the form avis_schreiben.

3. Application Area: FI – Customer/Vendor Balance Confirmation:

Application of the process BTE event '00002410' –

· This process BTE is useful during a Customer/Vendor Balance Confirmation form which needs to be sent to the Customer/Vendor by an electronic form (EMAIL). By default, the form is sent to the Customer/Vendor either by Fax or via 'POST'.

· But as an environmental aspect to avoid wastage of paper, the same Statement could be sent by means of electronic form directly after the Customer/Vendor Statement run has been carried out.

· So, to achieve this functionality we need to enhance the standard process.

Transaction - FIBF -> Environment -> Info Systems (Processes)

· Click on Execute.

· Select BTE 00002410 as it deals with Determining the Output Device

· Click on Sample Function Module. The FM 'SAMPLE_PROCESS_00002410' is assigned. In order to include the mail sending functionality, Copy the Function Module into a Z Function Module and make the required changes to enable the mail sending functionality.

Logic in the FM:

Check if the Customer or Vendor has Email Maintained in the Master Data. If it is maintained then

· The structure c_finna includes the internet address.

We set the transmission medium to ‘I’ as below.

C_finaa-nacha = 'I'.

C_finaa-intad = l_smtp_addr(130). [Email Obtained from the master data]

· Later the mail sending functionality can be called after the Close_form as shown in the below screen shot or By OTF data, and excel can be created using the Structure HBSIDH for Customer and HBSIKH for Vendor.

4. How to achieve Mail Functionality Technically:

Create a Common Functionality for sending mail using classes

i) For sending the subject greater than 255 characters

· At present using the FM SO_DOCUMENT_SEND_API1 has the capability of sending only 50 characters but using the below method of the class the subject more than 255 characters.

· So cl_bcs class is used for the below purpose.

· There is also any option of changing the sender ID in case the requirement is not to use the

· SAP master User ID using the cl_bcs class.

· Create the below object of type cl_bcs and call the method set_message_subject

          w_send_request     TYPE REF TO cl_bcs           VALUE IS INITIAL,
      CALL METHOD w_send_request->set_message_subject
        EXPORTING
          ip_subject = subject.

ii) For Sending Multiple Attachments like PDF and Excel

· In case multiple attachments the below method add_attachment attachment can be used by looping on the attachments obtained to this function module.

f_ATTACHMENTS TYPE RMPS_T_POST_CONTENT

w_document TYPE REF TO cl_document_bcs VALUE IS INITIAL,

LOOP AT attachments INTO f_attachment.

w_attachment_subject = f_attachment-subject.
w_filesize = f_attachment-docsize.

· This Method will have the option to take input as method subject, filesize and
        w_document->add_attachment(
        EXPORTING
        i_attachment_type    = f_attachment-doc_type
        i_attachment_subject = w_attachment_subject
        i_attachment_size    = w_filesize
        i_att_content_text   = f_attachment-cont_text[] ).

      ENDLOOP.

iii) For Sending Email to multiple recipients like To, BCC and CC,

· The below Logic can applied to provide cc bcc and to as like multiple receivers. The method

add_recipient has the option to give blind_copy, Copy and recipient.

w_recipient TYPE REF TO if_recipient_bcs VALUE IS INITIAL,

· Loop at the multiple receivers

LOOP AT receivers INTO f_receivers.

w_recipient_mail = f_receivers-receiver .

· The below method sets them mail ID of the Receiver.
w_recipient = cl_cam_address_bcs=>create_internet_address(
w_recipient_mail).

        w_send_request->add_recipient(
            EXPORTING
            i_recipient = w_recipient
            i_express = 'X'
            i_copy = f_receivers-copy
            i_blind_copy = f_receivers-blind_copy).
ENDLOOP.

Continuing with the New G/L accounting Part -1 covered under: New General Ledger Accounting - Part 1

In this document we will be covering one of the major topic in New General Ledger Accounting i.e. Ledger which includes Leading and Non-Leading Ledger overview along with the configuration steps.

LEDGER

A ledgeris a section of a database table. A ledger contains only those dimensions of the totals table that the ledger is based on and that are required for reporting.

The following types of ledgers are available:

Leading Ledger

The leading ledger is based on the same accounting principle as that of the consolidated financial statement. It is integrated with all subsidiary ledgers and is updated in all company codes. In each company code, the leading ledger automatically receives the settings that apply to that company code for local currencies, fiscal year variant, and posting period variant.

There has to be exactly one leading ledger. The leading ledger gets many of its "control parameters" from the company code. Company codes gets automatically assigned to the leading ledger (cannot be deactivated).

Group valuation is done at leading ledger. The leading area of asset accounting (area 01) is posted to the leading ledger. Controlling is integrated to the leading ledger.

Non-Leading Ledger

The non-leading ledgers are parallel ledgers to the leading ledger. They can be based for example on local accounting principles. You must activate a non-leading ledger by company code.

Note:

SAP provides the leading ledger 0L and totals table FAGLFLEXT with the standard system.

Only the values from the leading ledger are posted to CO in the standard system The non-leading ledgers can then be assigned to currencies and fiscal year variants that differ from the leading ledger.

There can be only one leading ledger for the New G/L, but you can have number of non-leading ledgers.

Ledger Configuration steps:

1. Define Ledgers for General Ledger Accounting

Create your ledgers for General Ledger Accounting and set the Leading indicator for one of the ledgers.

Transaction code	SPRO
IMG menu	Financial Accounting (New) -- Financial Accounting Global Settings (New) -- Ledgers -- Ledger -- Define Ledgers for General Ledger Accounting

0L is the Leading Ledger as per the standard SAP system.

Click on New Entries: Update the following:-

Click on Save. If the ledger is to be a leading ledger you need to select the Leading check box.

Table - FAGLFLEXT

SAP delivers the totals table FAGLFLEXT for General Ledger Accounting in the standard system. When the New General Ledger Accounting is activated, the totals records in General Ledger Accounting are updated in the standard totals table FAGLFLEXT.

The totals table of New General Ledger Accounting (=> FAGLFLEXT) updates more entities than was possible in the classic totals table (=> GLT0).

FAGLFLEXT table—a total of 142 fields which include Cost Center, Profit Center, Functional Area, Business Area, Controlling Area, as well as Account Number, Company Code, and Segment all included in one table. You can also extend this FAGLFLEXT table with additional fields, either predefined SAP fields or new customized fields.

2. Define Currencies of Leading Ledger

This configuration is only required when you want to activate additional currencies for your leading ledger.

Currencies is to be applied in the leading ledger. The local currency (as company code currency) is specified in the company code settings. You can assign multiple currencies to your company code for the leading ledger.

The group currency must be stored in the client definition which can be seen using transaction code SCC4.

Here we can select valuation 1 & 2 only if the following conditions are met:

1) Controlling area has been assigned to the company code

2) A currency and valuation profile is defined in the controlling area

3) The currency and valuation profile is active which has the group and profit center valuation view

Caution

You cannot change the currency type for company codes that are already productive.

Transaction code	SPRO
IMG menu	Financial Accounting (New) -- Financial Accounting Global Settings (New) -- Ledgers -- Ledger -- Define Currencies of Leading Ledger

Double Click on company code to maintain currency.

Click on New Entries

Click on Save.

Currency type

The currency type defines the role of the parallel currency. A distinction is made between the following types of currencies:

Company code currency

Group currency

Hard currency

Index-based currency

Global company currency

Exchange rate type for the translation

The exchange rate type determines the exchange rate, which is stored in the system, is applied in calculating the additional amount fields. As in the case of the local currency, you can use exchange rate type M (average rate) or any other exchange rate type.

Base currency for the translation

The calculation of the amounts in parallel currencies can be determined using the document currency of the local currency.

Translation date

The rate for translation amounts can be based on the translation date, the document date, or the posting date.

3. Define and Activate Non-Leading Ledgers

Here you make the following settings for the non-leading ledgers for each company code:

You activate the non-leading ledgers in the company code.
You can define additional currencies beyond that of the leading ledger. The first currency of a non-leading ledger is always the currency of the leading ledger (and hence that of the company code). For the second and third currencies of a non-leading ledger, you can only use currency types that you have specified for the leading ledger.
You can define a fiscal year variant that differs from that of the leading ledger. If you do not enter a fiscal year variant, the fiscal year variant of the company code is used automatically.
You can specify a variant of the posting periods.

Transaction code	SPRO
IMG menu	Financial Accounting (New) -- Financial Accounting Global Settings (New) -- Ledgers -- Ledger -- Define and Activate Non-Leading Ledgers

Click on New Entries

Update the following:-

Click on Save

Take a drop down in the field FV (Fiscal year variant)

You can even assign a different posting period variant to this ledger

Click on Save.

4. Assign Scenarios and Customer Fields to Ledgers

In this step, we need to assign the following to the ledgers:

Scenarios

Scenarios identify the fields that are updated in Ledgers during posting.

A ledger can be assigned one scenario, several scenarios, or even to all six at once.
The decision as to how many scenarios to assign depends solely on which "facts" / "business aspects" you want to model in the corresponding (non-leading) ledger.

You cannot define your own scenarios.

**Need to activate only the scenarios that you need.

Note: If a scenario is not activated, then it is hard to activate a scenario after GO LIVE. You need to take SAP‟s help to implement it. It is suggested to activate all the scenarios upfront to avoid such hassles.

Custom Fields

You can add custom fields (that you have already defined) to the ledger.

Versions

This enables you to make general version settings for the ledger that depend on the fiscal year. In the versions, you specify whether actual data is recorded, whether manual planning is allowed, and whether planning integration with Controlling is activated.

Transaction code	SPRO
IMG menu	Financial Accounting (New) Financial Accounting Global Settings (New) -- Ledgers -- Assign Scenarios and Customer Fields to Ledgers

Select

Double Click

Click on

Click on Save so as to save the customization.

Similarly Update for Ledger Y1 & Y2.

To assign Profit center update you need to have controlling area assigned to company code and profit center module active.

5. Activate Cost of Sales Accounting (Optional)

Transaction code	SPRO
IMG menu	Financial Accounting (New) -- Financial Accounting Global Settings (New) -- Ledgers -- Ledger -- Activate Cost of Sales Accounting

6. Define Ledger Group

A ledger group is a combination of ledgers for the purpose of applying the functions and processes of general ledger accounting to the group as a whole.

You do not need to create a ledger group for all ledgers because the system automatically posts to all ledgers when you enter a ledger group in a function.

Representative Ledger of a Ledger Group

The system uses the representative ledger of a ledger group to determine the posting period and to check whether the posting period is open.

If the posting period for the representative ledger is open, the system posts in all ledgers of the group, even if the posting period of the non-representative ledgers closed. Each ledger group must have exactly one representative ledger.

If the ledger group has a leading ledger, the leading ledger must always be identified as the representative ledger.

We do not want to group the ledgers, therefore we do not do any configuration here.

Transaction code	SPRO
IMG menu	Financial Accounting (New) -- Financial Accounting Global Settings (New) -- Ledgers -- Define Ledger Group

In the Series with New G/L Accounting Customization, will come up next with Parallel Accounting & Parallel Ledger.

Refer toNew General Ledger Accounting - Part 1

Appreciate to have your views, comments and suggestions.

Warm Regards,

Mukesh Sharma

Overview on New G/L Accounting

A highly competitive, increasingly global economy and a rapidly changing regulatory landscape have increased the demands on varied reports in general-ledger accounting and related businesses, as a result New GL Accounting has been introduced by SAP. The New G/L overcomes the shortcomings of traditional G/L accounting by providing a single robust application with a unified interface catering both financial and management accounting.

The New G/L approach was developed to accommodate the numerous requirements for legal, managerial, country, and local accounting practices. Basically, this approach brings together much of the reporting and analysis completed separately by several different components in the ECC system.

With New G/L, SAP incorporates additional functionality that will offer information which otherwise normally obtained from the areas of the classic FI module, the Cost of Sales Ledger, the reconciliation ledger used to validate and reconcile data between FI and CO, the managerial reporting handled by the CCA and PCA modules (segment reporting) within ECC, and the reporting and analysis available by using the Special Purpose Ledger process.

In this way, the New G/L Accounting serves as a complete record of all business transactions. It is the central and up-to-date component for reporting. All posted transactions can be checked at any time in real time.

Advantages/ Benefits with the New General Ledger Accounting

New G/L provides flexibility, new and improved functionality, such as document splitting, parallel accounting, segment reporting, as well as improved integration with other applications.

Comparative Analysis between New G/L and Classic G/L

New G/L and Classic G/L are two ways to implement General Ledger functionality in SAP ECC5 and ECC6 respectively. New G/L provides lot of benefits over classic G/L. The New G/L benefits

- Provide an extension to the existing functionality in classic G/L, or

- Provide new functionality compared to classic G/L, or

- Provide a technologically superior way to perform a functionality in Classic G/L

It is imperative to understand the differences between Classic and New G/L to be able to understand which solution addresses the business requirements better. I am providing a comparative analysis of the basic differences between Classic and New G/L.

In the classical approach, users would have to retrieve information through various areas outside of the G/L, such as the special purpose ledger.

A Comparisons:

(1) Extended Data Structure provides flexibility

SAP has consolidated the multiple totals table (GLT0, GLPCT etc) in classic G/L into a single FAGLFLEXT Totals table with New G/L. One Summary Table provides flexibility and faster response time for reporting. FAGLFLEXT can also be enhanced by adding customer defined fields.

(2) Reconciliation

No automatic reconciliation existed between G/L and applications, as a result closing activities used to take several weeks or months, considerable time was lost on preparing the financial statements.

(3) Segment reporting to ensure Statutory Requirements

New G/L has document splitting functionality that enables segment reporting. Standard Segment Reporting functionality is not available in Classic G/L.

(4) Real Time Integration between FI and CO

Classic G/L has the period-close reconciliation ledger functionality to synchronize FI and CO for cost transfers across functional area, business area and company code originating in CO. New G/L has a real-time integration between FI and CO.

(5) Parallel Accounting

New G/L provides Non-leading ledgers for parallel accounting like IFRS and GAAP. Parallel accounting can also be implemented using Account based approach which is also available in classic G/L.

(6) Reduce TCO by Faster Period Close Activities

Faster Period Close is possible with New G/L as,

a. Reconciliation Ledger is not required

b. Balance sheet Adjustments are not required

c. Profit and Loss Adjustment are not required

d. Activities related to Special Purpose Ledger are not required

e. Depreciation posting is online instead of a batch session

(7) Flexible Drill-down Reporting in New G/L

New GL has advanced drill-down capabilities by segment and other characteristics.

Totals Table

A totals table is a database table in which totals records are stored. A totals table is used in General Ledger Accounting (New) as the basis for your parallel ledgers. It offers a number of dimensions. SAP delivers the totals table FAGLFLEXT for General Ledger Accounting in the standard system.

When the New General Ledger Accounting is activate, the totals records in General Ledger Accounting are updated in the standard totals table FAGLFLEXT.

The totals table of New General Ledger Accounting (FAGLFLEXT) updates more entities than was possible in the classic totals table (GLT0).

With the standard table, you can easily activate support for many scenarios, thereby supporting segment reporting, profit-center updating, cost of sales accounting, business area update and many more. Even you can define your own table - if there is very large volume of data or very different characteristic values - using FAGLFLEXT as the template.

Business Scenario:

Group of companies IBM is a multinational company with companies across the world with base in US. The company has decided to implement SAP for its subsidiary IBM LLC, US. Group of companies have to use the common chart of accounts 1000. The currency for US is USD. The Parent company wants the accounts to be prepared based on Calendar year January to December.

IBM LLC has a local reporting requirement under US GAAP.

IBM LLC also has to maintain financial statements for IFRS

Based on the above requirements we need to configure the following using he New GL:

Create company code IBM LLC. - 1200

The company code currency – USD

Parallel currencies to be implemented – EURO

Common chart of accounts – 1000

Ledger 0L (leading valuation view) reporting period – Jan to December for group reporting

Ledger L1 (additional ledger) for local reporting US GAAP

Ledger L2 (additional ledger) for IFRS (April to March)

Configuration Steps:

Creating Company Code
Activation of New G/L
Ledger
Parallel Accounting
Document Splitting
Document Type
Segment

Configuration Steps:

1. Create Company Code

In SAP, a company code is representative of a stand-alone legal entity that requires its own set of accounting records for reporting purposes.

Company code is the basic organizational unit in FI (Financial accounting) for which a balance sheet and profit & loss account can be drawn.

IMG Menu: Enterprise Structure --- Definition --- Financial Accounting --- Edit, Copy, Delete, Check Company Code

Click the New Entries button:

Company Code: Enter the four-character alphanumeric value of your company code. It is usually good to have the company code numeric (1200).

Company Name: Enter a descriptive name for your company code. This field is alphanumeric and can contain up to 25 characters.

City: Enter the name of the city in which your company is located or headquartered. This field is alphanumeric and can contain up to 25 characters.

Country: Enter the name of the country in which your company is located. This field must contain one of the two-character SAP country values.

Currency: Enter the currency that your company code will operate with and will report in from a tax and statutory accounting perspective.

Language: Enter the one-character language ID for the default SAP language display for the company code.

Click on Save.

A new tab will come up, fill the details as below:

Click on Save.

2. Activation of New G/L

In new installations, the new General Ledger Accounting is activated by default in SAP system. SAP does not recommend that new customers use the classic general ledger accounting.

For Existing Clients: If existing customers want to use New General Ledger Accounting, they first need to activate it using a Customizing transaction. Activating New General Ledger Accounting results in system-wide changes to application and Customizing paths. The activation indicator is set at the client level, so it will become active for all the company codes in that client.

Caution: This transaction is performed at the start of the course to only enable you to explore the new functions. However, In practice execution of this transaction (for existing customers) is one of the last activities performed during the migration project leading up to the implementation of New General Ledger Accounting.

Just to show you how to activate New G/L if it is not yet activated in your SAP system, but it is recommended do not try this in a live/ production system.

Note: This is the first activity which you need to do for configuration of new G/L accounting. In the case of existing customer this should be last transaction after completion of new G/L migration project.

With activating new G/L, it results in wide changes to customization path and table structures. The path for New General Ledger Accounting is added to the existing/classical customization path. In case you want to remove the classical paths which are reflecting int he IMG path. You need to run the program RFAGL_SWAP_IMG_OLD to hide classic G/L configuration path.

If you are already using classic General Ledger Accounting in your production system, you need to perform the migration of this data before you activate New G/L accounting.

Go to SE38 and run program “RFAGL_SWAP_IMG_OLD”

Now New G/L configuration path will be shown. Now you can start configuration for Ledger and other New G/L related configuration.

Upcoming with further configuration on New General Ledger Accounting shortly.

To discover which batch jobs are running for a specific program you have to first find out the program name then use the transaction SM37 to look for the jobs.

To do this follow the steps:

1. Go to transaction SE93 and fill the transaction code and click on Display. In this example we are using the transaction FBL3N;

2. Execute transaction SM37 and enter the program name and Execute. You can also limit your search filling fields Job name, User name and selection Job status and Job start condition;

3. System will show you all jobs related to the program.

This document explains capabilities of search strings in electronic bank statement processing

Passing values from EBS file to assignment field in accounting document

1. Incoming Electronic Bank File (BAI format):

2. Configuration of Search String -

To pass value from ‘Note to Payee’ to accounting document we need 2 search strings.

a) First one to identify the target field in accounting document for search string and,

b) Second one to pass bank reference value in assignment field.

Search String definition-

Configuration of first search string (BANK REF. IDENTIFIER) to identify the target field in accounting document:

First 2 characters I and A as constant.
Next 7 characters as numbers. Numbers in search strings are identified by sign ‘#’.
8^th character as (#|O), which means 8^th character can be an alphabet ‘O’ or a number. System will identify string in both the cases.
Last 4 characters as numbers.

Configuration of second search string (BANK REF. POSTING) to pass bank reference value to assignment field –

Please note that here I have configured search string exactly as the first one but it has mapping. If search string has mapping it means that value will be passed to accounting document.

Search String Use-

Search strings are assigned to combination of Company Code/House Bank/Acct ID/Bank Code. To pass value to specific field in accounting document we will use BDC Fields.

BDC fields work as follows (Excerpt from SAP Performance Assistant) –

BDC Field Value 1 = "V1"

BDC Field Name 1 = "BSEG-MWSKZ"

BDC Account Type 1 = "0"

0: First line, posting area 1

1: First line, posting area 2

2: Second line, posting area 1

3: Second line, posting area 2

In the control indicator example, note that you must set the "Calculate Tax" indicator too, so that the posting can be made automatically. You then need the following settings in addition:

BDC Field Name 2 = "BKPF-XMWST"

BDC Field Value 2 = "X"

BDC Account Type 2 = "0"

Continuing to our configuration proceed as follows-

1. For relevant Co Cd/House Bank/Acct ID/Bank Code combination assign first search string (BANK REF. IDENTIFIER) to “Target Fields” “BDC Field Name 1” and “BDC Account Type 1”.

2. For same combination in step 1 assign second search string (BANK REF. POSTING) with target field “BDC Field Value 1”.

3. Assign following values to fields “Mapping Prefix”:

BDC Field Name 1 - BSEG-ZUONR (Target field)

BDC Account Type 1 - 2 (Target line)

BDC Field Value 1 - IA000000000000 (Target value)

3. Changing the posting rule for same bank code:

Bank Code for ACH OUT – 169

Posting rule for ACH OUT - WF08; debits ACH clearing account, credits bank account

Posting rule for ACH RETURN – WF10; debits bank account, credits ACH clearing account,

BAI file comes as shown below for ACH out –

BAI file comes as shown below for ACH return –

For ACH out posting would have been gone through posting rule WF08 which is configured as shown below –

We want to substitute posting rule WF08 with posting rule WF10 for bank code 169 if note to payee has string “ACH RETURN”. For ACH RETURN search string can be defined as shown below –

Assign search string configured above in node “Search String Use” as follows:

A string of characters you can define yourself to have the funds center found "filled out" in the event of a successful search if it is too short.

The prefix should be the same length as the document numbers being searched for in the system. The later part is then replaced with the search string found.

If a "hit" is longer than, or as long as, the relevant prefix, the hit overwrites the whole prefix.

Use

This function is particularly useful for filling in redundant parts (such as leading zeros) when the reference information is incomplete.

Example

Prefix "1800000000" and hit "12345" results in number "1800012345".

Once above configuration is in place any file with bank code 169 assigned for house bank and account when loaded with string ACH RETURN will replace the posting rule WF08 with WF10.

Email Sending Functionality for Different Business Process in Sap

Nov, 2013

Introduction

Introduction to Email Processes

This Document contains how this mail functionality can be achieved by using the BTE’s for Different applications in FI.

1. Application Area: FI - Accounts payable and Accounts receivable – Dunning

Application of the process BTE event '00001040' -

· This same dunning notice could be a very beneficial if it is sent by means of electronic form directly after the dunning has been carried out.

· So, to achieve this non-standard functionality we need to enhance the standard process.

Transaction - FIBF -> Environment -> Info systems (Processes)

· Click on execute,

· Select the BTE 00001040 as it deals with the Output device/medium

· Change the Already Present function module to Z function Module.

Now, technically the BTE is ready to work as we have registered the BTE.

As a functional aspect, the following things are needed to be taken care of.

· Standard communication option - to 'EMAIL' in the 'General' Tab in customer master 'XD02/01'.

· After configuring these basic steps, the BTE is complete to trigger for dunning run for this particular customer.

Dunning Run

· SAPF150D2-This Program can be used to execute the Dunning form by giving the Run date and identification and the logic in the FM's can be checked by placing the debugger.

· Best way is to check in the debugger,

Ø FINAA-NACHA - For Communication Medium (I- Internet, 1-Print Out, 2-Fax)

Ø FINAA_INTAD – Email Address to send the PDF

Ø Process the next step by confirming the 'Send to mail' dialog,

This is a very eco-friendly means of informing the customers for their over-due items.

2. Application Area: FI – Payment Advice and Collection Advice:

Application of the process BTE event '00002040' –

This BTE is called in the standard include RFFORI06 as shown below.

· In the transaction FIBF Select the BTE 00002040 as it deals with the Output device/medium sample_process_00002040 will be assigned.

· Since this is not a standard functionality we need to enhance the FM so copy the

sample_process_00002040 into Zsample_process_00002040.

Logic in the FM

Check if customer or Vendor has Email Maintained in the Master Data. If it’s maintained then

· The structure c_finna included the internet address.

We set the transmission medium to ‘I’ as below.

c_finaa-nacha = 'I'.

c_finaa-intad = l_smtp_addr(130). [The email Obtained from the master data]

3. Application Area: FI – Customer/Vendor Balance Confirmation:

Application of the process BTE event '00002410' –

· But as an environmental aspect to avoid wastage of paper, the same Statement could be sent by means of electronic form directly after the Customer/Vendor Statement run has been carried out.

· So, to achieve this functionality we need to enhance the standard process.

Transaction - FIBF -> Environment -> Info Systems (Processes)

· Click on Execute.

· Select BTE 00002410 as it deals with Determining the Output Device

Logic in the FM:

Check if the Customer or Vendor has Email Maintained in the Master Data. If it is maintained then

· The structure c_finna includes the internet address.

We set the transmission medium to ‘I’ as below.

C_finaa-nacha = 'I'.

C_finaa-intad = l_smtp_addr(130). [Email Obtained from the master data]

4. How to achieve Mail Functionality Technically:

Create a Common Functionality for sending mail using classes

i) For sending the subject greater than 255 characters

· At present using the FM SO_DOCUMENT_SEND_API1 has the capability of sending only 50 characters but using the below method of the class the subject more than 255 characters.

· So cl_bcs class is used for the below purpose.

· There is also any option of changing the sender ID in case the requirement is not to use the

· SAP master User ID using the cl_bcs class.

· Create the below object of type cl_bcs and call the method set_message_subject

          w_send_request     TYPE REF TO cl_bcs           VALUE IS INITIAL,
      CALL METHOD w_send_request->set_message_subject
        EXPORTING
          ip_subject = subject.

ii) For Sending Multiple Attachments like PDF and Excel

· In case multiple attachments the below method add_attachment attachment can be used by looping on the attachments obtained to this function module.

f_ATTACHMENTS TYPE RMPS_T_POST_CONTENT

w_document TYPE REF TO cl_document_bcs VALUE IS INITIAL,

LOOP AT attachments INTO f_attachment.

w_attachment_subject = f_attachment-subject.
w_filesize = f_attachment-docsize.

iii) For Sending Email to multiple recipients like To, BCC and CC,

· The below Logic can applied to provide cc bcc and to as like multiple receivers. The method

add_recipient has the option to give blind_copy, Copy and recipient.

w_recipient TYPE REF TO if_recipient_bcs VALUE IS INITIAL,

· Loop at the multiple receivers

LOOP AT receivers INTO f_receivers.

w_recipient_mail = f_receivers-receiver .

· The below method sets them mail ID of the Receiver.
w_recipient = cl_cam_address_bcs=>create_internet_address(
w_recipient_mail).

Continuing with the New G/L accounting Part -1 & Part - 2 covered under: New General Ledger Accounting - Part 1 & New General Ledger Accounting Part-2 respectively.

In this document we will be covering one of the major topic in New G/L is Parallel accounting which includes overview along with the configuration steps on Parallel accounting:

Parallel accounting means that a company's financial statements need to be created in accordance with different accounting principles. This is because a local view (such as U.S. GAAP in the U.S.) is no longer sufficient by itself in a globalized world of creditors (banks, shareholders) and business partners. An internationally recognized accounting standard is increasingly in demand.

Examples of internationally recognized accounting principles include:

IAS
IFRS
U.S. GAAP

You can portray parallel accounting in your SAP system. This enables you to perform valuations and closing preparations for a company code according to the accounting principles of the group as well as other accounting principles, such as local accounting principles.

The New General Ledger supports Parallel Accounting by using either parallel Accounts or parallel ledgers.

In New GL, both approaches are considered equally powerful.

The choice will depend on the specific customer situation.

The parallel accounts approach in the New GL is as powerful as in classic GL in

R/3.

The parallel ledgers approach in the New GL is much better than the SAP R/3 approach of using classic GL plus the special ledger application.

Benefits of Parallel Ledger

Standard reporting for multiple ledgers

Postings into multiple ledgers

Postings per specific ledger

Closing activities are run separately in parallel ledgers.

Configuration Steps:

1. Define Accounting Principles

Here, you define your accounting principles. You then assign the desired ledger group to the accounting principles.

For performance reasons, you can combine several different accounting principles in one entry; for example, you create one accounting principle for IAS/US GAAP. This can be useful if, in an application, you have to create the data for each accounting principle, even if the postings derived from the data are identical for each accounting principle.

Caution

The accounting principles that you have defined are available in various functions in Financial Accounting, SAP therefore advises you not to delete any accounting principles.

Transaction code	SPRO
IMG menu	Financial Accounting (New) -- Financial Accounting Global Settings (New) -- Ledgers -- Parallel Accounting -- Define Accounting Principles

Click on New Entries

Maintain the input parameters as below:

Click on Save

2. Assign Accounting Principle to Ledger Groups

Here, we assign the desired ledger group to your respective accounting principles.

Transaction code	SPRO
IMG menu	Financial Accounting (New) -- Financial Accounting Global Settings (New) -- Ledgers -- Parallel Accounting -- Assign Accounting Principle to Ledger Groups

Click on New Entries:

Click on Save.

In the next series with New G/L Accounting Customization, will be covering "Document Splitting".

Refer toNew General Ledger Accounting - Part 1 & New General Ledger Accounting - Part 2

Appreciate to have your views, comments and suggestions.

Warm Regards,

Mukesh Sharma

Purpose

I would like to provide a document that outlines the basics of SAP tax configuration and provides a couple of examples of how tax code could be determined in SD and MM.

Overview

SAP provides the majority of the tax configuration out of the box by country
There are three SAP areas that work together to determine taxes FI,MM, and SD

FI – Base configuration for tax procedures, rates and accounts

SD – Configuration/master data to determine output tax code

MM – Configuration/master data to determine input tax code

Master data such as customer, vendor, and material, as well as transactional data like POs and Sales Orders are key to determining the correct tax
Rates can be maintained in SAP or SAP can call an external system for them (this document with focus on rates maintained in SAP)

FI Tax Basics

Tax configuration is done by country
All company codes in the country share those settings
Two Main Components:
- Tax Calculation Procedure – Provide the method of calculation – normally use SAP standard
- Tax Codes – Provide the rates

Tax Procedure

These are provided by SAP for each country – General recommendation is to use delivered logic
Tax Procedure, related conditions, and access sequences can be viewed in transaction SPRO at the path Financial Accounting Global Settings>Tax on sales/Purchases>Basic Settings>Check Calculation Procedure

Tax Procedure Example

Steps define calculation, conditions, and account assignments

Condition Type Example

Condition record defines access sequence, and other characteristics about the condition

Access Sequence Example

Access Sequence defines field required to access a condition
For example to find a condition for the entry below the system will use Country, Tax Code, and Tax Jurisdiction

Configuration - Assign Tax Procedure to Country

Tax Procedures are assigned to countries in transaction OBBG

Tax Jurisdictions

Represent government authorities to which taxes need to be paid
SAP allows up to 4 levels tax jurisdictions representing state, country, city, and others

Configuration - Jurisdiction Code Structure

Tax Jurisdiction structure must be defined in transaction OBCO

Configuration - Maintain Jurisdiction Codes

Jurisdiction codes are maintained manually in transaction OBCP for tax procedures that do not use an external system

Tax Codes

Tax Codes are maintained by country and jurisdiction code
They define the rate that is used in calculation
They are maintained in transaction FTXP
Don’t be confused on the name, this transaction can create,maintain, and display tax codes

Tax Code - Properties

The properties of the tax code identify its code, name, type (input vs output) and other information about it

Tax Code - Tax Rates

In the tax rate screen you enter the appropriate tax rates
You can also see the account assignment key and the conditions that are used to calculate a value in the follow on transactions such as SD invoice

Tax Account Determination

Accounts are assigned in transaction OB40
You can also see the account assignment key and the conditions that are used to calculate a value in the follow on transactions such as SD invoice

Tax Code Determination

At the end of the day the tax is determined based on the tax code and the tax procedure on the AP or SD invoice
SAP multiple ways to determine the tax code, condition tables, master data, programs, manual entry, etc.
Method can be different by situation
This document shows an example of how a tax code could be determined for an SD invoice (output tax) and SRM Pos/invoices (input tax)

Purpose

Provide an overview of SAP Enterprise Structure and some of the specific finance related organizations

SAP Enterprise Structure Overview

Enterprise Structure is the system representation of your business structure
SAP has a number of organizational unit elements that help you portray the Accounting, Logistics, Sales, and Human Resources structure of your company
The structure of your company, business processes, and implementation scope will guide the SAP organizational units that will be required
Example Org Units are: Company Code, Sales Organization, Purchasing Organization, Plant, Segment, Profit Center, Cost Center, etc

Key Considerations/Notes For Enterprise Structure

SAP Enterprise Structure is a fundamental and key step in your implementation
The process should start by analyzing the business structure and processes in your company and then mapping them to the SAP structures
Enterprise Structure is made up of a combination of configuration settings and master data. Example – Company Code is Configuration and Profit Center is Master Data
Four Keys:

Simplicity– do not use more organization units than necessary

Acceptance– all levels of the project team should have input and acceptance

Ownership– limit the group that has ownership of the org structure and implement governance early in the project

Importance– once the enterprise structure is set it is not easy to change and will impact future setup decisions

Main Areas Where Enterprise Structure Elements Exist

SAP traditionally divides Enterprise Structure into 8 Areas

Example Enterprise Structure

Taken from SAP Best Practice Baseline Template for ECC 6.0

Enterprise Structure - SPRO Path

SAP has grouped Enterprise Structure activities together in SPRO
This is not 100% complete some objects are found elsewhere in SPRO or in master data transactions

Finance and Controlling Enterprise Structure

Let’s take a closer look at the Financial Accounting and Controlling Enterprise Structure Elements
Note – A single implementation will not use all of these elements only the ones that best fit the business model

SAP Enterprise Structure – Financial Accounting - Company

SAP Definition - The smallest organizational unit for which individual financial statements are created according to the relevant legal requirements. A company can include one or more company codes.
Think of it more as a Hierarchy of Company Codes
This is an optional organizational unit that tends not to be used in new installations
Was used in previous SAP versions when GL consolidation functionality was less developed
Function now typically done with other objects like segments or profit centers

SAP Enterprise Structure – Financial Accounting - Company Code

SAP Definition - Smallest organizational unit of external accounting for which a complete, self-contained set of accounts can be created. This includes the entry of all transactions that must be posted and the creation of all items for legal individual financial statements, such as the balance sheet and the profit and loss statement.
Best Practice – 1 Financial Legal Entity = 1 Company Code
This is the core organizational unit for SAP FI it is required on all financial postings

SAP Enterprise Structure – Financial Accounting – Company/Company Code Example

SAP Enterprise Structure – Financial Accounting – Business Area

SAP Definition - Organizational unit of external accounting that corresponds to a specific business segment or area of responsibility in a company.
Movements in value entered in Financial Accounting are assigned to business areas.
Used primarily for reporting purposes, cannot assign responsibility like some other objects (i.e. Profit Center)
Business Area is independent of Company Code
Role has diminished with the introduction of the New GL as the distinction between the objects used for internal and external reporting has diminished
Optional and not as commonly used as previously – Role is taken more by profit center or segment

SAP Enterprise Structure – Financial Accounting – Company/Company Code Example

SAP Enterprise Structure – Financial Accounting – Profit Center

SAP Definition – an organizational unit that reflects a management-oriented structure of the company and for which an individual period result can be determined
The division of a company into profit centers makes it possible for management responsibility to be delegated to these local organizational units
Profit center acts like a company within the company
Traditionally had a stand alone ledger in SAP, now can be activated directly in the New GL
Business Area and Profit Center are not typically used together
SAP focus for future developments in profit center vs. business area

SAP Enterprise Structure – Financial Accounting – Segment

SAP Definition – Division of a company for which you can create financial statements for external
Used to satisfy GAAP or IFRS requirements for some companies to disclose segment reporting
Profit Centers can be used to replace or in conjunction with Segment to satisfy this requirement
Profit Centers are assigned to a segment

SAP Enterprise Structure – Financial Accounting – Profit Center/Segment Example

SAP Enterprise Structure – Financial Accounting – Credit Control Area

SAP Definition - An organizational unit that represents the area where customer credit is awarded and monitored.
This organizational unit contains either a single or several company codes, if credit control is performed across several company codes.
One credit control area contains credit control information for each customer.
Customers can be created in different company codes - the credit control area responsible for a given customer depends on which credit control area the company code is assigned. Customers that are created in company codes with a common credit control area are controlled by this one control area for all company codes.
Basic Decision - If the same customer needs a different credit limit if they are assigned to multiple company codes then multiple credit control areas are required.

SAP Enterprise Structure – Financial Accounting – Credit Control Area Example

SAP Enterprise Structure – Financial Accounting – Functional Area

SAP Definition – Account assignment characteristic that sorts operating expenses according to functions, for example:
Used to produce what SAP calls Cost of Sales Accounting
Assigned based on the other objects involved in the transaction or through rules.
For example – $10 posted to an office supplies GL with a R&D cost center is tagged with the Research and Development functional area

SAP Enterprise Structure – Controlling – Controlling Area

SAP Definition – organizational unit in an organization that represents a closed system used for cost accounting purposes
A controlling area may contain one or more company codes, which can operate in different currencies, if required
The company codes within a controlling area must all use the same operational chart of accounts and fiscal year variant
Cost Centers and other controlling master data objects are assigned to a controlling area
All internal allocation transactions refer only to objects from the same controlling area

SAP Enterprise Structure – Controlling – Operating Concern

SAP Definition – An operating concern represents an organizational unit in your company for which the sales market has a uniform structure.
It is the valuation level for Profitability Analysis (CO-PA).
Profitability Analysis has a flexible structure based on characteristics derived from the various Sales, MM, and financial postings
Controlling Areas are assigned to one Operating concern
Fiscal year variant must match

SAP Enterprise Structure – Segment Assignment Example

Hi All,

This is my First Document in the Forum and hope this will be helpful for all.

I have searched in Forum but I did not get any Document on DMEE where Step By Step Configuration is Given.

Any Suggestion and Critics are always Welcome as this will help me to improve.

Introduction:
DME stands for Data Medium Exchange
A data medium exchange (DME) is a data exchange file which is used to send payment information of an enterprise to banks or tax authority. Basically these files contain financial data which can be in flat file or xml file format. Different File formats can be created for different countries and different banks based on their own norm which replaces conventional ABAP programs.

DMEE Configuration:Step By Step.

Create Payment Medium Formats (OBPM1)Accounts Receivable and Accounts Payable ® Business Transactions ® Outgoing Payments ® Automatic Outgoing Payments ® Payment Media ® Make Settings for Payment Medium Formats from Payment Medium Workbench ® Create Payment Medium Formats

Select New Entries

Format : Z_IDES

Description : Z_IDES

Payment medium without docs. : Select

Type : 01 File

Country : IN

Mapping using DME engine : Select

Company Code : Select

House Bank : Select

Save!

Create a new format with the same name as your DMEE format tree. Choose the format output Payment medium without docs., and type File. Under Program control, set the Mapping using DME engine indicator. Once this indicator is set, the DME engine button appears, which allows you to access the DMEE format tree directly.

Under Format information, specify your country. You can also write documentation for your PMW format by choosing the field help for the Documentation module field. From there, choose Proceed, and a document maintenance screen appears. Select document class General text, enter a name for the text, and create the documentation. Lastly, enter the name of this text in the PMW format in the Documentation module field.

DME Engine: Initial Screen (DMEE):

Select Active Version and press Copy.

Click on Change.

Click on DMEE tree:Properties

Here you need to give the format attributes for your DMEE output File.

Please see the screen shot Below.

In the Field type you have two options 1 or 2

I have taken 1,Fields are separated by Delimiter.

In Delimiter Section I have taken | but you can use comma,semi colon or anything.

Delimiter separates the items in DMEE file by the input provided by you.

After this click on Sort/Key Fields.

Sort key Fileds controls the output of line in DMEE.It actually controls the levels of DMEE.

Please see the Screen Shot below.

Header data should appear only once, so a value like the payment run identifier (FPAYH-LAUFD) is the same for the entire payment run and file created. Next level is usually the single payment (FPAYH-LFDNR), so the DMEE creates a new line for every payment. Alternatively and based on the requirements, this could be done also per vendor. Lowest level is usually the invoice references, as you can group several vendor invoices in a single payment.

After This Goto File Data where you need to tick on Carriage return and Line Feed.

The tick on Carriage return and Line feed is for creatin new line after the finish of Header Part.

Carriage Return is used for creating new line in word or PDF formart and Line Feed is used for creating new line in XML format.

Please refer Screen Shot Given Below.

In Header Part you need to define the Level and the type of output you want..

Screen shot is attached for the same.

The tick on Carriage return and Line feed is for creatin new line after the finish of Header Part.

Carriage Return is used for creating new line in word or PDF formart and Line Feed is used for creating new line in txt Format.

Add the fields to Header and Details as per the requirement and then save.

Now will show step by step for every Header and payment Details configured here.

P.S:Requirement may vary according to Client and Bank.

In Header Part I have made it Constant which you need to choose in Attributes tab of DMEE.

Give name(as I have given Header),Give Length and choose character as shown in Screen Shot Below.

Go to Source Tab and write what you want to get in the output as shown in screen shot below.

The Next is Corporate ID,This is nothing but the paying Co code.

Give Name,Length and Type.

Please select Structure Field(I have taken Structure Field because it can be fetched from the Tables and Field,Some data are there which you can fetch from tables so either you have to make it constant or you have to use Exit Module).

Click on Source Tab.

You will find Field name,You can choose Field name according to your requirement.

Here I have taken FPAYH-ZBUKR as shown in screen shot below.

Now We will configure the payment details.

As I have copied the standard structure where Segment group and Elements were already there but you can definitely create segment group,segment and elements according to the requirement.

In my Configuration the first is payment type(Means the payment is NEFT or RTGS)

For this you can not use constant or structure field,here you need to use Exit Module and you need the help of ABAPER to write a logic(The logic here is that if the amount is less than or equal to rs 200000 then NEFT else RTGS).

Now click on the Source Tab and one need to provide structure and Field name(though we are using Exit Module but we need to provide Structure and Field name so that the data can be populated in the Structure and field given and system populates the data in DMEE file through this Structure and Field)

I have Used FPAYH-FORMZ,.

Please refer the screen shot Below.

The Exit Function “ZDMEE_EXIT_TEMPLATE_ABA” is done by ABAPER and you need to assign this Exit Function as shown in Screen Shot Above.

I am giving the code as well which is done by ABAPER and it works according to NODE ID.

The Coding is as follows:

CASE i_extension-node-node_id.
WHEN 'N_8559886880' .
IF l_item-fpayp-dmbtr LT 200000.
l_item-fpayh-formz = 'NEFT'.
o_value = l_item-fpayh-formz.
c_value = l_item-fpayh-formz.
ELSE.
l_item-fpayh-formz = 'RTGS'.
o_value = l_item-fpayh-formz.
c_value = l_item-fpayh-formz.
ENDIF.

Now click on Payee IFSC Code and Configure as given in the screen shot below.

PS:Please maintain the IFSC code of Payee bank in Control Data Tab in SWIFT column in House bank .

Click on Payee Bank Number and Configure According to Screen Shot.

Click on Receivers IFSC Code and configure as shown in Screen Shot Below.

I have used Exit Module here as well and the coding is as follows:

WHEN 'N_9336226660' . "ifsc code
CLEAR: l_lifnr,l_bkref.
l_lifnr = l_item-fpayp-gpa2r.
SELECT SINGLE bkref FROM lfbk INTO l_bkref WHERE lifnr = l_lifnr.

l_item-fpayh-bkref = l_bkref . " L_ITEM-FPAYH-EIKTO. " L_BKREF.
o_value = l_item-fpayh-bkref.
c_value = l_item-fpayh-bkref.

Now in Vendor Master Data You need to maintain IFSC code in Reference Details Field as shown in Screen Shot Below.

Now Click on Beneficiary Account No and configure as shown in Screen Shot Below.

Here also I have used Exit Module and the Coding is as follows:

WHEN 'N_3908411670'. "account no
CLEAR: l_lifnr,l_bankn.
l_lifnr = l_item-fpayp-gpa2r.
SELECT SINGLE bankn FROM lfbk INTO l_bankn WHERE lifnr = l_lifnr ." L_ITEM-FPAYH-EIKTO.

l_item-fpayh-zbnkn = l_bankn.
o_value = l_item-fpayh-zbnkn.
c_value = l_item-fpayh-zbnkn.

Maintain bank account in vendor master in Bank account Column as Shown in Screen Shot Below.

Now Click on Transaction Currency and configure as shown below.

Now Click on Amount and configure as Shown in Screen Shot.

Click on Name of Payee(Vendor) and configure as shown in Screen Shot Below.

Click on Vendor Email Id and Configure as shown in Screen Shot Below.

Here also I have used Exit Module.

Coding is as follows:

WHEN 'N_9785488450'. " Vendor Email ID
CLEAR: l_lifnr,l_adrnr,l_emailid.
l_lifnr = l_item-fpayp-gpa2r.
SELECT SINGLE adrnr FROM lfa1 INTO l_adrnr WHERE lifnr = l_lifnr .
IF sy-subrc IS INITIAL.
SELECT SINGLE smtp_addr FROM adr6 INTO l_emailid WHERE ADDRNUMBER = l_adrnr.
ENDIF.

l_item-fpayh-INTAD = l_emailid.
o_value = l_item-fpayh-INTAD.
c_value = l_item-fpayh-INTAD.

WHEN OTHERS.
ENDCASE.

Click on User Mobile No(Vendor) and Configure as shown in Screen Shot.

Settings in Bank Customization (FBZP):

a) Payment Methods in Country: Create Pymt. Method ‘E’ for country ‘IN’. Define the Currency.

In Payment Medium,Put Z_IDES in Format Column.

b) Bank Determination: For Paying Company Code ‘1000’, select Ranking Order.

Create New Entries for "E"

c) Bank Accounts

Create Bank Account for 1000.

Due to limitations of screenshots (Up to 20 in one Document) rest of the Configuration is in

DMEE Configuration:Step By Step Part 2

Please Follow the link for the same.

http://scn.sap.com/docs/DOC-65031

Hope this will be helpful for all.

Any Suggestions or Critics will be highly appreciated as this will help me to Improve in Future.

Regards

Eugene

Hello, SAPers!

Quite recently I worked on implementation of budget payment orders (taxes, social payments etc.) for our Client. First of all, I compared the structures of ordinary and budget payment orders and found out that there is a dozen of extra fields in budget payment order that are not supported in an ordinary payment order. So the task boiled down to add these extra fields to the existing DMEE-tree (for ordinary payments), however output them only when certain conditions are met. I decided to implement this requirement using conditions in DMEE-tree. As it turned out, this functionality is quite simple, but when you try to use it for the first time it will take some time to understand the mechanics behind it. Let’s take a closer look at this functionality.

Condition technique is a standard functionality in DMEE that enables you to control whether a node would be processed during the generation of payment orders or not. Basically, if the condition for a separate node is not fulfilled then the node will not be processed and hence not displayed in the file with payment orders. The conditions can be configured for any node type. If the condition should apply to several fields, you can apply it to a composite node () or a segment () that contain these fields.

For configuration of conditions you can reference either the field values in source structures (i.e. FPAYH, FPAYHX and FPAYP) or the values in another nodes of DMEE-tree. We will consider the implementation of both cases. The following are typical fields used in configuration of conditions:

- Arg.1-1 contains reference value that should be checked (reference node, source structure (FPAYH, FPAYHX and FPAYP) or a constant value);

- Arg.1-2 contains the field of the source structure or a node attribute that should be checked (e.g. 1A– contents in internal format; 1– contents in output format if some conversion was applied etc.). The list of all options can be checked via help options (F1). In case you specified the constant value in Arg.1-1, this column should be empty.

- Type contains the reference to an argument type of reference value (1 – constant value, 2 – field in source structure, 3 – reference ID).

- Operator specifies which logical comparison should be applied to the reference value in order to fulfill condition criteria.

- Arg.2-1 contains the comparison value against which the reference value should be compared (the same possible values as for Arg.1-1).

- Arg.2-2 contains the attributes of the value (the same possible values as for Arg.1-2);

- Type for the comparison value serves the same purpose as for the reference value.

- Operator contains the linking operator and is used in case of several conditions (AND– if both conditions should be met; OR– if some of the conditions should be met).

1.1 Condition via Reference to another Node of DMEE-Tree

Case: for foreign vendors additional field with information on house bank SWIFT code should be displayed.

First of all, you have to configure the reference node. You can use the existing fields of the DMEE-tree or you can define technical nodes () to store reference values that should not be displayed in payment order. If there are several technical nodes, you can create separate segment to group them together. In this example a segment with technical node will be used. In any case, specify meaningful reference ID for the node whose value should be checked e.g. VEND_COUNTRY. You can use all standard mapping options to fill this field. In this case a field from the source structure will be used (FPAYH-ZLAND). Example of reference node can be found below.

Remark: DMEE-tree for this example uses segment with two elements LABEL and VALUE. Label element is mapped to a constant text value (tag) that by default equals to the name of the segment e.g. "CLN_BANK_SWIFT=". Value element contains the actual value of the payment order tag. Typical example can be found below:

Condition will be applied on segment level, thus it will effect both elements. In order to meet stated requirements, the following condition was configured:

This solution might be good if you use the DMEE only for a specific country (e.g. Ukraine in my case). But if you want to configure it more flexibly in order to use across several countries you will have to modify and check whether vendor country equals the country of company code. This data is available in source structure (FPAYHX-LAND1). The condition should be configured the following way:

Alternatively, you can use complex condition containing the list of specific countries for which the condition applies e.g.:

In any case, the result would be the same (except the third option): there would be additional line with house bank SWIFT code for the second payment (payment to a foreign vendor).

1.2 Condition via Fields of Source of Structure

Let’s consider another case building on a previous one. Suppose you want to display IBAN number for a foreign vendor (if it is configured in master record). For a local vendor, bank account number should be displayed instead (if there is no IBAN number).

The first complex condition checks whether the country of vendor is the same as the country of company code and there is no IBAN in master record. If both of these conditions are met, the segment will be processed and bank number will be output (source: FPAYH-ZBNKN). If one of them is not met, the segment will not be processed.

The second condition checks whether the country of vendor differs from the country of company code and there is IBAN in master record. Similarly, if both conditions are met the segment will be processed and IBAN number will be output in file (source: FPAYH-ZIBAN).

As can be seen from the attached screenshot, bank number of the local vendor is displayed in tag RCPT_ACCOUNT and IBAN number for a foreign vendor in tag RCPN_IBAN.

I hope you will find this information useful if you are interested in topics around payment medium workbench and DMEE-trees.

All suggestions are welcome!

Best regards,

The Wirtschaftsmann

P.S. Disclaimer.

All sensitive information (bank accounts, company names etc.) used in this example is invented by my own. If there is some coincidence with real-life companies, it is a purely accidental one. The structure of the DMEE-tree represents a real-life example alghouth I modified it for the purposes of this blog post.

Hi All,

This is the continuation of the document DMEE Configuration.

Please refer the below link for the DMEE Configuration:Step By Step Part 1.

DMEE Configuration:Step By Step Part 1

Create/Assign Selection Variants (OBPM4)

Accounts Receivable and Accounts Payable ® Business Transactions ® Outgoing Payments ® Automatic Outgoing Payments ® Payment Media ® Make Settings for Payment Medium Formats from Payment Medium Workbench ® Create/Assign Selection Variants

Double click on the Format Created Earlier, i.e-Z_IDES.

Create ‘For All Selection Screens’ and then continue.

Give Payment Medium Format ‘Z_IDES’

Then select Print Parameters and give the name of the printer.

Then Save.

Reservation for Cross-Payment Run Payment Media (OBPM5)

Select

Run APP (F110)

ID should End with 'E' and there should at least one space left.

Complete APP Run.

Go to ENVIRONMENT-PAYMENT MEDIUM-DMEE Administration

Select the File and save the Output File.

Hope you all will find the Document Helpful.

Any Suggestions and Critics are always Welcome as this will help me to Improve in Future.

Regards

Eugene

To discover which batch jobs are running for a specific program you have to first find out the program name then use the transaction SM37 to look for the jobs.

To do this follow the steps:

1. Go to transaction SE93 and fill the transaction code and click on Display. In this example we are using the transaction FBL3N;

2. Execute transaction SM37 and enter the program name and Execute. You can also limit your search filling fields Job name, User name and selection Job status and Job start condition;

3. System will show you all jobs related to the program.

Executive Summary:

Amounts received from customers can or cannot be considered as realized revenue depending on the status of the delivery/legal transfer of title of the product or services. IAS 18, SOX and IFRS lay down detailed norms on revenue recognition. Revenues are recognized when they are realized or realizable, and are earned, usually when goods are transferred or services rendered. Essentially, it is considered fine to recognize revenue as soon as the manufacturer/service provider carries no further liability of the goods/services dispatched/rendered in any sense of the transaction.

In some cases businesses may take advance payments from customers. Advance payments could be of two types:

·100 % Cash in advance of the order value.

·Multiple part payments before the order is shipped ( eg. 10 % when order is booked, 50 % when order is ready to ship etc)

While the payment is received, the goods/service has not yet been completely delivered to the customer. In such a case the advance payment is treated as deferred revenue (liability) and no revenue is recorded unless the goods/services are delivered. Since the customer has paid an advance amount, he/she may ask for a billing document for the same. In some countries, especially in Europe, it is a non-compliance to collect advance payment from the customer using a proforma invoice. In such cases the customer needs to be provided with an actual tax invoice against which the customer can make the advance payment. As per revenue recognition guidelines while billing may be done in such cases it should not post to revenue account but to a deferred revenue account (liability account).

This whitepaper specifically discusses a compliant SAP standard solution of revenue recognition in case of advance payments. Specific insights from live projects have been added to enrich the content to make it useful for interested SAP consultants to solve some of the known implementation issues related to SD based revenue recognition functionality of SAP.

Note: Sound understanding of SAP SD-FI integration is a pre-requisite to this reading.

Business requirement:

The general, sales cycle involves creation of sales order, passing demand in to MRP , picking, packing and delivery on the sales logistics side. Billing is done post delivery. At billing, revenue gets posted to financial accounting. The accounting entry that gets posted at billing in this case is as follows:

Receivables A/c Dr

Revenue A/c Cr

The customer can then pay for the goods received basis the billing done.

In case of advance payment scenarios customers pay ahead of the delivery. The amount thus received cannot be treated as revenue. It needs to be shown as deferred revenue (liability). The accounting that should get posted in this case should be:

Receivables A/c Dr

Deferred Revenue A/c Cr

Imp Note :- It is very important to note here that as per the revenue recognition functionality, Tax amount for the Advance payment which gets calculated in the Billing document cannot be deferred and for each billing document it is calculated proportionate to the revenue amount in the billing document.

Once the delivery has been made and the manufacturer does not have any further liability of the goods sold/dispatched, revenue can be recognized. The accounting that should get posted at that instance should be:

Deferred Revenue A/c Dr

Revenue A/c Cr

With increasing need for compliance, businesses are looking forward to solutions which can make the correct recording in accounting and ensure that they are compliant with the international guidelines on revenue recognition.

SAP Standard Solution:

In general billing scenarios the revenue account gets determined basis the VKOA setup in SAP. For advance payment cases discussed above it is required to circumvent the normal SAP VKOA setup and post to a deferred revenue account. SAP provides this ability as a special activation request i.e the functionality is not available in standard SAP but has to be activated separately post a system audit and confirmation by SAP (Please refer SAP-notes 779366 and 605665-: special activation guidelines from SAP)

SD based revenue recognition functionality of SAP is recommended for the following scenarios:

Periodic revenue recognition based on specified periods. This is known as time-related revenue recognition method. Example: Revenue for annual contracts where a monthly service is provided and revenue for the corresponding period recognized at each month end.
Revenue recognition based on a specific event like delivery of goods or completion of service. This is known as Service-related revenue recognition Example: business receives advance from customer but the transfer of title for the good happens only after the customer sends confirmation of goods received. Post acceptance from the customer the revenue recognition can take place. Acceptance by customer is the event which will trigger revenue recognition in this case.

SD based revenue recognition functionality of SAP also addresses some other key business requirements. This functionality gives the ability to:

track revenues which have been recognized but not yet billed (non-billed receivables)
track revenue which has been billed but not yet recognized (calculated revenue)
Recognize revenue partially for partial deliveries done.

All constraints of this functionality are documented in detail in SAP notes 678260.

Detailed Setup:

Setup for this functionality includes the following steps:

Special activation of the functionality as per notes 779366 and 605665
SD related Setup

· Sales order Setup: - A Header level billing plan should be activated for the sales order type. The Billing plan will be used to setup Milestones for Billing, In case of 100 % Cash in advance, you can setup one milestone, in case of multiple part payments, you can setup multiple milestones. Once the Milestone is released, an actual Tax invoice can be created.

· The Sales order should be setup for Order related billing , copy control between sales order and Billing document should be setup in a way that there is no PGI Completed check when an Invoice is created against the sales order

Item category setup for determination of revenue recognition. It is the item category in the sales order line item that contains the rule (service/time related) for revenue recognition. For the identified item category revenue recognition and accrual period start fields are important configuration considerations.

Revenue Recognition field controls the method of revenue recognition to be used for the sales order line item. The possible options in this case are:

- A: Time-related revenue recognition

- B: Service-related revenue recognition

- D: Time related revenue recognition with a billing reference

- No input: Revenue recognition happens along with billing (as is the normal billing scenario)

Accrual period start field controls the determination of the period from which revenue recognition gets started. The possible potions in this case are:

- A: Accrual start date is the same as item sales contract date

- B: Start date could be start date of milestone billing plan or periodic billing plan date

Proof of Delivery Activation: Activating Proof of delivery for the Item category which is configured for Service related revenue recognition helps in recognizing partial revenue to the extent of the goods which have shipped in cases where partial delivery has been processed for a Sales order.

Finance related Setup

Deferred Revenue account to which deferred revenue has to be posted is maintained in the “Provisional account” column in VKOA.
Non-billed Receivables account is setup in transaction OVUR for each customer reconciliation account used in the setup

COPA related checks

While there are no specified checks for COPA, it has been observed that with activation of SD based revenue recognition functionality at times due to SAP notes and patch level issues sales quantity otherwise flowing to COPA gets suppressed i.e it might be observed that while COPA document is created, it doesn’t contain sales quantity.

SAP Provides notes 619498 to help resolve the issue.

Functional Constraints:

Detailed functional constraints of SD based revenue recognition functionality are provided in SAP notes 678260. Any implementation of this functionality should start with a very clear understanding of its function constraints and its relevance to business. A key constraint that is noticeable about this functionality in SAP is the inability to defer COGS like revenue. This essentially means that revenue recognition has to be carried out immediately post delivery to ensure matching principle is adhered to.

Competing product Oracle R12 has introduced the functionality for COGS deferment and with growing demand for IAS18, IFRS and GAAP compliance this would possibly become a strong requirement from SAP solution as well.

Useful SAP notes:

Some useful SAP notes for quick reference are as listed below:

678260: Functional Constraints of SD based revenue recognition

779366 and 605665-: special activation guidelines from SAP

1172799: Revenue Recognition best practice

1166848: Revenue Recognition customization

Notes relevant to revenue recognition but not in EHP4:1265438,1392080, 1452022, 1489782, 1500879, 1511715, 1528295, 1529073, 1468536, 1509243

678260: Revenue Recognition with New GL

619498: Transfer of quantity and value fields

1025066: Revenue recognition by proof of delivery (POD)

532876 - FAQ: Revenue recognition process

Conclusion:

SD based revenue recognition provides a compliant solution to revenue recognition requirements of businesses. There are some functional constraints but none too stringent or without workarounds. At the end, the functionality provides a very clear audit trail and is an accountant’s and auditor’s delight.

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”

(Assign Accounts to Account Symbol ) assign Y12 to GL Account ++++++ as below

(Create Keys for Posting Rules) create a Keys for posting rule Y12

(Define posting rule) define a posting rule like below

Posting Area 2 “Sub ledger posting “

Document Type: KZ

Posting Type : 7 “clear Debit Sub ledger account

T-Code FBZP “ Pmnt method in country” in posting details section choose Payment order only

T-code OT52 create manual bank statement posting rule

Interpretation Algorithm : 29 “Payment order”

T-code: OT43 Define Variant for Manual bank Statement

You have to add the payment order to variant

While Run F110 , SAP will create payment order Number for the selected invoice to be paid
You can display the payment order created from F110

When Run FF67 .. you have to enter payment order Number

SAP will create the below entry and clear the open item

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

In FINT transaction the interest calculation start date is not available in the selection screen which was available in the F.24 transaction. This setting of date from which the interest will be calculated is handled through the below SPRO customization:

In the preparation for interest calculation we have the options of selecting the Ref Date, as shown in below screenshot. This Reference date is nothing but the date from which the interest can be calculated.

Note: Normally the checkbox "Always Calculate Int. from Net Dte" gives the error " "Do not select "Calc.intrst from net due date" for this int.calc.type Message no. F7128"

However mere selecting the Ref Date as 1 can solve the problem. See the below example.

A document is posted with document date as 01.01.2015

The payment terms are FB30 ( 30 days from the baseline date)

that means the net due date is 31.01.2015.

Transaction FINT executed for this document

Execute and check the Interest Start from Date :-

If you wonder why the date is not 31.01.2015 but is 03.02.2015 it is because in the interest indicator setting you have mentioned transfer days as 2. (Transfer days are the days required for a payment to go from the payer to the payee)

Hence the interest start date is now the net due date of the invoice document.

Overview

Its is often done that multiple locations/branches of the same customer are created as different customers in SAP.

In such case the credit limits need to be maintained for only main customer and rest all the branch customers are needed to use this credit limits even if the sales are done using all the customers.

This can be achieved by assigning a customer as reference for credit control for several customers

Let us assume that in the below example 137110156 is a head office and 137110267 is branch

Main Customer whose credit limit is to be shared