This process is used to set up basic data other than object related basic data to carry out fixed assets accounting processes. This involves the following.
In order to carry out any operation in IFS/Fixed Assets Accounting, a code part with the code part function set to FA Accounting must exist in the system. This code part is used to save the object ID when transactions are entered for a fixed asset object. Code parts are defined in IFS/Accounting Rules.
This is required to create depreciation plans and depreciation proposals. Once a depreciation method is defined, it can be connected to a fixed asset object with a book. When a depreciation plan or a depreciation proposal is created, the depreciation method for each individual object is selected by the system based on the book specified for the plan/proposal.
Calculation indices are used to recalculate base values. A calculation index should be connected to a fixed asset object in order to automatically recalculate a selected base value type linked to that object. The recalculation can be performed with only the latest informed index value.
Base value types are value types that are linked to fixed assets objects. They are used for depreciation as well as for information (e.g. for insurance) and change object value calculations. By connecting a calculation indices to user-defined base value types, you can recalculate base values at required times. Both user-defined base value types and system-defined base value types are available to be connected to depreciation methods for the purpose of calculating depreciation.
Books are used to create depreciation plans, create depreciation proposals and to change net values of objects. More than one book can be used in the system for different purposes. For example, you can use separate books to depreciate fixed asset objects for tax purposes and to depreciate fixed asset objects for internal accounting.
You can specify whether a book should be used to create accounting transactions or not. If a book is used to create accounting transactions, only the default calendar can be connected to that book. Books that are not used to create accounting transactions can be connected to any depreciation calendar of your choice.
Object physical locations are the physical locations in which the fixed asset objects are kept. These must be defined in order to carry out a physical count of fixed assets. In order to define object physical locations, at least one site must exist for the company.
Depreciation periods are the periods defined for the purpose of accounting for fixed assets objects. When IFS/Fixed Assets Accounting is installed, the default depreciation calendar will be created. The depreciation periods in the default calendar will be equal to the accounting periods in IFS/Accounting Rules. If the depreciation periods do not correspond with accounting periods, the information must be modified or supplemented.
The relative size of the depreciation amount per period is determined by the number of depreciation periods in a depreciation year rather than the length of the individual depreciation periods, unless the depreciation method type Rem Value/Rem Days is used to calculate depreciation. When this method is used, the number of days in the period and the remaining days of the estimated life will be used to calculate depreciation.
Several depreciation periods can be equivalent to a single accounting period, but it is not possible for a single depreciation period to be equivalent to more than one accounting period.
When a new fixed asset object is defined, it is required to specify an acquisition account for that object. Therefore at least one acquisition account must exist in the system before you carry out any operation in IFS/Fixed Assets Accounting.
A property in IFS Applications/Fixed Assets Accounting is a unique detail relating to a fixed asset object such as the registration number, manufacturer, motor number, unloaded weight etc. that is not available as a standard information field. A property code is a code for a particular property. Thus, one or more property values can be defined for a property code. For example, a list of manufacturer IDs can be entered as property values for a single property code that stands for the manufacturer of the fixed asset object. Once you have defined a property code and specified appropriate property values for it, it will be available to be connected to fixed asset objects as well as to property templates.
When there is a set of property codes that is common to many fixed asset objects, they can be grouped together using property templates. A property template can have one or more property codes connected to it. When you connect a property template to an object group, all the property codes belonging to the property template will be connected by default to all the objects within that object group. It is also possible to collectively enter all the property codes that belong to a selected property template to an individual object of your choice.
The ID of a new fixed assets object is automatically generated if a specific object series ID is connected to the object group to which it belongs. However, it is possible to modify the automatically generated ID as long as it is not saved. Defining object series IDs is not mandatory since it is also possible to manually enter fixed asset object IDs.
At the time a fixed asset object is defined, you are required to enter the object group to which the object should belong. Therefore, at least one object group must exist before you carry out any operation in IFS/Fixed Assets Accounting. When you define an object group, you can specify the default values to be used as the acquisition reason, acquisition account, disposal reason and the object class of the objects belonging to that object group.
Object classes can be used to differentiate fixed asset objects on any basis determined by the user. However, it is not mandatory to define object classes since they are not used in any operation in IFS/Fixed Assets Accounting.
When carrying out any transaction relating to fixed assets in the system, you will be required to state the transaction reason. It is possible to predefine transaction reason IDs with relevant descriptions in IFS/Fixed Assets Accounting. A transaction reason can be used as an acquisition reason, a disposal reason and/or a depreciation reason. At least one transaction reason must exist in the system before you carry out any operation in IFS/Fixed Assets Accounting.
For the system to automatically select the code part values to which different fixed asset transactions should be posted, you are required to define the posting rules in IFS/Accounting Rules. A separate posting types exists for each kind of transaction relating to fixed assets. The posting rules are created by specifying a code part value for a combination of a posting type and one or two control types. On the other hand, you can also specify a code part value to a posting type regardless of the control type(s) to which it is combined. (Please refer Posting Types and System Events - IFS Financials in Topics in IFS Applications/General Documents for further information on posting control).