Architektura danych lokalu
POS a system zaplecza restauracji: różnice i przepływ danych
POS i system zaplecza restauracji rozwiązują różne problemy. POS rejestruje zamówienie, płatność i paragon. Zaplecze wykorzystuje wynik sprzedaży do kontroli receptur, kosztów, stanów, zobowiązań i wyniku. Integracja ma przenosić dane między tymi rolami, a nie dublować cały system kasowy.
Autor: Plentaro. Aktualizacja: .
Podział odpowiedzialności
Granicę najlepiej wyznaczyć zdarzeniem biznesowym. POS kończy swoją podstawową rolę, gdy poprawnie rejestruje sprzedaż i metodę płatności. Zaplecze zaczyna pracę, gdy łączy tę sprzedaż z recepturą, kosztem, stanem magazynowym albo prognozą gotówki.
- POS: zamówienia, paragony, płatności, rabaty, zwroty i raport sprzedaży.
- Zaplecze: receptury, koszt porcji, zakupy, stany, faktury, terminy i analiza wyniku.
- Księgowość: ewidencja, podatki, deklaracje i zgodność rozliczeń.
Minimalny przepływ danych
Na początku wystarczy stabilny raport dobowy lub plik CSV. Integracja API daje szybszą aktualizację, ale nie naprawi niejednoznacznych nazw produktów, brakujących identyfikatorów ani zmiany struktury kategorii. Najpierw trzeba zdefiniować kontrakt danych.
- Jednoznaczny identyfikator pozycji sprzedażowej.
- Data i czas sprzedaży, ilość, wartość netto, VAT, rabat i metoda płatności.
- Mapowanie pozycji POS do receptury albo jawny status braku mapowania.
- Idempotencja, aby ponowny import nie dublował sprzedaży.
CSV czy API
CSV jest dobrym startem, gdy format eksportu jest stabilny, a decyzje podejmujesz raz dziennie. API ma sens, gdy dane muszą być aktualizowane częściej albo ręczny eksport staje się realnym obciążeniem. W obu wariantach potrzebne są walidacja, raport błędów i możliwość ponowienia importu bez duplikatów.
Najdroższy wariant to częściowa automatyzacja bez kontroli kompletności. Właściciel widzi wtedy aktualny wykres, ale nie wie, że część paragonów albo produktów nie została połączona.
Pytania przed połączeniem systemów
Dostawca powinien odpowiedzieć nie tylko, czy integracja istnieje, lecz także jak zachowuje się przy błędzie i jak można sprawdzić kompletność danych.
- Jaki identyfikator pozostaje stabilny po zmianie nazwy produktu?
- Czy eksport zawiera zwroty, rabaty, anulowania i formy płatności?
- Jak system wykrywa ponowne przesłanie tego samego raportu?
- Gdzie właściciel zobaczy rekordy odrzucone lub niepołączone?
Pytania i odpowiedzi
Najczęstsze pytania
Czy trzeba zmieniać POS, aby wdrożyć Plentaro?
Nie, jeśli obecny POS pozwala uzyskać stabilny raport sprzedaży zawierający dane potrzebne do analizy. Zakres integracji sprawdza się na rzeczywistym eksporcie lokalu.
Czy API jest zawsze lepsze niż import CSV?
Nie. API skraca czas aktualizacji, ale zwiększa zależność od jakości integracji. Dla codziennego raportowania stabilny i walidowany CSV może być wystarczający.
Weryfikacja
Źródła
- 1.Plentaro, publiczny opis przepływu POS i zaplecza
Źródło deklarowanego podziału odpowiedzialności produktu.
Zastosowanie w lokalu
Zobacz Plentaro na danych swojego lokalu.
Na trzydziestominutowym spotkaniu przechodzimy przez konkretny dzień pracy restauracji, bez prezentacji sprzedażowej.
Umów demo