Asset.pm

This module will manage assets for the ledger(s). New assets can be created, information about them can be maintained, and depreciation schedules can be setup and modified.

I have been toying with the idea of making this an xml system that can manage assets without the neccessity of xiwa. Of course it could interface with xiwa. The system will create an asset, create a depreciation schedule, view an asset or view a depreciation schedule. The viewing of an asset or depreciation schedule could query xiwa to get the data or look at files.  If the system has to use xml to do all of its work anyway, then it should be able to be configured to use XML files or talk to xiwa--in which case the xml files would be temporary.

XML  xml files needed.  Subdirectories:  Assets, Schedules, Accounts, Groups.
Asset XML

<xml><asset>
  <name></name>
  <id></id>
  <purchase_date></purchase_date>
  <salvage_date></salvage_date>
  <purchase_price></purchase_price>
  <salvage_price></salvage_price>
  <gain_loss></gain_loss>
  <sub_entity_id></sub_entity_id>
  <account_id></account_id>
  <depreciation_id></depreciation_id>
  <contra_id></contra_id>
  <life></life>
</asset></xml>

<xml><account>
  <id></id>
  <name></name>
</account></xml>

<xml><depreciation>
  <asset_id><asset_id>
  <method></method>
  <schedule>
    <expense date="2001/1/1">$123.34</expense>
    <expense date="2001/7/1">$123.34</expense>
  </schedule>
</depreciation></xml>

<xml><group name="">
  <asset_id></asset_id>
  <asset_id></asset_id>
  <asset_id></asset_id>
  <asset_id></asset_id>
  <asset_id></asset_id>
</group></xml>

These are standard forms that a page in the accounting application will use: mainForm, menuForm, optionsForm

Commands:

display

newAsset

enterAsset

viewAsset

editAsset

newDepr

enterDepr

viewDepr

editDepr

deleteDepr

display - displays a list of asset name/number links to other functionality, (this list is assets that have been purchased in xiwa or come from xml files.)

There should be a filter on the screen.  Assets can be filtered by Account, Group, Date?

When the proper selections have been made the page will submit with the command as viewDep or viewAsset

enterAsset - Does the work of submitting the information of the asset to the database modules(submit to result screen and autosubmit with message back to createAsset

editAsset - possibly use the same screen for new, edit, view

newAsset - collects information for creating an asset purchase_date, salvage_date, purchase_price, salvage_price, sub_entity, dep_acct, contra_acct, sub_acct, depr_method, depr_life, depr_increment(1 for year 4 for quarter and 12 for month, etc. ) (we may need depr_day and depr_month in asset_tb) The depreciation is not necessarily going to start on the purchase date. The schedule would use the depr_day and depr_month to start the entries and would run for the life * depr_increment

viewAsset - displays information about the asset in table format Name/Number, purchased, salvaged, cost, accumulated dep?, book value (oops, I think we need to add a field to the asset_tb: asset_acct) click on cost goes to purchase transaction, click on book value goes to depreciation schedules

newDepr - This screen calculates and displays the depr sched based on the settings for a given asset. If the user chooses it can replace the entire current schedule by choosing a checkbox [] replace current schedule.

enterDepr - This screen enters the data pertaining to depr. This should probably just take the data to be entered, run security checks, and enter it. This keeps this screen from having to determine whether there are other entries to remove etc.

editDepr - can we use the same screen for edit/view? This screen will allow the deletion of part of the schedule. At first thought the schedule should probably be deleted from the chosen row into the future--thats the only thing that makes sense. Then, the rest of the depr sched needs to be filled in. This screen could reuse the calculation code to calculate the depr sched from the last entry to the end of the depr_life.
Basic steps for this screen.
1. calculate total depr for item chosen
2. if total depr != contra depr display messages
3. if total depr = purchase_price - salvage_price
  select all entries display them
else
  deprLeft = purchase_price - salvage_price - total depr
  from last date of last entry calculate the dep sched for the remainder and display it asking whether or not to enter it.

What about views for multiple types of entry.  Annual, Semi-Annual, Qtr, Month

Semi-Annual

And so on down to monthly view.  Monthly would obviously create quite a burden on the screen.  Will have to rethink it.  Perhaps a monthly or quarterly schedule can only be done for one assset at a time.

viewDepr- same as edit only does not perform calculations??? Not sure if we should have two screens that are basically the same! Just requires asset sub acct number. This screen should list The depreciation information about the asset then the entries in the database that pertain to the depreciation of this asset. for ex. Asset X would list this information first: Name, Number, purchase_date, salvage_date, purchase_price, salvage_price, sub_entity, dep_acct, contra_acct, depr_method, depr_life, depr_increment, depr_day?
Then a table with this information:
Ref | Date | Debit | Credit |
This information should be based on Depr or Contra Asset?both? Do checking to make sure that the depr exp total equals the contra asset total.
There will be check boxes to Edit/Delete the rows in the schedule. Deleting the schedule will simply run a sql command something like: select from debitcredit_tb where account = <DepreciationAcct> and sub_account = X and date >= purchase date and date <= salvage_date. accounting for salvage date not existing because the asset has not been sold yet. A check should also be done here and a warning displayed to the user along with the results if this sql statement returns any records. select from debitcredit_tb where account = <DepreciationAcct> and sub_account = X and date < purchase_date and date > salvage_date.

deleteDepr - After a period is closed out those depr schedule entries prior to the closeout should not be able to be deleted. But the other entries can be deleted by simply passing the journal ref_nums to this method. (method should validate that the entries are not in a closed out period)

Copyright (c) 2001 PC Xperience
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1; A copy of the license is available at http://www.gnu.org/licenses/licenses.html#FDL.

Updated: $Id: Asset.html,v 1.7 2004/01/14 22:52:19 moreejt Exp $