Fixed Asset Management

 

 

Fixed Asset Functional Specification
 
Functional Requirements
A fixed asset, also known as property, plant, and equipment, is a term used in accounting for assets which cannot easily be converted into cash. This can be compared with current assets such as cash or bank accounts, which are described as liquid assets. In most cases, only tangible assets are referred to as fixed. 
The purpose of the Fixed Asset extension package is to provide detailed information on the types, quantities, location, financial values, and associated transactions of fixed assets. The Fixed Asset register will provide detailed information compared to a few entries in a General Ledger account.
This is intended to be the first step in functionality that could lead to an Asset Maintenance module whereby maintenance activities are planned and the maintenance costs linked to the Asset and posted to the G/L.
The following Capabilities will be added as an extension to xTuple:
·        Define Fixed Asset Types
o       Define differing types of Fixed Assets
o       G/L account determination for assets linked to each type
o       Define the Depreciation methodology for assets linked to each type. Diminishing Value or Straight Line
·        Define Fixed Assets
o       Manually create Fixed Assets
o       Define the Type of Asset for each asset which then determines the accounts and the depreciation profile
o       Define the purchase price of the asset (at this stage it will not be linked to Purchase Orders)
o       Define the Installation Date of the asset which will determine the beginning date for depreciation purposes
o       Define the Retirement date at which point the asset is sold or written off.
o       Define the Asset Life (in years) and Residual value for depreciation calculation purposes
o       Define the Location and Address of the asset. (Location will be linked to the Inventory Location). Address will use the standard Address widget
o       The ability to attach documents to the asset
o       The ability to add characteristics to the fixed asset
o       The ability to add comments to the fixed asset
o       A record of financial transactions linked to the asset
·        Depreciation Calculations
o       Select All Assets, Asset Types or specific Assets and calculate depreciation based on settings
·        Adjustments
o       Apply write-ups, write-downs, write-offs and post appropriate financial transactions into the G/L
·        Reporting
o       Asset Register – List of Assets (by Type?)
o       Depreciation Report – List of depreciation transactions for a defined time period
 
New Terms and Definitions
Fixed Asset
    • A fixed asset, also known as property, plant, and equipment, is a term used in accounting for assets which cannot easily be converted into cash. In most cases, only tangible assets are referred to as fixed. 
Asset Type
    • Grouping of Fixed Assets with similar features and functionality. This will be used to define depreciation regimes, and G/L Account determination
Depreciation
    • A term used in accounting to spread the cost of an asset over the span of several years. Typically countries have specific tax requirements for the handling of depreciation.
 
Related Existing Functionality
In many ways we could treat a Fixed Asset in a similar manner to an Inventory Item. A Fixed Asset would be purchased and the value booked to the appropriate Asset account as well as being recorded in the Asset Register. Sale of an Asset could be managed through the Sales Order process. Potentially the Bill of Materials could be used to reflect Asset components or sub-assets. This however is probably too large in scope in terms of project size and in terms of amending core xTuple.
Purchasing and Sales transactions will not be integrated in to the process.
Asset Maintenance will be considered as a subsequent phase of the development.
 
Similar and Related Requests
Conflicting Features
The functionality is intended to run independently so should not cause conflicts.
 
User-Level Functionality
A new menu area under Accounting will be created to house the Fixed Asset functions. This will allow the maintenance of Asset Types, Fixed Assets, Depreciation, Write-Ups and Write-Downs, and Reporting.
 
Window Changes
Fixed Asset List:  Used to search and find Assets and to access relevant transactions.
 
Fixed Asset Type:  Used to group assets together into like types and to define financial account assignment for various transactions
 
Fixed Asset:  The main asset screen holding all important attribute information.
 
Depreciation
Adjustments
 
Report Changes
Fixed Asset Register
Fixed Asset Transactions
Depreciation Summary
 
Batch Manager Changes
Add Depreciation calculation functionality to Batch Manager
 
Usability Considerations
How do we think this will affect user access to existing functionality?
What problems do we anticipate users might have with this functionality and how can we minimize the impact of these problems?
What errors or abnormal situations do we expect users might encounter during normal processing and how can we make it easy for the user to fix these problems using the application?
 
Problems and Alternatives
What might go wrong with the solution described in this document?
The development is intended as a plug in so will operate independently from core xTuple. It will however post significant transactions into the G/L so care and thorough testing is required.
Why might this not be the best solution?
As mentioned above if we modified Items and created a type of Item called an asset then we could reuse purchasing and sales functionality as well as a BOM. We would need to add attributes to Items to define the required actions.
What are the limitations of this approach? What's missing that might be desirable?
Integrated Purchasing and Sales.
Asset maintenance functionality (next phase)
Describe briefly other ways to solve the basic problem and the advantages and disadvantages of each alternative.
Justify the chosen solution or argue why one of the alternatives would be better. Be as broad as possible here, since an important purpose of this section is to provide alternatives in case the initial attempt at implementation encounters a significant implementation block.
 
Internal Design
Now that we have defined what we have to do and how we think it should look to the user, we can describe the internal structure of the application. If possible, outline the architecture of the feature implementation here. Then in the sections below describe the changes and additions to the application to create this architecture.
 
Basic Algorithms
Are there particular algorithms required to implement this feature? If so, describe them here.
If you are going to outline a particular algorithm in pseudo-code 
	    put it in a programlisting
	    try to limit lines to approximately 80 characters
	    try to limit programming constructs while still being clear about intent
	end if // a programming construct that may be unavoidable to maintain clarity
 
Custom Widget Changes

None anticipated. 

Schema Changes
A new schema will be created with the following tables
fixedAssetType
fixedAsset
fixedAssetTrans
 
 
The new whatever-you-call-it table
Column Name
Description
Data Type
Comments
field1
Describe me
data_type
how it's used
foreign_key
Describe me
integer
foreign key to other_id
enum_field
Status or similar field
character(1)
Can take one of the following: 
* A value 
* Different Value 
* Final Value
 
What privileges do we need?
Privileges for feature
Name
Description
MaintainFixedAsset
Can Add/Edit/Delete Assets
ViewFixedAsset
Can View Assets
MaintainAssetTypes
 
ViewAssetTypes
 
DepreciateAssets
Run the Depreciation calculations
 
Stored Procedure Changes
·        depreciateFixedAsset
·        adjustFixedAsset
·        purchaseFixedAsset
·        sellFixedAsset
Performance Considerations
Calculation of depreciation for large groups of Assets could impact performance.
 
Error Handling
What internal errors do we anticipate might occur?
How can we best hide them from the user, prevent them, or fix them automatically?
 
QA Considerations
Does this feature require any special tools or data to test? Is it testable (some features may be hard to reach from the user level)?
What are some anticipated areas of concern that require special attention?
 
Documentation Considerations
Is there a significant documentation impact?
Does the feature require a standalone essay or only field-level descriptions?
 
Release Considerations
What release would we like to target?
What is the potential impact on a release if we don't finish in time?
What happens if we only get some of the functionality done?
Are there any pieces that would be useful on their own?
Are there any dependencies on other features or applications (such as Qt 4 or a particular release of OpenRPT)?
What is the anticipated impact on users, particularly those who have customized the sources, reports, and database schema?
 

 

AttachmentSize
AssetList.JPG23.21 KB
AssetType.JPG30.62 KB
FixedAsset.JPG59.26 KB
Fri, 10/08/2010 - 04:06
#1
sajjad_syed
sajjad_syed's picture
Offline
Joined: 09/08/2010
Availability Date

Hi

What will be the availability date of the the fixed asset system. are you looking for beta customers.
Regards,

Sajjad Syed

sajjad.syed@exdnow.com

Top
Fri, 10/08/2010 - 07:50
#2
jrogelstad
jrogelstad's picture
Offline
Joined: 12/10/2008
There is no timeline. This

There is no timeline. This is specification initiated by the community at large, but hasn't seen activity for a while, though some folks have made noise on the side that they want to pick it up again.

Top
Fri, 10/08/2010 - 21:18
#3
sajjad_syed
sajjad_syed's picture
Offline
Joined: 09/08/2010
Fixed Asset Timeline

Is there a document (functional design, requirements, use cases etc.) or any other material that was created to this effect. We would like to take this up and would like to estimate the time effort for this. If not we will start the research work.

Regards,

Sajjad

Top
Mon, 10/11/2010 - 07:20
#4
jrogelstad
jrogelstad's picture
Offline
Joined: 12/10/2008
This page is it.

This page is it.

Top
Tue, 10/12/2010 - 03:01
#5
anderson
anderson's picture
Offline
Joined: 01/28/2009
Development is continuing

I am the initiator of the Fixed Asset spec and I am currently developing the functionality.

I am probably 80% of the way through developing the basic Fixed Asset functionality and almost ready for packaging and testing. I will then begin work on the depreciation side of things which will take a bit of time to work through.

I'm hoping to have the basic Fixed Asset register ready in time for the 3.6 release.

Top
Tue, 10/12/2010 - 14:07
#6
anderson
anderson's picture
Offline
Joined: 01/28/2009
Fixed Asset Characteristics and Comments

Characteristics:
I think it would be very useful to have Fixed Asset specific characteristics. This would assist in grouping and reporting and would be essential for a planned maintenance package.

Two questions: We would need to add another checkbox on the new Characteristic screen in the "may be used on" section. This would allow us to only display asset characteristics. Secondly, I don't think we have a Characteristic widget. Would this normally be handled by an xTree widget?

Comments:
Similarly I would like to add Comments to track an Asset's history/changes, and user comments. It is easy enough to add a custom Comment type by adding to the source table. However the Comment widget only has the standard sources it its type list. Would it also be possible to adjust this widget to include Fixed Asset as a type? I have tried using setType() but this appeared only to work with standard types??

Top
Wed, 10/13/2010 - 07:47
#7
jrogelstad
jrogelstad's picture
Offline
Joined: 12/10/2008
Yes, you should be able to

Yes, you should be able to add characteristics with scripting. You'll have to duplicate all the behaviors found in other screens. The flag for fixed asset characteristics would have to be kept in a separate table for the fixed asset schema. Because of all the code duplication there is some work involved there.

Comments on the other hand, as you've pointed out, is a widget with types hard coded in. There is no way to add a new type without changing the C++ core. Would be nice to modify it so that types could be added in on an ad hoc basis so it could be more easily implemented in these kinds of environments.

Top
Wed, 10/13/2010 - 15:18
#8
anderson
anderson's picture
Offline
Joined: 01/28/2009
Comments Widget

Thanks John for the reply.

Characteristics can probably wait until work on maintenance begins.

However I think it would be really useful to have a Comments section. Is it possible to add fixed asset as a comment.type attribute short-term so I can complete this area? Is it difficult to add another type to the widget? I understand this muddies the clean separation between core and packages. Similarly I don't want to use a standard comment.type in lieu of having one for assets. I did think about reusing the Item type and setting the starting id of the asset to be way outside of the likely item range.

Any thoughts?

Top
Wed, 10/13/2010 - 15:26
#9
jrogelstad
jrogelstad's picture
Offline
Joined: 12/10/2008
No, it's really, really bad

No, it's really, really bad practice to add a type to the core that isn't used by the core. What needs to happen is that "adhoc" type needs to be added to the comment widget (and it follows also the document widget, alarms widget etc.). Combo boxes have a provision, for example, for an AdHoc type where you can set any query to populate it in our format. 3.6 is in beta now, so it's really too late to get it in there. But if you want to contribute something to the core, we can work on getting it in the next round.

Top
Wed, 10/13/2010 - 16:35
#10
anderson
anderson's picture
Offline
Joined: 01/28/2009
Comments Widget

No problems - I will have to leave both Characteristics and Comments till a later stage.

Top
Wed, 10/13/2010 - 01:33
#11
naumaan_sagheer
naumaan_sagheer's picture
Offline
Joined: 08/13/2010
Beta Testing

Hi Anderson,

Can you share with us the software package for Beta Testing purpose.

Regards,
Naumaan Sagheer

Top
Sun, 10/31/2010 - 14:42
#12
anderson
anderson's picture
Offline
Joined: 01/28/2009
Depreciation Methods

Can I please have some feedback regarding Depreciation methods that need to be supported.

My thoughts are to cover:
* Straight Line
* Diminishing Value (also known as Declining Balance)
* Double Declining Balance
* Sum of Years

I will be using the calculation methods outlined in http://accountinginfo.com/study/dep/depreciation-01.htm

The idea is that depreciation expense is calculated and stored in a depreciation transaction table. If the organisation desires, these transactions will then be able to be posted to the G/L into the accounts specified by the Asset Type. Once depreciation is posted, some of the Asset data will need to be locked down. Other transactions will be enabled to facilitate the purchase, sale, adjustment, and disposal of an Asset from an accounting perspective.

Top