phpbalancesheet-devel — Mailing list for people interested in helping to develop PHPBalanceSheet

[Phpbalancesheet-devel] Any Users Out There?

[James T. <jay...@us...>]

Ladies and Gentlemen,

It may have slipped your attention that you ever signed up to this
mailing list, it's been so long since anything was posted here.  The
simple fact of the matter is that, apart from a couple of minor tweaks
here and there, development of the PHPBalanceSheet project has been
non-existent -- I've simply had other things to do.

A few weeks ago, I came across the SQL-Ledger project[0] which seemed,
at a brief glance, to have achieved what I set out to do with
PHPBalanceSheet.  Since that project is maintained and actively
developed and this one hasn't been, it occurred to me that perhaps I
should call it a day and kill off PHPBalanceSheet once and for all.

Before I did this, however, I wanted to be sure that no-one was on the
lists waiting with baited breath for me to release something or wanting
to take over the project, what little of it there is.  So please, if you
have any objections to me closing the PHPBalanceSheet project, get in touch.

If I haven't had any reponses by the end of the week, I'll set things in
motion to have the project shut down, as it seems to me that all it is
providing at the moment is an extra hit in the results list for
potential users to check out, get confused by and discard.

Many thanks,

JT

[0] http://www.sql-ledger.org/cgi-bin/nav.pl?page=about.html&title=About

Re: [Phpbalancesheet-devel] Accounts/Tables

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

Hi Duncan,

I'm going to do my usual trick of replying inline....

Duncan Turnbull wrote:
> Sounds all good to me

Oh good. :)

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

This sounds painfully familiar....

> Specific thoughts below but conceptually what I would like is as follow=
s
>=20
> 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 nee=
d
> an offline system but that=92s not really what I am after.

I went with an online system for exactly these reasons.  It's=20
accessible, it's portable, it's extensible.  If you're an accountant=20
contracted to several different clients, you can use the same system for=20
all of them.

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

It's good to get some approval, thanks. :)

> 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.

Indeed.  User validation at every level, to prevent people side-stepping=20
authentication checks.  Audit trails are vital.  I intend to handle this=20
by "versioning" the transactions if they are modified, e.g.:

TRANS_ID   |VERSION|CLIENT_ID|AMOUNT|USER_ID
-----------+-------+---------+------+-------
           1|      1|       42| 12.34|      1
           1|      2|       42| 56.78|      2
           1|      3|       43| 56.78|      3

Here, the User with ID 1 entered the original transaction, to the client=20
with ID 42, for the value of 12.34; then, the User with ID 2 modified=20
that transaction so that the value was 56.78; finally, the use with ID 3=20
modifies the transaction again so that the client ID was 43.  This way=20
we have full visibility of the history of the transaction, including=20
what changes were made and who made 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.

True.  I've had a couple of thoughts about this (e.g. plugging in an=20
invoicing module to produce PDF invoices), but haven't really come up=20
with anything concrete as yet.  I'd value any suggestions.

> Equity into the business e.g. cash shows on the balance sheet but is no=
t
> income or expense - it will reflect in the bank accounts and will depen=
d
> on whether it=92s a loan or cash injection.=20
>=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.
>=20
> 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

Again, I'm going to show my complete ignorance of anything more involved=20
than the absolute basics of accounting here.  My wife normally works on=20
a cash basis, except for two clients who work on accrual (going purely=20
by your definitions).  Thus far this hasn't been a problem, but I have a=20
feeling my current solution is going to be woefully inadequate.

> 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

Could this not be worked out manually (yuk! :P) and entered as standard=20
transactions, at least in the beginning?

> 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.

I'd tend to agree with that, again, at least in the beginning.  If we=20
can get a basic functioning accounts system first, then we can add the=20
more complex behaviour later.

> 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

I'm wondering how much of a problem the regional differences in tax laws=20
are going to be.  The last thing I want to do is make a system that only=20
works for me!  I don't think (tentative...) that allowing customers to=20
view their accounts with us would present too much of a problem.  We=20
just have to be really careful about security.

> 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

I've not use either of those packages, unfortunately, but if you have=20
experience of them I'd appreciate your views -- descriptions of the=20
modules they provide, how functionality is split, etc. would be good.=20
It all helps to work towards a general development plan.

Cheers,

JT
--=20
+-----------------------------------+----------------------------------+
| James Tait                        | ICQ# 17834893                    |
| Web Developer and Linux advocate  | http://www.wyrddreams.org/       |
+-----------------------------------+----------------------------------+

[Phpbalancesheet-devel] Accounting Issues

[kenny j. <jeo...@ya...>]

Hi, Jame,

I agree with Duncan for the following points: 
 
1) "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."
 
It is why we need an web based accounting system.
 

2) "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 its a loan or cash injection." 

For cash investment: shown as CASH and EQUITY on the
balance sheet;
For property investment, for contributed a used
computer: shown as 
FIXED ASSET and EQUITY.
For loan from shareholders/partners: shown as CASH and
LIABILITY
 
3)"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."

Depreciation and amortization schedules can be handled
by Excel 
efficiently. 
A general purpose input form for depreciation and
amortization is good 
enough.
A general purpose input form can be used for fund
transfers between two 
bank   accounts,bad debt, credit memo, debit memo,and
more.  

It is better not to worry about the depreciation and
amortizartion 
schedules at this point because the users only need to
input two figures: 
Depreciation Expense and Accumulated Depreciation, or
Amortization 
Expense and Accumulated Amortization(or directly
CREDIT the amortizable 
asset account).
 
4) "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" 

It is not very hard to generate the reports with PHP
and MySql.
  
*****************************
Followings are for James' questions;

5) Accounting methods: it is not a big issue for the
accounting program 
if the accounting program allows the users to make a
choice. It means 
that the program must be able to handle Accounts
Receivable and Accounts 
Payable.

6) Buy and sell of business properties, such as
equipment and 
furniture: is it taxable or nontable?
 
Actually, it is the depreciation and amortization
case. See #3 above.

7)Inventory: when a user records the purchase, he also
needs to record the number of units purchased; when
the products are sold, the user records the number of
units sold. Anything onhand is the 
$ending_inventory=$unit_on_hand*$unit_cost. If the
number of units is too low, reorder.

8)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?"

If a business is making a profit, it may need to pay
income taxes. Income taxes may or may not tax
deductible, but a business needs to record the amount
of income taxes that it has to pay, how much it has
paid and when. 
This is the tax payable situation.

9)The methods of payments: paid by check,cash,credit
card; payment term, such as, 
COD,Due on Receipt, 1% 10 Net 30, 2% 10 Net 30, Net
15, Net 30, Net 60.

A business needs to know how the purchases are
paid,where the money is going; 
A business also needs to know if a customer has paid
on-time, has not paid a bill, how late. What the
collection actions should be taken.

A business should need to know how much it owes
others, how late.

With the above information, it is easier to generate
the Accounts Receivable and Accounts Payable reports.

10)Date: Would you please review this one that I am
using?

<select name="date">
<?
$i=0;
while ($i<1825){

$date = date("Y-m-d",date("U")-$i*24*60*60 );
?>
<BR>
?>
<option value='<? echo $date; ?>'><? echo $date;
?></option>

<?
$i=$i+1;
}

?>

</select>

*************************
11)I am an accountant, but I am not a programmer. I
started to learn PHP and MySql in May after I
installed your Php Balance Sheet. I am still learning
the basic things of PHP and MySql. 

I copied something from PHP Balance Sheet and wrote
something. It is for my learning purposes and it has
not be completed yet, but I know that I have to make
lots of improvement. I will rewrite the whole thing
when I learn more about PHP and MySql.

You may look at my homework at
http://www.cpaea.com/accounting



Thanks,

Kenny Jeong 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

RE: [Phpbalancesheet-devel] Accounts/Tables

[Duncan T. <du...@e-...>]

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

[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-----

[Phpbalancesheet-devel] tables

[kenny j. <jeo...@ya...>]

Hi,James,

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.

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.

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

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.

*******
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. 

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.

Thanks,


Kenny Jeong 

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

[Phpbalancesheet-devel] Accounting

[kenny j. <jeo...@ya...>]

JT,

I still have other questions for you.

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

2)Accounting methods: cash basis or accured basis.

3)Buy and sell of business properties, such as
equipment and furniture: is it taxable or nontable?
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. 

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. 

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. 

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

7)The methods of payments: COD,etc.

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

These are some basic accounting issues.

Thanks,

Kenny Jeong

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Re: [Phpbalancesheet-devel] Clients/Suppliers

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

-----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-----

[Phpbalancesheet-devel] Clients/Suppliers

[kenny j. <jeo...@ya...>]

Hi,JT

Admin functions, login, and logout are very important
for security purposes. 

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. 

How about employees, owners/shareholders and others? 

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. 

Some accounting transactions are not sales/purchases,
such as loan transactions, investments, etc.

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. 

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. How about delete this feature? 


Thanks,

Kenny Jeong

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

[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-----