Så bygger du en lagerhanteringsapp för ett småföretag

För att bygga en lagerhanteringsapp behöver du fyra saker: en lista med artiklar, antalet av varje artikel på varje plats, en logg över varje lagerrörelse (in, ut, justerad, med skäl) och varningar för lågt saldo baserade på en beställningsgräns. En AI-appbyggare kan skapa databasen, skärmarna och varningarna utifrån en vanlig beskrivning. Det designval som betyder mest är att registrera rörelser i stället för att bara skriva över ett antal, eftersom historiken är det som gör att du kan lita på siffrorna.

Varför småföretag bygger sin egen

De flesta småföretag börjar hålla koll på lagret i ett kalkylblad, och det fungerar tills det inte gör det. De vanliga brytpunkterna:

• Flera personer uppdaterar kalkylbladet och skriver över varandra
• Ingen kan se varför ett antal ändrades eller vem som ändrade det
• Något tar slut innan någon märker det
• Lagret finns på fler än ett ställe (butiksgolv, lagerrum, skåpbil, andra enheten)
• Kalkylbladet har fått instruktioner för hur det ska användas

Färdig lagerprogramvara finns och är ofta rätt svar (se slutet av den här guiden). Folk bygger egna när lagret är ovanligt (partier med bästföredatum, varor som tillverkas av andra varor, uthyrning som kommer tillbaka), när de bara behöver en bråkdel av en stor produkt, eller när de vill att den ska passa exakt hur teamet arbetar. Om du kommer från ett kalkylblad är så gör du en app av ett kalkylblad en användbar följeslagare.

Vad appen behöver

Kärndata

Den centrala idén: lagersaldot är resultatet av rörelserna. Varje ändring går genom en rörelsepost, och antalet i lager uppdateras utifrån den. Det ger dig en granskningslogg på köpet och gör misstag enkla att spåra och ångra.

Kärnskärmar

• Artikellista med sökning, kategorifilter och ett filter för ”lågt saldo”
• Artikelsida som visar antal per plats och senaste rörelser
• Snabbjustering: ta emot varor, ta ut varor, flytta mellan platser, registrera en inventering
• Vy för lågt saldo: allt på eller under beställningsgränsen, grupperat per leverantör
• Inventeringsläge för periodiska inventeringar, som registrerar skillnaden som en justering

Senare, om du behöver dem

• Inköpsorder: skapa en order till en leverantör och ta emot mot den
• Partier och bästföredatum för livsmedel, kosmetika och läkemedel
• Materialförteckning: en färdig produkt gjord av komponenter, så att försäljning av en minskar flera
• Rapporter: lagervärde, långsamt rörliga artiklar, användning över tid (se så bygger du en dashboard)
• Streckkodsskanning med telefonens kamera

Beslut att fatta innan du bygger

Vem som är källan till sanningen

Om du säljer via en webbutik eller ett kassasystem som redan håller koll på lagret, bestäm vilket system som äger antalet. Två system som båda redigerar samma siffror glider isär. Alternativ:

1. Din app är bara till för det butiken inte håller koll på (råvaror, förbrukningsmaterial, lagerrumsvaror).
2. Butiken är källan; din app läser från den för rapporter och varningar via dess API.
3. Din app är källan och skickar antal till butiken. Det mest kraftfulla, och det mest arbete att få rätt.

Börja med alternativ 1 eller 2, det är betydligt säkrare.

Vem som får göra vad

Att dölja inköpspriser för vissa personal är ett vanligt krav; säg det i din första prompt. Riktiga behörigheter kräver app-inloggning, som tas upp i så lägger du till inloggning i din app.

Telefon eller dator

Lagerarbete sker stående: i lagret, vid leveransdörren, i skåpbilen. Designa justerings- och inventeringsskärmarna för telefon först, med stora knappar och så lite skrivande som möjligt. Rapporter och redigering av artiklar kan vara datorförst.

Bygg steg för steg

Steg 1: Rensa din nuvarande data

Exportera ditt kalkylblad och städa det innan import: en rad per artikel, enhetliga enheter, unika artikelnummer, inga sammanfogade celler. Det tar längre tid än folk tror och sparar mycket problem senare.

Steg 2: Skriv första prompten

Beskriv verksamheten, lagret, personerna och rörelserna:

Bygg en lagerapp för Fern & Stone, en växtbutik med butiksgolv, lagerrum och en leveransbil. Artiklar har namn, artikelnummer, streckkod, kategori, enhet, inköpspris, försäljningspris, leverantör och en beställningsgräns. Spåra antal per plats. Varje ändring är en lagerrörelse med typ (mottagen, såld, skadad, inräknad, flyttad), antal, anteckning, användare och tid — ändra aldrig antal direkt. Skärmar: sökbar artikellista med filter för lågt saldo, artikelsida med lager per plats och rörelsehistorik, en snabbjusteringsskärm anpassad för telefon, och en sida för lågt saldo grupperad per leverantör. Personal kan inte se inköpspriser; chefer kan det. Använd en databas, enkel och snabb design. Låt mig importera artiklar från en CSV-fil.

Steg 3: Importera och kontrollera

Importera din rensade CSV-fil och kontrollera tio artiklar mot verkligheten. Felaktiga startsaldon undergräver förtroendet för appen från första dagen, så gör en verklig inventering av dina viktigaste artiklar den dag du byter.

Steg 4: Testa rörelserna

Ta emot varor, sälj några, skada en, flytta några till skåpbilen, gör en inventering som hittar två saknade. Kontrollera att varje artikels historik berättar rätt historia och att antalet stämmer. Prova att få antalet under noll och bestäm om det ska blockeras eller flaggas.

Steg 5: Lägg till varningar och rapporter

En varning om lågt saldo via e-post eller en daglig sammanfattning till chefen är oftast det första folk efterfrågar när grunderna fungerar. Det kräver en e-postleverantör och ett schemalagt jobb. Efter det kommer en enkel rapport över lagervärde och en lista över artiklar som inte har rört sig på 90 dagar.

Steg 6: Rulla ut på en plats först

Använd den på ett ställe i ett par veckor, åtgärda det som är krångligt, och utöka sedan. Den största risken är inte en bugg; det är att personalen går tillbaka till kalkylbladet för att appen är långsammare.

Vanliga misstag

• Att bara lagra det aktuella antalet. Utan rörelser kan du inte svara på ”varför är det här fel?”
• Att låta vem som helst ändra vad som helst. Ett stavfel i en beställningsgräns eller en raderad artikel kan passera obemärkt i veckor.
• Att ignorera enheter. Att köpa i lådor om 12 och sälja styck kräver en tydlig regel, annars blir antalen fel med en faktor 12.
• För många fält på justeringsskärmen. Om det tar en minut att registrera en leverans gör folk det inte.
• Att bygga tvåvägssynk mot butiken först. Få appen betrodd på egen hand innan du kopplar den till något annat.
• Att behandla den som bokföring. Värdering av lager för skattesyften (FIFO, vägt genomsnitt) har regler; kontrollera med din redovisningskonsult innan du förlitar dig på appens siffror i din bokföring.

När en färdig produkt är det bättre valet

• Du säljer främst via en plattform som Shopify eller Square. Deras inbyggda lagerfunktioner kan räcka för det du behöver, redan kopplade till din försäljning.
• Du behöver lager tätt kopplat till bokföringen. Bokföringsprogram och lagerprodukter som är byggda för att integreras med dem sparar mycket avstämning.
• Du har en lageroperation med plockning, packning, fraktetiketter och flera försäljningskanaler. Dedicerade lager- och lagerhanteringssystem är byggda för det.

Bygg själv när ditt lager inte passar de produkterna, när du skulle betala för ett stort system för att använda en liten del av det, eller när processen runt lagret (godkännanden, arbetsorder, returer av uthyrning) är det du egentligen behöver hantera. Vår guide om att bygga eller köpa programvara för småföretag går igenom avvägningen.

Bygga den med Mythex

Mythex är en AI-appbyggare: du beskriver lagret, platserna och personerna, och den bygger appen i en levande förhandsvisning och lägger till en databas i projektet för artiklar, platser och rörelser. Du kan bifoga en skärmdump av kalkylbladet du använder idag så att den kan se dina kolumner, och be om en CSV-import. Artikelfoton använder projektets filutrymme. Om din butik eller ditt kassasystem har ett API kan du lagra dess nyckel i projekthemligheter och be Mythex läsa från det. Det finns ingen inbyggd inloggning för din personal, så konton och roller för appen använder ett autentiseringsbibliotek eller en leverantör du väljer. Dokumentationens sidor om att bygga ett internt verktyg och att bygga en CRUD-app är bra startpunkter.

För en första prompt du kan redigera, öppna mallen för lagerspårning, eller läs den bredare guiden så bygger du ett internt verktyg.

Frågor