|
#1
|
|||
|
|||
|
Here is my contribution to this site:
I've been holding off on sharing this for about 6 months because I don't want someone selling it. My desire is that this will be a free tool for people just starting out. Most people have MS Office and should be able to run a small shop with it. Once you've had a chance to use a management program without limitations then you know what functionality to look for when buying a true management system. I've been developing this MSAccess Shop Management Tool since last year while laid off from my full-time job. I've since found a new job and have not had a chance to do anything else with it. It's functional and you can build on it. Please don't sale it. It's designed to work in a shop If has a 2 databases Backend DB is on a shared network drive and hold all the ticket and customer info Client DB can be placed on any number of machines within the shop. Tickets are checked out by techs and checked in when finish. Manager can assign tickets to techs. etc I have written a good Setup document to get anyone up and going with this Maybe a donation if this helps you but it is not required. Last edited by steve1040; 06-14-2011 at 09:44 AM. |
|
#2
|
||||
|
||||
|
Hi Steve, I have to say this program has some really good features. It is well written, however I have a couple of queries..
The countries, are very limited, ie china, japan, us, canada etc. How about techs from other countries, is it possible they can add their chosen country? Also within the address part, you have state listed, that would only be applicable to those in the US. In the uk we have counties. For techs who are just starting out in business, I think they would find it of great use. For those of us who are experienced, I think it is a little too basic for our requirements. But overall, I think it is a well written database, and kudos to you. The instruction manual is also well written and simple enough to follow.
__________________
Hope this helps Be Safe Nige Cadishead Computers |
|
#3
|
|||
|
|||
|
It looks like a good start as far as the logistics...as far as the function...I don't understand it.
The UI needs some work here and there. Windows open and aren't sized correctly, and I'm having trouble figuring out some of the way it works at first glance. For example, I can't figure out how to add notes to a ticket when logged in. I can change the customer and equipment type, and all of that, but I can't figure out how to enter notes regarding what the status is of the ticket. What are the "add title" and "delete title" buttons supposed to do when viewing tickets? When I click them, I just get a runtime error. (I didn't look in design view, too lazy )When I click the "invoice" button on a ticket, the report shows as blank. Basically, I'm sure this works since you know how to use it...but it looks foreign to me....as I'm sure my program would look to you. |
|
#4
|
||||
|
||||
|
Any way to get this working in access 2010? Instructions aren't jiving, when I click on database tools there's no database utilities selection.
|
|
#5
|
|||
|
|||
|
In Access 2010, just click database tools, then click the linked table manager button.
|
|
#6
|
||||
|
||||
|
I must be using a different access 2010, found my linked table manager under external data, not database tools.
|
|
#7
|
|||
|
|||
|
Quote:
But for those starting out this has the basics and they can modify to suit there situation including adding other countries |
|
#8
|
||||
|
||||
|
Thanks for sharing.
Had a look at the underlying database (back-end) and did see some fundamental mistakes. You are using Foreign Keys for look-up fields. As Access is a relational database, there will be problems in manipulating the data, creating reports, etc. For example table CustomerCases has 4 foreign keys. That means it is the slave (detail) table of 4 other tables which are it's master. That is a flawed concept, and although it may function as a database, it will not be of much use. For example in table Customers why did you need to make ZipCode and Country fields as foreign keys? For look-up purpose you don't need that, it can be safely achieved with in-line SQL to fill up your drop-down menu and simply make the field required. Edit: Did analysis of the model and came up with only 1 big warning (this is a design problem, not functionality like the many foreign keys): Object: Reference2 Page: MainPage Warning: Foreign key datatypes don't match (ZipCodes.ZipCode - Customers.ZipCode) Whatever you do, fix this. Make it string type, because other countries have letters in their zip code. And integer types are only needed if you do calculations, other than that, even if there was to be only numbers, if there are no calculations on the values, the field should be string type. Last edited by K007; 04-22-2011 at 05:07 PM. |
|
#9
|
||||
|
||||
|
No clue what any of that ^^^^ means but whatever, it sure looks like it'll do what I need it to and can't beat the price
|
|
#10
|
||||
|
||||
|
Quote:
Make sure you got a good friend in the chemist shop. ![]() Oh, and it wasn't intended directly to users, but to it's maker. Last edited by K007; 04-22-2011 at 05:18 PM. |
![]() |
| Thread Tools | |
| Display Modes | |
|
|