Tracking Database

  • Thread starter Thread starter Guest
  • Start date Start date
Howard said:
P.S. I'm enjoying all the "trolling for work" comments.

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 said:
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 shit 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>
 
Ken,

Thanks very much!

HF
--
Howard


Ken Snell said:
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....
 
Back
Top