Engine, Inventory, Payroll, etc

[Dave Peticolas]

Conrad Canterford writes:
> Hi all,
> I've now got the situation where I really need to think about
> implementing some serious inventory stuff, and would find payroll really
> useful as well. I was thinking about how this would be best implemented,
> and I have come to some conclusions and suggestions which I'd like to
> pass by people for comment. It is nothing dramatic, but I think it
> should be clarified now, before too much development happens based on
> wrong assumptions.
> 
> There is an implication in the doco that the (current :-)) plan is to
> implement all the "business" functions as part of the one "gnucash"
> application. Having become extremely proficient at cursing and swearing
> at StarOffice for its memory (and processor) footprint, can I suggest
> that this is a Bad Plan (especially for those that don't require this
> extra functionality).
> Since the plan already entails a separation of the GUI and engine, I'd
> propose that the better solution is to clearly and explicitly publish
> the "correct"/"supported" interfaces to the engine, and leave such
> stand-alone applications out of the picture, so-to-speak.
> An inventory control program would only need to appear to the GnuCash
> engine as (effectively) another GUI. Similarly for a Payroll
> application. This leaves the way open for other people to produce
> specific applications for their purposes, but still have them interface
> with the main engine. For that matter, it would allow someone to develop
> a M$ Windoze GUI that can talk to the engine, for those big corporates
> that still believe in spending too much money on useless software, and
> not enough on the real software. 
> It would not need to be a separate interface for each type either - the
> same sort of things that get done by the GUI now would be what you'd be
> sending to GnuCash anyway. One general engine interface, and people can
> develop their own add-ons as required (inventory, payroll, job costing,
> accounts receivable/payable, etc).
> This would mean that the inventory, payroll, etc. applications could
> then be "spun off" as separate development efforts.
> 
> Any thoughts, comments, or gaping holes you see in my logic?

No flaws, but one thing you might consider is implementing the
inventory and payroll functions largely in scheme and only loading
them if needed. That way, all the modules could be included in a
GnuCash distribution, but only loaded when actually used, hopefully
preventing the bloat you are trying to avoid.

I presume that the inventor/payroll functionality would need to
use the register? I've been meaning to make the register configurable
from scheme rather than being hard-coded and this would give me some
impetus to do that.

dave