@guca
Forumsvar skapade
-
Inlägg
-
PalMik – Anledningen till att köra PhP (istället för Microsoft-plattform) är att slippa göra lösningen själv
Det finns Joomla. Det finns 3795624 plugins till Joomla (ungefär). Betalväxlar har i regel färdiga integrationslösningar för Joomla (eller rättare sagt – för Joomla plugins). Om jag slänger upp en Sharepoint så har jag ehhh, en Sharepoint. Och sen får jag börja med punkt 1a – skriv ett ehandlessystem och använd betalväxelns API för att programmera betalkanalen. Nope. Vill inte det.Jag hänger inte riktigt med i din beskrivning av integrationen med bokföringssystemet. Målet är ju att hantera korttransaktioner online, inte att skicka fakturor. Så bokföringsprogrammet blir väl inblandat först då jag ska bokföra miljoninkomsterna?
Det finns ju hur många sidor som helst på Internet som använder en lösning liknande den jag vill ha – jag kunde aldrig ana att det skulle vara så komplicerat att åstadkomma…
PalMik . Jag kör SPCS Admin 500. Hmm. att integrera mitt bokföringsprogram i hanteringen har aldrig slagit mig. Liksom du är jag tveksam till lämpligheten att slänga in en hel eshop. Jag är utvecklare (webutvecklare dessutom) men för Microsoft-plattformen och är ganska vilsen i PhP, Joomla och all den tekniken. Jag tror det är oerhört mycket mer kostadseffektivt om jag fokuserar på att utveckla det jag är bra på istället för att försöka hacka ihop en ehandelslösning. Alldeles oavsett vilka komponenter den består av.
Men problemet är att jag ser två vägar. Antingen köper jag in mig i en eshop-lösning och får då en design som jag inte vill ha i en lösning som är fokuserad på att sälja mängder med olika varor. Eller också få jag fixa det själv. Och i fixa-det-själv-alternativet så står jag med en massa trådar i handen utan att ha klart för mig hur man knyter ihop dem. Ska jag dra i nån eshop-tråd och i så fall varför? Eller ska jag installera VirtueMart och försöka neutralisera allting utom kundregistret? Och btw – jag behöver en betalväxel också. Ska den integreras mot min site eller mot eshopen? Och jag behöver ett konto. Och alla på vägen ska ha betalt i procent vilket jag tycker är så fullkomligt ologiskt så det är inte sant. Jag har inget problem med att betala en bra tjänst vad den är värd – men att andra ska ha mer betalt för att *jag* gjort ett bättre jobb (och därmed kunna ta mer betalt) är motbjudande.
Kodmyran – Prixis, det var nåt sånt jag hade tänkt mig, tack
Det finns dock 2 stora svarta hål (eller vita fläckar eller nåt sånt) där din beskrivning passerar över min förståelse och det är precis på de punkterna som jag försöker få grepp på hur de ska hanteras:
Samtidigt så hamnar själva kunduppgifterna, dvs namn, adress e-post osv i ett kundregister i din butik.
”Min butik” är i det fallet någon ehandleslösning som jag köper in mig på? Kundregistret hanteras på en annan server och kommer inte över till min server? Kunduppgifterna kan inte (utan specialtrix) användas för inloggning till min site för att få support och ladda ner uppdateringar? (…det ligger inga värderingar i de frågorna, jag försöker bara förstå)
…och när du klickar där så kommer du till en shop som du då ser till att designa så att den passar med resten av din sajt.
ehh…rrright…
Det är ungefär det som jag brottas med att förstå hur det går till. När jag började fundera i de här banorna så var funderingen just: ”Först måste jag ha en shop. Sedan måste jag ha en betalväxel. Sedan måste jag ha ett konto (där banken fascinerande nog ska ha betalt för att jag sätter in pengarna!) Eftersom jag egentligen inte har behov av en shop i traditionell betydelse så kan jag inte hoppa i en sådan tunna rakt av. Om jag *ändå* måste göra en massa anpassningar för att få shopen att se ut som min sida och dessutom försöka se till att betalväxelns sida anpassas – varför ska jag lägga ner jobb på shopen över huvud taget? Är det bättre att installera VirtueMart på min site, ta hand om kundregistret själv och istället lägga krutet på att integrera direkt mot betalväxeln istället” ??? Finns det någon shop som säger ”ange vilket konto du vill ha in pengarna på så fixar vi resten”? Det skulle tilltala mig…Jag märker att jag har väldigt svårt att beskriva mina ”behov” – troligen därför att jag inte har dem helt klara för mig. Tack för att ni hjälper mig att tänka efter.
Jag märker att jag ogillar de förslag som går ut på enkla, snabba lösningar med Paypal och liknande. Jag tor att vad jag är ute efter är en lösning som är enkel och snabb för mig att använda men som ger ett kompetent och professionelt intryck för kunderna. Det kommer säkert att kosta, jag vet det, men om jag hittar en bra lösning som på ett snyggt sätt kan integrera sig i den presentationswebsite som jag har så är jag beredd att betala för det.
Miin målgrupp är IT-chefer på internationella/multinationella företag med fler än 1.000 anställda – troligen mycket fler än 1.000 anställda. Paypal och kundregister i Excel passar inte riktigt in i den bilden tror jag. Min målgrupp förväntar sig att ha en fortlöpande kontakt – få information, uppdateringar, supportforum etc. Jag vill ha en professionell site som ger professionella kunder professionellt stöd både vid köp och efter köp. Men jag vill inte ha en e-butik som är byggd för att presentera mängder med varor. Så småningom kan jag tänka mig att det blir aktuellt att sälja uppgraderingar och/eller support och då kommer jag ju att få fler produkter än den enda produkt jag har nu. Så en varukorg kommer nog inte att sitta i vägen. Och att kunna hantera flera produkter sitter nog inte heller i vägen. (jag vet, jag säger emot mig själv hela tiden
Jag är grinig vad det gäller design. Jag köper inte ”vad som helst” och låter min site anpassas efter hur e-butiken råkar se ut. Jag vet hur min presentation av min produkt ska se ut – ehandelslösningen får anpassa sig efter det.
Det låter på något sätt som att CertiTrade skulle kunna vara ett alternativ för transaktionshanteringen, men jag förstår fortfarande inte tillräckligt mycket för att ha klart för mig hur den integrerar i min site, var ett kundregister ligger etc. Shit,va svårt de här va…
Olika domännamn – nej. Olika språk – nej. I alla fall så kommer jag inte ha min site tillgänglig på olika språk. Ifall ehandelssidan ska vara på olika språk har jag inte funderat på. Men min produkt pratar engelska, så förstår man inte att köpa den på en engelsk site så ska man nog inte köpa den
Jag tror att mitt huvudproblem just nu är att jag inte förstår vem som gör vad. De flesta produkter verkar inriktade på presentation av produktkataloger och varukorgar, typ postorderföretag, Dustin och liknande. Eftersom jag endast ska sälja en (1) produkt så har jag ju inget behov av allt det där.
Men om jag inte skaffar en produkt med varukorg och hela köret – var finns mitt kundregister? Vem hanterar momsen för olika länder? Vad hanteras på betalväxelns websida och vad måste jag hantera på min sida? Jag skulle t.ex. kunna använda SoftwareKey.com för själva varukorgen – den varukorg som jag egentligen inte känner att jag behöver. Då ska de ha en massa pengar för att göra nåt som jag inte vill ha. Men om jag *inte* använder SoftwareKey.com så har jag inte deras integration med betalväxlar, så då måste jag göra det själv. Tror jag. Typ. eller använda någon annan som har ett system för produktkataloger och varukorger. Som jag inte vill ha. Och vad innebär det i så fall. Ja ni hör. Out bicycling on the hal ice. liksom.
Det finns Joomla. Det finns 3795624 plugins till Joomla (ungefär). Betalväxlar har i regel färdiga integrationslösningar för Joomla (eller rättare sagt – för Joomla plugins). Om jag slänger upp en Sharepoint så har jag ehhh, en Sharepoint. Och sen får jag börja med punkt 1a – skriv ett ehandlessystem och använd betalväxelns API för att programmera betalkanalen. Nope. Vill inte det.
