From: James T. <jt...@wy...> - 2003-09-05 12:23:47
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Kenny, On Thu, 4 Sep 2003, kenny jeong wrote: > Hi,JT > > Admin functions, login, and logout are very important > for security purposes. Agreed. The POC version that is currently released was basically a means to an end, that end being my wife wanting to fill in her tax return. As a result, none of this was ever needed, but since I intend to extend the target audience and make the software more fully-featured these features are going to be absolutely necessary. > A client can be a supplier also. If you want to check > a person who has done business with you, you may want > to know the buy/sell transactions between you and the > person, including return of sales or return of > purchase. This was my thought, hence the question of separating clients and suppliers. I've had cause in my time to use Microsoft Money, and I seem to recall that when creating a transaction both were listed, regardless of the type of transaction, but grouped into suppliers and clients. Perhaps, then, a single table with a flag would suffice. > How about employees, They count as an expense, and hence would currently fall into the category of suppliers (they supply a service to you). This may well change in the future. > owners/shareholders and others? I haven't thought of these. Suggestions? > For dates, you may not want users to enter 02/30/2003 > or 09/31/2003. I believe that the use of real date is > better. I used the php date functions. In what way do you mean "real" date? As in "3rd October 1921"? If it's just the general input (and output) format you're thinking about, this will be made configurable, probably on a per-user basis. > Some accounting transactions are not sales/purchases, > such as loan transactions, investments, etc. No, but they are expenses. I realised this when we came to enter transactions for my wife's business loan. I think it's just a case of bad naming, as I can't think of anything you'd want to include about one specific type of transaction that wouldn't be equally applicable to others. > I tried to write some codes to prepare General Ledger, > Trial Balance, Balance Sheet, Income Statement or Cash > Flow Statement, but I found that there were limits > with the database structure. I believe that the tables > should be improved first. Definitely! This is where the bulk of the work is going to come, as the UI is basically nothing more than a simple interface to the DB. I think most of the reports you mention can be created, but it's far too much work at the moment, and worse than that it's work that should be possible largely in the DB, but because of the poor DB structure it falls to the PHP code to perform it. Once the DB structure is improved this will be much easier. > What is taxable? What is non-taxable? For income tax > purposes, for sales tax purposes, or for something > else? A common user may not be able to use the > taxable/non-taxable feature unless he understands the > tax laws. Taxable/non-taxable are referring to income tax. This is again a result of the original purpose of the system. I didn't envisage people wanting to use the software to manage their personal accounts, hence this field would always be relevant, but now you mention it.... :) > How about delete this feature? Deleting it isn't an option, as my wife needs it to be able to complete her tax return correctly. We could make it a configurable option, though. I'm not sure how we would go about it... we don't want people using it for business use (hah!) not having the taxable/non-taxable feature available, but people using it for their own personal accounts may not find it relevant. Perhaps this could be turned on/off on a per-business (where a business may in fact be an individual just keeping track of their personal accounts) basis? > Thanks, > > Kenny Jeong Thanks for your input! 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/WIAAyDo4xMNTLiYRAniyAKCqn/s5HEM5IsMvN+pMqSCvo73EUwCfffZs g2JioTyP4dR5mH+QQglXKxs= =6x8Q -----END PGP SIGNATURE----- |