Word - AccountingWEB

advertisement
Access goes retro – create your own
extended trial balance application
1.1 Introduction
This series of short tutorials is designed to cover some of the issues that you might come
across when creating a small database application. The intention is not to create a database
that is the last word in elegance and sophistication, but rather to demonstrate some useful
techniques and procedures as part of a usable application. If you have never set up a
database before, you will hopefully find the tutorials interesting, but we haven’t included
complete explanations or step by step guidance. There are other resources on
AccountingWEB that will guide you through these areas in greater detail.
In the first instalment we will deal mainly with setting up the main tables for our database. A
few other tables will be required in later instalments, and these will be described when
needed.
1.2 Product specification
Our database will be called ‘ETB’ and is intended to produce a trial balance and associated
prints and displays. The input screens are designed to allow transactions to be posted from
the normal prime entry sources:

Opening balances

Cash book

Sales and purchase day books

Accruals and prepayments
 Journals
In order to keep things simple, we will not include facilities for multiple sets of data or for year
end functions.
1.3 Basic data structure
First of all we need to establish the structure of the data - this will define the tables which we
create in Access and how those tables are related to each other.
Our application needs to store transactions and details of the nominal code structure. The
main types of information we need to hold will be as follows:
Transactions
Nominal account details
This is as far as many people get with trying to set up a database. Unlike the way many
spreadsheets tend to be set up, you really do need to sort out how your database is going to
be structured before you start typing anything. If you are used to stream-of-consciousness
spreadsheet creation, then you will probably find the far more structured nature of databases
is initially challenging. However, please persevere – at least to the end of these tutorials.
Once you understand how to set up a simple database you are likely to find a whole range of
uses for your database skills.
2. Getting started
We will be using Access 2000 for our examples. If you have a different version of Access you
might find there are some cosmetic differences, but most things will work in pretty much the
same way.
2.1 Create a new database
When you first open Access you will see the following screen. The ‘wizards, pages and
projects’ option is worth investigating – you can, for example, set up your own Time and
Billing system – but in order to explain the basics of Access we will ignore the wizards and
start off with a Blank Access database.
We will call our new database ‘ETB’. The first screen you see will show you the different types
of ‘objects’ that form a database. First of all we’ll explain the uses of the different objects
within an Access database:
Tables – tables are used to store the data that our database holds – they present the data as
a grid, similar to the rows and columns of a spreadsheet.
Queries – these serve two main purposes, at their simplest they allow you to choose the data
you want to look at – e.g. the names and addresses of all clients based in Yorkshire, but they
can also be used to carry out actions on the data. For example to increase all the prices in a
price list by 10%.
Forms – as well as a simple method of collecting and storing data, databases can be used to
create complete applications. Forms can be used for entering and editing data, and as the
main interface between the user and the application. Forms would be used to create the
‘menus’ for the application.
Reports – used to print or preview chosen elements of the data, particularly useful for
‘grouping’ and sub-totalling data. For example showing the total of all expenses by employee
by month.
Pages – similar to forms, but used to create browser-based screens to review or edit and
enter data.
Macros – used to automate database actions in a similar way to the use of macros in a WP or
spreadsheet program. However Access cannot ‘record’ actions, instead it uses a series of
commands and options that you select. Macros are generally not used, most developers or
even casual users opting for the use of Visual Basic code instead.
Modules – used to automate database actions using Visual Basic for Applications code. Most
of the code in a simple application would not be developed or held within the ‘Modules’
objects, instead it would be part of the forms. So a form might have a button to print a report.
The code that carries this out would be part of the form, not a separate ‘module’, and Access
would ‘write’ most of it automatically.
Groups – used to group objects together if required.
2
2.2 Designing the database structure
The starting point of our new database is to set up the tables of data that we will be using.
We need a separate table for each different ‘entity’ that our database is to contain. The
obvious different entities in our incomplete records system are nominal code details, and
transactions. So we will need at least two tables. There are important rules that underpin the
structure of data in a database and if you intend to work on more complex structures it is well
worth getting to grips with them. Most books on how to use Access will include a section on
the underlying theory, and again AccountingWeb has some very useful resources that should
help. For this tutorial, we will use a ‘common sense’ approach to setting up our tables,
basically seeking to eliminate any duplication of data within our tables.
2.2.1
Entities
First, let’s try to explain how we would have arrived at two main tables even if we hadn’t
intuitively considered transactions and nominal codes to be separate entities. If we had tried
to set up our database with just one table we would have had to include all the nominal code
information in the transactions tables – so if, for example, 11 transactions were posted to
‘Miscellaneous expenses’ we would have to enter ‘Miscellaneous expenses’ 11 times. Not
only would this be tedious, but if the code and its description were included in the transaction
table itself there would be several problems:
Data duplication
The same data would be repeated hundreds
of times in the transaction table - and if the
data included codes and descriptions this
would be inefficient to enter and store
Data inconsistency
By having to enter what should be the same
item of data several times, we run the risk of
entering it differently or spelling it incorrectly.
This could make it difficult or impossible to
retrieve the records that relate to a particular
nominal code for example
Updating
If a nominal description was changed many
transactions would need to be edited.
Deletion
If no transaction refers to a particular nominal
code, there will be no record anywhere in the
database of that code’s existence.
By putting all the nominal codes and their descriptions into a separate table we can solve all
these problems:
 Each code and description is held once only - the duplicated field is a small numeric field
rather than two large text fields;
 Changing the code or description once in the nominal codes table changes it for all
transactions;
 All nominal codes that are, or maybe needed, are kept in the nominal codes table.
3
2.2.2
Key fields
Having split our data into different tables, we need to be able to link the two tables. The
nominal code table needs a field that uniquely identifies each record in the table, this is known
as the ‘primary key’ field. The transaction table then needs a field that holds the reference to
the nominal code key field. The linking fields need to be the same data type. Often the key
field will be an ‘AutoNumber’ field – this is a Long Integer (big number, no decimal point)
which is automatically incremented when new records are set up. When saving a table for the
first time, you will be prompted to designate a key field if you haven’t already done so – if you
have an AutoNumber field this will be used as the key field, otherwise a new AutoNumber
field will be added. Tables don’t have to have a primary key field, but it’s usually a good idea
to include one. A field that refers to another tables primary key field is knows as the ‘foreign
key’ field.
2.2.3
Table details
So hopefully you are convinced that we have at least two entities, and need at least two
tables. Let’s now list the items of data we will be keeping for each one:
2.2.3.1
Transactions
ID
Analysis code
Source code
Date
Reference number
Description
Value
Type
2.2.3.2
Nominal ledger code details
ID
Code
Description
Type
We have added some fields in green. We have already mentioned that we need to include a
unique ‘ID’ field in the nominal codes table, and we need to link our transactions table to this
unique field. Our example is relatively complicated, as our transactions table has two fields
which link to the nominal code table – the source code and the analysis code. Usually there
would just be one – e.g. an invoice would have single field linking it to a customer.
We have also included an ID field in our transactions table. This isn’t essential – there is no
other table in our database that will link TO our transactions table. However, as we mentioned
above, having a unique field is usually a good idea as it does give us a quick and reliable
method of identifying a particular record.
This leaves us with the two ‘type’ fields. Our database is designed to deal with different types
of transaction – e.g. bank and cash, or journal. In order to identify the type of the transaction
we need a type field. However, using the same logic we used to separate our transactions
and nominal codes tables, we separate our transactions table from the description of our
transaction type to avoid duplication or incorrect entries. So our ‘type’ field in the transactions
table is a link to the ID field of our ‘transaction type’ table. Similarly we might need to separate
our nominal codes into different types – profit and loss or balance sheet – for example. So
again we have a nominal code type table, These are our additional tables:
4
2.2.3.3
Transaction types
ID
Description
Short description
2.2.3.4
Nominal ledger type
ID
Description
2.3 Setting up the tables
Again we could choose to use a wizard to help set up our table, but we will start with the
basics and choose ‘Design view’. Here is our blank table design screen:
We now need to consider which table to set up first. Where one table links to another, Access
has a ‘lookup wizard’ that helps us to set up the link. To use this as we set up the table, we
need to ensure that the tables that are linked to (nominal analysis code type, transaction type
and nominal analysis code) are set up before the tables that link to them (transactions). So
we will start with Nominal analysis code type:
5
Transaction
type
2.3.1
Transactions
Nominal
analysis
code
Nominal
analysis
code type
Nominal analysis code type (tblCodeType)
When we set up the definition of a table field, we need to give that field a name, specify what
sort of data it is to contain, and often enter further details about it – known as properties.
We enter the fields and main properties in Access as follows:
Field name
Data type
Caption
Data
type/length
CodeTypeID
Autonumber
ID
Long integer
CodeTypeDescription
Text
Description
50
Notice that we have entered the ‘Field name’ without the spaces, but with initial capitals. You
will often see this format used in databases – one advantage is that it makes it easier for
Access to know you are referring to a particular field, rather than just typing text, because
there are no spaces to confuse it.
The CodeTypeID field is going to be the ‘key’ field, so it must be unique to each record. The
simplest way of achieving this is to choose the ‘AutoNumber’ data type. This creates a
number which is automatically incremented each time a new record is set up, and is therefore
unique to each record. Unless you already have a unique code that you need to use, it is
good idea to use AutoNumber for your key fields as the user then doesn’t have to worry about
ensuring new entries have unique codes.
6
Let’s have a look at the field properties for this field. The field size options vary according to
the data type of the field. For a number field such as this, the field size defines the type of
number. Pressing ‘F1’ whilst the cursor is in the field size field will display a help screen
detailing the options for this data type. Generally numbers where you don’t need to enter
decimals are held as long integers, and numbers requiring decimal places as ‘double
precision’. We can set a format to control how the information in the field is to be displayed –
particularly useful for dates and times and numbers. We can also use the ‘Input mask’ field to
speed up data entry by creating a defined format for the way the data is entered – for
example, an input mask for a date field could be set up to request 3 sets of 2 numbers with
the intervening ‘/’ being entered automatically. Next comes the caption. This is very useful, as
it will appear as the heading for our columns, and can be automatically included in any forms
or reports that refer to this field. Where we are using the initial capitals convention for our field
name, it is a good idea to enter the caption in normal English:
You will see that the last entry in our Field Properties screen is ‘Indexed’ and currently shows:
Yes (Duplicates OK). This may strike you as strange, since we claimed that the whole point of
this field was to be unique, the therefore duplicates are definitely not OK! Watch what
happens when we set this field to be the ‘key’ field by clicking the picture of a key on the
toolbar:
7
The key appears to the left of the field to show it has been designated as the ‘Primary Key’,
and we now have (No Duplicates) beside indexed. Indexing fields can have a dramatic effect
on the performance of your database. It is a bit like an index in a book. If you want to find all
references to ‘Word Art’ in ‘Using Microsoft Office 2000’ you could start at page one and
check each page through to the last page (page 1473), or you could look it up in the index,
and go straight to each reference. Like a book, the more data, the bigger the time difference
between the two methods!
Once we have entered all the information required for the transactions table we can close the
table. As we do so, we will be asked to give it a name and save it. We’ll call it ‘tblCodeType’.
Now we will set up the other tables required in the same way:
2.3.2
Transaction type (tblTransactionType)
Field name
Data type
Caption
Data
type/length
TransactionTypeID
Autonumber
ID
Long integer
TransactionTypeDescription
Text
Description
50
2.3.3
Nominal analysis code (tblNominalCode)
Field name
Data type
Caption
Data
type/length
NominalID
Autonumber
ID
Long integer
NominalCode
Text
Code
10
NominalDescription
Text
Description
50
NominalTypeRef
Number
Type
Long Integer
8
Note that the last field in the table is the one that links to tblCodeType. We have used the
‘lookup wizard’ data type to let Access take us through the process of creating the link step by
step. We have used both the fields in tblCodeType and accepted the default suggestions, but
changed the label name to ‘Nominal Type’ and the field name to ‘NominalTypeRef’.
2.3.4
The transactions table (tblTransactions)
Field name
Data type
Caption
Data
format/length
TransactionID
Autonumber
ID
Long integer
TransactionAnalysisCode
Number
Analysis code
Long integer
TransactionSourceCode
Number
Source code
Long integer
TransactionDate
Date
Date
Short date
TransactionNumber
Text
Number
10
TransactionDescription
Text
Description
50
TransactionValue
Currency
Value
Currency
TransactionTypeRef
Number
Type
Long integer
The transactions table includes 3 ‘lookup’ fields. TransactionAnalysisCode and
TransactionSourceCode both refer to tblNominalCode, and we have included the first three
fields – ID, code and description – when prompted by the wizard. TransactionTypeRef refers
to tblTransactionType and is set up pretty much the same way as NominalTypeRef in
tblNominalCode
2.4 Table names
Our tables have been named using the ‘Hungarian naming convention’. This convention
allocates a three letter description to each object within the database. A few examples follow:
Object
Designator
Example
table
tbl
tblTransactionTypes
query
qry
qryDetailedNominal
form
frm
frmETB
report
rpt
rptNominalDetails
In addition to the prefix, you will notice that all the object names use the initial capitals format.
The benefits of using a naming convention are as follows:
Consistency - all objects are named in a similar way. This makes it much easier to remember
object names without having to look them up all the time.
Identification - because the name of each object identifies what type of object it is, it makes it
much easier to understand any expressions or programming code that refer to a range of
different kinds of Access objects.
9
2.5 Referential integrity
A potential problem with any relational database is the deletion of records in one table that
are related to those in another table. For example if there are transactions that are linked to
nominal code ‘1000’ and someone deletes nominal code ‘1000’ those transactions will
become ‘orphan’ records, and the integrity of the database will be compromised. When you
used the ‘lookup wizard’ to create your ‘foreign key’ fields, Access created ‘joins’ between the
two tables for you. You can look at the way your tables are joined by choosing the
‘Relationships’ option from the ‘Tools’ menu. This will show us the joins that Access has
already created for us:
We have expanded the tables and moved them around to show the links more clearly.
We can right click on each of the join lines and then use the ‘Edit Relationship’ option to
enforce referential integrity:
We can then click the ‘Enforce Referential Integrity’ check box. You can see that in our
example the relationship is ‘One-To-Many’ - each NominalID exists once in tblNominalCode
(the ‘One’) table, but many times in tblTransaction (the ‘Many’ table).
Referential integrity can be enforced by ensuring that you cannot delete a record in the ‘One’
table if a record referring to it exists in the ‘Many’ table, or by ensuring that if you delete the
‘One’ record, all the ‘Many’ records will also be deleted - this is the ‘Cascade Delete Related
Records’ option. The latter option is obviously rather dangerous and is likely to be set only in
unusual circumstances. Here we can see our Relationships screen with referential integrity
set up for each join.
10
2.6 Conclusion
That’s the end of part 1. We have worked out how to structure the data within our
applications, and create the four main tables, and enforced referential integrity. In the next
episode we will concentrate on setting up some of the forms for our application.
11
The Knowledge Base IT Clinic Order form
Our IT Clinic feature has now been running for about 5 years. During this time we have
covered an enormous range of different queries that our Gold Card and eSupport clients have
presented us with. We have taken all the IT Clinic articles from IT Regularly and organised
them by application with a full, detailed index. The CD includes a printable Word document
version together with an HTML version suitable for browsing or adding to your office Intranet.
Just complete and return this order form, or send an email to [email protected] stating whether
you would like a personal, 10 user or unlimited version.
Applications covered include Excel, Word, PowerPoint, Outlook and Access. Each article
includes step-by-step instructions with appropriate screen shots. If you have any queries
please call us on 01403 270970 or email [email protected]
NAME
ORGANISATION
ADDRESS
£
(inc VAT)
Issue
Personal copy
Fully indexed CD - for individual use only
47.00
10 user edition
Fully indexed CD - permission to copy to up to 9
further members of your organisation
94.00
Unlimited access
(single location)
Fully indexed CD - permission to copy to any
members of your organisation as long as they are all
at the same location
141.00
Either: tick the appropriate boxes and return to us – we will send you an invoice or
please SEND WITH REMITTANCE TO The Knowledge Base, 7 Kings Court, Harwood
Road, Horsham, West Sussex, RH13 5UR. Please make cheques payable to The
Knowledge Base
PHONE 01403 270970
FAX TO 0871 242 0556 (this is a fax to email service)
12
Please
tick
Download
Related flashcards
Google

20 Cards

Databases

28 Cards

Digital libraries

62 Cards

Yahoo!

50 Cards

Create flashcards