It's not clear what you mean by that the calculations are too complex.
Perhaps you're talking about extremely complicated commission rates, or
perhaps you doing some kind of simplex algorithm and calculation on stock
market values to come up with a type of bid for a stock.
however, if you're just talking about some type of classic ledger sheet who
we are entering account numbers and amounts, then I assume they approach
could be as follows:
you could build a report that groups by teach organization.
I would then build a sub report that has all of the expenses for that
organization.
I would then build a sub report that sums up all of the payments made by
that organization..
you could then have your report gave you the difference between the two
values.
and do not work
like they would in Excel, where it's easy to put something like this
together
with their formula functions.
If it's so easy in excel, then why aren't you using excel? Furthermore, last
time I looked there are several well known accounting packages in the
marketplace, and none of them are built and based on excel, but there is a
good number of accouting packages based on MS access. The very popular
simply accounting package is in fact based on MS access files. The folks at
simply accounting of course changed the file extension, but you can in fact
open simply accounting files directly with MS access.
I guess I'm pointing the above out, because MS access is a different beast
than that of excel, and your traditional approaches in excel that you used
will not work in MS access, and they won't work also in PowerPoint either.
The old saying about if you view every problem as a nail, then the only tool
you're going to want to use is a hammer.
Basically, I've got all the information entered into a table and I have a
query written to pull out individual accounts, but when I go to put those
into a report that does the calculations, I can't get it to work properly.
I suspect that you actually need a few tables here. I would assume you have
a table of organizations, this will allow you to have to contact
information, phone numbers, things like mailing address etc. Each
organization only needs to be entered ONCE into the system.
I would then probably at a table of payments made, and then another table of
expenses or cost items. (Or perhaps just make this one table, and have a
column called credit, and debit, and also other details such as was a paid
by check, visa etc...and of course a payment date).
So, at this point we're up to 2, or 3 tables already.
The current balances owing can be calculated by taking the difference
between payments made, and expenses (debts) for that particular customer
(account).
You could also take a look at the sample accounts ledger database at the
template library of Microsoft, but keep in mind these templates can be quite
simple examples:
"Accounts ledger database can be found here:"
http://office.microsoft.com/en-us/templates/TC010175341033.aspx?pid=CT101426031033&WT.mc_id=42
At the end of the day, I think it really comes down to how you actually plan
to enter this information into access. If the whole thing is just one big
table values that you're entering in over and all over, and you're copying
things like company information over and over, then this is not a data
normalized design. You might just as well stick to excel. However even in
these cases MS access generally a better reporting tool because it can
generate totals by each account for you.
Also, how you build and design the interface for the users to use this
application, is another issue you need to consider. For example, if all
payments or debts to a particular organization are always done at the same
time, then you'd build a form to display that organization, and enter the
numbers into a sub-form. This design would work well if you're dealing with
one client on the phone at a time for example. This design also means that
if you have to enter 4-5 items for that one company, then you'll not even
have to type the vender account number over and over again.
On the other hand, if your given a pile of receipts from all kinds of
different organizations in a big box at the end of the month, then you're
dealing in doing data entry for one different organization right after
another (or even better yet simply a one different account number after
another). In this type of scenario I would suggest that you build a ledger
style sheet that allows you to enter the account number, and then the
pertinent details (however, I still to suggest for rapid data entry that you
do build a table of organizations and their particular account number - the
advantage of this is you will NOT be able to enter illegal account numbers
during data entry). The other reason why I'm suggesting one table of
organizations (or account #) is because then that single defined list of
legal organizations (or legal account#) also becomes the source for your
grouping options in your reports.
The beauty of a relational database system is then you can say give me
totals for all of the account# (or organizations), and this tends to be a
lot easier in MS access to them that of using excel. And if done right, it
also tends to be less data entry work then using excel...