Thread: RE: [Phpbalancesheet-devel] Accounts/Tables

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Sounds all good to me

My thoughts - as I work painfully through a huge excel accounts
spreadsheet propped up with coffee

Specific thoughts below but conceptually what I would like is as follows

An online accounts system that I can reference, my accountant can
reference or download from, that customers can get invoices from and
login and check their details, and bills. I imagine some people may need
an offline system but that=92s not really what I am after.

And I would be really happy with that. I do like php and mysql with DAO.

The other bit would be audit trails, user validation and thorough
security as my accounts are hard enough anyway without worrying about
someone else mucking around with them.

I would go with a module approach as accounting systems are split this
way anyway to charge more for them. It also makes delivery easier if
have simpler first up goals.

Cheers Duncan

Equity into the business e.g. cash shows on the balance sheet but is not
income or expense - it will reflect in the bank accounts and will depend
on whether it=92s a loan or cash injection.=20

However somewhere we need to draw a line - I desperately need a better
solution than what I have right now but if we tackle everything we will
be where I am now - which is a great dream but still not there.

I prefer accrual basis as cash works well if you pay things on time,
accrual is a bit more complicated though which is why lots of small
businesses have only cash books=20

For fixed assets (in NZ anything over about $200 that is not an expense)
we then need amortization rates and a description mechanism of the item.
We also get into working out the depreciation relative to any given
period. This is often a separate module though

Entertainment expenses in NZ (and I imagine its different around the
world) are sometimes fully deductible and other times not depending on
when and where it occurred and who with. This is the biggest impact on
SMEs, however also you can make expense claims for home office related
items which are then apportionments of your home costs - the system
probably just wants the raw details rather than the full mechanics of
calculation rationales.

Invoicing and receipts are interesting because then do we add a debtors
ledger and the ability to generate statements - the good thing with
invoices etc is that if we were clever customers could look at their
individual details online. But this requires handling recurring and one
off products and services, working out taxes, in NZ mostly GST,=20

The simple way to figure out whats in and out maybe to copy the module
approach of something like Mind Your Own Business or Quick Books and
debate which components are tackled at which point

-----Original Message-----
From: php...@li...
[mailto:php...@li...] On Behalf Of
James Tait
Sent: Thursday, 11 September 2003 12:33 a.m.
To: php...@li...
Subject: [Phpbalancesheet-devel] Accounts/Tables

-----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=3D"startday">
> <?
>             for ($i =3D 1; $i < 32; $i++) {
> ?>
>               <option value=3D"<? echo $i ?>"><? echo $i
> ?></option>
> <?
>             }
> ?>
> </select>
>=20
> 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=3D46 -- 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
- --=20
-
-------------------------------------+----------------------------------
--
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=3D
=3DnkcQ
-----END PGP SIGNATURE-----

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Phpbalancesheet-devel mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpbalancesheet-devel

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/08/2003
=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/08/2003
=20