Client--Server Implementation Model.

[Rishikesh Shukla]

Hi Mike,

Absolutely agreed with your point mike, even i was thinking of the same
thing. system should be audit-able and should have authorization.

So their must be one more module, called as authorization module, where you
can authorize one or more account to one or more people concerned with that
account and should be able to add, delete or modify the transactions. to
test it around we can apply this into desktop version also.  I hope you
agree with me.

Dear JOSH:
======

Here i need your help, you sounds like a coding guy, and believe that
earlier you were actively involved writing codes. Well i have gone through
the link that you provided, But i could not found any of the page which
provides the data flow digram and ER Digram as well. so can you provide any
such docs or links.

Secondly, i putting this mail to whole Development group also. As i could
not find any listing of the groups that handles the different modules, since
it has been mentioned in the docs at the beginning itself which shows
the requirement of the modularization.


On Fri, Nov 27, 2009 at 6:49 AM, Mike or Penny Novack <
stepbystepfarm at mtdata.com> wrote:

> I'm going to jump in here.
>
> Need to first take a closer look at the "business need" before jumping to
> "simultaneous access". The latter would "solve" the perceived need but in a
> way that may not be really appropriate. Let me explain.
>
> As businesses grow larger, transaction handling tends to become
> specialized. Might have an "accounts receivable" clerk who handles those
> transactions, sales clerks who enter that kind of transactions, etc.
> Normally you DON'T want people to be able to enter transactions of a sort
> not their area of responsibility, though of course a single person might be
> wearing more than one of these "hats". Using "simultaneous multiple access"
> would allow everybody to enter their assigned sorts of transactions to the
> main books BUT it would also permit them to enter unauthorized sorts of
> transactions.
>
> In really large systems this is handled by "feeds" to "general ledger".
> That might be the model we should consider. Not multiple simultaneous access
> to the main books but some way by which data might be moved from subsidiary
> (specialized) books to the main books and THAT doesn't require simultaneous
> access as can be a "batch" process. And yes, right now Gnucash would support
> "subsidiary books" (books that represent only a portion of the business).
> What we don't have is any way to automate "feeds" and transfers between
> these books. All well and good to have that a manual process when you are
> talking about once a month transactions between "petty cash" and "general
> ledger" with likely only a few accounts affected. Another thing were that
> A/R to general ledger on a daily basis with scads of customer accounts
> involved.
>
> Understand what I am saying? Were I the owner of a medium size business I
> probably wouldn't want the employees entering A/R or sales transactions to
> be able to even SEE the main books. Just their part of them.
>
> Michael D. Novack
>
> _______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
>



-- 
Thanks & Regards
Rishikesh Shukla