Prisjämföreselse-system

[Christoph]

Hej,

 

jag har en idé som jag tror skulle vara till stor nytta för det lilla samhället jag bor i, nämligen ett system som gör det möjligt för lokalbefolkningen att jämföra priser på främst livsmedel som säljs här i trakten. Den stora fördelen jag har är att jag är bosatt på en ö med några få butiker, dvs det gör det ganska så enkelt att jämföra varornas priser.

 

Men - hur får man folk att mata in hela eller delar av sitt kvitto enklast, eftersom det är A och O för ett fungerande system? Jag tänker t ex på en bra och smart autocomplete-funktion, samt att tagga varorna så att man snabbt kan identifiera varorna från en lista över varor som redan finns i systemet, dvs sådant som någon annan har matat in tidigare. Men för detta behövs det givetvis en lista med inlagda produkter redan. Hur fyller man på den listan snabbt, sådant tänker jag på.

 

En annan sak jag tänkte på är detta med olika produkter men ändå av samma "typ" - 500 gram Oboy mot Willy's motsvarighet, som dessutom säljs som 700 gram. Och så vidare.

 

Finns det någon där ute som har några spontana tanker, input, idéer, så är jag mycket tacksam för allt sådant jag kan få tag i. Här nedan ett första utkast på en struktur på detta.

 

Tack för hjälpen,

 

Christoph

 

 

 

 

Produktgrupp
Produktgrupp-Id
Produktgruppnamn
(Huvudgrupp, t ex Livsmedel?)

Produktdetaljer
Produkt-id
Pruduktgrupp-id
Produktnamn
Märke-id
Enhet
Antal i förpackningen

Märke
Märke-id
Märkesnamn

Enheter
Enhet-id
Enhetnamn

Taggar
Produkt-id
Tagnamn




Exempel:

Produktgrupp
1		Läsk
2		Tvättmedel
3		Ris
4		Potatispuré

Produktdetaljer
1	1	Coca-Cola		1		1	1500		1
2	1	Fanta			1		1	1500		1
3	2	Ariel			2		2	800		1
4	3	Långkorningt ris	3		2	400		1
5	3	Jasminris		4		2	500		1


Märke
1		Coca Cola
2		(okänd)
3		Uncle Ben's
4		Lidl
5		Euroshopper

Enheter
1	ml
2	gramm
3	stk

Taggar
1	Coke
1	Cola
2	för färgat tvätt

[.M]

Det allra snabbaste sättet att skapa en lista med varor är att be butikerna lämna in en. Nackdelen är att dom kanske inte vill vara med i ditt projekt. Och då är antagligen alternativet att knata runt i varje butik och inventera för hand.

 

Och återigen, om en butik inte vill vara med, hur ska du hantera det?

 

Men annars så kanske du får skapa en OCR-funktion som läser in kvitton.

[Monshi]

Skaffa en handhållen OCR-skanner och gör en turné....

 

Eller skriv en App för Android/Iphone som kan skanna in produktkod och pris, på något vis, från hyllan. Eller från kvitton.

 

men som sagt, problemet blir att få folk att använda det hela. Enklast vore om affärerna öppnade upp sina system för dig men det kommer nog aldrig att ske.

[Christoph]

Skaffa en handhållen OCR-skanner och gör en turné....

 

 

Oki, så mycket till att få in någon bas, det ordnar sig säkert. Tack för inputten!

 

Hur är det med de andra punktr, är det någon som har en idé om de andra punkter, typ

 

Men - hur får man folk att mata in hela eller delar av sitt kvitto enklast, eftersom det är A och O för ett fungerande system? Jag tänker t ex på en bra och smart autocomplete-funktion, samt att tagga varorna så att man snabbt kan identifiera varorna från en lista över varor som redan finns i systemet, dvs sådant som någon annan har matat in tidigare.

 

samt

En annan sak jag tänkte på är detta med olika produkter men ändå av samma "typ" - 500 gram Oboy mot Willy's motsvarighet, som dessutom säljs som 700 gram. Och så vidare.

 

Mera inne på själva utvecklingsbiten alltså.

 

Tack för hjälpen, än en gång!

[Monshi]

Som sagt, det enklaste vore om butikerna kunde ställa upp och ge dig en datafil över de varor du önskar jämföra.

Att börja jämföra kvitton är nog inte det enklaste och kommer kräva en hel del manuellt arbete.

 

Det är ju inte sällan kvitton är mindre tydliga, vid köp av tomater kan man ju få allt från Kvist Tom, kvTomat, Tomat Holl, Tomat, plommon, Tomat (kampanj) osv. Variationerna inom en kedja är många och att då få ihop så man kan jämföra olika butiker. Dvs svårt att läsa av kvitton och jämföra dem.

 

Känns som en ganska stor tröskel att ta sig över och inte blir det mycket lättare över tid...

 

Å andra sidan kan man förenkla det och helt enkelt kalla tomat för tomat, makrill för makrill, tonfisk i olja för tonfisk i olja och inte bry sig om att det finns delfinfri tonfisk..

 

Helt enkelt fundera ut vilken detaljnoggrannhet du önskar, hur du vill ta in dina data, vilka system som fungerar. skanna in? OCR? Då måste du få tag på kvittona och skanna in dem och tolka dem för inte har varje användare en skanner?

 

Om nu användaren ska mata in får du nog begränsa antalet produkter, ta en standardkorg som start. Kanske låta användarna notera nya produkter med risk för att det blir väldigt rörigt.

 

Enklaste vore nog, ärligt talat, att skapa ett program för Android som låter användare gå runt i butik och koppla EAN-kod med produkt och kedja/butik för att sedan mata in priset.

Då kommer samma EAN-kod dyka upp på alla paket med Oboy 500 gram, du får en unik identifikation, men flera olika för tomater exempelvis beroende på butik och tomatsort/leverantör.

 

Oavsett är problemet att få in uppgifterna och hålla dem aktuella. Utan automatiskt system...blir det nog svårt.

[Christoph]

Precis min uppfattning, mycket medveten om problematiken. Jag tänkte också att det kanske är bäst att satsa på "Makrill är makrill", men att den som matar in sina artiklar kan, om han vill eller kan utläsa det från kvittot/memorerar, lägga till den informationen om vad det är för sorts makrill han köpte.

 

EAN-idén, och även butikernas datafiler, gillar jag inte riktig, även om det skulle underlätta en hel hel del, det kan jag hålla med om. Men problemet där är att det blir allt för stelbent att kunna jämföra - personligen bryr jag mig inte så värst mycket om vilken makrill jag köper, det är främst priset som avgör där. Så produktgrupper i olika nyanser mm är A och O här, för att kunna gruppera olika produkter till "Makrill" och göra produkterna inom gruppen jämförbart - förstår du hur jag tänker?

 

Hälsningar,

 

Christoph

[Monshi]

En fundering, vad är det du önskar hjälp med egentligen, vad är din fråga? Några exakt pekpinnar "såhär-ska-du-göra" kan jag inte ge.

 

Skriv upp en kravspec, fundera ut hur denna ska implementeras (databas, språk, webbmotor, kostnad/ersättning) och sätt igång att arbeta med det. Vore nog inte fel att skaffa din en kompanjon som du kan bolla idéer med.

[Christoph]

En fundering, vad är det du önskar hjälp med egentligen, vad är din fråga? Några exakt pekpinnar "såhär-ska-du-göra" kan jag inte ge.

 

Skriv upp en kravspec, fundera ut hur denna ska implementeras (databas, språk, webbmotor, kostnad/ersättning) och sätt igång att arbeta med det. Vore nog inte fel att skaffa din en kompanjon som du kan bolla idéer med.

 

Jag har en kompanjon, och vi bollar konstant, men jag tyckte det vore bra att få in lite extern input, bara för att checka om vi är på rätt eller fel spår, lite om hur databasstrukturen kan/bör vara, lite sådant. Jag tänkte satsa på MySQL, PHP, möjligen med stöd av CodeIgniter.

 

Jag var inte ute efter en komplett lösning, missförstår mig inte. Mera efter lite bollandet på den tekniska biten, som sagt så är just databasstruktren avgörande.

[Jonas__B]

Jag skulle hellre säga att det är konceptet och datainsamlingen (flödet) som är avgörande. Får man allt klart för sig går det att lösa databas och programmeringsmässigt.

[Monshi]

Okej, då är jag med.

Då är frågan vilken detaljrikedom man ska kunna spara data i. I mina ögon, ju fler detaljer desto bättre men ur användarsynpunkt får det samtidigt inte blir för svårt.

 

Om vi tar exemplet makrill igen, de varianter som finns.

Vi har fisk, en makrill

Den kan vara färsk, hel, filead, konserverad i tomatsås och då i olika storlekar, olika märken, olika pris.

Frågan då är Makrill i sig är en produkt som har egenskapen färsk, filead eller om makrill färsk, filead är en namnet på produkten...

 

Grundläggande tankar om hur databasen ska se ut, hur den ska fungera.

ja, i stil med det du skrev i första inlägget i tråden.

Kanske färsk, konserv, halvkonserv, fryst, torkat osv är egenskaper som ska kunna anges, kanske en produktkategori...