Jak platforma Hub łączy salon, sklep i panel dealera z systemami, które już działają w grupie. Co jest w prototypie, co jest realne w MVP, a co zależy od umów i dostępu do cudzych systemów.
Trzy warstwy: klienci, platforma Hub, integracje. Linia ciągła - integracja w MVP, kreskowana - faza 2, kropkowana - faza 3. Na telefonie schemat przewija się w bok.
Ocena ryzyka to nasze założenia robocze, nie wynik rozmów z dostawcami. Prawie każda pozycja zależy od umowy lub zgody właściciela systemu - to główne ryzyko harmonogramu, nie sama technika.
| System | Kierunek danych | Tryb | Dane | Ryzyko i plan B | Faza |
|---|---|---|---|---|---|
| System importera | importer do Hub | plik CSV/XML (SFTP, e-mail); REST tylko jeśli importer go udostępnia | stany, ceny katalogowe, warianty, gwarancje | Dostęp do danych importera wymaga umowy i jest u każdej marki inny. Plan B: ręczny import pliku z panelu dealera; ceny publiczne tylko jako orientacyjne. | MVP |
| DMS dealera | dwukierunkowo, w MVP tylko DMS do Hub | eksport bazy / most bazodanowy (widok SQL, replika do odczytu); REST/SOAP rzadko | klienci, faktury, magazyn, zlecenia serwisowe | Wiele DMS nie ma API. Dostawca może wymagać zgody lub opłaty, a zapis zwrotny jest ryzykowny. Plan B: nocny eksport plikiem, zlecenia wpisywane w DMS ręcznie. | 2 |
| CEPiK / dekoder VIN | Hub do zewnętrznego | API komercyjne dekodera; CEPiK tylko przy podstawie prawnej | dekodowanie VIN, wyposażenie fabryczne | Dostęp do CEPiK jest ograniczony prawnie - nie zakładamy go w MVP. Dla nowych aut wystarcza VIN i dane z systemu importera. W prototypie: atrapa. | 3 |
| KSeF | wysyłka z DMS, Hub czyta status | API Ministerstwa Finansów, zwykle przez DMS | e-faktury, numery KSeF, statusy | Terminy obowiązku wdrażane etapami - do sprawdzenia aktualnie. Faktury wystawia DMS; Hub nie powinien dublować tej roli. Plan B: numer faktury wpisywany ręcznie. | 2 |
| Partnerzy leasingowi | Hub do partnera i z powrotem | REST kalkulatora albo portal partnerski; e-mail z wnioskiem | cena, wkład, wykup, okres, rata, status wniosku | Nie każda firma leasingowa ma API. Plan B: własny kalkulator na tabelach stawek (wycena indykatywna) i wniosek wysyłany do partnera. | MVP |
| Ubezpieczyciele | Hub do ubezpieczyciela | REST agregatora lub brokera | dane pojazdu i ubezpieczanego, oferty OC/AC | Sprzedaż polis wymaga statusu agenta lub współpracy z brokerem (regulacje). Plan B: formularz zgłoszeniowy przekazywany brokerowi. | 2 |
| Płatności online | Hub do bramki, webhook zwrotny | bramka płatnicza (redirect, webhook) | zadatek za rezerwację, płatność za części | Niskie ryzyko techniczne; dane karty zostają po stronie bramki. Plan B: przelew z tytułem i ręczne potwierdzenie. | 2 |
| E-mail / SMS | Hub do klienta | SMTP, bramka SMS | potwierdzenia, przypomnienia, kody | Niskie ryzyko. Wymagane zgody (RODO, komunikacja marketingowa). Plan B: powiadomienie tylko w panelu. | MVP |
| Kluczkomaty | Hub do sterownika | API producenta lub kody jednorazowe | kod odbioru, okno czasowe, potwierdzenie wydania | Zależy od modelu urządzenia; część nie ma API. Plan B: kod generuje i wpisuje pracownik. | 3 |
Wybierz endpoint, popraw parametry i wyślij. Wywołanie idzie przez window.API - ten sam obiekt, którego używają pozostałe strony prototypu. Wywołania trafiają do prawdziwego serwera Hub (baza SQLite, logowanie, role); endpointy wymagające roli pokażą okno logowania.
-
-
Pokazuje wszystkie wywołania API wykonane na tej stronie, także statusy integracji i synchronizację. Dziennik jest w pamięci strony - po przejściu na inną podstronę zaczyna się od zera.
Stan z API.integrations(). Wartości są symulowane - w produkcji pochodziłyby z testów połączeń i ostatnich udanych wymian danych.
Propozycja kontraktów docelowych. Atrapa w prototypie implementuje je częściowo: nie wymusza zgód, nagłówków ani walidacji pól.
Propozycja ról. "Własny salon" oznacza dane ograniczone do salonów przypisanych użytkownikowi.
| Rola | Auta | Zgłoszenia | Wyceny | Sync importera | Zamówienia | Dane osobowe |
|---|---|---|---|---|---|---|
| Dealer (zarząd grupy) | wszystkie salony | odczyt i zapis, wszystkie | tak | tak | tak | tak |
| Handlowiec | własny salon | własny salon | tak | nie | własny salon | własne zgłoszenia |
| Serwis | nie | tylko serwis i kluczkomat | nie | nie | części, własny salon | własne zgłoszenia |
| Importer (tylko odczyt) | stany i sprzedaż, zbiorczo | nie | nie | nie | nie | nie |
| Partner B2B | nie | nie | nie | nie | własne, z limitem kredytowym | tylko własna firma |
Zasada nadrzędna: importer nie widzi danych osobowych klientów dealera. Logowanie i cztery role (admin, handlowiec, serwis, warsztat B2B) już działają; podział na własny salon i rola importera to opis docelowy.
Hub ma dziś działający backend, logowanie, role, import plikowy i pomiar leadów, ale nie ma prawdziwych integracji z systemami zewnętrznymi (DMS, CEPiK, KSeF, leasing, ubezpieczenia, płatności). Poniżej lista prac, część już zrobiona w wersji demonstracyjnej. Kolumna z tygodniami to szacunek przy założeniu małego zespołu (2-3 programistów), bez doliczania czasu oczekiwania na umowy i dostępy - nie jest wynikiem analizy projektowej.
| Praca | Co obejmuje | Szacunek, tygodnie |
|---|---|---|
| Backend i API | baza danych, REST, uwierzytelnianie, role z sekcji 6, dziennik audytu | szacunek: 4-6 |
| Katalog i stany | model aut i części, dopasowanie po modelu/VIN, rezerwacje | szacunek: 3-4 |
| Import z systemu importera | parser plików, mapowanie na własny model, obsługa błędów i zmian cen | szacunek: 3-5 po uzyskaniu dostępu |
| Kolejka zgłoszeń | statusy, przypisanie do salonu, powiadomienia e-mail/SMS, zgody RODO | szacunek: 3 |
| Silnik wycen leasingu | tabele stawek, kalkulator, później API partnerów | szacunek: 4-6 |
| Most do DMS | eksport lub replika odczytowa, mapowanie klientów i zleceń; zapis zwrotny dopiero później | szacunek: 4-8, zależy od DMS |
| Ubezpieczenia | integracja z brokerem/agregatorem, zgodność z regulacjami | szacunek: 4-8 |
| Płatności i KSeF | bramka z webhookami; podgląd statusów KSeF przez DMS | szacunek: 4-6 łącznie |
| Kluczkomaty | integracja ze sterownikiem lub generator kodów | szacunek: 3-6 |
| Bezpieczeństwo, monitoring, testy, pilotaż w jednym salonie | kopie zapasowe, alerty, testy integracji, szkolenie, poprawki po pilotażu | szacunek: 6-8 |
Dwa moduły z panelu (zakładki Radar i Systemy). Radar liczy czas reakcji, lejek i utraconą wartość z danych Hub albo z importu CSV; katalog zbiera systemy, z których dealerzy w Polsce korzystają, i te, które wymagają producenci, importerzy oraz przepisy.
| Endpoint | Rola | Co robi |
|---|---|---|
| GET /v1/radar?scope=demo|live|all&days=7|30|60|90 | personel | KPI, lejek, tabele wg źródła, marki, oddziału i typu, trend tygodniowy, przed i po wdrożeniu, kolejka leadów bez kontaktu, metodyka |
| PUT /v1/radar/assumptions | admin | SLA, godziny pracy, próg zaniechania, minimalna próba, data wdrożenia, wartości leadów (puste = brak, [X]) |
| POST /v1/radar/import | admin | CSV lub JSON z CRM, tylko metadane (ts, type, source, brand, salon, first_contact_ts, status, closed_ts); ?dry=1 sprawdza bez zapisu |
| POST /v1/radar/demo/reseed | admin | generuje dane DEMO od nowa (prawdziwe zgłoszenia zostają) |
| GET /v1/systems, /v1/systems/connectors | personel | katalog systemów z dowodami i pewnością W/S/N oraz łączniki Hub ze statusem działa, atrapa lub plan |
Dane DEMO Radaru są generowane i zależność szybszej reakcji od konwersji jest w nich założona z góry, więc ekran pokazuje obliczenia, a nie fakt o rynku. Szacunek utraconych PLN to korelacja, nie dowód przyczynowy. Pełny opis: docs/SZKIELET.md w repozytorium.