Dear All,

As per circular 01/2014 I did some configuration changes Please check if this is helpful

Purpose:Based on the above circular, certain modifications have been effected to meet the conditions. The document also projects the accounting treatment in SAP for payment made under section 194 where Service tax is explicitly mentioned or not mentioned in the invoice. Requirement is that when one needs to implement this through Net amount, All the Tax including Vat, CST etc. also exclude from Withholding Tax Base amount. it is ok for 194J but when it comes to 194C, we need to go to below approach.

1.     Define Withholding Tax Type for Invoice Posting--change withholding tax base amount to "Modif. net amount" for required TDS code.

If you set this indicator, the modified net amount is used as the base amount for calculating the withholding tax.

Modified means that the additional amount is added to the net amount. This additional amount consists of the tax amount and is determined by one or more transaction keys that you define in your Customizing settings for the withholding tax base amount.

so you need to add those tax keys which you are assigned in input tax code in FTXP

you can get those from table T030K.

from all tax keys please remove service tax related tax keys and map balance as below for required TDS tax code (If you are using same tax key for service tax & other taxes; you need to create Z tax key for service tax than map that to condition type, "In my case it was NVV & condition type JSV2")

2. Withholding Tax Base Amount--Define Processing Key for Modified Net Amount-- maintain withholding tax type & Internal processing key for which you need to deduct withholding tax

now you are calculating TDS on (net amount  + tax keys mapped with TDS code) in above transaction.

This document will help  you how system calculate remain use full life of asset.

Use full life can define at Asset class Transaction code OAYZ

OR at Asset Master

Remaining use ful life flag select at Multi level method , Transaction code AFAMS.

Multilevel method assigned to Depreciation Key in Transaction code AFAMA.

Example: Test case of Before un check of Remain useful life.

Asset Acquisition history:

When Depreciation executed T.Code AFAB

We selected the flag remaining use full life and changed base value from 3 to 24

executed the depreciation

Hope the above scenario help you.

This document will help when you are facing translation in standard report S_ALR_87013611.

log in EN language and report executed but system shows the report in other language instead of English. In this case use Transcation code OKD3.

Bleow example:

We log in French , but system shows in Russia language.

Follow this steps:to translate to logon language.

Execute the report , now report will display in French language

Report executed in French language.

1       Introduction

This document discusses how a dunning run can be reversed. Reversal of dunning run means changes are required both at the customer master level and at the document level since dunning updates the customer master data and the open items for the customers that have become overdue

At the customer master level the last dunning run date and dunning level is required to be changed to the immediate prior run for that customer.

At the document line item level the fields dunning date and dunning level are required to be restored to those corresponding to the immediate prior run.

2       Background

In a typical business scenario it might be possible that a dunning run was executed by mistake though it was not supposed to be executed.

The issue of dunning letters cannot be undone. However changes can be made in the customer master data and transaction data. This change in master and transaction data is described below in the document.

3     Procedure and Aspects involved

SAP provides a standard program to undo the dunning run which has already been run. The program is RFCORR14. This program can be executed in the test run and once the results of the test run are fine, the same can be executed in the real run.  Running the program in the real run requires that code changes are made to the program to hard code name of the user who can run the program. This is done to ensure that only users who have access can run the program. Unauthorized users are prevented from running the program.

An instance of reversal of dunning run:

Selecting a particular customer 172200269 for dunning

Customer Master Data before the execution of dunning run:

Documents that are overdue for that customer:

Carrying out a dunning run for the selected customer:

Subsequent to the dunning run the customer master data changes as below:

The line items in the customer master data also get updated as under with the new dunning date and the new dunning level.

Customer line item display:

At the document level, the last dunned date and last dunning level gets updated as shown under:

Now we reverse the dunning run which was executed above:

Using the program RFCORR14 to reverse the dunning run

Carrying out a test run giving the run date and identification:

In the test run we can see that changes are made both at the document level and at the customer master level:

If the results of the test run are successful, we carry out the real run by checking the field “Update run with update to BSEG”:

In case the name of the user is not hard coded in the program we get the following error:

Once updated the error does not appear.

The customer master data and the document data changes as shown below:

In the customer master, the dunning date changes to the previous date. The dunning date changes from 12.09.2012 to 31.05.2012 as shown below:

At the document level also, the last dunned date changes to previous dunned date immediately prior to execution of the dunning run. The dunning run will appear as blank and the dunning level becomes 0 in case the dunning run which was reversed was the first run for that particular line item:

Thus we see that the program RFCORR14 can be used for reversal of dunning run that was incorrectly dunned.

In order to prevent unauthorized use SAP has placed a check that the user who is authorized to run the program be hard-coded in the program. This prevents unauthorized users from reversing the dunning run.

This document explains the steps how execute the dunning reversal.After executing the dunning reversal what are changes updated at customer master data , line item can view.

SAP provides a standard program to undo the dunning run which has already been run. The program is RFCORR14. This program can be executed in the test run and once the results of the test run are fine, the same can be executed in the real run. 

Example given below step by step

First view the dunning history

Dunning history in F150, BISD, MHND

F150

BSID or BSEG

MHND

Before executing reversal last dunned at line item 12.02.2014 level 2

Executing standard program RFC0RR14

Give the inputs Run date and identification, executed in test mode

Now executing in real mode, by selecting check box update run with updated to BSEG

Dunning reversal executed successfully

Now view at line item dunned data changed and first dunned date updated 20.01.2014 level 1

At master data also changed, here dunning level not changed.

In the same way reversing first dunning level

Compare the dunning last dunning reversal and first dunning screen

Last dunning reversal screen given below

At line item dunned date will be blank

Still at customer master dunning level will not change

At customer master data you can view the dunned change history

Note: Dunning reversal always should done last dunning

Example: You have done 3 dunning level for that customer in this you cannot directly done reversal for dunning level 2.

Hello All,

This is to give you a heads up for option “Input Template” in SAP for fast entries in Finance.

Configuration Steps for creating Screen template Variants

The below steps will explain you how to create a Screen template variants.

1. Use T-code O7E6 and execute
2. Variant >> New Variant >> Create

3. Enter the name for your variant and text for your variant

4. Choose the fields for your screen variant template

5. Activate your screen variant.

6. Finally Save your screen template variant

Below are the steps for enabling the “Input Template” – Here I use TCode F-32

1. Enter T-Code F-32 and execute in the command
2. Goto >> G/L Item fast entry

3. Settings >> input template

4. Select the Screen template variant you just created.

Enjoy reading!

Hoping for your feedback.

Overview

Payment via payment medium workbench is very common these days in SAP. Along with payment medium files other documents get generated such as payment summary, error list.

Payment summary list could consist different columns as per business requirement which can be changed by changing the layout. This document explains how the layout can be changed and same layout can be used again even payment summary is generated as spool.

Steps:

To change the layout of payments summary we need to create the layout. Layout can be created with below steps (these steps need to be performed as one time)

Use Transaction code: FBPM

Provide the run ID, date, payment Medium format etc. Select the ‘screen output’ check box then execute.

Click on layout button as shown in above screen shot.

Based on requirement field could be moved.

For example IBAN field is added in the end in above screen.

Now click on save layout button.

Provide the layout name starting with ‘/’. Remove the user specific check box otherwise it can be used by specific user only. Then click on save.

Created layout can be added to payment medium variant so that layout can be used again.

Transaction code: OBPM4

Provide the variant name “Test” is provided in the above screen and press enter.

Select the options as per business and provide the payment summary layout and save.

Payment medium variant setting helps to use layout again and again without manual intervention even spool can be generated for the same layout while running APP with payment medium payment method.

A very warm Hello to all!

This document is part of the POD series that I started. The earlier two docs are referenced below for quick reference

POD - Series 1

POD - Series 2

This document will focus on the Inter-Company stock transfer process. This is basically a variation/extension of the Intra-Company stock transfer process discussed in POD- Series 1

The process of inter-company stock transfer can be divided into two parts

1. Refurbishment

2. Drop Shipment

Refurbishment:- This process is also known as Stock replenishment process. This is basically when Company A manufactures the Product and stock transfers it to Company B upon request.

As said earlier, from Logistics perspective, this is same as Stock Transfer Process. However, because the product is crossing the company code boundaries, this amounts to Sale/Purchase in the eyes of law. 

A Product ,say, P1 is manufactured in Plant A (Company 1000). For some reason (eg: further processing) it is transferred to Plant B (Company 2000).

Briefly, the process steps would be as below 

a. Plant B raises a STO (Stock Transfer Order) on Plant A

b. Plant A might have the stock ready with it or it may need to manufacture the same

c. Once stock is available in Plant A, the same will be despatched (PGI) to Plant B (Movement type 601)

Accounting entry at this stage will be:

     Dr. COGS (cost of goods sold)

     Cr.  Stock account                       

After PGI, the stock is removed from the books of Plant A and the same is shown as "Stock-in-Transit" (SIT) in the books of Plant B

d. Billing will follow after PGI in Company 1000

       Dr     Inter Co Customer (Company 2000)

       Cr     Sales revenue

e. Plant B receives the stock and does GR (MIGO - Movement type 101). At this moment, the stock shifts from SIT to Unrestricted / QI stock depending upon the system set-up

Accounting entry at this stage will be:

     Dr.  Stock account                       

     Cr.  GR/IR account

f. Invoice verification (MIRO) in Company 2000

Accounting entry at this stage will be

      Dr. GR/IR account

      Cr. Inter Co. Vendor (Company 1000)

Note that there are various options possible to automate this step.

    a. One can set-up the Idoc process whereby at Step (d), system generates an Idoc and posts a corresponding entry in the receiving company

   b. One can set up the ERS (Evaluated Receipt Settlement) process to automatically process Invoice verification using a scheduled background job. Since group company is involved in the process, it would be a trusted source of supply and hence using ERS should not be an issue (ERS process automatically does MIRO for the posted goods receipts)

Dropshipment:- This is when a customer approaches company 2000 to purchase a product. Company 2000 may not be manufacturing the product or the customer is close to the location of company 1000. Hence, company 2000 requests company 1000 to deliver the goods to the customer, on behalf of company 2000

The process goes like this:-

However, accountancy angle says there are two set of transactions involved in the above process

    1. Company 1000  selling to Company 2000

    2. Company 2000 selling to the Customer.

The process steps and scheme of entries in this case would be as below

a. Customer approaches Company 2000. Company 2000 creates a Sales Order in its system

b. Company 2000 raises a STO on Company 1000. For Company 1000, Sold-to-Party and Bill-To-Party will be Company 2000, however, Ship-To-Party will be the end Customer

c. Company 1000 ships the Product to the end Customer.

Accounting entry at this stage will be:

     Dr. COGS (cost of goods sold)

     Cr.  Stock account 

d. Company 1000 raises invoice on Company 2000

Accounting entry at this stage will be:

       Dr     Inter Co Customer (Company 2000)

       Cr     Sales revenue

The COGS account posted above is maintained in T code OBCB (not in OBYC)

f. Company 2000 raises invoice on the end customer

Accounting entry at this stage will be:

        Dr. Customer

        Cr. Sales revenue

g. The payment process will follow the course (between End Customer <-> Company 2000 and between the group companies)

                                                                           =====End of the Process========

Experts corner:- 

Below points are meant to provide expert knowledge about this process. These are separated from the above process steps so as to target the relevant audience.

a. Material master set up in Plant A:- (Only the settings relevant to FICO)

  - Procurement Type = E (In-House manufacturing)

  - Price control = S (Standard price)

b. Material master set up in Plant B:-

- Procurement Type = F

- Special Procurement Type = Z1 (to be configured in OMD9)

- Price control = V

Note that it is still possible to transfer the cost component split from the sending plant, provided both the companies use same cost component structure.

c. Valuation price of the material

Usually, the price at which the Product will be sold by the Company 1000 + any planned delivery costs + any non-deductible taxes would form the valuation price of the receiving company

d. A separate distribution channel can be earmarked in SD in order to distinguish the inter-company sales so as to report them separately in COPA

Thank you for reading the document. I would appreciate your feedback on the document, which will help me to improve it further.

Next document would focus on few other processes

This documents explains the customization and how system calculate interest when we select the check box Open and all cleared items and open items and items cleared with a payment.

Intoduction:

Every company has their own pre-defined policies/terms and conditions towards the collection of the debts from the customers. These policies/terms and conditions depend upon the legal environment that exist in the countries where the company carries on its operations. One of the prominent policy/terms and condition would be to have an interest clause in the sales invoice to levy interest on the receivables.

The purpose of this document is to communicate to the readers the process of charging such interest on the receivables to the customers and posting an accounting document on the customer accounts.

The process followed for calculating the interest calculation on customer accounts would be to execute the interest calculation run for a defined period for defined accounts. The system would calculate the interest based on the customization maintained related to interest indicators. The calculation run can be executed further to post an interest document in the customer accounts. For correspondence with the customers, the same run can generate an output document (like invoice) which contain the amount of interest charged and the receivables towards which such interest is charged.

Interest can be calculated on customer and vendor accounts in two ways:

Account balance interest calculation: This calculation type calculates interest on the balance of the customer on the interest calculation day. If the customer has a debit balance (receivable) then the debit interest rate will be taken into consideration and if the customer has a credit balance then the credit interest rate will be considered for calculation.Account balance

Item interest calculation: This calculation type calculates interest on the line items for a customer. A customer may have open line item as well as cleared line items. Interest can be calculated for both open and cleared line items or only on the open line item.

Customization Transaction Code and Path given below

1. Interest calculation customization done at client level
2. Assigning interest calculation to customer master data at company code level

The below Setting done in transaction code OB82

Selected interest term with Open and all cleared items.

Once all the customization comleted assig at customer master data .

Same interest indicator we use at dunning customization :

At dunning this indicator only becomes effective if there is no interest calculation indicator entered in the master record. Otherwise the indicator in the master record has priority. If there is no indicator at either level (dunning procedure or master record), i.e. 'BLANK' is entered, then no dunning interest is calculated by the system

Invoice Entry posted

Interest run executed on 31.07.2013 in test mode

UN check Test run and post the document

Check the customer balance and customer master data

Last key date updated

Case Two:Credit memo posted

Now customer having negative balance

Interest executed in test run  mode on 31.08.2013

Even though the customer having negative balance , interest will be calculated on open line items as per customization.

Case 3:

Changed the customization from Open and all cleared items to open items and items cleared with a payment.

With this option you will come to know what happen when partial payment received and how system calculate interest.

Now posted incoming payment with 215.59 and clearing the invoice document EUR 115 and interest document EUR .59

Current balance:  credit memo value 200 EUR+ 100 Excess payment received = 300 EUR

Interest executed in test mode on 31.08.2013

In the above case system correctly calculating interest on 115 EUR from 01.08.2013 to 15.08.213.

System calculates the interest even the customer having total of negative balance.

Case 4:

1. Posted invoice with EUR 400 on 29.08.2013
2. Clearing posted with EUR 400 with total credit amount EUR 300 29.08.2013

Customer balance

Now  Clearing of invoice 400 with excess amount received of 300

After clearing the Current balance of that customer is 100 EUR

Executed interest and document posted 31.08.2013

Case 5:

Changing customization once again to Open item and all cleared items. and removing the check box option only calculate interest on debit item.

See now how system display interest.

Credit memo Invoice posted 01.09.2013

Interest executed on 30.09.2013

in the above case you can view interest calculated on credit line item 3% and debit line items with 8 % as per customization.

Hope with you learn how system calculate interest on credit and debit line items of the customer .

Lots of time when we clearing we want to use field in F-03 other transaction we need common field to clear the item but that field is not available F-03. Like now we want to do clearing on the Basis Trading Part.BA which not available in F-03

Now we will add Trading Partner Business Area field.

Go to Transaction - O7F1.

Now choose the position where you want to enter and select that field. Here I will enter After Assignment field so I am selecting Assignment field and clicking on Insert after

Now you can choose the field you want to display like Trading Partner business area by clicking on standard field.

Now double click on file you want enter

Now save.

PS: If you are doing this change in development client then system will prompt with transport request to move in different Environment.

Now go to F-03 and choose any GL account and then click on Other

Press ENTER and Pop of other selection will come

Now as you see New filed for Selection after assignment Field.

I hope this will help you and all suggestions are welcome.

Many Thanks

Regards

Preeti Agarwal

1. Introduction

Sensitive Data Fields provides dual control function in SAP to provide more security when changes are made in Customer and Vendor Master Data records. After activating Sensitive Data Fields functionality, changes done by one profile (Ex. Clerk) in AP and AR Master Data has to be confirmed by another profile (authorized person), thereby facilitating strong control over unauthorized modification. Changes made in relevant Customer or Vendor Master Data are visible but the account is automatically blocked for payment run till the changes are confirmed.

If this function is not activated then when the master data for a customer/vendor is changed then all business processes, including for example a payment run, can be executed immediately afterwards without the changes having being confirmed regarding the 4-eyes-principles. The risk of fraudulent behavior, especially in payments to vendor and customer, remains higher than a situation where the changes of sensitive data fields need to be confirmed by another person.

2. Steps

Standard SAP offers the possibility to define sensitive fields for both customer and vendor data. This customization is at Client level and is applicable for all Customer or Vendor account groups.

Customer Master Data

      1.    IMG Path for customization of Sensitive Fields for Customers:

IMG -> Financial Accounting -> Accounts Receivable and Account Payable -> Customer Accounts -> Master Data -> Preparations for Creating Customer Master Data -> Define Sensitive Fields for Dual Control. Single data fields can be defined as sensitive.

  Similar customizing exists for vendor accounts.

     2.    Maintaining Sensitive Fields:

       Below screenshot shows various fields available for customization as Sensitive data fields.

       This includes Customer name and address, Bank details etc.

     3.    Terms of payment saved as Sensitive Field:

     4.    Changing Payment Terms in Customer Master Data:

        Existing payment term is FB00

        Terms of payment have been changed from FB00 to FB09

         Changes saved with an information message to confirm the changes

     5.    Display Customer Master Data:

         Changes available for display but the same are required to be confirmed.

    6.    Confirmation of Change:

       Changes made can be displayed by clicking Changes to sensitive fields

       Below screen provides details of changes made

       Changes have not been confirmed

     7. Executing Automatic Payment Run:

       Customer has open item (T Code: FBL5N)

        Executing Payment Run without confirming the changes (T Code: F110)

       Account was not considered for payment run due to unconfirmed changes.

Vendor Master Data

    1. IMG Path for customization of Sensitive Fields for Vendors:

     IMG-> Financial Accounting-> Accounts Receivable and Account Payable-> Vendor Accounts-> Master Data-> Preparations for               creating Vendor Master Data-> Define Sensitive Fields for Dual Control. Single data fields can be defined as sensitive.

     2.    Maintaining Sensitive Fields:

      Below screenshot shows various fields available for customization as Sensitive data fields.

      This includes Vendor name and address, Payment terms, Dunning data etc.

      3.    City and Accounting Clerk Field have been saved as Sensitive Field:

     4.    Changing Sensitive Fields in Vendor Master Data:

        City changed from Montvale to Rutherford

        Accounting clerk field was empty

        Now filled with AP

       Changes available for display but the same are required to be confirmed.

    5.    Display Vendor Master Data

          Changes made are available for display

   6.    Confirmation of Change

       Changes done in city comes under Vendor Master General Data

       Changes done in Accounting clerk comes under the preview of Company Code Data

7.  Executing Automatic Payment Run:

       Vendor Open item ready for payment run (T Code: FBL1N)

        Executing Automatic Payment Program (T Code F110)

      Vendor is blocked for payment due to unconfirmed changes.

3.    Customized solution

As already mentioned, Sensitive Data Field functionality provided by standard SAP is at client level and therefore applicable for all the customer and Vendor account groups existing in the system. Based on customer request, this functionality can be activated for specific account groups.

In our project, Customer and Vendor Account groups have been created at country level. To fulfill customer requirement, A custom table has been created to maintain the relevant account groups and Sensitive Data Fields.

Also we have added one enhancement spot in include MF02DFEX for customer MF02KFEX for vendor. Accordingly Sensitive Data Field functionality has been activated at account group level.

In this way, unauthorized changes in Customer and Vendor master data can be effectively controlled thereby reducing overall business risk.

Hello ERP Financials, SAP ERP Financials  - Asset Accounting and SAP ERP Financials - Controlling Community

I would like to present a short knowledge article in the backdrop of legal requirements / one of the SAP limitations. This requirement might be there in many other countries, however, I have faced this during Indian implementations / rollouts

During Audit, the companies are required to provide a detail of the fixed assets acquired during the current fiscal year in a designated format. The details requested are quite logical like

  - Fixed asset no

  - Description

  - Type of asset (represented by asset class in SAP)

  - Date of acquisition

  - Date of capitalization

  - Purchased from (Vendor)

  - etc

Almost all this information is captured either in the asset master or in the transaction. One can juggle around SAP tables and download the information into excel. However, that involves manual work.

One limitation that crops up here is that asset master shows the Vendor from whom the asset is acquired. However, it shows only the 1st Vendor from whom the asset is acquired. If there are subsequent additions from different vendor OR the asset is acquired at the same time from two different vendors, this poses a challenge. Hence, to overcome this limitation and to automate the process of data extraction, I would like to present an approach (with sample code), attached along with this document

One can extend the code as needed. Hope this document helps and people dont have to reinvent the whole wheel again!!

Br, Ajay Maheshwari

Applies to:

FICO DART Extract being developed in SAP ECC 6.0.

Summary:

This document will help in creating a DART Extract for the France country Article A47 A-1

  - To provide an overview of the France Article A47 A-1

  - Explain the Field requested by France administrative

  - To list the configuration steps needed to activate France DART View

Introduction

France Article A47 A-1

Computerized accounting systems and transfer of electronic data to the tax administration for the purpose of tax inspections

An administrative order dated 29 July 2013 has modified the provisions of article A47 A-1 of the French tax procedure handbook with regard
to requirements for copies of computer files. It requires companies to communicate, if so requested by the French administration in the context of tax
inspections announced on or after 1st January 2014, all their accounting records in the form of aunique dematerialized “accounting records file” in a predefined format.

The file must include the detailed final accounting entries booked throughout the financial year, as well as the applicable opening balances. All the accounting data available in the company’s computerized accounting system must be included in the file, whose first eighteen fields for each accounting entry must obligatorily reflect, in the same order, those listed in a table defined by the tax authority.

Objective

This document explains step by step in setting up Data view creation as per the French administrative requirement.

Business Requirement

As per new French fiscal procedure article A47 A-1 , French company should be able to deliver an extraction of general ledger for complete
fiscal year with a certain list of fields and in a particular format.

Solution 

To meet the legal requirements of France where DART is used to report to tax authorities. The pre-requisite DART release in the system should be DART 2.6 or DART 2.6e or DART 2.7.

Following SAP note implementation has to be done as prerequisites for the View configuration:

-1935509 - Carry forward postings for new GL in France

-1923322 - DART: View file creation for France Legal Requirement

-1906078 - FTW1A: BADI for additional selections from BKPF

They are all contained in the note 1933144. These notes also refer to the French law and to the general flow up to the production of the DART.

SAP Mapping Fields:

Data view: 2FR_FI01 creation in transaction FTWY:

Maintenance of DART attributes:

Maintenance of Data Segment as per the business requirement:

Maintain Join condition:

Creation a set to restrict the extract selection based on business requirement if any:

Set Creation to restrict the extract selection based on business requirement if any:

Data View Field mapping:

Save the Dart View and Activate view
After Activation of the Dart View a program will be generated 

Note:

1. In addition to the 18 fields I have included Year in the report to restrict the values of the specific fiscal Year

2. If you want to add any field which is not in SAP note 0001923322 take the proactive step on following things:

1. To update additional field entries in the tableTXW_LANGU_TEXT, create customized view for the table TXW_LANGU_TEXT as the program
   ZTXW_LANGU_TEXT only update 18 field text.
2. Include additional field in the View Fields (FTWY)

3. In the View Fields of DART mark Entry Date (CPUDT) as a group so that sort will be done based on Entry date

4. Further restriction on the extract can be controlled by Selection condition in the DART data Segment

This series of documents for FI-SD integration is divided into 4 parts. This document is the last part of the series. Adding links for other parts before I start with the content.

Even though the document title says FI-SD Integration - III, it is the fourth part because part I was the pre-requisites required for the integration.

Part-I : Pre-requisites for FI-SD Integration

Part-II : FI-SD Integration - I

Part-III : FI-SD Integration - II

Assign G/L Accounts

The last step is assigning G/L accounts. This is done in t-code VKOA or the menu path SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination -> Assign G/L Accounts

Only those tables will be displayed in VKOA which are linked to access sequences for which the account determination types are already assigned to account determination procedures. To make assignment of G/L accounts, double click on the required condition table entry. For illustration purposes, the condition table 1 has been chosen.

New rows can be added to the table using the New entries button. As seen from the screen shot above, G/L accounts assignment in this table is based on

• Application
• Condition type
• Chart of accounts
• Sales Organization
• Customer account assignment group
• Material account assignment group
• Account Key

The provision account column is used in case the account key is an accrual key as explained in section 3.3. The G/L account column for such an account key has the P&L account and the provision account column is filled with the Balance Sheet account number

For instance, for application = v, condition type = KOFI, chart of accounts = A999, sales org = MMMM, customer group = D1, material group = J1, if the account key is ERL, the posting is done to G/L account 51010201 and for account key ERS, the posting is done to G/L account 51010101. Thus, we differentiate the G/L account based on the transaction type through the account key. Similarly, for application = v, condition type = KOFI, chart of accounts = A999, sales org = MMMM, customer group = D1, account key = ERL, if the material group is J1, the posting is done to G/L account 51010201 and for material group J2, the posting is done to G/L account 51010101. Thus, we differentiate the G/L account based on the material group of the material.

Similarly, the G/L accounts are assigned to all the condition tables. For instance, if we would have chosen table 2 instead on 1 for assignment of G/L accounts, the screen would have been as shown below.

As seen, the difference between tables 1 and 2 is that in condition table 2, there is no material account assignment group criterion for determination of G/L account. So, for instance, if an access sequence lists the table 1 as the first one to be checked and table 2 as the second one, and the material group is missing from the billing document, then the G/L account to be posted to would be traced from table 2.

From the condition table displayed for G/L account assignment, rows that satisfy particular criteria can be identified. Use Menu tab Selection -> By Contents

The fields that can be used for selection are displayed. Here, for instance, we choose account key and G/L account by clicking on these fields and press enter.

We want to display rows with Account key = ERS and G/L Account = 51010101. Enter the field values and select the choose button. The list is displayed as shown below. The number of entries selected will also be shown at the bottom of the page as highlighted.

This selection can also be used for easy assignment of G/L accounts. For example, for table 2, choose chart of accounts = CABE, sales org = XCSH and account key = ERL in the selection. When the list of entries is displayed, the same account number can be easily entered in the G/L account column.

Displaying Account Determination Analysis

The screen shot below shows an accounting document in FI. The t-code used is FB03 or follow the menu path SAP Easy Access Manu -> Accounting -> Financial Accounting -> General Ledger -> Document -> Display

As highlighted in the screen, the G/L account 800000 has been chosen for posting of the sales. The corresponding billing document can be seen using menu tab Environment -> Document Environment -> Original Document.

To see the account determination analysis, from the billing document screen, use the menu tab Environment -> Account Determination Analysis -> Revenue Accounts

As seen from the screen above, the G/L account entry was not found in condition table condition type/account key. The account 800000 was determined from the table Acct Key.

This series of documents for FI-SD integration is divided into 4 parts. This document is the first part of the series. Adding links for other parts before I start with the content.

Part-II : FI-SD Integration - I

Part-III : FI-SD Integration - II

Part-IV: FI-SD Integration III

FI-SD Configuration Pre-requisites

The pre-requisites for carrying out this configuration are as follows:

• Material Master
• Customer Master
• Pricing Procedures
• Condition Records
• G/L Accounts

Material Master

The material master can be displayed using t-code MM03. The menu path for MM03 is SAP Easy Access Menu -> Logistics -> Materials Management -> Material Master -> Material -> Display. In the material master, the  relevant view is Sales: Sales Org. Data 2 as shown below:

In the view, the relevant field is the Acct assignment group. This is one of the criteria for G/L account determination. The materials which have the same account assignment group are grouped together to post to the same G/L accounts.

Customer Master

The customer master can be displayed using t-code FD03. The menu path for FD03 is SAP Easy Access Menu -> Financial Accounting ->  Accounts Receivable -> Master Records -> Display. In the customer master, the relevant data is under the Sales area data section of the customer master. Select the Billing Documents tab.

The relevant field is the Acct assignment group. This is also one of the criteria for G\L account determination. The customers who have the same account assignment group are grouped together to post to the same G\L accounts.

Pricing Procedures

Pricing procedures are used to define the valid condition types for pricing calculation and the sequence in which they should be processed.  Other processing data can also be specified for each condition type such as, if the condition type is statistical, specification of a calculation type different from the one mentioned in the condition type configuration etc.

The pricing procedures can be seen in t-code V/08. The menu path for V/08 is SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Pricing -> Pricing Control -> Define and Assign Pricing Procedures -> Maintain Pricing Procedures

The relevant field here is the Account Key. It is also one of the criteria for G/L account determination. Based on the account key, the required G/L account to be posted is selected.

The column next to account key is the accrual key. The accrual accounts are used if accrual condition types such as a rebate condition type are used in the pricing procedure. Rebate is the discount given to customers by manufacturers, say, a rebate given to dealers at the year end based on the number of units sold. The rebate is not paid per invoice. It accrues over the period and is paid at the period end.

The account key is used to determine a rebate discount account which is a P&L account. The accrual key is linked to 2 G/L accounts, a P&L account and a B/S account (Provision account).

When a billing document is posted, the P&L account linked to accrual key is debited and the provision account is credited with the rebate amount. When the rebate agreement is settled, the account linked to account key is debited and customer is credited with the rebate discount amount. At the same time, reverse posting is done to the accounts linked to accrual key.

Condition Records

For each condition type in the pricing procedure, condition records are used to specify the factors, say, customer, material,  etc. that can vary and then store the price for various combinations of these factors.

They can be seen in t-code VK13. The menu path for VK13 is SAP Easy Access Menu ->Logistics -> Sales and Distribution -> Master Data -> Conditions -> Select Using Condition Type ->Display

The condition record for condition type PR00 is shown in the screen above. The Sales Organization and Distribution Channel as seen in the screen form the Org level at which the condition record is stored. The condition record does not directly affect the account determination. If for a condition type, the condition record is not maintained, the condition type will not have a value and hence no account determination is needed.

G/L Accounts

To complete the configuration for account determination, the G/L accounts should already exist in the system.

They can be seen in t-code FS00. The menu path for FS00 is SAP Easy Access Menu -> Accounting -> Financial Accounting -> General Ledger -> Mater Records -> G/L Accounts ->Individual Processing -> Centrally

This series of documents for FI-SD integration is divided into 4 parts. This document is the second part of the series. Adding links for other parts before I start with the content.

Even though the document title says FI-SD Integration - I, it is the second part because part I was the pre-requisites required for the integration.

Part-I : Pre-requisites for FI-SD Integration

Part-III : FI-SD Integration - II

Part-IV : FI-SD Integration III

Automatic Account Determination

The accounting entries with respect to the billing will generally result in

• Debit Customer account
• Debit Freight-out account
• Credit Revenue account
• Credit Excise Duty Payable account
• Credit Sales Tax Payable account

Hence, primarily, one side of the account is a Customer and the other is a revenue account. The customer account gets picked up from the customer master data and the revenue account is configured based on certain inputs so that correct account is hit during FI posting. This automatic account determination is configured not only for revenue, but also, other elements like Freight, surcharges, sales deductions etc.

The account determination can be done to be based on the following criteria:

• Application
• Condition Type
• Chart of Accounts of Company Code
• Sales Organization
• Customer Account Assignment Group
• Material Account Assignment Group
• Account Key

Note: The above mentioned fields are standard fields included by default. More fields can be added as criteria.

Configuration Steps

The configuration steps required for this activity can be found by following path SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination

As seen in the screen shot above, there are 6 configuration steps.

Check Master Data Relevant For Account Assignment

The first step is setting up the master data relevant for account assignment. The menu path is SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination -> Check Master Data Relevant For Account Assignment

There are two activities to be done in this step – material account assignment groups and customer account assignment groups.

The first activity is material account assignment groups maintenance. From the screen, double click on Materials: Account Assignment Groups. The screen for maintaining material groups will appear.

Use the New Entries button to create new groups. There are different material groups created as in the screen above which ensures that, for example, all the trading goods (Group 01) can be posted to different accounts than that of all the services (Group 20).

As already seen before, these material groups are assigned to materials in the view Sales: Sales Org. Data 2 of the material master. The system automatically proposes the account assignment group for the material in the Sales documents from the material master.

The second activity in this step is customer account assignment groups maintenance. From the screen, double click on Customers: Account Assignment Groups. The screen for maintaining customer groups will appear.

Use the New Entries button to create new groups. There are different customer groups created as in the screen above which ensures that, for example, all the domestic revenues (Group 01) can be posted to different accounts than that of all the foreign revenues (Group 02) or the affiliated companies’ revenue (Group 03).

As already seen before, these customer groups are assigned to customers in the tab Billing Documents of the Sales Area data in the customer master. The system automatically proposes the account assignment group for the customer in the Sales or Billing documents from the customer master.

Define Dependencies of Revenue Account Determination

The next step is defining the dependencies for revenue account determination – defining fields as well as condition tables. The menu path is SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination -> Define Dependencies Of Revenue Account Determination

As already mentioned, the purpose of setting up account determination is to be able to differentiate accounts for posting according to certain criteria like customer account assignment group, account key,  material account assignment group etc. Hence, the first activity here in this step is to decide which all criteria will be used for such differentiation. The field catalog contains fields that can be selected when we create or maintain a condition Table. These decided criteria are to be added by double clicking on the Field Catalog: Allowed fields for the tables option.

As seen in the screen shot above, the some of the required criteria are already present. If new ones are to be added, click on new entries and press F4. A list of all the fields in the tables that can be added as criteria is listed as shown below.

As shown above, if we want to add Payment cards: Card type as a criteria, double click on the entry and then press save. As seen below, this criterion has been added to the already existing list of criteria.

Once the fields have been selected, these fields have to be added to condition tables. There can be many tables, each with different combination of criteria that will be used for account determination. The existing tables can be displayed using Account Determination: Display Tables option.

Enter the table number for which we need to see the table details and press enter.

As seen in the screen above, table 9 uses Sales Organization, Distribution Channel and Division as criteria for account determination. The left pane shows the fields selected as criteria for this table and the right pane shows the field catalog i.e. the fields available from which the criteria can be added to the table.

The system already contains standard tables like the one shown above. Most of the times, these standard condition tables are sufficient. However, we can also create custom condition tables for specific requirements. These custom tables can range from 501 to 999. Some of the standard tables are

• Table 001 - Customer group/ Material group/ Accounting key
• Table 002 - Customer group/ Accounting key
• Table 003 - Material group/ Accounting key
• Table 004 - General
• Table 005 - Accounting key

To create a new table, double click on Account Determination: Create Tables option. Here, a custom table 501 is being created with the Payment Card type field as criterion.

Enter table number 501 and press enter. If the table is to be copied from another existing condition table we can enter the existing table number in the field below the new table number.

Select the field payment card type and choose the Select field button.

As seen, now this field has been added to the table as criterion as it can be seen in the left pane. The description of the table can be changed using the highlighted button in the screen shot. Add all the required fields and press save. The new condition table has been created.

Note : The Field Catalog table is cross-client. Therefore, any changes done to this table will have effects in all clients on a server.

Define Access Sequences and Account Determination Types

The next step is defining account determination types and access sequences. The menu path is SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination -> Define Access Sequences And Account Determination Types

The first activity, Maintain access sequences for account determination is used to setup access sequences. Access sequences store information about which condition tables will be accessed for account determination, the sequence in which these tables will be accessed and the field contents of these condition tables. Double click on the option.

As seen, there are two standard access sequences defined in the system – KOFI and KOFR.  To create new access sequences use the new entries button. To view an already existing one, click on the entry and double click on the Accesses folder as highlighted on the left hand side.

The above screen shows the condition tables and the sequence in which they are accessed in the access sequence KOFI. The No. column gives the order in which the tables are accessed i.e. the one with the lowest number is accessed first. As shown in the above screen shot, system will access table 953 first during determination procedure as that is first in sequence. If system is able to find out necessary information in this table it will not access table 496 but otherwise it will access table 496 next. Usually, the sequencing of the tables is configured such that, the more specific tables are accessed first for the information and then the less specific ones follow. The Tab column contains the condition table number and the Description field contains the table description. To see the fields contained in the condition table, click on the respective row and double click on the Fields folder as highlighted on the left hand side. To add new tables to the access sequence use the new entries button, enter the values in the No. and Tab column and save.

The screen shot above shows the fields in table 496 – Condition Type/Account Key.

The screen shot above shows that the table 501 – Payment Card Type has been added to access sequence KOFI.

As seen, there is a column called Requirement. A requirement, simply put, is a routine or a small program, which one can specify as a precondition to decide that the access sequence is to be activated if that condition fulfilled. Say, for instance, an access is applicable only for export business, then, a requirement, say 8 is used. This requirement number checks if the order is of export business. If yes, then only the access is read. Otherwise it is not. So, it saves a lot of time for the system, improving the response time. The requirements for the various application areas such as pricing, material determination, account determination etc. are maintained using transaction code VOFM. Once the created, they can be assigned as required to access sequence's / pricing procedures, etc.

Note : The Access Sequences table is cross-client. Therefore, any changes done to access sequences will have effects in all clients on a server.

The second activity in this step is Define account determination types. The account determination type is used for defining the control data for access sequence and the validity date. Double click on this option from the menu.

As seen in the screen shot, in this step, condition types are defined and then access sequences assigned to them. It is to be noted that these condition types are different from the condition types used in pricing procedures as discussed in the pre-requisites section. These condition types are used in account determination procedure. There are two standard condition types in the system – KOFI (for account determination without CO) and KOFK (for account determination with CO).

Note : Custom condition types and access sequences can be defined, but, it is recommended that these start with Z.

This series of documents for FI-SD integration is divided into 4 parts. This document is the third part of the series. Adding links for other parts before I start with the content.

Even though the document title says FI-SD Integration - II, it is the third part because part I was the pre-requisites required for the integration.

Part-I : Pre-requisites for FI-SD Integration

Part-II : FI-SD Integration - I

Part-IV: FI-SD Integration III

Define And Assign Account Determination Procedures

The next step is defining account determination procedures and assigning them to billing document types. The account determination procedure contains the condition types relevant to the procedure through which the access sequences are read and also the order in which these condition types are accessed. The menu path is SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination -> Define And Assign Account Determination Procedures

The first activity in this step is defining the procedures. Double click on the option Define account determination procedure.

KOFI00 is a standard account determination procedure. New procedures can be created using the button New Entries. To view the procedure, place the cursor on the respective row and double click on the folder Control data as highlighted on the left hand side.

The above screen shot shows the control data of the account determination procedure KOFI00. New condition types can be added to this procedure using the New Entries button. The step, counter, condition type and requirement values should be entered and saved. The step column contains the sequence in which the condition types of the procedure will be accessed, the one with the lowest step value being accessed first. If two condition types contain the same step value, the counter column is checked for the sequence. The one with the lower counter value will be accessed first. The condition types are contained in the column CTyp. The requirement column has options that can be chosen for a condition type as shown below.

The 3 options shown here are standard ones. Customized routines can also be created and added here. For example, for KOFI, the requirement column contains value 2 implying that this condition type can be activated only when the requirement that there is no CO account assignment is satisfied.

The second activity in this step is assigning the procedures. Double click on the option Assign account determination procedure.

As seen in the screen shot above, all the billing document types defined in the system are presented. The required account determination procedure for each billing type is assigned in the column ActDPr in the respective row. For a particular billing type, the corresponding account determination procedure is used to determine the sequence of condition types and then the respective access sequences are read in the sequence of condition types.

The column CaAc is used to specify account key for cash transactions for each billing type. This causes the system to post to a G/L account rather than to a receivables account. G/L accounts can be entered for the key in account assignment.

Define And Assign Account Keys

The next step is defining account keys and assigning them to condition types in pricing procedures. The account keys are defined to group together similar accounts in financial accounting. The menu path is SPRO -> IMG -> Sales and Distribution -> Basic Functions -> Account Assignment/Costing -> Revenue Account Determination -> Define And Assign Account Keys

The first activity in this step is to define account keys. Account keys are defined as based on the requirement of G\L account in FI. Double click on the option Define Account Key.

New account keys can be created in the system using the New Entries button. As seen in the above screen shot, different account keys are defined for different types of accounting entries. For example, ERL is account key for revenue related entries while ERF is defined for Freight revenue related entries. Since account keys also play an important role in the account determination process, it helps us in hitting different accounts for various transactions for the same set of customer or material.

Some of the standard account keys are:

• ERB - Rebate Sales Deductions
• ERF - Freight revenues
• ERL - Sales Revenues
• ERS - Sales Deductions
• ERU - Rebate Accruals
• EVV - Cash Settlement
• MWS - Sales Tax

The second activity in this step is to assign account keys to condition types in pricing procedures. Double click on the option Assign Account Key.

This step is the same as the one discussed in pre-requisites for pricing procedures. The activity done there through t-code V/08 is the same as the one done in this step. However, in this screen, we can add only the required account key in the ActKy column against the corresponding Condition types in the CTyp column. The V/08 screen allows several other activities like adding new procedures, changes to condition types within a procedure, change of steps or counter etc. along with the assignment of the account keys.

As part of majority of SAP Implementations, the customer master is one of the key master data objects to be loaded from Legacy system into SAP system.

The customer master data is very important in clients business, and the fields of the same should not be compromised during migration.

One of the main attributes of the customer master data is the dunning data, which will appraise the business with the status (riskiness for the item to be realized) of the open items.

Dunning data for customer open items is captured at two places as mentioned below:

1. Customer master data is updated with highest level of dunning irrespective of the Dunning level of

    individual line items.

2. While migrating customer open items, the last dunning date and dunning level of each individual open

    item is also migrated as part of the open items migrated to the new system

With the above explanation and understanding, we will now see why we require migration of Dunning information only at line item level but do not require at the Customer master data level.

For Example Customer account number 172110290 in legacy system was last dunned on 28.02.2014 and Dunning level as 2

Note: Dunning Procedure should be migrated.

Open line items of the same customer were also migrated with Dunning information as shown below.

When Dunning run is carried out for the same Customer in new SAP system, Customer open line item (If considered by Dunning run) will be updated with the next Dunning level and the Customer master data will always get updated with highest Dunning level of all the open items.

Customer line items reach the next Dunning level.

Customer master data gets updated with highest Dunning level 3

This situation would have been same in case Last Dunned date and Dunning level were not migrated while migrating customer master data. So, in a nutshell, MADAT-KNB5 (Last Dunned date) and MAHNS-KNB5 (Dunning level) fields can be excluded from Customer Master data migration strategy and rest of the other important data fields can be focused for successful migration of customer master data.

A Validation / Sustitution is transported to the Traget System using T. codes GCT9 and GCT0 respectively. For the same, you select Validation / Substitution in the Dropdown list in these t. codes and include it in a Transport request.

However, once a Validation / Substitution is deleted from the System, the same do not appear in the Dropdown list and thus not available for inclusion in the Transport request,

This document aims at inclusion of an already deleted Validation / Substitution in a Transport request and then Transport it to a Target System.

Scenario:

You have created a Validation / Sustituion and moved it to Quality / Production System. However, later on it was realised that the same is either not required or created wrongly and thus Need to be delted in all Systems.

Validation Overview in Development System:

Validation Overview in Quality System:

As can be seen, the Validation Z10003 has been deleted in the Development System after it was Transported to the Quality System.

Inclusion of Deleted Validation in the Transport Request

T. Code: GCT9

Doing the F4 on the Validation Name field, the deleted Validation do not appear in the Dropdown list.

So, rather than doing a F4 on the field, enter the Deleted Validation manually in the Box.

Then, go to Object and select the Option " Delete in Target Sytsem" (as shown below)

A message will appear

Press "Enter". The System will prompt for a Transport request.

Enter the "Workbench Transport Request" and then Transport it to the Target sytsem as per the deifned process in your organization.

For Substitutions, the Process is exactly the same. You just Need to use T. Code GCT0 (instead of GCT9)

There is also a possibility to remove an already added Validation / Substitution from a Transport request using the same T. codes.

Scenario: You have included multiple Validations / Substitutions in a Transport request, however, later you do not want to Transport a particular Validation / Substitution and hence want to delete from the Transport request.

It will Prompt for the Workbench Request from which you want to delete the Validation / Substitution. Enter the desired Transport request.

Overview

Payment via payment medium workbench is very common these days in SAP. Along with payment medium files other documents get generated such as payment summary, error list.

Payment summary list could consist different columns as per business requirement which can be changed by changing the layout. This document explains how the layout can be changed and same layout can be used again even payment summary is generated as spool.

Steps:

To change the layout of payments summary we need to create the layout. Layout can be created with below steps (these steps need to be performed as one time)

Use Transaction code: FBPM

Provide the run ID, date, payment Medium format etc. Select the ‘screen output’ check box then execute.

Click on layout button as shown in above screen shot.

Based on requirement field could be moved.

For example IBAN field is added in the end in above screen.

Now click on save layout button.

Provide the layout name starting with ‘/’. Remove the user specific check box otherwise it can be used by specific user only. Then click on save.

Created layout can be added to payment medium variant so that layout can be used again.

Transaction code: OBPM4

Provide the variant name “Test” is provided in the above screen and press enter.

Select the options as per business and provide the payment summary layout and save.

Payment medium variant setting helps to use layout again and again without manual intervention even spool can be generated for the same layout while running APP with payment medium payment method.