Witam,
Stoję właśnie przed przeniesieniem działalności wirtualnej do świata rzeczywistego. Mam sklep internetowy, który będzie poszerzony o sklep realny. Pojawił się jednak problem.
Chciałbym aby sklepy miały wspólną bazę danych produktów, stanów magazynowych - gdy klient kupuje w internecie, to automatycznie zmniejszają się stany magazynowe itd.

Jako, że po raz pierwszy będę robił coś takiego chciałbym się spytać a właściwie prosić o wszelkie uwgai jakie uznacie za konieczne. Ja to widzę tak:
- baza produktów, stanów magazynowych itd będzie dalej w Internecie
- dla sklepu stworzę drugą aplikację, która będzie odpowiedzialna za obsługę klienta realnego. W sklepie realnym będzie istniał lokalny serwer, który będzie zawierał listę produktów, ceny itd (okrojona wersja bazy z internetu) - będzie on współpracował z czytnikiem kodów kreskowych (javascript) oraz w przyszłości z kasą fiskalną. Lokalny serever pozwoli na szybszą pracę (nie będzie trzeba tylu zapytan do bazy internetowej wykonywac itd) - po zakonczeniu transakcji (np. po zaplacie) serwer lokalny wywola skrypt aktualizujacy stany w internecie zgodnie z poczynionymi zakupami.

Od razu dodam, że wszystko musi chodzi na php, gdyż jedynie w tym języku jestem obecnie w stanie to napisać bez dodatkowej nauki a czas goni. Wiem, że lepiej byłoby zrobić ten front-end np. w C#, ale w chwili obecnej jest to niemożliwe.

Co myślicie o takim modelu - jakie słabe strony dostrzegacie?
- Mój pierwszy typ to mimo wszystko duże uzależnienie od Internetowej bazy danych - trzeba zadbać o to aby system w razie potrzeby mógł pracować samodzielnie i gromadzic tranzakcje lokalnie przez dluzszy czas - wiadomo jak to jest z ISP - raz dziala raz nie

Na jakim skrypcie oparty jest obecny sklep?

Ja zakupy w "realnym" sklepie realizowałbym poprzez kupowanie we własnym sklepie - wszystko zależy od tego, czy sklep internetowy wystawia faktury, itp., bo to też istotna rzecz - numeracja faktur musi być spójna.

EDIT:


Zmieniasz ISP na nazwa lub home i problem odpada. Napisałem kilka internetowych systemów magazynowo/księgowych i nie był to nigdy problem.

Mialem dosc nietypowe potrzeby wiec napisalem wlasny system.

Jesli chodzi o kupowanie we wlasnym sklepie to jak najbardziej tak chcę to właśnie zrobić. Ale
a) Wyklikanie wszystkiego (mam okolo 1000 produktow a bedzie docelowo 3000) zajmuje zbyt wiele czasu
pady nawet nazwie sie zdarzaja (mam u nich ten sklep), moze przstac dzialac Internet w sklepie realnym, może się zmienić konfiguracja serwera i sklep może przestać działać (miałem taką sytuację ostatnio, że nagle musiałem zmienić 1 linijkę kodu, ale nie było mnie przy kompie i sklep lezal 3h)

Dlatego chcialbym zrobic tak, zeby mimo wszystko sklep dzialal lokalnie i aktualizowal stany po transakcji. Wydaje mi się to bezpieczniejsze i szybsze.

edit
elnino.pl - a pisales moze kod obslugujacy kase fiskalna - bo nie mam pojecia jak to ugryzc. Taka kasa ma jakies API ? Instaluje się jakieś stery?

A co gdy w sklepie internetowym bedzie jeden produkt, przyjdzie real-klient i bedzie go kupowal (10 minut) i w miedzyczasie ktos kupi ten produkt przez net?


1. Transakcje -- no tak, ale trzeba ja rozpoczac gdy przyjdzie klient i prosi o produkt, trzeba by go zarezerwowac i kontynowac sprzedaz.
A jesli wszystko wysylasz po zakonczeniu sprzedazy to mozesz uzyskac anomalie jak opisalem wyzej.
2. Duzo zapytan?? Ile klientow na sekunde jestes w stanie obsluzyc w realu: 0.01? A przez net, powiedzmy 10 klientow /s (to jest raczej malo) -- widzisz roznice, nie ma sie czym przejmowac.

Nigdy nie pisalem takiego sklepu wiec rozwiazan ci nie podam.

@dr_bonzo - też o tym problemie myślałem... Jedyne logiczne rozwiązanie jakie mi przyszło do głowy, to ujemne stany magazynowe (niektóre systemy ERP -np Impuls dopuszczają taką sytuację). Myślę, że sytuacja taka zdarza się rzadko - ale ma prawo się zdarzyć. Ten sam problem jest zresztą z koszykime w necie - pytanie czy blokować produkt gdy klient wkłada go do koszyka czy dopiero gdy go kupuje - większość klientów nie kończy transakcji i może blokować produkt przez dłuższy czas.
Klient Internetowy będzie niestety musiał poczekać.

Co do ilości zapytań to faktycznie masz rację - jak teraz czytam swojego posta to głupotę w nim napisałem
Problem jaki widze to jednak szybkość działania Internetu (lub awaria) - głupio aby klienta czekał przy kasie aż uda się pobrać dane produktu z sieci. Tu częściowo można użyć ajax - ja wrzucam kody czytnikiem a w międzyczasie reszta się pobiera - ale w razie awarii (np. Neostrada ma zwiechę) mam problem.

Moje rozwiązanie z drugiej strony wymaga dbania o spójność cen itp w obu bazach i to będzie trzeba jakoś inteligentnie rozwiązać.

Ja bym skorzystał z istniejącego oprogramowania do obsługi sklepu prawdziwego, natomiast stany towarów w internecie aktualizować co jakiś czas (np. 2h) automatycznie, ale używając określeń stanów nie przez ilości numeryczne, ale np. "dużo(>20), mało(10-20), na wyczerpaniu (<10), brak(0)". Inaczje musiałbyś BARDZO dbać i kontrolować stan zapasów,bo przecież może sie zdarzyć taka sytuacja, że klient w internecie wlozy do koszyka 10 sztuk towaru, system ściagnie je ze stanu magazynu, a w tym samym czasie klient zostanie odesłany z kwitkiem, bo tych 10 (akurat ostatnich) sztuk nie ma - a za jakis czas automatem skasujesz nieaktywną sesję z tymi 10 pozycjami ze sklepu internetowego.... Taka sama sytuacja może sie zdarzyć nawet w sklepie wirtualnym, gdy dwóch klientów wybierze sobie ten sam towar. W przypadku niewielkiej ilości pozycji nie jest to problem, zawsze przecież możesz iść i policzyć ile faktyznie jest towaru, ale gdy masz ich sporo to takie coś byłoby conajmniej kłopotliwe, żeby nie powiedzieć męczące - w koncu nikt by ci nie zwrocil uwagi ze coś nie gra - dopier po jakimś czasie samo by to wyszło...
Dlatego ja proponuje takie rozwiazania:
1. towar zdejmujesz ze stanu w momencie faktycznej sprzedaży (sklep prawdziwy) lub w momencie potwierdzenia zamówienia (sklep internetowy)
2. ogólne określenie ilości zamiast dokłądnych.

Kolejna sprawa to bezpieczeństwo...
Nie odważyłbym sie połączyć sklepu internetowego ze sklepem istniejacym fizycznie w jeden "organizm" ze względu na to, że nikt nie pisze bezbłędnych aplikacji i zawsze, predzej czy pozniej, znajdzie sie ktoś kto odkryje dziurę w systemie.

A co wybrać... zależy od tego gdzie masz większy ruch - jeżeli sporo większy w internecie to bym sie zastanowił nad dostosowaniem, ale jeżeli internet ma być jakby rozszerzeniem sklepu realnego, to bym nie cudował, tylko aktualizował raz na czas.

Też się zastanawiam czy nie jest to "kombinowanie pod górkę". Spenzol masz dużo racji w tym co mówisz.

Chyba też trochę źle naświetliłem sytuację: szukam rozwiązania zadowalającego - wiem, że nie uniknę takiej sytuacji, że jakieś zakupy się nałożą - ale też nie jest to moim celem.
Raczej chodzi o to, że towar pochodzi z wielu lokalizacji i na niektóre rzeczy czasami trzeba czekać około 10dni. Ja chcę aby w danej chwili była informacja czy towar jest (a jeśli go nie ma to niech się wyświetli info o wydłużonym czasie oczekiwania). Dążę mniej więcej do takiego modelu jak ma Komputronik -> widzisz ile w poszczególnych sklepach jest towaru. Oczywiście jak najbardziej będzie to informacja rangowana np. na wyczerpaniu, trochę, dużo -> po co konkurencja ma wiedzieć ile mam towaru

W samej bazie danych stany jednak muszą być przechowywane dokładnie. Dlatego, że mój model biznesowy zakłada niskie stany magazynowe i częste zamówienia. Muszę dokładnie wiedzieć co mam, żeby automagicznie kontrolować co zamówić.W sumie to dobry pomysł aby np. dokładne stany przechowywać lokalnie a w sieci tylko rangowo... muszę o tym pomyśleć

Każdy towar ma przecież swojego dostawce. Każdy dostawca potrzebuje X czasu od otrzymania zamówienia do dostarczenia do ciebie. Wiec wystarczy rozbudować baze dostawców o średni czas dostawy i brać go pod uwage przy sprawdzaniu stanu magazynu w stosunku do czasu dotarcia następnej dostawy i ew. wyświetlanie tego na stronie, czy sygnalizowaniu gdzieś w panelu admina o kłopotach mogących wystąpić z powodu zmniejszającego sie stanu. Również wprowadzajac zamowienie do dostawcy możesz gdzies to zapisywać, i korzystając z średniego czasu dostawy wyświetlać info, że przewidywany czas dostępności produktu to na przykład 3 dni.


Ale... Od jakiegoś czasu pracuje w sporej hurtowni właśnie w handlu i im bardziej sie zagłębiam, tym bardziej twierdze, że napisanie systemu do obsługi sprzedaży TYLKO wydaje sie proste. Dlatego radze ci skorzystać raczej z gotowych systemów niż kombinować ze swoim.

Niestety - w biznesie dopiero zaczynam i nie stać mnie na gotowe rozwiązania tej klasy jakiej będę chciał mieć. Myślę perspektywicznie o małej sieci - a skoro pracujesz w handlu to wiesz ile kosztuje system, który obsługuje kilka sklepów + sklep internetowy. Takie systemy mają zresztą ogrom opcji, których i tak bym nie wykorzystywał.

Zdaję sobie sprawę, że nie uda mi się napisać takiego systemu jak komercyjny. Myślę jednak , że jeśli dobrze podejdę do problemu już na etapie projektu to uda mi się zrobić coś co będzie spełniało moje potrzeby (w sumie nie aż tak wygórowane), a jednocześnie będzie w jakiś sposób skalowalne.
Zresztą powiem szczerze, że znam jeden system z "górnej półki" i z mojego doświadczenia wynika, że w przypadku handlu detalicznego byłby to przerost formy nad treścią - takie systemy sprawdzają się bardziej w przypadku hurtowni i firm produkcyjnych gdzie zachodzi potrzeba koordynacji wielu sfer.

W moim przypadku jest to tylko sklep internetowy + sklep realny (w przyszłości kilka sklepów). Aplikacja ma mi tylko pomóc w zarządzaniu i dać kilka narzędzi. Mam nadzieję, że nie okarze się tak jak mówisz, że mi się tylko wydawało

Jeżeli chcesz prowadzić sprzedaż tylko detaliczną to wystarczy ci kasa fiskalna (chyba, specjalistą nie jestem ;P) natomiast wtedy jak najbardziej ma sens jakiś własny skrypt dla utrzymywania porządku w magazynie. Ale jak chcesz wystawiać faktury to sprawa sie już troche komplikuje, gdyż wymaga to (bardzo) spójności i porządku we wszystkim co bedzie z tym związane.

Fakturami się bardzo nie przejmuję bo z doświadczenia to jest kilka w miesiącu. Fiskalizacja na drukarce fiskalnej wystarczy - faktury można spokojnie "wystawiać" ręcznie.

Kiedyś pisałem (tak dla sportu w zasadzie) coś ale system do wystawiania faktur. Wystawianie jest w teorii proste - gorzej jak są korekty, usuwanie faktur itp... wtedy to już jest sajgon z utrzymaniem spójnej numeracji i jakiegoś porządku... System zakończył żywot na fazie wstępnej :-)