Tracking Database

"Howard" schreef in bericht ...

P.S. I'm enjoying all the "trolling for work" comments.
--
Howard

Making these comments in not an enjoyable task. I am *not* enjoying this 'game'.

But since you are the OP:
What's *your* opinion on this?
Do you think this 'offer' from PCDatasheet added to your question?

Arno R

Arno R,

I apoligize. I didn't mean to imply that it was enjoyable from your
perspective.

No, the offer did not add to my question. Is it possible to have a forum
where people could advertise their services or request help they are willing
to pay for?
--
Howard


"StopThisAdvertising" wrote:


"Howard" schreef in bericht ...

P.S. I'm enjoying all the "trolling for work" comments.
--
Howard

Making these comments in not an enjoyable task. I am *not* enjoying this 'game'.

But since you are the OP:
What's *your* opinion on this?
Do you think this 'offer' from PCDatasheet added to your question?

Arno R

"Howard" schreef in bericht ...
Arno R,

I apoligize. I didn't mean to imply that it was enjoyable from your
perspective.

No need to apologize Howard. I know and understand that some comments are 'fun'.
I just would like other people to comment also. I am getting a bit tired of all this.
I was just asking your opinion since Steve always states that he is such an enormous help to the poor posters here...

No, the offer did not add to my question. Is it possible to have a forum
where people could advertise their services or request help they are willing
to pay for?

We do have 'rules of conduct' here that condemn advertising and jobhunting of any kind.
Steve just doesn't give a **** about it.

There are groups where one can ask for payed help indeed I guess.
But IMO the spirit of newsgroups is to provide FREE help.

Arno R

OK - here are some suggested starting points for tables:
---

tblClients (note that this could also hold other entities, such as
payees, payers, etc. - if you do that, you might want another
table called tblRoleTypes where you can store what role(s)
an entity can have)
ClientID (primary key)
ClientName
ClientAddress
(etc.)

tblReturnTypes
ReturnTypeID (primary key)
ReturnTypeName

tblReturnProcessTypes
RetProcessID (primary key)
RetProcessName

tblProcessorTypes
ProcessorTypeID (primary key)
ProcessorTypeName
ProcessorTypeAddress
(etc.)

tblReturns
ReturnID (primary key)
ClientID (foreign key to tblClients)
ReturnTypeID (foreign key to tblReturnTypes)
(etc.)

tblReturnProcessing
ReturnID (composite primary key with RetProcessID --
and with ProcessorTypeID if more than one processor
is possible for a single process type)
RetProcessID (composite primary key with ReturnID --
and with ProcessorTypeID if more than one processor
is possible for a single process type)
ProcessorTypeID (possible composite primary key with
ReturnID and RetProcessID)
DateSubmitted
DateCompleted

tblPaymentTypes
PaymentTypeID (primary key)
PaymentTypeName

tblPayments
ReturnID
PaymentTypeID
PaymentAmount
PaymentDate
PaymentToWhomID
PaymentFromID
(etc.)


and so on....
--

Ken Snell
MS ACCESS MVP




"Howard" wrote in message
...
Ken,

We'll track the prep and filing of tax returns: when an analyst has
reviewed
a return and sent it to our tax vendor for processing; when tax info has
been
sent to the trust beneficiary; when the return has been filed. We'll store
all payments made by the trust which include balances due and estimated
payments. And we'll track filing info: date filed, returns on extension
etc. All this would be for federal and state returns.
We'll have various reports.

Thanks again for your suggestions.

P.S. I'm enjoying all the "trolling for work" comments.
--
Howard


"Ken Snell [MVP]" wrote:

You'll need to specify some details about the data that you want to
track/store.

--

Ken Snell
MS ACCESS MVP

"Howard" wrote in message
...
Ken,
Thanks. One more thing. Do you have any suggestions about setting up
the
relationships between the tables?
--
Howard


"Ken Snell [MVP]" wrote:

If the account number is recycled, then it cannot be the "primary key"
of
the table in which it's used as an identifier -- otherwise, data from
different people would be mixed together over time. In this situation,
using
an autonumber field as the primary key (which means that your children
tables would link back via the autonumber field, not the account
number
field) would likely be best.

The account number field can be text -- not a problem.
--

Ken Snell
MS ACCESS MVP






"Howard" wrote in message
...
Free is good! That's why they have me, a non-programmer!
The data from the accounting system is basic descriptive data: among
others
we have account number, title, date opened, fiscal year-end and a
field
called tax responsibility code. The tax responsibility code tells
what
type
of trust: grantor trust, irrevocable trust, estate, charitable
(number
of
different types) among others.
So, I guess we would need this descriptive data table, a return
types
table,
a payment table and a filing table? The returns type table would be
linked
to
the tax responsibility code in the descriptive data table.
Would this run off auto numbers? I thought the account number was
unique,
but I understand they can be recycled after a number of years. Also,
it's
data type is text, not integer.
--
Howard


"Ken Snell [MVP]" wrote:

Recommendations would depend upon the type and format of the data
that
you
download. In general, your database should have tables for each
entity/class
of data (e.g., customers/clients, returns filed, types of returns,
etc.).

If you can post more details about your data, I'm sure we can
provide
some
*free" suggestions to you.
--

Ken Snell
MS ACCESS MVP



"Howard" wrote in message
news
-- We would appreciate your suggestions for a tax database to
track
preparation and filing of tax returns.

The basic account information is downloaded from our accounting
system.
That
would be one table. Then we would need a payment table and a
filing
information table?

Actually, we have a tracking database now, but the creator of it
dumped
everything into one table. So, it's very inflexible.

Thanks,

Howard

Ken,

Thanks very much!

HF
--
Howard


"Ken Snell [MVP]" wrote:

OK - here are some suggested starting points for tables:
---

tblClients (note that this could also hold other entities, such as
payees, payers, etc. - if you do that, you might want another
table called tblRoleTypes where you can store what role(s)
an entity can have)
ClientID (primary key)
ClientName
ClientAddress
(etc.)

tblReturnTypes
ReturnTypeID (primary key)
ReturnTypeName

tblReturnProcessTypes
RetProcessID (primary key)
RetProcessName

tblProcessorTypes
ProcessorTypeID (primary key)
ProcessorTypeName
ProcessorTypeAddress
(etc.)

tblReturns
ReturnID (primary key)
ClientID (foreign key to tblClients)
ReturnTypeID (foreign key to tblReturnTypes)
(etc.)

tblReturnProcessing
ReturnID (composite primary key with RetProcessID --
and with ProcessorTypeID if more than one processor
is possible for a single process type)
RetProcessID (composite primary key with ReturnID --
and with ProcessorTypeID if more than one processor
is possible for a single process type)
ProcessorTypeID (possible composite primary key with
ReturnID and RetProcessID)
DateSubmitted
DateCompleted

tblPaymentTypes
PaymentTypeID (primary key)
PaymentTypeName

tblPayments
ReturnID
PaymentTypeID
PaymentAmount
PaymentDate
PaymentToWhomID
PaymentFromID
(etc.)


and so on....
--

Ken Snell
MS ACCESS MVP




"Howard" wrote in message
...
Ken,

We'll track the prep and filing of tax returns: when an analyst has
reviewed
a return and sent it to our tax vendor for processing; when tax info has
been
sent to the trust beneficiary; when the return has been filed. We'll store
all payments made by the trust which include balances due and estimated
payments. And we'll track filing info: date filed, returns on extension
etc. All this would be for federal and state returns.
We'll have various reports.

Thanks again for your suggestions.

P.S. I'm enjoying all the "trolling for work" comments.
--
Howard


"Ken Snell [MVP]" wrote:

You'll need to specify some details about the data that you want to
track/store.

--

Ken Snell
MS ACCESS MVP

"Howard" wrote in message
...
Ken,
Thanks. One more thing. Do you have any suggestions about setting up
the
relationships between the tables?
--
Howard


"Ken Snell [MVP]" wrote:

If the account number is recycled, then it cannot be the "primary key"
of
the table in which it's used as an identifier -- otherwise, data from
different people would be mixed together over time. In this situation,
using
an autonumber field as the primary key (which means that your children
tables would link back via the autonumber field, not the account
number
field) would likely be best.

The account number field can be text -- not a problem.
--

Ken Snell
MS ACCESS MVP






"Howard" wrote in message
...
Free is good! That's why they have me, a non-programmer!
The data from the accounting system is basic descriptive data: among
others
we have account number, title, date opened, fiscal year-end and a
field
called tax responsibility code. The tax responsibility code tells
what
type
of trust: grantor trust, irrevocable trust, estate, charitable
(number
of
different types) among others.
So, I guess we would need this descriptive data table, a return
types
table,
a payment table and a filing table? The returns type table would be
linked
to
the tax responsibility code in the descriptive data table.
Would this run off auto numbers? I thought the account number was
unique,
but I understand they can be recycled after a number of years. Also,
it's
data type is text, not integer.
--
Howard


"Ken Snell [MVP]" wrote:

Recommendations would depend upon the type and format of the data
that
you
download. In general, your database should have tables for each
entity/class
of data (e.g., customers/clients, returns filed, types of returns,
etc.).

If you can post more details about your data, I'm sure we can
provide
some
*free" suggestions to you.
--

Ken Snell
MS ACCESS MVP



"Howard" wrote in message
news
-- We would appreciate your suggestions for a tax database to
track
preparation and filing of tax returns.

The basic account information is downloaded from our accounting
system.
That
would be one table. Then we would need a payment table and a
filing
information table?

Actually, we have a tracking database now, but the creator of it
dumped
everything into one table. So, it's very inflexible.

Thanks,

Howard