Some obversations:

a) Is this for a single entity, or are there divisions, branches,
departments involved? May need additional fields & reporting for this.

Single entity. There may be multiple offices but I think I have that
covered.

b) Printed output - reports of patients accounts, statements,
reminders & mailing, aged listings, trial balances, reportwriter access

There will be a "walk out statement" that will correspond to one SUPERBILL
and a "mail out statement" that will show activity that has an open balance.
Also I will need to provide AR reports and various productivity reports.

c) Cash accounting records not clearly detailed here - cash books,
monthly bank reconciliations

Not sure what you mean about cash accounting records? There will be a CASH
account, or more specifically two seperated by the source of the money
(insurance or patient). I'm not sure if bank reconciliation is necessary as
I'm not trying to replace the role of an accounting package (at this time).
In my current released version of my beta software I have set up a simple
single entry accounting system (basically just charges and credits) and have
run into some issues that are not too cleanly resolved (like refunds,
patient credits, reversal of write offs, et. al.). I want to do things in
more of an accounting way to better handle these issues and also I would
like the option to expand it into a full featured accounting system in the
future.

d) Budget figures required?

Not at this time.

e) Ledger account entries typically have an opening balance, a debit
column, a credit column and a (current) balance column, with
a date for each posting to each account.

Well my LEDGERACCOUNT table just defines the accounts and then the LEDGER
table stores each transaction. As far as the current balance goes, won't
that be a calculation? I mean I shouldn't necessarily store that I don't
think. The opening balance would be assumed to be 0 on all accounts, aside
from any data I convert into the system.

f) Are subaccounts required to provide a categorised breakdown
per account?

No, I'm trying to keep it as simple as I can at the moment.

g) Manual Journal entry functionality is commonly required

Can you please elaborate on this? In my application I plan to wrap up all
of these tables into various classes that will then move data back and forth
to the user inteface. My billing screen will have simple to use functions
for the user for any activities they would need. Basically this would
include the following functions: adding CHARGES, PAYMENTS, DISCOUNTS, WRITE
OFFS, INSURANCE ADJUSTMENTS, REFUNDS and then reverseing any of those. I
will not allow anything to be deleted once it is "posted".

h) Multiuser with access/role controls for security reasons

Well my system is definately multi-user and I have security. I would take
care of security at the application level. Basically my application has a
login, and my application controls what can be done based on the application
log in. (There is a single Firebird login embedded in the application.)

i) Ability to handle other accounting functionality - creditors
& suppliers accounts and payments, rent, repairs & maintenance,
vehicles, assets, equity & capital accounts etc

Yep, defiantely don't want to do that now. This is a pretty big task at the
moment. However I definately want what I do have to be done correctly so
that I can grow into that sort of thing in the future.

j) Year end accounting close off possibly months after the
actual end but still able to process & report on the new
year.

OK, now here is something I was wondering about. Why is this necessary? I
can tailor my reports to report on any period of time the user wants. Why
is it necessary to "close off" the account and functionally how would this
be done?

k) Reporting will be extensive - current output functions
will be a good guide to the level of complexity & transaction
volume, which will then indicate the type & extent of
storage & summarisation required.

HTH,
John

I guess to summarize what I am trying to do is that I want to have sort of
minimal accounting functionality done in a correct way so as to be flexible
and avoid problems I have encountered in my beta test so far and leave me
the option to grow accounting functionality in the future. However it is
not required to take the role of the accounting pacakge at this time. Thank
you for your insights! :)

-Anthony



[Non-text portions of this message have been removed]