Inventory and payroll

[Christopher Browne]

On Tue, 12 Sep 2000 13:45:52 +1100, the world broke into rejoicing as
Conrad Canterford <conrad@mail.watersprite.com.au>  said:
> 
> OK, here are my thoughts on why we keep an inventory of shares in
> Gnucash. Please remember that I am not an accountant, so it is entorely
> possible I'm completely off track.
> 
> 1. The value of an asset must be revalued occassionally to determine
> their value as assets, and as Philip points out, this is best done by
> multiplying the current share price by the number of shares held.

That's reasonable...

> 2. Strictly speaking, this is not a part of the account recording
> function. The revaluation or devaluation of any asset should be recorded
> in the accounts, but is effectively an external activity, and only the
> results form a part of the accounts.

The conventional view is contrary to this; revaluations only occur
when some specific event takes place to cause there to be cause to
revalue the asset.

This is known as "historical cost accounting," and somewhat parallels
the way history is often viewed from the perspective of the punctuation
of wars; the events that are considered of importance are a subset of
all those that happen.

"Historical cost" ignores those events that do not involve some form
of transaction.  You can "make money" only when you buy something, sell
something, or some other reasonably comparable event occurs.  Watching
dust settle on stock on the shelf is not one of those events :-).

> 3. For convenience sake, we include this revaluation function in Gnucash
> because:
>   a. It will satisfy the requirements of a larger set of home users.
>   b. It is very simple to automate and still be sufficiently accurate.
>   c. It does not require much more information than is already
> contained.

Not.  The _serious_ problem with this is that it potentially pushes into
the system huge numbers of transactions that are associated with
_nothing happening_.

What the system should track is _not_ the "potentially continuous"
variations in value, but rather the transactions that are actually of
importance.

I would agree that there is lots of merit to having the ability to
_VIEW_ data using as flexible a set of "binoculars" as possible; that
doesn't mean having this inside the "engine."  

In the realm of SQL, that corresponds to the notion of database views.

> None of this makes the Gnucash stock account type suitable for serious
> business use.
> - The value of the asset is not trivial to calculate.
> - The amount of information required to be stored is considerably larger
> (and considerably less related to the accounts).
> - The level of detail and complexity required (due, if nothing else, to
> the extra information and the things needed to be done to it) is several
> orders of magnitude more complex.
>
> So,
> - the stock account type is a type of inventory.
> - it performs its function adequatly (I believe) for simple share
> holdings.
> - but it does not contain the details required for a full inventory
> control system.
> Which brings me back to my original point. I think the inventory control
> stuff should be a seperate (but fully integrated) application. I might
> be able to be convinced that it can be sensibly done as a scheme module,
> but it will require some more convincing yet... :-)
> 
> Make sense?

I think it would make sense to create a data structure for storing
transactions relating to transformations of commodities.  That would be
the basis for tracking the things that happen to inventory, and how they
relate to the more purely financial side of things.
--
aa454@freenet.carleton.ca - <http://www.ntlug.org/~cbbrowne/linux.html>
Horribly wedging my very own personal machine gives me a comfortable,
familiar, Lisp-machine feeling (like an old shoe), laced with that racy
hint of raw, cold-boot power.