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