Požiadavky prototypu

Živá kontrolná listina napojená na docs/prototype-requirements-sk.md
Rola
Celkový pokrok86 / 100 · 86%
P0: 40/42
P1: 40/44
P2: 6/14

Status sa aktualizuje úpravou markdown súboru docs/prototype-requirements-sk.md ([x] = hotovo).

1.Ciel projektu5/5
CIE-001
System musi sluzit ako centralizovany ERP/CRM pre medzinarodny B2B obchod s vozidlami.
Akcept.: Pouzivatel vie spravovat skladove vozidla aj objednavky do vyroby v jednom systeme.
Projekt
P0
CIE-002
System musi podporovat automatizovany tok dat medzi obchodom, nakupom, financiami, logistikou a reportingom.
Akcept.: Zmeny statusov a klucove udalosti automaticky ovplyvnuju suvisiace moduly.
Workflow
P0
CIE-003
System musi podporovat pokrocile planovanie logistiky cez integrovany kalendar.
Akcept.: Nakladky, dodania a expiracie su zobrazene v centralnom kalendari.
Logistika
P1
CIE-004
System musi podporovat internu spravu prepravnych dokumentov CMR.
Akcept.: CMR dokument je mozne nahrat, archivovat a naviazat na kartu vozidla.
Dokumenty
P1
CIE-005
System musi riadit viacstupnove zalohy, cashflow, medzifiremnu fakturaciu a reporting.
Akcept.: Financne udalosti su sledovane a premietaju sa do cashflow a reportov.
Financie
P1
2.Role a pristupove prava7/7
ROL-001
System musi podporovat rolu Administrator / Management s plnym pristupom.
Akcept.: Pouzivatel tejto roly vidi vsetky moduly, ceny, marze, cashflow a firemne reporty.
Pristupove prava
P0
ROL-002
System musi podporovat rolu Nakupca.
Akcept.: Nakupca vidi nakupne ceny, dodavatelov, vyrobne plany a nakupne dokumenty; predajne ceny len obmedzene.
Pristupove prava
P0
ROL-003
System musi podporovat rolu Obchodnik.
Akcept.: Obchodnik vidi CRM, klientov a ponuky, ale nevidi nakupne ceny ani interne marze.
Pristupove prava
P0
ROL-004
Nakupne ceny a interne marze musia byt pre obchodnika systemovo nedostupne.
Akcept.: Obchodnik nedokaze ziskat tieto data ani cez UI, API alebo export.
Bezpecnost dat
P0
ROL-005
Obchodnik musi vidiet iba vlastne obchodne reporty.
Akcept.: Reporty obchodnika neobsahuju data inych obchodnikov, ak nema manazersku rolu.
Reporting
P1
ROL-006
System musi podporovat rolu Logista / Back-Office.
Akcept.: Rola ma pristup k logistike, dokumentom TP/COC/CMR, registraciam, poisteniu a kalendaru.
Pristupove prava
P0
ROL-007
System musi podporovat rolu Uctovnik / Financnik.
Akcept.: Rola ma pristup k fakturacii, bankovym vypisom, parovaniu platieb a lokalnemu cashflow entity.
Pristupove prava
P0
3.Globalne rozhranie a grid system5/5
UI-001
Hlavne prehlady musia byt postavene na robustnom tabulkovom grid systeme.
Akcept.: Zoznam aut, sklad, objednavky a faktury pouzivaju konzistentny grid.
Grid
P0
UI-002
Grid musi podporovat dynamicke fasetove filtre podla lubovolneho databazoveho stlpca.
Akcept.: Pouzivatel vie filtrovat napr. podla statusu, klienta, dodavatela, modelu, farby, KW, Loading ID alebo meny.
Filtre
P0
UI-003
Filtre musia byt kombinovatelne.
Akcept.: Pouzivatel vie sucasne pouzit viac filtrov a vysledok sa spravne zuzi.
Filtre
P0
UI-004
Grid musi podporovat hromadny vyber riadkov cez checkboxy.
Akcept.: Pouzivatel vie oznacit viac poloziek naraz.
Hromadne akcie
P0
UI-005
Nad oznacenymi polozkami musia byt dostupne hromadne operacie.
Akcept.: System podporuje hromadnu zmenu statusu, priradenie k nakladke, export a Delivery Update.
Hromadne akcie
P1
4.Datovy model vozidla12/12
DAT-001
Zakladnym prvkom systemu musi byt karta vozidla.
Akcept.: Karta vozidla existuje ako centralny zaznam pre obchod, financie, logistiku a dokumenty.
Vozidlo
P0
DAT-002
Karta vozidla musi podporovat identifikator ID, VIN a cislo komisie.
Akcept.: Vozidlo je mozne vyhladat a parovat podla tychto identifikatorov.
Identifikacia
P0
DAT-003
Karta vozidla musi podporovat typ obchodu Sklad alebo Pipe_Vyroba.
Akcept.: Procesy a workflow sa prisposobia zvolenemu typu obchodu.
Typ obchodu
P0
DAT-004
Karta vozidla musi evidovat menu nakupu a menu predaja.
Akcept.: System uklada `Currency_Purchase` a `Currency_Sales`.
Multi-currency
P0
DAT-005
Karta vozidla musi evidovat booking kurz a aktualny kurz.
Akcept.: System uklada `Exchange_Rate_Booking` a denne aktualizovany `Exchange_Rate_Actual`.
Kurzy
P1
DAT-006
Karta vozidla musi evidovat hrubu nakupnu cenu, zlavu, cistu nakupnu cenu a predajnu cenu.
Akcept.: System uklada a zobrazuje `Price_Purchase_Gross`, `Discount`, `Price_Purchase_Net` a `Price_Sales`.
Ceny
P0
DAT-007
System musi vypocitat internu marzu vozidla.
Akcept.: `Margin_Internal` sa vypocita ako predajna cena minus nakupna cena.
Marza
P0
DAT-008
Karta vozidla musi evidovat danovy rezim.
Akcept.: System podporuje Reverse Charge, Export a Tuzemsky s DPH.
DPH
P1
DAT-009
Karta vozidla musi evidovat, ci ide o externu alebo internu portfoliovu transakciu.
Akcept.: Zaznam obsahuje intercompany priznak pouzitelny vo fakturacii, cashflow a reportoch.
Intercompany
P1
DAT-010
Karta vozidla musi evidovat kalendarny tyzden vyroby v tvare KW.
Akcept.: Hodnota je validovana vo formate napr. `KW24`.
Vyroba
P0
DAT-011
Karta vozidla musi evidovat stav dokumentov TP a COC.
Akcept.: Pouzivatel vidi checkboxy TP a COC s hodnotou Ano/Nie.
Dokumenty
P1
DAT-012
Karta vozidla musi evidovat statusy a expiracie registracie a poistenia.
Akcept.: System podporuje hodnoty Na firmu, Dodavatel a Netreba spolu s datumom expiracie.
Registracia a poistenie
P1
5.Vyrobne objednavky a zalohy6/7
PIPE-001
Modul Pipe musi riadit vyrobne objednavky vozidiel.
Akcept.: Vozidla typu Pipe_Vyroba maju vlastny stavovy proces a vyrobne udaje.
Vyrobne objednavky
P0
PIPE-002
System musi sledovat klientsku zalohu ako samostatny inflow okruh.
Akcept.: Pri Pipe_Vyroba system vygeneruje klientsku zalohovu fakturu, napr. 10 % z predajnej ceny.
Zalohy
P0
PIPE-003
System musi sledovat zalohu dodavatelovi ako samostatny outflow okruh.
Akcept.: Po prijati klientskej zalohy system pripravi prikaz na uhradu zalohy dodavatelovi.
Zalohy
P1
PIPE-004
System nesmie povolit zadanie vozidla do vyroby bez potvrdenej klientskej zalohy.
Akcept.: Status sa odomkne az po 100 % sparovani platby cez bankove API alebo ekvivalentnu validaciu.
Validacia platieb
P0
PIPE-005
System nesmie povolit priradenie vozidla k nakladke bez potvrdeneho finalneho doplatku.
Akcept.: Logistika je odomknuta az po sparovani 90 % doplatku alebo po vynimke managementu.
Validacia platieb
P0
PIPE-006
System musi podporovat hromadne priradenie VIN ku komisiam importom Excelu od dodavatela.
Akcept.: Import automaticky sparuje VIN s kartami podla zhodneho cisla komisie.
Import VIN
P1
PIPE-007
System musi umoznit zmeny specifikacie pocas stavu Vo vyrobe bez narusenia financnych vazieb.
Akcept.: Uprava konfiguracie nezrusi sparovane zalohy ani existujuce fakturacne vazby.
Konfiguracia
P2
6.Fakturacia, bankove parovanie a multi-entity6/7
FIN-001
System musi podporovat vystavovanie faktur pre viac vlastnych firiem.
Akcept.: Faktury je mozne vystavit pod spravnou entitou a legislativou.
Multi-entity
P0
FIN-002
System musi podporovat zalohove aj ostre faktury.
Akcept.: Pouzivatel vie vytvorit oba typy faktur pre obchodny proces vozidla.
Fakturacia
P0
FIN-003
Fakturacia musi podporovat SK/CZ legislativu, EUR/CZK meny a DPH sadzby.
Akcept.: Faktura respektuje entitu, menu a danovy rezim.
Legislativy a meny
P1
FIN-004
System musi udrziavat white-list internych portfoliovych firiem.
Akcept.: Interna fakturacia medzi firmami zo zoznamu je oznacena ako `Intercompany_Invoice`.
Intercompany
P1
FIN-005
System musi automaticky citat bankove vypisy.
Akcept.: Bankove transakcie su importovane a dostupne na parovanie.
Bank API
P1
FIN-006
System musi automaticky parovat prichadzajuce a odchadzajuce platby.
Akcept.: Zalohy a doplatky klientov aj platby dodavatelom sa paruju k fakturam alebo vozidlam.
Parovanie platieb
P1
FIN-007
System musi podporovat automatizovany dunning pre oneskorene doplatky.
Akcept.: Po splatnosti doplatkovej faktury system odosiela e-mailove upomienky v nastavenych intervaloch.
Upomienky
P2
7.Cashflow a financne predikcie7/7
CSH-001
System musi zobrazovat lokalny cashflow pre kazdu firmu samostatne.
Akcept.: Financnik vie vybrat entitu a vidiet jej ocakavane prijmy a vydavky.
Cashflow
P1
CSH-002
System musi zobrazovat konsolidovany cashflow za cele portfolio.
Akcept.: Management vidi spolocny cashflow napriec entitami.
Cashflow
P1
CSH-003
Konsolidovany cashflow musi automaticky eliminovat intercompany faktury.
Akcept.: Intercompany faktury nenavysuju ocakavane prijmy ani vydavky v konsolidovanom pohlade.
Intercompany eliminacia
P1
CSH-004
System musi dynamicky prepocitavat cashflow v case.
Akcept.: Cashflow je mozne zobrazit po dnoch, tyzdnoch alebo mesiacoch.
Forecasting
P1
CSH-005
Cashflow musi pouzivat vystavene faktury ako zdroj ocakavanych tokov.
Akcept.: Datum splatnosti faktury ovplyvni ocakavany pritok alebo odtok penazi.
Faktury vo forecastingu
P1
CSH-006
Cashflow musi pouzivat planovane nakladky na odhad buducej fakturacie.
Akcept.: Plan nakladky ovplyvni predpoklad vystavenia doplatkovej faktury a prijmu.
Logistika vo forecastingu
P2
CSH-007
Cashflow musi pouzivat vyrobne objednavky a KW vyroby na predikciu kapitalovej potreby.
Akcept.: System odhaduje buduce doplatky dodavatelom a inkaso od klientov niekolko mesiacov dopredu.
Pipe vo forecastingu
P2
8.Multi-currency a kurzove riziko3/3
FX-001
Pri schvaleni obchodu musi system uzamknut kurz dna.
Akcept.: `Exchange_Rate_Booking` sa ulozi a pouziva pre kalkulacie marze a cashflow.
Kurzy
P1
FX-002
System musi denne aktualizovat aktualny bankovy kurz.
Akcept.: `Exchange_Rate_Actual` sa pravidelne aktualizuje z externeho zdroja alebo API.
Kurzy
P2
FX-003
System musi upozornit na kurzove riziko ohrozujuce marzu.
Akcept.: Ak rozdiel kurzu ohrozi marzu o viac ako 1,5 %, system vytvori varovanie.
Alerty
P2
9.Obchodny modul a CRM9/10
CRM-001
System musi evidovat klientov a ich obchodne udaje.
Akcept.: Klientsky zaznam obsahuje zakladne udaje, preferencie a historiu komunikacie.
CRM
P0
CRM-002
Obchodnik musi vediet vybrat vozidla zo skladu alebo vyroby a pripravit ponuku.
Akcept.: Vozidla oznacene cez multi-select sa daju pridat do klientovej ponuky.
Ponuky
P0
CRM-003
Obchodnik musi vediet pridat marzu k ponuke.
Akcept.: System vypocita predajnu cenu alebo ponukovu cenu podla nastavenej marze.
Marza v ponuke
P0
CRM-004
System musi generovat vizualnu klientsku ponuku.
Akcept.: Export obsahuje logo, meno klienta a predajne ceny bez internych dat.
Export PDF/obrazok
P1
CRM-005
System musi generovat ocisteny Excel pre klienta.
Akcept.: Export fyzicky neobsahuje nakupne ceny, marze ani interne poznamky.
Export Excel
P0
CRM-006
CRM musi podporovat wishlist klienta.
Akcept.: Pri klientovi je mozne evidovat preferovane znacky, modely a dalsie poziadavky.
Wishlist
P2
CRM-007
CRM musi evidovat historiu odoslanych ponuk.
Akcept.: Ponuky su filtrovatelne podla znacky, modelu, uzavretych obchodov a marze.
Historia ponuk
P1
CRM-008
System musi podporovat upozornenia podla dostupnosti pozadovaneho modelu alebo znacky.
Akcept.: Pri splneni wishlist podmienok system vytvori notifikaciu naviazanu na klienta alebo ponuku.
Upozornenia
P2
CRM-009
CRM musi evidovat datum posledneho kontaktu a pripomienky.
Akcept.: Obchodnik vidi a spravuje follow-up ulohy ku klientom.
Remindery
P1
CRM-010
System musi automaticky overovat DIC zahranicneho partnera cez VIES API.
Akcept.: Pri neplatnom DIC system zablokuje fakturu s 0 % DPH.
VIES
P1
10.Logistika, CMR a skladovne5/6
LOG-001
Logista musi vediet oznacit pripravene vozidla cez multi-select.
Akcept.: Oznacene vozidla sa daju spracovat ako jedna logisticka akcia.
Nakladky
P0
LOG-002
System musi automaticky zoskupovat vozidla do logistickych celkov.
Akcept.: Vozidla su rozdelene do `Loading_ID` podla miesta nakladky a vykladky.
Multi-routing
P1
LOG-003
System musi generovat a archivovat CMR dokumenty.
Akcept.: CMR je priradene priamo ku karte vozidla.
CMR
P1
LOG-004
Nahratie potvrdeneho alebo podpisaneho CMR musi automaticky zmenit status vozidla na Delivered.
Akcept.: Ak `CMR_Document` prestane byt prazdne, system prepne status na Delivered.
CMR trigger
P0
LOG-005
System nesmie uzavriet cezhranicny Reverse Charge obchod bez finalne podpisaneho CMR.
Akcept.: Uctovne uzavretie je zablokovane, kym CMR nie je nahrate.
Compliance
P1
LOG-006
Logisticky modul musi vytvorit priestor na evidenciu skladovneho.
Akcept.: Ku karte alebo logistickemu procesu je mozne evidovat relevantne skladovacie informacie.
Skladovne
P2
11.Integrovany kalendar3/5
KAL-001
System musi obsahovat centralizovany kalendar prepojeny s databazou vozidiel a CRM.
Akcept.: Kalendar zobrazuje logisticke aj obchodne udalosti.
Kalendar
P1
KAL-002
Kalendar musi zobrazovat planovane nakladky a dodania.
Akcept.: Udalosti su zobrazene vo forme timeline alebo Gantt pohladu.
Logistika
P1
KAL-003
Kalendar musi podporovat meetingy s dodavatelmi a klientmi.
Akcept.: Meetingy su priradene ku konkretnym pouzivatelom a CRM zaznamom.
CRM
P2
KAL-004
Kalendar musi upozornovat na expiracie registracii a poisteni.
Akcept.: Back-office dostane upozornenie pred bliziacou sa expiráciou.
Notifikacie
P1
KAL-005
Notifikacie musia podporit vcasnu deregistraciu vozidiel.
Akcept.: Pouzivatel vidi vozidla vyzadujuce akciu pred expiráciou.
Deregistracia
P2
12.Business Intelligence a reporty7/7
BI-001
System musi generovat dynamicke reporty s filtrovanim.
Akcept.: Reporty je mozne filtrovat podla datumu, entity a pouzivatela.
Reporty
P1
BI-002
System musi generovat report predanych vozidiel.
Akcept.: Report obsahuje pocet a zoznam vozidiel v stave Objednane/Potvrdene, objem predaja a ocakavanu marzu.
Sales performance
P1
BI-003
System musi generovat report dodanych vozidiel.
Akcept.: Report obsahuje vozidla so statusom Delivered za vybrane obdobie.
Logistics performance
P1
BI-004
Report dodanych vozidiel musi sluzit ako podklad pre uznanie uzavreteho zisku a fakturaciu.
Akcept.: Delivered vozidla su pouzitelne v konecnych financnych reportoch.
Zisk a fakturacia
P2
BI-005
System musi generovat individualny vykonnostny report pouzivatela.
Akcept.: Report zobrazuje pocet obchodov, obrat, vytvorenu marzu a plnenie planov.
User report
P1
BI-006
Management musi vidiet porovnanie vykonnosti vsetkych pouzivatelov.
Akcept.: Manazerska rola vidi agregovane aj porovnavacie reporty.
Manazersky pohlad
P1
BI-007
Celofiremne reporty musia mat moznost odfiltrovat intercompany fakturaciu.
Akcept.: Reporty odzrkadluju realny trhovy vykon bez dvojiteho zapocitavania.
Intercompany reporting
P1
13.Zivotny cyklus vozidla a workflow statusy11/14
WF-001
System musi podporovat status Vo vyhlade / V analyze.
Akcept.: Vozidlo alebo dopyt moze zacat v uvodnom analytickom stave.
Status
P0
WF-002
Obchodnik musi vediet vytvorit a odoslat ponuku cez multi-select.
Akcept.: Po odoslani sa status zmeni na Ponuka odoslana klientovi.
Ponuka
P0
WF-003
Odoslana ponuka musi byt zapisatelna do predpovede cashflow.
Akcept.: Ponuka vytvori ocakavany obchodny vstup pre forecast.
Cashflow
P2
WF-004
Po potvrdeni klientom musi system vygenerovat klientsku zalohovu fakturu.
Akcept.: Status prejde na Potvrdene / Generovana KZ a Zalohova FA.
Potvrdenie
P0
WF-005
Bankove API musi sparovat prichadzajucu zalohu od klienta.
Akcept.: Po 100 % sparovani sa status zmeni na Zaloha od klienta prijata.
Platba zalohy
P0
WF-006
Po prijati zalohy musi system spustit pokyn na uhradu zalohy dodavatelovi.
Akcept.: Po uhrade sa status zmeni na Objednane u dodavatela.
Dodavatel
P1
WF-007
Import od vyrobcu musi doplnit VIN a KW vyroby.
Akcept.: Status prejde na Vo vyrobe / Pipe a udaje su zapisane do kalendara a cashflow.
Vyroba
P1
WF-008
Po ukonceni vyroby musi system vygenerovat klientsku doplatkovu fakturu.
Akcept.: Status prejde na Na sklade dodavatela / Vygenerovany doplatok.
Doplatok
P0
WF-009
Po sparovani 100 % platby od klienta musi system odomknut logistiku.
Akcept.: Status prejde na Schvalene na nakladku.
Odomknutie logistiky
P0
WF-010
Logista musi vediet naplanovat trasu a prepravu.
Akcept.: Status prejde na V preprave a terminy su zobrazené v kalendari.
Preprava
P0
WF-011
Nahratie podpisaneho CMR musi zmenit status na Dorucene / Delivered.
Akcept.: Vozidlo sa automaticky zapise do reportu dodanych aut.
Doručenie
P0
WF-012
Po doruceni musi prebehnut audit dokumentov TP/COC a kontrola entity voci VIN.
Akcept.: System umozni evidovat vysledok kontroly dokladov.
Kontrola dokladov
P1
WF-013
System musi vytvorit report pre Back-Office na fyzicku expediciu dokladov kurierom.
Akcept.: Back-office vidi zoznam dokladov pripravenych na odoslanie.
Expedicia dokladov
P2
WF-014
Po fakturacii musi vozidlo prejst do stavu Vyfakturovane / Uzatvorene.
Akcept.: Obchod je zapisany do konecnych financnych a user reportov holdingu.
Uzavretie
P0
14.Otvorene body na dopresnenie0/5
OPEN-001
Definovat presny rozsah wishlist udajov pri klientovi.
Akcept.: Spisat povinne a volitelne polia pre klientsky wishlist.
CRM
P1
OPEN-002
Vybrat bankove API alebo sposob importu bankovych vypisov pre prototyp.
Akcept.: Rozhodnut, ci prototyp pouzije realne API, CSV import alebo mock data.
Bank API
P0
OPEN-003
Dopresnit fakturacny engine a integracie pre SK/CZ legislativu.
Akcept.: Rozhodnut, ci prototyp bude generovat realne faktury alebo iba evidencne doklady.
Fakturacia
P0
OPEN-004
Definovat dizajn a datovy rozsah PDF/obrazkovej ponuky.
Akcept.: Pripravit sablonu klientovej ponuky.
Exporty
P1
OPEN-005
Definovat vzorce pre plan, uspešnost a marzu v user reportoch.
Akcept.: Schvalit KPI metriky pre obchodnikov a nakupcov.
Reporty
P1