[TimJ]

Hej Oskar!

Jag tror vi fick vårt första avtal när vi skickade ca 3000 kollin / år. Alltså i runda slängar 8 paket/dagen.

Ett tips är att använda fraktjakt.se eller någon typ av avtal (ehandel edge etc) och andra speditörer tills du når volymer så du kan förhandla. Och kan du så använd varubrev som är betydligt billigare.

Ha en fin dag!

Hälsningar,
Tim

[TimJ]

Vi har gjort prisjusteringar uppåt flera gånger (10-25%) eftersom vi inte kunnat hantera tillväxten och ändå sett försäljningen öka i nästan oförändrad takt.

A/B testa priser ser jag som lite tekniskt svårt. Vad händer om en kund går in via mobilen, hamnar i ”billiga gruppen” A och sedan använder datorn och hamnar i grupp B och funderar varför det är dyrare? Det är där skon klämmer för oss i alla fall. Eller någon postar på FB om ett pris och andra ser ett annat? Många skulle känna sig lurade om de hamnade i den dyrare gruppen.

[TimJ]

@ake125 78273 wrote:

Är det någon som har länkar till bra bank api dokumentation?

Handelsbanken för min del.

Det finns inte någon officiell dokumentation. Det man kan göra är att reverse-engineera deras mobilapplikation genom att sniffa-trafiken. Sen bygga ett eget runt det. ex har någon påbörjat detta här: SHB API. Tänk då på att APIt kan ändras vilken sekund som helst och sluta att fungera.

En enklare lösning kan vara att hämta data från deras mobilsida. Det finns en open-source app som heter Bankdroid som gör just detta. Här är exempelvis koden för Handelsbanken: https://github.com/liato/android-bankdroid/blob/master/app/src/main/java/com/liato/bankdroid/banking/banks/Handelsbanken.java. Skriven i Java.

@Rosahuset 78230 wrote:

Jobbar du Tim åt partykungen eller kan man hyra in dig för att fixa en sådan lösning?

Jag jobbar åt Partykungen på deltid. Men frilansar även när tid, lust och insipration infinner sig. Dock så sitter ni som jag förstår på en hyrlösning?

Dessutom är detta med Swish någon som antagligen kommer kräva en hel del underhåll eftersom det i dagsläget inte finns några officiella APIer. Rent teoretiskt kan det sluta fungera vilken sekund som helst. Det skulle nog finnas risk att det springer iväg bra många timmar och kostar mer i konsultarvode än det smakar.

Har man inte in-house utvecklare skulle jag råda folk att avstå från detta tills dess att Swish själva löst det med ett API.

[TimJ]

Det var jag björn! Hela fyra stycken Retro Godispåsar – Partykungen.se för avhämtning.

För övrigt tror jag Swish kommer gå riktigt bra på hämtordrar!

[TimJ]

Ett alternativ är att ha två olika typer av reservationer. Varukorgsreservationer och orderreservationer. Lite förenklat och tekniskt följer. Förutsätter att man har en unik identifierare av kundvagnar och att flödet är varukorg -> order -> betalning -> utleverans.

0. Två olika tabeller:

stock
upc, qty
123123, 2

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id

---

1. Vi lägger något i varukorgen
Reservationen läggs till.

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id
123123, 1, 1383080023, ’cart’, 9999, NULL

---

2. Varukorgen blir en order
Reservationen uppgraderas.

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id
123123, 1, NULL, ’preorder’, 9999, 1

ELLER

2. Varukorgen utgår
Tas bort via exempelvis cronjob och villkoret för expiry bör vara med i stock-queries.

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id

---

3. Ordern utlevereras
Stock-tabellen uppdateras. Reservationer kopplade till ordern tas bort.

stock
upc, qty
123123, 1

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id

ELLER

3. Ordern makuleras innan utleverans.
Tar bort relevanta reservationer.

stock
upc, qty
123123, 2

reservations
upc, rsv_qty, expire, rerservation_kind, cart_id, order_id

---

Ovan i text.
När man lägger något i varukorgen så skjuter man helt enkelt in en reservation i reservation-tabellen. När varukorgen sedan blir en order (även innan betalning) så ”uppgraderas” reservationen till en order-reservation. Vid eventuell makulering av ordern på grund av exempelvis utebliven betalning tar man helt enkelt bort de order-reservationerna som hör till den ordern (slipper göra en inleverans). Cart reservationerna tas bort med jämna intervall när expiry-time är uppnådd.

Vid utleverans av ordern uppdateras stock-tabellen och reservationerna tillhörande ordern tas bort. Nackdelen är att man lär summera mellan två tabeller och de blir ofta en separat query bara för att få ut ett saldo, vilket iof ofta inte är ett problem då man ofta inte vill joina en transaktions-heavy tabell med en mer statisk pga cache-lösningar osv.

På det här sättet skiljer man även ut vad som faktiskt finns på det fysiska lagret, vad som är på väg att utleveras och vad som ligger ”på gång”. Smidigt om man inte har separat affärsystem med lagerhantering (ex VB).

Nackdelen är att har man ett väldigt litet lager och inte support för backorders så kan hela den reserverbara stocken tas upp av kunder som bara nöjeslägger saker i varukorgen.

[Författare]

Inlägg