Approval/Verification Database

[zool]

Hi!

I would like to get opinions from you guys whether is it good to create a database which has approval & verification process model.

Below is the flow of the database i'm trying to create:-

1. Prepare Purchase Order(PO) for Supplier (Amount, Date, Ref No. & Project Code)
2. Management Approve (Yes/No or secured digital signature, list of approved PO)
3. Delivery Order from Supplier (Ref No, Project Code, Summary)
4. Invoice from Supplier (Amount, Ref No. & Project Code)


4. Verification (Yes/No or Approved/Verified, List of verified Invoice/PO/SO)
5. Costing (Amount, Qty, Description, Date, Project Code, etc)

This type of database must be accessible by everyone in the company (internet/intranet).

If database is not appropriate for this type of model, please suggest me any software which is suitable.

[Rod]

I think you are in danger of confusing different concepts.

A database (such as Access) is a repository for data. It is not in itself proactive. It can check the consistency and integrity of the data stored in it.

Software (e.g. programs, procedures, what-you-will) is required to make use of the database. This software will interface with the users and store, retrieve and update data in the database. Access is in fact more than a Relational Database Manager - the RDMS is in fact JET - and contains great labour saving tools for creation design of user interfaces (i.e. forms and reports) as well as sets of commands and functions that help in the programming.

What you have described is what I call a work flow for a 'Purchase' and has nothing to do with databases per se. The work flow is a business view/requirement. Actually it is the correct place to start; too many people start with the tool and work toward the business requirement rather than the other way round.

From your description I am already able to identify entities: purchase order, delivery, invoice and a couple of actions: approval and verification. (I'm not entirely sure what you mean by costing.) The actions indicate that there are life cycles associated with your entities.

OK, that's enough preamble. Will Access be a suitable tool for developing a computer system for this requirement? I say, Yes. From your comment about accessibility then the system should be designed as a Split database (the terms client/server and front end/back end are also used).

You may care to search for template Access databases that have been developed for this (typical) requirement. I don't know of any offhand but others will.

[zool]

Thanks a lot for your comment. I'll try to study the elements required especially the database model and how to design the interface.

This is the first time i heard about split database. I do have developed some simple database for my company but yet to have a function to distribute the data so that anyone can access.

[Rod]

'Split' databases are simply client/server implementations; there are one-to-many clients networked to a single server. There's a good 'how to' contained in Access Help; invoke the help from Access and search on the word, 'Split.' For convenience you may start developing your project as a single stand-alone database and split it later on. However it's always useful to have the intended disposition in your mind as you develop regarding things like the quantity of network traffic, locking recordsets for exclusive use (data contention), and so on.

I was strict in my definition of the word database in my previous post. What has happened over the years is that all the fragments that comprise a system have been gathered together in one amorphous thing loosely termed, 'The Database.' You will not find separate components for programs, forms, reports, hyperdata, data (the 'true' database). Instead you find one file with an .accdb (.mdb) extension that contains everything.

If you need any more practical help don't hesitate to ask.