Inventory and payroll (long, sorry)

[Conrad Canterford]

Robert Graham Merkel wrote:
> When you say a "seperate, but fully integrated" application, it sounds
> like a bit of an oxymoron to me.  If it is integrated, it thus depends
> on interfaces to the other parts of GnuCash.

Yes, but I am worried about there being produced something that is
usable for some people, but unusable for others. Because it is "part" of
gnucash, it may:
- dissuade people from using/producing other software that can also be
integrated into gnucash as an addition/substitution.
- be messy, complicated, and/or excessively time consuming for
alternatives to be put in its place, even if people do produce them.
- the above points may cause "functionality bloat" and a debugging
nightmare as people add their required features to the already existing
software, rather than producing an alternative.

I felt that a SBFIA (thanks Dave :-)) would avoid these problems by
being more obviously disconnected from gnucash proper. Please understand
that I was not planning on taking it away from the gnucash "family" -
just making it something that was clearly optional and able to be
replaced with alternatives if required.

Bear in mind that I'm envisaging payroll and inventory both being able
to use this interface. Payroll could be a nightmare to produce in any
case, as each and every country potentially do things differently.

> At a very simple level, to make an inventory system you need three things:
> 1) An "engine" to keep the inventory records.
> 2) A "reporting ssystem" to analyse data from the engine and prepare
> reports.
> 3) A user interface to get information in and out of the engine and
> reporting system.
> This is, in a rough sense, the kind of structure we have in GnuCash
> already.

Yes.

> The "reporting system" of GnuCash is quite suitable for preparing
> inventory reports already.

Provided that it can talk to the inventory engine.

>  The user interface is also quite suitable
> for inventory work (with some adaptation necessary) and there are
> substantial benefits to having a unified user interface rather than
> two separate applications.

This I'm not so sure about. I'm not familiar with the way the GUI stuff
works now, but again, I fear adding additional complexity and memory
footprint for stuff that the majority of users won't have the slightest
interest in.
I also have concerns with allowing every user access to everything, but
this is more of a multi-user issue than an inventory/payroll issue, and
is very solvable.

> The engine requirements for storing inventory details are somewhat
> different to the financial accounting system.  There is no reason,
> however, that a somewhat decoupled "inventory engine" can't be
> written with a defined interface between it and the rest of the engine

Assuming that it doesn't suffer from the functionality bloat problem, or
(ideally in my mind) we have some way of saying to gnucash "this is the
engine and gui components you will use for inventory" (or payroll,
etc.), allowing different engines (presumably with matching gui's) to be
substituted as required.

What I had initially envisaged was something that would just look like
another GUI to the gnucash engine, but which would have its own "engine"
(although I wasn't thinking of it using that term) to contain the
inventory stuff.

I must confess that I have been clarifying my thinking while working
through this on the list, and I'm not sure that there really is that
much need for a separate inventory system (although I don't really know
how other people do their inventory management, so I could be wrong).
However, I do think that the payroll stuff needs to be substitutable to
allow different systems depending on the country or whatever. It just
seemed logical at the time that the same interface should be used by
both inventory and payroll.

> As for Scheme, while we like Scheme, I think the general consensus
> around here is to stick to C in the engine.

That makes it a bit more likely that I'll contribute something useful,
and not just flood the list with comments on the appropriate philosophy
of development  :-).

Conrad.
-- 
Conrad Canterford (conrad@mail.watersprite.com.au)
Water Sprite Pty Ltd   | info@mail.watersprite.com.au
 GPO Box 355,          | Incorporating:
 Canberra, ACT, 2601   |   Australian Tour and Event Management (ATEM)
 Australia.            |   Ticketing Services Division
Phone: 0419 122 553    |   Catering Services Division