Sklep internetowy dla muzeum - bilety

Dzień dobry
Jesteśmy niewielkim muzeum i obecnie korzystamy z usług zewnętrznej firmy, która robiła dla nas sklep. Problem mamy taki, że to jest ich sklep, a oni nam go tylko udostępniają no i za to biorą prowizję. Właśnie o tę prowizję się rozchodzi, wolelibyśmy ją zostawić sobie;) No nie tylko, bo każde wprowadzenie nowego lub wycofanie istniejącego biletu wymaga kontaktu z tą firmą.
Dlatego rozglądamy się za gotowym rozwiązaniem, które będzie tylko nasze. Postawimy go na swoich serwerach i będziemy sami obsługiwać.
Co proponujecie dla sklepu z biletami?
Nasze wymagania:

• Bilety są sprzedawana na różne trasy po muzeum o różnych godzinach w różnych dniach z różną ceną i inną pulą dostępnych wejściówek normalnych i ulgowych.
  np:

trasa1:
    2024-09-11
        9:00 - $20, 20 biletów normalnych; $15, 10 biletów ulgowych
        10:00 - $20, 15 biletów normalnych; $15, 15 biletów ulgowych
        15:00 - $15, 20 biletów normalnych; $10, 15 biletów ulgowych
    2024-09-12
        10:00 - $18, 15 biletów normalnych; $15, 10 biletów ulgowych
        14:00 - $20, 20 biletów normalnych; $17, 20 biletów ulgowych
        15:00 - $18, 15 biletów normalnych; $15, 50 biletów ulgowych
    2024-09-13
        15:00 - $20, 30 biletów normalnych; $17, 30 biletów ulgowych
        16:00 - $20, 20 biletów normalnych; $15, 20 biletów ulgowych
        16:30 - $20, 30 biletów normalnych; $15, 15 biletów ulgowych
        17:00 - $20, 20 biletów normalnych; $18, 10 biletów ulgowych
trasa2:
    2024-09-13
        8:00 - $5, 100 biletów normalnych; $4, 100 biletów ulgowych
        9:00 - $5, 110 biletów normalnych; $3, 90 biletów ulgowych
    2024-09-14
        9:00 - $7, 90 biletów normalnych; $5, 90 biletów ulgowych
        10:00 - $6, 90 biletów normalnych; $5, 80 biletów ulgowych
        11:00 - $7, 90 biletów normalnych; $6, 70 biletów ulgowych
        12:00 - $7, 90 biletów normalnych; $6, 60 biletów ulgowych
    2024-09-15.
        8:30 - $6, 100 biletów normalnych; $5, 100 biletów ulgowych
        12:00 - $6, 120 biletów normalnych; $5, 100 biletów ulgowych
        17:30 - $5, 80 biletów normalnych; $4, 50 biletów ulgowych

• Szybkie płatności, to chyba standard.
• Bilet jest zbiorczy. Np klient kupił 3 wejściówki normalne i jedną ulgową na 2024-09-12, to dostanie jeden papierek z kodem qr (o kodzie qr piszę niżej). Ale nie zbiorczy dla całego zamówienia. Np klient do koszyka włożył i kupił 3 wejściówki normalne i jedną ulgową na 2024-09-12 10:00 oraz jedną wejściówkę normalną na 2024-09-12 14:00. Wtedy dostanie dwa papierki, jeden na 3 wejściówki normalne i jedną ulgową na 2024-09-12 10:00 i drugi na jedną wejściówkę normalną na 2024-09-12 14:00.
• Po zakupie klient musi dostać bilet z kodem qr. Ten kod będzie skanowany na wejściu do muzeum, więc w sklepie musi być jakieś api. W kodzie będzie zakodowany jakiś identyfikator biletu i po api ten identyfikator będzie przesłany i odebrana odpowiedź z informacjami o dacie i godzinie wejścia, ilości biletów normalnych i ilości ulgowych (i może coś jeszcze). Żeby bramkarz podjął decyzję czy wpuścić klienta czy go nie wpuścić. Np klient przyszedł o innej godzinie niż zakupił bilet, albo przyszło więcej ludzi niż kupiono biletów. Przez api bilet ma być oznaczany jako wykorzystany (oczywiście, jeśli wszystko się zgadza i klient wszedł do muzeum), żeby ponownie nie można go było użyć.
• Zwroty i zmiana daty i godziny też są wymagane.
• Jeszcze jednio api, dla innych sklepów. Współpracujemy z innymi jednostkami i sprzedają bilety łączone na kilka muzeów. Dlatego trzeba im umożliwić generowanie naszego biletu przez ich sklep. Takie bilety muszą być w panelu jakoś oznaczone, że zakupił je klient u takiego czy innego naszego partnera.
• My też chcemy mieć możliwość sprzedaży ich biletów u siebie, dlatego potrzebujemy móc po ich api generować ich bilety u siebie.

To na razie chyba tyle. W razie pytań postaram się odpowiedzieć.

Pytasz się o silnik gotowego sklepu?
Myślę, że poza jakimiś opcjami typu bilety łączone z kliku miejsc będziesz miał od strzału wszystkie opcje w każdym silniku sklepu.

Nie znam gotowca, który da Ci 100% tego co potrzbujesz, ale są na pewno gotowce, które dają znaczną część tych funkcjnalności.
Popatrz na https://hi.events tam pewnie trzeba byłoby podpiąć kolejnego gotowca jakim są integracje z płątnoścami elektornicznymi.
Do tego należałoby również dograć gotowca, który wystawi API - albo samemu napisać proste API.

To wszystko trzeba przeliczyć ile Ciebie teraz kosztuje prowizja, a ile będzie kosztowało spięcie systemu dla CIebie z gotowców + utrzymwanie

to nie jest trudne jak ktos siedzi w tych technologiach

pizzerie czy kina maja taki system platnosci na stronie www

oczywiscie pytanie ile to bedzie kosztowac

na takim systemie platnosci mozna zarobic w obecnych czasach dlatego pewnie engine sam nie dojdziesz

Właśnie o tę prowizję się rozchodzi, wolelibyśmy ją zostawić sobie;)
Postawimy go na swoich serwerach i będziemy sami obsługiwać.
Nasze wymagania:

Brakuje mi tutaj chyba najważniejszego - jaki budżet? Ile tej prowizji dałoby się zostawić dla siebie "na swoim"? Rząd wielkości miesięcznie podaj.

Piszesz że małe muzeum. Ale chcesz integracje ze skanowaniem kodów (pewnie z tel/apki), jakaś logika łączenia zakupów, powiązania z innymi systemami. Ktoś to musi zakodzić, samo się nie zrobi. Może się okazać, że wdrożenie takiego systemu to kilkadziesiąt tysięcy samej robocizny (po taniości) i pytanie czy to ma rację bytu.

Ktoś pisze, że większość opcji dostanę od strzału w większości gotowców. Ktoś inny pisze (tak zrozumiałem), że trzeba to zakodować dedykowanie.
Budżet budżetem. Chcemy gotowca, który już jest. Silnik sklepu + gotowe wtyczki. Wykupujemy serwer hostingowy, instalujemy sklep, instalujemy wtyczki. Testujemy i ruszamy ze sprzedażą. Raczej nie nastawiamy się na zlecanie programowania, bo to już 'mamy' z obecną firmą. Zlecenie napisania sklepu na nowo tylko dla nas praktycznie nie różni się od obecnej sytuacji. Też pewnie trzeba opłacać wsparcie. Może to, że sklep będzie na naszych serwerach jest jakąś różnicą i prowizji do właściciela sklepu nie będziemy płacić. Ale doświadczenie podpowiada mi, że jak komuś zlecimy to do napisania, to i tak będzie chciał to stawiać na jakimś swoim serwerze, bo niby 'przetestowany i sprawdzony'. A za tym idzie dzierżawa tego serwera i na pewno opłata za ruch na nim. Pytaliśmy o nasze wymagania w platformach typu selly. Żadna odpowiedź nie była pozytywna. Wszystkie nie wspierają takich funkcji. Kilka zaproponowało specjalnie dla naszej współpracy przystosowanie sklepu na naszym koncie. Ale przecież takie coś mamy już teraz.
Skanowanie na bramkach mamy już gotowe współpracujące z obecnym sklepem. Kwestia konfiguracji oprogramowania pod nowe kody qr i api nowego sklepu.

czesuaw napisał(a):

Ktoś pisze, że większość opcji dostanę od strzału w większości gotowców. Ktoś inny pisze (tak zrozumiałem), że trzeba to zakodować dedykowanie.

Jeszcze nie widziałem gotowca, który w 100% pokrywałbym wymagania jakiegokolwiek klienta.

Gotowce są, np.
https://github.com/pretix/pretix
https://github.com/Attendize/Attendize

Budżet budżetem. Chcemy gotowca, który już jest. Silnik sklepu + gotowe wtyczki. Wykupujemy serwer hostingowy, instalujemy sklep, instalujemy wtyczki. Testujemy i ruszamy ze sprzedażą.

Wystarczy wziąć gotowca, zainstalować wtyczki, skonfigurować i sprawdzić czy działa zgodnie z oczekiwaniami. Jeśli nie, wybrać innego gotowca i kontynuować poszukiwania.

Co Was powstrzymuje przed działaniem?

Skanowanie na bramkach mamy już gotowe współpracujące z obecnym sklepem. Kwestia konfiguracji oprogramowania pod nowe kody qr i api nowego sklepu.

Patrz wyżej, wystarczy skonfigurować i przetestować.

@czesuaw - obawiam się, że nie znajdziesz "gotowca". Chociażby dlatego co napisałeś wyżej: "kwestia konfiguracji oprogramowania pod nowe kody qr i api nowego sklepu". To nie jest tak, że sobie siadasz i "konfigurujesz" i wszystko śmiga. To jest jedna rzecz.

Kolejna, system sprzedaży biletów. To co opisałeś to szczerze mówiąc to nie spotkałem się z czymś takim ale zerknij na coś takiego: https://www.fooevents.com/sell-tickets/
Myślę jednak, że będzie i tak potrzebny wam programista aby to zaimplementować poprawnie.

Ostatnia rzecz - " Ale doświadczenie podpowiada mi, że jak komuś zlecimy to do napisania, to i tak będzie chciał to stawiać na jakimś swoim serwerze, bo niby 'przetestowany i sprawdzony". To raczej akurat jest jakaś bzdura. Skoro daliście się "wmanewrować" na dzierżawę czyjegoś serwera i im płacicie no to możecie mieć pretensje tylko do siebie. Generalnie to ja raczej się spotykałem z ODWROTNĄ sytuacją gdzie to klient poniekąd "narzucał" gdzie należy trzymać sklep (sam wykupował hosting i po jego stronie było utrzymywanie i opłacanie faktur).

I jeszcze jeden cytat z Twojej wypowiedzi: "Też pewnie trzeba opłacać wsparcie". Jeżeli coś będziesz opierał na samych gotowcach to bez wsparcia moim zdaniem się nie obejdzie. Zakładamy, że zainstalujesz wszystko, uruchomisz i... działa to sobie rok, dwa a potem przestaje. Wtedy już musicie kogoś wezwać do "naprawy". Przychodzi programista, patrzy na to wszystko i wybrzydza... "A tu dopiero PHP 7.4... uuu... słabiutko" i wystawia wam adekwatną fakturę za samo zapoznanie się z problemem

yarel napisał(a):

Gotowce są, np.
https://github.com/pretix/pretix
https://github.com/Attendize/Attendize

Dzięki za propozycje. Sprawdzimy.

leonpro778 napisał(a):

"kwestia konfiguracji oprogramowania pod nowe kody qr i api nowego sklepu". To nie jest tak, że sobie siadasz i "konfigurujesz" i wszystko śmiga

Akurat oprogramowanie na bramkach mamy bardzo elastyczne. Skanery odczytują kilka rodzajów kodów qr, to ustawia się w sofcie samego skanera. W kodzie qr ma być zakodowany tylko identyfikator biletu. Skaner komunikuje się z naszym oprogramowaniem dostarczając mu ten identyfikator. Nasz program loguje się przez api do naszego (obecnie sklepu który prowadzi zewnętrzna firma) sklepu, przesyła ten identyfikator i dostaje w odpowiedzi informacje o bilecie (w jsonie ile osób, jaka godzina i inne rzeczy). Konfiguracja sprowadza się do podania nowych endpointów do logowania i pozyskania danych o bilecie, oraz credentiali do logowania. To zawsze działa, bo firma od sklepu przebudowywała go kilka razy i zawsze podobnie konfigurowaliśmy. Program pozwala nawet zdefiniować jakie pola jsona są odpowiedzialne za jakie informacje. Można mu podać, że ilość osób dorosłych znajdzie w polu bilet.bietyNormalne, a ilość dzieci bilet.biletyUlgowe, zaś data wejścia siedzi w bilet.dataWejścia.
O oprogramowanie bramek się nie martwimy.

leonpro778 napisał(a):

Kolejna, system sprzedaży biletów. To co opisałeś to szczerze mówiąc to nie spotkałem się z czymś takim ale zerknij na coś takiego: https://www.fooevents.com/sell-tickets/
Myślę jednak, że będzie i tak potrzebny wam programista aby to zaimplementować poprawnie.

Sprawdzimy to.