Special Purpose Ledger

Special Purpose Ledgers are ledgers that you can define for your specific business and organizational requirements. The ledgers contain the dimensions you enter. You can create Special Purpose Ledgers in your FI-SL system.

Step 1) Define Table Directory

IMG Path:

Financial Accounting (New) -> Special Purpose Ledger->Basic Settings->Tables->Execute Express Installation

In this activity, you can perform an express installation for a FI-SL system. The system performs the express installation for the respective functions using default settings and values.

Step 2) Maintain Table Directory

Financial Accounting (New) -> Special Purpose Ledger->Basic Settings-> Maintain Table Directory

In this step, you can call up a directory of all the tables used in the Special Purpose Ledger system and display or maintain these tables. The table directory is updated automatically when you install an FI-SL table.  You should only maintain it manually if absolutely necessary.

Step 3) Maintain Fixed Field Movement:

Financial Accounting (New)-> Special Purpose Ledger->Basic Settings-> Maintain Fixed Field Movements

In this step, you can define which fields of a sender table are transferred to the fields of a FI-SL receiver table. Table T800M is updated automatically if you install a FI-SL table you should only maintain the table manually if absolutely necessary. You should under no circumstances delete entries from this table.

Step 4) Maintain Field Movements

Financial Accounting (New)-> Special Purpose Ledger-> Basic Settings-> Master Data-> Maintain Field Movements

When assigning activities to your company code/ledger and global company/ledger combinations, you define a field grouping code for each combination.  This field grouping code determines which dimensions from other SAP application areas are transferred to dimensions in the FI-SL system.  In the "Maintain Field Movement" step you can maintain the field grouping codes for your activities.

Step 5) Define Ledger

Financial Accounting (New) -> Special Purpose Ledger-> Basic Settings-> Master Data-> Ledger-> Define Ledger

In this step, you can create and maintain a Special Purpose Ledger. Data is posted to the ledgers from other SAP application areas or external systems and can also be entered directly in the FI-SL system.

Step 6) Maintain Company code:

Financial Accounting (New)-> Special Purpose Ledger-> Basic Settings-> Master Data-> Ledger-> Maintain Company Codes

Display Data

When a document is entered it generates unique special purpose document number. In the reference field of the document the original document detail appears. It may be FI document number (If posted directly),PO number(If entered through MM module) or it may be a Billing document number.

Ex:Go to FB03 and enter FI document number as below and press enter.

In the below screen you can get the special purpose document number as below.

The special purpose ledger document appears as below.

Under this we will go through check management for a bank account with below transactions

• Maintain check number
• Issuing check for payment account
• Updating the check resister after check clearing
• Printing check
• Cancelling of check

1. Go to transaction  à F110
2. Click on environment tab à check information à number range

System will ask for the paying company code , house bank and the account ID for which we need to maintain the check lot.

Click on change option to go inside. Then click on create to create a check lot.

Give the check lot number along with along with starting and ending check number .

We can also maintain some details like short info and purchase date for the reference only . which will not effect to any account.

Click on and save to save the check lot. System will give a pop up that ‘check number have been saved.

The check number can update against payment document in two ways

1. Check updation through automatic payment program

To maintain the check updations through automatic payment program select RFFOUS_C

1. T-Code SE38 à execute à program name à  F8

1. Manual check updation

Under this we will update check manually against a bank payment document

Before execute this post one invoice and do the payment manually ( kz document )

1. Accounting à Financial Accounting à Banks à Environmentà Check balance à Create à FCH5 - Manual Checks

Make sure the bank account gl should be relevant to cash flow

*Otherwise system will show a message like the document is not a payment document

Give the payment document number, paying company code and fiscal year to track the payment document. Then give the house bank, bank id and check number to generate the particular check.

Press enter. 

Here you can maintain the payee details in addition to the data saved in vendor master .

We can maintain the check amount and payment date.

Click on . System will give a message that check created manually along with company code house bank and bank id details.

To display the check details we have 3 option

1. FCH1 - For Check.
2. FCH2 - For Payment Document.
3. FCHN - Check Register.

FCH1 - For Check

This code is used to know the details about a check if check number known

Here we can see the check encashment field is blank , means check is not cleared in bank.

FCH2 - For Payment Document

This code is used if the payment document number is known

From the payment document number system will show the related check details.

FCHN - Check Register

This is to know all the check details for a check lot

Here we have 2 option like –

1. Without line items – to see the check balance only
2. With line items here we can see the check balance with the clearing document

Press F8 or click on execute to go inside.

System will show all the check for the particular house bank and bank id , but the system will not show the related payment document details.

If with line item selected

Here system will give the check details along with the payment document.

FCH6 - Additional Info/Cash

Here we will maintain the additional data and the check encashment date after getting the conformation from the bank or from the current bank statement.

Give the paying company code , house bank and bank id with the check number. Press enter.

Update the check encashment date and Click on save.

If you see the check resister, you can see the encashment date maintained everywhere, means check got cleared.

Voiding of check

For voiding of check we have 3 types

1. Unissued check cancellation
2. Issued check cancellation
3. Cancel payment
4. 1. Unissued check cancellation

Unused check can be voided due to many reason like printing problem, destroyed or unusable etc.

Here we will give the paying company code , house bank and bank id along with the check number from and to with the void reason code to know why the check is voided.

After providing the details click on the void option

System will give a message that check voided.

So these cannot be use further .

1. 2. Issued check cancellation

1^stwe will post a payment document and update a check against the payment document.

T-Code FCH1 to display the check details

As we see check encashment is not update means check is not clear,

As we come to know the check is stolen so we need to void the check first.

Give the check number and the reason code for voiding.

Click on to void the check

System will give a message like check is voided but payment is not reversed.

If we see the check resister 

Here we can see the check voided and void date also update.

Now we can re issue a fresh check against the same payment document number .

After issuing a fresh check if we see the related check for a particular payment document system will show both the check.

1. 3. Cancel payment

If you reverse a issued check the system will reverse the check only and will not reverse the financial document , the reversal of payment need to be done in finance .

And if you reverse a payment document in finance for which check is already issued the reversal cannot be done in finance unless until check is cancelled

Cancel payment option will only use if the check is already encashment complete.

Click on cancel payment to reverse the check

System will give a message like payment for check xxxxx was cancelled and document reverse.

Hello All,

Last year in one upgrade project we have faced the issue in displaying G/L account text fields in chart of accounts & company code.

In this document I will explain about FS00/FSP0/FSS0 transactions in brief and the solution for the issue. Most of you folks might know it, but have a look & provide or add your comments.

Introduction to FS00

Transaction FS00 is used to edit the master G/L account centrally.

Using this T-Code:

· We can create, change, block or set the deletion flags for G/L accounts individually.

· We can change chart of accounts & company code specific details of G/L accountindividually.

G/L accounts can be created in two methods:

· One step Creation:

Here we can directly maintain the company code view & chart of accounts view for a G/L account. (FS00)

· Two Step Creation:

In this we first create the chart of accounts view & second we create a company code view for a G/L account.           

SPRO Navigation path:

On executing the highlighted ‘Edit G/L account centrally’ tcode FS00 will be opened.

G/L account has two main parts here:

The chart of Accounts:

This is at client level. Here chart of accounts data can be maintained.

FSP0:

The Company Code:

A company wants to use a particular G/L account from Chart of accounts, for that a company code view has to be created.

FSS0:

Upgrade issue in detail:

   We can maintain specific text ids for Chart of Accounts data & Company code data.

   Navigation path in SPRO for maintaining text ids.

Prior to upgrade all the chart of accounts text & company code text fields  were displayed properly as required in the FS00 layout irrespective of the settings in T-codes OBT6& OBT7.

In the above screen-shots we can see few check boxes are marked and few are left blank. Irrespective of these settings all the text fields are displayed in the G/L account layout properly prior to the upgrade.

After upgrade the text fields in chart of accounts are not displayed at all & one text field of company code not displayed in FS00, even though the all settings are same before & after upgrade.

On analyzing the issue found that, post upgrade as per the settings in T-codes ‘OBT6’ & ‘OBT7’ layout of ‘FS00’ is modified.

1. i.e. we have to mark the required check boxes in these transactions which are required to be displayed in FS00. If we don’t select any text field then the total block will be removed from the layout of FS00.

These changes are implemented through note 1307123 as part of upgrade.

Overview

An enterprise may have transactions in foreign currencies or it may have foreign branches. Foreign Currency transactions should be expressed in enterprise’s reporting currency and the financial statement of foreign branches should be translated into enterprise’s reporting currency in order to include them in the financial statement of the enterprise.

The principle issues in accounting for foreign currency transactions and foreign branches are to decide which exchange rate to use and how to recognize the effect of exchange rates in the financial statements.

Effects of changes in Foreign Exchange Rates

In India, Financial statements are prepared in Rupee, which is the reporting currency. All the transactions are done in rupee and, therefore, recorded in rupee. However, if enterprise has the transactions in another currency, say, in US,  dollars, because the enterprise is making export sales or importing material, plant or taking loan from abroad, in these cases, transactions shall be in foreign currency but recording and reporting has to be done in rupee, then the question of translation of foreign currency transaction in INR arises.

Further, there may be a case that an enterprise domiciled in India has the foreign operation in the form of –

a)   Branch in foreign currency: The transactions of foreign branch have to be incorporated in Head Office books as the financial statements are presented for whole enterprise including branches, domestic as well as foreign. The transactions of foreign branches are dominated /measured in the currency of the country in which the branch is situated, for example, if an Indian company X Ltd. Has a branch in New York. The branch must be transacting in US dollars where as X Ltd. Reports in rupee, therefore, an accounting standard is needed which will prescribe the method of translation of foreign currency in to reporting currency ( in this case , rupee).

b)   Subsidiary in foreign currency: If an enterprise domiciled in India has a subsidiary in foreign countries, and if as per applicable laws, Indian holding enterprises has to consolidate the account of foreign subsidiary, the need of accounting standard arises which will prescribe the procedure and principles for translation of subsidiary’s financial statement which are in foreign currency in to Indian Currency, as the reporting currency as the holding enterprise is Indian rupee.

c)   Associated or Joint Venture in foreign currency: The need of  Accounting standard will be felt when proportionate consolidation method under AS-27 [Financial Reporting of Interest in Joint Venture] is applied for jointly controlled entities and equity method of accounting is done in case of investment in associate in consolidated financial statements as per AS-23.

Accounting Standard -11 [AS-11]

AS-11 (revised 2003) shall be applicable in respect of accounting periods commencing on or after 01.04.2004 and is mandatory in nature. The revised 2003 AS supersedes AS-11 (1994). However, accounting for transactions in foreign currencies entered in to by the reporting enterprise itself or though its branches before 01.04.2004 will continue to be done as per AS-11(1994).

Applicability of AS-11

The accounting standard applies to –

1. a)   In accounting for transaction in foreign currencies
2. b)   In translating the financial statements of foreign operations – integral as well as non-integral.
3. c)   The accounting standard also prescribes the accounting for Forward Exchange Contract.

Non - Applicability of AS-11

The accounting standard is not applicable to –

1. a)   Re-statement of an enterprise’s financial statements from its reporting currency in to another currency for the convenience of users accustomed to that currency.
2. b)   The presentation in cash flow statement of Cash Flow arising from transactions in a foreign currency and the transactions of cash flow of foreign operations.
3. c)   Exchange differences arising from foreign currency borrowings to the extent that they are regarded as an adjustment to interest cost (refer AS-16)

Currencies

Currencies are legal means of payment in a country.

For each monetary amount that we enter in the SAP system, we must specify a currency. Currencies are entered as per ISO standards, for example, USD for US dollar, INR for Indian Rupee.

Few common terminologies associated with Currencies are as follows:

a)   Reporting currency– is the currency used in presentation of the financial statements.

b)   Foreign currency - is the currency other than the enterprise currency.

c)   Group Currency - A group currency is used in the consolidated financial statements. Before the consolidation process can be completed, all values in the  individual financial statements must be translated from the local or transaction currency into group currency

d)   Company currency: A currency used for internal trading partner

e)   Hard Currency: A country specific second currency used in countries with high rate of inflation.

f)    Index currency: A country specific theoretical currency used in some countries with high inflation as a comparison currency for purpose of statutory reporting.

In SAP, we define various currencies used by our company/company codes

Define Currency Codes (T code OY03)

SPRO-> SAP NetWeaver -> General Settings -> Currencies -> Check currency code

Other Terminologies:

g)   Exchange rate– is the ratio for exchange of two currencies as applicable to the realization of certain assets or the payment of specific liability and even recording of specific transactions or group of transactions.

h)   Average rate – is the mean of exchange rates in force during a period.

i)     Forward rate – is the exchange rate established by the terms of an agreement for exchange of two currencies at a specified future date.

j)    Closing rate – is the exchange rate at the balance sheet date.

k)   Monetary items - are money held and assets & liabilities to be received and paid in fixed or determinable amounts of money e.g. cash receivables and payables.

l)     Non monetary items – are assets and liabilities other than monetary items e.g. fixed assets, inventories, investment in equity shares.

m) Settlement date – is the date at which receivable is due to be collected or payable is due to be paid.

n)   Recoverable amount– is the amount which the enterprise expects to recover from the use of asset including its residual value on disposal.

What are foreign currency transactions?

Transactions denominated in a foreign currency or require settlement in a foreign currency are called foreign currency transactions.

Example of foreign currency transactions are –

1. Buying or selling of goods or services priced in foreign currency.
2. Acquisition or disposal of fixed assets denominated in foreign currency.
3. Incurs and settles liabilities denominated in foreign currencies.
4. Lending or borrowings when the amounts are denominated in foreign currency.
5. Unperformed forward exchange contract.

Exchange Rate(s) 

In SAP, we have to specify for each of the company codes, in which currency, the ledgers should be managed. This currency is the national currency/ local currency /company code currency/ operative currency of the ledger. From a company code view, all other currencies are then foreign currencies. In addition to the local currency, we can manage the ledger in two parallel currencies, for eg: group currency or hard currency.

In order for the system to translate amount in various currencies, we must define exchange rates. For each currency pair, we can define different exchange rates and then differentiate between them by using exchange rate types.

In Financial Accounting, currencies and currency translations are relevant in the following circumstances-

(a)  Account Master Data - Defining account currencies

(b)  Posting - Posting documents in foreign currency

(c)  Clearing - Clearing open items in foreign currency

(d) Foreign Currency Valuation

As we already defined in the previous section, Relationship between two currencies in known as Exchange Rate.

In other words, exchange rates are used to translate an amount in to another currency.

We define exchange rates in the system for the following purposes:

• Posting and Clearing

To translate amounts posted or cleared in foreign currency, or to check a manually entered exchange rate during posting or clearing.

• Exchange Rate Differences

     In order to determine gains or losses from exchange rate differences.

• Foreign Currency Valuation

To valuate open items in foreign currency and foreign currency balance sheet accounts as part of the closing operations.

Note: Exchange rates are defined at client level and therefore apply for all company codes.

To Maintain Exchange Rates (T Code OB08)

SPRO-> SAP NetWeaver -> General Settings -> Currencies -> Enter Exchange Rates

If you maintain the exchange rates on a daily basis, you should delete the exchange rates that you no longer required, so that there are not too many entries in the system.

We do not have to enter all exchange rates. There are many tools that can be utilized to automatically determine other exchange rates from existing ones.

Following tools are available-

a)   Inversion

b)   Reference Currency

c)   Exchange rate Spread

Exchange Rate Types (T Code OB07)

SPRO-> SAP NetWeaver -> General Settings -> Currencies -> Check Exchange Rate Types

Exchange rates for different purposes for the same date are defined in the system as exchange rate types.

If we need to carry out currency translations between a numbers of different currencies, we can simplify exchange rate maintenance by entering a base currency for the exchange rate type. Instead of entering translation rates between every single currency, we only need to specify the translation rate between each currency and the base currency. All currency translations then take place in two steps - into the base currency and from the base currency into the target currency.

Example

The base currency is INR. You want to translate GBP to USD. To do this, the following entries must be made in the table for maintaining currency translation rates:

• Ratio for GBP -> INR
• Ratio for USD -> INR

Translation from GBP to USD is then carried out automatically. The translation is done as though this exchange rate (GBP-> USD) was actually entered in the conversion table. 

The following exchange rate types exist:

• Buying rate
• Bank Selling rate
• Average rate
• Historical exchange rate
• Key date exchange rate

Define Translations ratio for currency translation (T Code OBBS)

The Currency Translation Ratio identifies the relationship of the units of one currency to the units of another. It is not possible to maintain exchange rate in the system without maintaining the translation ratio for the currency pair. It is essential to maintain these ratios for each exchange rate type & currency pair.

Configuration of Foreign Currency Revaluation in SAP

In this section, we define the specifications required for the valuation of foreign currency balances e.g. Bank accounts holding foreign exchange and Open Items in foreign currency – Customers and Vendors

Define Valuation methods

IMG à Financial Accounting à General ledger Accounting à Business Transactions à Periodic Processing  à Valuate à  Define Valuation methods

SAP uses exchange rate type M to value all foreign currency items. M is the average rate for any foreign currency.

In this step, you define your valuation methods for the open items. With the valuation method, you group specifications together which you need for the balance and individual valuation. Before every valuation run, you specify the required valuation method.

SAP provides various Valuation methods. We can also create our own key starting with Z.

SAP provides the following valuation methods:

BSK                  CZ/SK valuation method

EVR                  Always Valuate

KTO                  FC bal. per account, Lowest cost principle

Double click on BSK to display the configuration parameters

Val Method BSK is used for foreign currency account balances valuation for e.g. Bank account held in foreign currencies.

In the valuation procedure, various configuration options are available:

Lowest Value Principle – The Valuation is only displayed if the valuation difference between the local currency amount and the valued amount is negative that is an exchange loss is taken place. The valuation is carried out per item total.

Strict Lowest Value Principle – The valuation is only displayed if, as a consequence, the new valuation class has a greater devaluation and/or a greater revaluation at credit entries than the previous valuation. The valuation is calculated per item total.

Always Valuate – If you select this procedure, revaluations are also taken into consideration.

Revalue only – if you select this procedure, system only does a revaluation if applicable but does not do devaluation where there is exchange loss.

Reset- if you select this parameter, then the open items is valuated at the acquisition price. This way the valuation difference is set to zero. The old valuation method is reset. The account determination is reversed. The revenue that arises is posted to the expense account.

Exchange rates are types that are attached to the valuation methods.

Determine rate type from account balance- If you select this field, the account balance/group balance in the relevant foreign currency is used to determine the exchange rate type. This is relevant for account balance revaluation.

A document type SA is attached to Valuation method.

Configuration details – EVR (always valuate)

Configuration details – KTO

Assign GL accounts for Foreign Currency valuation (T code OBA1)

IMG >Financial Accounting > General Ledger Accounting >Business Transactions > Periodic Processing > Valuate > Foreign Currency Revaluation > Prepare Automatic postings for Foreign Currency valuation.

Double click on KDB line Item

Exchange Rate difference in foreign currency balances e.g. bank accounts held in foreign currency.

Exchange Rate Difference key: Can be kept blank or you can enter a key with 4 digits e.g. 0001. In case you create this exchange rate key then the same has to be updated in the GL code of the foreign currency account i.e. the control data tab which has the field exchange rate difference key. Only when it is attached, the system will re-valuate the foreign currency account.

Expense account: We need to enter the expense GL code for unrealized foreign exchange loss. The loss on revaluation is unrealized and will be automatically reversed in the next month e.g. 2345678  unrealized exchange gain/loss trade.

E/R gains: You need to enter the revenue GL coded for unrealized foreign exchange gain. The loss on revaluation is unrealized and will be automatically reversed in the next month.

Double Click on KDF

Here we will enter the GL codes for AR and AP (the reconciliation account).

We can enter different GL codes for currency and currency type or we can keep it blank.

12000092   Sundry Creditors for Expenses

84000001   Exchange Gain / loss others – Realized

84565882   Exchange Gain / loss others – Revaluation

12000023 Creditors Revaluation

Account Determination (OBYC)

There can be exchange rate difference on account of document posted through MM process, in such cases we need to maintain the exchange gain/loss account for KDM (Materials management exch.rate diffs) key using Transaction code – OBYC.

Exchange rate differences in the case of open items (KDM)

In the case of open items, Exchange rate differences arise when an invoice relating to a PO is posted with a different exchange rate to that of the goods receipt and the material cannot be debited or credited due to standard price control or stock under coverage/shortage.

Double click on KDM to display the configuration parameters:

Now system will post the arising Gain/loss automatically to the assigned GL account, for this purpose default cost centers are required to be maintained for the gain/loss accounts to which the posting will be done using transaction code – OKB9

Introduction

RMCA (Receivables Management – Contract Accounting) which is designed for mass processing for Telecommunication companies with huge customer database can be integrated with COPA for profitability Analysis. This article talks about COPA related configuration settings and processes in RMCA.

The key difference between RMCA and FI on COPA integration is that in FI, COPA document is generated at the time when the document is posted to FI. In case of RMCA, COPA transfer needs to be done as a separate activity which will take profitability segments for the documents into COPA and generate COPA documents. This is done as a daily transfer from RMCA to COPA in tune with RMCA GL transfer.

Account Determination

Account determination in RMCA is based on the Main Transaction (MT) and Sub Transaction (ST) settings. Combination of MT and ST determines the GL account to be posted. If the determined GL is set for Profitability Segment as required entry in the field status group, then the Entry in RMCA will always ask for profitability segment input while posting the document.

Defining Characteristic Derivations for CO-PA Update

While transferring data from external systems (Billing Systems) into RMCA through IDocs, configuration settings needs to be done for COPA characteristics derivation

IDoc FKK_EBS_TOI_COPA is used for data transfer in RMCA. Segment E1FKK_EBS_TOI_COPA_ITEM takes care of COPA characteristics for the document which is posted for the external data transfer

Go to > CA Receivable and Payable > Data Transfer> Communication with External Billing Systems> Define Characteristics derivation for COPA update.

In this activity, for each operating concern, you define the characteristics for the update in the profitability analysis (CO-PA). The table is used to derive the characteristics when you post the IDoc characteristic data.

The table is used to derive the characteristics when you post the IDoc characteristic data. The external billing system transfers the characteristic values to the application in the IDoc category FKK_EBS_TOI_COPA or FKK_EBS_DOC in segment E1FKK_EBS_TOI_COPA or E1FKK_EBS_DOC_COPAITEM. If the characteristic values cannot be provided via the IDoc interface, you can determine the value using a function module at runtime.

Transfer to COPA from RMCA

This is done as a periodic processing unlike the real time transfer in GL. Transaction Code to be used is FPG3

The transfer is based on Reconciliation keys and documents having line items with profitability segment numbers are transferred to COPA. The status of the transfer is retained for each reconciliation key so that duplicates are not transferred. All Reconciliation Keys which are selected for transfer should be closed before initiating transfer.

If the line items contain a posting date for which the posting period is already closed, the program tries to determine an alternative posting date. You maintain alternative posting data in transaction FPG0.

Profitability Analysis and System Performance.

A very important factor to be considered while implementing COPA is system performance while posting or transferring documents to COPA. SAP Note 35288 talks about the same . When a document is posted to COPA, system would check for a profitability segment number for the combination of characteristics values to be posted in table CE4xxxx. Creating a secondary index with the most selective fields for this table will make this search faster when external data is transferred or journals are posted. Otherwise there is a risk of considerable slow down in processing each transaction. The most selective fields in the secondary index can be found by running the report RKE_ANALYSE_COPA. Once a new index is created, report RSANAORA to be executed to update DB statistics

I just want to share the experience of how to print out all the Field Status Group detail definition to excel/local file. I was trying to find from SCN but fail to see the correct support information either the way to print out or table where store all in one configuration. That is why coming to this thread.

First, you need to know how to come into the Field Status Variant:

Path: SPRO --> Financial Accounting (New)-->Financial Accounting Global Settings (New)-->Ledgers-->Fields-->Customer Fields-->Define Field Status Variants

Tcode: OBC4

Second, if you wish to print out all of Field Status Group from your own Field Status Variant, simple steps are:

1. Select all Field Status Group

2. Then come to Table View --> Print --> Field Status Variant (combine key Shift + F1)

3. Then, last step is to extract to local file and you can easily to use.

Hope it could help.

Regards,

Hai

Activation of Open item management:-

I would like to share one document, where you can learn how to activate the open item management with using of existing SAP tools. SAP given tool activates OI for GL accounts since ECC 600 onwards, if balances existed ,but suggestible to use from ECC 603 onwards as per SAP note 1770786.

What is open item management:- 

In technical point of view it is just check box of control data tab in GL master data (FS00).Check screen shot as marked.

In Functional point of view, it would be control all outstanding’s ,which will be receive from customer’s and pay to vendor’s / Employees / Govt.authoirities etc. in each and every line item of respective GL account reports. It should be give clear report, which line item / invoice has to be paid to vendor and received from customers. One red / Green symbol as below mentioned will be appear in standard report like FBL3N, FBL5N, and FBL1N & FAGLL03 report ,if you marked as open item management check box in GL master. Red symbol states those line items are still open and yet to clear & green symbol line items states those line items are cleared.

Accounts to be managed as Open item management:-

1. Bank clearing GL accounts: - All bank sub ledgers like Bank incoming payments & outgoing payment GL account must be select as open item management & it will be help us for bank reconcialtion purpose.
2. Payable GL accounts :- Like salary payable ,commission payable ,wages payable Freight payable & other tax related GL accounts like VAT payable must be select as open item management & it will be guide to FI department line item was tracking whether outstanding line items are paid to vendor’s / employees and VAT authorities or not.
3. GRIR Clearing accounts: - You easily recognize your contingency liability status of GRIR accounts, if you activated OI management.

Process to activate the OI Management:-

Case 1:- Activate open item management for GL account with existing all line items:-

Transaction code: - FAGL_ACTIVATE_OP

You can able to activate OI for all existing line items with using of above transaction. Let us assume there is one GL account as mentioned screen shot, which was not maintained as OI and posted several line items & now you want to activate open item management for all existing line items.

FAGLL03 report view (Before activation of Open item management)

Let us assume now business would like to activate all above line items as open with using of above program. Go to that transaction code & do as follows.

Enter company code & GL account number, which is to be activating as OI & switch on date should be before the line items was posted with respect to above GL.In above case study my first document posted on 01.04.2013 ,that means switch on date should be earlier than 01.04.2013.  Document type & account for transfer posting is not required, if you enter switch on date earlier than my first document posting date & enter profit center and segment, which are mandatory & execute.

Mentioned log would shown

Display must not be red mode, it should be green or yellow mode. Comeback from above screen & unselect test run & execute.

Check above log ,which was given information about how many line item has been activated as open items & any transfer document posted or not. Now go to FAGLL03 & check whether line item activated as open item management and also check GL master activated for OI check box or not.

Check mentioned applicable SAP notes, which can give more details.

1356457 - Function of FAGL_ACTIVATE_OP

1349772 - FAGL_ACTIVATE_OP: Standard open item management

1770786 - FAQ - Open Item Management - FAGL_ACTIVATE_OP

Regards

Mani Kumar

Hello, SAPers!

         From time to time, when you configure custom DMEE trees you'are faced with different bank-dependent requirements concerning the format of payment orders. Most of these requirements can be dealt with using standard customizing and mapping procedures. However sometimes there are more complicated issues related to configuration of DMEE trees. One of the comparatilvely typical problems is use of TAB as delimiter in segments of DMEE tree. Basically, you can use any printable symbol as a delimiter, but you cannot simtly insert TAB as symbol on the Format attributes tab of your DMEE tree and there is no other standard customizing that will enable this. Thus, in order to configure tab as delimiter in segments the following configuration should be performed.

          First of all, make sure that there are no delimiters in segments specified for your DMEE format tree. Go to Format attributes tab and make sure that the following fields are empty:

          On the transaction level of DMEE the following logic has to be applied: create a composite node for each element which will group its value and tab value. For instance, according to bank requirements there should be a field with payment document type with fixed value 01 for domestic payment. In order to meet this requirement you create a composite node payment_doc_type:

          As can be seen from the figure above, composite node doesn’t require a lot of customizing. You just have to specify a name of composite node and short description. As a rule you’ll need two elements (VALUE and TAB) for each composite node – except for those nodes which are not mandatory.

          VALUE element will have different properties depending on mapping requirements. For instance, field with payment document type should return fixed value “01” therefore this element will have the following properties:

          This particular VALUE element uses Constant as mapping procedure therefore "01" was specified on the Source tab in the respective field:

          TAB element will have the same properties for each composite node:

          TAB elements should use Exit function as mapping procedure therefore function module Z_DMEE_TAB_SYMBOL was specified in the respective field on the Source tab:

          Consequently you will have to create a simple function module in transaction SE37. Source code for this function module can be found in the attached file. Please, note that you need developer key in order to create function module.

          As a result, the DMEE tree will look as follows:

          Create other composite nodes as required for payment medium for your bank and activate the tree. Afterwards, when you run the transaction FBPM and create the payment medium, your lines will look as follows:

      Generally, I would recommend the following sequence of configuration steps for DMEE tree with TAB as delimiter:

          1. Figure out what fields do you need and create a list with proposed names and mapping procedures for each field;

          2. Create composite node for each field;

          3. Create an element TAB and copy it as subnode to each composite node;

          4. Create an element VALUE for each subnode with properties that will satisfy your mapping requirements.

     I hope this information will be useful. All suggestions are welcome!

     Best regards,

     The Wirtschaftsmann

     P.S. Source code for FM was found on SCN under the following link: DMEE Transaction

     Thanks to authors!

1. Purpose of this documents   

From Bank to Bank Transfers SAP standard future; business can easily move money between one house banks to another house banks with in company code or between company codes.

2. Where Applicable

When and where business want to transfer amount form one bank accounts to another bank account.

System automatically generates interbank amount transfer accounting entry and it will generate authorized form.

Take authorized signature on system generated from / DME file and sent to amount transfer bank, with reference to the authorized letter / DME file the sending bank will be transfer amount to receiving bank.

3. Solution.

      Step by step guide provided in attached document.

Symptom:

When running transaction FAGL_CO_02, the accumulated balance doesn't match with the cumulative balance displayed in FAGLB03.

Reproducing the Issue:

1. Enter transaction FAGL_CO_02.
2. Enter chart of accounts and G/L accounts.
3. Enter company code and ledger.
4. Enter  fiscal year and posting period.
5. Enter account selection: E (P&L accounts).
6. Execute and check the total accumulated balance for P&L statements accounts.
7. Enter transaction FAGLB03.
8. Enter same account numbers, company code, fiscal year and ledger selected previously in FAGL_CO_02.
9. The total accumulated balance doesn't match with FAGL_CO_02.

Cause

The program is working as per the standard design in this case if transaction FAGL_CO_02 is run with account type output "E"  for P&L accounts.
Bear in mind that accounts listed in FAGLB03  include balance sheet accounts as well which are not listed in FAGL_CO_02 report.

OB52 – Maintain posting period control through authorization group.

Requirement is to use the concept of Authorization Group in posting period Variant and restricting the

access of posting period 1 to limited user who is defined in the authorization group. Other user able to

post in period maintained in posting period 2.

The authorization group only has an effect in period defined in period 1 area and period 2 area

is for all other users.

First maintain the authorization group from T-code SM30 for authorization object F_BKPF_BUP.

Now maintain the period as per requirement and assign the authorization group.

Now assign authorization group 'FIGR' to authorization object F_BKPF_BUP and generate it.

1. Here we have given authorization for FIGR authorization group to user, now user will able to post
   the document in period 1 area that is April 2014 to May 2014.

  2. Here we remove the authorization for ‘FIGR’ authorization group to user, now user will not able to post the  
      document in period 1 area that is April 2014 to May 2014.

Regards,

Rohidas Shinde

Dear Forum,

Please find the below process to activate the GL line item display and open item management for a GL account.

GL display: FS00

GL line item display: (FBL3N)

Due to absence of line item display indicator in the GL master when user try to display the GL account in FBL3N system won’t allow displaying any open items.

Now to activate the line item display indicators in the GL master initially block it for postings and execute the program RFSEPA01 in SE38.

Execution of RFSEPA01 program to display the posted line items:

Give the GL account and company code

After execution the GL line item display in FAGLL03 and FBL3N will show like below:

Now execute the transaction code FAGL_ACTIVATE_OP to activate the open item management, give the GL account and company code and switch on date.

After execution in the GL master the open item management will active automatically:

In the GL line item display the open items will show like below:

After the T code execution the open item management will active and open items will appear in the GL line item display.

Regards,

Ravi

Purpose

If a vendor is also a customer, from the perspective of making vendor payment, it is possible to offset the outgoing payment amount from the existing amount owed to the customer when running the F110 - Automatic Payment Run.

Prerequisite settings in vendor/customer master

Vendor Master

1 Input Customer Information in Vendor Master

1. The customer number is used by the payment and dunning programs for clearing open items. For line item display, the link to the customer line items is established using this number.

     If you require clearing between the customer and vendor, the following requirements must be met:

     -  The customer number must have been entered in the corresponding vendor master record.

     -  The vendor number must have been entered in the corresponding customer master record which we will do in the next step.

     -  The fields "Clrg with vend." or "Clrg with cust." must have been selected in both master records.

     2. For clearing with customer setting, the screen is as shown below. As for clearing with vendor setting will cover in next step.

When you try to activate the ‘Clrg with cust.’ Indicator, SAP displays the follow message where the ‘clearing account 10201734’ is the customer number.

Customer master

2 Input Vendor Information in Customer Master

    1. Specifies an alphanumeric key that uniquely identifies the vendor or creditor in the SAP system.

     2. Then turn on the ‘Clearing with vendor’ indicator in order to complete the settings in respective master in order to allow clearing with customer during

          automatic payment process.

Clearing between vendor and customer via F110

1 Analyse Vendor and Customer Balance

1. Analyse the open item balance for vendor, that the total amount outstanding on vendor side must be greater than the balance outstanding on customer side. This is required in order for clearing with customer to work.

         Vendor Open item

Please take note, the item with debit balance where the document number is 620004610 as shown above, should be excluded from automatic payment in the parameter set up (shown in next step) as SAP throws out error during payment run.

     2. Check the outstanding balance on the customer side where the amount is 2,200 very much less than the vendor outstanding amount.

          Customer Open Item

     3. Together with the settings both in vendor and customer master we discussed previously being fulfilled then we can proceed to next step for payment           settlement between the vendor and customer.

2 Automatic Payment Settings and Payment Run

      1. In the F110 (Automatic Outgoing Payment) parameter settings as shown below, both vendor and customer must be input in order to do offsetting payment           between a vendor and customer. Both vendor and customer numbers must be entered besides other settings.

     2. The result of payment proposal list shows the amount details of all open items from vendor and corresponding customer highlighted in red colour box.

     3. Display payment proposal job log

     4. Display payment job log

     5. Actual document posted

This document will explain the process of reference key 1 and 2 to make mandatory field without creating any validation for particular GL accounts.

You can restrict it for company code wise also.

1. Create field status : Go to SPRO > Financial Accounting (New) > Financial Accounting Global Settings (New) >  Ledgers > Fields > Define Field Status Variants

         Select field status groups which is already activated for your company code.

         Create new field status group by copying any existing group which is applicable for GL master.

         Double click on newly created field status group following screen will be appear

2. Double click on  General  tab then click on required entry to Reference Specification 1/2 option

3. Go to FS00; enter GL account number, company code. Select tab Create/bank/interest select from the list field status group which is created

4. Reference key 1 and 2 will be mandatory field while posting document entry for this GL.

Regards

Sampat KumKar

Introduction

RMCA (Receivables Management – Contract Accounting) which is designed for mass processing for Telecommunication companies with huge customer database can be integrated with COPA for profitability Analysis. This article talks about COPA related configuration settings and processes in RMCA.

The key difference between RMCA and FI on COPA integration is that in FI, COPA document is generated at the time when the document is posted to FI. In case of RMCA, COPA transfer needs to be done as a separate activity which will take profitability segments for the documents into COPA and generate COPA documents. This is done as a daily transfer from RMCA to COPA in tune with RMCA GL transfer.

Account Determination

Account determination in RMCA is based on the Main Transaction (MT) and Sub Transaction (ST) settings. Combination of MT and ST determines the GL account to be posted. If the determined GL is set for Profitability Segment as required entry in the field status group, then the Entry in RMCA will always ask for profitability segment input while posting the document.

Defining Characteristic Derivations for CO-PA Update

While transferring data from external systems (Billing Systems) into RMCA through IDocs, configuration settings needs to be done for COPA characteristics derivation

IDoc FKK_EBS_TOI_COPA is used for data transfer in RMCA. Segment E1FKK_EBS_TOI_COPA_ITEM takes care of COPA characteristics for the document which is posted for the external data transfer

Go to > CA Receivable and Payable > Data Transfer> Communication with External Billing Systems> Define Characteristics derivation for COPA update.

In this activity, for each operating concern, you define the characteristics for the update in the profitability analysis (CO-PA). The table is used to derive the characteristics when you post the IDoc characteristic data.

The table is used to derive the characteristics when you post the IDoc characteristic data. The external billing system transfers the characteristic values to the application in the IDoc category FKK_EBS_TOI_COPA or FKK_EBS_DOC in segment E1FKK_EBS_TOI_COPA or E1FKK_EBS_DOC_COPAITEM. If the characteristic values cannot be provided via the IDoc interface, you can determine the value using a function module at runtime.

Transfer to COPA from RMCA

This is done as a periodic processing unlike the real time transfer in GL. Transaction Code to be used is FPG3

The transfer is based on Reconciliation keys and documents having line items with profitability segment numbers are transferred to COPA. The status of the transfer is retained for each reconciliation key so that duplicates are not transferred. All Reconciliation Keys which are selected for transfer should be closed before initiating transfer.

If the line items contain a posting date for which the posting period is already closed, the program tries to determine an alternative posting date. You maintain alternative posting data in transaction FPG0.

Profitability Analysis and System Performance.

A very important factor to be considered while implementing COPA is system performance while posting or transferring documents to COPA. SAP Note 35288 talks about the same . When a document is posted to COPA, system would check for a profitability segment number for the combination of characteristics values to be posted in table CE4xxxx. Creating a secondary index with the most selective fields for this table will make this search faster when external data is transferred or journals are posted. Otherwise there is a risk of considerable slow down in processing each transaction. The most selective fields in the secondary index can be found by running the report RKE_ANALYSE_COPA. Once a new index is created, report RSANAORA to be executed to update DB statistics

SAFT for Online Communication of Transports to AT (PORTUGAL)

Content

1. Purpose
2. Preparation

           2.1 Prerequisites

   3.  Implementation Information

          3.1Sollution Overview

   4.   Report ways of working

1. Purpose:

            As per Country PT legal requirement (198/12), delivery notes which accompany the shipment of goods will require previous notification and approval from TAX authorities. The truck has loaded the goods for shipment must notify the authorities with the corresponding delivery notes before leaving the loading center.

2. Preparation:

           To meet the legal requirement (198/12), all companies in Portugal are required to submit the transport document (before goods issue) in SAFT format.

2.1 Prerequisites:

            For this SAP has released the below SAP notes to generate the data and send it in particular XML format. By implementing these notes, country will be able to submit transport documents to PT Tax authorities before goods issue.

Once we implemented all above SAP Notes in the System, PT Country will be able to submit the required data to the tax authorities in the requisite format.

3.Implementation Information

          3.1 Sollution Overview:

The SAFT for online communication of transports to AT solution enables the generation of a XML File containing the data of delivery documents in the SAP system. This document is then submitted manually to the Portuguese Tax Authorities online website. 

4.Report ways of working

Please find below Steps to follow while executing T-code: RMINI_SAFT and Report SIPT_GM_SAFT_PT_XML:

The report SIPT_GM_SAFT_PT_XML (RMINI_SAFT) is the main component of the SAFT for online communication of transports to AT solution. This is used to Export the XML file and Import the XML Response from the Tax Authorities.

For this transaction we will have to perform follow below two steps in a sequence:

1. Export
2. Import

Export:

• As per Business Scenario we will have to extract XML file (in given system patch) for which deliveries has to validate
  by TAX authorities website (AT site) and we will have to provide Extracted XML file to PT business.
• Once XML file extracted from SAP system you can track the status in table (WSPT_LIKP) i.e.(In Progress).
• Once XML file successfully validated at AT site with no errors. After that Business users has download same XML file from
  AT site (which they uploaded).
• After we will have import the same XML file into SAP system which we have downloaded from AT site.

Make Sure Tax Authorities Website (AT site) is kind of Third party system which will be used by Business (only Business Users will have access to AT site).

Use the selection screen to find delivery documents that you want to export.

a. Choose Export.

b. Choose a filename in your computer where the SAFT file will be saved.

c. Apply the selection criteria as desired.

I have given the desired path where I need to save extracted XML file as mentioned below.

I have given the company code as 0160 (i.e., PT country) and goods movement date range (this can be changed as per requirement) as mentioned below.

Important Notes:

• This report we have implemented only for PT country.
• This report will display only the deliveries which are having PT shipping points.
• As per the design to display delivery list system will check shipping point country if it is PT only report will display
  the deliveries list.
• If some deliveries having PT plants and ES shipping points system will ignore this delivery document.
• This report will display the delivery document which already invoiced and which are not invoiced (PGI done).

I have executed the report for above mentioned selection parameters.

As you can see list of PT deliveries for the given selection parameters.

Here those deliveries which are in Green light those are already invoiced and which are in Red light those are not yet invoiced (but PGI has been done).

Here you can select the deliveries which needs to extract into XML file and for my testing purpose I have selected below deliveries.

After selection you will have to click on “Export XML”.

If you select any documents which plant date in the past system will show below pop-up(not an Error) and we need to click on “ok”.

As you can see below selected deliveries has been extracted to XML file and XML file has been saved in given path.

XML file:

As explained above this XML file has to be uploaded in Tax authorities’ site (AT site) and this has activity has to perform by business users only.

Once results are fine in Tax Authorities website Business users has to download the same XML file which they have uploaded.

TAX Authorities Website looks like below:

Below screen not related to above XML file. This was related to different XML file I am just showing how AT site will show the pop when any XML file uploaded successfully without any errors.

Import:

We can import the valid XML file which has been down loaded from TAX Authorities Website.

Once it got imported an import log will show which documents were accepted by the authorities and that are now stored in the SAP system. The errors that were present in the response are also showed here and we can tract the delivery statues in table (WSPT_LIKP) and for the approved deliveries status will be changes to Approved with an Approval ID.

A profit center (PC) is a sub-division within the organization responsible for its own revenues, expenses, assets and the ROI (return on investment).  Profit centers can be considered as “companies with in the company”

It is a mystery to many how the profit center is determined in various postings. Without understanding this, it is not possible to define a sound SAP enterprise structure. For example, Company ABC wants to decide at what level  the Profit Centers must be defined. The knowledge about the profit center determination will help you judge whether the decision taken is tenable or not

Here, we will discuss Profit center determination in various postings that happen natively in FI module or triggered from Logistics module i.e. MM, PP and SD modules.

At the end of the document, you will appreciate the (Crisp) logic used in SAP to determine the Profit center in various important scenarios.

Profit Center determination in native FI Postings: -

Profit Center determination in MM Postings: -

In the case of MM postings, the Profit center is first determined in the parent document, i.e., Purchase order, and it flows from there into subsequent postings.

Profit Center determination in PP Postings: -

In the case of PP postings, the Profit center is first determined in the parent document, i.e., Production order, and it flows from there into subsequent postings.

Profit Center determination in SD Postings: -

In the case of SD postings, the Profit center is first determined in the parent document, i.e., Sales order, and it flows from there into subsequent postings.

Hope you enjoyed reading the document and it served its purpose. Do share your feedback / comments at the end of the document after reading the same!!!

Thanks,

Kavita Agarwal

Introduction:

The document provides the overview of invoice approval process cycle in OpenText VIM for both PO and Non-PO invoices along with important configuration steps involved. It also covers linkage of process types and chart of authority in invoice approval process along with their configurations.

Invoice Approval Process:

OpenText VIM provides the facility to approve the invoices before they are created in SAP. The approval system is easily configurable and highly customized with provision of multi-level approval. Approval process is available for both PO and Non-PO based invoices. Non-PO invoices support multilevel approval. PO invoices have only one step approval but can be customized for multilevel approval. Approval can be delayed by sending the invoice to AP Processor first. Approval process ends when the invoice is approved and posted or deleted or rejected.

Important roles involved in invoice approval process:

1. Coder: Person responsible for entering accounting data.
2. Requester: Person who has requested the goods or services.
3. Approver: Person responsible for approving the invoices.
4. AP Processor: Member of Accounts Payables team responsible for dealing with invoices.

NOTE: Above mentioned roles are the basic roles involved in the IAP however one can create additional roles.

Figure 1: Invoice Approval Process

Approval can be handled at two stages:

1. DP processing stage: Process type needs to be configured accordingly (steps to configure the process type are written below). Approval workflow can be started by clicking ‘Submit for Approval’ option.
2. After conversion of DP document into SAP parked invoice: Appropriate parking reason has to be provided. Create parking reason if required. Based on the parking reason workflow starts. Approval workflow is triggered by changing the parking reason. Trigger points can be configured for this by going to /n/opt/spro > Configuration > Non PO Processing > Invoice Approval Process > Approval Workflow > Additional Configuration – Web Approval. Below is the screen shot.

Figure 2: Configuration for document parking reason

BLOCKRSN 9 is for PO based invoice and V is for Non-PO based invoice. ‘Start Approval Immediately’ starts the workflow immediately without delay.

Configure Process type: A process type needs to be created for approval when approval is required at DP processing stage. Process type can be defined using transaction /n/opt/vim_8cx1. Below are the important fields:

• Process type number: 5 digit unique number.
• Process type: Description of Process type.
• Initial Actor: User that gets the work item.
• Initial Actor Function: If no initial actor is available then it is picked from the function module specified here.
• Is Exception: If this check box is selected then process type will be not be relevant for automatic document processing.
• Auto Start: If this check box is not checked then Initial Actor manually starts the workflow else it is automatically started.
• Create SR: If this is checked then automatic service request is created.
• Country Check: Checks country specific configurations.
• Workflow Type: Opentext Approval Workflow or External Workflow can be selected for this.
• Task ID
• Binding Function
• Max Retry Counter
• Retry Time (Minutes)
• Mail Config ID
• Function Module for Rcvr Email
• Function Module to send email
• Logical System: Enter the name of the system where the external workflow is supposed to run.

Figure 3: Process Type

To receive and send email the configurations are done in the process type for respective function modules.

IAP Process Configuration:

Below are the important steps involved in the invoice approval configuration.

• Defining Multi Level Approval: For PO invoices a custom extension is required. If the approver rejects the invoice then it is send back to previous approver. If the first approver rejects the invoice then it is send to AP department. The user from AP department has the option to select the approver if process is started from DP dashboard. Approvers are maintained in Chart of Authority.
• Driving the Approval Flow for DP Invoices: The process starts when invoice gets the process type for approval or ‘Submit for Approval’ button is clicked. For Non-PO invoices the initial approver is usually entered in the indexing screen in the Email ID field. For PO invoices the approver is the requisitioner.
• Driving the Approval Flow for Parked Invoices: The process starts when document is parked or ‘Submit for Approval’ button is clicked.
• Defining Approval Hierarchy and Approval Level: Approval hierarchy can be implemented by either using OpenText delivered approval hierarchy table or customization as per business needs. OpenText delivered approval hierarchy table allows defining the approver, coder and respective hierarchy for them along with approval amount, currency, company code and plant for which the user is authorized to approve.
• Defining the Expense Type: For few expenses (Marketing Expense, Office Supply, Communication, Utility, etc.) a different path might be required and for this expense types are configured which allows defining different approval limits for different expense types. Expense type can be created by going to /n/opt/spro and then to LiveLink VIM - Configuration > Non PO Processing > Invoice Approval Process > Setup Approval Chain > Expense Types > Maintain Expense Types. Create the expense type, provide description and indicate if approval is required for the expense type.

Figure 4: Expense Types

• Defining Approval Access Rights: Some of the access rights are: Approve, Coding, Coding_Display, Coding_Delegation, Override, Look_ahead and Configuration
• Configuring the Email Notification: Approvers will receive email notifications if any new invoice is waiting for their approval for this method Get_Approver_List of business object type /ORS/INVAP is used to get the approvers and method SENDEMAIL is called to send the mail. The actual function to create the send request is /PTGWFI/CP_SENDMAIL. The body of the mail can be easily configured.
• Configuring the Certify Message: When approver approves the invoice then a message is displayed. This can be configured at /n/OPT/SPRO transaction and follow LiveLink VIM -Configuration > Non PO Processing > Invoice Approval Process > Technical General > Invoice Approval Configuration. Maintain the text id here that needs to be shown post approval.

Figure 5: Certify Message Configuration

• Configuring General Ledger Fields and Search Help for Web Screen Fields: This can be done at LiveLink VIM - Configuration > Non PO Processing > Invoice Approval Process > Financial Processing > Online Coding > GL Titles.

Figure 6: General Ledger Fields and Search Help for Web Screen Fields

Chart of Authority:

Chart of Authority (COA) is required to setup the approval hierarchy for Non-PO invoices. In case of PO invoices baseline implementation determines the
requester as the first approver and is the only approver unless a customization is done for PO approver. In COA one can configure the approval hierarchy, the approval limit and coder for the invoice approval process. T-code to access the COA is /n/opt/vim_7cx1. There are three views available in COA.

• User Details View: It contains the general details for all the users like user id, user’s manager id, if user is allowed for bulk approval or not, department of user, email address, telephone number, default coder etc. If the requirement is to allow the approval to go first to the approver and then to the manager then maintain the manager for the user in this view without manually entering the user in COA Details View. The data for the user is automatically populated in COA Details View.

Figure 7: User Details View

• COA Details View: In this view the data for approval are maintained like approval amount up to which approver can approve, currency for which approver is allowed to process approval, company code and cost center for which approver is authorized etc. Thus it basically controls the approver limit and scope of approval.

Figure 8: COA Details View

• Coder Details View: This is where coders are maintained for the requester. Thus due to this configuration the system knows from where to pick the coder for a particular requester. If the ‘Default’ check box is ticked then it means that user is always a coder.

Figure 9: Coder Details View

The user details contains all the users and the managers to whom invoice will go for approval. The approval limit is set in COA details and corresponding coder can be determined from coder details. Thus process type helps to know is approval is required or not and COA helps to know who will be approving.

Business Problem

According to the new amendment to the Czech tax act on Value Added Tax (VAT), VAT-payers who have seriously violated the administration of value added tax will be deemed unreliable VAT-payers and Customers who receive supplies from unreliable VAT-payers will become guarantors of any outstanding VAT on supplies.

• VAT-payers who have seriously violated the administration of value added tax will be deemed unreliable VAT-payers
• Customers who receive supplies from unreliable VAT-payers will become guarantors of any outstanding VAT on supplies
• The only way  for customers to avoid this obligation is to pay VAT on supplies directly to Czech tax authorities, instead
  to unreliable VAT-payers.

Solution

The Czech government regularly updates the status of unreliable VAT payers on their website. The link to the website is http://cds.mfcr.cz/cps/rde/xbcr/cds/2013_Nespolehlivy-platce.pdf

Option 1.

The reliability of VAT tax payers can be checked regularly using their tax identification number on the website. This is manual activity and allows only 1 tax identification number at a time.

Option 2.

A webervice is available on the website to read the Reliability status of VAT tax payers in a batch of 100 Tax identification numbers. The technical parameters of the webservice can be found on http://epodpora.mfcr.cz/33-1218.html

An interface can be created between SAP and the goverment website using the web service. The data read can be uploaded in SAP database table.

The user can be presented with a report to display the list of Reliable VAT tax payers. Alternately, enhancements can be implemented to retrict payments to VAT tax payers with a 'Not Reliable' status.

The closing cockpit is a very powerful tool in SAP Financial System which provides a structured interface for executing transactions and programs that form part of complex processes such as periodic and annual closing processes. The tree structure supports processes within an organizational structure such as a company code, as well as scenarios impacting multiple organizational structures. The closing cockpit as a tool is very useful in scenarios:

1. The activities are repeated periodically

2. Multiple people are responsible for completion of tasks

3. The activities are performed in a chronological order

4. A collaborative view is required by all people or units involved with a clear overview for dependencies

Two of the basic structural elements of a closing cockpit configuration is:

1. Template - The template contains the list of steps to be executed, the sequence in which they need to be executed

2. Task List - The task list contains the information contained in the template along with the actual date of execution.

The major steps in the configuration for a closing cockpit have been listed in the diagram below:

The path for accessing the closing cockpit configuration is as under:

The transaction for this is CLOCOC

The first prerequisite for configuring the closing cockpit is to register the programs in the table SCMATRANSACT. This can be done using SM30 or the closing cockpit configuration itself as shown below:

The complete list of programs which are already registered is shown. You can add additional programs including custom programs by clicking on "New Entries" as below:

Just like the programs, all the transactions which need to be execute from closing cockpit must also be registered as shown below:

Similar to Programs, you can add the custom Z or Y Transactions as well to the closing cockpit in addition to the standard transaction codes. Once the above prerequisites have been completed, we are now ready to start the configuration steps  for the closing cockpit.

Creation of Organizational Hierarchies

The configuration starts with the creation of organizational hierarchy. The creation of organizational hierarchy allows to distribute the closing process in terms of organizational structures. If org elements like profit center are used in SAP system, it essentially means that segregation can be done at this level as well.

Follow the path shown in the screen shot above to start creating the Organizational Hierarchy. If the standard delivered organizational elements are not sufficient for the Business Requirement, you can add more organizational elements for Closing Cockpit as shown below:

Add the field value which needs to be added for creating the organizational hierarchy. When the field has been added, now you can specify the name of your organizational hierarchy as below:

Creation of Template

A template is used to create the individual steps in a process chain. The template is therefore a collection of tasks which need to be executed in a particular sequence keeping in orientation the overall process and organizational units involved.The steps to configure organizational template is as under:

Be mindful of the fact that the Create Template is available only in the change mode for T Code CLOCOC.

A pop up box will appear in which you can define the name of the template and also link the same to the Closing Hierarchy. You can also link it to a Factory Calender and define other time dependent attributes for the template.

When you press enter, the template is saved. Now you create all the subfolders in the order in which the activities need to be executed.This represents a systematic view of completing the closing activities.

You can right clock to modify a folder properties or to create a new sub folder

Once the folders have been created, now we need to add the task to in the form of individual activities that need to be performed as part of the overall process in the task list. This can be an execution of a transaction code or a program. For creating a task in sub folder, right click on the same and click on add task as shown below

The tasks can be created in the following types:

-      Program with Variant

-      Program without variant

-      Transaction

-      Notes

-      Flow Definition

You can specify the planned run time of the activity. If the same has a deadline for completion, the same can be marked as "Critical Path" and it will display accordingly in the cockpit. You can also specify the usage of the task highlighting the usage of the same, whether the same is used in month end or period end or year end closing.

In the closing cockpit, you can also portray dependencies for a preceding step as well for a task. This allows that the preceding task is completed first successfully before execution of the current task in hand. This is an important step to plan a smooth closing.

Click on any task and on the Dependencies tab, right click to add a dependent task

The task will than show up as a preceding task as shown below

The next step in the configuration is the generation of the task list. Follow the steps as shown below

Here the name of the task list and template is same. This means that we are generating the same out of task list template. The key date is entered along with the type of closing and fiscal year details. By default task list is not in released status.While saving, if the task is ok, save it as released. This will allow the task to be scheduled.

Once all the tasks are in released, these can now be scheduled as part of month end processes.

There are standard templates for closing cockpit delivered which can also be used.

Depending on the requirements, you can create your own task list or use the standard ones.