[Phpbalancesheet-devel] Accounts/Tables

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

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

Hi Kenny,

I'm going to paste both of your mails into one and reply that way. :)

> 1)Owners/shareholders invest money or properties into
> business: it is not income, and it is not expense.

True, but it has to be reflected as cash injected into the business,
right?  I'm not an accountant, so please do correct me if I'm wrong, I
need to understand this stuff better.

> 2)Accounting methods: cash basis or accrued basis.

Hmmm... I'll have to ask an accountant friend about that one. :)

> 3)Buy and sell of business properties, such as
> equipment and furniture: is it taxable or nontable?

I think that's tax-deductable.  For example, if my wife buys a new mop
and bucket and a load of cleaning materials, that expenditure goes on
her tax return as operating costs, reducing her tax bill.

> You may not deduct them in one year. Users may need to
> compute depreciation/amortization?
> They also need to know the basis of the properties.

OK, good points.  Any suggestions as to how we handle these?

> 4)The users may receive money from clients for sales
> made last year; The users may also make payments to
> suppliers for purchases shipped last year. The users
> may need to get information regarding to Accounts
> Receivable, Accounts Payable, Notes Receivable and
> Notes Payable.

I'm not sure how this is normally handled.  As far as I know, my wife
gets payment more or less as she provides the service, so I don't think
we've come across this situation. :)

Accounts Payable and Accounts Receivable... couldn't they be handled by
only selecting those transactions that haven't been reconciled?

> 5)The users may purchase $100,000 inventories this
> year, but they only sell $50,000 this year. They need
> to count inventory monthly or every year.

Good point.  Suggestions as to how we handle this?

> 6)Users may have to pay taxes. Some are tax
> deductible, but some are not.

I'm not quite aure what you mean here, could you elaborate?

> 7)The methods of payments: COD,etc.

I hadn't intended to keep track of this, the reason being that I didn't
see that it added much value, except perhaps where payment was by
cheque.  Feel free to convince me otherwise. :)

> 8)Types of business entities: sole proprietorship,
> partnership, LLC, corporation, trust.

Yes, these do need to be kept account of.  I had envisaged a separate
table for the individual business details, including name, address and,
as you say, the type of the business.

> 1) I believe it is better to have a table for account
> numbers, and the fields should be: account_number,
> account_title, account_type (such as current asset,
> fixed asset, other asset, current liability,long-term
> liability, equity, income,cost of goods sold, expense,
> other income, and other expense), and
> active_or_inactive. Account numbers should not be
> deleted if they have been used.

Yes, we currently just lump everything in together as though it's in one
account.  I'm aware of this and agree that we need to look at proper
account handling.  I'm happy to use your suggestion as a starting point.

> For the two tables, payment and receipt, it is better
> to add a field for account numbers. It is not
> necessary to have a field for taxable/non-taxable if
> account numbers are used.

I can imagine the two tables actually becoming one, tracking just
"transactions" rather than "payments" and "receipts".  Some receipts are
taxable, some are not, likewise some payments are tax-deductable and
some are not.  I'm not sure that keeping track of accounts would remove
the need for that field.

> With these information, it is easier to generate
> income statement and balance sheet.

Agreed. :)

> I can create the general ledger report without the
> account_number table. However, the balance sheet
> accounts should show beginning balance and ending
> balance, but income statement accounts should show
> only the total amounts for each income statement
> accounts, for the selected period such as 01-01-2003
> thru 12-31-2003.

OK, we can maybe look at these reports once we've got a better idea of
how the accounts are going to be managed.

> 2) From dates.php:
> <select name="startday">
> <?
>             for ($i = 1; $i < 32; $i++) {
> ?>
>               <option value="<? echo $i ?>"><? echo $i
> ?></option>
> <?
>             }
> ?>
> </select>
> 
> Users may make some stupid mistakes, such as choosing
> 02-30-2003, 04-31-2003, 06-31-2003, 09-31-2003, or
> 11-31-2003. These are incorrect dates. There may be
> some problems if these errors are stored in database.

Agreed, currently there is no validation whatsoever on the dates.  That
just about matches the state of the entire system, it's just a first
tentative stab at how things might work.  In a proper version there
would be JavaScript validation at the view layer and extra validation at
the control layer.

> 3)For the equity section of the balance sheet: it is
> different for different type of businesses (sole
> proprietorship, partnership, LLC, C-corporation,
> S-corporation, and trust). It is better to add a table
> for keeping the business information, including the
> name of the business, address, phone, fax,
> website,email,type of business, accounting method,
> year-end date, user-names and passwords,etc.

Agreed -- see comments above. :)


As you may have gathered from the general tone and content of the
discussion, I'm not an accountant, but I'm determined to make this a
system that accountants can use.  Things are still in the very early
planning stages really -- the PROOF_OF_CONCEPT release is exactly
that; it was a result of me playing around with PHP and MySQL and coming
up with something very basic to fulfill a need.  I decided to release it
because:

  a) I thought it would make an interesting project
  b) I didn't see anything similar for Linux (GNUCash perhaps?)
  c) I wanted to improve the software and get people involved
  d) I'm not an accountant and could do with some guidance
  e) I don't have a lot of time, and could do with some help

Now the real work is starting.  It's one thing to have a basic system
that was knocked up in a couple of hours, but a true accounting package
is going to take longer.  I appreciate your input and help so far, and
hope you're not put off by my naivety, especially where accounting
principles are concerned.

You may also gather from some of the comments above that I'm intending
to employ the classic Model-View-Control design pattern (I'm from a Java
background, so that's my comfort blanket).  I'm looking at using PHPMVC
(http://www.phpmvc.net/) for that.  I'm also intending to employ the DAO
pattern (again, my background comes into this).  I've had a couple of
PHP DAO implementations recommended (I believe pear::DB was one, see
http://pear.php.net/package-info.php?pacid=46 -- there were others, but
I don't have the names to hand).

Anyway, enough of my rambling for now, I don't want to turn what's so
far been a useful and productive discussion into the "James Tait
unrealisable dreams show". :P

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/Xxn4yDo4xMNTLiYRAkg+AJ9I8E5Upvlx7Lbi4GpsFKQTjIUIrwCgiKvz
r78ErgqJ/hiSEnX68supKWI=
=nkcQ
-----END PGP SIGNATURE-----