121779377 Sap Sd Cin Configuration Steps

CIN - Country India Version - Excise Duty Configuration Steps:

Brief Introduction:

Country India Version (CIN) is designed for use by business with operations in India. It contains a localization implementation guide (IMG), and a country template to help us customize the system according to

local requirements. This is over and above the generic SAP system functionalities. Most of the country-specific functions for India relate to

Financials and Logistics, and center around taxes, including:

o Excise duty and the central value-added tax system (CENVAT)

o Tax deducted at source (TDS)

o Sales tax

Activate Country Version India for Specific Fiscal Years:

In this activity, we specify for which fiscal years we want to activate Country Version India for the accounting interface.

Menu Path: Financial Accounting (new) --> Financial Accounting

Global Settings (New)--> Tax on Sales/Purchases --> Basic settings --> India --> Activate Country Version India for Specific Fiscal Years

Transaction Code: SPRO

Basic Settings:

We maintain the data relating to excise registrations. Excise registration

is an entity in India that is entitled by law to produce any goods liable to excise. Each entity is assigned its own excise registration number. For example every factory that manufactures excisable goods is required to

register separately, so that a business with seven factories requires seven registrations. Each of the excise registrations needs to be specified by a four-character code.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Basic Settings--> Maintain Excise Registrations


Maintain company code settings:

Maintain the standard defaults for the company code.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Basic Settings--> Maintain company code settings


Maintain Plant Settings:

Maintain the excise information relating to the plants.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Basic Settings--> Maintain Plant Settings


Maintain Excise Groups :

Here we define the excise groups. An excise group is a unit within an

excise registration, in India, which keeps its own set of excise records. Whereas the excise registration reports to the excise authorities, the excise group is a purely internal organizational unit. Each excise group

keeps records of all transactions that have to be reported to the excise authorities. When the time comes to present these records to the authorities, the excise registration compiles the information from all of

its excise groups. For each excise group, we can also control how various excise invoice transactions will Work.

Menu Path: Logistics – General --> Tax on Goods Movement --> India -->

Basic Settings--> Maintain Excise Groups


Maintain Series Groups :

Series groups allow maintaining multiple number ranges for the outgoing excise documents. Based on excise regulations and exemptions from the

authorities we can maintain multiple number series for outgoing documents. But each of these series has to be declared to the excise authorities.


Basic Settings--> Maintain Series Groups


Maintain Excise Duty Indicators: Here we maintain the excise duty indicators. This determines the effective duty that would be used for

excise duty calculations. Generally, no change to the standard settings is required.


Basic Settings--> Maintain Excise Duty Indicators


Maintain Postal Addresses:

The addresses of various customs and excise organizations that the company deals with are maintained here. These addresses are used in the

ARE Documents functions. When an ARE-1 or ARE-3 document is created, the address of the excise department and the customs department involved in the export process are entered. The system then prints their

names and addresses on the AREs.

A default local excise department for each excise group and a default customs department for each series group can be defined.


Basic Settings --> Maintain Postal Addresses


Maintain Sub Transaction types :

By default, the system records excise duties on the accounts that have been specified in the IMG activity "Specify Excise Accounts per Excise Transaction". However, if we want to be able to record some excise duties

on other accounts we need to create a sub-transaction type in this IMG activity.


Basic Settings --> Maintain Sub Transaction types


Select Tax Calculation Procedure:

For country India we need to specify which tax procedure we would use to determine excise duties and sales taxes on input materials.

o For condition-based excise determination, use TAXINN or a copy of it

o For formula-based excise determination, use TAXINJ or a copy of it.

This tax procedure also supports condition-based excise determination, so that we can work with both concurrently.

It is recommend that for new implementations we use condition-based

excise determination. Note that once a tax procedure is already used and documents posted, it is difficult to switch to another one, as the old documents will not be displayed.


Basic Settings --> Determination of Excise Duty --> Select Tax Calculation Procedure


Maintain Excise Defaults:

Here we define which tax procedure and pricing condition types are used

in calculating excise taxes using formula-based excise determination (TAXINJ or a copy of it). If condition-based excise determination is used

(TAXINN or a copy of it), maintain the CVD condition field and leave all the others blank.

If formula-based excise determination is used (TAXINJ or a copy of it), maintain the following:

o Tax procedure and the pricing conditions that are relevant for

excise tax processing.

o The purchasing and sales conditions types used for basic excise duty, additional excise duty, special excise duty, and Cess.

o The conditions in the sales order that are used for excise rates.

o The countervailing duty condition type used for import purchase

orders.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Basic Settings--> Determination of Excise Duty --> Maintain Excise

Defaults


Define Tax codes for Purchasing Documents:

Maintain tax codes for the purposes of calculating excise duty when creating purchasing documents.


Basic Settings--> Determination of Excise Duty --> Condition Based Excise Determination --> Define Tax codes for Purchasing Documents

Transaction Code: FTXP

Assign Tax code to company code:

Assign the tax code for purchasing documents to the company codes

where it will be used. This is only required if you condition-based excise determination is used.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Basic Settings--> Determination of Excise Duty --> Condition Based Excise

Determination --> Assign Tax code to company code


Classify condition types:

Here we specify which condition types are used for which sort of tax. Note that this only applies to condition types that are used with the new excise

determination method (TAXINN). The system uses this information when a document is creating from another one. For example, when an incoming

excise invoice is created from a purchase order, or when an outgoing excise invoice is created from a sales order, the system determines the various excise duties in the excise invoice using the information that

have been entered here. In addition, when a purchasing document is created, the system only uses the condition types that are entered here.

o For taxes on purchases, use the condition types contained in the tax procedure

o For taxes on sales, use the condition types contained in the pricing procedures.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Basic Settings --> Determination of Excise Duty --> Condition Based

Excise Determination --> Classify condition types


Maintain Chapter Ids :

Maintain the chapter IDs and the corresponding descriptions as per the schedules published by the Central Board of Excise and Customs.


Master Data -->Maintain Chapter Ids


Assign Users to Material Master Screen sequence for Excise Duty:

Here we customize the material master data so that it shows the information relating to excise duty. Country Version India comes with a

screen sequence (IN) that shows the excise duty fields. We need to assign it to each of the relevant users under User Screen Reference.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Master Data --> Assign Users to Material Master Screen sequence for

Excise Duty


Define Form Types:

Define which form types needs to be recorded in the system. This is used for form tracking for the form types that are maintained.


Master Data --> Define Form Types


Define GL accounts for taxes:

Here we specify which G/L accounts to use to record account postings for taxes. We have to set up G/L accounts for each of the processing keys

listed below. The accounts for VS1, VS2, and VS3 are used as clearing accounts during excise invoice verification.

VS1 (basic excise duty)

VS2 (additional excise duty)

VS3 (special excise duty)

VS5 (sales tax setoff)

MWS (central sales tax)

MW3 (local sales tax)

ESA (service tax)

ESE (service tax expense)

Account Determination:


Account Determination --> Define GL accounts for taxes

Transaction Code: OB40

Specify Excise Accounts per Excise transaction:

Here we specify which excise accounts (for excise duty and CENVAT) are to be posted to for the various transaction types. Maintain all the

accounts that are affected by each transaction type. If sub-transaction types are used then, maintain the accounts for each sub-transaction type

as well.

Transaction type UTLZ is used for determining accounts only while posting excise JVs and also if the payment of excise duty has to be done fortnightly. The fortnightly CENVAT payment utility picks up the credit

side accounts from the transaction types of GRPO, EWPO, and TR6C for determining the CENVAT and PLA accounts. There is no separate transaction type for fortnightly payment.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Account Determination --> Specify Excise Accounts per Excise transaction


Specify GL Accounts per Excise transaction:

We assign the excise and CENVAT accounts to G/L accounts in this step. While executing the various transactions, the system determines which

G/L accounts to post to by looking at the:

Excise group

Company code

Chart of accounts

If separate account determination settings within an excise group are required, we use sub transaction types.


Account Determination --> Specify GL Accounts per Excise transaction


Business Transactions --> Incoming Excise Invoices

Select Fields:

Specify which fields are required in the Incoming Excise Invoices transaction. The settings that are made here apply for all versions of the

transaction. For each field, we need to specify whether it is to be an input field, a display field, and so on. It is also possible to highlight fields of

particular importance.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Incoming Excise Invoices --> Select Fields

Transaction Code: J1IEX_SFAC

Define processing modes per transaction:

Specify which processing modes the user can use in the various Incoming

Excise Invoice transactions. This way, we can customize the transaction to what the end users have to do.

Standard settings - The system comes with three standard transactions relating to the Incoming Excise Invoices function (those that are included

in the role SAP_CIN). The processing modes available in these transactions are as follows:

J1IEX_C - This transaction is for excise clerks: users of this transaction can only capture and display excise invoices.

J1IEX_P - This transaction is for excise supervisors: they can change,

display, cancel, and post excise invoices.

J1IEX - In this transaction, users can capture and post excise invoices, as well as displaying, changing, and canceling them.

If the standard setting does not meet business requirements, adjust the

standard settings or you can create custom transactions. To do so, in Maintain Transaction, we create a new transaction by making a copy of one of the standard transactions. Give the new transaction a transaction

code. Enter data as follows:

Transaction code - The transaction code that is created.

Processing mode - Specify which users of the transaction will do with the excise invoices.

Active - Select this indicator to activate the setting.


Business Transactions --> Incoming Excise Invoices --> Define processing modes per transaction


Define reference documents per transaction:

For each combination of transaction and processing mode which

reference documents the users to be able to use. Activate each entry for it to work.


Business Transactions --> Incoming Excise Invoices --> Define reference documents per transaction


Maintain rejection codes : Define the rejection codes that are to be used in the Incoming Excise Invoices transaction. For each rejection code,

enter a code and a description. It can also be specified whether the excise duty in the invoice is to be posted to the CENVAT on hold account,

instead of the CENVAT clearing account.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Incoming Excise Invoices --> Maintain rejection

codes


Specify which movement types involve Excise Invoices:

Specify which movement types relating to goods receipts involve excise invoices. The system uses this information during the goods receipt

procedure. When a goods receipt is posted using one of the movement types that is specified here, the system prompts to enter the excise invoice number.


Business Transactions --> Incoming Excise Invoices --> Specify which movement types involve Excise Invoices


Excise Invoice capture against delivery in the background:

Select the method of processing Excise Invoices for a particular

combination of Plant and Vendor, in the Supplier Self Service system (SRM-SUS). In the table J_1I_BCKEXCSUS, we can process Excise Invoices

using the following methods:

Background Processing - Set the Create Excise Invoice Automatically indicator to yes for a particular combination of Plant and Vendor. In this case, the SRM-SUS system automatically processes the Excise Invoices in

the background.

Manual Processing - Set the Create Excise Invoice Automatically indicator to No for a particular combination of Plant and Vendor. In this case,

processing of Excise Invoice takes place manually. The processing can be done using transaction J1IEX.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Incoming Excise Invoices --> Excise Invoice

capture against delivery in the background


Business Transactions --> Outgoing Excise Invoices:

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Outgoing Excise Invoices --> Pricing Procedure

for Factory

Assign billing types to Delivery types:

Here we specify which billing document types you use as a reference for CENVAT utilization and assign them to the appropriate delivery document

types

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Outgoing Excise Invoices --> Assign billing types to Delivery types


Maintain default excise group and series group:

Here we specify which excise group and series group is to appear in these fields by default. We can make separate settings for different combinations of sales organization, distribution channel, division, and

shipping point.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Outgoing Excise Invoices --> Maintain default

excise group and series group


Business Transactions --> Subcontracting

Subcontracting Attributes:

The subcontracting attributes help determine conditions for a combination of an excise group, a transaction type, and a sub-transaction

type. The conditions such as the number of excise items per subcontracting challan, if the non-excisable materials have to be filtered or not when the subcontracting challan is created, the movement type

groups for issues and receipts and the hierarchy of determining the excise base value are mentioned here.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Subcontracting --> Subcontracting Attributes


Maintain movement type groups:

Here we group movement types together to form movement type groups. Movement Type Groups will be used to club the movement types based on

their nature (issues or receipts).

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Subcontracting --> Maintain movement type

groups


Business Transactions --> Exports under Excise Regulations

Make settings for ARE-1 procedure:

The settings that control how the ARE documents transaction works for ARE-1s are maintained here. These settings apply to exports under bond

and exports under claim for rebate. The system can be configured differently for different series groups.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Exports Under Excise regulation --> Exports -->

Make settings for ARE-1 procedure.


Make settings for ARE-3 procedure:

The settings that control how the ARE documents transaction works for ARE-3s are maintained here. These settings apply to deemed exports only.

The system can be configured differently for different series groups.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Exports Under Excise regulation --> Deemed

Exports --> Make settings for ARE-3 procedure


Maintain License types:

The license types that are to be used are maintained here. License types are used when we maintain the customers' deemed export licenses: Whenever a license is maintained, we need to specify which type it is.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Exports Under Excise regulation --> Deemed

Exports --> Maintain License types


Maintain output type

We define an output type for printing ARE-1s and ARE-3s from the ARE documents transaction. We specify which program, FORM routine, and

form is required to print the documents. The system comes with an output type already configured, J1IB (Excise Bonding) for printing the ARE Documents transaction.


Business Transactions --> Exports Under Excise regulation --> Printouts of ARE documents --> Maintain output type.

Transaction Code: M706

Specify printers:

We maintain a printer for each storage location. If there is a requirement

for the system to print the ARE documents immediately, we choose Print in the ARE documents transaction, and select "Immediately".


Business Transactions --> Exports Under Excise regulation --> Printouts of ARE documents -->Specify printers

Transaction Code: OMJ3

Define processing modes per transaction:

Please refer to the section on "Incoming Excise Invoices ® Define

processing modes per transaction", (the underlying logic is the same). We specify which processing modes the user can use in the various ARE document transactions. This way, we can customize the transaction to

what the end users have to do.

Standard settings - The system comes with eight standard transactions relating to the ARE document function (those that are included in the role SAP_CIN). The processing modes available in these transactions are as

follows:

Processing mode ARE-1s ARE-3s

Create, change, update, cancel, display J1IA101 J1IA301

Create, change, display J1IA102 J1IA302

Update, display J1IA103 J1IA303

Cancel, display J1IA104 J1IA304

Separate transactions have been created to allow distinguishing between

users who can only create AREs and those who can update them, which requires more skill and knowledge of the CENVAT processes.

Cancellation has been assigned a transaction of its own. Managers and administrators can use the central transactions with authorization for all

processing modes.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Exports Under Excise regulation --> Transaction

configuration --> Define processing modes per transaction


Define reference documents per transaction:

For each combination of transaction and processing mode which reference documents the users to be able to use. Activate each entry for it

to work.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Exports Under Excise regulation --> Transaction configuration --> Define reference documents per transaction


Maintain rejection codes :

Define the rejection codes that are used in the ARE Documents function. For each rejection code, maintain a code and a description. The third field need not be used.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Exports Under Excise regulation --> Transaction

configuration --> Maintain rejection codes


Business Transactions --> Utilization

Utilization Determination:

In this customizing we specify which CENVAT accounts are to be debited by the Fortnight Utilization of CENVAT report: When the report calculates

how much excise duty to be remitted, it automatically proposes which CENVAT accounts the duty should be debited to. We specify those defaults here. We can

o Either debit all the excise duty to one account or

o Debit the excise duty to more than one account, in which case we specify which percentage is to be debited to each account

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Business Transactions --> Utilization --> Utilization Determination


Maintain Minimum Balance for Excise accounts:

Maintain minimum balances in the excise accounts. When the balance in these accounts during utilization falls below this level, the system automatically utilizes funds in the PLA account.


Business Transactions --> Utilization --> Maintain Minimum Balance for Excise accounts


Business Transactions --> Excise register

Specify SAP script forms:

For each of the company codes, we specify which SAPscript forms the

system prints the excise registers with.

The layout description can be left blank or an appropriate description maybe filled in. Custom layouts and names can be maintained here

(preferably make a copy of the standard). If the output device and number of copies are maintained it is automatically picked up for printing.


Business Transactions --> Excise Register --> Specify SAP script forms


Tools

Long Texts:

Define the different types of long texts that is required for the various excise transactions. There is no limit to the number of types of long texts.

For each long text, we need to specify which transactions the long texts are for.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Tools --> Long Texts


Number Ranges:

Maintain the number ranges for all CIN Number range objects using this transaction. The number range number has to be '01' for all.

Menu Path: Logistics – General --> Tax on Goods Movement --> India --> Tools --> Number Ranges

Transaction Code: J1I9

Message Control :

Here we specify whether a given message should appear as a warning

message or an error message. Maintain each message, specifying whether it should apply to one user or all users.


Tools -->

Message Control


SAP Go-Live activities: Initial Data Takeover

Journal Entries

The stock upload will generate the following entry in the system:

Finished goods stock a/c ...................Dr

Semi-Finished goods stock a/c ............Dr

Raw Material stock a/c .....................Dr

Packing Material stock a/c .................Dr

Stores and spares a/c .......................Dr

Data take over a/c ..........................Cr

The accounting entry for Accounts Receivable open item upload is:

Customer a/c (not GL) ............Dr

Data takeover a/c .................Cr

The accounting entry for Accounts Payable open item upload is:

Data takeover a/c .................Dr

Vendor a/c (not GL) ...............Cr

Update the FI entry for asset through transaction OASV:

Plant and Machinery a/c .................Dr

Accumulated depreciation a/c ..........Cr

Data takeover a/c ........................Cr

Upload General Ledger account balances:

Data takeover a/c .......Dr (Balancing figure)

Cash a/c ..................Dr

Bank a/c ..................Dr

Advances ..................Dr

Share capital a/c .........Cr

Short term Loan a/c .....Cr

Long term loan a/c .......Cr

SAP Upgrade – Key points to remember

Purpose of this post - to highlight why customers across industry need SAP ERP

upgrades & how effectively these upgrade projects can be executed. This document

also covers actual upgrade experience of customer XYZ Corp.

Why upgrade ?

How do we start – The first steps

You must check following for making pre-upgrade checklist

What Happens During an SAP System Upgrade – Technical perspective?

The system switch upgrade

Upgrade strategies for SAP software (Downtime-minimized / Resource-minimized)

What tools are used during upgrade and how they affect overall plan?

Why Downtime?

How do we support while upgrade is going on?

Key things to have in place before starting - actual upgrade

Change Management (For regular production support)

System testing after upgrade (Test scripts)

Role Management

Interfaces – Connecting systems

Note: Above given points covered in one link only.

http://tknight.org/sdn/show/9136














SAP - FI ECC 6.0 New GL Functionality Config

Activate the New General Ledger Accounting by a single click on the clock icon.

You will reach to change view "activation of New GL A/cg" detail screen and tick

the checkbox and save.

After activation of New General Ledger Accounting, you exit the IMG screen when

you re-enter, you find that a new node is added Financial Accounting (New)

After activation of New General Ledger Accounting; a new sub node appears in the

IMG structure. This sub node is Define Segment

The Menu path is: SAP Customizing IMG ---> Enterprise Structure ---->

Definition --> Financial Accounting --> Define Segment

In this IMG activity, you define your segments. If you then define your profit

centers, you can enter an associated segment in the master record of a profit center.

The segment is then derived from the assigned profit center during posting.

Activation has created a new field in Profit Center Master Record: the SEGMENT

Leading and Non- Leading Ledgers In General Ledger Accounting. You can use

several Ledgers in parallel. This allows you to produce financial statements

according to different accounting principles. A ledger uses several dimensions from

the totals table it is based upon. When defining Ledgers, one must be defined as the

Leading Ledger. The Leading Ledger is based on the same accounting principles as

that of the consolidated financial statements. It is integrated with all subsidiary

ledgers and is updated in all company codes. This means that it is automatically

assigned to all company codes. In each company code, the Leading Ledger receives

exactly the same settings that apply to that company code: the currencies, the fiscal

year variant and posting period variant. You must designate one of yo ur ledgers as

the Leading Ledger. It is not possible to designate more than one ledger as the

leading ledger.

The Menu path is: SAP Customizing IMG ----> Financial Accounting (New) ----->

Financial Accounting Basic Settings (New) -----> Ledgers --- -> Ledger ----->

Define Ledgers for General Ledger Accounting

Clicking on the checkbox identifies one of your ledgers as the Leading Ledger.

Activation of Non Leading Ledgers Non Leading Ledgers are parallel ledgers to the

Leading Ledger. They can be based on local accounting principle, for example. You

have to activate a non- Leading Ledger for individual company codes. Non- Leading

Ledgers can have different fiscal year variants and posting period variants per

company code to the Leading Ledger of this company code.

The Menu path is: SAP Customizing IMG ----> Financial Accounting (New) -----

> Financial Accounting Basic Settings (New) -----> Ledgers - ---> Ledger ----->

Define and Activate Non --Leading Ledgers

Assign scenarios to ledgers : A Scenario combines Customizing settings from

different business views. Each business view specifies which posting data is

transferred from different application components in General Ledger Accounting,

such as cost Center update or Profit Center update .You assign the desired scenarios

to your ledgers. For each ledger, you define which fields are filled with posting data

from other application components. SAP delivers a number of scenarios in the

standard system. It is not possible to create additional sc enarios.

The Menu path is: SAP Customizing IMG -----> Financial Accounting (New) -----

> Financial Accounting Basic Settings (New) -----> Ledgers - --->Fields ----->

Display Scenarios for General Ledger Accounting.

Cost of sales accounting : Cost of sales accounting is a way to create a profit and

loss statement (P&L) for a company by comparing the revenues to the costs or

expenses incurred to obtain these revenues. The expenses are mainly divided by

functional area such as: Manufacturing Administration Sa les Research and

Development We can activate Cost of Sales Accounting by the following

Menu path: SAP Customizing IMG -----> Financial Accounting ( New ) ---- ->

Financial Accounting Basic Settings (New) -----> Ledgers --->Ledger-----> Activate

Cost of Sales Accounting

Offsetting Account Report ECC 5.0 Offsetting account report for vendors in ECC

5.0 is possible after implementing the OSS Note 1034354.

Difference between ECC 6.0 vs 4.7EE - SAP FI /

SD / MM / ABAP (Functional & Technical)

ECC means Enterprise Central component.

SAP R/3 4.7 is based on the 3-tier architecture. SAP is continuously upgrading the software,

which is called as release versions for example SAP R/3 4.6C, SAP 4.7....

Now SAP evolved into using the Internet technology and is called as service oriented

architecture (SOA). There are lots of functionalities available in ECC 5.0 and ECC 6.0 compared

to R/3 in integrating with other systems. Probably to understand the specific release dependent

changes, you can go thro the help documentation. For example to understand the diff between

ECC 6.0 and ECC 5.0 please go thro the link:

Release Notes for SAP ERP Central Component (English) – Click here

Some of the differences in SD Module are:

1. Document Flow

In ECC 6.0, the flow of sales documents is seen much better and improved as compared to 4.6C.

Once you look at the screen, you will clearly figure out the difference.

2. Sales Order Look and Feel

There are more tabs in ECC 6.0 for Item Level Details.

The Sales Doc. appears as supremely perfect.

3. ECC 6.0 is built on Net Weaver Technology (that possess SOA i.e. service oriented

architecture), Hence more reliable and improved as compared to previous one.

Release Notes for SAP ERP Central Component (English) – Click here

http://help.sap.com/saphelp_erp2004/helpdata/en/c6/feda40ebccb533e10000000a155106/frameset.htm

http://help.sap.com/saphelp_erp2004/helpdata/en/c6/feda40ebccb533e10000000a155106/frameset.htm

Some of the differences FI Module side:

1. ECC 6.0 enables Business area posting - Segment reporting made easy.

2. Profit center accounting is through new GL.

3. Document splitting: Split of entry to post assets and liabilities to respective profit centers.

(Balance sheet items)

4. Enables commitment of FM, improved CRM feature & Mobile sales feature

Here are the list of Transactions not their in ECC 6.0

QAS1 Download Insp. Specs. (Obsolete)

QAS2 Download Basic Data (Obsolete)

QAS3 Upload Results (Obsolete)

QAS4 Upload UD (Obsolete)

WLF1K Report used to generate WLF1K is: SAPLWLF1

O07C Report used to generate O07C is: SSFPSEMAINT

Check the below links to download the PDF files for the release notes of MM Module:

ECC 5.0 - MM Module Release notes

SAP R/3 MM Module Release notes

http://help.sap.com/saphelp_erp2004/helpdata/en/1f/00d340fa1a732ae10000000a155106/Chap_13_MM.pdf

http://help.sap.com/saphelp_47x200/helpdata/en/cb/2f26455c59a046a37e58dc3f1ae85e/Chap_09_MM.pdf

Pre – Go Live activities: Below given Master data

Loads required into Production system

Material Master – Basic responsibility MM: All the respective views of the materialmasters the

other modules responsible . Ensure that all the required views are uploaded

GL codes - FI

Customer Master - FI (accounting view) and SD (sales view)

Vendor Master - FI (accounting view) and MM (purchasing view)

Cost elements - CO

Secondary cost elements - CO

Profit centers - CO

Cost center - CO

Activity type – CO

Bill of Material – PP

Work Center/ Resource – PP

Routing / Master Recipe – PP

Purchasing Info Record – MM

Service Master - MM

Bank Master - FI

Use the TCODE: SE16N. TCODE: SE16 mostly used by the ABAPer. For a functional consultant SE16N helps much. Try and let me know

SAP FI: Payment Terms Set Up Example

Payment Terms Issue :

Payment term to be set up as below:

70 days, days of payment 15 and 30

Example:

Date invoice: 01/05/2011 Due date: 15/07/2011

Date invoice: 10/05/2011 Due date: 30/07/2011

SOLUTION:

We have created 3 payment terms with the day limit as 6, 21 and 31.

In the 'payment term' field of OBB8, we have input:

Payment term Fixed date Additional months

ZTE6-6 15 2

ZTE6-21 30 2

ZTE6-31 15 3

SAP FI: SWIFT Code details :

SWIFT code is a standard format of Bank Identifier Codes (BIC) and it is unique

identification code for a particular bank. These Codes are used when transferring

money and messages between banks.

The SWIFT code consists of 8 or 11 characters. When 8-digits code is given, it

refers to the primary office.

First 4 characters - bank code (only letters)

Next 2 characters - ISO 3166-1 alpha-2 country code (only letters)

Next 2 characters - location code (letters and digits) (passive participant will have

"1" in the second character)

Last 3 characters - branch code, optional ('XXX' for primary office) (lett ers and

digits)

SAP AP: F110 Automatic Payment Run : Tables Payment Run relevant tables:

FEDIWF1 FI EDI: Person with signing authority

OPN_J1 Japanese DME Foreign Payment Accounting

Data (Open FI)

PNBK Prenotification: New bank data from master

records

PNHD Prenotification: Files created in ACH format

PYONUMKR Auxiliary structure for lock object

EPYONUMKR

PYORDH Payment order header data

PYORDP Payment order item data

REGUA Change of payment proposals: user and time

REGUH Settlement data from payment program

REGUHH REGUH version before the 'n'th change

REGUHM Payment Data for Cross-Payment Run

Payment Medium

REGUHO REGUH version before the 'n'th change

REGUP Processed items from payment program

REGUP_CORE Processed Items from Payment Program

REGUPO Line item status before the 'n'th change

REGUPW W/tax information per w/tax type/FI line item

in pmnt run

REGUS Acounts blocked by payment proposal

REGUS_SEPA SEPA Mandate Lock: Applications To Be

Retrieved

REGUT TemSe - Administration Data

REGUTA Paying Company Codes for DME Files

REGUV Control records for the payment program

REGUVM Payment Data for Cross-Payment Run

Payment Medium

SMFIAP Spec. FI-SL Data in Monitor (See

Schedman_specific_fisl)

T004F Field status definition groups

T012E EDI-compatible house banks and payment

methods

T042 Parameters for payment transactions

T042A Bank selection for payment program

T042C Technical Settings For The Payment Program

T042D Available amounts for payment program

T042FSL Last additional selections used

T042G Groups of company codes ( payment program

)

T042I Account determination for payment program

T042J Bank charges determination

T042JB Customizing table for Japan Bank Mergers

T042JB1 Customizing table for Japan Bank/Branch

Mergers

T042K Accounts for bank charges

T042L Bank transaction code names

T042M User Numbers At The Bank

T042N Bank transaction codes

T042OFI Events for MT100 and other DME Formats

T042OFIT Events for MT100 and other DME Formats

T042P Bank selection by postal code

T042R Name of account holder (ref.specifications on

bk.details

T042S Charges/expenses for automatic pmnt

transactions

T042U Block Entries for Debit Customers/Credit

Vendors

T042V Value date for automatic payments

T045T User ID for bank transactions

T077D Customer account groups

T077K Vendor account groups

T078D Trans.-dependent screen selection for

cust.master

T078K Transaction-dependent screen selection for

vendor master

T079D Company code-dependent screen sel.for

cust.master

T079K Company code-dependent screen sel.for

vend.master

T079M Vendor master data screen selection

(purch.org.)

TBACN Bank EDI file version numbers

TBSL Posting Key

TFAGS Definition of FI clearing rules

TFAGT Texts on FI clearing rules

TZGR Grouping rules for automatic payments

TZGRT Name of grouping rules

TBTCO Job Status Overview Table

TFBUF Table for FI Data Puffers

TRDIR Generated Table for View TRDIR

VARID Variant directory

VARIT Variant Texts

Variant Tex

http://purch.org/

SAP Fiscal Year Variant Change :

Business Scenario:

The requirement for Fiscal Year Variant change was felt due to the following scenario:

= ABC Ltd Business is sold to XYZ Ltd.

= Fiscal Year followed by ABC Ltd is „April – March‟, but XYZ Ltd. follows a cycle of

„January – December‟ as their Fiscal Year.

= ABC Ltd wants to switchover to the Fiscal Year covering „January – December‟ to align their

reporting period with the one followed by XYZ Ltd...

= Statutory reporting e.g., Excise, Sales Tax, Withholding Tax to continue as per law of the land.

The period to follow is „April – March‟, as always followed.

= ABC Ltd wants to end the Fiscal Year 2004 at December 2004 and move to the New Year

2005 from January 2005. Here ABC Ltd wants to close the year 2004 after 9 months, thereby

shortening the Fiscal Year of 2004.

Steps to be performed:

To meet the requirement of business scenarios, we need to perform the following changes in

SAP: -

1) Creation of a new Fiscal Year Variant. Here we can copy a SAP provided Standard Variant to

make the new one.

2) New variant to be made Year Dependent. Year dependent status to be extended for required

numbers of past and future years to create the number of periods in terms of month.

3) The new Fiscal Year Variant to be shortened on the basis of number of periods under

consideration.

4) New Fiscal Year Variant to be assigned to all Co Codes involved (OB37).

5) Change of Fiscal Year Variant in Controlling Area (OKKP).

6) Fiscal Year to be shortened for Depreciation Areas in Asset Accounting customization

(OAYP).

7) Table T093C to be viewed to check whether the field XRUMPF (Shortened Fiscal Year) has

been activated with “X”. If the field is found to be blank then we need to refer to SAP Note

123026 and then execute program ZRUMPF. That will activate XRUMPF in T093C.

8) Recalculate Depreciation to be executed (AFAR). This will adjust the planned depreciation

according to the number of periods in the shortened fiscal year.

9) After checking the recalculated depreciation, Depreciation run (AFAB) and other closing activities to

be performed as per normal procedure.

Relevant SAP Notes:

SAP Note 123026 to be applied for activation of field XRUMPF (Shortened Fiscal Year) in Table T093C.

Some of the related notes are 672255, 506622, 484048, 183546, 26891 etc. SAP Note 373894 is a

very important master note

Ts

SAP: IBAN – International Bank Account

number :

IBAN – International Bank Account number – internationally recognized, unique

identification number for a specific bank account

IBAN designed by ISO and ECBS (European Committee for Banking Standards) –

for international payments

IBAN – 34 alphanumeric character and structured differently in every country

IBAN – contains Country code, Bank Key and Account Number

IBAN – maintaines in Customer / Vendor Master bank details & House bank

IBAN – you have to enter manually in each master record , for certain countries the

system proposes the IBAN number

IBAN – when you enter for new bank details, system generate the country-specific

bank details for certain countries.

Differences : SAP FI & SAP CO

Deactivation & Retirement of Asset :

When asset is sold or scrapped with retirement posting, the asset value date is updated as

deactivation date.

You can also plan deactivation of asset by entering future date in deactivation date field asset

master data.

ABGF and AB08 :

AB08 is used to Reverse the amount posted to an asset - reverses the asset document.

ABGF is for passing a credit memo using an adjustment account(offsetting account) in the next

year.

KO88 and KO8G :

KO88 is used for settling single order (more like day to day work) used settlement to final asset

KO8G is used periodical to select a group of internal orders used periodical posting for AUC

Asset History and Asset History Sheet:

the Asset History is a report which shows the complete history of an asset. All information such

as master data, depreciation area definition, development over the years of useful life. Further

more this report uses SAP Script.

The Asset History Sheet is a report which shows the value flow (= value history) for one year in

the asset useful life.

Manual depreciation and Unplanned depreciation :

Manual depreciation is when you use in the asset a manual depreciation key.

Unplanned depreciation you use aditional on a Manual or an other depreciation rule.

GL Planning & Cost element planning:

GL Planning would be carried out in FI and can be done for all P&L and B/S GL accounts. In

case controlling is active then you can try for Cost element planning for P&L accounts. The Cost

element planning will also be made use of for activity type plan price calculation in product

costing

BADI and USER-EXIT:

i) BADI's can be used any number of times, where as USER-EXITS can be used only one time.

Ex:- if your assigning a USER-EXIT to a project in (CMOD), then you can not assign the same

to other project.

ii) BADI's are oops based.

LIV and Normal Invoice document :

LIV is useful for verifying goods which related to MM. When goods purchased or when received

verifying the invoice details like quantity, rate, invoice number etc., PO with the invoice. LIV is

linked to FI and MM. But FI inovice is creating only in FI, it no where linked to any module.

Entries are different in both cases.

Consolidated Business Area and Cost Center Grouping :

Business consolidation is for more of consolidation purpose and cost center grouping is more for

management reporting purpose for cost control purposes.Both the organizational units serve for

different purposes. Consolidatied business will not have much meaning unless you go with EC-

CS.Cost Center Groups are much for control purpose and help in managerial reporting.Business

Units are part of FI Organizational Structure and Cost Centers are part of CO organizational

structures.

COPA & PCA :

In Profit Center Accounting Costs and Revenue are matched to find the profitability of the

Investment Center. The shared services expenses are allocated equitably in between the profit

centers to find our the accurate ROI of the Investment Centers. Here you will get the Segmental

Profit and loss account.

Whereas in the case of COPA, we get Product profitability upto Net income before Corporate

tax. The Cost of Sales is matched with the revenue to get the gross margin per each product as

well as marketing segment. Then selling overhead and Corporate expenses are allocated to the

products on the basis of revenue and we get EBITDA(Earnings before Interest, Debenture

interest and tax. The Longterm Interest and debenture interest shall also be allocated to the

products equitably. Consequently, it is able to know the profitability of the products before

payment of tax.

TAXINJ & TAXINN :

The only difference between TAXINJ & TAXINN is that TAXINJ is formula

based tax procedure which is dependant to a large extent on routines

to calculate taxes at each level.

TAXINN on the other hand is condition based tax procedure which is very

similar to the standard pricing procedure & is not dependant on routines

and other programs to fetch taxes. It is simply dependant on condition

records maintained for each of the tax conditions.

Prior to R/3 Enterprise we had only formula-based and from R/3 Enterpri

version you will have the option of Formula-based or Condition-based.

If you select TAXINN, it will support only condition- based excise

determination. And if select TAXINJ, you will have the option of Formula

-based and Condition-based (in SD not MM).

If you have future plans for extending your organisation to our new

dimension product such as CRM....then using TAXINJ would mean that the

formulas would need to be copied/rewritten to the CRM IPC. Where as you

would not be required to do that in TAXINN....

So if you do not have any plans for extending SAP solutions in your

organisation then you can use TAXINJ, else it is recommended that you

use TAXINN only.

Controlling and enterprise contrilling :

In controlling module you define the cost centres and in enterprise controlling you define the

profit centres.

SAP cannot generate the profit and loss acoount and balance sheet for every cost centre but can

generate P&L and balance sheet for each and every profit centre.

Enterprise Controlling is a separate module altogrther and consists of Consolidation and PCA as

well. Whereas Controlling is a module which consists of CCA ,PA,Product Costing ,IO etc

Activity Types & SKFs :

Stat key figures are just that they have no financial impact in Controlling but may be used for

reporting

and allocation purposes etc.Activity type are associated with a sender (usually cost centre with a

specific rate). Activity type wil always carry rate against it where as SKF wont have any rate.. It

means activity type

is used for both allocation and absorption where as SKF can only be used for allocation.

Example -

Activity types in production cost centers are machine hours or finished units.

Stat key figures are just that they have no financial impact in

Controlling but may be used for reporting and allocation purposes etc.

Activity type are associated with a sender (usually cost centre with a specific rate). When an

activity posting is made with either CATS or KB21 a transfer posting is made for the quantity *

rate . This creats a CO posting between 2 different objects (sender and receiver)

SKF is not a real cost object , it carries statistical posting only =so it solely for reporting and

analysis. Hoewev activity type is use for cost allocation from one cost object to another. Activity

type for example No of Employee, Production hr whcih we can use to charge production over

head to production order.

CK91 and CK86 :

CK91 is creating a Procurement Alternative where you define that source of procurement for a

said material / plant whether it would be stock transfer / production etc..

Where CK86 costing a material based on a Procurement alternative.

Production Order and Product Cost :

Transaction for product cost collector is KKF6n. the product cost collector for that particular

material,plant for repetetive manufacturing, production version it is used. As cost is collect and

settle on period base.

While the production order costing done on order bsae and settelment also carried for order.

In REM settlement is against a period. Because production is not dependent by order. So to settle

the cost for all the orders in certain period ex. for a month product cost collector is required. In

this product cost collector, cost will store for all the orders.

In Production order or process order, settlement against each order. So no need to create product

cost collector.

In production orders can can be used as a Cost object. Since production order is a cost object the

costs can be settled to the cost centers or Sales orders using the process order as a cost carrying

object.

In REM there is no Production order. Hence Product Cost Collectors are used. The cost can be

sttles period or quantity wise.

SAP New GL : DOCUMENT SPLITTING –

Configuration Standard Customizing Settings

In the Implementation Guide, choose Financial Accounting (New)->General Ledger Accounting

(New)-> Business Transactions->Document Splitting.

1. Classify G/L Accounts for Document Splitting

You need to classify the individual document items so that the system knows how to handle

them. You do this by assigning them to an item category. The item category is determined by the

account number. In this IMG activity, you need to assign the appropriate accounts.

2. Classify Document Types for Document Splitting

Every business transaction that is entered is analyzed during the document splitting process. In

this process, the system determines which splitting rule is applied to the document. To enable the

system to determine the splitting rule, you need to assign a business transaction variant to each

document type.

3. Define Zero-Balance Clearing Account

Here you define a clearing account for account assignment objects for which you want to have a

zero balance setting when the balance is not zero.

4. Define Document Splitting Characteristics for General Ledger Accounting

Here you specify to which document splitting characteristics document splitting applies, for

example, profit center or segment. The characteristics that you specify should be maintained in at

least one of your ledgers. You determine which characteristics are maintained in your ledger by

assigning scenarios or customer fields to your ledgers. You also define how this characteristic is

to be handled by specifying, for example, whether you want to apply a zero balance setting,

whether the field is a required entry field, and the appropriate partner field.

5. Define Document Splitting Characteristics for Controlling

Here you specify which additional characteristics you want to apply in document splitting. The

additional characteristics are not relevant for General Ledger Accounting. Instead, they are

relevant for components in Controlling that use documents transferred from General Ledger

Accounting.The selected characteristics are only transferred to the specified line items when the

account to which the postings are to be made can also take the characteristics.

6. Define Post-Capitalization of Cash Discount to Assets

Here you define whether the cash discount that is applied in the payment of an asset-relevant

invoice should be capitalized to the asset. When you select this setting, the cash discount amount

is not posted to the cash discount account in the payment document, but instead directly to the

asset.

7. Edit Constants for Nonassigned Processes

Here you define default account assignments (for example, a default segment) for specific line

items in processes for which it is not possible to derive the correct account assignments at the

time when the document is posted. This is the case if the required information is not yet available

when the posting occurs.

8. Activate Document Splitting

In this IMG activity, you activate document splitting. The splitting method used is that delivered

by SAP as standard, which contains the splitting rules for the different business transactions. If

this splitting method does not meet your requirements, you can first define and then select your

own method in Customizing for document splitting (see the next step).

Settings for Extended Document Splitting

Here you define your own rules for document splitting and make the necessary settings so that

the system applies the rules you defined and not the SAP standard rules.

9. Define Splitting Method

Here you define your own method for document splitting. A splitting method contains the rules

governing how the individual item categories are dealt with.

10. Define Splitting Rule

Here you define the splitting rules for document splitting. You assign one or more business

transaction variants, the account key for the zero balance setting, and the leading item categories

for cross-company code transactions to a splitting method.

11. Assign Splitting Method

Here you assign the splitting method to be used for document splitting after activation. If you

want to activate your own splitting method, replace the standard method with your own method.

12. Define Business Transaction Variants

Here you can define business transaction variants for the business transactions in document

splitting.

DOCUMENT SPLITTING - Details

Document splitting allows you to display documents using a differentiated representation.

In the representation, line items are split according to selected dimensions.

In this way, you can draw up complete financial statements for the selected dimensions at any

time.

Using the document splitting procedure, you can also create a segmented display of a (partial)

balance sheet according to a set of legal requirements (for example, IAS) or according to areas of

responsibility.

In addition, you can allocate at the time of posting additional costs (such as realized or valuated

exchange rate differences) to the CO account assignment objects to which the costs relate.

Assets can also be subsequently capitalized at the time of posting.

Implementation Considerations: You need to make settings in Customizing and other

preparations for document splitting.

If you already use new General Ledger Accounting in your production system and want to

implement document splitting subsequently, you need to use the General Ledger Migration

Cockpit

Integration: Document splitting has an effect on subsequent processes, such as closing

operations, and on processes in Controlling (CO).

Features: You can use the document splitting procedure to split up line items for selected

dimensions (such as receivable lines by profit center) or to effect a zero balance setting in the

document for selected dimensions (such as segment). This generates additional clearing lines in

the document.

Document Splitting Process: For document splitting to be possible, the system classifies the

individual line items as well as the documents. This takes place using your settings in

Customizing. Depending on how a document is classified, the splitting rule selected for a

document specifies how the document is split and for which line items.

SAP delivers a set of standard splitting rules. You can also define your own rules.

Subfunctions of Document Splitting

The following functions are part of document splitting:

Passive document splitting:

Clearing and similar processesThe system creates a reference to existing account assignments.

These account assignments are used as the basis for line items to be split.

The system applies all account assignments that you have defined as document splitting

characteristics in Customizing.

If you have set the Zero Balance Setting indicator for the document splitting characteristic, the

system then creates any necessary clearing lines to ensure that the characteristics produce a

balance of zero in each document.

Active document splitting:

Splitting a documentIn this subfunction, the line items are split according to the settings in

Customizing (the classification of the document and the splitting rule assigned to the document).

Subsequent processes:

Clearing, such as realized exchange rate differencesFor example, you can also use the CO

account assignments relating to the costs to post the realized exchange rate differences occurring

in this subsequent process.

Closing operations, such as foreign currency valuation

You can perform closing operations according to the document splitting characteristics defined.

Document Splitting Simulation

During document entry, you can simulate the postings to be generated.

From the simulation in the general ledger view, you can call the expert mode.

In the expert mode, you obtain detailed information about the split document as well as about the

document splitting rules applied.

Furthermore, it allows you to view the Customizing settings for document splitting specific to

the business transaction. Displaying the Split Document

You can display a document as follows:

- In its original form in the entry view

- Split from the view of a ledger in the general ledger view and with the generated clearing lines

How the document is displayed in the general ledger view depends on whether the ledger to

which you want to post contains the document splitting characteristics to be applied in document

splitting.

Limitations: You can only use document splitting for documents that can be uniquely assigned to

a business process. The relevant relationship is unclear when there are multiple business

processes within one document

Change of Account type from Balance Sheet to P&L

account :

There are times you commit mistakes in creating general ledger account master record. Instead

of creating it as P&L account sometimes it's created as Balance Sheet account (& vise-versa).

More often than not, that mistake of g/l account setting becomes apparent only and notice when

there are already posted transactions to the account. The SAP standard won't allow change of g/l

account from P&L account to Balance Sheet account if transactions exist with the account.

Error Message:

When trying to change, the error message that appear is " Change balance sheet control in spite

of account balance".

Analysis and Diagnosis:

You've changed the G/L account from a "balance sheet acount" to a "P&L account" or

conversely.

The g/l account that has changed from P&L account to balance sheet account (& vise versa) has

an existing transaction balance.

Soluation:

The message is under application area FH. You can set as warning message applicable to all

users (user name is blank), for online processing and/or for bakground processing. The save the

change.

In your testing after the change, the message "Change balance sheet control in spite of account

balance" is now only a warning message, hence; you can save the change in g/l account from

P&L account to Balance Sheet account or conversely.

And always run Balance Carryforward (FAGLGVTR) transaction after the change to classify

correctly the balance of the g/l account changed.

In the standard SAP, the message "Change balance sheet control in spite of account balance" is

set as an error message. Hence, if this message appear you can not save the change.

As an alternative solution, you can change the message control from an Error (E) to Warning

(W) message only. To do that follow this useful guide and procedures:

Path: SPRO → Controlling → General Controlling → Change Message Control.

Transaction Code: OBA5

The message is under application area FH. You can set as warning message applicable to all

users (user name is blank), for online processing and/or for bakground processing. The save the

change.

In your testing after the change, the message "Change balance sheet control in spite of account

balance" is now only a warning message, hence; you can save the change in g/l account from

P&L account to Balance Sheet account or conversely.

And always run Balance Carryforward (FAGLGVTR) transaction after the change to classify

correctly the balance of the g/l account changed.

Currency type in FI & CO

1. Possible currency types in CO

o 10 company code currency

o 20 currency of the controlling area (known only in CO)

o 30 group currency

o 40 hard currency

o 50 index-based currency

o 60 global company currency

2. Possible currency types in FI:

o 10 company code currency

o 30 group currency

o 40 hard currency

o 50 index-based currency

o 60 global company currency

3. Some Points on Currency type:

o A maximum of two currencies can be managed for all postings in FI and

CO, independentof the currency types used in the controlling area.

o Currency type 10 is always managed in FI. In addition, if needed, currency type 30 can be

managed as a parallel currency in FI.

o Currency type 30 can be managed as a parallel currency in FI.

o Currency type 20 cannot be managed as a parallel currency in FI (this exception is only

valid for currency type 20, since it can only be managed in CO).

o You can also activate type 20 in FI-SL and Profit Center Accounting.

o There is also currency type 80 (ledger currency) in FI-SL and currency type 90 in Profit

Center Accounting (currency of Profit Center Accounting).

o In FI, a maximum of 3 parallel local currencies can be managed per company code but

category 10 is mandatory.

o You can invariably use all of the currency types with the material ledger.

o You can only use transfer prices with currency type 10 or 30, since currency type 20 is

notsupported in FI.

The selection of the currency type in the controlling area has no influence on CO-PA. You can

set theoperating concern currency independent of the other CO currencies. In the costing-based

Profitability Analysis, you can update the operating concern currency and the company code

currency (optional). In the account-based Profitability Analysis, the data (as in CO as well) is

always updated in controlling area currency, company code currency and transaction currency.

Document Number not in sequence ...

Issue:

Gaps (jumps) occur when allocating internal numbers.

The status of the number range interval does not match the number that was last assigned.

The number assignment does not reflect the insert sequence.

Applicable for below TCODES:

FB01, VF01, KO88, KE21, KE11, FD01, FK01, XK01, XDN1, MB01, MB0A, MB11, MB1A,

MB1B, MB1C, MB31, KANK, KB11, KB13, KB14, KB41, KB43, KB44, KB21, KB23, KB24,

KB31, KB33, KB34, KB51, KB53, KB54, PR01, PR02, PR03, PR04, PR05, XD01, VD01,

MK01, SNUM, SM56, SNRO, VL01, VL02, CO01, CO40, CO41, VA01, MR1M, MIRO.

Reason:

A large number of number range objects are buffered. When the system buffers a number range

object, it does not update numbers individually in the database but reserves a preset group of

numbers in the database the first time a number is requested, and makes these numbers available

to the application server in question. The following numbers can then be taken directly from the

application server buffer. New numbers are not used in the database until the application server

buffer has been used up.

Buffering the number range objects has a positive effect on performance, because the system no

longer has to access the database (number range table NRIV) for each posting. Furthermore, a

serialization of this table (database locking) is prevented to a large extent so that posting

procedures can be carried out in parallel.

Solution:

Since number range buffering does not cause any expressly assured qualities to be lost, no

correction is required.

If you still require continuous allocation, you can deactivate the number range buffering

specifically for individual objects.

Proceed as follows:

Start Transaction SNRO and enter the affected object.

Choose 'Change'.

Deactivate buffering: Choose 'Edit' -> 'Set Up Buffering' -> 'No Buffering'.

If you want to change the buffer size only, enter the corresponding value in the field 'No. of

numbers in buffer'.

Save the changes.

Number range buffering can be activated or deactivated at any time.

Number range objects that have to be continuous due to legal.

For the following number range objects, gaps may cause:

Area CO:

- RK_BELEG (CO Document)

CAUTION: Note that the problems described in Notes 20965 and 29030 may occur if you

deactivate buffering.

- COPA_IST (Document number in actual posting)

- COPA_PLAN (Document number in planned posting)

- COPA_OBJ (Profitability segment number)

Area FI:

- DEBITOR (Customer master data)

- KREDITOR (Vendor master data)

Area HR:

- RP_REINR (Trip numbers)

Area PM, PP, PS

- AUFTRAG (Order number, production, process, maintenance order, network number)

- QMEL_NR (Number range - message)

Area MM:

- MATBELEG (Material documents)

- MATERIALNR (Material master)

Area QM:

- QLOSE (Inspection lots in QM)

- QMEL_NR (Number range - message)

- QMERK (Confirmation number)

- QMERKMALE (Master inspection characteristics in QSS)

- QMERKRUECK (Confirmation number of an inspection characteristic in QM results

processing)

- QMETHODEN (Inspection methods in QM)

- ROUTING_Q (Number ranges for inspection plans)

- QCONTROLCH (Quality control chart)

Area Workflow:

- EDIDOC (IDocs)

For other possible solutions, refer to the following notes: 37844, 23835, 179224, 678501, 599157

and 840901.

IMPORTANT: Read Notes 504875 and 678501.

What type of qustions need to ask to client

before sap fico prject start ?

Initially you need to prepare topics wise questions and in the process the data collection should

be from 2 sources i.e. Primary - collecting information directly by interacting with the client and

the other one is Secondary - from the documents that you collect from the client.

After formal introduction during the Kick off meeting never directly jump down to interact with

the client you need to patiently observe the day-to-day business process of the client -

department wise for the first few days. Do document all the observations that are made by you,

this will help you to analyze the gap between the legacy system and standard SAP Process.

The first and the foremost thing is that we need to see on what platform all the business process

relating to Accounting is maintained i.e. the software used to store the legacy data.

Now I will mention some of the important points that can be used a checklist during your

interaction with the client.

1.We are the consultants who need to freeze the Enterprise Structure first and later on the other

module consultants will add their respective enterprise elements to the enterprise structure

freezed by us. Therefore this process will by itself will take not less than 1 to 2 months. This

process is the typical phase where a lot of interaction/understanding/experience will come into

limelight. So beattentive and observe the process thoroughly, once the Enterprise Structure is

freezed and configured we cannot withdraw from the system.

2. Codification of the Enterprise Elements play a vital role does follow some naming

convention. Here coding can be in 3 forms i.e. pure numeric, alphanumeric or pure alphabets.

3. Identify the chart of accounts that is maintained.

4. Grouping process of the GL Account According to Schedule VI of Companies Act 1956

5. Customer & Vendor Grouping - payment terms maintained - Down payment

if applicable - how the memos maintained.

6. Collect all the documents relating to Procurement Process right from indent preparation

to billing and followed by payment. This is very useful.

7. CIN plays a very important role regarding this we will have a separate session in the

days to come.

Duplicate Invoice Check :

OMRDC Configure Duplicate Invoice Check

In this screen, you can configure for each company code if the system is to check for duplicate

invoices when you enter invoices.

This check should prevent incoming invoices being accidentally entered and paid more than

once.

You can choose whether to activate or deactivate the check criteria of company code, reference

document number and invoice date for each company code. The more criteria that you activate,

the lower the probability of the system finding a duplicate invoice. The

Accounting documents are checked first, followed by documents from Logistics Invoice

Verification (only incorrect invoices or those entered for verification in the background).

When checking duplicate invoices, the system compares the following attributes in the standard

system:

Vendor

Currency Company code

Gross invoice amount

Reference document number

Invoice date

If the system finds an invoice that matches all attributes, the system displays a customizable

message.

If you are entering credit memos, subsequent debits, or subsequent credits, the system does not

check for duplicate invoices.

If a previously processed document is later cancelled and then entered again, no message is

displayed.

Example

The following document has been entered and posted:

Reference document number: 333

Invoice date: 28.04.2000

Gross invoice amount: 100,00

Currency: EUR

Vendor: 15000

Company code: 1000

The settings for checks for duplicate invoices in Customizing have been maintained as follows:

The field reference document number and company code are not selected. This means that these

attributes will not be checked. Now enter the following invoice:

Reference document number: 334

Invoice date: 28.04.2000

Gross invoice amount: 100,00

Currency: EUR

Vendor: 15000

Company code: 2000

Result: By entering the reference document number and entering an invoice, it is possible to

check for duplicate invoices. The reference document number and the company code contain

different data than the invoice you entered. These attributes are not checked because you have

deselected them in Customizing. All other attributes are equal. The system displays a message

telling you that a duplicate invoice has been found.

If, for example, you had selected the reference document number in Customizing, the system

would check this and recognize that this invoice is different to the previously entered invoice.

The system would not then display a message.

SAP - FI AR BK: Electronic Bank

Reconciliation

The EBS is used to automatically assign incoming and outgoing payments to house bank

accounts when they relate to items already posted in the system to customer/vendor/clearing

accounts and, where appropriate, the clearing of them.

Each uploaded electronic bank statement will be assigned with a unique no. in SAP and can be

printed retrospectively.

Steps in Electronic Bank Reconciliation:

1. Electronic Bank Statement file (in SWIFT MT940 format) is extracted from BANK

2. Data (SWIFT MT940 for BANK) is imported into a temporary dataset in SAP

3. Batch input sessions are generated (per bank statement: one session for G/L Accounting and

one for Subledgers- AR/ AP). Bank accounting and subledger accounting batch session can be

executed separately or jointly

4. Posting rules and account determination are defined in TR-CM customization

5. As an electronic bank statement is being imported, the system identifies the transactions in it

and determines how they are posted.

6. The note-to-payee fields in the electronic bank statement contain various information relevant

to open item clearing. Note to payee fields can be interpreted by document number or reference

document number for the clearing transaction (example: standard algorithm). If the algorithms

we deliver are not sufficient, it is possible to program a user exit tailored to your business (e.g.

change the posting rule; influence account determination by means of account modification).

7. Post-processing for posting proposals(line items) which cannot be cleared

Note:

Electronic Bank Statement format SWIFT MT940 is compactable with SAP TR-CM. Standard

algorithm for clearing documents is available in the predefined form in SAP. Customisation, as

stated in point 6 above, will be needed to cope with AAA specific requirements on Bank

Reconciliation. The review task will be performed on the Detail Design Phase, detail of which

will be incorporated into the respective customisation functional specifications.

Intercompany transactions in SAP AP / AR :

Cross Company Code Transaction

Several companies are involved in an intercompany transaction. The system will post a separate

document with its own document number in each of the company codes. A common cross-

companycode number links individual documents together. The system generates line items

automatically (receivables and payables arising between company codes) in order to balance the

debits and credits in each document.

Company One

Dr. Expense / Balance Sheet account for Company One

CR. Intercompany AP

Company Two

DR. Intercompany AR

CR. Expenses / Balance Sheet account for Company Two

Each branch will have different general accounts for AP and AR to separately identify there

debits and credits.

This transaction will only be finance related. Intercompany posting in Logistics will be posted in

the system automatically.

The process for posting intercompany transactions is as follows:

1. The initial entry is parked.

2. Then an email is sent to the other branch to view the document.

3. On approval of the transaction, the parked document is then posted to the g/l in both

companies. The company receiving the revenue will be the one responsible to book into system

using the US dollar as base currency.

SAP - AA : Legacy Asset Data Transfer Configuration Steps

Transaction Code

SPRO Set Company Code Status

OAYE Specify Sequence of depreciation areas

SPRO Specify Transfer Date / Last Closed Fiscal Year

OAYC Specify Last Period Posted in Prv. System (Transf. During FY)

OAYD Transfer Foreign Currency Values

OAYF Recalculate Depreciation for Previous Years

OAMK Set Reconciliation Accounts (Manually)

Set Company Code Status:

SAP Reference IMG > Financial Accounting > Asset Accounting > Asset Data Transfer > Set

Company Code Status

You use this indicator to specify the status of the company code from the point of view of Asset

Accounting:

Test status - You can change values by transferring asset data from a previous system, or by

posting.

Transfer status - You can enter and change values by transferring asset data from a previous

system, but posting is not possible.

Production status - The asset data transfer is complete. You can only change values by posting.

Before the system goes live, it is essential that you set the system status to "production" (not

test).

This rule applies even if you transfer asset data from your previous system in several phases

over the course of time. If you do transfer data in this way, you have to temporarily remove the

"production" setting of the the company code status. Company code status is generally set to '2'

for conversion purposes. This identifies the company code as being in test with data transfer

always allowed. This should be the start-up position for the asset company codes.

In the Production system, this setting should be changed to "0 – Asset data transfer completed"

once all data takeover activities are completed for each company code.

Once the SAP company code has had at least one Quarter end reported and verified after go-live,

and the assets data is deemed stable, the company code status will be set to '0'.

0 Asset data transfer completed

1 Asset data transfer not yet completed

2 Test company code with data transfer always allowed

3 Company code deactivated - reporting allowed

Specify Sequence of Depreciation Areas:

SAP Reference IMG > Financial Accounting > Asset Accounting > Asset Data Transfer >

Specify Sequence of Depreciation Areas

In this field you define the order in which you wat to update depreciation areas with values

during legacy data transfer. You determine this sequence by entering a relative number in this

field.

During the transfer of legacy data, the first depreciation area to be transferred is generally the

book depreciation area.

In this step, the sequence of the depreciation areas for the data takeover transaction is specified.

If there are additional depreciation areas for local / fiscal purposes, the sequence for the

depreciation areas may be impacted.

Specify Transfer Date/Last Closed Fiscal Year:


Parameters for Data Transfer > Date Specifications > Specify Transfer Date/Last Closed Fiscal

Year Status

In this step, the asset transfer date for conversions is specified. This setting is maintained in each

client to facilitate test conversion activities.

This configuration is mostly maintained directly in each client. You have to enter this date before

starting the asset data transfer. In most cases, the transfer date will be the last day of a fiscal year.

All transactions starting in the new fiscal year are then carried out only in SAP Asset

Accounting. The values transferred are the cumulative values at the end of the fiscal year.

The transfer date can also be during the fiscal year. When the transfer date is within the fiscal

year, the values transferred are the values as they stand at the end of the last closed fiscal year

before the transfer date. The transactions since the start of the current fiscal year, however, also

have to be transferred. This is necessary in order to create the asset history sheet.

This field is only ready for input if the company code is not yet live. The system uses this date to

determine the last closed fiscal year.

Specify Last Period Posted in Prv. System (Transf. During FY):


Parameters for Data Transfer > Date Specifications > Specify Last Period Posted in Prv. System

(Transf. During FY)

The following step is only necessary if you want to perform an old assets data takeover during

the fiscal year. In this case, you must specify the period up to which depreciation was posted in

the previous system. This period refers to the posted depreciation that is to be transferred during

old assets data takeover.

In this field, the system enters the period, for which depreciation was last posted. If the legacy

data transfer is carried out during the fiscal year, you must update this field manually.

This field is not available for input if there is no legacy data transfer during the fiscal year, or if

depreciation is not posted in this depreciation area.

If the asset takeover date is during a fiscal year, e.g. 31.03.2006, then the last period in which

depreciation postings were made in the legacy system must be specified. This setting is

maintained in each client.

This configuration is maintained directly in each client.

Transfer Foreign Currency Areas:


Options > Transfer Foreign Currency Areas.

You only need to carry out this step if you manage depreciation areas in foreign currencies.

In this step, you determine that foreign currency areas can receive values during old assets data

takeover. Then the depreciation areas are not supplied with values from another area by the

system, although they are defined as dependent areas by the Customizing settings. This

specification can only be made for areas that are managed in foreign currency.

Using this indicator, you specify that you will provide values for the foreign currency area during

the legacy data transfer. The system then does not provide values itself for the area (by taking

over values from another area, with no changes allowed) as it normally would.

You can only make an entry in this field for an area which is managed in foreign currency.

For any Depreciation area with foregin currency values fixed at the Group Rate as at the takeover

date, the takeover values for this depreciation area is calculated manually/automation tool.

Please note that if any change to depreciation area sequence is undertaken, that the manually

input flag will change position and will require updating.

Recalculate Deprecation for Previous Years:


Parameters for Data Transfer > Options > Recalculate Depreciation for Previous Years

Set this indicator if you want the system to newly calculate accumulated depreciation from past

ears during the legacy asset data transfer.

You can recalculate the accumulated depreciation from the past, based on SAP depreciation

rules, when a depreciation area is newly entered the values from a depreciation area should be

recalculated in the R/3 system.for example, conversion data is not available for this depreciation

area for these assets

This recalculation is based on the condition that the acquisition value was acquired completely at

the time of capitalization. However, for the book depreciation area, this is only possible in

company codes that are still in test mode.

You can also recalculate accumulated past depreciation for individual assets using the transaction

"change old assets" (Function: recalculate values) after the takeover of data from your previous

system.

Set Reconciliation Accounts (Manually) :

SAP Reference IMG > Financial Accounting > Asset Accounting > Preparing for Production

Startup > Set Reconciliation Accounts - TCODE: OAMK (OAK5 - for automatically set)

This step is required for conversion purposes. Carried out directly in client during cutover. By

default the relevant GL accounts will have been created as reconciliation accounts. As part of the

conversion, the flag is removed from the GL accounts per asset class per company code. After

the balances have been loaded, the reconciliation flag is reset. OAMK allows this to be carried

out manually. Once they are set as reconciliation accounts, the system will only post to them via

Asset Accounting from this point onwards. This is maintainable in each client except production

where this step is managed by the cutover strategy.

New GL : Company Code Validation vs Real Time

COFI Integration- What is the relation ???

Recently I came across an issue in New GL wherein I have to understand the relation between ,

Real time COFI integration and Company code validation. If you opt for Company code

validation then only you can activate and assign Real time COFI integration, otherwise NO.

In this blog, I want to analyse the logic behind the relation and justify SAP's error message.

Before proceeding to the analysis, take a look at the scenario and the error message.

Company code is “Productive”.

Company code validation is not checked in OKKP against controlling area ( Fig-1 )

Fig-1 : Activate / deactivation of Company code validation

3. You want to activate and assign the Real time integration variant to one of the

company code under the controlling area.( Fig-2)

Fig 2 : Assignment of COFI realtime integration variant

4. And the error message : ( Fig-3)

http://scn.sap.com/people/sivaprasad.r/blog/2008/12/12/new-gl-company-code-validation-vs-real-time-cofi-integration-what-is-the-relation

http://scn.sap.com/people/sivaprasad.r/blog/2008/12/12/new-gl-company-code-validation-vs-real-time-cofi-integration-what-is-the-relation

http://scn.sap.com/servlet/JiveServlet/showImage/38-48382-57073/Compcodevalidation.JPG

http://scn.sap.com/servlet/JiveServlet/showImage/38-48382-57074/COFIvariantassignment.JPG

http://scn.sap.com/servlet/JiveServlet/showImage/38-48382-57073/Compcodevalidation.JPG

http://scn.sap.com/servlet/JiveServlet/showImage/38-48382-57074/COFIvariantassignment.JPG

Fig-3 : Error message while assigning the Variant

Fig -4 : Error message full text

Company code validation means, in the same document , all the objects must belong to the same

company code. i.e in one document , you cannot input objects say cost centre belonging to 2

company codes.

WHY : Business Process : Salary GL ( P& L account ) is originally charged to Cost center

0001 ( Company code-0001) , but it should be reposted to Cost center 0002 ( Company code

0002).

Scenario 1 : Transfer postings ( repostings ) happens from FI route

There should be NO company code validation , because in the same document you want

to input 2 cost centers belonging to 2 different comp codes.

Posting in Company code 0001

Gl Cost centre Amt

Debit : Salary GL 0002 200 ( belongs to Co code- 0002)

Credit : Salary GL 0001 200 ( belongs to Co code- 0001)

http://scn.sap.com/servlet/JiveServlet/showImage/38-48382-57075/Error-brief.JPG

http://scn.sap.com/servlet/JiveServlet/showImage/38-48382-57076/Error-Full.JPG

http://scn.sap.com/servlet/JiveServlet/showImage/38-48382-57075/Error-brief.JPG

http://scn.sap.com/servlet/JiveServlet/showImage/38-48382-57076/Error-Full.JPG

With this FI posting, the 2 actual entries will be triggered as below (Through automatic inter

company account determination settings) :

Company code-0001

Debit : Inter company GL 200

Credit : Salary GL 0001 200

( Note that the CO posting will be posted now accordingly)

Company code-0002

Debit : Salary GL 0002 200

Credit : Inter company GL 200

(Note that the CO posting will be posted now accordingly)

Conclusion : The CO entries are already passed by system. SO there is no need for any CO FI

integration, therefore, COFI integration variant is not allowed. If it is allowed, the system may

trigger( amounts to duplication.. so wrong ) the FI documents again from CO documents.

Scenario 2 : Transfer postings ( repostings ) happens from CO route

In this case, you activate the Company code validation, so FI route ( Scenario-1) cannot be

followed . You use reposting functionality in CO wherein you transfer the amount from Cost

center 0001 to 0002. But to give effect in FI, Realtime COFI integration variant must be

assigned to the Company code to keep the CO and FI books duly reconciled.

TO SUMMARISE,

1. If you follow FI route to transfer the postings across company codes ( for example) don‟t

activate company code validation and justifiably, system will not allow you to assign Real time

COFI integration variant to the Company code.

2. If you follow CO route, activate the company code validation and system will allow you to

assign the COFI integration variant to the company code

http://sap-f2.blogspot.in/2010/12/sap

http://sap-f2.blogspot.in/2010/12/sap