[MySQL] ongedefineerde prijs

[turkosh]

Hoi,

Ik ben gestuit op een kleine dilemma met het opstellen van een POS db.
Nu zijn er artikelen opgenomen met vaste prijs in het tabel artikel. Maar er zijn ook artikelen die geen voogedefineerde prijs hebben.
Bijv.:
Redband 1.80 zoetwaren
is een vast gegeven. De prijs kan je ook niet tijdens verkoop veranderen.

Maar je hebt ook:

Zoetwaren .... zoetwaren
die geen bedrag heeft. Dit om zoetwaren zonder prijskaartje of niet te lezen barcode op te vangen in de goede categorie. De prijs kan dus varieren.

Heb de volgende indeling in tabellen:
artikel(PLU, omschrijving, rapportcode, prijs, barcode, aantal per verpakking, datum, bestelnivo)
hoofdgroepen(id, rapportcode, productid, btw_code, tabelcode, categorie)
verkooplijst(verkoop_id, PLU, sofinummer, tmstamp)

Het is de bedoeling om de ongedefineerde waren ook netjes in verkooplijst op te nemen. Hoe pak ik dit het beste op?

[xtra]

Het eerste wat ik bedenk is aan je tabel een veld toevoegen wat aangeeft dat het bedrag zelf ingevoerd moet worden. De prijs laat je dan leeg of op 0. Je kunt dan bijvoorbeeld ook afprijzingen op die manier doen.
Je zou het eventueel kunnen afleiden uit een ander veld (bijv als prijs = 0) maar dit komt de betrouwbaarheid niet ten goede lijkt mij.

[turkosh]

als ik een veld moet opnemen in om vast of los bedrag te specifieren, dan moet ik dus eigenlijk ook een prijs veld opnemen in verkooplijst die bij elk verkoop null of aangepast geprijsd wordt.
Is het niet onhandig om 2 prijs velden te hanteren?
En gebruik makend van referenties voor prijs is volgens mij ook tricky. Dan gebruik ik eigenlijk wel 1 veld maar elke keer als ik de prijs van zoetjes in verkoop aangeef, verandert die mee in artikel prijs.

[xtra]

turkosh schreef op 09 januari 2004 @ 15:07:
als ik een veld moet opnemen in om vast of los bedrag te specifieren, dan moet ik dus eigenlijk ook een prijs veld opnemen in verkooplijst die bij elk verkoop null of aangepast geprijsd wordt.
Is het niet onhandig om 2 prijs velden te hanteren?
En gebruik makend van referenties voor prijs is volgens mij ook tricky. Dan gebruik ik eigenlijk wel 1 veld maar elke keer als ik de prijs van zoetjes in verkoop aangeef, verandert die mee in artikel prijs.

Als je geen prijsveld in verkooplijst hebt (sorry, had ik niet eens naar gekeken.) dan heb je misschien een ander probleem. Als de drop op 1 december 1,90 wordt i.p.v. 1,80 dan heb je ineens een veel hogere omzet in de periode daarvoor.
Als je dat soort overzichten niet hoeft te hebben dan maakt het niet uit natuurlijk.

Maar beide problemen naast elkaar gezien zou ik toch een prijsveld in de verkooplijst opnemen.

[turkosh]

Daar had ik ook niet aangedacht. Je hebt gelijk.
Nu is de kwestie dus "hoe" omgaan met die ontwikkelingen. De prijs kan fluctueren. Dus wel handig als oude gegevens blijven bestaan en niet zomaar veranderen. Als ik me niet vergis doet MySQL niet moeilijk met dit. Als je eenmaal een record hebt toegevoeg kan je makkelijk de waardes veranderen (ook al komen die waardes niet voor in gerefereerde tabel-veld) zonder dat de velden in andere tabellen meeveranderen.
Nu zou het wel handig zijn als ik een item verkoop in de eerste instantie de prijs automatisch wordt overgenomen. Maar ik denk dat dit niet met MySQL mogelijk is.

[drm]

turkosh:
Nu zou het wel handig zijn als ik een item verkoop in de eerste instantie de prijs automatisch wordt overgenomen. Maar ik denk dat dit niet met MySQL mogelijk is.

Je zou hiervoor de INSERT INTO ... SELECT syntax kunnen gebruiken.

Voorbeeldje:
Tabel `spef`(`a`,`b`)
Tabel `knel`(`c`,`d`)

code:

INSERT INTO
   spef(a, b)
SELECT
   'piet',
   `c`
FROM
    `knel`
WHERE
    `d`=1;

Wat dit even kort door de bocht doet is een record in de tabel `spef` toevoegen met de waarden:

a	'piet'
b	c uit knel waar knel.d =1

[Verwijderd]

ff een tip tussendoor, neem in je verkoop records altijd de volgende gegevens mee:
artikelnr, omschrijving, prijs, btw-percentage, aantal

en nog wat velden natuurlijk maar vooral prijs,btw-percentage, aantal die heb je nodig om naderhand btw en omzet berekeningen te maken !

Als je een aparte BTW tarieven tabel bijhoudt met ingangsdatum zou je ipv btw-percentage ook een BTW_ID mee kunnen geven (HOOG,LAAG of NUL). Doe dit dus niet als je vaste BTW percentages gebruikt.

[edit]
Of hebben we het alleen over weergave van verkoop cijfers ??

[ Voor 35% gewijzigd door Verwijderd op 09-01-2004 16:41 ]

[turkosh]

Tnx. Ik heb inderdaad een aparte BTW tabel met de BTW_code, BTW, Omschrijving, datum_ingang, datum_einde.
Ik heb inderdaad de aantallen en btw (en in de eerste instantie de prijs) niet opgenomen in de verkooplijst vanwege het bijhouden van de aantallen bij tabel artikel. Elk vekocht item komt dus in verkooplijst. En na het afsluiten van de shift worden de verkochte artikelen van een bepaald PLU nummer bij elkaar opgeteld en afgeschreven bij boekvoorraad.
En het leek mij handiger om de gegevens bij betreffende tabellen te beheren, omdat je dan alleen de BTW hoeft aan te passen in btw tabel en het wordt zo opgenomen door de rest.
Maar het addertje onder het gras was de prijs. Centraal beheer is fijn, maar niet als het de gegevens onbetrouwbaar maakt.

[xtra]

turkosh schreef op 09 januari 2004 @ 16:54:
Tnx. Ik heb inderdaad een aparte BTW tabel met de BTW_code, BTW, Omschrijving, datum_ingang, datum_einde.
Ik heb inderdaad de aantallen en btw (en in de eerste instantie de prijs) niet opgenomen in de verkooplijst vanwege het bijhouden van de aantallen bij tabel artikel. Elk vekocht item komt dus in verkooplijst. En na het afsluiten van de shift worden de verkochte artikelen van een bepaald PLU nummer bij elkaar opgeteld en afgeschreven bij boekvoorraad.
En het leek mij handiger om de gegevens bij betreffende tabellen te beheren, omdat je dan alleen de BTW hoeft aan te passen in btw tabel en het wordt zo opgenomen door de rest.
Maar het addertje onder het gras was de prijs. Centraal beheer is fijn, maar niet als het de gegevens onbetrouwbaar maakt.

Maar ja, dat geldt natuurlijk ook weer van BTW. Een tarief dat van 17,5 naar 20 naar 19% gaat... (ongeveer dan)

[turkosh]

Had ik toch maar een cout "Hello world!!" project gekozen. :-P

[Crazy D]

turkosh schreef op 09 januari 2004 @ 16:54:
En het leek mij handiger om de gegevens bij betreffende tabellen te beheren, omdat je dan alleen de BTW hoeft aan te passen in btw tabel en het wordt zo opgenomen door de rest.
Maar het addertje onder het gras was de prijs. Centraal beheer is fijn, maar niet als het de gegevens onbetrouwbaar maakt.

Het maakt ze niet onbetrouwbaar, alleen incorrect voor historische gegevens
En daarom moet je altijd de gegevens van dat moment ook in de verkooporder/faktuur opslaan, want dat zijn de gegevens die op het moment van verkoop van toepassing waren. Wat er een dag later ook gebeurt (andere prijzen, BTW, whatever), dat is niet intressant voor eerder ingevoerde verkopen, want die zijn gebaseerd op andere gegevens.

Als je je prijs-veld null-able maakt, kun je daar natuurlijk altijd op checken. Als ik het goed begrijp, mag een prijs alleen gewijzigd worden indien het een 'algemeen' artikel is (snoepgoed, schrijfwaren, etc, wat je gebruikt voor een artikel waarvan de barcode niet leesbaar is). Ik zou dan niet kiezen voor een apart veld om aan te geven of een prijs wijzigbaar is, maar je prijsveld op null zetten. Dit is net zo makkelijk om te checken als een apart veld, en als dat de enige reden is vind ik een apart veld een beetje zinloos (en dat kun je in je query opnemen zodat je in code het alsnog kunt gebruiken alsof het een veld is).

[turkosh]

De prijzen van de "algemene" artikelen heb ik standaard op het bedrag 0.00 gezet. de rest van de artikelen hebben zowiezo een vast bedrag (groter dan 0.00). Maar als ik een artikel verkoop zou ik toch de bedrag moeten aanpassen zonder de artikel gegevens overhoop te gooien.
Dus dat betekent toch dat het prijs invoer op de een of ander manier ook plaats moet vinden in het verkooplijst (want die registreert wat er verkocht is en nu ook voor welk bedrag).
Nu ben ik een oplossing aan het zoeken om de prijs automatisch in te laten vullen tijdens elke nieuwe record in verkooplijst. Die van de algemene artikelen kunnen later nog bijgewerkt worden, want voor zover ik heb kunnen uitvissen doet MySQL niet moeilijk met het wijzigen van gegevens als het eenmaal is ingevoerd.

[Gert]

Je moet sowieso voor elke wijzinging in de artikelen tabel een nieuwe record maken. Stel dat de naam van een artikel veranderd dan mag dat niet betekenen dat op de factuur van oudere orders dit ook veranderd.
In je join van artikel op de transactie moet je dan selecteren op artikel code + datumtransactie tussen begin/einddatum versie artikel.

Ik snap verder niet waar het probleem zit. Je hebt een artikel met prijsloze prijs in de artikelen db, in de order wordt per transactie bijgehouden welke artikel met welke prijs wordt verhandeld. Dan weet je toch genoeg?

[turkosh]

Dat is dus hier niet het geval.
De PLU code wordt gebruikt voor het herkennen van de artikel. Als je bijv. een artikel (blikje cola) niet kan scannen maar je weet de code (4023) dan heb je het ook de prijs.
Het is dus niet de bedoeling dat er na verloop van tijd in lijst artikelen stuk of 5 blikjes cola worden opgenomen met steeds andere PLU code en prijs. Dat is een constraint waaraan ik mij moet houden.
Klinkt misschien stom om het niet te doen, maar zo is het nu eenmaal met de systeem die ik heb geanalyseerd voor mijn project. Ik moet een simulatie daarvan maken en dit is hoe ze omgaan met de gegevens:

Prijs vaste artikelen is centraal te wijzigen.
PLU code per bestaande artikel blijft altijd hetzelfde.
Opgenomen verkoopgegevens hebben geen last van centrale gegevens wijzigingen.
Prijs van algemene artikelen kunnen (tijdens verkoop) altijd worden veranderd zonder de "centrale" gegevens te vernaderen.

[Crazy D]

turkosh schreef op 11 januari 2004 @ 15:17:
Het is dus niet de bedoeling dat er na verloop van tijd in lijst artikelen stuk of 5 blikjes cola worden opgenomen met steeds andere PLU code en prijs. Dat is een constraint waaraan ik mij moet houden.

Als je in die constraint de huidige datum opneemt, heb je als het goed is maar 1 huidige prijs Maar die gegevens moet je imho niet in het artikel-bestand zelf willen bijhouden, hooguit in een aparte ArtikelPrijzen tabel oid.
Maar op zich is dat ook niet nodig. Je bewaard de verkoopprijs in je verkoopregel, eventueel kun je daar nog de omschrijving bijzetten voor de volledigheid. Daar heb je dus je historische gegevens, en je artikelbestand is altijd de basis voor nieuwe verkopen.

Prijs vaste artikelen is centraal te wijzigen.
PLU code per bestaande artikel blijft altijd hetzelfde.
Opgenomen verkoopgegevens hebben geen last van centrale gegevens wijzigingen.
Prijs van algemene artikelen kunnen (tijdens verkoop) altijd worden veranderd zonder de "centrale" gegevens te vernaderen.

Wat is het probleem dan?
Je artikel-bestand is altijd leidend voor nieuwe verkoop. Historische verkopen hebben daar niks mee te maken, daarbij sla je immers de prijs etc al op. Dus je hebt 1 plek waar je gegevens staan en onderhouden moeten worden: het artikelbestand

Het toestaan van wijzigen van de prijs zul je in je applicatie moeten doen. De prijs die je bij de algemene artikelen invoert, komt dus alleen in je verkoop-regel te staan (net zoals dat je bij 'normale artikelen' de prijs uit het artikelbestand overneemt). Overnemen van de prijs uit het artikelbestand is ten 1e standaard SQL, en ten 2e denk ik dat je die prijs moet ophalen bij het scannen. Ik neem tenminste aan dat je via een aparte functie de verkooporder definitief wegschrijft? Stel dat iemand tussen het moment van scannen (waarbij de klant de prijs doorkrijgt, en die is dus geldig op dat moment) en het moment van 'definitief maken van de verkoop' de prijs wijzigt, krijg je vreemde verschillen waarnaar je erg lang kunt zoeken (ja, praktijkvoorbeeld uit een niet nader te noemen bekend boekhoudpakket).

[turkosh]

Ik denk denk dat ik me te veel zorgen maak om niets. Het is maar een project voor school (van je mogelijke fouten leer je toch?).
Trouwens is het handig om ook in mijn tabel op tenemen de variabele garantie tijd (bijv. tot aan de deur, aanraken is kopen e.d.) :-P

[xtra]

turkosh schreef op 12 januari 2004 @ 20:33:
Ik denk denk dat ik me te veel zorgen maak om niets. Het is maar een project voor school (van je mogelijke fouten leer je toch?).
Trouwens is het handig om ook in mijn tabel op tenemen de variabele garantie tijd (bijv. tot aan de deur, aanraken is kopen e.d.) :-P

Nee, tenzij je het nodig hebt. Bij TV's en andere min of meer duurzame goederen wil je zoveel mogelijk informatie bij elkaar. Voor rollen drop geldt dat wat minder.

Je kunt het zo uitgebreid maken als je wilt. Garantie in maanden in je tabel of verwijzen naar een tabel met vaste garantievoorwaarden. Eventueel met verlengde garantie.

Ik neem aan dat je opdracht voor school wel ongeveer aangeeft waar de beperkingen liggen. Als je daaraan voldoet (+ een beetje extra voor de bonuspunt) doe je meer dan genoeg naar mijn mening.