On 14 Jan 2004 16:15:49 -0800,
pietlinden@hotmail.com (Pieter Linden)
wrote:
Do your client a favor, and insert a prototyping phase in your
development lifecycle. Whip up some ideas - not necessarily in
Access, and run them by your client to gauge their reaction.
-Tom.
[color=blue]
>Hi,
>I have been asked to fix a database that deals with Customers and
>Sales/Repairs that they request. The company is a clock shop, and the
>users are NOT very technically savvy. In a nutshell, the process goes
>like this:
>1. Customer comes to shop.
>2. Staff person looks user up by phone number, and finds all the
>client's records
>3. If the customer is dropping off a new item, the staff person
>duplicates the record (I think) and adds the "Invoice" information.
>4. As the repair is changes status, it is updated in the database.
>5. Once the repair is complete and the customer comes to pick the
>piece up, the invoice is printed and the customer takes both the items
>repaired and the invoice.
>
>There are a zillion ways of doing this, I know. I was thinking of
>presenting the user with an interface where he could:
>1. Find a customer (by Phone number).
>2. Show the open and closed invoices on two separate(?) subforms. - or
>just put a dropdown to do the filtering.
>3. Include a button on the subform to allow the viewing/opening of the
>Invoice report based on the clicked job. (One invoice per job - "house
>rules".)
>
>is this a reasonable approach or am I off my rocker? There's no need
>to keep any "location history" for a client. Just the current
>name/address/phone number is fine.
>
>Any ideas on which is the best way to go with this, or would I have to
>just build it and test it out on the users? Keep in mind, these users
>are serious technical neophytes...
>
>Thanks,
>
>Pieter[/color]
