On Fri, 12 Mar 2010 07:53:59 GMT, "sys_analyst47 via AccessMonster.com"
u58607@uwe wrote:

Hi,
I am developing a inter dept application which will help us out to track the
auto loan application receiving, status of application, daily activity of
staff & few more things beside that. The problem which i am facing to design
tables is this I have a contract which needs to be issue to customer if the
loan has approved which is based on 36 fields which are as under just suggest
me is there any way to split this ?? if i will split this in different tables
I have to setup a mail merge with Word So will i be able to do that??

A mailmerge can easily be based on a Query. You certainly do not need to have
it all in one table!

Customer identification
Customer name Branch
Sales officer
Local purchase order date
Vendor
Vendor address
Brand
Model
Year of Make
Color
Chassis no
Engine no
Original cost
Insurance cost
Total cost Down payment
Total deferred payment
1st installment date
Last installment date
1st installment amount
Last installment amount
Place of registration
Vehicle owner name
Passport no
Debt account
Commission amount in no
Commission amount in words

Each type or "Entity" - real-life person, thing, or event - should have its
own table. A Customer is an entity; an automobile is a different kind of
entity; a payment is yet a third type of entity. I'd suggest at LEAST tables
such as:

Customers
CustomerID autonumber primary key
LastName
FirstName
PassportNo you might be able to make this the primary key if every customer
will have one, but I doubt that is the case

SalesOfficers
OfficerID your company's employee number or an autonumber
LastName
firstName
other biographical or contact data

Vehicles
VehicleID I think the VIN is pretty standard
Make
Model
ModelYear
Color
other vehicle specific fields

Loan
LoanNo primary key, your unique loan number
LoanDate
PrincipalAmount
other loan terms


Fields which can be derived from other fields should not exist in your table,
period - they should instead be calculated on the fly. Amount in words is one
example. If the monthly payment can be calculated from the loan amount,
interest rate and term, then it should be calculated, not stored.


this is my customer table from where i generate contract.
The idea a customer record is entered there should be no redundancy. Please
don't forger that I have to issue contracts by mail merge. Or is there any
way to design report for contracts. it contains 12 pages for one customer.
can we design such a report???

Sure.

--

John W. Vinson [MVP]