Onderwerp: Re: Vraagje, gegevens opvragen voor selectiebox.

Erick T. Barkhuis wrote:
> Jan:
>> <knip>
>>>
>>> *proest*
>>> Ik beveel nog steeds warm OE-QuoteFix aan.
>>>
>> Heb in nu gedaan......
>
> Van harte! Je hebt een nuttige stap gezet.
>
> Laten we eens naar je huiswerk kijken:
>
>> Klanten
>> - naam, dhr/mevr
>> - adres/huisnummer
>> - postcode, plaats
>> - telefoon
>> - e-mail
>> - opmerking
>
> Dit is voorlopig heel goed. Zodra we echt tabellen gaan maken, zullen
> we dit waarschijnlijk nog wat verder gaan uitsplitsen. Een naam
> bestaat bijvoorbeeld uit onderdelen.
>
> Overgens is dit wel een goed moment om even in gedachten een
> uitstapje te maken naar de wijze waarop je bestellingen (of
> offerte-aanvragen) wilt gaan afhandelen.
> Stel, je hebt een vaste klant, Piet Jansen in Lutjebroek. Piet heeft
> al eens een PC besteld, en wil nu graag een offerte voor een
> noodboekje.
>
> Vraag: wat wil je dat Piet invult, opdat jij _weet_ (kunt herkennen)
> dat het hier gaat om dezelfde Piet Jansen die de vorige keer de PC
> kocht? [Achtergrondgedachte is, dat je Piet's nieuwe bestelling wilt
> koppelen aan zijn bestaande klantgegevens. Maar als dit een andere
> Piet Jansen is, dan wil je zijn gegevens nieuw in je administratie
> opvoeren. Het is dus van belang dat je een reeds in je administratie
> aanwezige klant herkent. Alternatief is, dat je het geen enkel
> probleem vindt om klanten niet te herkennen. Je kunt ook bij elke
> bestelling klantgegevens opnemen, alsof het telkens weer om nieuwe
> klanten gaat. Het nadeel ervan is, dat je niet later afzonderlijke
> klanten kunt herkennen om hiervoor statistieken of nieuwsbrieven aan
> te maken.]
Elke bestelling en klant een unieknummer bijv datum_tijd /
postcode_huisnummer ?

>
>> Producten
>> - prodruknummer
>> - productnaam
>> - aantal
>
> Kun je verklappen wat je hier met "aantal" bedoelt?
> [Als het is wat ik denk dat het is (namelijk het door Piet Jansen
> bestelde aantal) dan zit je hier vooralsnog op een verkeerd spoor.]
Oke, jij hebt gelijk Erick. Foutje van mij.

>
>> Categorieen
>> - categoriecode
>> - categoriehoofdgroep
>> - categoriesubgroep
>
> Ik vermoed dat we hier nog een flinke uitsplitsing moeten maken. Kun
> je een voorbeeld noemen van een Categorie en van een Subcategorie,
> zodat de groepdenizens kunnen vatten wat je daaronder verstaat?
> Geef daarbij ook even aan of een Subcategorie bij meerdere Categorieen
> kan horen...dat is van groot belang.
Bijv. bij de HD.
Hoofdcategorie is bijv. Hardeschijven
- subcategorie; Ide, Sata, 31/2, 21/2, externe,

Zo ook bijv, met CD / DVD spelers
- subcategorie; intern, extern


>> -
>>
>> Offertes
>> -
>>
>>
>> Bestellingen
>> - datum / tijd
>> - afhalen
>> - rembours
>
> Hier zullen we ook aan moeten sleutelen.
> Voor het gemak zouden we "Offertes", "Bestellingen" en "Leveringen"
> als hetzelfde 'ding' kunnen beschouwen, waarvan slechts de status
> verandert. Daarmee bedoel ik, dat een offerte op enig moment
> verandert in bestelling (er komen dan alleen wat gegevens bij, zoals
> besteldatum) en de bestelling gaat dan nog eens over in levering.
> Dit is goed realiseerbaar, mits een bestelling straks niet uit
> allerlei deelleveringen gaat bestaan.
>
Goed plan.


Gr. Jan.

Laten we hier even een subdraadje van maken:

Jan:
> Erick T. Barkhuis wrote:


> >> Producten
> >> - prodruknummer
> >> - productnaam
> >> - aantal
> >
> > Kun je verklappen wat je hier met "aantal" bedoelt?
> > [Als het is wat ik denk dat het is (namelijk het door Piet Jansen
> > bestelde aantal) dan zit je hier vooralsnog op een verkeerd spoor.]

> Oke, jij hebt gelijk Erick.

Mooi, maar laten we dan kijken waar dat 'aantal' (wat kennelijk inderdaad
het bestelde aantal van een product is) terecht komt.

We hebben inmiddels de entiteiten:
KLANT
PRODUCT
CATEGORIE (en misschien SUBCATEGORIE)
BESTELLING (die de status OFFERTE, BESTELLING en LEVERING kan hebben)

Heb je enig idee?


--
Erick

"Ik heb niets tegen Javascript, maar dat je helemaal niets kan doen als
je javascript uit hebt staan, dat vind ik gewoon niet slim." - Marcel de
Groot in niwo

Jan:
> Erick T. Barkhuis wrote:

> > Vraag: wat wil je dat Piet invult, opdat jij _weet_ (kunt herkennen)
> > dat het hier gaat om dezelfde Piet Jansen die de vorige keer de PC
> > kocht?

> Elke bestelling en klant een unieknummer bijv datum_tijd /
> postcode_huisnummer ?

Okee....dat komt al dicht in de buurt.
Moet je nog slechts een oplossing bedenken voor enkele situaties:

a) Piet en Peter Jansen zijn broers, die allebei op Kerkstraat 4 in
1111DX Diemen wonen.

b) Piet verhuist naar Schoolstraat 8, en bestelt een noteboek, _voordat_
hij een adreswijziging naar je heeft opgestuurd.


....en situatie (b) levert daarbij een extra probleem op: als Piet (wiens
_identificatie_ PC/huisnr is) verhuist, krijgt hij een andere PC/huisnr,
waardoor hij een andere Piet wordt. Zijn identificerende item wordt
immers anders.

Je voelt waarschijnlijk weinig voor het uitdelen van klantennummers,
waarmee geregistreerde klanten kunnen inloggen, he?


> > Kun je een voorbeeld noemen van een Categorie en van een Subcategorie,
> > zodat de groepdenizens kunnen vatten wat je daaronder verstaat?
> > Geef daarbij ook even aan of een Subcategorie bij meerdere Categorieen
> > kan horen...dat is van groot belang.

> Bijv. bij de HD.
> Hoofdcategorie is bijv. Hardeschijven
> - subcategorie; Ide, Sata, 31/2, 21/2, externe,
>
> Zo ook bijv, met CD / DVD spelers
> - subcategorie; intern, extern

Wil je dit soort zaken ook echt als categorieen en subcategorieen zien,
vraag ik me af?

[Ik bedoel: je zou nu ook categorieen kunnen bedenken als:
Categorie MONITOREN
Subcategorieen:
- tot honderd euro
- boven honderd euro

of

Categorie MONITOREN
Subcategorieen:
- zwarte behuizing
- witte behuizing
- beige behuizing
- zilveren behuizing

_Waarom_ juist die subcategorieen die je noemt? Wat ga je juist daarmee
doen?


--
Erick

"Een browser doet wat je hem opdraagt, niet wat je wilt dat-ie doet."

Jan:
> Erick T. Barkhuis wrote:

> > Vraag: wat wil je dat Piet invult, opdat jij _weet_ (kunt herkennen)
> > dat het hier gaat om dezelfde Piet Jansen die de vorige keer de PC
> > kocht?

> Elke bestelling en klant een unieknummer bijv datum_tijd /
> postcode_huisnummer ?

Okee....dat komt al dicht in de buurt.
Moet je nog slechts een oplossing bedenken voor enkele situaties:

a) Piet en Peter Jansen zijn broers, die allebei op Kerkstraat 4 in
1111DX Diemen wonen.

b) Piet verhuist naar Schoolstraat 8, en bestelt een noteboek, _voordat_
hij een adreswijziging naar je heeft opgestuurd.


> > Kun je een voorbeeld noemen van een Categorie en van een Subcategorie,
> > zodat de groepdenizens kunnen vatten wat je daaronder verstaat?
> > Geef daarbij ook even aan of een Subcategorie bij meerdere Categorieen
> > kan horen...dat is van groot belang.

> Bijv. bij de HD.
> Hoofdcategorie is bijv. Hardeschijven
> - subcategorie; Ide, Sata, 31/2, 21/2, externe,
>
> Zo ook bijv, met CD / DVD spelers
> - subcategorie; intern, extern

Wil je dit soort zaken ook echt als categorieen en subcategorieen zien,
vraag ik me af?

[Ik bedoel: je zou nu ook categorieen kunnen bedenken als:
Categorie MONITOREN
Subcategorieen:
- tot honderd euro
- boven honderd euro

of

Categorie MONITOREN
Subcategorieen:
- zwarte behuizing
- witte behuizing
- beige behuizing
- zilveren behuizing

_Waarom_ juist die subcategorieen die je noemt? Wat ga je juist daarmee
doen?


--
Erick

"Een browser doet wat je hem opdraagt, niet wat je wilt dat-ie doet."

Erick T. Barkhuis wrote:
> Laten we hier even een subdraadje van maken:
>
> Jan:
>> Erick T. Barkhuis wrote:
>
>
>>>> Producten
>>>> - prodruknummer
>>>> - productnaam
>>>> - aantal
>>>
>>> Kun je verklappen wat je hier met "aantal" bedoelt?
>>> [Als het is wat ik denk dat het is (namelijk het door Piet Jansen
>>> bestelde aantal) dan zit je hier vooralsnog op een verkeerd spoor.]
>
>> Oke, jij hebt gelijk Erick.
>
> Mooi, maar laten we dan kijken waar dat 'aantal' (wat kennelijk
> inderdaad het bestelde aantal van een product is) terecht komt.
>
> We hebben inmiddels de entiteiten:
> KLANT
> PRODUCT
> CATEGORIE (en misschien SUBCATEGORIE)
> BESTELLING (die de status OFFERTE, BESTELLING en LEVERING kan hebben)
>
> Heb je enig idee?

Ik zou gaan voor KLANT
Omdar ik er vanuit ga dat de KLANT het belangrijkste is om daar van alles
van te registreren.

Gr. Jan.

Jan:
> Erick T. Barkhuis wrote:

> > Je voelt waarschijnlijk weinig voor het uitdelen van klantennummers,
> > waarmee geregistreerde klanten kunnen inloggen, he?
>
> Uit je goede redenering blijkt het eigenlijk niet anders te kunnen om een
> veilig systeem te hebben. Ik ga nu ook voor een inlogsysteem klantensysteem.

_Als_ je inderdaad klantengegevens eenmalig wilt bewaren, opdat je er
iets mee kunt doen, dan kom je er niet onderuit om iets kenmerkends van
een klant (zijn sofinummer, bijvoorbeeld) vast te houden.

Het is niet voor niets dat de meeste webwinkels eerst willen dat je je
registreert, en dat je met zo'n gegeven inlogt, voordat je kunt
bestellen. Ze kunnen dan vaststellen wie die klant is.

> (Jij had wederom gelijk dat het omvangrijker wordt.)

En nu nog omvangrijker, want klanten vergeten na een tijdje hun
inloggegevens, dus moet je een systeempje hebben waarme klanten
automagisch hun eigen wachtwoord weer kunnen opvragen.


> > Wil je dit soort zaken ook echt als categorieen en subcategorieen
> > zien, vraag ik me af?
> >
> > [Ik bedoel: je zou nu ook categorieen kunnen bedenken als:
> > Categorie MONITOREN
> > Subcategorieen:
> > - tot honderd euro
> > - boven honderd euro
> >
> > of
> >
> > Categorie MONITOREN
> > Subcategorieen:
> > - zwarte behuizing
> > - witte behuizing
> > - beige behuizing
> > - zilveren behuizing
> >
> > _Waarom_ juist die subcategorieen die je noemt? Wat ga je juist
> > daarmee doen?
> Categorie MONITOREN, hierbij denk ik alleen aan CRT en
> TFT subcatogorieën.
>
> Subcategorieën wil ik mee bereiken dat de klant sneller kan zoeken, het
> voor-komen van lange lijsten waar de klant nog in moet zoeken.

Aha. Maar dan zou je in plaats daarvan kunnen overwegen om een systeem te
maken waarmee klanten kunten filteren op allerlei eigenschappen van
PRODUCT, zoals kleur, extern/intern, e.d.

Overigens krijg je dan ook nog verschillende eigenschappen per soort
product, wat het geheel wat lastiger maakt.
Immers, niet elk product heeft als kenmerkende eigenschap
"opslagcapaciteit" of "draadloos" of "soort beeldbuis", om maar wat te
noemen.


Wellicht een gewetensvraag: wil je echt nog steeds het systeem zelf
ontwerpen en bouwen? En _kun_ je dat met een 'beetje' hulp?

Jan:
> Erick T. Barkhuis wrote:

> > Mooi, maar laten we dan kijken waar dat 'aantal' (wat kennelijk
> > inderdaad het bestelde aantal van een product is) terecht komt.
> >
> > We hebben inmiddels de entiteiten:
> > KLANT
> > PRODUCT
> > CATEGORIE (en misschien SUBCATEGORIE)
> > BESTELLING (die de status OFFERTE, BESTELLING en LEVERING kan hebben)
> >
> > Heb je enig idee?
>
> Ik zou gaan voor KLANT
> Omdar ik er vanuit ga dat de KLANT het belangrijkste is om daar van alles
> van te registreren.

Maar Jan, een KLANT bestelt toch niet in zijn hele leven 1x 'aantal'?

Om je een beetje op weg te helpen:
Als jij een factuur stuurt, hoeveel keer komt daarom al het gegeven
'aantal' voor? En waar hoort 'aantal' dus allemaal bij?

--
Erick

"Wij likken nog altijd even aan onze vinger, voordat we met de PgDn-toets
de bladzijde omslaan."

Erick T. Barkhuis wrote:
> Jan:
>> Erick T. Barkhuis wrote:
>
>>> Vraag: wat wil je dat Piet invult, opdat jij _weet_ (kunt herkennen)
>>> dat het hier gaat om dezelfde Piet Jansen die de vorige keer de PC
>>> kocht?
>
>> Elke bestelling en klant een unieknummer bijv datum_tijd /
>> postcode_huisnummer ?
>
> Okee....dat komt al dicht in de buurt.
> Moet je nog slechts een oplossing bedenken voor enkele situaties:
>
> a) Piet en Peter Jansen zijn broers, die allebei op Kerkstraat 4 in
> 1111DX Diemen wonen.
>
> b) Piet verhuist naar Schoolstraat 8, en bestelt een noteboek,
> _voordat_ hij een adreswijziging naar je heeft opgestuurd.
>
>
> ...en situatie (b) levert daarbij een extra probleem op: als Piet
> (wiens _identificatie_ PC/huisnr is) verhuist, krijgt hij een andere
> PC/huisnr, waardoor hij een andere Piet wordt. Zijn identificerende
> item wordt immers anders.
>
> Je voelt waarschijnlijk weinig voor het uitdelen van klantennummers,
> waarmee geregistreerde klanten kunnen inloggen, he?

Uit je goede redenering blijkt het eigenlijk niet anders te kunnen om een
veilig systeem te hebben. Ik ga nu ook voor een inlogsysteem klantensysteem.
(Jij had wederom gelijk dat het omvangrijker wordt.)

>
>>> Kun je een voorbeeld noemen van een Categorie en van een
>>> Subcategorie, zodat de groepdenizens kunnen vatten wat je daaronder
>>> verstaat?
>>> Geef daarbij ook even aan of een Subcategorie bij meerdere
>>> Categorieen kan horen...dat is van groot belang.
>
>> Bijv. bij de HD.
>> Hoofdcategorie is bijv. Hardeschijven
>> - subcategorie; Ide, Sata, 31/2, 21/2, externe,
>>
>> Zo ook bijv, met CD / DVD spelers
>> - subcategorie; intern, extern
>
> Wil je dit soort zaken ook echt als categorieen en subcategorieen
> zien, vraag ik me af?
>
> [Ik bedoel: je zou nu ook categorieen kunnen bedenken als:
> Categorie MONITOREN
> Subcategorieen:
> - tot honderd euro
> - boven honderd euro
>
> of
>
> Categorie MONITOREN
> Subcategorieen:
> - zwarte behuizing
> - witte behuizing
> - beige behuizing
> - zilveren behuizing
>
> _Waarom_ juist die subcategorieen die je noemt? Wat ga je juist
> daarmee doen?
Categorie MONITOREN, hierbij denk ik alleen aan CRT en
TFT subcatogorieën.

Subcategorieën wil ik mee bereiken dat de klant sneller kan zoeken, het
voor-
komen van lange lijsten waar de klant nog in moet zoeken.

Gr. Jan.

Jan:

[Het gegeven 'besteld aantal']

> Mijn eerste gedachte was dat Klant een belangrijk entiteit zou zijn en dan
> dat het bijv. zijn tweede keer is dat hij besteld heeft of een offerte heeft
> aangevragen.
>
> Nu je het zo met nadruk nogmaals vraagt wil ik op mijn kivieten zijn.
> Feitelijk kan er bijv. 2 keer een geheugenstreepje, 2 monitor enz
> besteld worden. Dus op een factuur komt mijninziens te minimaal
> te staan staan:
> - factuurnummer, naw-gegevens enz.
> - bestelnummer
> - omschrijving
> - aantal
> - bedrag
> - btw
> - totaal
> - betalingswijze

Een factuur ziet er ongeveer zo uit:

-----------------------------------------------------------
BRIEFHOOFD
Factuurnummer
Factuurdatum
Leverdatum

Klantgegevens

Bestellingsregels:
<aantalA> <productA>.......<prijs per stuk> <prijs aantalA*prijsPS>
<aantalB> <productB>.......<prijs per stuk> <prijs aantalB*prijsPS>
<aantalC> <productC>.......<prijs per stuk> <prijs aantalC*prijsPS>
SUBTOTAAL:.......<prijzen opgeteld>
KORTING:.........<bedrag>
BEZORGKOSTEN:....<bedrag>
BTW:......<%age>:<bedrag>
TOTAAL:..........<bedrag>
-------------------------------------------------------------

Je hebt, om dit te kunnen maken, nodig:

* Van elk besteld PRODUCT: omschrijving, prijs
* Voor de BESTELLING: nummer, datum, leverdatum
* Voor de KLANT: naw en leveringsadres
* Voor de combinatie BESTELLING/PRODUCT: aantal

....en verder heb je nog een set rekenregels nodig om het btw-percentage,
de korting, het factuurnummer en de transportkosten te bepalen.

De combinatie BESTELLING/PRODUCT levert een BESTELLINGREGEL op, en _daar_
leg je het aantal vast! Op deze manier hebben we er dus weer een entiteit
bij.

--
Erick

Erick T. Barkhuis wrote:
> Jan:
>> Erick T. Barkhuis wrote:
>
>>> Mooi, maar laten we dan kijken waar dat 'aantal' (wat kennelijk
>>> inderdaad het bestelde aantal van een product is) terecht komt.
>>>
>>> We hebben inmiddels de entiteiten:
>>> KLANT
>>> PRODUCT
>>> CATEGORIE (en misschien SUBCATEGORIE)
>>> BESTELLING (die de status OFFERTE, BESTELLING en LEVERING kan
>>> hebben)
>>>
>>> Heb je enig idee?
>>
>> Ik zou gaan voor KLANT
>> Omdar ik er vanuit ga dat de KLANT het belangrijkste is om daar van
>> alles van te registreren.
>
> Maar Jan, een KLANT bestelt toch niet in zijn hele leven 1x 'aantal'?
>
> Om je een beetje op weg te helpen:
> Als jij een factuur stuurt, hoeveel keer komt daarom al het gegeven
> 'aantal' voor? En waar hoort 'aantal' dus allemaal bij?

Ik heb je vraag proberen te "lezen";
>>>(wat kennelijk inderdaad het bestelde aantal van een product is)
Mijn eerste gedachte was dat Klant een belangrijk entiteit zou zijn en dan
dat het bijv. zijn tweede keer is dat hij besteld heeft of een offerte heeft
aangevragen.

Nu je het zo met nadruk nogmaals vraagt wil ik op mijn kivieten zijn.
Feitelijk kan er bijv. 2 keer een geheugenstreepje, 2 monitor enz
besteld worden. Dus op een factuur komt mijninziens te minimaal
te staan staan:
- factuurnummer, naw-gegevens enz.
- bestelnummer
- omschrijving
- aantal
- bedrag
- btw
- totaal
- betalingswijze

Gr. Jan.

Jan:

> Ik sta te popelen om aan de slag te kunnen gaan met 2 onderdelen.
> Zodat ik, met hulp, meer ervaring opdoe met PHP en tzt deze twee
> basis onderdelen eventueel kan uitbreiden.
>
> Tijdje geleden wilde ik eenvoudig beginnen met twee dingen.
> -1 offerte aanvragen pc samenstellen als voorbeeld "Informatique"
> * mijn probleem is oa:
> "hoe krijg ik gegeven uit een database in een
> tekstveld in een formulier. Ook hoe ik de gekozen produkten
> in een andere tabel van de database kunnen worden opgeslaan.
> Daarna via mail versturen naar klant en mij.

Je hebt daar al een aantal aanwijzingen toe gekregen in voorgaande
threads.

Gegevens uit de database en in een tekstveld (je bedoelt vermoedelijk
geen tekstveld maar een <select>-groep met <option>s) krijg je door een
SELECT uit te voeren op je database en de resultaatset te verwerken.

Ongeveer:

$sql = "SELECT * FROM producten ORDER BY prodid";
$result= mysql_query($sql, $connectie) or die("Query Error:
".mysql_error());

while ($row=mysql_fetch_array($result)) {
$middenblok .= "<option>$row['prodomschr']</option>\n";
}

>
> -2 een totale productenlijst bijv:
> nummer - omscchrijving - prijs en daar achter een vakje waar de klant
> op kan klikken om bestellen/offerte te vragen.
> * mijn probleem is oa:
> Gegevens op het scherm laten zien geselecteerd eventueel geselecteerd
> uit categorieën/subcategorieën lukt wel. Maar dat vakje waar de
> klant kan aankruizen wat men besteld lukt me niet.

Met zo'n setje <option>s kunnen je klanten uit de <select>-groep kiezen.
Echter, je wilt ook invoercontrole. Bij een verkeerde invoer wil je niet
alleen een foutboodschap afgeven, maar ook de reeds gemaakt correcte
selecties weer "aktief" maken. Dat doe je door in bovenstaande regels ook
nog na te gaan wat de waarde was van het betreffende $_POST-item, en bij
die waarde de kreet "selected" te vermelden.
Doe je dat niet, dan moeten de klanten telkens weer opnieuw alles
invullen cq. selecteren.


> Hopelijk ben ik niet te kort af Erick want dat wil ik zeker niet zijn, zeker
> niet tegen jou die veel tijd in me steekt.

Nee hoor, je bent niet kortaf.
Ik begrijp inmiddels ook wel wat je wilt. Maar als ik heel eerlijk mag
zijn: in dit tempo gaat het wel erg lang duren voordat er iets bruikbaars
gebouwd is. Je beschikt, naar mijn inschatting nu, gewoon nog over iets
te weinig basiskennis om aan een dergelijk experiment te beginnen.

Mijn advies zou daarom zijn om een stapje terug te doen, en een eenvoudig
zelfstudieboek over PHP en MySQL door te werken. Je leert dan erg veel
van de daarin gegeven voorbeelden, en ik vermoed dat het je daarna wel
zou kunnen gaan lukken.
In zulke boeken leer je ook gangbare manieren om invoer te controleren.
Daarna zul je in tutorials on-line wel kunnen nalezen waarom het niet
altijd handig is om:

> Ook hoe ik de gekozen produkten
> in een andere tabel van de database kunnen worden opgeslaan.

Het uitgangspunt van een tabel voor producten die je verkopen kunt en een
tabel voor producten die je hebt verkocht is....ehhh...niet erg gelukkig.


Welnu,
als je bijvoorbeeld bij bol.com zoekt op "php mysql" zie je dat er voor
minder dan dertig euro zowel Nederlandstalige als Engelstalige
beginnersboeken worden aangeboden.
Overigens zou ik als ik jou was (en gelegenheid had) eens naar een goede
boekenzaak of bibliotheek stappen om een paar van die boeken door te
bladeren. Je krijgt dan goed zicht op het taalgebruik en instapniveau,
waardoor je een optimale keuze kunt maken.


Niet boos worden, Jan. Ik hoop je de afgelopen weken te hebben laten
zien, dat er ietsje meer bij komt kijken dan "hoe krijg ik databaseveld X
in formulierveld Y". En daarbij zijn wij nog niet eens verder gekomen dan
een stukje gegevensanalyse...


--
Erick

Erick T. Barkhuis wrote:
> Jan:
>
> [Het gegeven 'besteld aantal']
>
>> Mijn eerste gedachte was dat Klant een belangrijk entiteit zou zijn
>> en dan dat het bijv. zijn tweede keer is dat hij besteld heeft of
>> een offerte heeft aangevragen.
>>
>> Nu je het zo met nadruk nogmaals vraagt wil ik op mijn kivieten zijn.
>> Feitelijk kan er bijv. 2 keer een geheugenstreepje, 2 monitor enz
>> besteld worden. Dus op een factuur komt mijninziens te minimaal
>> te staan staan:
>> - factuurnummer, naw-gegevens enz.
>> - bestelnummer
>> - omschrijving
>> - aantal
>> - bedrag
>> - btw
>> - totaal
>> - betalingswijze
>
> Een factuur ziet er ongeveer zo uit:
>
> -----------------------------------------------------------
> BRIEFHOOFD
> Factuurnummer
> Factuurdatum
> Leverdatum
>
> Klantgegevens
>
> Bestellingsregels:
> <aantalA> <productA>.......<prijs per stuk> <prijs aantalA*prijsPS>
> <aantalB> <productB>.......<prijs per stuk> <prijs aantalB*prijsPS>
> <aantalC> <productC>.......<prijs per stuk> <prijs aantalC*prijsPS>
> SUBTOTAAL:.......<prijzen opgeteld>
> KORTING:.........<bedrag>
> BEZORGKOSTEN:....<bedrag>
> BTW:......<%age>:<bedrag>
> TOTAAL:..........<bedrag>
> -------------------------------------------------------------
>
> Je hebt, om dit te kunnen maken, nodig:
>
> * Van elk besteld PRODUCT: omschrijving, prijs
> * Voor de BESTELLING: nummer, datum, leverdatum
> * Voor de KLANT: naw en leveringsadres
> * Voor de combinatie BESTELLING/PRODUCT: aantal
>
> ...en verder heb je nog een set rekenregels nodig om het
> btw-percentage, de korting, het factuurnummer en de transportkosten
> te bepalen.
>
> De combinatie BESTELLING/PRODUCT levert een BESTELLINGREGEL op, en
> _daar_ leg je het aantal vast! Op deze manier hebben we er dus weer
> een entiteit bij.

Ik kan het NU volgen, vroeg je dat een paar weken geleden dan had ik het
niet kunnen volgen.

Zijn we nu toe om "relaties en sleutels" aan te geven ?
Of ga ik te snel?

Gr. Jan

Erick T. Barkhuis wrote:
> Jan:
>> Erick T. Barkhuis wrote:
>
>>> Je voelt waarschijnlijk weinig voor het uitdelen van klantennummers,
>>> waarmee geregistreerde klanten kunnen inloggen, he?
>>
>> Uit je goede redenering blijkt het eigenlijk niet anders te kunnen
>> om een veilig systeem te hebben. Ik ga nu ook voor een inlogsysteem
>> klantensysteem.
>
> _Als_ je inderdaad klantengegevens eenmalig wilt bewaren, opdat je er
> iets mee kunt doen, dan kom je er niet onderuit om iets kenmerkends
> van een klant (zijn sofinummer, bijvoorbeeld) vast te houden.
>
> Het is niet voor niets dat de meeste webwinkels eerst willen dat je je
> registreert, en dat je met zo'n gegeven inlogt, voordat je kunt
> bestellen. Ze kunnen dan vaststellen wie die klant is.
>
>> (Jij had wederom gelijk dat het omvangrijker wordt.)
>
> En nu nog omvangrijker, want klanten vergeten na een tijdje hun
> inloggegevens, dus moet je een systeempje hebben waarme klanten
> automagisch hun eigen wachtwoord weer kunnen opvragen.
>
>
>>> Wil je dit soort zaken ook echt als categorieen en subcategorieen
>>> zien, vraag ik me af?
>>>
>>> [Ik bedoel: je zou nu ook categorieen kunnen bedenken als:
>>> Categorie MONITOREN
>>> Subcategorieen:
>>> - tot honderd euro
>>> - boven honderd euro
>>>
>>> of
>>>
>>> Categorie MONITOREN
>>> Subcategorieen:
>>> - zwarte behuizing
>>> - witte behuizing
>>> - beige behuizing
>>> - zilveren behuizing
>>>
>>> _Waarom_ juist die subcategorieen die je noemt? Wat ga je juist
>>> daarmee doen?
>> Categorie MONITOREN, hierbij denk ik alleen aan CRT en
>> TFT subcatogorieën.
>>
>> Subcategorieën wil ik mee bereiken dat de klant sneller kan zoeken,
>> het voor-komen van lange lijsten waar de klant nog in moet zoeken.
>
> Aha. Maar dan zou je in plaats daarvan kunnen overwegen om een
> systeem te maken waarmee klanten kunten filteren op allerlei
> eigenschappen van PRODUCT, zoals kleur, extern/intern, e.d.
>
> Overigens krijg je dan ook nog verschillende eigenschappen per soort
> product, wat het geheel wat lastiger maakt.
> Immers, niet elk product heeft als kenmerkende eigenschap
> "opslagcapaciteit" of "draadloos" of "soort beeldbuis", om maar wat te
> noemen.
>
>
> Wellicht een gewetensvraag: wil je echt nog steeds het systeem zelf
> ontwerpen en bouwen? En _kun_ je dat met een 'beetje' hulp?

Ja!

(en dan is het even stil )

Ik sta te popelen om aan de slag te kunnen gaan met 2 onderdelen.
Zodat ik, met hulp, meer ervaring opdoe met PHP en tzt deze twee
basis onderdelen eventueel kan uitbreiden.

Tijdje geleden wilde ik eenvoudig beginnen met twee dingen.
-1 offerte aanvragen pc samenstellen als voorbeeld "Informatique"
* mijn probleem is oa:
"hoe krijg ik gegeven uit een database in een
tekstveld in een formulier. Ook hoe ik de gekozen produkten
in een andere tabel van de database kunnen worden opgeslaan.
Daarna via mail versturen naar klant en mij.

-2 een totale productenlijst bijv:
nummer - omscchrijving - prijs en daar achter een vakje waar de klant
op kan klikken om bestellen/offerte te vragen.
* mijn probleem is oa:
Gegevens op het scherm laten zien geselecteerd eventueel geselecteerd
uit categorieën/subcategorieën lukt wel. Maar dat vakje waar de
klant kan aankruizen wat men besteld lukt me niet.

Ik heb erg veel gesuft naar scripts die gratis het zij betaald te verkrijgen
zijn maar ze voldoen niet aan mijn verwachtingen. Vele shop-scripts
werken allemaal met plaatjes, enorme uitleg enz. en dat wil ik niet.
Ik ga voor simpel en eenvoudig.

Hopelijk ben ik niet te kort af Erick want dat wil ik zeker niet zijn, zeker
niet
tegen jou die veel tijd in me steekt.

Gr. Jan.

Erick T. Barkhuis wrote:
> Jan:
>
>> Ik sta te popelen om aan de slag te kunnen gaan met 2 onderdelen.
>> Zodat ik, met hulp, meer ervaring opdoe met PHP en tzt deze twee
>> basis onderdelen eventueel kan uitbreiden.
>>
>> Tijdje geleden wilde ik eenvoudig beginnen met twee dingen.
>> -1 offerte aanvragen pc samenstellen als voorbeeld "Informatique"
>> * mijn probleem is oa:
>> "hoe krijg ik gegeven uit een database in een
>> tekstveld in een formulier. Ook hoe ik de gekozen produkten
>> in een andere tabel van de database kunnen worden opgeslaan.
>> Daarna via mail versturen naar klant en mij.
>
> Je hebt daar al een aantal aanwijzingen toe gekregen in voorgaande
> threads.
>
> Gegevens uit de database en in een tekstveld (je bedoelt vermoedelijk
> geen tekstveld maar een <select>-groep met <option>s) krijg je door
> een SELECT uit te voeren op je database en de resultaatset te
> verwerken.
>
> Ongeveer:
>
> $sql = "SELECT * FROM producten ORDER BY prodid";
> $result= mysql_query($sql, $connectie) or die("Query Error:
> ".mysql_error());
>
> while ($row=mysql_fetch_array($result)) {
> $middenblok .= "<option>$row['prodomschr']</option>\n";
> }
>
>>
>> -2 een totale productenlijst bijv:
>> nummer - omscchrijving - prijs en daar achter een vakje waar de
>> klant
>> op kan klikken om bestellen/offerte te vragen.
>> * mijn probleem is oa:
>> Gegevens op het scherm laten zien geselecteerd eventueel geselecteerd
>> uit categorieën/subcategorieën lukt wel. Maar dat vakje waar de
>> klant kan aankruizen wat men besteld lukt me niet.
>
> Met zo'n setje <option>s kunnen je klanten uit de <select>-groep
> kiezen. Echter, je wilt ook invoercontrole. Bij een verkeerde invoer
> wil je niet alleen een foutboodschap afgeven, maar ook de reeds
> gemaakt correcte selecties weer "aktief" maken. Dat doe je door in
> bovenstaande regels ook nog na te gaan wat de waarde was van het
> betreffende $_POST-item, en bij die waarde de kreet "selected" te
> vermelden.
> Doe je dat niet, dan moeten de klanten telkens weer opnieuw alles
> invullen cq. selecteren.
>
>
>> Hopelijk ben ik niet te kort af Erick want dat wil ik zeker niet
>> zijn, zeker niet tegen jou die veel tijd in me steekt.
>
> Nee hoor, je bent niet kortaf.
> Ik begrijp inmiddels ook wel wat je wilt. Maar als ik heel eerlijk mag
> zijn: in dit tempo gaat het wel erg lang duren voordat er iets
> bruikbaars gebouwd is. Je beschikt, naar mijn inschatting nu, gewoon
> nog over iets te weinig basiskennis om aan een dergelijk experiment
> te beginnen.
>
> Mijn advies zou daarom zijn om een stapje terug te doen, en een
> eenvoudig zelfstudieboek over PHP en MySQL door te werken. Je leert
> dan erg veel van de daarin gegeven voorbeelden, en ik vermoed dat het
> je daarna wel zou kunnen gaan lukken.
> In zulke boeken leer je ook gangbare manieren om invoer te
> controleren. Daarna zul je in tutorials on-line wel kunnen nalezen
> waarom het niet altijd handig is om:
>
>> Ook hoe ik de gekozen produkten
>> in een andere tabel van de database kunnen worden opgeslaan.
>
> Het uitgangspunt van een tabel voor producten die je verkopen kunt en
> een tabel voor producten die je hebt verkocht is....ehhh...niet erg
> gelukkig.
>
>
> Welnu,
> als je bijvoorbeeld bij bol.com zoekt op "php mysql" zie je dat er
> voor minder dan dertig euro zowel Nederlandstalige als Engelstalige
> beginnersboeken worden aangeboden.
> Overigens zou ik als ik jou was (en gelegenheid had) eens naar een
> goede boekenzaak of bibliotheek stappen om een paar van die boeken
> door te bladeren. Je krijgt dan goed zicht op het taalgebruik en
> instapniveau, waardoor je een optimale keuze kunt maken.
>
>
> Niet boos worden, Jan. Ik hoop je de afgelopen weken te hebben laten
> zien, dat er ietsje meer bij komt kijken dan "hoe krijg ik
> databaseveld X in formulierveld Y". En daarbij zijn wij nog niet eens
> verder gekomen dan een stukje gegevensanalyse...

Tja Erck, nee boos ben ik niet maar wel een beetje teleurgesteld.
Ik ga me bezinnen en ik hoop dat ik je hulp nog eens mag vragen.

O ja , je gaf een beetje uitleg bij over mijn eerste wens maar zo je
ookiets kunnen vertellen over mijn tweede wwns?
Gaat over dat vakje waar de klant aangeeft wat hij/zij wil
nummer - omschrijving - bedrag krijg ik al op het scherm
maar dat de klant hiervan een offerte wil hebben niet. Dus "iets"
doorsturen als een klant een vinkje zet in het lege veld.

Bedankt..... het is jammer maar ja niks aan te doen, ligt
meer aan mij dan aan jou.

Gr, Jan.

Jan:
> Erick T. Barkhuis wrote:

> > [boeken]

> Ik ga me bezinnen en ik hoop dat ik je hulp nog eens mag vragen.

Tuurlijk. Daar is deze nieuwsgroep voor. Anderen, die zich nu even
beleefd stil hielden, zullen zich er dan ongetwijfeld ook weer tegenaan
gaan bemoeien.

> O ja , je gaf een beetje uitleg bij over mijn eerste wens maar zo je
> ookiets kunnen vertellen over mijn tweede wwns?
> Gaat over dat vakje waar de klant aangeeft wat hij/zij wil
> nummer - omschrijving - bedrag krijg ik al op het scherm
> maar dat de klant hiervan een offerte wil hebben niet. Dus "iets"
> doorsturen als een klant een vinkje zet in het lege veld.

Dat was, zoals eerder gepost door jou:

> >> -2 een totale productenlijst bijv:
> >> nummer - omscchrijving - prijs en daar achter een vakje waar de
> >> klant
> >> op kan klikken om bestellen/offerte te vragen.
> >> * mijn probleem is oa:
> >> Gegevens op het scherm laten zien geselecteerd eventueel geselecteerd
> >> uit categorieën/subcategorieën lukt wel. Maar dat vakje waar de
> >> klant kan aankruizen wat men besteld lukt me niet.

Je wilt kennelijk dat de klant ergens een vinkje zet, waarmee hij
aanduidt dat een bepaald product is geselecteerd.

In html heb je dus iets als:

<input
type="checkbox"
value="ABC1234"
name="productkeuzeA">Bestel product A

Ongetwijfeld heb je ook een submitbutton, waarmee de bestelling wordt
verstuurd.

In je PHP-script komt nu een variabele $_POST['productkeuzeA'] die de
waarde "ABC1234" bevat.

Is dat wat je bedoelt?


--
Erick