[Phpbalancesheet-devel] Thoughts and intentions

[James T. <jt...@wy...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

Firstly, I need to apologise for the lack of activity on the project.  
Although I am determined and committed to developing PHPBalanceSheet
into more than just a naff web-based front-end to a couple of simple DB
tables, to say I've been busy of late would be like saying Microsoft
wrote a couple of computer programs.  Every now and then, however, I do
manage to dip my toe into the project again.

Right, apologies out of the way, to business!  I've been having a few
thoughts for a while now, some of which I've written down and others
that I've sadly forgotten.  I want to try and get the development ball
rolling again, if possible, stimulate some discussion, get some input 
and feedback, and I want to bounce some ideas off people.  The ideas are
presented just as they come to mind.

I'm intending to make it so that users have to login to the
software.  They will have a user account, and each user account can be
associated with one or more businesses.  Thus, UserA might be the
accountant for CompanyA, UserB might be the accountant for CompanyB and
CompanyC.  When a user enters the system they choose one of the
businesses they are associated with and perform accounting operations
for that business.

Access control would be role-based.  So, UserA can only raise invoices
if he/she has the RaiseInvoices role.

Management of businesses and business users is going to necessitate an
admin user of sorts.  I'm currently thinking probably one admin user per
business, possibly the head accountant, who would allow his/her
subordinates to perform certain operations.

When we come to storing the transaction details in the DB, I want to
make it fully versioned, i.e. details of a transaction are never
deleted, only updated.  Changes would be linked to the user who made
them.  Thus, a full audit trail is possible, you can see who raised a
Purchase Order, who signed it off, who reconciled it, etc.

I'm having a bit of a mind wrangle with Clients/Suppliers and
Sales/Purchases.  Do we feel that we need to separate these entities, or
is it sufficient just to have one table for people we deal with, whether
Clients or Suppliers, and one table for transactions, whether sales or
purchases?  I'm thinking if I buy something from XYZ Corp, they're a
supplier, but if I return it and get a refund I want to be able to
reflect that as a credit.  I could do sale at negative cost, but that
just feels wrong....


OK, I think I've rambled on for long enough to give you something to
talk about.  Any comments, ideas, suggestions will be gratefully
received and taken into consideration.

Cheers,

JT
- -- 
- -------------------------------------+------------------------------------
James Tait, BSc                      |                       ICQ# 17834893
Web Developer and Linux advocate     |          Mobile: +44 (0)7779 337596
- -------------------------------------+------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iD8DBQE/VgQ6yDo4xMNTLiYRAjtYAJ9341zzxUh+iNq5DR95+WVNljYqhQCfQwi4
yN9Z1asf67ACx1+s1+f0fY8=
=HFgy
-----END PGP SIGNATURE-----