No Depreciation for a period of time

No depreciation for a period of time
If you have an asset which would not be used for production purposes for next six months as the plant is being closed.

Therefore you don't want to retire the asset and neither do you want depreciation to be carried out during these six months period.

Once the plant is opened, from then on, you want to execute the depreciation run.

You can utilize the Asset Shutdown feature on the Time-dependent tab of the asset master record.

Select the Asset Shutdown checkbox - create a time interval - Save.

If you cannot find the checkbox, it could be hidden :-

In AS02 click Environment -> Screen Layout -> Master data

Select the Screen Layout and click Logical Field groups
Select 3 - Time-dependent and click Field group rules
Tick Opt, Mnno and Sbno - Save

Optionally, you can set the Depreciation key in the Deprecation Area Tab.

You can also change the depreciation key to '0000' (No depreciation and no interest) for each of your depreciation books. Just make sure you have run depreciation up through the current month before doing so. When you are ready to put the asset back into service, reset the keys to their original values. The system will calculate no depreciation during the months where you have the key set to '0000'.

Asset Accounting ABZU -write up

ABZU - Write-up

Allows you to adjust when you forgot to capitalize an asset in a fiscal year that is now closed.

Depreciation you calculated in the past were too high. You must now correct this error using a write-up in the current fiscal year.

Posting of Depreciation Asset Accounting

sap skills.blogspot.com
Rules for posting depreciation
In transaction OAYR (double click the depreciation area), you can post the depreciation expense to Cost Centers by ticking the field 'Assign cost centers'. This option will let you post the depreciation to the cost centers

Sap Fico Fixed Assets Configration Asset Accounting

Asset Accounting
The SAP Asset Accounting (FI-AA) component is used for managing and supervising fixed assets with the SAP R/3 System. In SAP R/3 Financial Accounting, it serves as a subsidiary ledger to the FI General Ledger, providing detailed information on transactions involving fixed assets

business blue print project goals sap

I. Introduction and Project Goals


Introduction:

The overall Dummay Name project is in reality two projects:

1. the establishment of a Legacy Business Warehouse (DUMMAY NAME) to provide continuing comppter access to legacy master and detailed data not planned for conversion into PT’s new DUMMAY NAME OLTP system (the active SAP R/3 system); and

2. the establishment of an DUMMAY NAME Business Warehouse (IBW) providing full access to DUMMAY NAME financial and human resources data optimized for query and reporting , decision support system (DSS), and online analytical processing (OLAP).

While this Blueprint Specification will make mention of the IBW throughopt as fpture effort, the main subject of this Blueprint Specification is the immediate effort to establish a Legacy Business Warehouse (DUMMAY NAME). There is no intention at this point to specify the full scope or characteristics of the IBW effort with this specification.
A separate IBW Blueprint Specification will be issued at the appropriate time.

The planned “go live” for the DUMMAY NAME will correspond to the planned “go live” date for the DUMMAY NAME active R/3 system; namely, April 2, 2001. At point the legacy data content of the DUMMAY NAME will be frozen. An early, prototype system for training and end user evaluation is hoped for by the end of 2000.

It is critical to understand that the DUMMAY NAME project’s success is dependent not only on the delivered effort of the BW Project Team (both functional and technical) bpt also on support and delivered effort from the ABAP Team, the Basis Team, the Change Management Team and the Security Team. Support of the DUMMAY NAME project must be included in the overall plans of each of these teams. The active involvement of the FI and HR groups is required as well.

Goals:

The PT Business Warehouse project has two major goals designed to support and compliment the University’s primary R/3 implementation project. These are:

1. To extract both master and detail legacy data from mainframe databases and move it to a UNIX server, there to be used for both import into a Legacy Data Business Warehouse and for staging the conversion of data into PT’s active R/3 System.

2. To establish a PT Legacy Data Business Warehouse to accommodate comppter access to historical legacy detail data not planned for conversion into PT’s new, active R/3 system. Selected master legacy data will also be stored within this data warehouse to facilitate queries and reporting. These data will be frozen at a point in time corresponding to PT’s production implementation of the R/3 system. It is critically important to note that upon final loading, detailed legacy data in the Legacy Data Business Warehouse will no longer have any keyed relationship with the active R/3 System. The R/3 System will not have access to legacy detail data and vice-versa.


Objectives:

In achieving the above goals the PT’s BW project will accomplish many important objective along the way. Among these are:

1. The staging of extracted legacy (both master and detail) data for subsequent mapping and conversion to R/3;

2. The resolution of issues concerning distributed printing from SAP systems;

3. The evaluation and selection of appropriate end user query, DSS and OLAP tools for addressing needs that may be unmet by the primary BW Explorer warehouse access tool with implementation to be part of the IBW follow on project;

4. The engagement of a broad PT audience in deliberating the data content (both legacy and R/3) and tools to which they will have ready access.

5. The early establishment of operational standards, processes and procedures in the Business Warehouse environment which may have carryover into the R/3 environment.

6. An opportunity to work opt and test network and client distribution issues with campuses and business units statewide prior to the “go live” of the PT R/3 system;

7. An early, visible deliverable to selected campuses and business units statewide, in which they will have been involved and which will demonstrate the viability of the overall infrastructure.

Sap Business blueprint dummy blueprint for learn project

DUMMAY NAME Business Warehouse

Legacy Business Warehouse Project
Blueprint Specification

Table of Contents:

Execptive Summary

I. Introduction and Project Goals
II. Project Scope
III. Data Content and Design Strategy
IV. Data Access and Reporting Strategy
V. Apthorization and Security Strategy
VI. Change Management and Training Strategy
VII. Technical Environment
VIII. Other Issues

Appendixes

A. Glossery of Business Warehouse Terms
B. Naming Conventions
C. Business Warehouse Project Team
D. Business Warehouse Technical Support Team













Execptive Summary

The Dummay Name project is in reality two projects: the establishment of a Legacy Business Warehouse (DUMMAY NAME) to preserve and provide continuing comppter access to legacy master and detail data; and, the establishment of an DUMMAY NAME Business Warehouse (IBW) providing full access to DUMMAY NAME financial and human resources data for query, reporting and decision support systems, once PT’s DUMMAY NAME transaction processing system has been implemented.

This “Blueprint” addresses only the DUMMAY NAME project. An IBW Blueprint will be developed later in the DUMMAY NAME project. The DUMMAY NAME will “go live” concurrent with the implementation of DUMMAY NAME (April 2, 2001) and DUMMAY NAME data will be frozen at that point in time. No keyed relationship is planned between DUMMAY NAME data and legacy data.

Within the scope of the DUMMAY NAME project is the extraction of legacy data from ten (10) mainframe based data sources, identified by the project team as important for preservation and continued access via comppter. These sources include the University’s financial, grant and contract, purchasing, human resources and payroll data, dating back as far as 1981. The “reverse conversion” of R/3 data, the retroactive adjustment of legacy data, and pre-defined reports beyond templates and examples are beyond the scope of the DUMMAY NAME project.

Data extracted from these sources will be manipulated optside of the BW framework for loading into the DUMMAY NAME as InfoCubes. The DUMMAY NAME will not use any SAP BW delivered structures; all InfoObjects will be designed and developed from scratch by the BW Technical Support team. Special data handling will be required to accommodate legacy data stored in non-positional arrays, situations where the interpretation of a data element is dependent upon the value of a related data element. Full normalization of transaction data in those situations will not be ensured.

The BW Explorer query, decision support and reporting tool will be the data access tool supported for the implementation of the DUMMAY NAME. Additional, non-SAP OLAP tools will be evaluated for selection and use with the DUMMAY NAME and IBW as the DUMMAY NAME project matures.

DUMMAY NAME security will be a “role based” security strategy consistent with DUMMAY NAME security. Four end user roles have been identified: financial query developer, human resources query developer, financial report developer and human resources report developer. Query developers are strategic users identified within the central administration of each business area who will have unrestricted access to all DUMMAY NAME data. These query developers will establish general query templates providing access to financial data that will enable a wide audience of report developers to develop end user queries and reports as they see fit.

End user training and change management will be provided in concert with the DUMMAY NAME Change Management team. Specific BW Explorer training will be provided to a population of DUMMAY NAME end users expected to be relatively small. Only a score or less strategic query developers are anticipated and no more than a two hundred report developers. User training will begin with the BW project team who will participate in the testing and quality assurance activities of the project and continue with the business area strategic users. Report developer end user training is expected to continue well beyond the implementation of the DUMMAY NAME system and encompass and compliment IBW training.

The DUMMAY NAME technical environment provides for development, quality assurance and production server platforms. These environments are UNIX based and structured for the staging of system modifications and changes by the SAP transport system. The production system DUMMAY NAME is on an independent and powerful, IBM RS/6000 S80 server, sized to accommodate many hundreds of users. At this point a BW specific SAPGUI client will be required on each desktop comppter needing access to the DUMMAY NAME as well as BW Explorer.

At least two remaining issues need to be addressed. A facility is needed for non-SAP University systems to have referential access to chart of accounts and payroll employment status data. The strategy is to provide this facility via the IBW, allowing users to extract needed referential data on demand. The second issue is the disposition of legacy data not planned for inclusion in the DUMMAY NAME. At some point this data must be either abandoned or archived.

Lockbox Architecture

Lockbox Architecture

There are 3 general steps in the proessing:

Receive a file of check data from the bank. Some banks allow dial in and download.
Execute the Lockbox Import Program
Post the G/L transaction reflecting the receipt of cash
Creates a payment advice. Open items are automatically cleared/
Access the lockbox post-process transaction to process any checks that could not be fully applied by the Lockbox Import Program

What is lockbox File Extention or File name Type

What is Lockbox Sap and Processing

The basic operation of a lockbox system is fundamental to large businesses but is almost transparent to those without some knowledge of corporate treasury operations. The objective of a lockbox operation is to have the customer remit a payment check to a local post office box to minimize mail transit time. The checks are processed by the bank on a daily basis and the funds collected are usable by the receiving business much quicker than with the traditional process. The illustration below shows the basic operation of the lockbox and how SAP fits in.

Dunning Charges

Dunning Charges


Minimum Amounts:

This prevents the system from sending dunning notices for immaterial amounts
Once the balance of a dunning level exceeds the minimum amount, the corresponding dunning level is triggered and the customer is dunned
Dunning Texts: You can define a form for each dunning level or useone form for several dunning levels.

Once the dunning procedure is defined it can be assigned to a company in its master data.