[DB] Prijzen bijhouden, omgaan met wichtsprijzen

[ShitHappens]

Ik ben momenteel een database aan het ontwerpen voor een programma, met de volgende doelen:
- Bijhouden hoeveel ik uitgeef, en waaraan. Dit ook ingedeeld in categorieën (geef ik meer uit aan groenten, vlees of drank?)
- Het prijsverloop van een artikel bijhouden (hoe vaak word het duurder/goedkoper)
- Prijsvergelijkingen gaan maken (is artikel A goedkoper bij supermarkt Y of X?)

Dat heb ik vervolgens in een ERD gezet:

Nu zit ik alleen nog met één gigantisch punt:
Zoals deze database nu is ingericht, kunnen alleen artikelen verwerkt worden met een stuksprijs. Nou heb je alleen met kaas/vlees/groenten/fruit nog wel eens te maken met een wichtsprijs. Dat zou nu lastig worden om op te slaan.
Praktisch voorbeeld:
Ik heb hier een pakje kaas liggen. Deze heeft als EAN nummer 2302530702668. Het dikgedrukte gedeelte de prijs: €2,66. Deze wichtartikelen zijn te herkennen omdat hun EAN begint met 22 of 23. In principe sla je die dan op in de tabel Prodcuct_EAN onder het stamnummer 2302530700000.
Ga ik die nu opslaan, en haal later diezelfde kaas weer met een andere prijs, zal deze niet herkend worden. In principe kan dit een hoop duplicaten gaan opleveren.

Daarnaast kan er niet worden omgegaan met aanbiedingen. En ja, daar houden we natuurlijk wel van.

Nu zit ik er aan te denken, om dan het programma de prijs te laten uitrekenen, en die dan in een veld bij Aankoop op te slaan. Dit kan dan zowel met de wichtartikelen en aanbiedingen. De koppeltabel ProductPrijs komt dan te vervallen.

Zou dit een "nette" oplossing zijn? Of zie ik nu een manier over het hoofd?

[Gerco]

De prijs die je hebt betaald moet je altijd bij de transactie opslaan. Wat zou er anders gebeuren wanneer de prijs van een artikel veranderd om de 1 of andere reden? Je bestaande transacties zouden dan opeens een andere prijs krijgen en dat kan natuurlijk niet.

De betaalde prijs is niet hetzelfde als de prijs van een artikel. Het is een ander gegeven wat toevallig vaak overeen komt met de stickerprijs van een artikel, maar niet altijd. Er zijn allerlei redenen waardoor die anders kan zijn: prijswijzigingen, kortingsacties, bonuscombinaties, wichtartikelen, etc. Bijvoorbeeld ook een eenmalige korting omdat het artikel bijna over datum is of misschien wel een tegemoetkoming van de winkel omdat het artikel verkeerd geprijsd bleek.

[ Voor 25% gewijzigd door Gerco op 29-05-2014 21:49 ]

[ShitHappens]

Voor je eerste punt: daarvoor is het veld VanafDatum in de tabel ProductPrijs. (zie net dat deze eigenlijk ArtikelPrijs moest heten om concequent te zijn, maar dat terzijde).
Dit zodra bij een winkel een artikel in prijs verandert, deze als nieuw record toegevoegd kan worden. Als je dan een artikel daarin opzoekt, zie je direct wanneer de prijswijzigingen waren.

Het is overigens niet relevant in deze situatie om artikelen tot op transactieniveau op te slaan: een datum volstaat.

Over je tweede opmerking:
Daar ben ik me volledig van op de hoogte. Daarom zat ik er dus ook aan te denken om bij een nieuwe Aankoop juist daar de prijs ervan op te slaan (per stuk teruggerekend). Dit lost dan ook het probleem rondom de wichtsartikelen op.

[ Voor 18% gewijzigd door ShitHappens op 29-05-2014 21:57 ]

[Xaero]

Je kan met types gaan werken welke er voor zorgen dat de weergave verschilt. Bijvoorbeeld een kolom met 'type' welke 'stukprijs' of 'gewichtprijs' is. Vervolgens ook een kolom met het gewicht. De prijs sla je bij de gewicht op als prijs per gram of per kilo. Bij per stuk laat je dit gewoon.

Daarnaast kan ik eigenlijk niks vinden over een prijs met een EAN code, weet je zeker dat dit klopt?

Net even een pak kaas er bij gepakt, en zie dit idd ook terug.. Is het niet zo dan dat het eerste gedeelte van bijvoorbeeld de EAN code laat zien dat het kaas is?

[ Voor 17% gewijzigd door Xaero op 29-05-2014 22:08 ]

[Fish]

Ook het geldende btw tarief opslaan

Je moet natuurlijk nie werken met een stuksprijs maar met een eenheid een kwantiteit. heb je al nagedacht over staffelkortingen ?

Kijk maar bij de ah daar zie je precies het zelfde bij de vleesafdeling. de prijs in de ean.
Maar daar moet je dan rekening mee houden oid. e.g creeer je een ean range waar die prijs dus tussen kan vallen. of als het een vaste lengte is een vinkje erbij "ean contains price"oid

[ShitHappens]

Xaero schreef op donderdag 29 mei 2014 @ 22:03:
Je kan met types gaan werken welke er voor zorgen dat de weergave verschilt. Bijvoorbeeld een kolom met 'type' welke 'stukprijs' of 'gewichtprijs' is. Vervolgens ook een kolom met het gewicht. De prijs sla je bij de gewicht op als prijs per gram of per kilo. Bij per stuk laat je dit gewoon.

Daarnaast kan ik eigenlijk niks vinden over een prijs met een EAN code, weet je zeker dat dit klopt?

Net even een pak kaas er bij gepakt, en zie dit idd ook terug..

Dat is inderdaad een goede optie, ga ik even uitwerken.

En ja, daar ben ik zeker van. 6 jaar in supermarkten gewerkt, moeder is data-analist bij een marktonderzoeksbureau en bevestigt dit Zit bijvoorbeeld dit: http://www.psretail.eu/ps.../Instructie-Map/xxx-J.pdf hoe dit in kassasystemen wordt afgehandeld.
De eerste cijfers (in mijn voorbeeld dus 23025307) vermeldt dus het daadwerkelijke artikelnummer. (In dit geval "AH Zaanlander 48+ Jonge graskaas in plakken").

fish schreef op donderdag 29 mei 2014 @ 22:06:
Ook het geldende btw tarief opslaan

Je moet natuurlijk nie werken met een stuksprijs maar met een eenheid een kwantiteit. heb je al nagedacht over staffelkortingen ?

Kijk maar bij de ah daar zie je precies het zelfde bij de vleesafdeling. de prijs in de ean.
Maar daar moet je dan rekening mee houden oid. e.g creeer je een ean range waar die prijs dus tussen kan vallen. of als het een vaste lengte is een vinkje erbij "ean contains price"oid

Ik heb het idee dat jij heel erg richting een verkoop/kassa achtig systeem zit te denken. Het idee is echter dat het bedoeld is om uitgaven bij te houden (a la huishoudboekje, enkel voor de boodschappen). BTW acht ik niet zeer relevant. Daarom hoeven kortingen ook niet zo heel complex erin verwerkt te worden. Heb je een "2e halve prijs" aanbieding gekocht, volstaat het om beide artikelen op te slaan met 25% van de prijs afgetrokken.


Ik heb 'm nu dus zo gedaan:

Met als veranderingen:
- In tabel Aankoop kun je aangeven of er een korting gegeven is op het betreffende artikel
- In tabel Artikel_Prijs zit een boolean: 1 indien prijs per stuk, 0 indien prijs per kilo. Bij wichtsartikelen dan in Aankoop in Aantal het gewicht in kg invoeren. (kan het programma berekenen adhv de prijs in de barcode en de kiloprijs in Artikel_Prijs)

Dit zou dan de problemen moeten tackelen toch?

[ Voor 56% gewijzigd door ShitHappens op 29-05-2014 23:01 ]

[ACM]

De prijs is altijd een 'prijs per eenheid', je kan er dus ook voor kiezen om bij te houden wat dan eigenlijk een eenheid is. Op die manier kan je eventuele andere scenario's uit gaan werken zonder dan je boolean weer te moeten uitbreiden.

Voorlopig zijn de mogelijkheden bij je 'eenheid' dan 'per kilo' of 'per stuk', maar wellicht is er ook iets dat per liter werkt.
Sterker nog eigenlijk hoef je dat niet eens bij te houden, bij je aankoop-aantal kan je gewoon het juiste cijfer neerzetten (dus 1 voor een stuksprijs en 0,295 of 295 als je ergens 295g van hebt gekocht).

Verder zou ik bij de aankoop het daadwerkelijke bedrag bewaren, zoals eerder al gemeld. Dat maakt allerlei samenvattende queries een stuk makkelijker en bovendien zorgt het ervoor dat je geen fouten maakt met kortingscijfers.

Ik wens je trouwens succes met het bijhouden... het lijkt me een enorme, saaie klus om dat elke week weer allemaal te gaan zitten invoeren. Of ga je ook nog een OCR-scanner maken om kassabonnen te interpreteren (niet dat daar de EAN's op staan, dus dat wordt ook nog een uitdaging)?

[ShitHappens]

Per eenheid opslaan klinkt inderdaad wel een goeie optie. Nu ken ik (behalve benzine) nog niets dat per liter verkocht wordt, maar zie er wel potentie in. Met name op gebied van prijzen vergelijken.

Daadwerkelijk bedrag opslaan onder Aankoop leek me niet de meest "nette" versie maar gaat het wel allemaal een stuk makkelijker ja.

De grootste klus wordt het inkloppen van de gegevens. Gelukkig heb ik wel een barcodescanner, en alle producten die ik zeer regelmatig haal zijn al in huis. Van al het AH-spul (daar doe ik 70% van de boodschappen) zijn de prijzen on-line te vinden. Dan is het daarna per winkeltrip een kwestie van alles even bliepen en eventueel korting toekennen.

OCR zat ik ook wel aan te denken. Bij de Spar (waar de rest van de boodschappen vandaan komen) zijn de kassabonteksten specifiek genoeg om te herleiden naar één artikel. Alleen doe van de AH zijn heel beperkt in lengte, waardoor heel veel bontekst-prijs combinaties niet uniek zijn. Of dezelfde omschrijving bij 2 totaal verschillende producten (zowel een pizza als bakmix staan er als DR OETKER op).

[kwaakvaak_v2]

ShitHappens schreef op vrijdag 30 mei 2014 @ 15:52:
Per eenheid opslaan klinkt inderdaad wel een goeie optie. Nu ken ik (behalve benzine) nog niets dat per liter verkocht wordt, maar zie er wel potentie in. Met name op gebied van prijzen vergelijken.

Niet helemaal waar, Cola heeft bijv. ook een literprijs, ondanks dat jij misschien een fles van 1.5 of 2 liter koopt. Ik kijk er tenminste altijd na in de supermarkt, want omdat iets in een grotere fles zit het niet automatisch betekend dat het goedkoper is. Zeker niet met aanbiedingen bijvoorbeeld.

En wat dacht je van luiers, niet iets wat de meeste mensen kopen, maar als je het dan toch doet is het handig om daar bijv. de stuks prijs bij te houden ipv de prijs per pak.

[ShitHappens]

Punt dat ik meer probeerde te maken, was dat je bij iets als cola of melk altijd vast zit aan een vaste verpakking (0,5L, 1L, 1,5L, 2L etc.), het is niet zo dat je een kraantje kunt opendraaien om de gewenste hoeveelheid te tappen.

Ik heb het uiteindelijke database-ontwerp nog wel wat aangepast. Juist om makkelijk prijzen te kunnen vergelijken. Zo staat bij Artikel ook de inhoud geregistreerd in stuks, liters of kilogrammen.

[Voutloos]

ShitHappens schreef op donderdag 29 mei 2014 @ 22:08:
Daarom hoeven kortingen ook niet zo heel complex erin verwerkt te worden. Heb je een "2e halve prijs" aanbieding gekocht, volstaat het om beide artikelen op te slaan met 25% van de prijs afgetrokken.

Ehm, dat lijkt mij juist de eenvoudigste feature/idee voor een van je doelen: Dit zouden juist de aankopen zijn waar je bespaard hebt. Of misschien wel geld weggegooid hebt, als je iets overbodigs pakte omdat het een aanbieding was.

Aka: van een notepadje met kortingen leer je wellich qua inkoopbeleid al meer, met niet eens een 10e vd inspanning.

Een hele db opzetten en bijhouden is jezelf nerd snipen. De DB opzetten is uiteraard wel leerzaam, maar ik ben skeptisch over hoe doeltreffend het is.

[ShitHappens]

Het houdt me voorlopig even bezig (te veel vrije tijd) en zal er ongetwijfeld nog wat nieuws van leren of ontdekken

[Fish]

kwaakvaak_v2 schreef op maandag 02 juni 2014 @ 09:15:
[...]


Niet helemaal waar, Cola heeft bijv. ook een literprijs, ondanks dat jij misschien een fles van 1.5 of 2 liter koopt. Ik kijk er tenminste altijd na in de supermarkt, want omdat iets in een grotere fles zit het niet automatisch betekend dat het goedkoper is. Zeker niet met aanbiedingen bijvoorbeeld.

En wat dacht je van luiers, niet iets wat de meeste mensen kopen, maar als je het dan toch doet is het handig om daar bijv. de stuks prijs bij te houden ipv de prijs per pak.

Bij coca cola kan de literprijs juist per verpakking enorm wissellen
Maarrrrrr. elke verpakking heeft weer zijn eigen ean. de literprijs is dus ook per verpakking bij te houden, dus niet zon ramp

Je koopt echter niet iets uit een ktraan oid. ik zou dan wel de hoeveelheid verpakkingen reistreren en niet de liters. dat is een mooie eigenschap van het produkt in dit geval

[The Eagle]

Waarom wil je dit, en waarom beperk je dit alleen tot een supermarkt
De meeste banken kennen een financieel dagboek in telebanking, waarbij je zo kunt zien wat je waaraan hebt uitgegeven. Gaat weliswaar tot niveau boodschappen en niet in detail, maar de vraag is waarom je dat detail zou willen weten.

Verder: Als jij een bonuskaart bij de AH hebt houden ze al bij wat je koopt. Volgens mij moet je ze op basis van de privacywetgeving zo kunnen vragen om een uitdraai.

Ik snap dat het bezigheidstherapie voor je is, maar toch - ik denk dat je je tijd beter kunt besteden

[ShitHappens]

Het feit dat ik dit tot in detail wil weten/bijhouden is dat ik een éénpersoonshuishouden heb, en Tim (het online huishoudboekje) geeft soms bijzonder hoge bedragen voor de boodschappen. Dit terwijl ik weet dat het niet zo veel zou hoeven zijn. Daarom wil ik graag voor mezelf helder hebben wat er nou ik huis komt.
Soms zie ik een paar dagen achter elkaar transacties van €30 aan boodschappen, denk dan bij mezelf "WTF heb ik dan gekocht?", bonnetje alweer kwijt en dat soort problemen. De aankoopgeschiedenis zoals AH deze online toont is wel heel erg karig.
Maar goed, inmiddels zitten we wel heel erg ver van het oorspronkelijke onderwerp af, dat inmiddels behandeld en voltooid is.

[ Voor 10% gewijzigd door ShitHappens op 02-06-2014 11:11 ]