Syrve/iiko + LiqPay: QR-menu, zamówienia ze stołu, napiwki, potwierdzenie przez kelnera

Budżet: 27000 UAH Termin: 7 dni

Na pierwszym etapie chciałbym przejść przez projektowanie techniczne w ciągu 5-7 dni roboczych. Koszt tego etapu to 30000 UAH. Po nim będzie dokładny schemat integracji, ocena MVP i lista ryzyk związanych z Syrve/iiko, LiqPay oraz FOP-ami.

Mamy doświadczenie z integracjami POS, płatnościami, panelami użytkowników, panelami administracyjnymi i skomplikowaną logiką zamówień. Podejście do Resto.Front.Api lub Syrve POS API należy wybrać po sprawdzeniu waszej wersji Syrve/iiko, licencji, scenariusza pracy kelnerów i tego, gdzie dokładnie należy zarządzać otwartym zamówieniem na stole.

Architekturę widzę tak - strona QR stołu, serwer zamówień, panel kelnera lub administratora, moduł synchronizacji z Syrve/iiko, moduł płatności LiqPay, dziennik zdarzeń i oddzielna warstwa reguł dla FOP-ów. Zamówienie z QR nie trafia automatycznie do kuchni - trafia do kolejki potwierdzenia, kelner sprawdza pozycje i dopiero potem system tworzy lub aktualizuje zamówienie w Syrve/iiko.

Oddzielna wtyczka, najprawdopodobniej, będzie potrzebna, jeśli trzeba niezawodnie pracować z otwartym stołem, lokalnym frontem Syrve/iiko, potwierdzeniem kelnera i przyszłym automatycznym zamknięciem. Jeśli wasza konfiguracja pozwala na wszystko przez dostępne API bez lokalnej wtyczki - nie będziemy komplikować.

Napiwki 5%, 10%, 15%, własna kwota lub pominięcie lepiej zrealizować jako oddzielny krok przed płatnością. Tutaj jest niuans - napiwków nie można po prostu zmieszać z pozycjami kuchni, bo potem zaczyna się księgowa poezja, a ona rzadko ma szczęśliwy finał =/ Trzeba określić, jak dokładnie restauracja prowadzi napiwki prawnie i technicznie.

!! Krytyczne miejsce - kilku FOP-ów i fiskalizacja !! Alkohol i kuchnia muszą iść różnymi zasadami, kategoriami, płatnościami lub rachunkami. Na MVP nie robiłbym automatycznego zamknięcia paragonu, a dałbym administratorowi niezawodny status płatności, podział po FOP-ach i bezpieczne ręczne zamknięcie. Pełną automatyzację warto robić tylko po testach na rzeczywistej fiskalnej schemacie.

Ocena czasowa - MVP około 4-6 tygodni. Orientacyjny koszt MVP - 220000-380000 UAH. Pełna wersja z automatycznym zamknięciem, stabilną fiskalizacją, dziennikiem błędów, rolami i normalnym monitoringiem - około 450000-900000 UAH, w zależności od API, wtyczki i wymagań dotyczących logiki kasowej.

Należy wyjaśnić 2 rzeczy.
> Jaka wersja Syrve/iiko jest obecnie u was i czy jest dostęp do Resto.Front.Api lub Syrve POS API.
> Jak obecnie są podzielone FOP-y, merchanty PrivatBank/LiqPay i fiskalne paragony dla alkoholu i kuchni.

Podobne logicznie przykłady naszych prac.
> https://business.ingello.com/forma-bpm - procesy biznesowe, role, potwierdzenie działań, skomplikowane stany operacji.
> https://business.ingello.com/forma-crm - panele administracyjne, ewidencja, kontrola wniosków i praca personelu.
> https://business.ingello.com/prime-eva - logika detaliczna, integracje, ewidencja towarów i skomplikowane zasady sprzedaży.

Strona główna Ingello dla Freelancehunt - https://systems-fl.ingello.com/ua Rozwiń

Budżet: 10000 UAH Termin: 1 dzień

Cześć! Wspaniałe i głębokie zlecenie. Mam doświadczenie z architekturą Syrve (iiko), C# oraz integracjami LiqPay.

Najwęższe miejsca w Twoim projekcie to prawidłowy podział płatności między różnymi FOP (aby uniknąć problemów z fiskalizacją) oraz przechwytywanie paragonu przed jego automatycznym wydrukowaniem w kuchni. Mam jasną wizję, jak zrealizować ten proces w sposób niezawodny i wiem, jak obejść się bez opracowywania ciężkiego wtyczki kasowej na etapie MVP, aby znacznie zaoszczędzić Twój budżet.

Napisz do mnie w wiadomościach prywatnych — krótko opiszę optymalny schemat integracji dla Twojej restauracji i podam orientacyjne liczby!

Budżet: 12000 UAH Termin: 14 dni

Dzień dobry! Robiłem zamówienie internetowe dla restauracji z płatnością LiqPay — QR na stole, menu, koszyk, rachunek. Co do Syrve, główne pytanie: czy macie dostęp do iikoCloud/Syrve API (token chmurowy), czy kasa jest tylko lokalna (RMS na miejscu)? Od tego zależy, jak zamówienie będzie trafiać na stół i czy można dopisywać pozycje do już otwartego rachunku. Reszta — potwierdzenie przez kelnera przed kuchnią, napiwki 5/10/15/własna kwota, płatność LiqPay — odbywa się bez problemu. Jestem gotów się tym zająć, orientacyjnie 12-14 dni. Szczegóły omówimy.

Budżet: 27000 UAH Termin: 14 dni

Cześć! 👋

Twój projekt jest dobrze opisany i widać, że już przemyślałeś podstawową logikę biznesową. Mam doświadczenie w tworzeniu złożonych systemów backendowych, integracjach z zewnętrznymi API, usługami płatniczymi, rozwiązaniami CRM/POS oraz projektowaniu skalowalnej architektury. Również z API Iiko Syrve.
Mój główny stos technologiczny:

Backend

Python
Django
Django REST Framework
FastAPI
PostgreSQL
Redis / Celery

Frontend

React
Next.js
TypeScript

Integracje

REST API
LiqPay / integracje płatnicze
Powiadomienia Telegram
Webhooki
Docker / Nginx / VPS

Jak widzę architekturę MVP:

* Kod QR jednoznacznie identyfikuje stół.
* Frontend wyświetla aktualne menu, otrzymane przez API.
* Zamówienie trafia do własnego backendu ze statusem "oczekuje na potwierdzenie".
* Administrator lub kelner potwierdza zamówienie.
* Po potwierdzeniu backend przekazuje zamówienie do Syrve/iiko.
* Jeśli przy stole już istnieje otwarte zamówienie — nowe pozycje są do niego dodawane, w przeciwnym razie tworzone jest nowe.
* Płatność odbywa się przez LiqPay z wykorzystaniem webhooka do potwierdzenia statusu.
* Panel administracyjny wyświetla statusy zamówień i płatności w czasie rzeczywistym.

Dla napiwków zrealizowałbym osobny krok przed płatnością z opcjami:

* 5%;
* 10%;
* 15%;
* własna kwota;
* bez napiwków.

Kwestie z wieloma FOP-ami należy rozwiązać na poziomie logiki biznesowej i fiskalizacji. Ostateczna decyzja zależy od możliwości konkretnej konfiguracji Syrve/iiko oraz sposobu integracji, dlatego warto to określić podczas technicznego projektowania.

Odpowiedzi na Twoje pytania:

Czy pracowałem z Syrve/iiko? Pracowałem z integracyjnymi API i rozwiązaniami POS, ale przed rozpoczęciem realizacji przeprowadziłbym audyt techniczny możliwości Twojej konfiguracji Syrve/iiko.

Resto.Front.Api / Syrve POS API - tak, realizowałem rozwiązania dla sieci restauracji.

LiqPay / PrivatBank? Tak, mam doświadczenie w integracji usług płatniczych przez API i webhook.
Czy potrzebny jest osobny plugin? To zależy od wybranego sposobu integracji. Po audycie można określić, czy wystarczy API Syrve, czy lepiej użyć pluginu Resto.Front.

Potwierdzenie zamówienia przez kelnera — osobna kolejka zamówień QR w panelu webowym lub tablecie administratora z przyciskami "Potwierdź" / "Odrzuć".

Napiwki — osobny etap przed płatnością z przekazaniem kwoty razem z transakcją płatniczą.

Czekam na Twoją wiadomość w prywatnych!
Z poważaniem, Andrij! Rozwiń

Budżet: 27000 UAH Termin: 28 dni

Dzień dobry!

Zapoznałem się z Twoim zadaniem. Proponuję wdrożenie nowoczesnego rozwiązania webowego opartego na Syrve Cloud API (REST API) zamiast przestarzałego podejścia z lokalnymi wtyczkami w C#. To właśnie według takiej architektury działają czołowe usługi (Choice, Expirenza). Umożliwi to systemowi niezależność od sprzętu w restauracji, zwiększy stabilność i zaoszczędzi Twój budżet.

Odpowiedzi na Twoje pytania:

Czy miałeś doświadczenie / Czy pracowałeś z API? Specjalizuję się w web development i integracjach przez REST API. Zamiast lokalnego Resto.Front.Api (który wymaga C#) integruję system przez chmurę Syrve Cloud API. To nowoczesny standard, który działa z JSON i nie wymaga pisania obejść w C#.

Czy potrzebna jest osobna wtyczka dla Syrve? Nie, wtyczka NIE jest potrzebna. System będzie komunikował się z kasą bezpośrednio przez oficjalną chmurę Syrve.

Czy robiłeś integracje z LiqPay? Tak, mam doświadczenie w pracy z bramkami płatniczymi.

Jak widzisz architekturę? Gość skanuje QR ➔ trafia do aplikacji webowej (frontend) ➔ zbiera koszyk ➔ mój backend przetwarza zamówienie i wysyła zapytanie do Syrve Cloud API ➔ administrator widzi zamówienie na kasie ➔ po płatności status aktualizuje się przez webhooki.

Jak zrealizować potwierdzenie (żeby nie szło od razu do kuchni)? Zamówienie z menu QR jest wysyłane do Syrve jako "Zewnętrzne zamówienie" (dostawa/na stół). Na terminalu kasowym w restauracji miga jako nowe. Administrator je sprawdza, naciska "Akceptuj", i dopiero po tym następuje drukowanie biletów do kuchni.

Jak rozwiązać kwestię z kilkoma FOPami? To jest rozwiązywane na poziomie mojego backendu. Towary dzielą się według kategorii (Kuchnia / Alkohol). W LiqPay rejestrowane są dwa różne merchanty. Przy płatności backend dzieli koszyk na dwie części, a gość dokonuje dwóch transakcji (lub konfigurujemy podział płatności, jeśli pozwalają na to warunki banku). Fiskalizacja przebiega idealnie czysto.

Jak zrealizować napiwki? Przed przejściem do płatności gość widzi ekran z przyciskami (5%, 10%, 15%, własna kwota, pominąć). Aby nie mylić napiwków z dochodem FOPa, idealnie byłoby skonfigurować przekaz tych środków na osobne portfele LiqPay/Mono kelnerów.

Terminy i koszt:

MVP (QR, menu, koszyk, wysyłanie zamówienia do Syrve z ręcznym potwierdzeniem na kasie, bez auto płatności) — orientacyjnie 2-3 tygodnie.

Pełna wersja (LiqPay, 2 FOPy, napiwki, statusy) — jeszcze 3-4 tygodnie.

Dokładny budżet będę mógł podać po uzgodnieniu szczegółów i flow.

Jestem gotów przeprowadzić krótką konsultację techniczną i dokładniej wyjaśnić, dlaczego chmurowa architektura REST to najlepszy wybór dla tego zadania. Będę zadowolony z współpracy! Rozwiń

Budżet: 27000 UAH Termin: 35 dni

Mamy praktycznie gotową podstawę do takiego zamówienia QR z panelem administracyjnym, którą można szybko dostosować do Syrve/iiko, LiqPay i zasad waszych FOP-ów, możemy to omówić tutaj, jestem dostępny na czacie =)

Pracowaliśmy z Syrve/iiko i podobnymi systemami POS, po Resto.Front.Api lub Syrve POS API wybrałbym po sprawdzeniu waszej licencji, dostępów i tego, gdzie są rzeczywiście otwarte zamówienia stolików. Pracowaliśmy z LiqPay i PrivatBank - płatności, callback, weryfikacja podpisu, statusy płatności, ręczne uzgadnianie dla administratora.

Architekturę widzę tak - strona QR stolika, backend z koszykiem i statusami, ekran kelnera do potwierdzenia, warstwa integracji z Syrve/iiko, warstwa płatności LiqPay, dziennik działań administratora. Plugin dla Syrve, najprawdopodobniej, będzie potrzebny, jeśli trzeba będzie niezawodnie widzieć otwarte stoliki i dodawać pozycje do bieżącego zamówienia przez Resto.Front.Api. Jeśli wystarczy Syrve POS API, część można zrobić bez lokalnego pluginu, ale to trzeba sprawdzić na waszej instalacji.

Potwierdzenie przez kelnera robiłbym jako kolejkę zamówień QR - zaakceptować, odrzucić, zmienić komentarz lub pozycję, i dopiero po tym wysyłać do Syrve/iiko. Napiwki 5%, 10%, 15%, własna kwota lub pominąć są realizowane na ekranie przed płatnością, a następnie trzeba je poprawnie przeprowadzić jako osobną kwotę lub pozycję serwisową w zależności od schematu fiskalnego.

Zobaczcie, tu jest niuans... Kilka FOP-ów lepiej rozwiązywać przez grupy towarów, zasady routingu płatności, oddzielnych merchantów lub konta LiqPay i oddzielną logikę fiskalizacji. Na pierwszym etapie zostawiłbym ręczne zamykanie paragonu przez administratora, ponieważ to zmniejsza ryzyko błędów z alkoholem i kuchnią.

MVP orientacyjnie 4-6 tygodni i 180000-260000 UAH. Pełna wersja z automatycznym zamykaniem, rolami, analityką i stabilną logiką fiskalną - około 8-12 tygodni i 400000-700000 UAH. Projektowanie techniczne przed rozwojem - 3-5 dni, da to dokładny schemat API, pluginu i fiskalizacji.

Pytania przed dokładną wyceną: jaka wersja Syrve/iiko jest zainstalowana i czy jest dostęp do API? Czy alkohol i kuchnia mają być opłacane jedną płatnością dla gościa, czy dopuszczalne są 2 płatności w tle?

Podobne przykłady: https://business.ingello.com/eva - e-commerce, płatności, księgowość i skomplikowana logika zamówień; https://business.ingello.com/platforma - system korporacyjny z rolami, procesami i działaniami administracyjnymi; https://business.ingello.com/svitbus - rezerwacje, płatności i statusy zamówień, bliskie logice do scenariusza restauracyjnego.

Główny landing dla FLH: https://systems-fl.ingello.com/ua Rozwiń

Budżet: 1500 UAH Termin: 7 dni

Dzień dobry, Serhii!

Zapoznawszy się z opiniami innych specjalistów, chcę pomóc Ci w projekcie. Poniżej przedstawiam przykłady udanych przypadków:

- Wzrost ruchu o 689% w ciągu 3 miesięcy.
- Wzrost ruchu o 486% dla firmy zajmującej się drukiem.
- Wzrost ruchu o 4854% w ciągu 15 miesięcy.

Na razie powstrzymam się od oferty, ponieważ muszę lepiej zrozumieć cele integracji. Aby zaproponować optymalną formę współpracy, proszę o wyjaśnienie:

- Jakie są terminy uruchomienia? Czy planowane jest szybkie uruchomienie MVP?
- Czy istnieje szczegółowe TŻ lub wizja integracji?
- Jak wyobrażasz sobie architekturę rozwiązania? Czy potrzebny jest osobny plugin dla Syrve?
- Jak zrealizować potwierdzenie zamówienia QR przez kelnera?
- Jak rozwiązać kwestię z wieloma FOP w fiskalizacji?

Na koszt i terminy rozwoju wpływają:

1. Potrzeba konsultacji technicznej.
2. Jasna wizja architektury i potrzeba pluginu dla Syrve.
3. Złożoność integracji z LiqPay lub PrivatBank.
4. Liczba funkcji: potwierdzenie zamówienia QR, ustawienia napiwków.
5. Czas na realizację MVP i pełnej wersji.

Na początku współpracy ważne jest uzgodnienie ostatecznej wizji integracji, którą odzwierciedlimy w technicznym zadaniu. Preferuję formułowanie wizji na podstawie analizy konkurencji i Twoich życzeń.

Mam doświadczenie w pracy z Syrve/iiko i LiqPay, rozumiem specyfikę branży restauracyjnej oraz znaczenie integracji dla poprawy obsługi. Wiem, jak skonfigurować system dla wygody gości i optymalizacji pracy personelu.

Następnym krokiem jest omówienie projektu i zrozumienie, jak bardzo do siebie pasujemy. Ustalmy szczegóły w korespondencji lub na spotkaniu, aby lepiej zrozumieć Twoje potrzeby i znaleźć optymalne podejście do integracji. Rozwiń

Budżet: 10000 UAH Termin: 14 dni

Mam doświadczenie w tworzeniu aplikacji webowych fullstack przez ponad 3,5 roku, stos technologiczny: TypeScript, Vue/Nuxt, NestJS, PostgreSQL. Rozumiem zadanie: integracja menu QR ze stołu, synchronizacja zamówień przez API Syrve/iiko, potwierdzenie przez kelnera i płatność przez LiqPay.

Mogę pomóc w konsultacji technicznej na pierwszym etapie: określić, jak podłączyć się do API Syrve/iiko, jaki plugin jest potrzebny, zaproponować architekturę dla prawidłowego działania dwóch FOP-ów i fiskalizacji, ocenić MVP i terminy. Mam doświadczenie w budowaniu podobnych integracji w produktach B2B, gdzie ważna jest dokładność transakcji i niezawodność.

Jestem gotów omówić szczegóły Twojego projektu i zaproponować jasne rozwiązanie techniczne.

Budżet: 6000 UAH Termin: 5 dni

Dzień dobry!

Zapoznałem się z opisem technicznym. Mogę pomóc w projektowaniu i realizacji integracji menu QR z Syrve/iiko, ustawieniu logiki zamówień ze stołów, integracji systemów płatności oraz przetwarzaniu statusów zamówień.

Na pierwszym etapie proponuję przeprowadzenie analizy technicznej API Syrve/iiko, określenie optymalnej architektury rozwiązania oraz ocenę możliwości realizacji MVP bez zbędnej komplikacji dla personelu restauracji.

Pracuję z REST API, integracjami systemów płatności oraz rozwiązaniami internetowymi do automatyzacji procesów biznesowych.

Jestem gotów omówić szczegóły i zaproponować etapowy plan realizacji.

Budżet: 4000 UAH Termin: 5 dni

Cześć!

Możemy pomóc w automatyzacji Playerok, ale z opisu wynika, że to dość duży system, a nie prosty bot. Jest tutaj dashboard, Autocode, Job, Autobump, Relist, statystyki, panel Telegram, Google Sheets i oddzielny workflow Roblox/Swizzyer.

Zajmujemy się automatyzacją procesów biznesowych, wewnętrznymi panelami, botami Telegram, parsowaniem, systemami dashboard oraz integracjami z zewnętrznymi usługami. Dobrze rozumiemy zadania związane ze statusami, kolejkami, logami, ręcznym zarządzaniem i ochroną przed błędnymi duplikatami.

Za budżet 4000 UAH mogę zaproponować pierwszy etap:

- przeanalizować obecny scenariusz;
- sprawdzić ograniczenia techniczne Playerok / Swizzyer;
- zaprojektować strukturę modułów;
- stworzyć prototyp jednego podstawowego scenariusza lub panelu Telegram.

Pełną funkcjonalność lepiej ocenić osobno po sprawdzeniu dostępów i sposobu automatyzacji. Tak będzie bezpieczniej i bardziej realistycznie pod względem terminów. Rozwiń

Budżet: 1000 UAH Termin: 1 dzień

Cześć! Zrealizowałem integrację z LiqPay — część płatności i QR zamknę, co do API Syrve, jestem gotów zająć się tym na początku razem z Wami. Liczę na współpracę!

Odpowiedzi na:

1. Doświadczenie z Syrve/iiko — nie pracowałem bezpośrednio, ale jestem gotów nauczyć się API na początku
2. Resto.Front.Api / Syrve POS API — przeanalizuję dokumentację przed rozpoczęciem
3. LiqPay / PrivatBank — tak, mam doświadczenie w integracji
4. Architektura — QR → strona internetowa stołu → koszyk → kelner potwierdza → API Syrve → płatność LiqPay → status dla administratora
5. Wtyczka dla Syrve — zależy od wersji, ustalimy na konsultacji
6. Potwierdzenie przez kelnera — oddzielny panel administracyjny lub bot Telegram z przyciskiem potwierdzenia
7. Napiwki — zrealizuję jako oddzielny krok przed płatnością z przyciskami 5/10/15% + własna kwota + pominąć
8. Dwa FOP-y — dwa oddzielne konta LiqPay, podział pozycji według kategorii na poziomie koszyka
9. MVP — orientacyjnie 3-4 tygodnie
10. Koszt MVP — omówimy po konsultacji, obecnie nie ma przykładów podobnych prac. Rozwiń

Budżet: 1500 UAH Termin: 1 dzień

Dzień dobry. Na pierwszy etap (konsultacja techniczna i ocena architektoniczna) jestem gotów wejść, na pełną rozwój MVP szczerze nie mogę: wymaga C# i Resto.Front.Api, tego stosu nie posiadam. Jeśli interesuje was konsultacyjny zakres, proponuję to.

W architekturze rozwiązania standardowo dzieli się na cztery warstwy: część gościnna (strona QR z menu, koszyk, napiwki, płatność) na Next.js lub dowolnym frameworku SSR plus backend na Pythonie lub Node z REST API, warstwa integracji z Syrve lub iiko przez oficjalne Cloud API (dokumentalnie dostępne bez wtyczki C# dla większości scenariuszy, w tym tworzenie i uzupełnianie zamówień przy stole), warstwa płatności przez LiqPay z walidacją serwerową przez podpis, oraz panel administracyjny dla kelnera z potwierdzeniem zamówień QR. Multi-tenant dla FOP-ów realizowane jest na poziomie routingu pozycji według kategorii w warstwie płatności, nie w POS.

W ważnych kwestiach z waszego ZT: Syrve ma API oparte na chmurze (api-ru.syrve.live), do którego można wysyłać zamówienia bez wtyczki. Wtyczka C# potrzebna jest tylko, jeśli trzeba zmieniać zachowanie terminala POS od wewnątrz. Potwierdzenie zamówień QR przez kelnera najprościej realizować jako osobną stronę administracyjną z websocketem do backendu plus push w POS po potwierdzeniu. Napiwki 5-10-15-standardowo idą jako osobna pozycja w rachunku z typem opłaty serwisowej lub przez API LiqPay payee_split.

Co mogę zrobić na pierwszym etapie: pełny dokument architektury z wyborem API, schematem integracji, oceną MVP w godzinach, odpowiedziami na wszystkie pytania z waszego ZT i rekomendacją dotyczącą programisty C# do samej realizacji, z kim można kontynuować. Czasowo 1 dzień roboczy na szczegółową konsultację po zapoznaniu się z waszym aktualnym stanem POS i FOP-ów. Jeśli taki format wam nie odpowiada, całkowicie rozumiem.

Budżet: 10000 UAH Termin: 5 dni

Dzień dobry. Mamy 4-letnie doświadczenie w web development i integracjach systemów biznesowych. Dla takiego rozwiązania widzimy architekturę przez oddzielny web serwis QR-menu z integracją do Syrve/iiko przez Syrve API lub Resto.Front.Api, gdzie zamówienie najpierw trafia do panelu administratora do potwierdzenia, a dopiero potem tworzone lub uzupełniane jest zamówienie w systemie POS. Płatność i napiwki można zrealizować przez LiqPay z wyborem 5%, 10%, 15% lub własnej kwoty, a dla pracy z kilkoma FOPami zaproponujemy oddzielny schemat podziału pozycji i fiskalizacji zgodnie z wymaganiami biznesu. Możemy pomóc zarówno w technicznej konsultacji i projektowaniu MVP, jak i w pełnej realizacji rozwiązania. Przykłady prac: apple-family.com.ua/uk, 3magency.co.

Budżet: 18000 UAH Termin: 21 dni

Cześć,

zadanie nie jest trywialne — szczególnie w części multiFOP i potwierdzenia zamówienia przez kelnera. Przejdźmy do punktów.

Architektura

Trzy warstwy:

Frontend (React SPA) — QR → strona stołu z menu, koszyk, ekran napiwków, rachunek
Backend (Node.js / Python) — middleware między frontendem, Syrve i LiqPay; tutaj żyje kolejka potwierdzeń
Syrve otrzymuje zamówienia tylko po potwierdzeniu, przez iiko Cloud API
Schemat potwierdzenia: gość wysyła zamówienie → trafia do backendu ze statusem pending → kelner/admin widzi je w prostym interfejsie webowym lub Telegram-bocie → potwierdza → backend sprawdza, czy jest otwarte zamówienie na stole przez order_by_id, i albo dodaje pozycje do istniejącego (order_add_items), albo tworzy nowe (order_create).

Czy potrzebny jest plugin dla Syrve?

Nie. iiko Cloud API (REST) pokrywa wszystko: pobrać menu, stworzyć/uzupełnić zamówienie, zamknąć rachunek. Resto.Front.Api — to dla pluginów in-POS w C#, które uruchamiają się wewnątrz samego POS. Do tego zadania nie jest potrzebny.

Napiwki

LiqPay nie ma natywnego pola dla napiwków — i to jest w porządku. Realizacja: gość wybiera 5/10/15% lub wprowadza kwotę, backend oblicza sumę (rachunek + napiwki) i wysyła jedną kwotę do LiqPay. Napiwki są rejestrowane w bazie osobno — do raportu.

Dwa FOPy — fiskalizacja

LiqPay wspiera split payment: jedna płatność automatycznie dzieli się między kilka kont merchant. Schemat: backend przy formowaniu płatności dzieli pozycje na dwa koszyki — alkohol (FOP 1) i wszystko inne (FOP 2), oblicza kwoty, przekazuje w LiqPay parametry split. Oba FOPy otrzymują środki w ramach jednej transakcji. W tym celu należy włączyć funkcję split na poziomie konta merchant — zapytanie do wsparcia LiqPay.

Syrve w tym czasie może widzieć jedno zamówienie — kwestia, czy dzielić na dwa rachunki według FOPów, jest rozwiązywana wspólnie z księgowym i konfiguracją rejestratora fiskalnego. Na pierwszym etapie admin zamyka rachunek ręcznie — to rozwiązuje węzeł.

Terminy i koszt

Jestem gotów przeprowadzić krótką konsultację techniczną — piszcie na priv.

MVP — QR-menu, koszyk z komentarzami, potwierdzenie przez kelnera, wysyłka do Syrve, podstawowa płatność przez LiqPay, statusy dla admina: 18 000–22 000 UAH, 2–3 tygodnie.

Pełna wersja — napiwki, split payment między FOPami, auto-zamknięcie rachunku, admin-dashbord z historią płatności: dodatkowo 15 000–20 000 UAH, jeszcze 2–3 tygodnie. Rozwiń

Budżet: 1000 UAH Termin: 1 dzień

Witam, mam podobne doświadczenie w pracy z płatnościami QR.\nIntegruję w Państwa systemie w całości.\nOto przykład wykonanej pracy - płatność również przechodzi przez Liqpay, jednak integracja z 1C.\nhttps://qr.megaoptika.ua/\nhttps://qr.megaoptika.ua/table/1/\nW sprawie wszelkich pytań proszę pisać na prywatną wiadomość, z przyjemnością pomogę!

Budżet: 8000 UAH Termin: 5 dni

Dzień dobry. Nasz zespół ma wieloletnie doświadczenie w tworzeniu ERP, CRM, CMS oraz specjalistycznego oprogramowania dla biznesu. Tworzymy efektywne rozwiązania cyfrowe, które pomagają automatyzować procesy, zwiększać wydajność i skalować firmy.

Pracujemy z nowoczesnymi technologiami — od botów i skryptów po agentów AI i systemy analityczne. Opracowujemy strony internetowe o różnym stopniu skomplikowania. W naszym portfolio znajdują się zrealizowane rozwiązania ERP dla branży hotelarskiej, a także dla firm zajmujących się importem i sprzedażą towarów, a także nasz własny produkt XFitness — system ERP stworzony specjalnie dla klubów fitness.

Jesteśmy gotowi zrealizować Twój projekt i zaproponować najlepsze rozwiązanie dostosowane do Twoich potrzeb. Nasze portfolio: Freelancehunt

Specjalizujemy się w takich dziedzinach:
-Rozwój systemów ERP
-Rozwój systemów CRM
-Rozwój stron internetowych o dowolnym stopniu skomplikowania
-Rozwój systemów CMS
-Wsparcie stron internetowych
-Rozwój OpenCart
-Wsparcie OpenCart
-Modyfikacja OpenCart
-Doróbki OpenCart
-Rozwój WordPress
-Wsparcie WordPress
-Modyfikacja WordPress
-Doróbki WordPress
-Rozwój ECommerce
-Wsparcie ECommerce
-Modyfikacja ECommerce
-Doróbki ECommerce
-Rozwój aplikacji internetowych
-Wsparcie serwerów 1C
-Wsparcie serwerów WWW
-Rozwój aplikacji mobilnych
-Parsowanie danych
-Rozwój botów
-Rozwój agentów AI

i w takich technologiach:
-Python
-PHP
-Laravel
-Symfony
-Yii2
-JS
-NodeJS
-jQuery
-TypeScript
-MySQL
-HTML
-CSS
-Vue
-Nuxt.js
-React
-React Native
-C++ Rozwiń

Budżet: 10000 UAH Termin: 1 dzień

Cześć!

Możemy pomóc z integracją menu QR, płatnościami i obsługą zamówień zgodnie z Twoim schematem.

1. Czy masz już wybrany sposób podłączenia do Syrve/iiko?
2. Jaki scenariusz dla MVP jest potrzebny w pierwszej kolejności?

—
O nas

Jesteśmy dZENcode – firmą IT zajmującą się pełnym cyklem rozwoju: od projektowania i programowania po integracje i wsparcie posprzedażowe rozwiązań cyfrowych.
Tworzymy projekty od podstaw, a także łączymy się z już istniejącymi rozwiązaniami, które potrzebują poprawek, rozwoju lub wsparcia technicznego.

Szczegółowe informacje o naszych usługach i stawkach znajdziesz na oficjalnej stronie: Freelancehunt

Zobacz – po tym będziemy mogli omówić szczegóły i uzgodnić następny krok.

⚠️ Po wyjaśnieniu wszystkich szczegółów określimy zakres prac, odpowiedni format współpracy: zadaniowy, outsourcing lub outstaffing – oraz ostateczną cenę.

Z nami projekty gwarantowanie dochodzą do wydania:
• 10+ lat świadczymy usługi IT;
• 90+ pracowników na etacie;
• 250+ publicznych opinii od 2015 roku;
• Wspieramy produkty zgodnie z SLA po uruchomieniu;
• Pracujemy na podstawie NDA i umowy z firmą! Rozwiń

Budżet: 24800 UAH Termin: 21 dni

Witam. Mam doświadczenie w podobnych projektach integracyjnych, dlatego mogę pomóc zarówno w zakresie konsultacji technicznych i projektowania architektury rozwiązania, jak i w dalszym rozwoju MVP. Na pierwszym etapie można określić optymalny sposób integracji z Syrve/iiko, opracować logikę zamówień, płatności i fiskalizacji, aby uniknąć problemów podczas uruchamiania i skalowania systemu.

Budżet: 11000 UAH Termin: 7 dni

Pracowałem z API iiko i LiqPay, więc rozumiem zadanie od środka. W zasadzie to połączenie: front na stole (QR -> menu -> zamówienie), backend, który zapisuje zamówienie w iiko przez API i utrzymuje status, plus LiqPay do płatności i opcjonalnie napiwków jako oddzielna transakcja. Kluczowym punktem tutaj, moim zdaniem, jest potwierdzenie przez kelnera: trzeba zrozumieć, czy to przez interfejs kasjera iiko, czy oddzielne powiadomienie mobilne. Jestem gotów omówić szczegóły i oszacować zakres prac.

Budżet: 1000 UAH Termin: 7 dni

Zrozumiałem zadanie. Kiedyś często bywałem u znajomych restauratorów i wiem, jak bolesne jest później poprawianie błędów w księgowości i paragonach, dlatego architekturę lepiej przemyśleć jeszcze przed rozpoczęciem prac. Widzę sens, aby zacząć od konsultacji technicznej i schematu integracji, aby zrozumieć, czy API Syrve będzie wystarczające, czy dla waszych procesów będzie potrzebny osobny plugin. Po tym można już dość dokładnie ocenić MVP, terminy i budżet. Proszę, powiedzcie, jaka wersja Syrve jest obecnie używana w restauracji? Czy jest już gotowe menu QR, czy też trzeba je opracować? I jak obecnie zorganizowana jest praca z kilkoma FOP w samej systemie POS?

Budżet: 25000 UAH Termin: 20 dni

Mamy doświadczenie w integracji Syrve/iiko z bramkami płatniczymi. Realizujemy system przez API do synchronizacji menu, zamówień i transakcji LiqPay. Zapewnimy poprawne przesyłanie danych do terminala kelnera oraz automatyczne zamykanie paragonów. Jesteśmy gotowi zaprojektować architekturę dla stabilnej pracy Twojej restauracji.