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
  • Financial Accounting – Structure for G/L Accounting, AP, and AR
  • Controlling– Structure for Cost Center Accounting, Cost Controlling, and Profitability Analysis
  • Material Management – Structure for Material Valuation, Material Planning, Purchasing, Inventory Management, Invoice Verification, and Warehouse management
  • Sales and Distribution – Structure for Sales, Shipping, and Billing
  • Human Resources – Structure for all HR related activities
  • Logistics – General – Structure for general logistics activities including those relating to purchasing
  • Logistics Execution – Structure for the execution of logistics i.e. loading points, transportation points, and warehouses
  • Plant Maintenance – Structure for facilities maintenance

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:
  • Production
  • Administration
  • Sales
  • Research and development
• 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

Overview on Currencies

Currency is the Legal means of payment in a country. In the SAP system you can post in different currencies. For each monetary amount that you enter in the SAP System, you must specify a currency. You enter currencies as the ISO standards, for example, USD for US dollar.

In SAP, all currencies are maintained as per the ISO (International Organization for Standardization) standard.

In this section, one need to:

• check the preset currencies; and
• add new currencies according to your requirements

Here you define the currencies allowed in the system and the exchange rates for Currencies. You must define a company code currency for each company code in FI. In addition, you can define one or two parallel currencies for each company code.

Configuration Steps:

     Path:IMG -- SAP NetWeaver -- General settings -- Currencies

1. Check Currency Codes

The currency table must have entries for all currencies which are required in the company’s business transactions.

In SAP, all currencies are defined according to the international ISO standard (International Organization for Standardization). SAP recommends that one should use the ISO standard for your additional entries.

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

Actions

1. Check the currency entries for completeness.
2. Add the missing currency entries as required.
3. Use the ISO standard for your additional entries.

Example:

            Create a new currency key

            Currency Key: USDZ

Long Text: United States Dollar - 3 Decimals

Short Text: USD 3 deci

ISO Code: USD

Alternative Key: 840

2. Set Decimal Places for Currencies

Each currency has a different number of decimal places. If you are adding new currencies, which do not have two decimal places, you have to enter these currencies in the menu option 'Decimal places'.

In the settings delivered with the system, the most important currencies which do not have two decimal places are pre-set according to the ISO standard.

Activities

     1. Check whether in your company currencies are in use which do not have two decimal places, in addition to those delivered.

     2. Set the appropriate number of decimal places for these currencies.

     3.Define Standard Quotation for Exchange Rates

3. Define Standard Quotation for Exchange Rates

For each currency pair you need to define either the indirect quotation or the direct quotation as the standard quotation for the exchange rate.

This setting is used for the following activities:

1. When you process the exchange rates table you can enter the exchange rate either as a direct or an indirect quotation. If the exchange rate you enter does not have the same quotation as the standard quotation set up.
2. An exchange rate is only taken from the exchange rates table if it has already been given by the user. If this is a type of exchange rate that demands translation using a reference currency, the standard quotation is used to be determined for further processing.

4. Enter Prefixes for Direct/Indirect Quotation Exchange Rates

Exchange rates can be entered as a direct or indirect quotation. Here you can maintain two prefixes that can be used to differentiate between direct and indirect quotation exchange rates during input and output.

Recommendation : If you use mainly direct quotation exchange rates, you should set the prefix for

• direct quotation as ' '
• indirect quotation as a different symbol, e.g. '/'

If you do not set up a prefix here, the standard setting is valid:

• ' ' for direct quotation exchange rates
• '/' for indirect quotation exchange rates

The prefix ' ' means that you can enter the exchange rate without a prefix.

Example

Your local currency is EUR. You enter a business transaction in the transaction currency USD. '/' has been defined as the prefix for indirect quotation and ' ' for direct quotation (' ' = no prefix necessary). You can then either enter the exchange rate as a direct quotation without a prefix, e.g. '0.97234' or as an indirect quotation with prefix '/', e.g. '/1.08456'.

5. Check Exchange Rate Types

Exchange rates for different purposes for the same date are defined in the system as exchange rate types (you cannot delete existing entries).

If you need to carry out currency translations between number of different currencies, you can simplify exchange rate maintenance by entering a base currency for the exchange rate type.

The standard system includes the exchange rate types for the bank buying rate (G), bank selling rate (B), and average rate (M).

6. Define Translation Ratios for Currency Translation

Here you enter the translation ratios for currency translation. You enter these ratios for each exchange rate type and currency pair. You also specify whether you want to use an alternative exchange rate type for specific currency pairs.

Example

As of 01/01/1999 the exchange rate for DEM (German Mark) to FRF(France) will be calculated via EUR. To translate amounts enter:

• 01/01/1999
• The exchange rate type under which the exchange rates of the European national currencies are stored in the Alt. ERT field

7. Enter Exchange Rates

Exchange rates are required to:

· Translate foreign currency amounts when posting or clearing transactions.

· Determine the gain and loss from exchange rate differences

· Evaluate open items in foreign currency and the foreign currency balance sheet accounts

The system uses the type M exchange rates for foreign currency translation when posting and clearing documents. An entry must exist in the system for this exchange rate type. The exchange rates apply to all company codes.

8. Maintain Exchange Rate Spreads

In this activity you can derive the bank buying rate and bank selling rate using the average rate and the spread. By spread, we mean the difference between the average and buying rates or between average and selling rates. You convert to the buying or selling rate by first determining the average rate, then adding or subtracting the spread from that average rate.

Example

If the average rate between USD -> DEM is 1.46000 and the spread is 0.00400, the bank buying rate derived is 1.45600.

To make that calculation you must make the following entries in this step:

M (rate type) USD (From) DEM (To) 0.00400 (spread)

9. Define rounding rules for currencies

For the company code/currency combination for which payments are to be made not in the smallest denomination, but in a multiple of it, enter the currency unit (rounding unit) to which amounts are to be rounded.

This ensures that the amounts in this currency are always rounded to this unit. The payment program evaluates your entries to determine the cash discount and rounds off the amount accordingly.

10.  Define Worklist for Exchange Rate Entry

Here you create a worklist for entry and editing of exchange rates. Users receive authorization to enter exchange rates at the worklist level. It is possible for two or more users to edit two or more worklists in parallel, as the lock applies at the worklist level during editing.

You can assign each combination of exchange rate type, from and to currencies to one worklist only.

Click on New Entries:

11.  Assign Exchange Rate to the Worklist

Here you assign exchange rates to a worklist. You can assign all exchange rates to a worklist that are to be entered at the same intervals and linked to the same authorizations. You can enter the rates either directly in the productive system using transaction TCURMNT.

Click on to New Entries:

Click on Save.

12. Expiring Currencies

You can use this new function to allow currencies to expire. This means that you can attach warning or error messages to the creation/change of objects in the currencies expiring.

For example: the currencies participating in the European Monetary Union that then lose their validity after the end of the dual currency phase.

For longer running objects (such as sales orders) you can enter a date for a warning or error message.

In this way, you can ensure that on/after the end of the dual currency phase, these objects can no longer be created/changed in the currency that is being discontinued.

This function can also be used to discontinue currencies of countries where there is high inflation.

     i. Define expiry reasons

In this IMG step you define the expiry reasons for the currencies that you want to allow to expire.

Example

The Austrian Schilling loses its validity at the end of the dual currency phase. You want to prevent objects in this currency being create/changed drawing up to/after the end of this dual currency phase.

EURO - European Monetary Union

You can assign this expiry reason to the participating currencies in the next IMG step.

The Austrian Schilling loses its validity at the end of the dual currency phase. You want to prevent any objects in this currency being created/changed leading up to or after the close of the dual currency phase.

     ii. Define expiring currencies

In this IMG step you assign the expiring currencies an expiry reason as defined in the earlier step. You also define the new currency that is to replace the expiring currency.

     iii. Define warning and error dates

You can also enter a date for a warning and/or error message for each link between expiry reason and object type. The warning date is earlier than the error date

Example:

According to your requirements, e.g. 01.01.2002 as a warning date and 06.30.2002 as the error date for the object types made available by SAP. For company code dependent objects you can restrict the check by company code. When a user then wants to create/change an object in ATS from the 01.01.2002 a warning message and from the 06.30.2002 an error message will appear for the assigned object types and company codes.

Will shortly update with the SAP configuration screens as well.

Thank you,

Mukesh Sharma

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)

1. 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

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.

1. 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

        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.

Here I will describe three ways to find the transaction code for a report or program. In this document I will use as example the program RFITEMGL.

Using transaction SE80

1. Go to transaction SE80 and select Program in the list. Fill the program name and click on Display. In the list below, look for Transactions.

Using transaction SE38

1. Go to transaction SE38, fill the program name and click on Where-used List (Ctrl + Shift + F3);

2. Select the option Transactionsand click on Execute;

3. System will show you all transactions related to that program.

Using table TSTC

1. Go to transaction SE16, fill the table name as TSTC and press Enter;

2. Fill the program name and click on Execute (F8);

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

You can use the same table to do the opposite! Fill the transaction code to find the program name.

Withholding Tax is also called as retention tax. Its requirement of Government to deduct or withhold a particular percentage from paying to the vendor and pay such amount to the Government on behalf of other person. It’s a kind of Indirect Tax.

[A] CONFIGURATIONS:

All the configurations for the Withholding Tax is done in the following Tab only:

·         Define Business Places: Business Place is to be created for each Tax Deduction Account Number (TAN) that company has.

·         Define Section Codes: In India for each Business Place a Section Code is created and mapping is done on one to one basis. In Section code information about Local Tax office as well as District Tax office can be made.

The flow for the configuration is such that firstly the Withholding Tax Key (e.g. 194C) is to be created then under that Withholding Tax type is created one at the time of invoice and other at the time of payment and then based on the different rates prevailing in the Income tax Act, different Tax Codes are to be created (e.g. for 194C, 2 different rates are there in the Act, one is 1% TDS on the contract basis and second is 2% TDS on the sub-contract basis)

E.G. 194C à Invoice / Payment Posting àC1/C2 based on different rates.

Define Withholding Tax Keys: Withholding Tax key is used to identify different withholding tax types. A name is to be given with the official key.

Withholding Tax can be deducted at two point of time; it can be either at the time of invoice or at the time of payment. So for this Withholding tax types are to be created one for invoice and second for payment.

·    Define Withholding tax Type for Invoice Posting: Here the withholding tax type is assigned for the invoice purpose and the same will not get triggered at the time of Payment Posting.

·    Define Withholding Tax Type for Payment Posting: Here the withholding tax type is assigned for the payment purpose and the same will not get triggered at the time of Invoice Posting. The withholding information is to be provided while posting for such document for Withholding Tax payment.

For each Withholding Tax Type, according to the different rates available in the Income tax rates, the different Withholding Tax Codes are to be created based on the Withholding Tax Type.

·         Define Withholding Tax Code: In withholding tax code, different rates are maintained and on what basis the TDS should be deducted is maintained.

Here above configuration is done and on the above basis the TDS amount will be deducted from the invoice or payment.

·    Defining Document Type for Challan:

Here we maintain the Document type for posting Challan.

·    Define Number Ranges for the Challans create: Here this is important on the basis that the client requires that he want details about the combination of Section Code and the Withholding Tax Key basis, so then different number range can be assigned and so he will be able to know the TDS Challans that are generated for each area.

·    Maintain Number Groups: Here a Number Group is assigned to the combination of Company Code, Section Code and Withholding Tax Key. From below we can see that Number Group ‘01’ is assigned to the combination of AP01 and all the Tax Types.

·    Assign Number Ranges to Number Groups: In this step of configuration, the number Group created above is assigned to an Internal Number Range for the challans.

·    Maintain Number Ranges: Here we maintain the number ranges for Challans. The number groups are assigned to number range and these number ranges are maintained for fiscal years which are consumed while challan posting.

Here we Edit Groups by clicking on Groups button for defining number ranges specific to Number groups.

For example, if we want to maintain the number range for number group 01, then we have to select the number group 01 and then insert the number range for the same.

Here we can add or delete the number ranges for particular fiscal years.

·    TDS JV Configuration:

For passing the TDS JV for the rectification amount, we need to define the Document Type and the GL account for JV Losses. Following are the configuration nodes for the same.

The Document types are configured here in the following Node.

The JV Losses GL accounts are configured in the following Node.

Above is the full configuration document for the purpose of implementing Withholding Tax in the system.

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.

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.

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:

1. Creating Company Code
2. Activation of New G/L
3. Ledger
4. Parallel Accounting
5. Document Splitting
6. Document Type
7. 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.

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:

1. Special activation of the functionality as per notes 779366 and 605665
2. 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.

4. 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

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
  • Financial Accounting – Structure for G/L Accounting, AP, and AR
  • Controlling– Structure for Cost Center Accounting, Cost Controlling, and Profitability Analysis
  • Material Management – Structure for Material Valuation, Material Planning, Purchasing, Inventory Management, Invoice Verification, and Warehouse management
  • Sales and Distribution – Structure for Sales, Shipping, and Billing
  • Human Resources – Structure for all HR related activities
  • Logistics – General – Structure for general logistics activities including those relating to purchasing
  • Logistics Execution – Structure for the execution of logistics i.e. loading points, transportation points, and warehouses
  • Plant Maintenance – Structure for facilities maintenance

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:
  • Production
  • Administration
  • Sales
  • Research and development
• 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

Withholding Tax is also called as retention tax. Its requirement of Government to deduct or withhold a particular percentage from paying to the vendor and pay such amount to the Government on behalf of other person. It’s a kind of Indirect Tax.

[A] CONFIGURATIONS:

All the configurations for the Withholding Tax is done in the following Tab only:

·         Define Business Places: Business Place is to be created for each Tax Deduction Account Number (TAN) that company has.

·         Define Section Codes: In India for each Business Place a Section Code is created and mapping is done on one to one basis. In Section code information about Local Tax office as well as District Tax office can be made.

The flow for the configuration is such that firstly the Withholding Tax Key (e.g. 194C) is to be created then under that Withholding Tax type is created one at the time of invoice and other at the time of payment and then based on the different rates prevailing in the Income tax Act, different Tax Codes are to be created (e.g. for 194C, 2 different rates are there in the Act, one is 1% TDS on the contract basis and second is 2% TDS on the sub-contract basis)

E.G. 194C à Invoice / Payment Posting àC1/C2 based on different rates.

Define Withholding Tax Keys: Withholding Tax key is used to identify different withholding tax types. A name is to be given with the official key.

Withholding Tax can be deducted at two point of time; it can be either at the time of invoice or at the time of payment. So for this Withholding tax types are to be created one for invoice and second for payment.

·    Define Withholding tax Type for Invoice Posting: Here the withholding tax type is assigned for the invoice purpose and the same will not get triggered at the time of Payment Posting.

·    Define Withholding Tax Type for Payment Posting: Here the withholding tax type is assigned for the payment purpose and the same will not get triggered at the time of Invoice Posting. The withholding information is to be provided while posting for such document for Withholding Tax payment.

For each Withholding Tax Type, according to the different rates available in the Income tax rates, the different Withholding Tax Codes are to be created based on the Withholding Tax Type.

·         Define Withholding Tax Code: In withholding tax code, different rates are maintained and on what basis the TDS should be deducted is maintained.

Here above configuration is done and on the above basis the TDS amount will be deducted from the invoice or payment.

·    Defining Document Type for Challan:

Here we maintain the Document type for posting Challan.

·    Define Number Ranges for the Challans create: Here this is important on the basis that the client requires that he want details about the combination of Section Code and the Withholding Tax Key basis, so then different number range can be assigned and so he will be able to know the TDS Challans that are generated for each area.

·    Maintain Number Groups: Here a Number Group is assigned to the combination of Company Code, Section Code and Withholding Tax Key. From below we can see that Number Group ‘01’ is assigned to the combination of AP01 and all the Tax Types.

·    Assign Number Ranges to Number Groups: In this step of configuration, the number Group created above is assigned to an Internal Number Range for the challans.

·    Maintain Number Ranges: Here we maintain the number ranges for Challans. The number groups are assigned to number range and these number ranges are maintained for fiscal years which are consumed while challan posting.

Here we Edit Groups by clicking on Groups button for defining number ranges specific to Number groups.

For example, if we want to maintain the number range for number group 01, then we have to select the number group 01 and then insert the number range for the same.

Here we can add or delete the number ranges for particular fiscal years.

·    TDS JV Configuration:

For passing the TDS JV for the rectification amount, we need to define the Document Type and the GL account for JV Losses. Following are the configuration nodes for the same.

The Document types are configured here in the following Node.

The JV Losses GL accounts are configured in the following Node.

Above is the full configuration document for the purpose of implementing Withholding Tax in the system.

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 –

g

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.

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
  • Financial Accounting – Structure for G/L Accounting, AP, and AR
  • Controlling– Structure for Cost Center Accounting, Cost Controlling, and Profitability Analysis
  • Material Management – Structure for Material Valuation, Material Planning, Purchasing, Inventory Management, Invoice Verification, and Warehouse management
  • Sales and Distribution – Structure for Sales, Shipping, and Billing
  • Human Resources – Structure for all HR related activities
  • Logistics – General – Structure for general logistics activities including those relating to purchasing
  • Logistics Execution – Structure for the execution of logistics i.e. loading points, transportation points, and warehouses
  • Plant Maintenance – Structure for facilities maintenance

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:
  • Production
  • Administration
  • Sales
  • Research and development
• 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

Overview on Currencies

Currency is the Legal means of payment in a country. In the SAP system you can post in different currencies. For each monetary amount that you enter in the SAP System, you must specify a currency. You enter currencies as the ISO standards, for example, USD for US dollar.

In SAP, all currencies are maintained as per the ISO (International Organization for Standardization) standard.

In this section, one need to:

• check the preset currencies; and
• add new currencies according to your requirements

Here you define the currencies allowed in the system and the exchange rates for Currencies. You must define a company code currency for each company code in FI. In addition, you can define one or two parallel currencies for each company code.

Configuration Steps:

     Path:IMG -- SAP NetWeaver -- General settings -- Currencies

1. Check Currency Codes

The currency table must have entries for all currencies which are required in the company’s business transactions.

In SAP, all currencies are defined according to the international ISO standard (International Organization for Standardization). SAP recommends that one should use the ISO standard for your additional entries.

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

Actions

1. Check the currency entries for completeness.
2. Add the missing currency entries as required.
3. Use the ISO standard for your additional entries.

Example:

            Create a new currency key

            Currency Key: USDZ

Long Text: United States Dollar - 3 Decimals

Short Text: USD 3 deci

ISO Code: USD

Alternative Key: 840

2. Set Decimal Places for Currencies

Each currency has a different number of decimal places. If you are adding new currencies, which do not have two decimal places, you have to enter these currencies in the menu option 'Decimal places'.

In the settings delivered with the system, the most important currencies which do not have two decimal places are pre-set according to the ISO standard.

Activities

     1. Check whether in your company currencies are in use which do not have two decimal places, in addition to those delivered.

     2. Set the appropriate number of decimal places for these currencies.

     3.Define Standard Quotation for Exchange Rates

3. Define Standard Quotation for Exchange Rates

For each currency pair you need to define either the indirect quotation or the direct quotation as the standard quotation for the exchange rate.

This setting is used for the following activities:

1. When you process the exchange rates table you can enter the exchange rate either as a direct or an indirect quotation. If the exchange rate you enter does not have the same quotation as the standard quotation set up.
2. An exchange rate is only taken from the exchange rates table if it has already been given by the user. If this is a type of exchange rate that demands translation using a reference currency, the standard quotation is used to be determined for further processing.

4. Enter Prefixes for Direct/Indirect Quotation Exchange Rates

Exchange rates can be entered as a direct or indirect quotation. Here you can maintain two prefixes that can be used to differentiate between direct and indirect quotation exchange rates during input and output.

Recommendation : If you use mainly direct quotation exchange rates, you should set the prefix for

• direct quotation as ' '
• indirect quotation as a different symbol, e.g. '/'

If you do not set up a prefix here, the standard setting is valid:

• ' ' for direct quotation exchange rates
• '/' for indirect quotation exchange rates

The prefix ' ' means that you can enter the exchange rate without a prefix.

Example

Your local currency is EUR. You enter a business transaction in the transaction currency USD. '/' has been defined as the prefix for indirect quotation and ' ' for direct quotation (' ' = no prefix necessary). You can then either enter the exchange rate as a direct quotation without a prefix, e.g. '0.97234' or as an indirect quotation with prefix '/', e.g. '/1.08456'.

5. Check Exchange Rate Types

Exchange rates for different purposes for the same date are defined in the system as exchange rate types (you cannot delete existing entries).

If you need to carry out currency translations between number of different currencies, you can simplify exchange rate maintenance by entering a base currency for the exchange rate type.

The standard system includes the exchange rate types for the bank buying rate (G), bank selling rate (B), and average rate (M).

6. Define Translation Ratios for Currency Translation

Here you enter the translation ratios for currency translation. You enter these ratios for each exchange rate type and currency pair. You also specify whether you want to use an alternative exchange rate type for specific currency pairs.

Example

As of 01/01/1999 the exchange rate for DEM (German Mark) to FRF(France) will be calculated via EUR. To translate amounts enter:

• 01/01/1999
• The exchange rate type under which the exchange rates of the European national currencies are stored in the Alt. ERT field

7. Enter Exchange Rates

Exchange rates are required to:

· Translate foreign currency amounts when posting or clearing transactions.

· Determine the gain and loss from exchange rate differences

· Evaluate open items in foreign currency and the foreign currency balance sheet accounts

The system uses the type M exchange rates for foreign currency translation when posting and clearing documents. An entry must exist in the system for this exchange rate type. The exchange rates apply to all company codes.

8. Maintain Exchange Rate Spreads

In this activity you can derive the bank buying rate and bank selling rate using the average rate and the spread. By spread, we mean the difference between the average and buying rates or between average and selling rates. You convert to the buying or selling rate by first determining the average rate, then adding or subtracting the spread from that average rate.

Example

If the average rate between USD -> DEM is 1.46000 and the spread is 0.00400, the bank buying rate derived is 1.45600.

To make that calculation you must make the following entries in this step:

M (rate type) USD (From) DEM (To) 0.00400 (spread)

9. Define rounding rules for currencies

For the company code/currency combination for which payments are to be made not in the smallest denomination, but in a multiple of it, enter the currency unit (rounding unit) to which amounts are to be rounded.

This ensures that the amounts in this currency are always rounded to this unit. The payment program evaluates your entries to determine the cash discount and rounds off the amount accordingly.

10.  Define Worklist for Exchange Rate Entry

Here you create a worklist for entry and editing of exchange rates. Users receive authorization to enter exchange rates at the worklist level. It is possible for two or more users to edit two or more worklists in parallel, as the lock applies at the worklist level during editing.

You can assign each combination of exchange rate type, from and to currencies to one worklist only.

Click on New Entries:

11.  Assign Exchange Rate to the Worklist

Here you assign exchange rates to a worklist. You can assign all exchange rates to a worklist that are to be entered at the same intervals and linked to the same authorizations. You can enter the rates either directly in the productive system using transaction TCURMNT.

Click on to New Entries:

Click on Save.

12. Expiring Currencies

You can use this new function to allow currencies to expire. This means that you can attach warning or error messages to the creation/change of objects in the currencies expiring.

For example: the currencies participating in the European Monetary Union that then lose their validity after the end of the dual currency phase.

For longer running objects (such as sales orders) you can enter a date for a warning or error message.

In this way, you can ensure that on/after the end of the dual currency phase, these objects can no longer be created/changed in the currency that is being discontinued.

This function can also be used to discontinue currencies of countries where there is high inflation.

     i. Define expiry reasons

In this IMG step you define the expiry reasons for the currencies that you want to allow to expire.

Example

The Austrian Schilling loses its validity at the end of the dual currency phase. You want to prevent objects in this currency being create/changed drawing up to/after the end of this dual currency phase.

EURO - European Monetary Union

You can assign this expiry reason to the participating currencies in the next IMG step.

The Austrian Schilling loses its validity at the end of the dual currency phase. You want to prevent any objects in this currency being created/changed leading up to or after the close of the dual currency phase.

     ii. Define expiring currencies

In this IMG step you assign the expiring currencies an expiry reason as defined in the earlier step. You also define the new currency that is to replace the expiring currency.

     iii. Define warning and error dates

You can also enter a date for a warning and/or error message for each link between expiry reason and object type. The warning date is earlier than the error date

Example:

According to your requirements, e.g. 01.01.2002 as a warning date and 06.30.2002 as the error date for the object types made available by SAP. For company code dependent objects you can restrict the check by company code. When a user then wants to create/change an object in ATS from the 01.01.2002 a warning message and from the 06.30.2002 an error message will appear for the assigned object types and company codes.

Will shortly update with the SAP configuration screens as well.

Thank you,

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)

During the process of Lockbox you may receive the error F5 263 (The difference is too large for clearing) and one of the reasons is you may be trying to pay the invoices in record 4 with different amounts.

For example, you have 3 documents with different or same amount:

Document               Amount

000001                    $ 1,000

000002                    $    500

000003                    $ 2,000

In your Lockbox file you have in record 6 the total amount for the invoices, $ 3,500. In records 4, for each invoice, you have different amounts and expect with the sum of all the invoices you are able to clear the documents, but you receive the error F5 263 and a document is posted on account.

For example:

600100100003500011111111111111111111111111111

4001001601 000000001      0000350000                                          

40010016029000000002      0000000000    

40010016029000000002      0000000000

The error is correct based on system design. Lockbox program will not use the first amount and clear all documents/invoice. For this, you have to separate the amount in the invoices correctly according to the documents to be cleared, or use the user exits for lockbox (EXIT_RFEBLB20_001/EXIT_RFEBLB20_002) and change the file.

Overview on Cross-Company Code

The need for cross-company code postings arises in two situations first, when one of the company codes acts as the centralized purchasing or paying entity on behalf of other company codes and second, when one of the company codes sells the products manufactured by the other company codes.

Several company codes are involved in a cross-company code transaction. In a cross-company code transaction, the system posts a separate document with its own document number in each of the company codes. Individual documents are linked by a common cross-company code number. The system generates line items automatically (receivables and payables arising between company codes) in order to balance the debits and credits in each document.

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

Note

The company codes involved must be part of a single legal entity for tax purposes if you are posting invoices to which each of the following points apply:

• The receivables or payables are posted in a different company code from the one in which the revenue or expenses (costs) are posted.
• The business transaction is relevant to taxes.

If a single legal entity exists for tax purposes, then only one of the company codes creates the advance tax return for every company code involved in the cross-company code postings.

Configuration Steps:

     1. Doc type for cross company postings

     Document types are used to differentiate the business transactions and to manage how document are stored.

     Check the document type to be used for Inter-company postings. Example: SA However, you can also create a Z doc type as well.

     It’s better to have a Z Document Type for cross-company code transaction.

     Click on New Entries

     Click on SAVE

     2. Create G/L A/C in both company codes

We need to define the clearing accounts for the clearing entries the system makes when posting cross-company code transactions.

Caution: If the company code for which you are posting these items is an external one, then you can specify only G/L accounts as the clearing accounts.

      Create G/L accounts as below in respective company codes.

     Define G/L A/C No. 102290; under Co. Code: 1000

     Click on Save

     Similarly, Define G/L A/C No. 102291; under Co. Code: 1200

     Click on Save

     3. Prepare cross-company code transactions

    Here, you define accounts for the clearing entries which the system makes when posting cross-company code transactions. These clearing entries     represent the receivables and payables between company codes which result from central purchasing or payment.

     Click on Green tick Mark or Enter

     Maintain the parameters as below:

     Click on Save. 

     Repeat the steps for the other pair of company codes. You may use the List button to see all such company code pairs for which you have maintained      the settings.

     You can specify G/L accounts as well as Vendor and customer accounts for clearing between company codes. However, if you are posting these items

     to an external company code, then you can specify only G/L accounts as the clearing accounts.

     4. Prepare Cross Company code for manual payments

   Here, you enter the company codes which carry out manual payments and other clearing procedures for other company codes.

    Click on New Entries

     AUSGZAHL refers to Outgoing Payment.

     Click on Save.

     5. Prepare Cross company code for Automatic Payments

    Here, you make the settings for automatic outgoing payments to be processed by F110.

     Click on

     Click on New Entries and Maintain the below details respectively.

     Click on Save.

     Unit-Testing for the above configuration:

     1. Posting G/L Document with T-Code: F-02

     Company Code 1000 making payment for expenses on behalf of Company Code - 1200

     Enter

     Enter

    Press Enter and Simulate the document by click on to Document ˃ Simulate.

     Click to post the document.

     Here system generates a separate document number for each Company Code and a Cross-Co. code no (common document no for both Company           Codes) for both Company Codes.

     2. Post cross company code transaction – FB60

Make sure to use co code 1200 on the header and co code 1000 on the line item.

     Simulate document and then save.

     3. Change/ Display the cross company Document – FBU2/FBU3

     4. Reverse Cross Company Document – FBU8

     5. Manual Payment on behalf of other company code

Note: Alternatively, you can run Automatic Payment Program (F110) as well for that you need to customize step5.Prepare Cross company

code for Automatic Payments as covered above.

6. Display Line Item – FBL3N

       7. Display Vendor Line Item – FBL1N

Hi All,

Below pls find a step by step Archivelink configuration for uploading a zip file in Ixos for FI Accounting document. I hope you find this useful.

best regds

Subha