Inventory and payroll

[Amit Sathe]

Message: 1
Date: Mon, 11 Sep 2000 18:07:57 +1100
From: Conrad Canterford <conrad@mail.watersprite.com.au>
Organization: Water Sprite Pty Ltd
To: gnucash-devel@lists.gnumatic.com
Subject: Engine, Inventory, Payroll, etc

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.

I think :
While payroll can be considered a separate apllication, the same is not the
case iwth inventory. Payroll is a once a month activity and besides in non
ERP based systems, the employee database would be the concern of the HR
department.

In case of many small businesses, the differentiation between purchase and
store departments  is ambiguous so that the same person can enter both the
quantitative as well as money transactions simultaneously. Here an
integrated system would be of advantage.


> 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?

yeah they could be developed as separate p[ackages one for accounting dept
and other for stores so that both depts can maintain their respective
records. But then what happens to costing if the quantitaive details are not
available in the accounting module ?
To receivables and payables an ageing schedule could be implemented, that
gives the number of days for which a payment is outstanding.

Regards

Amit Sathe
Pune, India.