acces database

Status
Niet open voor verdere reacties.
T

trobwal

Gebruiker
Lid geworden
26 apr 2013
Berichten
22
ik zoek iemand die voor mij een access database kan aanmaken. is vrij simpel volgens mij maar van acces heb ik helaas geen kaas gegeten en het lukt mij niet om dit werkende te krijgen, mocht er iemand dit voor mij kunnen doen (tegen kleine vergoeding uiteraard) dan zou dit fantastisch zijn. meer informatie via PB.

Mvg Scherrens Jonas.
 
ok dan maar zo proberen, ik zou de database zelf willen bouwen maar ik ga wel wat hulp kunnen gebruiken hierbij. ik zal eerst verduidelijken wat ik wil en dan kunnen jullie mij misschien helpen om dit te bouwen.

Ik wil dus een database aanmaken waarin ik volgende dingen kan doen.

- Een klantenbestand
- Een lijst met wagens die ik aan klanten kan koppelen
- Een lijst met diensten die wij aanbieden
- Een factuur kunnen maken per klant waarin ik makkelijk de gegevens van de klant kan laten invullen en hierbij ook welke wagen er gebruikt is voor deze factuur
- mogelijkheid om opzoeking te doen op wagens per klant
- mogelijkheid om facturen makkelijk terug te vinden aan de hand van openstaand/betaald.
- liefst met makkelijke invoer van gegevens via soort van startpagina.


Dus om te beginnen maak ik waarschijnlijk een aantal tabellen, volgens mijn kleine kennis van access heb ik er 4 nodig nl: Klanten, Wagens, facturen en Diensten.

En dan begint de miserie.

Dus graag jullie hulp.
 
Dat is al heel wat meer info als in je mailtje stond (dat ik overigens pas net heb kunnen lezen). Qua tabellen ga je al een beetje kort door de bocht; de tabellen Klanten, Wagens (of Voertuigen) en Diensten heb je inderdaad wel nodig; daarin staan de stamgegevens die je gebruikt voor de transactietabellen. En die heb je nog niet benoemd. En dat begint eigenlijk bij het benoemen van de handelingen die je wilt gaan opslaan. Gaat het om verkopen? Verhuur? Lease?
 
hey octa.

Tnx voor de hulp. wij zijn een Hand car wash en wij bieden dus wasdiensten aan, sommige klanten hebben meerdere wagens dus wij zouden graag het overzicht bewaren en alles netjes in een database houden, als we daarbij ineens kunnen factuur maken is dit meegenomen omdat we nu alles handmatig invoeren en dit toch snel wat tijd in beslag neemt.
 
het zou dus mogelijk moeten zijn om een klantenbestand te hebben, een bestand met wagens die gekoppeld worden aan onze klanten, als we dan een factuur maken dat we snel de klant kunnen opzoeken en invoeren en dan ook de gegevens van zijn wagens kunnen terugvinden zodat we de juiste wagen kunnen selecteren in de factuur.
 
Voordat je überhaupt naar een tool (zoals Access) gaat kijken, moet je eerst alle processen goed beschrijven. Je komt nu beetje bij beetje met meer informatie, maar we hebben nog lang niet genoeg om daar zinnige dingen over te kunnen zeggen. Maar er begint schot in te komen, dat wel :).
Je hebt dus klanten die meerdere auto's hebben, en die worden gewassen. Gebeurt dat op ad-hoc basis, of heb je daar een wasschema voor? In het laatste geval zul je er wellicht een planningsschema op na willen houden waarin je vastlegt wanneer welke klant met welke auto komt. Voordeel van zo'n schema: je kunt de klant periodiek mailen welke auto's welke week worden verwacht en dat is dan weer een extra service. Maar we moeten dan wel weten of je op die manier werkt.
Iets vergelijkbaars met de facturering: doe je dat cumulatief, zodat je één keer per week of per maand factureert?
Sowieso heb je dus een tabel nodig waarin je de wasbeurten registreert op datum (+ tijd) + soort dienst + voertuigID. De facturering kun je opslaan in een aparte tabel, maar als je verzamelfacturen maakt moet je daar ook een splitsing in hebben.

Kortom: wat je in ieder geval voor jezelf goed op papier moet hebben, en ook voor de ontwikkelaar die het voor je gaat bouwen, is een Functioneel Ontwerp waarin alle processen beschreven staan. En liefst zo gedetailleerd mogelijk. Want op basis daarvan ga je dan kijken hoe het ER model er uit moet gaan zien. En als dat in orde is, kun je gaan bouwen :).
 
het gaat gewoon als volgt, sommige klanten maken een afspraak, andere komen gewoon naar ons en die nemen we er dan vlug tussen. wij wassen de wagens en gaan direct daarna factureren. nu gebeurt dit handmatig via excle, dus alle gegevens telkens opnieuw invoeren en afdrukken, ons klantenbestand bestaat nu vooral uit visitekaartjes maar dat is onoverzichtelijk en omslachtig.

Concreet wil ik dat.

Een nieuwe klant kan ingevoerd worden in het klantenbestand, bestaande klanten makkelijk kunnen opgezocht worden, de wagens die zij hebben kunnen bijhouden in een database waarin we makkelijk op klant, merk of nummerplaat kunnen zoeken.
Als de wagens gewassen zijn snel een factuur kunnen maken met de gegevens die in de database zitten zodat dit alles vlotter verloopt, de factuur opslaan per klant en meegeven of die betaald of openstaand is, mogelijkheid op opzoeken op openstaand en/of betaald, mogelijkheid om korting te voorzien op de factuur.

ik denk dat je het nu te ingewikkeld maakt, ik ken niet zo heel veel van access maar wat ik zelf in mijn hoofd heb is iets in deze trant.

een formulier waarin ik een nieuwe klant kan toevoegen of een bestaande klant kan bewerken
een formulier waarin ik een voertuig kan toevoegen (merk,type,kleur en nummerplaat, nummerplaat wordt dan de primaire sleutel) en deze kan koppelen aan een klant.
dan een mogelijkheid om een factuur te maken waarin ik de klantgegevens kan opzoeken en laten invullen, bij die klant uit zijn beschikbare voertuigen degene kiezen die van toepassing is en de geleverde diensten kan invullen. (dit hoeft geeneens op te zoeken zijn, kan ik makkelijk zelf invullen), kortingspercentage toevoegen en een mogelijkheid om die dan aan te duiden als openstaand of betaald.
mogelijkheid om opzoekingen te doen in het klantenbestand, voertuigenbestand en in de facturen.
er hoeft niks van planning of dergelijk bijgehouden te worden, de meesten komen gewoon binnen voor een snelle wasbeurt en maken geeneens een afspraak.
 
trobwal zei:
ik denk dat je het nu te ingewikkeld maakt, ik ken niet zo heel veel van access maar wat ik zelf in mijn hoofd heb is iets in deze trant.
Klik om te vergroten...
Dat is een denkfout aan jouw kant; een database werkt pas optimaal als alle processen in kaart zijn gebracht en zijn beschreven. Op basis daarvan moet je pas gaan kijken hoe je dat vertaalt. Jij denkt vanuit een eindproduct (je ziet waarschijnlijk de formulieren al voor je) en dat moet je dus niet doen bij databases. Want het resultaat daarvan is dat je je vastpint op een idee, en dat idee terugvertaalt naar een proces. En je moet altijd vanuit het proces denken. Dat proces bepaalt uiteindelijk hoe je workflow gaat worden, niet andersom.
 
sorry maar dat begrijp ik niet, heb toch al gezegd wat ik met die database wil bereiken, begrijp me niet verkeerd ik apprecieer uw input en expertise maar ik weet niet wat ik nog meer kan toevoegen aan mijn betoog.

de zaken die ik wil bereiken heb ik uitgelegd en met mijn kennis van access kan ik dit niet vertalen in een database die doet wat hij moet doen. ik zal proberen om uitgebreid uit te leggen wat ik verwacht dat de normale gang van zaken zou moeten worden met behulp van de database en dan zie je maar of je ermee verder kan of niet (voor het gemak zal ik een voorbeeld gebruiken voor een nieuwe klant die een eerste maal komt en dan een bestaande klant die voor een 2de maal komt met een andere wagen.)

Dus een nieuwe klant komt bij ons binnen en vraagt om zijn wagen te wassen, dit zonder afspraak te hebben gemaakt.
Wij leveren de diensten die beschreven staan in onze dienstenlijst, dit zijn vaste tarieven die niet afhankelijk zijn van duurtijd.
Vervolgens neem ik die klant op in ons klantenbestand en voeg ik zijn wagen toe in de database zodat die wagen gekoppeld is aan deze klant,
daarna maak ik een factuur waarop ik de klant zijn gegevens kan selecteren en de wagen kan selecteren waarop de diensten zijn uitgevoerd.
Ik geef in de factuur op of er een toeslag moet gerekend worden (vb grote bestelwagens) en of de klant recht heeft op korting of niet.
Ik print de factuur uit en sla die op in de database waarbij ik opgeef of de factuur voldaan is of niet.

Een bestaande klant komt bij ons met een wagen die nog niet geregistreerd is in onze database,
Wij leveren de gevraagde diensten.
Na de wagen gewassen te hebben voegen wij de nieuwe wagen toe in onze database en koppelen deze aan de bestaande klant.
Factuur maken zoals boven beschreven
opslaan zoals boven beschreven.

verder zouden we graag opzoekingswerk kunnen verrichten in de database zoals opvragen van facturen die openstaan, wagens per klant opzoeken op nummerplaat, type ed. hiermee bedoel ik dat we vb een nummerplaat ingeven en dan te zien krijgen bij welke klant deze wagen hoort.

Ik hoop dat ik mij met mijn betoog wat verduidelijkt heb en dat je hier verder mee kan zoniet graag iets meer info zodat ik u verder kan helpen om dit werkende te krijgen.

Nogmaals ik apprecieer uw input echt wel hoor en wil geen afbreuk doen aan uw expertise maar ik weet niet echt wat je bedoelt met processen.

ik ben een lastige klant he.

Mvg
 
Een klant is pas lastig als hij/zij de eigen wil doordrijft tegen elk (beter) advies in. Tot die tijd ben je hooguit een klant die wel weet wat-ie wil maar dat niet goed kan uitleggen... Je hebt het (nog) steeds over klanten die je opslaat in de klantentabel. Daarbij ga je er dus blijkbaar van uit dat elke klant die bij je langskomt van plan is om dat regelmatig te doen, en op basis van een (contract?) klantrecord wordt geregistreerd in je wastabel. De wasstraten waar ik kom hebben mij daar nog nooit om gevraagd :). Ik kan mij dus ook heel goed voorstellen dat je eenmalige (althans: voor de db eenmalige) klanten hebt die je niet in de klantentabel opslaat en die contant (of pinnen) afrekenen.

Onderdeel van een goede procesbeschrijving is ook dat je dat soort aspecten beschrijft. Dan zeg je bijvoorbeeld: "in onze wasstraat wassen we auto's van losse klanten die contant afrekenen en auto's van klanten die een contract hebben". Maar jij lijkt te zeggen: "in onze wasstraat wassen we alleen auto's van klanten een contract hebben; als de klant nog geen contract heeft wordt een nieuw contract gemaakt". Voor het inrichten van de database is dit onderscheid redelijk belangrijk. Het lijkt voor jou misschien zo klaar als een klontje het het bij jullie werkt, je moet niet vergeten dat wij als helpers jouw situatie totaal niet kennen. En het is lastig om zinvolle adviezen te geven op basis van niet-bestaande kennis. Alhoewel: eigenlijk is dat simpeler, want dan is alles goed wat je zegt :).
 
voor onze diensten hebben wij enerzijds klanten die regelmatig terugkeren maar waar er geen contract voor is, die klanten komen gewoon wanneer het hun past of wanneer zij het nodig achten, anderen die komen misschien maar eenmalig maar dat weten we niet tot zij terugkomen, wij werken niet met contracten of overeenkomsten. we hebben klanten die principieel wekelijks komen en dan degene die sporadisch komen.

Voor de klanten aan wie wij facturen moeten aanmaken gaat het vooral over zakelijke klanten die dus BTW plichtig zijn, die beschikken over 1 of meerdere bedrijfswagens en waarvan wij de BTW gegevens en dergelijke krijgen via visitekaartjes en dergelijke, het is inderdaad niet de bedoeling om elke klant hier in op te slaan, enkel wanneer ze bij de eerste maal duidelijk aangeven dat zij een factuur wensen of terugkerende klanten die we vb de vraag kunnen stellen of zij in ons systeem te wensen opgenomen worden om vb dan ook via mail ofzo op de hoogte gehouden willen worden over aanbiedingen en dergelijke.

ik begrijp uw uitleg nu wel iets beter denk ik. het zou vb makkelijker zijn om voertuigen in te boeken omdat je hier geen toestemming van de eigenaar nodig hebt en desgewenst een klant kan koppelen aan een voertuig, zo zou het vb ook makkelijker bij te houden zijn wat er aan bepaalde wagens gebeurt is, het gaat dan voornamelijk over grotere pakketten, een wagen die snel binnen en buiten gewassen wordt hoeft dus niet effectief ingeschreven te worden in de database, voor vb het polijsten en/of waxen van een wagen is het misschien wel aangewezen om dit ook te gaan bijhouden aangezien we dan kunnen zien hoelang geleden ze vb een wax gekregen hebben ofzo.
 
mss ook interessant om te weten, voor onze grotere pakketten wordt er zoiezo een formulier bijgehouden waarin de gegevens staan en wat er juist aan gebeurd is, die kunnen we dan eventueel inscannen en toevoegen aan de wagenfiche.
 
Dat zijn dus precies de zaken die je in een FO (Functioneel Ontwerp) zet; een database (en wij al helemaal niet) weten niet dat je bij de ene handeling wél een formulier gebruikt en bij een andere niet. Dat zijn verschillende werkprocessen en die vereisen dus verschillende oplossingen in de database. Nogmaals: begin altijd met het zo volledig opschrijven van het huidige proces, hoe dom dat ook lijkt. Dat moet dan op het niveau van: Jantje boekt de auto in (Jantje moet dus bij het invulformulier kunnen en dat kunnen invullen) en slaat het op waarna Pietje het formulier op het scherm ziet (maar er niet in mag wijzigen; hooguit bijvoorbeeld de washandelingen toevoegen). En uiteindelijk komt het dan bij de Financiële afdeling die de facturen uitdraait. Die hebben dan weer weinig te maken met de uitvoerformulieren, maar des te meer met de factuurformulieren en rapporten.
 
Ok

Ik zal eerst beginnen met de diensten te omschrijven en erbij te zetten of hiervoor iets bijgehouden wordt of niet

Dienst A : gewoon wassen exterieur, wordt niet bijgehouden
Dienst B : reinigen interieur, wordt niet bijgehouden
Dienst C,D en E: dieptereiniging, polijsten en/of waxen van het voertuig, hier wordt een 2delige fiche van de wagen opgemaakt die wij bijhouden.
Dienst F,G en H: Dieptereiniging interieur in verschillende gradaties, hier wordt geen fiche voor bijgehouden.
Dienst I,J,K en L: zijn specifieke zaken die extra gebeuren op onze primaire diensten.

Klanten kiezen steeds uit een combinatie van exterieur en interieur pakketten, zo is het niet mogelijk om een combinatie met VB C en D te maken maar wel C en F.

Omdat wij een opstartend bedrijf zijn is dit voor ons allemaal nieuw dus zal ik omschrijven hoe het nu gebeurt, misschien zal het zo makkelijker zijn om tot een FO te komen.

Klant A (particuliere klant) komt binnen en maakt gebruik van dienst A en/of B, Wij leveren de diensten en rekenen af, de klant geeft geen gegevens op en er wordt niks bijgehouden over de klant.

Klant B (particuliere klant) maakt afspraak en maakt gebruik van Dienst C,D of E en/of Dienst F,G of H, Wij leveren de diensten, waarbij wij 2 Fiches invullen die bij Dienst C,D of E hoort, deze fiches worden ondertekend door de klant en bijgehouden in een map. verder worden er geen gegevens van de klant bijgehouden

Klant C (zakelijke klant) komt binnen en maakt gebruik van dienst A en/of B, Klant geeft gegevens op via visitekaartje die bijgehouden wordt in een mapje, Wij leveren diensten, na afloop wordt een factuur gemaakt waarop de gegevens van de klant staan, onze gegevens en de gegevens van de wagen (Merk, Type, Kleur en nummerplaat), op de factuur kan een toeslag gerekend worden of een korting gegeven worden, Klant betaalt direct of later via overschrijving, nu houden we dat bij door de facturen op te slaan in respectievelijk de mappen "openstaande facturen" en "voldane Facturen" afhankelijk van de status. Klant vertrekt

Klant D (zakelijke klant) Maakt afspraak voor de grotere pakketten en maakt gebruik van Dienst C,D of E en/of Dienst F,G of H, klantgegevens zijn bekend of worden opgegeven, De fiche's die bij Dienst C,D of E horen worden ingevuld en ondertekend door klant, wij leveren onze diensten, factuur wordt na afloop opgemaakt zoals hierboven beschreven en op dezelfde manier bijgehouden, Klant betaalt direct of later via overschrijving, klant vertrekt.

Wij hebben geen diverse mensen die hier in hoeven te kunnen, wij zijn met 2 personen en de bedoeling is dat wij beiden alles kunnen doen in de database, verder moet het mogelijk zijn om meerdere wagens te koppelen aan klanten en ook de particuliere klanten opgenomen kunnen worden in de database.

Ik hoop dat je hier al wat verder mee kan. ik wil gewoon een simpelere manier om alles bij te houden en facturen te maken.

Mvg
 
trobwal zei:
Ik wil gewoon een simpelere manier om alles bij te houden en facturen te maken.
Klik om te vergroten...
Dat snap ik maar aan een simpel eindproduct (makkelijk te gebruiken formulieren) ligt meestal een heel voortraject. En doorgaans geldt: hoe simpeler het eindresultaat, hoe meer er aan de achterkant moet worden ingericht en gebouwd.

Een simpel voorbeeldje van die stelling geef je gelukkig zelf al:
trobwal zei:
;Klanten kiezen steeds uit een combinatie van exterieur en interieur pakketten, zo is het niet mogelijk om een combinatie met VB C en D te maken maar wel C en F.
Klik om te vergroten...
Dat moet dus al in het formulier worden opgelost, dat je verkeerde combinaties kunt maken! Je kunt zeggen: zet alles maar in de keuzelijsten, want wij weten echt wel wat wij doen en wij maken geen fouten (zou je trouwens de eerste zijn). Maar de praktijk is doorgaans dat er wel eens iemand ziek is of op vakantie gaat, en dan huur je iemand anders in en die is niet zo goed ingewerkt in het systeem, en die maakt dus wel de verkeerde keuzes. In een goed systeem kun je die fouten niet maken, al zou je willen!

Je beschrijft nu verschillende processen waar dus verschillende acties aan hangen; in het geval van je eerste voorbeeldje bijvoorbeeld zul je nog wel een bon met de geleverde diensten meeleveren, maar verder wellicht geen factuur maken. Kortom: je geeft nu al veel meer inzicht in wat je allemaal wilt hebben, en dat is een goede zaak :).
 
OctaFish zei:
Je beschrijft nu verschillende processen waar dus verschillende acties aan hangen; in het geval van je eerste voorbeeldje bijvoorbeeld zul je nog wel een bon met de geleverde diensten meeleveren, maar verder wellicht geen factuur maken. Kortom: je geeft nu al veel meer inzicht in wat je allemaal wilt hebben, en dat is een goede zaak :).
Klik om te vergroten...

Klopt, maar die bonnetjes worden handmatig geschreven dus daar hoeft geen ruimte voor te zijn in de database. Ik zou het wel graag zelf gaan doen met hulp van u dan uiteraard, zo leer ik ook ineens wat bij van access, denk je dat je nu voldoende informatie hebt om mij verder op weg te helpen.
 
trobwal zei:
Klopt, maar die bonnetjes worden handmatig geschreven dus daar hoeft geen ruimte voor te zijn in de database.
Klik om te vergroten...
?? Ik ken weinig mensen die sneller schrijven dan een rapportje met de geleverde diensten uitprinten m.b.v. één druk op een knop. En het lijkt mij dat je ook de losse activiteiten zult willen/moeten vastleggen omdat je bedrijfsvoering anders incompleet is. Hoe wil je anders een betrouwbaar financieel overzicht genereren als je de transacties niet vastlegt?
 
klopt al een bus octa, ik laat mij begeleiden door uw advies, we zijn nu zo'n 3 maand ver en hebben nu echt onze eerste drukke week achter de rug dus ik wil orde op zaken voor er gaten in onze organisatie vallen.

Nogmaals bedankt voor je hulp, apprecieer ik enorm. als je mij verder helpt om dit op punt te stellen heb ik daar wel een financiële tegemoetkoming voor over, op voorwaarde dat je mij duidelijk aangeeft hoeveel dit mij zal kosten op voorhand, hebben ons zo al eens laten vangen voor onze website, die heeft ons enorm veel gekost en niks opgebracht.
 
oh en voor alle geleverde diensten moeten wij een BTW bonnetje invullen dus via dat bonnetje worden onze transacties en dergelijke vastgelegd, verder ook een kas en ontvangstenboek bijhouden.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan