Czy możesz bardziej sprecyzować "nieduży sklep" ?Wysłane przez frico
(A żeby się nexus246 nie czepiał, to dodam - nieduży sklep)
Miałeś na myśli ilość produktów? Coś innego?
Jeżeli ilość produktów to ile?
Zamierzam wypróbować VM+ Joomla i nie wiem czy warto czas marnować
Przy ponad 400 produktach chodziło całkiem nieźle.
Jednak przy kilku tysiącach administracja, a przede wszystkim nawigacja po sklepie, byłaby moim zadaniem małym koszmarem.
Pozdrawiam
frico
Robie to co lubie, bo lubie to co robie.
I niech tak zostanie.
co masz na myśli mowiąc, że przy przy kilku tysiącach produktu administracja, a przede wszystkim nawigacja po sklepie, byłaby małym koszmarem. ???
Ja mam w tej chwili ok. 2000 produktów i nie narzekam.
Mówicie tutaj o profesjonalnych sklepach, a nie widzę żadnych przykładów, większość ofert które widziałem to przerobione OsCommerce z ładnymi templatkami, ewentualnie Sote, a inne ? chętnie zobaczę jak ma wyglądać profesjonalny sklep. Większość potrzebnych narzędzi już znajduje się w VM, a resztę można dołożyć tylko co ?
http://www.mbpartner.com.pl
Miałem na myśli zagnieżdżenie kategorii w produktach, jesli chodzi o sklep. Przy kilku poziomach robi się to mało czytelne. I odwiedzający się gubi. U Ciebie tego nie widać... teraz. Bo zrobiłeś dość klarowyny podział, ale nie zawsze tak się da. Jednak pamiętam wcześniejszy wygląd Twojego sklepu i gdyby wtedy było tam tyle artykułów w kilku kategoriach (jak pamiętam), to sam przyznasz, że wygląd nie byłby przejrzysty.
Teraz jest oczywiście "piknie" ;)
Co do administracji, brak jest narzedzi (wbudowanych) do dokonywania szybkich zmian wielu produktach. Sama organizacja realizacji zamówień, też czasami jest niewystaczająca.
Jak wiadomo specyfiką prowadzenia sklepu internetowego jest to, że praktycznie zamawia się towar który klient w sklepie już zakupił. Weźmy więc dla przykładu Twoją branżę. Załóżmy że masz w sklepie towar z AB, Pronox i Action. Ceny na niektóre grupy towarów zmieniają się praktycznie codziennie. Jeśli w dół, to nic. jednak jesli w górę, to jest kłopot. Jak więc sobie wyobrazić bez dodatkowych narzędzi kontrolowanie aktualności cen ? Jak dokonać szybkiej ich aktualizacji ? Jak szybko wybrać najtańszego dostawcę. Jak o godzinie 15 przygotować zamówienie na 70 pozycji i do 16 przesłać do dostawcy, aby jutro je dostarczono ?
Wielkość sklepu należy także oceniać po ilości obsługiwanych zamówień. Jeśli jest ich klilka dziennie, nie ma problemu. Można zrobić to "na piechote". Jednak przy kilkudziesięciu, zajmie to już mnóstwo czasu, a przeciez nie o to chodzi.
I takich właśnie narzedzi do automatyzacji moim zdaniem w VM brakuje. Zdarzyło mi się przygotować i obsługiwać sklep w Twojej branży z podobnym właśnie modelem. Kilku dostawców i do tego własny magazyn z ponad tysiącem produktów na stanie. Nie dość, że trzeba było obsłuzyć aktualizację stanów i cen od dostawców oraz aktualizację zmian cen i stanów towaru na magazynie, to jeszcze przy każdym zamówieniu wybrać najtańszy towar do zamówienia. I nie mogło to działać bez kilkunastu dodatkowych skryptów. Czyli sam VM nie wystarczyłby (choć oczywiście nikt od niego nie wymaga aż takicjh mozliwości).
W pierwszym miesiącu działania przez sklep przesło ponad 4 tys zamówień zrealizowanych. Gdyby nie automatyczne uaktualnianie cen (np. codzienie się zmieniających cen RAM), to nie wyobrażam sobie pisania do kilkuset klientów "przepraszamy towar podrożał i ....".
Ogólnie to miałem na myśli. I tutaj nexus246 ma rację. Koszty biznesowe prowadzenia "dużego" sklepu na VM moim zdaniem są zbyt wysokie.
I odbiegliśmy trochę od głównego wątku
Pozdrawiam
frico
Robie to co lubie, bo lubie to co robie.
I niech tak zostanie.
Właśnie na takich uwagach mi zależy, tak jak wspomniałeś nie mam dużo obsługiwanych zamówień ( mam nadzieję, że chwilowo ) i na razie mi to wystarcza, ale chciałbym się przygotować, dlatego zależy mi na doświadczeniu użytkowników dużych sklepów ( profesjonalnych ). Masz rację, że w tej branży aktualizacja cen to duuży problem, dlatego była to moja pierwsza poprawka VM - automatyczna aktualizacja cen z plików csv dostarczanych przez hurtownie. Wszystko da się zrobić, "potrzeba matką wynalazków". W moim przypadku przeróbki robie sam, a w profesjonalnym sklepie za wszystko musiałbym prawdopodobnie dodatkowo płacić.
A jak rozwiązałeś problem aktualizacji cen? Jak na razie sklep stawiałem tylko na oscommerce, tutaj ten problem rozwiązywałem poprzez import z excela, co jednak sprwdzało się tylko w przypadku rónoczesnej zmiany ceny o dany procent . To mnie w sumie wystarczało (sklep jubilerski) bo to kwestia kursu złota. A czy VM ma cechy produktów? Sorki za męczenie, tylko zanim przewale kilkaset produktów chciałbym się upewnić czy to ma sens.
A plik exela tworzyłeś ręcznie? Czy jakiś eksport z programu magazynowego?
Ja VM dopiero rozgryzam, jeżeli spełni moje oczekiwania to spróbuję się na "przesiąść" na joomla+VM. Z tego co zauważyłem akceptuje pliki w formacie *.csv, podobie jak osCommerce. Z tym, że import jest bardziej konfigurowalny (jeżeli mogę tak to ująć).
Nie wyobrażam sobie pisania ręcznie pliku *.csv w exelu na powyżej 100 towarów.
Z osCommerce poradziłem sobie tak:
Używam SubiektGT jako program magazynowy. Napisałem program (aplikacja pod windows), który eksportuje mi dane z bazy Subiekta (baza MsSQL) do pliku *.csv, potem import z poziomu osC i już. Aktualizacja cen i stanów magazynowych + wrzucenie ewentualnie nowych produktów za jednym podejściem, przy ilości ok 2000 kartotek zajmuje mi jakieś 5 - 10 minut (zależy jaki zakres akurat aktualizuję).
Jeżeli nie wrzucam nowych towarów, to ceny i stany aktualizuję bezpośrednio w bazie osC.
Spodziewam się, że z VM będzie podobnie. Na razie mam jeszcze małe problemy z polskimi literkami w VM (co dziwne w Joola jest ok), ale jak się z tym uporam to będę go probował zatowarować.
Witam wszystkich
Mam kilka sklepow na koncie i musze przyznac, ze VM spelnia sie niezle.
Na temat OC wole sie nie wypowiadac bo odrazu cisnienie mi skacze ;)
Faktem jest, ze wszyskie pracuja pod mambo nie joomla ale to ta sama rodzina
z oscommerce exportowałem do pliku exela i tam w jednej rubryce była cena którą zmieniałem procetowo w excelu no i potem import do bazy danych. Pojawiał się problem z polskimi znakami, ale "ctr H" i po chwili było ok. Co do bezpośredniego importu cen i towarów z programu magazynowego - to moja zmora. Co prawda wiele programów (moja żona ksieguje w kilku, stad mam porownanie) ma export stanu magazynu do excela, jesnak i tak trzeba to poprawiać. Moim marzeniem
w VM można importować i exportować cennik poprzez csv (gdy masz przygotowany taki w Excelu) ja rozwiązałem to w ten sposób, że dostaję cenniki w formacie csv i w odpowiednio zmodyfikowanym skrypcie aktualizuję bazę w zależności czy produkt jeszcze jest dostępny czy nie, oraz wpisuję najniższe ceny danego artykułu z danej hurtowni, oczywiście za jednym zamachem zamieniam ceny netto wg. swojego przelicznika (narzut marży w zależności od wartości ) oraz tak aby po naliczeniu podatku była to okrągła cena nie jakieś ( 33,2444).
Nie wiem dokładnie o co dokladnie ci chodzi mówiąc cechy "produktów". VM standardowo może wyswietlać w karcie produktów takie dodatkowe pola jak : "product_weight", "product_weight_uom", "product_length", "product_width", "product_height", "product_lwh_uom", "attribute", ( Kolor, rozmiar itd ), "custom_attribute", "attributes", "attribute_values",
a za pomocą ,CSV, 2 plików modyfikujących bazę danych, araz drobnej modyfikacji 2 plików php, może wyświetlać właściwie dowąlną ilość "cech produktu" (jeżeli dobrze zrozumiałem co masz na mysli). Właśnie pomagam przerobic kartę produktów tak aby wyświetlało się 14 dodatkowych pól z atrybutami produktu w zależności od tego czy coś jest wpisane w odpowiednim polu CSV czy nie.
Reguły pisania
Cytuj