Sitter och planerar lite inför en webbshop som jag ska bygga. Shoppen ska inkludera lagersaldo. Om saldot är <= 0 så ska produkten inte gå att köpa. Det finns dock ett undantag, en produkt kan markeras/taggas som beställningsvara och då ska lagersaldot kunna vara negativt.
Hur löser man det här på bästa sätt? Har funderat fram och tilllbaka och tänker mig en extra tabell som innehåller:
ProduktId (INT)
Saldo (INT)
Uppdaterad (DATETIME)
När man är inne på en produkt så kollar man mot lagertabellen och räknar fram aktuellt lagersaldo med hjälp av Saldo - (alla ordrar som innehåller produkten där orderdatum >= datum för senaste saldouppd.).
Eller finns det andra, bättre sätt att hantera det här?
Som jag har förstått så är det bokföringsmässigt att föredra att man gör ett FIFO (First In-First Out) lager för att få rätt lagervärdering. Det är riktigt svårt databasmässigt att implementera.
på en av shopparna jag byggt så har jag nåt liknande ditt förslag
jag lagrar dock lagersaldo i produkt-tabellen (databasen såg ut så när jag fick ta över projektet) Sen när något läggs i varukorgen så "reserveras" ett exemplar. Detta genom att jag helt enkelt räknar ihop "antal i varukorg"+"antal i ej skickade orders"
Att jag räknar in varukorg(ar) beror på att vissa saker finns det ytterst få av och man vill slippa att 4 kunder lyckas beställa det sista exemplaret.
När man sen bekräftar en order så räknas lagersaldot om.
Problemet är spårbarhet, dvs OM det blir fel så är det lite knepigt att se när lagersaldot börjar skeva. Så man skulle kunna ha en tabell som håller ordning på alla butikens uppdateringar av saldot (påfyllning/justering)
Man kanske kan göra så att man har en tabell Inleverans, där man håller koll på leveranstyp (inleverans eller justering), har ett inleverans_id för att koppla artikeln till en inleverans, sen kör man en kolumn med order_id, med id till den order eller justering där artikeln är förbrukad. För att få lagersaldot blir det nåt liknande:
SELECT COUNT(OrderId IS NULL) AS Aaldo FROM Inleverans WHERE ArtikelId = $id
Jag lyckas inte förstå eller komma på hur jag ska lösa det här. Vill ju hålla det enkelt, men samtidigt måste det fungera på ett bra sätt. Jag tror att jag kör på något liknande rhdf's lösning, där jag kör saldo i produkttabellen.
Har dykt på en liten issue nu mitt i arbetet. Jag har gjort så att man kan definera ett antal egenskaper (t.ex. XL, L, M, resp. Grön, Röd, Gul osv.) som man sedan kan koppla till varje produkt.
Nu behöver jag kunna hålla koll på lagersaldo för en enskild grundprodukt+egenskap. Det kan ju vara så att "T-shirt grön" kan finnas i 3 exemplar av Medium, 2 ex i Large osv. Hur löser jag det? Det lättaste bör ju vara att det skapas en artikel för varje grundprodukt+egenskap. Låt säg att man lägger upp en produkt som heter "T-Shirt Röd" som får artikelnummer "123456". Bockar man sedan i att den finns i storlekarna S, M, L så skapas produkterna "123456-1" , "123456-2", "123456-3".
På så sätt kan man då föra lager över varje enskild egenskap. Men hur löser jag det här på bästa sätt rent administrativt? Känner jag att målat in mig i ett hörn och kommer inte riktigt vidare i brist på idéer.
Ja, det borde väl inte vara några problem att lägga in dem som olika artiklar. Förstår inte Vad det blir för problem rent administrativt, borde väl gå bra?
Jo, jag är med på ungefär hur jag bör göra. Säg att man lägger till "T-Shirt Röd". Man anger ett pris, lagersaldo, osv.
Sen bockar man i vilka storlekar som ska finnas. När man sedan sparar skapas x antal artiklar av produkten och dessa kan sedan hanteras enskilt, d.v.s. man kan ha olika pris för olika artiklar av samma produkt. Ska lägga till en kolumn "sub id" eller så i databasen, som börjar på 1 och tickar uppåt för varje produkt+egenskap man lägger till. Senare om man i shoppen går in på artikel "123456-1" så kan ev. andra produkter som heter "123456-x" hämtas.
Min tanke var att man helt enkelt lägger in "T-Shirt Röd M", "T-Shirt Röd L" osv. Men då måste man nog ändå gruppera dem när man visar dem. Tänkte inte på det.
På den tiden när jag byggde stora lager, var det viktigt att att ha leverantör och batch (tidpunkt) med. Då kan man ta ut rätt saker till rätt pris samt ha koll på lagersaldot i kostnader.
Varje produkt har ju även en hanterings och lagerkostnad om man skall vara noggrann säger Lasp
Den här shoppen ingår i ett föreningssystem och ska vara välidgt basic. Det enda som skiljer min shop från det enklast tänkbara är just hantering av lagersaldo och det har visat sig vara mer avancerat än jag någonsin kunnat föreställa mig :)
Men jag tror att jag är hemma med min lösning ovan!
På den tiden när jag byggde stora lager, var det viktigt att att ha leverantör och batch (tidpunkt) med. Då kan man ta ut rätt saker till rätt pris samt ha koll på lagersaldot i kostnader.
Varje produkt har ju även en hanterings och lagerkostnad om man skall vara noggrann säger Lasp
Japp, jag håller med. Det var det jag påpekade med ett FIFO-lager. Men jag vet inte riktigt hur man ska designa tabellerna på att bra sett för FIFO med varukostnaden inräknad. Det är ju ganska svårt att få ut varukostnaden med SQL, eller har du någon bra databas-design för det?
Man kan ju ha en tabell med alla köpta produkter, antal och tidpunkt. Sen har man en tabell med alla inköp: antal, leverantör, varukostnad, tidpunkt... Hur gör man då för att få ut varukostnaden för en köpt produkt enligt FIFO?
Nu har jag fullständig koll på det här, ska bygga om databasen lite så att det blir något i stil med det här:
Kategori
ID
Namn
Beskrivning
Produkt
ID
Parent (Kategori.ID)
Namn (t.ex. T-Shirt, Röd)
Beskrivning
Artikelnummer
Bild
Kostnad
Beställningsvara (ja/nej)
Produktegenskap
ID
Parent (Produkt.ID)
Namn (t.ex. XL)
Lagersaldo
Varje produkt kommer alltså bestå av X antal artiklar och det måste finnas minst 1 artikel kopplat till en produkt för att det ska visas. När man går in på en produkt visas alla olika egenskaper (artiklar) i en rullista.
