[Access] Stageopdracht, graag reactie op idee!

[Niek_]

Hoi,

ben bezig met m'n stageopdracht. Ga een oud DOS-Systeem omzetten naar MS Access en uitbreiden met een aantal veel gevraagde functies.
Het wordt een programma waarin partijen ingevoerd kunnen worden incl. het eten wat ze op de partij willen hebben. Het programma moet dan per dag van een week een overzicht kunnen geven van wat de keuken moet maken, het moet per week een bestelfax naar verschillende leveranciers kunnen opzetten met daarop wat er nodig is aan ingrediënten voor de week daarop. De secretaresses vullen de parijen + het eten in.

Ik heb al het een en ander opgezet en vroeg me af of ik een beetje in de goede richting bezig ben. Dit is m'n eerste keer dat ik 'echt' met Access bezig ben. (wel al eens wat lopen aanklooien maar meer ook niet)

Dit is dus m'n eerste opzet aan tabellen.
* Leveranciers: Alle info over de verschillende leveranciers
* Ingrediënten: Alle info over de verschillende ingrediënten + prijzen enz.
* Invulling Recepten: Hierin staat per recept aangegeven hoeveel van een bepaald ingrediënt nodig is.
* Recepten: Info over de recepten, per hoeveel ze gemaakt worden
* Tabletop: Hoe het recept op het buffet komt (schaal, spiegel, warmhoudbak enz.)
* Invulling bon: Welke recepten er per partij besteld zijn en hun hoeveelheid.
* Bon: Info over de parij

Vragen
- Volgens mij heb ik aan tabellen wel alles wat ik zou moeten hebben. Weet alleen niet zeker of ik niet dingen anders had moeten verdelen over de tabellen, extra tabellen had moeten maken enz.

- Die relaties kloppen (volgens mij) ook niet helemaal, volgens mij zouden sommigen 1 op 1 relaties moeten zijn?

- Waar kan ik nu beter mee beginnen, met de formulieren of de query's? (of misschien wel iets anders?)

[The Eagle]

Om even een antwoord op je laatste vraag te geven: als ik jou was zou ik ipv meteen een DB'tje in elkaar te gaan schroeven, eerst eens beginnen met een functioneel ontwerp van de applicatie. En ik gok zo (maar tot die conclusie was je zelf misschien ook al wel gekomen) dat als je dit echt in een restaurant oid in gaat zetten (waar het verdraaid veel op lijkt ), dat een acces DB waarschijnlijk al snel veel te groot, log en traag gaat worden. Beter kies je denk ik voor een volwaardig DBMS (SQL server, MySQL, Oracle? )
Denk ook eens aan een koppeling met kassa's...het moet allemaal ook kunnen draaien. Dat er een bon uit komt rollen is leuk maar het is nog veel mooier als het geheel ook aangeslagen kan worden. En wat denk je van de functionaliteit inbouwen van de drankjes? Denk dat je ook wel flessen wijn en/of champagne of andere dranken wilt kunnen bestellen.

[Jaspertje]

Wat opmerkingen:
*Een ingredient wordt altijd maar bij een leverancier gekocht?
*In Ingredienten heb je leverancieer staan, die naam kan beter leveranciercode zijn zoals je verder wel doet
* Wat gebeurt er als de prijs hoger wordt van een ingredient, nu rekent ie door naar het verleden, of maak je dan een 'nieuw' ingredient met de nieuwe prijs?
*Wil je niet meer weten over de klant (dat is imo ook een betere naam ipv bon) en kan een klant ook terug komen met hetzelfde klant nummer??


Hoe je het best kan beginnen ligt aan jezelf. Ik vindt het prettig om eerst visueel te hebben wat ik moet doen (dus een formulieer) en dat dan in te gaan vullen, maar het kan ook andersom.. Waar je ook rekening mee moet houden is het op een lege en volle database te testen.. dat kan nog wel eens wat foutjes opleveren namelijk..

[ Voor 28% gewijzigd door Jaspertje op 16-01-2004 11:56 ]

[Niek_]

Jaspertje schreef op 16 januari 2004 @ 11:54:
Wat opmerkingen:
*Een ingredient wordt altijd maar bij een leverancier gekocht?
*In Ingredienten heb je leverancieer staan, die naam kan beter leveranciercode zijn zoals je verder wel doet
* Wat gebeurt er als de prijs hoger wordt van een ingredient, nu rekent ie door naar het verleden, of maak je dan een 'nieuw' ingredient met de nieuwe prijs?
*Wil je niet meer weten over de klant (dat is imo ook een betere naam ipv bon) en kan een klant ook terug komen met hetzelfde klant nummer??


Hoe je het best kan beginnen ligt aan jezelf. Ik vindt het prettig om eerst visueel te hebben wat ik moet doen (dus een formulieer) en dat dan in te gaan vullen, maar het kan ook andersom.. Waar je ook rekening mee moet houden is het op een lege en volle database te testen.. dat kan nog wel eens wat foutjes opleveren namelijk..

*Per productgroep (vlees, groenten, brood, enz) is er 1 leverncier. Elke ingrediënt heeft dus ook maar 1 leverancier.
*Goed punt, heb ik gelijk gewijzigd.
*Moet ik nog even naar kijken, heb in de search een aantal topics hierover gevonden, ben ze nu aan het doorlezen om te kijken hoe ik het ga doen. De prijzen in het verleden mogen naturlijk niet veranderen.
*Heb gekozen voor de naam 'Bon' aangezien er per partij een planbon wordt gemaakt met daarop het verloop van de partij, het eten wat ze willen hebben, tijden, enz. Van een klant is meestal wel meer bekend maar dat staat in die planbon (in Word). Klant kan wel terugkomen (neem een bedrijf wat elk jaar weer een nieuwjaarsreceptie bij ons besteld.

Denk toch dat ik ook een tabel met klantgegevens ga maken. Hierin dan bijvoorbeeld code, naam, adres, tel. Dan een tussentabel waarin klantcode en boncode gekoppeld zijn. (Goed idee??)

(Tis trouwens voor het bedrijf waar ik ook partime werk, een cateringbedrijf met een aantal eigen locaties. Dranken zijn altijd op basis van nacalculatie en we hebben geen kassa's of zo. Kan aan mij liggen maar het systeem zal alleen op kantoor beschikbaar zijn, dan zal Access toch moeten voldoen? Denk dat een volwaardig DMBS een beetje overkill is...(of ligt dit aan mij?))

edit:
Heb de tabellen toegevoegd, vraag me alleen af of die tussentabel tussen klant en bon goed is....

[ Voor 7% gewijzigd door Niek_ op 16-01-2004 12:29 ]

[P_de_B]

Denk dat een volwaardig DMBS een beetje overkill is...(of ligt dit aan mij?))

Dat denk ik ook ja, helemaal niet nodig. Access zal prima voldoen.

[ Voor 25% gewijzigd door P_de_B op 16-01-2004 13:00 ]

[Jaspertje]

Nog een opmerking:
* Kan een Bon meerdere klanten hebben
* is er niet al een andere database met klanten? kan je het dan niet daaraan koppelen?

[ Voor 45% gewijzigd door Jaspertje op 16-01-2004 13:12 ]

[P_de_B]

* Moet je niet per 'bon' bijhouden wanneer het is?
* Je moet geen spaties of andere rare tekens (+, /) in je tabel of veldnamen doen

[Jaspertje]

P_de_B schreef op 16 januari 2004 @ 13:17:
* Moet je niet per 'bon' bijhouden wanneer het is?
* Je moet geen spaties of andere rare tekens (+, /) in je tabel of veldnamen doen

Dat is wel een goede inderdaad...

Als je gaat optimaliseren, kom je zelfs uit dat je twee apparte velden maakt, een voor postcode en een voor plaats...

Nog een zeurdirig dingetje.. kijk eens naar je benaming (even de opmerking van P_de_B daar gelaten).. poscode/plaats en postcode + plaats... dit brengt verwaring.. als iets hetzelfde vasthoudt, noem het dan ook hetzelfde..

[ Voor 24% gewijzigd door Jaspertje op 16-01-2004 13:28 ]

[Verwijderd]

Per productgroep (vlees, groenten, brood, enz) is er 1 leverncier. Elke ingrediënt heeft dus ook maar 1 leverancier.

dus moet je toch de vlgd tabellen hebben:

tblLeveranciers
tblProductGroup - link = levID
tblProduct - link = produdctGroupID

in tblProduct staat de prijs en leverHoeveelheid en andere productspecificaties, tblProductGroup alleen de omschrijving en ID, tblLeveranciers alleen de NAW gegevens.

leveranciertabel staat er al wel hoor maar is ff voor de duidelijkheid weergegeven door mij

[ Voor 11% gewijzigd door Verwijderd op 16-01-2004 13:30 ]

[gulie]

zoals P_de_B al zij kan een bon meerde klanten hebben anderes moet je de tabel klant-bon weg hallen.deze is een dubeling waarmee je aleen maar een exra bon kan maken vo rhet zelfde, dus klantmoet twee keer betalen al je pech hebt (wacht je op lonsverhoging).
wil je onthouden welke bonnen een klant krijgt dan moet je een aparte hisorty maken en das niet makelijk in Acces,
Maar wil je dat toch dan moet je hem aan klant allen linken met een 1 op 1 relatie

[Boss]

Ik zal me naar niet afvragen waarom je dat hier komt vragen, als het voor een stage opdracht is. Dan kan je er toch vanuit gaat dat je een opleiding doet waar je dit soort dingen krijgt, en waardoor je dus zo'n peanuts databaseje zou uit de mouw kan schudden?

Ervan uitgaande dat het db ontwerp wel lukt, zou ik me vast wat andere dingen gaan afvragen, zodat je opdrachtgever ook al wat kan doen, zoals de recepten nagaan om te kijken of die nog volledig zijn in het huidige systeem. Alle recepten misschien omschrijven naar standaard hoeveelheden? Dat soort dingen.

Je weet hoeveel personen er komen, en voor hoeveel personen een bepaald recept is. Daarom staat er denk ik op teveel plaatsen een verwijzing naar de hoeveelheden.

Moet er ook iets aan kostprijsberekening gedaan worden? Lokatie van de partij? Contactpersoon gegevens? Factuurgegevens?
Ik weet niet hoe uitgebreid het moet worden, maar dat zijn zomaar nog wat dingen waar ik zo aan denk bij een catering-database.

[Verwijderd]

Boss schreef op 16 januari 2004 @ 13:38:
Ik zal me naar niet afvragen waarom je dat hier komt vragen, als het voor een stage opdracht is. Dan kan je er toch vanuit gaat dat je een opleiding doet waar je dit soort dingen krijgt, en waardoor je dus zo'n peanuts databaseje zou uit de mouw kan schudden?

Ervan uitgaande dat het db ontwerp wel lukt, zou ik me vast wat andere dingen gaan afvragen, zodat je opdrachtgever ook al wat kan doen, zoals de recepten nagaan om te kijken of die nog volledig zijn in het huidige systeem. Alle recepten misschien omschrijven naar standaard hoeveelheden? Dat soort dingen.

Je weet hoeveel personen er komen, en voor hoeveel personen een bepaald recept is. Daarom staat er denk ik op teveel plaatsen een verwijzing naar de hoeveelheden.

Moet er ook iets aan kostprijsberekening gedaan worden? Lokatie van de partij? Contactpersoon gegevens? Factuurgegevens?
Ik weet niet hoe uitgebreid het moet worden, maar dat zijn zomaar nog wat dingen waar ik zo aan denk bij een catering-database.

Misschien istie wel onzeker

BTW, je weet niet in welk jaar hij zit van zijn opleiding (en correct, zo'n databeesje zet je zo in elkaar. Later ff fine-tuning en hupla!)

[ Voor 4% gewijzigd door Verwijderd op 16-01-2004 13:45 ]

[Niek_]

*kan een Bon meerdere klanten hebben?
-Nee, een klant besteld een partij/bon.
Wel kan een klant meerdere Bonnen hebben (neem een bedrijf wat meerdere keren per jaar een eprsoneelsfeest geeft wat wij cateren)
*Is er al een andere database met klanten?
-Nee....was dat maar waar.....
*Moet je niet per Bon bijhouden wanneer het is?
-Klopt helemaal, had ik eerst ook wel maar is weggevallen, heb ik weer toegevoegd.
*Geen spaties andere rare tekens.
-Rare tekens, ok, maar waarom geen spaties?
*Postcode en plaats scheiden.
-Goed punt, gelijk gedaan.

@4Advanced --> Zou je even iets duidelijker uit kunnen leggen wat je bedoelt? Hoezo splits je ingredënt in een tabel met code + naam en een tabel met rest?

@Boss --> M'n opleiding heeft me heel fijn met behulp van het boek MS Access Step by Step (echt alleen de meest eenvoudige dingen + Noorderwind) Access uitgelegd. Zoals je wel zal begrijpen is dat dus echt minimaal... Ik heb de kok al aan het werk gezet om alle gerechten + ingrediënten te controleren omdat ik er al achter was gekomen dat de helft niet klopt.

Ik had zelf ook al in gedachten om te gaan rekeken met behulp van het aantal personen en de gegevens die bij de gerechten staan (ook aantal personenen) De hoeveelheden die jij ziet staan zijn:
- tblIngrediënten: Besteleenheid, vb. per 10 kilo te bestellen of zo.
- tblInvulling recepten: Hoeveel van een ingrediënt in een recept zit.
- tblRecept: per hoeveel kg/stuks de hoeveelheden zijn die je bij tblInvulling recepten staat. vb. Boerenkool = hoeveelheid bij tblRecepten 6kg.
- tblTabletop: Hoeveel er van iets in kan, neem een chafingdish (warmhoudbak voor op het buffet) hier heb je verschillende binnenbakken voor met verschillende inhoud.
-tblInvulling Bon: Hoeveelheid is inderdaad niet nodig, deze kan berekend worden met behulp van personen uit Bon en personen bij Recepten.

[ Voor 57% gewijzigd door Niek_ op 16-01-2004 14:15 ]

[P_de_B]

-Rare tekens, ok, maar waarom geen spaties?

omdat je dan steeds

code:

SELECT [mijn veld] FROM [Mijn Tabel Met Spaties]

moet doen

[Niek_]

P_de_B schreef op 16 januari 2004 @ 14:08:
[...]


omdat je dan steeds

code:

SELECT [mijn veld] FROM [Mijn Tabel Met Spaties]

moet doen

Ah, ok.

[Niek_]

Gulie schreef op 16 januari 2004 @ 13:35:
zoals P_de_B al zij kan een bon meerde klanten hebben anderes moet je de tabel klant-bon weg hallen.deze is een dubeling waarmee je aleen maar een exra bon kan maken vo rhet zelfde, dus klantmoet twee keer betalen al je pech hebt (wacht je op lonsverhoging).
wil je onthouden welke bonnen een klant krijgt dan moet je een aparte hisorty maken en das niet makelijk in Acces,
Maar wil je dat toch dan moet je hem aan klant allen linken met een 1 op 1 relatie

Klopt helemaal. Krijg het alleen niet voor elkaar om er een 1 op 1 relatie van te maken. (In dat fijne boek van me staat er niet eens wat over in....heb de help ook al doorgelezen maar daar wordt niet echt gezegd hoe je van een relatie een 1 op 1 relatie kan maken.

[gulie]

is niet makelijk in Acces inderdaat hij denkt denkt dat hij dat voor je kan bepalen (hij is Acces) dat is een nadeel er van wel kan je een 1 op m gebruiken en 1 op1 inrichten als het voor maar een kleine groep gebruikers gaat.
gaat het over merder gebruikers zou ik zo iezo een ander program gebruiken.

[Niek_]

Als het goed is vult de secretaresse de gevraagde gegevens in. 1x per week zal de kok de lijsten voor de leveranciers uitprinten en het overzicht voor de keuken. Das alles. Eigenlijk maar 1 gebruiker dus.

[Verwijderd]

Niek_ schreef op 16 januari 2004 @ 14:05:

@4Advanced --> Zou je even iets duidelijker uit kunnen leggen wat je bedoelt? Hoezo splits je ingredënt in een tabel met code + naam en een tabel met rest?

Ga nou zelf eens na niek wat je allemaal nodig hebt alleen al om een ingredieënt in je db te zetten.

Logisch toch dat je niet elke keer de naam van de leverancier wilt opgeven met al zijn naw gegevens. Dat doe je 1 keer, meer niet. Verandert je leverancier, hoef je slechts 1 keer een update query te draaien.
Hetzelfde geld voor je productgroep, die wil je ook niet steeds opnieuw opgeven. Je wilt je producten catagoriseren duszz.....je geeft het zelf al aan.

Hou relationele integriteit goed in de gaten Niek!

BTW Access voldoet PRIMA voor jouw toepassing. Verder niet mee bezighouden, doorgaan met ontwikkelen. Ga voor jezelf na wat je allemaal kunt filteren in je DB

[ Voor 10% gewijzigd door Verwijderd op 16-01-2004 14:56 ]

[P_de_B]

Verwijderd schreef op 16 januari 2004 @ 14:55:
[...]


Ga nou zelf eens na niek wat je allemaal nodig hebt alleen al om een ingredieënt in je db te zetten.

Logisch toch dat je niet elke keer de naam van de leverancier wilt opgeven met al zijn naw gegevens. Dat doe je 1 keer, meer niet. Verandert je leverancier, hoef je slechts 1 keer een update query te draaien.
Hetzelfde geld voor je productgroep, die wil je ook niet steeds opnieuw opgeven. Je wilt je producten catagoriseren duszz.....je geeft het zelf al aan.

Hou relationele integriteit goed in de gaten Niek!

BTW Access voldoet PRIMA voor jouw toepassing. Verder niet mee bezighouden, doorgaan met ontwikkelen. Ga voor jezelf na wat je allemaal kunt filteren in je DB

Huh? heb je het plaatje wel goed bekeken? De NAW gegevens van de leverancier worden niet steeds ingevoerd bij een ingredient.

[Niek_]

Volgens mij ook niet nee. Per ingrediënt wordt alleen aangegeven welke leverancier het heeft. Verder niks aan gegevens over de leverancier....
Dit is de huidige situatie:

edit:
Heb die 1 op 1 relaties trouwens via een wel heel vaag omweggetje voor elkaar gekregen. Heb eerst gezorgd dat boncode in de tussentabel primaire sleutel was. In relaties maakte acces er gelijk een 1 op 1 relatie van. Toen heb ik in de tussentabel de primaire sleutel veranderd in klantcode. Weer terug naar he relatiescherm en nu was klantcode een 1 op 1 relatie geworden maar....de 1 op 1 relatie van de boncode was blijven bestaan... vervolgens de primaire sleutel bij klantcode er ook weer afgehaald en tot mijn verbazing bleven de 1 op 1 relaties bestaan.... (hier snap i dus niks van maar goed, houwen zo...)

[ Voor 64% gewijzigd door Niek_ op 16-01-2004 15:40 ]

[Verwijderd]

sorry verkeerd gezien. Klopt staat vermeld

[martinvw]

Een één op één relatie, waarom zou je dat willen. Die hoort gewoon in dezelfde tabel thuis. Klant moet een veel op één relatie hebben met een bon en er hoeft helemaal niks tussen bon en klant.

Een één-op-veel relatie blijkt dat het eigenlijk in de zelfde tabel thuis hoort omdat in jou geval bij elke klant één bon hoort kan je die bon natuurlijk net zo goed bij een klant zetten...

Persoonlijk ben ik van mening dat je eerst veel meer moet nadenken en weten wat je wilt voordat je met het echte ontwerpen begint al heeft access hier wel als voordeel dat je grafisch de relaties legt en dus wel door hebt waar je mee bezig bent. Veel suc6

[ Voor 26% gewijzigd door martinvw op 16-01-2004 20:05 ]

[MMUilwijk]

Heb je wel eens van informatieanalyse gehoord? Ik zou me daar eens in gaan verdiepen en nagaan wat jouw bedrijf nou echt wil vastleggen!

Voorbeeld: kilo of stuk
Maak daar nu eens eenheid van. Immers, wellicht komt er in de toekomst nog wat bij.

Die bon en klant relatie klopt nog steeds niet. Een bon betreft altijd 1 klant, en niet meerdere. Een stukje normalisatie dus.

Wat betreft de BTW. Nu kan je dat wel als kolom bijhouden, maar als ooit het BTW tarief veranderd moet je alle records nagaan lopen. Wellicht een aparte tabel?

Kortom, ga eerst na of je nu wel alles hebt wat moet worden vastgelegd, denk daarbij ook na over de toekomst, stel daar een ontwerp voor op (gewoon op papier!) en ga daarna aan de gang met de database.

Succes ermee!

[Niek_]

Ok, na er weer een paar uurtjes mee bezig te zijn geweest, nog een screenshot. Ik twijfel alleen nog over bon.bevestigd en bon.offerte_of_bevestiging.
Zit namelijk zo:
1) er is een gesprek met een (potentiële) klant.
2) er wordt een offerte opgesteld en deze gaat naar de klant
3) eventuele op/aanmerkingen van de klant op de offerte worden verwerkt in de offerte
4) definitieve offerte wordt opgestuurd naar klant
5) klant bevestigd offerte

Nu is het zo dat ze 2 mappen hebben in Brieven 2004: de map offertes en de map bevestigingen. Alles word onder de achternaam van de klant opgeslagen, zijn er meerder mensen met dezelfde achternaam dan komt er een nummertje achter.
Alle offertes komen in de map offertes (hoezo logisch ) en zo gauw een offerte bevestigd wordt, wordt hij (de definitieve offerte) opnieuw opgeslagen in de map bevestigingen. (eigenlijk zit hij er dan dubbel in maar dit moet blijven ivm handmatig erbijgeschreven wijzigingen)
Nu was mijn idee om het alsvolgt te doen:
1) alle gegevens van een klant en een bon worden in de tabellen ingevoerd. In de tabel bon is een hyperlink naar de offerte die gemaakt wordt/is in Word. Zo gauw bevestigd (ja/nee keuze) aangevinkt wordt moet de offerte opgeslagen worden in een andere map. Had de volgende indeling in gedacht:
brieven 2004\naamklant\oddmmjj.doc of brieven 2004\naamklant\bddmmjj.doc
(dus o van offerte + datum en b van bevestigd + datum)
Hoe is dit te realiseren?

edit:
typfouten.....

Bedenk me opeens dat Access dus eigenlijk bij het aanmaken van een nieuwe klant ook gelijk de map voor die klant /brieven 2004/naamklant/ moet aanmaken. Geen idee hoe ik dit doe....

[ Voor 14% gewijzigd door Niek_ op 23-01-2004 09:41 ]

[Boss]

Met

code:

FileSystem.MkDir

zie verder de help van Access

[Verwijderd]

In de tabel InvullingRec(ept?), staat een veld met een trema op de e. Haal die es gauw weg . Nee ff serieus, als jij straks queries wilt gaan bouwen, dan wil je echt niet de hele tijd een of andere vage ALT + iets combi gaan typen (vraag me zelf serieus af, of SQL een trema in een veld / tabel naam slikt).

[BrZ]

euhm, wacht even.. volgens mij ben ik krom aan het denken

[ Voor 86% gewijzigd door BrZ op 23-01-2004 19:24 ]

[Niek_]

Inderdaad invulling Recepten. Ik zal hem gelijk weghalen. Enne Bos, bedankt voor je reactie, had al wel een aantal dingen in de help van Access gevonden maar lang niet alles waarnaar ik op zoek was. Bedankt.

[Niek_]

Ligt het nou aan mijn maandag-ochtend gevoel of kan de tabel ' invullingBon' er zonder problemen tussenuit? Dat receptcode uit de tabel 'invullingBon' bij de tabel 'Bon' inkomt?

[chem]

Alleen als je maar 1 bon per recept hebt.

[Niek_]

Dus het was toch mijn brakke maandag-ochtend gevoel wat ff op kwam zetten... (ook goedemorgen) Volgende keer zal ik ff wat langer nadenken voordat ik wat post...

[Niek_]

Nieuwe vraag:
Heb nu het eerste formulier in elkaar gezet. in het beging werd het bestand niet zo groot. Heb nu een aantal wijzigingen in het formulier aangebracht en ik ga van 1.1 mb (voor invoeren formulier) naar 6.8 mb.... Geloof veel maar heb toch heel ernstig het vermoeden dat hier iets niet goed gaat. Iemand een idee wat ik niet goed doe?

_{staat me iets bij over het steeds opslaan van wijzigingen. dat zou niet bevordelijk zijn voor de grote van je database, klopt dit en zo ja, hoe los ik dit op?}

edit:
1) maak trouwens elke ochtend voordat ik begin een back-up kan dus altijd nog terug naar hoe ik vanochtend begonnen ben, maar ja, denk dat ik dan weer tegen hetzelfde probleem aanloop...?

edit:
2) heb dat comprimeren gedaan: bestand is nu 'nog' maar 3.5 mb, kan me niet voorstellen dat een formuliertje 2.4 mb groot is.....(das namelijk het enige wat ik veranderd heb....)

[ Voor 29% gewijzigd door Niek_ op 26-01-2004 11:50 ]

[Devilfish]

nog even over je database ontwerp:

waar sla je opmerkingen van klanten op? (bv extra eisen)
wat als er bv ook vegetariërs bij zijn?
Heb je nagedacht hoe je prijzen gaat bijwerken als die veranderen bij je leverancier ?

[Niek_]

Devilfish schreef op 26 januari 2004 @ 12:30:
nog even over je database ontwerp:

waar sla je opmerkingen van klanten op? (bv extra eisen)
wat als er bv ook vegetariërs bij zijn?
Heb je nagedacht hoe je prijzen gaat bijwerken als die veranderen bij je leverancier ?

Opmerkingen van klanten komen op de bon, dus in de tabel bon. Hiervoor moet ik inderdaad nog een memo-veld maken. (normaal worden dat soort dingen op de bon erbij gekalkt met een pen. Nu zal dat dus 'netjes' in een memo-veldje moeten gebeuren )
Dat gedoe met de prijzen was me ook opgevallen, heb dit topic als lij-draad en ga even kijken of ik eruit kan komen. Tis inderdaad wel een goede opmerking van je.

[Niek_]

Ok, een ander probleem:
je hebt recepten en die bestaan uit ingrediënten. Het probleem is echter dat sommige recepten (vb, zalmsalade koud buffet) bestaan uit een aantal ingrediënten + een recept. In het voorbeel van de zalmsalade: deze bestaat uit allerlei ingrediënten + zalmsalade die uit andere ingrediënten in de eigen keuken wordt gemaakt.
Eigenlijk dus een recept dat bestaat uit een recept + een aantal ingrediënten.

Hoe los ik dit op? Moet ik een extra tabel maken of zo? Heb even zitten kijken maar zou het echt niet weten

[Jaspertje]

Niek_ schreef op 26 januari 2004 @ 15:04:
Ok, een ander probleem:
je hebt recepten en die bestaan uit ingrediënten. Het probleem is echter dat sommige recepten (vb, zalmsalade koud buffet) bestaan uit een aantal ingrediënten + een recept. In het voorbeel van de zalmsalade: deze bestaat uit allerlei ingrediënten + zalmsalade die uit andere ingrediënten in de eigen keuken wordt gemaakt.
Eigenlijk dus een recept dat bestaat uit een recept + een aantal ingrediënten.

Hoe los ik dit op? Moet ik een extra tabel maken of zo? Heb even zitten kijken maar zou het echt niet weten

bestaat het dan altijd maar uit 1 ander recept + extra ingredienten? of kan het ook uit 2 bestaan.. als het uit 1 ander recept bestaan, kan het een 'child' van een ander recept zijn, dan kan je een extra veld opnemen in recept met "erfanderrcept" ofzo waarbij je een verwijzig geeft naar het id van dat andere recept

[ Voor 5% gewijzigd door Jaspertje op 26-01-2004 15:13 ]

[Niek_]

Jaspertje schreef op 26 januari 2004 @ 15:12:
[...]

bestaat het dan altijd maar uit 1 ander recept + extra ingredienten? of kan het ook uit 2 bestaan.. als het uit 1 ander recept bestaan, kan het een 'child' van een ander recept zijn, dan kan je een extra veld opnemen in recept met "erfanderrcept" ofzo waarbij je een verwijzig geeft naar het id van dat andere recept

Het bestaat echt altijd uit maar 1 ander recept + extra ingrediënten. Nooit uit 2. Ik ga eens uitzoeken hoe dat zit met dat ' child' en 'erfanderrecept' . Hoop dat de help-functie wat uitkomst bied.

[Niek_]

Tis gelukt met die ' dubbele recepten' zie ^^^^^

Ander probleem, lijkt errug simpel en is alvaak gevraagd hier op GoT. Alles eens doorgelezen maar 'mijn' probleem lijkt er niet echt tussen te zitten.
Ik heb de volgende 2 excel-bestanden: deze en d eze . Het zijn 2 prijslijsten van leveranciers. (heb er wel meer, maar wil eerst deze eens proberen) Deze wil ik importeren in Acces, is iets makkelijker dan het overtikken...., ik loop nu tegen het probleem aan dat Acces elke keer zegt dat het importeren mislukt is. Ik wil ze importeren in de tabel ' Ingredienten'

De enige echt bruikbare tip die ik kon vinden gng over de veldeigenschappen, maar die zijn volgens mij allemaal goed....(toch?)

edit:
...typefouten...

[ Voor 11% gewijzigd door Niek_ op 27-01-2004 10:46 ]

[Reptile209]

Zeg, mag jij wel zomaar prijslijsten van leveranciers publiceren? Ik kan me zo voorstellen dat dat uit concurrentieoogpunt niet zo slim is...

Wat het importeren betreft: heb het zelf nog nooit gedaan, maar moeten de kolomnamen in Excel en Access niet overeenkomen? Nu mag Access gaan raden wat er waar moet. En geeft Access niet wat meer info dan "een foutmelding"?

[Dutch_guy]

Of importeren met de importfunctie van Access, of met behulp van kopieren en plakken.

Je moet dan zorgen dat je net zoveel kolommen kopieert als je kolommen hebt in je Access tabel. Dan "Toevoegen via plakken" o.i.d.

[Niek_]

Reptile209 schreef op 27 januari 2004 @ 11:08:
Zeg, mag jij wel zomaar prijslijsten van leveranciers publiceren? Ik kan me zo voorstellen dat dat uit concurrentieoogpunt niet zo slim is...

Yep dat mag ik, deze prijzen gelden voor iedereen (bedrijf) dat bij hun afneemt

Enne, helaas, access geeft alleen maar aan dat het importeren van het bestand c:/bla/bla/lba/lbal/1.xls mislukt is. Een foutcode of zo zou inderdaad wel handig zijn maar helaas...

Heb al wel even wat geprobeerd: Heb het excel-werkblad gesorteerd op kolom A (productcode) vervolgens alle zooi die onderaan het werkblad overbleef weggegooid. Bovenin een extra rij ingevoegd en daarin de kolom-namen gezet.

Maar helaas, krijg weer te horen dat het mislukt is en ook weer zonder code of verdere info....

edit:
[quote]Dutch_guy schreef op 27 januari 2004 @ 11:14:
Of importeren met de importfunctie van Access, of met behulp van kopieren en plakken.

Je moet dan zorgen dat je net zoveel kolommen kopieert als je kolommen hebt in je Access tabel. Dan "Toevoegen via plakken" o.i.d.[/quote]

Ik zal het eens proberen....hoop toch wel dat het anders kan, verwacht dat ik zo ongeveer 20 prijslijsten zal moeten doen....

[ Voor 23% gewijzigd door Niek_ op 27-01-2004 11:19 ]

[Vozze]

Heb niet onwijs veel verstand van importeren, maar het lijkt me dat het importeren stukloopt op die "subcategorieën", zoals Eend, Kwartel, Parelhoender. Denk dat je die er eerst even tussenuit moet halen door middel van een macrootje.

[Niek_]

MarkTheFOX schreef op 27 januari 2004 @ 11:31:
Heb niet onwijs veel verstand van importeren, maar het lijkt me dat het importeren stukloopt op die "subcategorieën", zoals Eend, Kwartel, Parelhoender. Denk dat je die er eerst even tussenuit moet halen door middel van een macrootje.

Had ik ook al geprobeerd: Heb eerst het hele blad gesorteerd op kolom A, hierdoor verdwijnt al die 'zooi' naar beneden, vervolgens heb ik die laatste paar rijen met 'zooi' gewoon weggegooid. Helaas hielp dit ook niet. Toch bedankt voor je reactie.

[Vozze]

Trouwens. Als je gaat importeren. Welk veld uit de Excel-sheet, koppel je dan aan inkoopcode. Ik mag hopen dat je hiervoor niet het veld kg/st neemt, want deze heb je als Numeriek gedeclareerd, terwijl kg of st echt geen numerieke waarden zijn.

[Niek_]

Dat veld werd nummeriek toen ik ervoor zorgde dat je kon kiezen tussen stuks en kilo. Heb dat gedaan met de wizard opzoeken. Was eerst wel tekst maar is nu (automatisch) nummeriek geworden. Denk dat ik dat hele opzoeken maar vergeet en er gewoon tekst van maak. Zla het daarna nog eens proberen en m'n bevindingen hier neer zetten. Bedankt voor de tip.

[Vozze]

En dat opzoeken moet echt wel lukken hoor. Ook als je het als Tekst declareert. Probeer het zonder de wizard en voer de onderstaande waarden in:

Je moet dan wel zeker weten dat er geen andere waarden in het Excel-sheetje staan, dan die vermeld staan bij Rijbron.

[ Voor 3% gewijzigd door Vozze op 27-01-2004 12:25 ]

[Niek_]

Snap, op een ding na, wat je bij rij-bron ingevuld heb: wat bedoel je met die laatste 4 ' apelstrofjes' : '''' ??

[Vozze]

Niek_ schreef op 27 januari 2004 @ 12:29:
Snap, op een ding na, wat je bij rij-bron ingevuld heb: wat bedoel je met die laatste 4 ' apelstrofjes' : '''' ??

Is twee keer een dubbele quote. Zo kan er ook helemaal niets ingevuld worden. Mocht het voorkomen dat het veld kg/st in 1 van die sheetjes van je niet staat ingevuld.

[ Voor 8% gewijzigd door Vozze op 27-01-2004 12:33 ]

[Niek_]

...dit is echt niet te geloven.... Er is afgelopen woensdag een kleine stroomstoring geweest (wekkerradio's hielden hun tijd maar computers vielen uit) was om 6 uur 's avonds. Kom ik de volgende dag op kantoor, zet de computer aan en wil inloggen op de server --> geen reactie. Dus ik loop naar beneden, kijk in de kast, staat 'ie uit. (zit notabene een UPS bij...) Ikke hem weer aanzetten, allemaal vage error's: missende systeembestanden enz. Moest van m'n baas toen het IT-bedrijfje maar ff bellen die de boel geleverd heeft, zodat zij het konden maken.

Komen ze langs: - allebei de (identieke) HD's kapot

Wordt nog leuker, ze nemen de server dus mee incl. de tape-stream bandjes waarop elke dag een back-up gemaakt is om hem weer te maken en om te back-up's weer terug te zetten. Wat blijkt: alle back-up's vanaf november vorig jaar waren mislukt...

Zijn dus alles kwijt....ik had nog een klein beetje mazzel: heb einde van de week steeds mijn spullen naar huis gemaild (weet nog steeds niet waarom, maar goed ) Heb dus nog wel iets. Maar de rest van het bedrijf is alle gegevens kwijt vanaf november vorig jaar...

_{Nu bidden dat zo'n data-recovery bedrijfje er wat mee kan...
(trouwens, 150 euro kijkkosten is toch wel normaal of niet?) Heb voor m'n baas ff een paar van die bedrijven gezocht, o.a. uit topics hier op GoT. Hebben al contact gehad en kiezen vanmiddag degene die het wordt...}

[ Voor 3% gewijzigd door Niek_ op 30-01-2004 11:06 ]

[Boss]

Als dat IT bedrijf ook de boel voor jullie onderhoudt, zou ik ze er maar eens op aanspreken dat de backuups al maanden niet lopen.

Anders eigen schuld. Toch wel een van de dayly/weekly tasks van de (amateur) systeembeheerder: backupschema maken en controleren!

Verder hoop ik natuurlijk voor jullie dat er nog wat te redden is!

[Niek_]

*Ok, laatste off-topic reply van mijn kant...

Ze komen vanmiddag om 2 uur langs van het IT-bedrijf..... Er heerst hier nu echt zo'n 'we-geven-ze-een-enorme-rotschop-sfeer'... Wordt nog leuk.

_{Baas heeft al andere IT-bedrijven in de regio gebeld met de vraag een offerte te maken om de boel over te nemen. Hij komt er nu mee dat 'ie al langer ontevreden was met de service, had 'ie wel wat eerder mogen bedenken...}

[Niek_]

Heb nu het volgende, heb de tabel Factuur eraan toegevoegd om ervoor te zorgen dat de prijzen die op een factuur staan niet mee veranderen als de prijzen van de ingrediënten veranderen. Heb het aan de hand van dit topic gedaan. Heb toch het gevoel dat iets niet klopt
- moet de regel: factuurregels er wel staan?
- zorg ik er met behulp van deze tabel eigenlijk wel voor dat de prijzen niet mee veranderen? (heb het idee dat de prijzen in de factuur-tabel nu nog steeds kunnen veranderen....)

[Boss]

Wat zou je kwijt willen in het veld 'factuurregels'?
Dat worden dus de afzonderlijke diensten/producten die zijn gebruikt voor de partij? Dan zou ik dat heel simpel houden:
- code (link naar receptcode)
- aantal / hoeveelheid
- prijs per eenheid
- btw

Meer gegevens heb je niet nodig voor een factuurregel. Dat maak je dan een 1-op-veel relatie met Bon.

[Niek_]

Boss schreef op 02 februari 2004 @ 10:10:
Wat zou je kwijt willen in het veld 'factuurregels'?
Dat worden dus de afzonderlijke diensten/producten die zijn gebruikt voor de partij? Dan zou ik dat heel simpel houden:
- code (link naar receptcode)
- aantal / hoeveelheid
- prijs per eenheid
- btw

Meer gegevens heb je niet nodig voor een factuurregel. Dat maak je dan een 1-op-veel relatie met Bon.

Dus:
Tbl_Factuur (zonder primaire sleutel, anders wordt het een 1 op 1 relatie) met daarin:
- Boncode (gelinkt aan tbl_Bon.Boncode)
- Receptcode gelinkt aan tbl_Recept.Receptcode
- Hoeveelheid (per recept)
- Prijs (voor het recept)
Klant krijgt gewoon over de hele party, dus ook personeel enz de btw dus btw doe ik hier niet in.

[Boss]

Ik zou de BTW er we in doen. Er zijn namelijk in nederland 3 btw tarieven: 0%, 6% en 19%. Voor voedsel is het meestal 6%. Voor diensten (personeel) en (sterke) drank 19% en voor sommige artikelen een 0% tarief.

[Niek_]

Klopt, heb je gelijk in. Maar wat het is: wat ik nu maak gaat alleen over het eten en dat is dus in principe altijd 6%. Soms wordt er wel een ingrediënt gebruikt wat 19% is (bijvoorbeeld wijn) maar dat wordt al doorgerekend in de prijs van het recept.

edit:
Krijg nu het idee om dat hele gebeuren ook te integreren in de database:
- locatiekosten (staan vast per locatie)
- Tafelgarnituren (paar keuzes, aanvinken als het gebruikt wordt...?)
- Koude/warme hapjes
- Bier/wijn/fris/gedistilleerd/sap uitgesplitst.
- Arbeidsloon

Op het formulier waar de bon wordt ingevuld ook deze opties beschikbaar maken op de een of andere manier. Ik ga eens nadenken en tekenen en zal m'n idee straks hier neerzetten.

[Niek_]

Heb nu ook een tabel Factuur. Zit alleen heel erg te twijfelen of hij op de goede plaats zit en of ik de goede dingen ermee kan (opslaan wat een klant besteld heeft en hoeveel het kostte. Zonder dat bij prijsveranderingen in de tabel ingredienten, de prijzen in factuur veranderen.)

Klikbaar....