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 want 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: 

 

SAP Reference IMG > Financial Accounting > Asset Accounting > Asset Data Transfer > 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):

 

SAP Reference IMG > Financial Accounting > Asset Accounting > Asset Data Transfer > 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: 

 

SAP Reference IMG > Financial Accounting > Asset Accounting > Asset Data Transfer > 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: 

 

SAP Reference IMG > Financial Accounting > Asset Accounting > Asset Data Transfer > 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 years 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.

SAP: HOW TO CHECK THE USER STATUS IN THE TABLE

Defined User Status details are stored in the Table: ENT5854. You can
see the number of status details for one status profile. These details
may differ from client to client. Also differs from one status profile
to another. Against each status(ENT5854-TXT04) you can see the
technical status(ENT5854-ESTAT) details. Here the technical status
(ENT5854-ESTAT) is the main reference to check details further.

In the Table: VICN01, for every RE-Contract (VICN01- RECNNR) you can
see the Object number (VICN01- RECNOBJNR).

Now, use the same object number in the Table: JEST in the Object
number (JEST- OBJNR) field and execute for the entries. Now you can
see multiple entries in the output. For one object number you can see
multiple entries.

To get the latest status relating to the object (JEST-OBJNR), check
the particular entry, which is with 'active' status (JEST-INACT) and
with the latest 'change number' (JEST-CHGNR).

This status check procedure is same even in case of Rental Object,
Internal Order, WBS Element, etc.,

Always user status starts with 'E0001'and system status starts with
'I0001'. Logic to check the status is also same i.e., active status
having the latest change number.

SAP COPA - KES1 Maintain Charcterstict Values - ABAP Dump

IF you get abap dump in KES1 –characteristic values.

Run the Program :

 

1 Goto transaction SE38->Give the program RKEAGENV and execute without test run. Maybe you face problem in KES1.

 

2 Goto transaction KEA0-> change -> activate and than generate operating concern.

 

Still not Solved implement OSS Note - 64490 and 942785

 

If you get an error executing transaction KES1 (V17 installation step Maintain Characteristic Values), install SAP notes 64490 and 942785. After you have executed report RKEAGENV as described in notes mentioned above, reactivate the operating concern (tcode KEA0, Tab Environment, cross-client and client-specific part).

 

Also check the below links:

 

Refer to the link - http://help.sap.com/bp_bblibrary/600/Documentation/E00_BB_InstallGuide_EN_DE.doc

 

Reference:
http://help.sap.com/bp_bblibrary/600/Documentation/BL_QuickGuide_EN_US.doc

SAP: COPA: Defining new characteristics

You can also manually define new characteristics that you only want to use in Profitability Analysis. Since these characteristics have no table of origin, their values are not automatically derived from other characteristics. You therefore need to define derivation steps for them. The name of new characteristics must begin with "WW" and consist of 4 or 5 characters. Depending on the desired attributes, you must choose one of the following variants:

With own value maintenance - In most cases, you will define new characteristics with their own value maintenance. In this case, the system creates a check table and text table. In the Customizing activity Maintain characteristic values , you can then enter characteristic values and texts for these. Only those values maintained here are permitted values for that characteristic.

Without value maintenance - This option lets you define characteristics with no check table. This means that there is no set of allowed characteristic values and texts. Consequently, no validity check takes place for values of these characteristics. These characteristics cannot be used as receiver characteristics for period-based allocations.

With reference to existing values - This type of characteristic is only required in special cases. Here you assign the characteristic to a data element that already exists in the system. The characteristic takes on the attributes of that data element (texts, length, check table, text table).

source: help.sap

SAP COPA: Deleting Characteristics/ Value Fields from an Operating Concern

You can delete characteristics and value fields retrospectively from an operating concern that you have already activated. However, you should only use this deletion function for operating concerns that have not yet been used productively. You should also note that some database systems require the operating concern tables to be converted (database conversion) after the deletion has taken place if data had already been posted to the operating concern. Depending on the data volumes involved, the database conversion can take a matter of seconds or indeed several hours. Moreover, you cannot post data or run reports during the conversion. Due to integration, other applications are also affected when data is postedwith an assignment to profitability segments (such as settlement and direct assignment from FI/MM). If the operating concern has been transported to another system (such as the productive system), then the database conversion must also occur in that target system.

To delete characteristics or value fields, perform the following activities:

1. Delete the corresponding characteristics and value fields from Customizing in all clients (this includes forms, reports, planning layouts, and so forth). To locate characteristics and value fields, use the appropriate where-used list in the Customizing Monitor . You can access it by choosing Tools -> Analysis -> Check Customizing Settings. You can jump directly from the where-used list to the relevant Customizing transaction and then delete the appropriate field there.

2. Switch to the screen for maintaining the data structure of an operating concern (Maintain operating concern).

3. If you need to effect other changes to the datastucture for the operating concern before making any deletions, effect those changes and save the data structure.

4. In order to be able to select the fields of the data structure, choose Extras -> Characteristics (or Value fields) -> Unlock.

5. Select the characteristics and value fields to be deleted and remove them from the data structure with the "Reset fields" function.

6. Reactivate the operating concern. The system starts by checking whether the operating concern contains any data and whether the fields to be deleted are still being used in any Customizing settings.

7. If none of the fields are still in use, the system then starts the re-activation. If the operating concern does not contain any data or does not require the database system to be converted, the tables are activated. You are then able to activate the environment for the operating concern. In this case, the following activities no longer apply.

If the operating concern already contains data, a system message tells you that the database needs to be converted. If you proceed, an activation log appears (at the top of the list).

8. Analyze the activation log. If it only contains error messages telling you to convert the tables, proceed with the next activity.

You must otherwise remove the cause of the errors before the tables can be converted. In this case, you should answer "No" to the next prompt, which asks whether the conversion transaction should start.

9. If you still only receive error messages telling you to convert the tables, choose "Back" and start the conversion.

10. Plan a job for the conversion. A list of the tables to be converted is shown for this. If the tables only contain a small amount of data (less than 10 000 records), then all the tables can be converted in one job. In that case, you can select all the tables.

For larger tables, conversion should take place in several jobs. However, you should ensure that table CE4xxxx (where xxxx = operating concern) is the last table to be converted.

Warning. No other changes can be made to the operating concern during the conversion.

A copy of the table is generated during the conversion. The database system should have sufficient memory available for this copy.
To schedule conversion as a job, use the "Schedule selections" function. You can display the current status of the conversion by selecting the "Refresh" icon. Tables disappear from the list once they have been converted sucessfully. If a conversion is taking a while, it is also possible to leave the transaction. You can then continue the conversion using DB requests -> Mass processing in one of the following ways:

With the job overview. You access this by choosing System -> Services -> Jobs.

Using the database utility transaction. You access this by choosing Utilities -> Database Utility in the ABAP Dictionary menu.

You can use the status function to call up the status of the operating concern during operating concern maintenance. You need to activate all tables after conversion.

11. To analyze errors that have occurred during the conversion, you can use the database utility transaction by choosing Extras -> Logs. The log has the same name as the conversion job: TBATG-date. You can also restart the conversion with this transaction.
For more information on the database utility, choose Help -> Application help while still in the above transaction.

12. Once you have activated all the tables in the operating concern, generate the operating concern environment from within operating concern maintenance.

You can then use the operating concern again.

SAP: COPA :Tables

When you activate the data structures of your operating concern, the system creates the following objects in the ABAP Dictionary.

 

Type	Name	Description
Structure	CE0xxxx	logical line item structure
Table	CE1xxxx	actual line item table
Table	CE2xxxx	plan line item table
Table	CE3xxxx	segment level
Table	CE4xxxx	segment table
Table	CE4xxxx_KENC	realignments
Table	CE4xxxx_ACCT	account assignments
Table	CE4xxxx_FLAG	posted characteristics
Structure	CE5xxxx	logical segment level
Structure	CE7xxxx	internal help structure for assessments
Structure	CE8xxxx	internal help structure for assessments

ABAA - AFAR : Unplanned Depreciation - Recalculation of Depreciation

ABAA - Unplanned Depreciation

 

There is an unexpected permanent reduction in the worth of the asset that you have to post as unplanned depreciation.

 

As a rule, the system automatically determines the planned depreciation for the current fiscal year by means of the depreciation keys entered in the master record. If you need to specifically set the amount of depreciation, the system offers a manual unplanned depreciation forecasting option. This means you can manually increase the planned values managed for the asset.The G/L accounts in Financial Accounting are not initially affected by this posting transaction. Asset line items are created, but no FI posting documents. The general ledger accounts are updated and the corresponding FI documents are created by the periodic depreciation posting run. The system then determines the depreciation to be posted up to a specific period, and creates the accompanying posting documents.

 

Transaction type - 640 : Unplanned depreciation on prior year acquistions

 

During posting system automatically calcualtes the depreciation in different amounts for different depreciation areas.

 

After posting you can see the same in AW01N in Planned values section under 'change' column against Unplanned depreciation

 

AFAR - Recalculation of Depreciation

 

This might be necessary if:

 

· You have changed depreciation keys.

· You have made mass changes that you programmed yourself, and these changes affected data relevant to depreciation.

· You want to calculate subsequent revaluation (after the legacy data transfer is closed) using current index figures. In order to correctly calculate replacement values, however, you can only use index series that calculate historically.

 

This program enables you to recalculate planned annual depreciation using the depreciation terms that are valid at the time that you start the report. You can also run the report in test mode. However, you can only recalculate planned depreciation for fiscal years that are still open. After the system recalculates the planned annual depreciation, it creates a statistical log with the total number of assets processed and the number of assets with errors. You can check the assets with errors using the asset value display transaction.
 

SAP: Transfer of Legacy Asset Data Methods

How is depreciation entered during old assets data takeover?

 

Answer:

 

Asset Accounting always manages the values related to the fiscal year.

Depreciation values for previous fiscal years are always entered as cumulative values.

 

Estimated annual depreciation values for the current fiscal year with an old assets data takeover during the fiscal year cannot be entered because they are calculated automatically by the system. Differences from the estimated annual depreciations can therefore only be adjusted as manual value corrections, that is, by entering an asset transaction.

However, if you use a a depreciation key which does not automatically calculate the depreciation, for example depreciation key MANU, the manual depreciation must be entered during the transfer with a 6xx transaction type.

 

If depreciations have already been posted for the takeover year in the legacy system, these values must also be entered into the SAP System sothat they can be used by the posting program.

 

Source: OSS 50607

 

What are the legacy data transfer methods available in Asset Accounting and how are they different?

 

Answer:

 

The following is an overview of the legacy data transfer methods with additional information on the transferring legacy assets R/3 library.

 

1. Manual transfer with Transaction AS91 - This works with Transaction AS01 and is suitable for transferring smaller datasets.

 

2. RAALTD01 transfer via batch input - This is suitable for the mass processing of larger datasets. The batch input session fills the fields of Transaction AS91 up to and including Release 4.0B or of Transaction AT91 for subsequent R/3 releases. Therefore, only the data fields of these transactions can be filled.

 

3. RAALTD11 Transfer via direct input - This is suitable for transferring very large datasets. It transfers the same fields as RAALTD01 does, however it only carries out limited field checks. So that you do not receive any incorrect datasets as a result, first test at random the assets to be transferred in AS91 or as of Release 4.5B with Transaction AT91.

 

Furthermore, bear in mind that value fields are not converted. If, for example you specify a value field for an amount of money in euro in the BALTD-structure, you must consider the format. If, for example the value field has the format ###,## and you only enter 10 as a value, this value is interpreted as 0,10. Therefore you must specify 10,00 as value in BALTD.

 

To achieve the high performance of RAALTD11, the writing of change documents was also dropped. When you go into the change document display of an asset that was created with this report, the system generates the message "Asset created with Transaction AS02" or " ... AS92" by mistake.

 

Both RAALTD01 and RAALTD11 have not been enhanced since Release 4.5B.As of Release 4.6B, the legacy data transfer therefore is recommended via BAPI BAPI_FIXEDASSET_OVRTAKE_CREATE since this offers all of the transfer options of the new Transaction AS91 (as of Release 4.5B).

 

The following methods use this BAPI.

 

1. Transaction AS100 data transfer with Microsoft Excel - This is suitable for the transfer of smaller datasets (limited by the line count of your Excel version). This transaction is suitable in particular if you have mapped your Asset Accounting prior to R/3 using Microsoft Excel. However, you can create only main asset numbers. More restrictions are described in Note 303710.

 

2. Transfers via Workbench LSMW or SXDA - BAPI_FIXEDASSET_OVRTAKE_CREATE is used by Business Object Method BUS1022->Create Incl Values, message type FIXEDASSET_CREATEINCLVALUES and IDoc type FIXEDASSET_CREATEINCLVALUES01.You can also call it for the legacy data transfer even from your own program. You can find more information in the documentation of the function module in Transaction BAPI.

IFRS: The Right Next Step for US Business

Overview

International Financial Reporting Standards (IFRS) is the framework used by most publicly traded companies in the world today to report their financial results. With support from important constituencies, the Securities and Exchange Commission (SEC) and the Financial Accounting Standards Board (FASB) have taken first steps toward a transition to IFRS from the accounting and reporting framework currently in place in the US. Is the US really going to set aside US generally accepted accounting principles (US GAAP)? The answer is almost certainly yes. As this white paper shows, within a few years the SEC is likely to designate a date for mandatory adoption of IFRS by all US public companies.

 

Read Full Story --> Click HERE

 

source: sdn. sap. com

Author: pwc

Data Processing Using ABAP code in LSMW

Data Processing Using ABAP code in LSMW

Before heading towards where and how we can process data using ABAP code I will explain in brief about data migration steps and where LSMW fits in it. Sounds boring, isn't it!!!

 But will be helpful to those who are new to data migration and LSMW.

Let's start!!!!!

Data Migration

It's a process to transfer data from Legacy System to SAP.

Data Migration Steps

 - Analyze the data to be Migrated
 - Create field mapping for legacy to SAP fields
 - Extract the Legacy data
 - Transform the Legacy data to SAP format
 - Load Transformed data to SAP
 - Validate the Data Loaded. 

Read Full Story here 

Author:Vijay Sharma
source:sdn. sap. com

SAP : Business Transaction Events (BTE)

Business transaction events:BTE is Customer Enhancements. It defines the standard interface, how the  communication is done to/from external system to SAP.
 
There are two types of interface available

1. Publish & Subscribe interfaces (also called "informing interfaces")
2. Process interfaces (also referred to as "process" in the following)

Publish & Subscribe interfaces:     These will inform you about particular events (such as a document   being entered) in the SAP standard application and make the data    generated as a result available to the external software.

 

Examples of such events in the R/3 System are:

 

-   Master record was created, changed, or blocked

-   Document was entered, parked, changed, or reversed

-   Items were cleared or reset

 

Process interfaces: Process interfaces are used to submit business processes to a different control which cannot be realized with the standard system,  that is process interfaces replace standard processes. It is possible   to connect different external developments to the standard R/3   System. The additional developments are generally carried out using the ABAP/4 Development Workbench.

 

Click here for full story

SAP ECC 6.0: New GL : Cross Company-Code Invoice Posting - Configuration

Configuration Path: IMG-> Financial accounting (New) -> General ledger accounting new -> Business transactions -> Document splitting -> Extended document splitting

1 Define Document splitting Rule
2. Assign business/transaction Variant to rule

3. Define Business transactions variants

There are two entries in customizing for Company Code Clearing lines.

A) One for the Company Code that does not contain leading item and

B) One for the Company Code that includes leading item.  

Click here for the Screens and the posting

Refer OSS Note: 1085921 - Document split

author: Cora Phelan

source: sdn. sap. com

SAP FI: Down Payment - Advance Payment

1. What is "down payment"? 

 

Down payment is the  Received/Paid amount before actual handing  over the Goods .

2. The main contents of the down payment:

(1)  Down payment is processed when the commodity buying and selling is promised, and the amount received/Paid before the commodity is handed over.

(2) The down payment happens in a debt or Credit side before the commodity is handed over .

(3)  after  the commodity is handed over, the down payment happened in debt/Credit could be deducted with  accounts receivable/Payable.

3. In SAP "special G/L indicator" is used for handling the down payment posting. 

 

What is special G/L indicator?  -> For distinguishing the down payment and accounts receivable of the same customer: The "special G/L indicator" is used.
    

In SAP standard , Special G/L indicator : "A" is used for  for Down payment.

 

Customizing: TCODE:FBKP->special G/L button->example: selecting "Acct Type"  :  " D " and "SGL Ind." : "A"->Maintain reconciliation account and special G/L account (the reconciliation account will be replaced by special G/L account when "A" is used for posting down payment line items) , by pressing properties button-> "Special G/L transaction types" could be set.

 

4. standard  scenarios for customer down payment in SAP R/3 system for down payment processing:   

 

(1)  Down Payment Request (T-cd:F-37) with special G/L indicator : "A" -> it is only a note, a line item.

(2) Create down paymet n in F-29 with special G/L indicator : "A" in T-cd:F-29. Within this step, the down payment could be cleared.

(3) Create account reveivable in T-cd:FB70( customer open line items is posted).

(4) Clear the down payment created in step(2)withinv customer open item created in step(3)  in T-cd:F-39.

 

Normally the partial amount in customer Open items is cleared with down payment( down payment amount <= amount in customer open item)

 

(5) Clearing the account receivable in F-28(clearing the left part amount in customer open line items)

 

For example:

(1)For down payment request, no transaction is happened, so no really document with debit/credit lines generated. 

(2) creatr down payment    :                     Bank ￥10,000 　/ down payment  ￥10,000  

(3) create customer open line item :      account Reveivable　￥15,000 　/ Revenue  ￥15,000 

(4) clear down payment     :                       Down payment　￥10,000　/ Receivcable　￥10,000

(5) clear the customer open line item :  Bank ￥5,000　/ 　Receivable   ￥5,000

SAP :EC-CS Data Upload Methods

Introduction to Consolidation (EC-CS):

Consolidation (ECCS) is a part of FI sub-module which is used for consolidation  of various company codes to extract the final financial position of the companies as a whole.

The consolidation is done mostly at 3 levels:

1.Statutory Consolidation - This is the consolidation carried out based on the company as the primary unit (Consolidation unit)
2.Profit Centre Consolidation - This is the consolidation carried out based on the profit centre as the primary unit (Consolidation unit)
3.Business Area Consolidation - This is the consolidation carried out based on the Business Area as the primary unit (Consolidation unit)
4. User Defined - This is done as per the requirement of the business, where it requires any other consolidation.
Data Collection in Consolidation: The data collection plays a crucial role in the consolidation process, basically consolidation units are grouped in to Consolidation groups depending up on the requirement of reporting to the business. The feed for the reports come from the data that is provided in various forms to consolidation.

Data Collection methods:

The data that is used in consolidation is not directly posted in to ECCS module; the data is extracted based up on the consolidation dimension or method used say statutory consolidation dimension, profit centre consolidation dimension or any other dimension as configured in the system.

The various methods of data collection are:-

1. Online data entry
2. Flexible upload
3. Real time update
4. Periodic extract
5. Rollup
6. Offline data entry

 

 

1.Online data Entry : Using the data monitor, you enter financial data online which was reported by those consolidation units for which you specified this data transfer method. You enter the data in data entry layouts. Data entry layouts are used for entering reported financial data both online in the SAP System and offline on the basis of MS ACCESS. You can use various layouts, depending on the type of data to be entered and the level of detail involved.

2.Flexible Upload: Option for importing both the master data (consolidation units and groups, chart of accounts, etc.) and the reported data from a text file.

 

3.Real time Update: The data entry method that is used  in real time update is to update the consolidation with a document, when ever a posting is done in to FI or Sales invoice, i.e., when ever a document is posted in to SAP, the configuration is done in such a way that the document will even generate a consolidation document.

4.Periodic Extract:  The data entry method that is used here is a on line data method, we decide in advance what data method we are going to input in to the consolidation unit, say either cumulative or periodically, if we use cumulative method we update the total cumulative postings as one document for a particular posting date and if we use periodically all the totals of a period is uploaded to a consolidation unit.

5.Rollup : The data entry method we use in Rollup method is to collect the data periodically say monthly by running the data monitor & consolidation monitor and pull the data to consolidation, this method is particularly used in profit centre consolidation, were we use the rollup monthly and once at year end to accumulate the data which is existing in various units (profit centre's) and pull the balances of totals to consolidation process.

 

6.Offline Data Entry: Decentralized data entry and processing of individual financial data is possible with MS Access. Master data are downloaded from a central R/3 system. After creation of the reported data, it is uploaded with a special method of the flexible upload.
 

Conclusion: The data entry method plays a crucial role in consolidation, as the data that we process to get final reports at the consolidation are extracted from already posted balances in FI (company code & business area) & Co (profit centre), the data is statistical data which is pulled and accumulated in the sub- ledger where from we configure the system to pull final financial reports.

 

author: Satish Puram

source: SAP Community Network

SAP ECC 6.0: Asset & NEW GL Integration

From the AC210 course you will see that  the new entities within New general ledger accouning such as the profit center/segment cannot be directly assigned to assets in asset master data. Therefore it has to be derived from cost center or order that is linked to asset. This is maintained in the time-dependent data of the asset.

 

 

Click here for full story.

 

 

author: Cora Phelan

source: sdn. sap. com

SAP : Using USER EXIT For FI SUBSTITUTION

Substitutions can be used for validating data at the time of entry in SAP system. This wiki can be used for creating custom user exits so that one can set his validations & conditions. User exits are user defined FORM routines that are used to calculate/replace values with in a substitution .I have shown demo for FI but same steps with some minor modifications can be used for other areas too.

What are substitutions?

Whenever a data is entered in a system, validations are invoked to check  its integrity .Once validations are done, one can substitute the entered value with some other value. This gives you the opportunity of having the system validate values that are to be substituted. A substitution value can be numeric or a string. The system first performs some validations and then substitutions.

Transactions used for substitutions are :                   

GGB1 :  Substitutions  maintenance.                                                                                                                                

OBBH :  Activation of FI substitutions.

Substitutions can be performed using three ways:

1.Constant values.

2.Field -Field assignment.

3.User exits.

Steps for creating user exits for substitutions....click here for fully story

Author: Rajneesh
Source: sdn. sap. com

SAP : Cash Flow Reports : Direct / Indirect Method Config Settings

TCODE' for the Cash Flow Reports are as below :

S_ALR_87012271       Cash Flow (Direct Method)
S_ALR_87012272       Cash Flow (Indirect Method) Variant 1
S_ALR_87012273       Cash Flow (Indirect Method) Variant 2

 

Below are the details of the Form' used in the above reports:

 

Form 0SAPRATIO-04 Cash flow (Direct Method)
Form 0SAPRATIO-03 Cash flow (Indirect Method) variant 1
Form 0SAPRATIO-01 Cash flow (Indirect Method) variant 2

 

Use the TCODE: FSI6 to view the above form.

 

Above given Forms used in the below given reports

 

Report 0SAPRATIO-04 Cash flow (Direct Method)
Report 0SAPRATIO-03 Cash flow (Indirect Method) variant 1
Report 0SAPRATIO-01 Cash flow (Indirect Method) variant 2

 

Use the TCODE: FSI3 to view the above reports.

 

You should know what format you would like to see in the cash flow statement.

 

You should use the FS items accordingly copy the standard forms and changed according to your format. You should be conversant enough to do basic report painter.

 

Go to the Form 0SAPRATIO-01

 

Go to the form menu > click on change.

Go to edit menu, select general data selection / gen.data select .

There you assign your financial statement version (FSV) and confirm.

Then come to the form double click on each row and assign your respective financial statement version item and confirm.

And you change the rows as per your requirements.

Save the form.

Execute the report change the INT to your own Chart of Account.

 

Also make sure in the form you have assigned the FS items from your Financial Statement Version (OB58).

FS items are nothing but nodes in your FSV.

 

Use TCODE: FF7A for Cash Position reporting. You must activate Cash Management first, Go to TCODE: FDFD in configuration and activate the company code for cash management.

Understanding Results Analysis for WIP

Introduction and Configuration Guide

Work in process (WIP) inventory forms a part of the working capital or current assets of a firm appearing in their balance sheet. Work in process or progress  are  partially completed goods, parts, or subassemblies that are no longer part of the raw materials inventory and not yet part of the finished products inventory. Fundamental Principle of International Accounting Standard 2 states that Inventories are required to be stated at the lower of cost and net realisable value (NRV).  

 

The guidance on measurement of cost of inventories is that, cost should include all:

 a)     costs of purchase (including taxes, transport, and handling) net of trade discounts received
 b)     costs of conversion (including fixed and variable manufacturing overheads) and
 c)     other costs incurred in bringing the inventories to their present location and condition

With SAP, the raw materials gets transferred to finished goods via production orders or process order. In this process, typically, the production order is created to which raw materials are issued, all activities performed in the process are charged along with any overheads that is apporopriate the production order.  Production is ongoing, and it is quite natural that at month end, we end up with some open production orders. SAP in its product costing functionality, provides the feature to calculate the value of WIP. This will be derived based on the careful definition of Line IDs in line with the cost components. The WIP shall be the total debits cost in the order as reduced by the credits for goods receipt.

Key elements of WIP Results Analysis Configuration.
 
Step 1         Define Results Analysis Key OKG1.

Here you just give a name, four letter key with its description.

Step 2         Create cost elements of type 31 the following minimum

Valuated Actual cost, say for eg. 990001.
Calculated Costs, say 990002.
WIP account 990003
WIP Reserve 990004
WIP Reserve 990005
 
Step 3         Define RA version, OKG9, Enable Transfer to Financial Accounting (checkbox)

Under extended control, you may enable checkboxes relating to  

- Generate line items 
- Assignment/RAkey 
- Update/RAkeyEnter the cutoff period for actual RA/WIP, the effective date before which any WIP data if existed, will not be     altered.

Step 4         In OKGC, define the valuation method for WIP.

Here, you specify that WIP calculation mode is one when the order has the staus REL.

The calculated WIP shall be cancelled when the order status changes to DLV or TECO. You maintain this data for CO area, RA version and RA key combination.

Step 5        SPRO>Controlling>Product Cost Controlling>Cost Object Controlling>Product cost by order>Period End Closing>Work in process>Define Line IDs.

The line IDs are similar to cost component, that you create during cost estimates like a) 010 for Material b) 020 for Labor and c) 030 for Overhead to say the least.

Besides these, create one more line ID say 999 for the Settled Cost, which appear as credit when you make a goods receipt.
                 
Create additional WIP type 31 cost elements and their corresponding Reserve account for the above#### WIP Material 990006

WIP Material Reserve 990007
WIP Labor 990008
WIP Labor Reserve 990009
WIP Overhead 990010
WIP Overhead Reserve 990011  

Step 6        Now you assign the source cost elements OKGB, that are expected in the production order to various line ID as created above.

You maintain this data for CO area, RA version and RA key combination.  You use masking when you mention which cost element to be assigned to various IDs. You can also direct various cost element, if it comes with a combination of particular cost center and activity type  to a particular Line ID. If you need to keep it simple, just enter +++++++ for cost centers, activity types and Business processes. Cost elements can be masked as follows; for eg. All cost primray cost elements for materials, if they start from 210001 to 219999, the you can mask them like 00021+++++.   Give the line ID in the column Required to Capitailze.

 

Step 7       Define the update. OKGA You maintain this data for CO area, RA version and RA key combination.

Here you specify which line IDs are to be grouped under which cost elements and their reserve account. You connect the cost elements created in step 5 to the line IDs. The category for the line IDs for material, labor and overhead shall be K, that stand for cost. The line ID 999 settled cost shall be maintained as category A,  (settled cost). When you assign A, you won't have to maintain any cost elements for WIP and reserve creation.

 

Step 8       Define posting rules for WIP calculation OKG8

You do this for Controlling area, company code, RA version. Maintain this for RA category WIPR (WIP cost, Required to be capitalized) and RUCR (Reserve for unrealized cost).  You maintain the P& L account (changes to stock)  and the balance sheet (WIP)account.These G/L accounts are posted in Financial Accounting.

 

Step 9        Ensure number range assignment for the WIP transactions under appropriate head OKG6:
 

KABG Automat. WIP/results analysis
KABM Manual WIP/results analysis
KSWP Prim. Target Cost Calc. (WIP)
KSWS Sec. Target Cost Calc. (WIP)

 

Period end WIP calculation Process

The process of running WIP is the t-code KKAX for individual order processing  and KKAO for collective order processing. The system debits the WIP account and credits Inventory Change account. This entire WIP is reversed and a new entry is passed the following month. When the order is fully delivered no additional WIP entries are passed.

Note: The RA Key shall be entered in the production order, under the control tab. This can be defaulted through order type.

 

author: Sridhar Vasudevan

source: sdn.sap.com

 

 

Surviving a successful SAP GO-LIVE

I still remember the first time that I was a part of a SAP project that went live. We had toiled for seven months to get the Netherlands operation of a gas manufacturing company from an outdated HP legacy on to SAP. The day before the go-live saw us toil till 04:30 in the morning only to miss the opening address of the general manager over some cakes and beer. Yes the Dutch can drink beer at all hours of the day. The go-live was a rocking success but still we missed out on the free cans of beer that morning. So here is my list of things that enable companies to have a rocking go-live and not miss the beer party:

==>  Proper Governance: A lot of resource and money is spent on a SAP implementation. Without a proper governance model there is no accountability and the project would fall apart. Lots of time, the upper management is way too busy in running the business at hand and the implementation takes a backseat. A proper governance ensures that the vision of the management is percolated down to the lower levels and conflict resolutions are easier. Weekly meetings with status reports go a long way in making a success story of any implementation.

==>  Scoping: Most SAP projects have time and cost overruns because of improper scoping. A proper blueprinting of the business at hand and mapping the same to the solution available results in knowing the gaps that have to be bridged. Sometimes very little time is given to this whole process resulting in improper estimates and subsequent gaps being found that are critical for the business. As a result the scope keeps on creeping up and leads to an overall delay in the program. Proper documentation should be maintained about the scope and a process should be set up by the governance team about scope creeps. Best managed projects have minimum scope changes.

==>  Stakeholder communicaton: Many project disasters can be avoided by setting up proper communication channels. Often there are no clear cut communications from the project management team about the expectations from the business. In turn the business has no clues about what to expect out of SAP. Communication of weekly progress and targets for the next week play a pivotal role  Most SAP implementation service providers follow a global-delivery model where custom development (ABAP coding) is done at a different location. As a result there are a lot of bottlenecks in communication. Efforts should be made to ensure that there is proper communication of requirements resulting in near zero errors. During the stage of cutover and go-live effort must be made to have status meetings everyday which go a long way in giving confidence to the stakeholders.

==>  Involvement of business at all steps of the project: An SAP implementation is not only an IT software change. It involves a change in the approach of business and lots of processes need to be aligned to this new way of working. As a result, there should be involvement of the business at all steps straight from blueprinting till the go-live. Teams working in silos often face a problem because of unwillingness of the business to look for alternative ways of working at the last moment before the go-live. The involvement of business results in healthy discussions and subsequent realignment of business process becomes easier.

==> Not the onus of IT: Similar to the previous point, there should be a firm communication from the top management that the onus of implementing SAP is not only for the IT team but the whole business. This results in different ideas coming to the table and reduces conflicts during go-live.Business approvals at every stage: No SAP project can be achevied without custom developments. There are local business processes that need ABAP codes to be written for certain add on functionalities. Often the developments related to such gaps go completely untested till the point of user acceptance testing resulting in major defects that can be avoided by taking the business approval from a very early stage of development. The best way is to share unit testing and integration testing results with the business and seek their approvals before hand.

==> Ease of usage tools creation: A lot of SAP processes/ transactions are time consuming and hence business users are unwilling to let go of old processes. In one of our projects, rebate processing was being done through excel sheets. It was very difficult to convince the business users to use the standard SAP functionality to create rebates because of the sheer time required to create one rebate in SAP. Similar was the requirement for having a tool for faster upload of contracts into SAP. We managed to create such tools that have gone a long way towards the acceptance of the solution by the business users. Such tools are easy to create and give the users a confidence and saves their time.

==> Exhaustive training and hand holding pre and post go-live: Usually during any implementation, user trainings are completed in tight schedules. For a novice, learning all the transactions and nuances of SAP is not easy. This can only be acheived through exhaustive trainings and hand holding sessions pre and post go-live. Most of the issues that are encountered during any implementation is caused because of a lack of knowledge. After the go-live there should be a validation of the data going into the system by the implementation team to check for errors in transactions before they become disruptive.

==> Controlling data issues during user acceptance testing: During any user acceptance testing the majority of issues are related to wrong master data. Most of these issues can be avoided by putting in place checks and controls to make the master data proper for the testing. A lot of time and effort can be saved by this step. If this step seems to be very tedious, then a subset of the data should be analsyed for errors and this should be provided to the users for user acceptance testing.

==> Managing changes: Change management is very important to any organisation and especially so when taking a giant step like a SAP implementation. A lot of processes are bound to change and reactions to change are not always positive. To ease changes there should be proper hand holding for the users and giving them the broader picture of why such changes are necessary. Human nature avoids changes and in case of a SAP implementation people are also afraid of their job security. To get the best results the governing body should address change management issues with positive reasons.

==> Motivating and rewarding people: A SAP implementation is a very complex project and people need motivation to go ahead with the work at hand. Rewarding people who have worked towards change, arranging open forums and appreciating people for their committment towards the project goes a long way in making an SAP implementation successful.

==> Managing politics: Politics is one thing that can derail an implementation and hence the governing committee should take every possible action to eliminate the politics. Hidden agendas should be brought out in open through transparent communication.

Author: ainindra

Source: sdn. sap. com

SAP FICO: SPL - Variable field movements in FI

Sometimes we need to modify standard SAP transactions in FI for field movements . This blog is intended to provide a step by procedure of user exit creation for this field movement to occur instead of modifying standard SAP programs with an example scenario.

Example Business Scenario Company A has created a special purpose ledger (ZZHYP say) would like to populate 4 digit trading partner(VBUND) in the special purpose ledger  .The field will only be used for reporting and is only needed in the Special Purpose Ledger. But the available data or the current values are present in 3 digits only. So Company A would like to change the entire 4 digit trading partner populated from FI to 3 digit trading partner in the special purpose ledger.  

For this purpose, a standard sap modification has to be done, but SAP allows you to enhance FI/CO features without modifying the standard code which are often collectively referred to as "user exits," SAP Enhancements are used to expand the standard functionality within SAP. Enhancements use function modules and are called from the standard SAP code. Each module in the system has a set of delivered enhancements that help companies expand the standard functionality where they need it. So here we create a Z program to insert our code for changes that has to be done and customize it. Hence when the data flows from FI to SPL, it will pass through the user exit that we have created to get the required result.

To accomplish this requirement, Company A will use the Variable Field Movement User Exit.

 

Read full story here

 

Author: Ramya

Source: sdn. sap. com

IFRS Adoption In Consolidated Statements

This first series of four blogs is dedicated to handling IFRS adoption for consolidated statements. They provide an overview of a new SAP "How-to guide" called "IFRS adoption in consolidated statements using SAP® BusinessObjects^TM Financial Consolidation, starter kit for IFRS". The objective is to bring practical guidance to end-users in order to manage successfully all the issues raised by the adoption of IFRSs and to get the maximum benefit from SAP® BusinessObjects^TM Financial Consolidation.

 

The blogs will cover: 

• Blog #1: Approaches in IFRS adoption
• Blog #2: Operating issues to deal with in financial reporting systems.
• Blog #3: How to face the challenge - The starter kit for IFRS as a starting point - this blog
• Blog #4: How to face the challenge - Key implementation templates

In the previous blogs (1 and 2), the retrospective method was described, along with the main issues to handle in financial reporting systems. We will now focus on the solutions proposed by SAP.

 

Continue here for full story

 

Author: Jean-Francois Bouillon

Source: sdn.sap.com

Non-Deductible Tax in Procurement

The detailed explanations regarding Taxes in purchasing are recorded in below SAP notes:

501054     FAQ: Taxes in purchasing
214151     Tax processing in purchasing

Let us review the customizings and have an example of non-deductible tax in procurement process. The simple example is procurement of non-stock material.

 

Click here for full story

 

Author: Jimmy Zhnag

Source: sdn.sap.com

TCodes F110 and FBZ0 - Segregation of Duty Fix

Generally Tcode F110 is a potential SoD risk. F110 combined with FBZ0 creates numerous SoD violations. Let's discuss what is exactly the risks are and how to avoid it.

F110 - Automatic Payment Transactions : Status
FBZ0 - Payment Proposal

Through F110, we can do two activities i.e. Payment Run and Payment Proposals.
(While running payment proposal it asks for FBZ0 access at the background, that is why I have combined both of the transactions while describing it)

Now the risk is that payment run and payment proposals should not be given to the same person who will access F110 because of SoD violation.

To remove this SoD risk, we need to play around some authorization objects i.e. F_REGU_BUK and F_REGU_KOA.

These authorization objects contain some activities which are given as numbers inside the role.

The meaning of those numbers are provided below.

02 Edit parameters
03 Display parameters
11 Execute proposal
12 Edit proposal
13 Display proposal
14 Delete proposal
15 Create payment medium proposal
21 Execute payment run
23 Display payment run
24 Delete payment run payment data
25 Create payment media of payment run
26 Delete payment orders of payment run
31 Print payment medium manually

To make payment run and payment proposal mutually exclusive, we need to restrict the activities accordingly.

So one role should not contain 11, 12, 13, 14 and 15 and the other role should not contain 21, 23, 24, 25, 26 and 31.

Restricting the authorization objects with above activities we can remove the potential SoD risk easily.

 

Author: Sambit

Source: sdn.sap.com

How to configure valuated project stock?

Introduction: 

Today many industries want to manage project stock in quantity and value basis.In this blog we are going to discuss the attibutes of valuated project stock and the configuration steps

valuated Project stock:

Project stock for which each material in the stock is always managed quantity-based and value-based.Each material quantity is valuated with monetary valuation.All goods movements for the project stock lead to corresponding postings to G/L accounts in Accounting.

 

Click here for full story

 

Author: Raja Ramaswamy

Source: sdn.sap.com

Restriction of Maximum 999 FI Document Items During MM transactions

I guess you might have this experience. While entering a goods receipt (MM-IM) through transaction MIGO, there is the error message: F5727 "Maximum number of items in FI reached".

 

There is a limit of (999) line items which can be posted per FI document.  This is because the line item number (BSEG-BUZEI) field length is defined as (3) numeric positions, i.e., (999) line items.

 

Click here for full story

 

Author: Jimmy Zhang

Source: sdn.sap.com