Fixed Asset functionality
I'm looking for feedback on a development I am considering either as part of Core or as an extension package.
I want to develop Fixed Asset functionality in xTuple to create a basic Fixed Asset Register. The Asset register will be used to hold information about Type of Asset, descriptions, Locations, Addresses, and value. The idea is to group assets by Asset Type which will hold information about associated G/L Account(s) such as the Fixed Asset account and the depreciation account. We will need to set up configurable depreciation models (by Asset type?). Probably start with just straight line and diminishing value but I am open to suggestions here. Ideally we have some link from Purchasing and Sales for the creation and disposal of fixed assets which then generate the corresponding G/L transactions.
Hopefully the community can give some feedback on whether this functionality is useful and to comment on rounding out the desired functionality.
This is the first step in a larger plan to develop functionality around Asset Maintenance.
Thu, 11/26/2009 - 08:53#1
I think this is a great idea
I think this is a great idea that would be very popular and well received by the xTuple user community! I'd suggest starting with an extension so that you could provide a working "prototype" to users without them having to download a custom or beta binary to try it on their data set. Once you have the kinks worked out you can either A) Post the extension on the xChange as a community contribution B) Sell the extension on the xChange or C) Convert the code to C++ and submit the tool as a core contribution. We'd be happy see your utility made available in any of those three forms.
It might also be worth noting that scripting has been expanded immensely in 3.4 as a result of our conversion of the commercial manufacturing edition to an extension package (http://www.xtuple.org/node/2431). For example, I posted a blog on the new script debugger (http://www.xtuple.org/node/2378). I'm hoping we can get some blogs from the other developers too in the next couple weeks on some of the other new script capabilities. You'd probably want to start your work in 3.4beta to have the most flexibility. 3.4RC should be out next week barring any unforeseen problems.
Fri, 11/27/2009 - 10:02#2
A few quick thoughts come to mind when thinking of assets as "machinery"
1. File attachments for storing pictures and manuals about the asset.
2. Preventive maintenance data fields - what, when, how
3. Use the CRM to create the asset as an "account" and include the preventive maintenance tasks as part the CRM work flow
Fri, 11/27/2009 - 17:48#3
Thanks for your comments Mitch.
Yes I am definitely looking ahead of "Financial" Assets with a mind to building some functionality around "Technical" Assets and the maintenance of those assets.
I will be putting a Design Specification together over the next few days to detail initial design considerations and to elicit further input from the community.
With regard to your points:
1. Absolutely - the Asset needs to have the ability to attach documents. I was also thinking that we need to add Characteristics to make it really flexible.
2. While I agree that PM fields are needed on the asset, I really want to get the financial side sorted first and build Maintenance into phase 2. Maintenance is a module in its own right if done properly and completely and I think it will potentially be a "bridge too far" for the first release.
3. Not sure I agree with the idea that an asset should be a CRM account as it muddies the intent of what an Account is. Good idea to link the asset to an Account. I do agree that any workflow needs to be consistent and consoliated within the xTuple system. Possibly re-use of the Incident mechanisms would be appropriate.
Sat, 02/06/2010 - 15:17#4
Still working on fixed asset?
Are you still working on this functionality? I'm also interested in implementing it, but do not want to unnecessarily duplicate effort.
If you aren't actively working on it, then I'll proceed with implementing as an extension. I thought that it would be good to follow a release early and often mindset, and would propose proceeding along the lines of:
1. Implement the detail/list screens and tables for fixed asset records and fixed asset classes - but not integrated in regards to G/L and POs.
2. Integrate fixed asset to PO/Invoice functionality, provide links between assets and G/L accounts for asset, depreciation and expense.
At the end of 2 there would be enough of an external API in place the one could conceivable link with external depreciation functionality.
3. Add depreciation capability by fixed asset and purpose (i.e. depreciation for taxes vs. for reporting)
Proposed Fixed Asset detail:
Status (Active, Disposed)
Asset Class (would be user defined)
Location (reuse xTuple's location system)
G/L account links (asset, expense, depreciation)
Purchase Order link
Depreciation Method (By depreciation group)
Thoughts are appreciated (or if this is currently being implemented, how may I help?)
Sat, 02/06/2010 - 16:08#5
Multiple Depreciation Methods
Most of the Fixed asset modules I have seen lately support multiple depreciation methods. A company may want to calculate depreciation using one method for book value and financial statements and another method for tax purposes.
Sat, 02/06/2010 - 16:42#6
Multiple Depreciation Methods
That's the reasoning I had behind the idea of a "depreciation group" which could be created by the user. Say you started with two groups, one named "Tax" and another named "Budget".
For a given fixed asset you could select the depreciation method to be used for each of the already defined groups. (i.e. there would one to many link between fixed asset and the depreciation group).
I'd imagine that you would want to set a default method to be used on the group, but then be able to override it on the asset level for that group if it didn't make sense (or was not allowed).
I've been looking at Sage's FAS as an example (there are probably better examples).
Sat, 02/06/2010 - 19:17#7
Multiple Depreciation Methods
I certainly don't want tell you how to design your extension, but I don't see the need for groups. Each Asset record just needs the appropriate fields or related tables to track accumulated depreciation for each method you intend to support. A company would designate which method's calculations should be used to post to the general ledger for each individual asset. When depreciation calculations are run, the processing program would calculate for each asset the depreciation amount for as many methods as you plan to support saving the data for each and using the designated method for posting. Users can then clearly see the impact on their financial records of each method.
I would also suggest a what-if process that does the calculation, prints a report but doesn't update any database records.
Each Asset needs a defined GL Asset account, a defined Accumulated Depreciation GL account, and a depreciation expense account.
There needs to be a method to dispose of an asset creating the appropriate journal entries. A method to add value to the asset for major repairs, etc which may qualify for capitalization is also needed with appropriate changes and GL transactions.
Just some of my thoughts, but I'm guessing you have already thought of these things.
Sat, 02/06/2010 - 19:48#8
Multiple Depreciation Methods
No please, do comment! That's the very reason I've posted here, because I've thought this out about 75% and need to find the holes. I'd also like to make this flexible enough to meet others needs since I'm not really in the full time business of writing xTuple extensions!
I do see your point regarding the groups - that is functionality that can already be accomplished via reporting by simply selecting what it is you want to show on the report.
Let me make sure I am understanding you correctly when it comes to the relationship between assets and depreciation methods:
1. Each supported depreciation method would be run periodically against the entire asset register to produce the data needed for both "what-if" reporting and GL posting.
2. Each asset record has a selection field named something like "GL Depreciation Method" which is assigned to one of those methods to be used for the actual posts to the GL accounts.
Does that sound accurate?
I'm not sure what to do about actual disposal yet in the context of the rest of xTuple. The journal entries of course would not be an issue, but in the case of a sale of the asset, it should probably go through a Sales Order so the sale was tracked.
Sun, 02/07/2010 - 02:03#9
Hi, sorry I've taken so long to take things further.
I have started the beginnings of a Specification which I want to post on this site so we can bring out further debate and comments.
I have mocked up some screens and given some thought around what sort of functionality there should be. Hopefully that will help clarify a design that suits most people.
I will commit to getting the draft spec online this week.
Sun, 02/07/2010 - 11:00#10
Awesome! That would be a huge help.
I have the beginnings of an extension written that I worked on yesterday and will probably spend some time on today. I'd be happy to bring it inline with your forthcoming specification and donate it to the effort to kick start the work. (CPAL license, if that is OK... unless you were planning a commercial development?)
The only thing I have run into so far is that it is not currently possible to create a top-level QMenuBar menu because that type isn't exposed to scripting. So I placed Fixed Asset under Accounting for now.
Sun, 02/07/2010 - 16:00#11
Yes CPAL is fine with me.
I'm looking at the Fixed Asset design with a view for the future of building some maintenance functionality which is a much larger undertaking and may become a commercial extension unless the community can share some of the development load.
I also have placed my prototyping screens under the Accounting menu.
I cannot see how to add a Development Specification to the xTuple website. If someone could point me in the right direction....
Mon, 02/08/2010 - 08:38#12
I've taken the liberty of putting a copy of the spec template at http://www.xtuple.org/FixedAssetManagement for you. You should see an Edit button near the top of the web page. If not, let us know.
For those navigating from the xtuple.org home page:
Docs -> Developer Zone -> Specifications -> In Design -> Fixed Asset Management
Mon, 02/08/2010 - 15:53#13
I have now posted initial thoughts around the Fixed Asset specification and welcome any suggestions.
My thoughts are we should focus on getting the basic framework around Asset management developed before extending functionality in future releases. If we have a tight scope then we are more likely to get the initial release completed in a timely manner rather than delaying a release to include every possible feature request developed.
One other comment: David Kern mentioned a number of specific attributes. My thoughts are to implement those as Characteristics. That would allow any industry to define their own requirements.
Tue, 02/09/2010 - 09:31#14
That looks like a tightly scoped addition that shouldn't be too difficult to pull off. The attributes that I mentioned would do just fine as characteristics, and that is a good way to handle them.
I'll let some of the CPAs hovering around here comment on the financial aspects, as that is not my background.
One comment regarding the Location. That would be a frequently used field for any movable fixed asset (test equipment for example), so I suggest the location field itself should be moved out of the tab into the main body of the dialog. Any additional detail (site, address, etc) could still be on the tab. Is the address you show intended to mirror the address of the site, or is it a separate address record?
Other than that I think it is a good start. Do you have your prototype screens as part of a package yet? If you'd like I can replace my ui dialogs with yours and post the work in progress package back here so others will be able to start testing out form and function.
Tue, 02/09/2010 - 13:40#15
It looks like you gentlemen are off to a great start with this extension. I would like to re-iterate my suggestion about calculating depreciation for each asset using multiple methods and maintaining all historical records for each method. I may be incorrect but from reading the specification I got the idea each asset would be configured to use just one particular depreciation method.
The reason I suggest this is because allowing various accelerated depreciation methods for tax purposes is a favorite tool of government for economic stimulus, encouraging the purchase of assets, etc. These various accelerated methods result in a lower profit for income tax purposes. However, a company may want to NOT depreciate those assets so rapidly for financial reporting purposes therby showing more profit than the tax return.
All the historical data and calculations are necessary so that from reporting etc., an accountant can properly prepare tax returns.
Tue, 02/09/2010 - 13:56#16
This is a really exciting
This is a really exciting thread and I am most impressed with the work and thought you all are putting into it.
There is some upcoming functionality you may want to consider that could impact this. First, there is a new recurrence widget being implemented in 3.5 in several CRM modules including To-Dos, Projects and Incidents. I could easily see this recurrence logic having applicability here for the depreciation schedule. Here's the related issue on that:
Also in 3.5 you will be able to send ad hoc MetaSQL statements to the batch manager. This may provide a vehicle to integrate your Fixed Asset module with batch manager without actually changing the code in that extension:
I think it is wise to keep the scope in check on the first pass. That said I'm wondering if somehow this couldn't be baked into the current item site paradigm so it's not a big deal to be able to buy and sell these things? Here's a thought: Perhaps fixed asset could be a flag on Cost Category. The new account mappings you've defined could be added to cost categories as well. Perhaps different mappings are made enabled depending on whether or not the cost category is flagged as a fixed asset. After all, aren't fixed assets just a special type of inventory? Then your view of fixed assets is really a view on a particular subset of inventory.
I certainly don't want to over complicate things, but it may be a good idea to think a solution to the sales/purchasing problem through, even if you don't implement it now, just to ensure you don't paint yourself into a corner later. My cost category suggestion may be one way of enabling fixed assets and item control to all fit together naturally.
Tue, 02/09/2010 - 15:46#17
I agree with the general concept of not doing too much now but having a total plan so you don't block yourself, but I think the sale/purchase using the sales order module and purchase order module is not really a requirement. True, you have to write a check and/or make a deposit when fixed assets are bought and sold, but the Fixed Asset module I am most familiar with doesn't handle acquisitions or disposal in that manner and I don't really recall any others that do. Essentiality you have both an asset acquisition screen and an asset disposal screen. Yes, these screens produce GL entries, but when checks are written and/or money deposited journal entries can offset against the entries made by the Fixed Asset system. In businesses like most of xTuple's client base, fixed asset acquisition and disposal just don't happen very often.
I surely agree with the comment that it would be good to have some input from one of our CPA friends. I am certainly not a CPA, but I believe there are three accounts necessary for Fixed Assets. Two balance sheet accounts, one for the asset acquisition value (typically a fixed asset on the balance sheet), an accumulated depreciation account(typically a fixed asset balance sheet account with a credit balance, commonly referred to as a contra-asset account), and an expense account that records the periodic depreciation expense as calculated by the application. Typically the fixed asset balance sheet account is only debited when acquired and no entries are made to that account. Periodic depreciation calculations typically create a debit to the depreciation expense account and a credit to the accumulated depreciation contra-asset account. The balance sheet presentation then typically shows the fixed assets at their acquisition value less the accumulated depreciation. Upon disposal, the disposal screen usually prompts users for the appropriate accounts to use to clear this asset off the books deneding on if this disposal is producing a gain or loss from present book value. Of course all assets can in fact share the same three accounts. The Fixed Asset module is just a sub-ledger to those accounts, just as Customer Accounts Receivable transactions are a sub-ledger to one Accounts Receivable general ledger account
John, I don't believe it is a fair characterization to say fixed assets are just a special type of inventory. I believe the module needs it own account mappings.
Tue, 02/09/2010 - 15:59#18
It just dawned on me as I was saving the previous post that everything I have said and, I think all of us participating in this thread, have been pretty much thinking of USA processes only. I have abolutely no idea what the requiremts might be for any of international friends might be.
Thu, 02/18/2010 - 11:20#19
Accounting practice is similar in Canada for book purposes. The only difference are the tax rules (tax depreciation methods). You are right that fixed assets are treated differently on the financial statements than inventory. Fixed assets are long term assets which are depreciated over the useful life of the asset, while inventory for sale is a short term asset, which is not depreciated. When you sell a fixed asset, there is a gain or loss on the difference between the proceeds and the depreciated value of the asset. Inventory is handled differently, from an accounting point of view.
Tue, 02/09/2010 - 16:05#20
I believe it is correct to say that most of xTuple customers are not start up, but have data to bring over from previous systems. I believe it would be necessary to provide a convenient screen or screens to load all historical values WITHOUT creating general ledger transactions.
Tue, 02/09/2010 - 16:13#21
Why does a fixed asset module
Why does a fixed asset module have to be completely separate, including the mappings? I don't think that because other systems have isolated it means that it must be so. Example: Tooling is a type of fixed asset. We have just introduced a number of enhancements to tooling (http://www.xtuple.org/node/2197), but those enhancements explicitly avoid the depreciation problem. Wouldn't it be nice if the asset management module would also be able to depreciate a tool without having to define that tool a second time in a separate place?
I can't see any reason why Fixed Assets are not a form of inventory. True it is not the kind of inventory you buy and sell at the core of your business, but it is not unusual to purchase fixed assets and on occasion even sell them. It seems to me if there is an opportunity here to introduce a new module that leverages existing business logic to a large extent, then that should be considered. Integration between modules is at the heart of what ERP systems are all about. It reduces the amount of new business logic that has to be built and maintained, and the amount of data and screens to be managed by the end user.
Tue, 02/09/2010 - 17:30#22
Lots of very good ideas coming out here. And as a non-USA person I am absolutely thinking of the depreciation methodology from international perspectives - although they do appear to be fairly consistent. I'm also mindful of xTuple's customer base and trying to keep the design aimed at small/medium business rather than an overly complicated system that possibly suits all.
I actually agree with jrogelstad regarding treating Fixed Assets as a type of item and storing them as inventory, hence you see my comments to that regard in the Specification. That would allow you to purchase and sell Assets, but retain them in a separate Fixed Asset account. However that will require significant changes to core xTuple and I was originally looking at Assets as a scripted extension module without having to modify core. But I am open to suggestions.
I think there are quite a few Asset specific attributes. To merge that functionality with Item we would need a new Item Type (Fixed Asset) which would then likely need to drive the screen to display new tabs to records attributes like depreciation type, asset life, residual value, etc. Also any future maintenance requirements will need to be included. As mentioned technical assets can move frequently so we need an easy way to record location/address. And to answer the above question, I was going to use the Address widget which allows you to reuse an existing address or create a new one.
lcartee's comments about multiple depreciation methods are correct however will greatly complicate the design - you are now talking about two or more chart of accounts and I'm not sure how that would be done in xTuple. We need to make a call regarding whether to build that in. I'm inclined to leave it out for the moment and focus on a single depreciation profile per asset that meets taxation reporting requirements.
Tue, 02/09/2010 - 17:43#23
scripted versus core
I certainly 100 % agree with you that just because someone does something that doesn't mean we have to and I did not mean to imply differently.
I certainly agree with using exisitng business logic. The posting and updating of general ledger transaction functions in the database can be used by any module or scripted extension. Outside of that I don't see any similarity in inventory transactions and fixed asset type transactions. Perhaps, I am wrong, but I have been thinking of this as an extension package built entirely with scripting and its own data base schema for some of its tables. The less reliant on exposing of core functionality to scripting the easier it is, in my opinion, to make a complete module entirely scripted. If there is something absolutely needed it can be exposed, but the more independent a scripted module can be, I believe, the greater chance of getting people to work and contribute who aren't capable of contributing C++ core code.
I understand the philosphy of sharing code so that if changes are needed system wide, change once and it is done. I also understand that if a change is needed for one process but not others the change is not always so simple. Too much shared functionality is sometimes what causes breaking exisiting functionality trying to create new from release to release. I am NOT talking about xTuple, only development in general. Like a lot of things too much of a good thing can become a bad thing. I also do know that users find it particularly frustrating when a new release adding some new functionality breaks something that was working. As I have said to you many times we all have the luxury of just spouting our opinions, but you have to make it all work, and you do it very well indeed. My personal development philosphy is that a lot of little pieces sometimes make more sense than one great big piece. Until, of course, you end up with too many little pieces to manage. This whole computing world we work in went from big central servers and "dumb" terminals to smart client machines and literally(in some businesses) dozens if not hundreds of special purpose servers. That old pendulum has been swinging back for some time now with powerful single servers running virtual machines, etc, etc.
There are not many absolute "right" answers to code development.
Sorry to be so long winded and get completely off track. More than anything, I just want to encourage thought processes before finalizing specifications.
Tue, 02/09/2010 - 17:50#24
Item/Fixed Asset combination
I also agree with John regarding combining a fixed asset record with an item record. There is just so much machinery that we get to reuse without too much effort (including moving between locations). It would need to be a new item type, so that we could control the tab display. Perhaps the fixed asset functionality is placed on a tab in item and enabled via the item type selection?
We should be OK adding another tab to the item via an extension based on what I've seen so far in the scripting interface. I'm not so sure what bad interactions a new item type might have.
I think we could allow for multiple depreciation methods using the same table that we would need to track for reporting. We could have a column for each method calculated, but only post through to G/L the method specified on the asset record.
Tue, 02/09/2010 - 18:02#25
Changing depreciation methods
Am I right in thinking that depreciation calculations would only be run once per accounting period and then posted (probably after the period was over)?. We'd need to avoid a situation where the depreciation method was changed on the fly and we had some transactions posted to G/L under one method as well as others using a different method in the same period.
Come to think of it, a change in method on an item could make backward looking reports a bit of a bear unless we really do keep track of calculations of all methods for each item vs. what was actually used.
Tue, 02/09/2010 - 18:13#26
OK, one more post and I'll wait for others to reply...
I just re-read what John mentioned about tooling (yay, btw). That really does point to the fact that fixed assets:
1) should be an item.
2) its an orthogonal issue to item type
We actually do end up manufacturing tooling which sticks around as a fixed asset. The other thing that happens is sometimes we start using one of our products internally, which means we convert an inventory item into a fixed asset (and pay use tax on it). Granted, this is infrequent and can be handled manually. But all of those scenarios suggest that an item have a check box for "Fixed Asset" which works much like the "Item is Sold" section.
Tue, 02/09/2010 - 18:28#27
Yes, typically depreciation calculations are run once for each accounting period. Yes, you are right about changing of methods could be an issue. I don't recall what any GAAP or IRS (no idea about international) rules are about changing depreciation methods for a specific asset, but I would think there are some. I really think some CPA advice is needed.
Isn't it interesting(or maybe irritating) how complex these things can get?
I'm reminded of Ned commenting in several places on this site why xTuple really wants to leave payroll alone. If government and taxes are involved it can become very complex very quickly.
With that being said, being the "devils advocate" that I am, perhaps this entire subject fits the payroll answer. There are many standalone products on the market tracking fixed assets and depreciation that require just a few journal entries each period(just like payroll) to get data into the financial reporting system.
Just a thought.
Thu, 02/18/2010 - 11:42#28
You are correct that the depreciation method can't change. Each class of fixed assets can have its own method of depreciation which can be different than the book method. The accounting treatment of a fixed asset really is different than an inventory item, and they are presented differently on the financial statements. There are a lot of fixed asset packages out there that can be reviewed to see how they function. Some of them operate as stand alone modules. You would usually want to use them for expensive assets or machines and not for supplies or small tools, which can get expensed. They are not treated the same way. Just trying to add an accounting perspective to the discussion.
Tue, 02/09/2010 - 19:28#29
Great feedback gentlemen!
Whilst I had thought about depreciation posting, I had not cemented my thoughts around changing depreciation methods. My accountant informs me you would not change the depreciation type (straight line to diminishing value) however there are other ways to change an asset (it could be the expected life of the asset or the residual value, or the DV rate). My thoughts are that we need to post adjustment entries in the G/L to reflect the new state of the asset. This could be a manual exercise or as part of the adjustment functionality (write-up, write-down) I was considering including.
I love a devils advocate - better decisions come from debate! And yes payroll is hideously complex to implement especially factoring in localised requirements from every single country. However I don't think we need to over complicate Fixed Assets and depreciation is likely no harder than some of the other xTuple functionality. I think the benefits of having an integrated system outweigh the complexity. That said, it is entirely possible the asset maintenance functionality I was considering may fall into the too hard basket.
Tue, 02/09/2010 - 19:43#30
I too would like to make one more post and then wait for others to chime in.
As far as multiple dpreciation methods, I don't think ZI explained clearly. Depreciation is calculated for each asset during the periodic run and all details are kept, but only one calculation is posted to the General Ledger.
I respectfully disagree with keeping inventory items and fixed assets in the same table or set of tables. The kinds of data that need to be stored for a fixed asset are not close to the kinds of data we need to store for an inventory item or itemsite. In my opinion it is that same old tired phrase "its apples and oranges". They a re just not the same.
Let's say I acquire three identical machines over a 12 month period. Are you all suggesting we carry those of three of the same item number. Let's say they are serialized and we certainly need to keep depreciation calculations separate because they were acquired at different times. Oh you say, we have serialized inventory. Perhaps we desire and can legally do so, to calculate each serial number's machine with a different depreciation method. So now each serial number needs it own depreciation method setup and and its own transaction history for each peiod and the running book value for each based on it's depreciation method. And, oh yes, Their costs are dramatically different because the manufacturer was closing out this model when we purchased the last machine. If and when significant maintenance or parts require adding to the depreciation basis it would have to be done by serial numbertoo, so fields for that data need to be available. I can only gasp at the number of linked tables and joins it might for this data.
If a company buys six new trucks any fixed asset system I have ever seen is going to create six separate fixed asset records and all the associated history. There will not be a quantity of six for one record.
Last thing. I believe the purchase of ERP software if reaching a dollar threshold can be capitalized and depreciated just as any other asset. Would you create an inventory item for xTuple?
Fixed assets are just not the same as inventory.
As always, just my opinion.
Tue, 02/09/2010 - 20:14#31
I was wondering when I was going to see intangible item capitalization in this discussion!
Perpetual software licenses, manuals and related, non-training labor of implementation (consulting & internal labor costs) should be capitalized and depreciated, and I believe this is a GAAP requirement. In practice, however, I've only been with one company where we capitalized software implementation related internal labor rather than expensing it (a public company with SOX requirements); moreover in that scenario we had to accrue all those costs to a CIP account (capital in progress) since depreciation couldn't begin until the software was 'placed in service'... on a two year long project, this mattered.
This is probably an edge case for most xTuple users, but is one factor leading me to the same conclusion that item may not be the best way to do this. Also consider that there can be a substantial number of Fixed Asset items relative to say manufactured items, unless there were good ways provided to filer this you could really muddle up the item master. I understand the desire though... so much of the application is there related to multi-site, etc. that item is a compelling structure to leverage for this sort of thing.
Steven C. Buttgereit
Tue, 02/09/2010 - 20:16#32
So much for asset=inventory
Yikes! I think you may have knocked over the house of cards.
While it would be quite nice to reuse inventory, you are right that we get into a nasty "item splitting" issue because items are kept in groups normally. You'd have to create separate item codes for each. We'd also probably have to make modifications to reports on inventory to exclude fixed assets which are masquerading as inventory.
I do recommend we reuse site/location functionality which seems to be the superclass of items and fixed assets (i.e. stuff that can be put somewhere), but it looks like reusing inventory would be opening the proverbial can of worms.
Tue, 02/09/2010 - 21:02#33
I said I was through, but I have to disagree with site/location also. Location might be the corner office(furniture), the employee break room,(kitchen equipment), salemen's automibiles, a satellite sales office, etc, etc. Just no relation to inventory site/location.
Tue, 02/09/2010 - 21:51#34
As mentioned in a recent xTuple blog post design is key and the debate on this thread is definitely helping to clarify requirements, issues and should end in a better result.
The above comments are absolutely correct, a dozen computers are not one item with an inventory count of 12. Although at one stage I was thinking of adding a Quantity field to the Asset record but left it off due to the potential for different purchase dates. And intangible assets are also not inventory as discussed.
So moving forward I suggest the following:
Per the Specification we treat Fixed Asset as an extension with separate schema and tables. For the first cut we do not implement purchasing or sales integration - manual creation of Assets only.
I'd like some more input around Larry's comments about multiple depreciation profiles and how we could handle that. I'm not sure the best method to assign multiple depreciation profiles to one asset and define which profile is booked to the G/L.
As a non-Accountant I need assistance with the different types of depreciation. Can we "hard-code" some types (such as straight line and diminishing value) or are there a bunch of other methods and do we need the setup of these methods to be configurable rather than coded?
David - I am happy to collaborate further with you if you want to split up some of the development effort.
Tue, 02/09/2010 - 22:11#35
I will be a seeing a former work colleague of mine who was (variously) controller and CFO for the company where we both worked on Thursday. If folks here would consider it useful, I can check with him for his insights related to depreciation methods that he would consider baseline methods to support and how many different flavors there might be to gauge whether it makes sense to worry about configurable methods vs. hard coded. We had some pretty robust fixed asset needs (300 locations in about 46 states) so the real danger would be getting carried away with it.
My belief is that for most purposes, there are a small handful of methods such as those mentioned and any others would be more exotic and not so applicable to the normal xTuple using company. Fixed Assets support in the various tier 2 and lower ERP suites I've worked with has generally been pretty simplistic in my experience and more sophisticated needs have typically been met by dedicated FAS products.
Tue, 02/09/2010 - 22:29#36
Dep. Types and Design
Personally I think that would be beneficial to get outside input. It would be specifically informative to know if all of the typically used depreciation methods can be generalized from a functional standpoint (i.e. input data about the item, # of periods over lifetime, the period to calculate to output a currency amount). If it can, then as part of the API we could implement the depreciation methods themselves as stored procs with a standard signature, making it straightforward for the end user to add other methods if needed.
Dave, I agree that it would be appropriate for this to be a standalone extension with minimal ties to the rest of xTuple. That will also allow us to move forward quickly with a first cut.
I'd suggest that the next step would be to start working out a database schema and include that as part this conversation. Once that is done, we can split work up however is easiest.
Phase 1 (Fixed Asset w/o tie in) will be sufficient for my company's purposes, so I'd be happy to assist with getting to a stable first cut per this Specification and then handing copyright for my work over to the community (or whatever entity would be appropriate).
Wed, 02/10/2010 - 07:36#37
I am a CPA has have been following this excellent discussion. One thing to consider is that the general ledger balances reflected in xTuple will normally be the "book" balances. For many small businesses that do not have external reporting requirements, the book balances will be the same as the tax balances. Also, most tax software applications calculate and maintain their own tax depreciation.
Straight-line depreciation is the most popular book method of depreciation, with the IRS adding its usually layers of complexity for tax calculations. With the USA ultimately aligning with International Financial Reporting Standards (IFRS), satisfying IFRS requirements, which are less complex, gets you to where you need to be for book accounting.
Perhaps a structure like the tax functionality in xTuple would work. Define expected life, initial (bonus)depreciation, diminishing factor (100% for straight-line, 200% for double declining balance, etc.) and other variables for the depreciation methods that you want to calculate. In this way a system would not be nationally or locally dependent.
Also, I'm not sure you really need to post directly from a fixed asset system, but use the reporting to calculate general ledger entries. In this way, changes to assets will be reflected in the accumulated depreciation numbers, and the current posting can tie to these accumulated numbers.
Wed, 02/10/2010 - 08:32#38
I agree this is far and away
I agree this is far and away the best discussion ever on xTuple forums.
I'm still not completely dissuaded that items would be a nice way to tie things together. Larry is right that the more things you do tie together, the more sensitive the intertwined linkages become. I did, however, envision that no changes would need to be made to the core to support that idea. I probably don't see leveraging potentially complex internal linkages as much of a deterrent because I have the advantage of working in xTuple code every day and know it pretty well. I could see how to folks who are newer or spend less time with it, and who aren't privy to every single core change coming through the product, may want to be less reliant on that infrastructure.
That said, the item master is a pretty stable area for the most part and has changed little in the last few years. And all I was asking was that you all consider this notion, which you have.
Whatever the outcome, I am thrilled by the idea of folks out there developing this extension and as I indicated by my initial response, we would be receptive to just about any approach.
With regards to depreciation, I guess I'd make a point that we've had pretty good luck thus far with xTuple using a development methodology where we always start by fulfilling a real life customer requirement, typically no more and no less. We get our fair share of criticism from folks who argue about what they think we should or could have built into the system, but by staying focused on real life requirements rather than hypothetical ones I link to think that over all we have stayed pretty true to the 80/20 principle (http://en.wikipedia.org/wiki/Pareto_principle). So the best advice I can give to whoever codes this is start by making this module do what you need it do, and just do your best to keep the door open to possible future requirements as you architect it.
Wed, 02/10/2010 - 09:22#39
Leaving the door open
It will be important for the first version to be simple and self-contained.
That said, I do not think that we will be painted into the corner with regards to the item/fixed asset distinction we discussed by keeping fixed asset as a self contained entity. I could see it to be very straightforward down the road to provide two additional bridge methods during fixed asset creation:
1. Create fixed asset from inventory - this would remove an item from inventory (must be in stock), copy over its details to a fixed asset record, then prompt the user for the rest.
2. Create fixed asset from PO line item (and add a Fixed Asset line-item option to PO) - same idea as above, but handles fixed assets which do not go through inventory first.
Of course you would keep a straightforward "Create" where the user is prompted for everything.
Similar idea would work on the Sales Order side of the process. And in both cases there really would not be much in the way of schema changes for the Fixed Asset module itself.
That all said, I'm not suggesting we do that for a first cut, as there are probably corner cases which would have to be addressed.
Wed, 02/10/2010 - 15:02#40
I think we are getting closer to a good starting point.
John's comments are appropriate in that those not working full-time with core development feel more comfortable with an extension. I also like the pragmatic approach of making the initial design fit a real world business requirement and extending to new requirements in later releases.
The way I am currently seeing it is depreciation is almost separate functionality from the Fixed Asset itself. We need to build the mechanism to record Fixed Assets and all of the appropriate attributes (which includes attributes required for depreciation, and in future for maintenance). Depreciation is a separate screen/calculation and we design that with some initial methods (Straight Line and Dimishing Value & ??). The depreciation method is recorded against the Asset Type (per the specification http://www.xtuple.org/FixedAssetManagement). When we run the depreciation function we will be able to select to run depreciation for Asset Types, All Assets, or individual Assets. Depreciation will post to a separate Fixed Asset Ledger where all details such as Purchase Value, Adjustments, Depreciation will be recorded. This may allow us to incorporate Larry's comments about Taxation versus Financial depreciation methods as we could key the ledger by some category and provide reports by those categories.
An aggregated summary of all asset transactions can then be posted to the main G/L.
This approach should mean new depreciation methods can be plugged in at a later stage.
David, lets collaborate our development effort offline. I can be contacted at dave AT anderson dot net dot nz
Of course any further design considerations will be posted on this thread.
Thu, 02/11/2010 - 13:06#41
I am glad I saw this. At the risk of repeating what has already been said. WOW! This is really exciting! Asset management functionality is an important component in and of its self and was lacking in the program. But most importantly, it is the necessary prerequisite to a full-fledged CMMS for maintenance management and fleet management modules and it also adds capabilities via the maintenance work orders to other service oriented businesses, rentals, etc. This is just great. Having the Asset base will open up a lot of possibilities. congrats.
Mon, 02/15/2010 - 16:34#42
If you're interested, and when and if you're ready, we'd be happy to set up a distinct Mantis "issues" project for this effort, and any other such infrastructure type support you might need. Just let us know.
Fri, 02/19/2010 - 07:45#43
Having only recently come across xTuple in a search for a new ERP, I am glad to see an active discussion regarding adding Fixed Asset functionality as this is a key item for our business.
We are a rental company, so in our case the fixed assets are heavy equipment. One of the things that our current (ancient) erp does is allow work orders against fixed assets (repairs) as well as generating revenue from them. I realize that this is an edge case but I would think that the system should be sufficiently flexible to handle it.
As part of our evaluation process we are considering developing our own Fixed Asset/Rental module. In speaking with the various people at our company we would be leaning towards an independent module separate from the inventory. The reasoning, for us at least, is based on the additional requirements that the rental functionality would add.
So I just wanted to throw that out there to the experts as a possible consideration for the specification development.
Mon, 12/13/2010 - 07:55#44
Fixed Asset Beta Available
To all who are following this thread I just wanted to point out that Dave Anderson has completed and published his Fixed Asset module set in beta form. There is a community version and a commercial version. You can read more about them on his blog here: