eKasa: pridať využitie aj pre občanov

Jasne. Lenze aj toto sa da robit uplne formalne alebo konstruktivne. Taky finstat by mohol napisat knihu o tom, ako sa sprava urad, ze @Ivet_Fercikova?

zdravim, maly update…v tejto teme sme v komunikacii s FS SR…FS SR oslovilo Urad na ochranu osobnych udajov a hladaju systematove riesenie…myslim si, ze to je na dobrej ceste

2 Likes

@peter_k , mas nejaky update k tomuto?

Tiez by ma zaujimalo, ci sa s “oficialitou” nejak pohlo. Osobne udaje tam nie su?

1 Like

ide to pomaly

FS SR oslovila UOOU o stanovisko…FS SR ide menit legislativu k tomu…cez 211tku sme si vypytali to stanovisko, lebo si nemyslime, ze zmena legislativy je koncepcne riesenie pre kazde otvorenie API
List č. 00190-2021-Op-4 zo dňa 25.5.2021 (1).pdf (651.3 KB)
Odpoveď Finančného riaditeľstva SR - 7.7.2021 (1).pdf (223.9 KB)

Ja si k tomu listu ÚOOÚ konkrétne myslím toto (aj som to dal FS vedieť):

  1. ÚOOÚ konštatuje, že služba “online overovanie pokladničných dokladov tretími stranami” je v súčasnosti prevádzkovaným spôsobom zákonom povolená.

  2. Konštatovanie ÚOOÚ, že sa rozšírením služby “mení zdroj údajov” je evidentne nedorozumenie, keďže už v súčasnej dobe je služba poskytovaná v GUI forme, kde zdrojom údajov pre jej používateľov je FSSR, o čom ÚOOÚ konštatuje že je zákonom povolené, pri API forme to bude rovnako.

  3. ÚOOÚ správne konštatuje, že dôjde k zmene formy poskytovania služby z GUI na API. Tento rozdiel však nemôže znamenať rozdielnu úroveň ochrany práv FO, ako priamo určuje rec.15 GDPR: “…by mala byť ochrana fyzických osôb technologicky neutrálna a nemala by závisieť od použitých technologických riešení…”. Jediný rozdiel doterajšieho “iba GUI” a zamýšľaného “GUI aj API” prístupu je potenciál automatizovaného spracovania u používateľov služby, ktorý sa zavedením API formy zvyšuje. FSSR už v súčasnosti všetky údaje pre túto službu spracúva automatizovane aj pri GUI forme.

  4. Z bodu 2 vyplýva, že parametre služby uvedené vo všeobecne platných právnych predpisoch (najmä zákon), musia byť rovnaké, bez ohľadu na formu spracovania. Ak sú tieto pravidlá v súčasnosti dostatočné, nevyhnutne ich treba vztiahnuť aj na API formu a doriešiť je potrebné “potenciálne automatizované spracovanie”. Naopak, ak by súčasné pravidlá neboli dostatočné pre API formu (okrem automatizovaného spracovania), nemohlo by FS poskytovať v súčasnosti ani GUI formu - čo však nie je pravda, špecificky ÚOOÚ potvrdzuje, že súčasné spracovanie je v poriadku.

  5. Špecificky bez ohľadu na GUI/API formu zostávajú rovnaké: právny základ, oprávnený prevádzkovatelia, rozsah spracúvaných údajov, povolené spracovateľské operácie, informačná povinnosť, práva DO.

  6. FSSR, aj používatelia služby, by mali v dokumentácii súladu služby s GDPR (bez ohľadu na formu) konkretizovať veci podľa bodu 5. (A verím že už to majú spravené.)

  7. V súvislosti s potenciálnym automatizovaným spracovaním osobných údajov využitím služby v API forme je potrebné u používateľov služby podľa GDPR riešiť: rec.67: a) zabrániť iným ako povoleným spracovateľským operáciám, b) zabrániť zmene údajov, c) označiť, že spracúvanie údajov je obmedzené, rec.71 a čl.22: d) profilovanie dotknutej osoby, e) rozhodnutia založené výlučne na automatizovanom spracúvaní údajov, čl.20: f) ak pokladničné bloky obsahujú osobné údaje získané na základe súhlasu DO právo na prenos údajov, čl.35.3.a GDPR: g) riešiť automatizované spracovanie v posúdení vplyvu.

  8. Za realizáciu týchto povinností nezodpovedá FSSR, ale používateľ služby, FSSR im však vie napomôcť vhodnými technickými a organizačnými opatreniami.

  9. Na podporu výkonu požiadaviek podľa bodu 7 by FSSR malo v podmienkach používania služby určiť pre používateľa aj: zákaz vykonávať iné ako povolené spracovateľské operácie, označenie osobných údajov, zákaz profilovania FO na základe využitia služby, zákaz vytvárať rozhodnutia založené výlučne na automatizovanom spracúvaní údajov služby, upozorniť na práva na prenosu údajov v prípade ak obsahujú údaje získané na základe súhlasu DO, upozorniť na povinnosť riešiť súlad spracúvania údajov s GDPR, vrátane posúdenia vplyvu.

  10. Na podporu výkonu požiadaviek podľa bodu 7 a) a b) prijme FSSR vhodné technické bezpečnostné opatrenia, ktoré neumožnia zmeniť (a zmazať) údaje a vykonávať iné ako povolené funkcie prostredníctvom tejto služby.

  11. Ďalej ÚOOÚ žiada, aby realizácia služby bola v súlade s čl.5 ods.1 písm.c) GDPR (minimalizácia spracúvaných údajov) a čl.25 GDPR (špecificky navrhnutá ochrana). Táto požiadavka sa vzťahuje na službu bez ohľadu na GUI/API formu v akej je poskytovaná.

  12. Požiadavku podľa bodu 5 FSSR nevyhnutne zabezpečí a) analýzou bezpečnosti služby, b) návrhom bezpečnostných parametrov služby s cieľoch chrániť dôvernosť a integritu údajov, c) analyzovaním prípadov použitia služby so zreteľom na minimálny nevyhnutný prístup k osobným údajom zo strany používateľov, d) návrh API podľa bodu c) - tieto veci sa ani nedajú “napísať do zákona”, musia sa riešiť organizačnými a technickými opatreniami FSSR, ako je aj v čl.25 GDPR priamo uvedené.

  13. Do analýzy prípadov použitia FSSR špecificky zahrnie aj funkciu “iba overenie pravosti pokladničného bloku”, kde požiadavkou je, aby informáciou získaná pomocou služby, že pokladničný blok je platný, neboli sprístupňované iné údaje.

Po dôkladnom preštudovaní listu ÚOOÚ je evidentné, že vo vyššie uvedených bodoch 1-13 sú riešené všetky ich požiadavky (a aj ďalšie nad rámec ich listu). Na ich splnenie je nutná kombinácia organizačných a technických opatrení na strane FSSR a používateľov služby (v nich uvedených).

Naopak, nikde nie je indikovaná potreba úpravy súčasných všeobecne platných právnych predpisov - za predpokladu, že dnes existujúca služba poskytovaná forme GUI je poskytovaná legálne, čo však potvrdzuje aj samotné ÚOOÚ.

Stručne povedané: zmena zákona nič nové neprinesie - bude iba duplikovať už existujúce práva a povinnosti, a ničomu nepomôže - uvádzané iné opatrenia bude treba spraviť rovnako.

Ja osobne v tejto situácii “prípravu novely” vnímam ako neúčelné vynakladanie prostriedkov verejnej správy.

1 Like

Tak túto otázku by sme mali vybavenú.

1 Like

Ako si to myslel ?

Ja som bol dodnes v tom, ze predavajuci ( napr. obchodny retazec ) nevie moje osobne udaje (ak mu ich dobrobolne neprezradim cez zlavovu karticku/aplikaciu ). Maximalne tak vie cislo platobnej karty, ale pri plateni v hotovosti nevie ani to. Ustavny sud teraz zatrhol statu (FS) moznost vyzadovat/odkladat si informacie o kupujucom a to aj v pripade, ze ich predavajuci pozna/posiela ich ako sucast blocku.

Tu poziadavku vyzsie som chapal v zmysle “umoznit obcanovi automatizovat stiahnutie obsahu blocku ak pozna jednoznacne ID-cko toho blocku”. Teraz take (asi) API existuje, ale z dovodu nastavenia bezpecnostnych obmedzeni (rate-limit), ho nie je mozne rozumne automatizovat. Mylim sa ?

Narazam na to, ze US rozhodoval aj o casti, ze tam nesmu byt udaje o polozkach nakupu. To zamietol.

Priklad pouzita rozhrania pre pripad OFF-LINE dokladu:

  • pouziva sa v pripade, ked registracna pokladnica v case vytvorenia blocku nemala online pristup na eKasu a vytlacila blocek s QR kodom , ktory neobsahuje idDokladu.

Vtedy qr kod obsahuje tieto informacie:

<Overovací kód podnikateľa (OKP)>:<Kód pokladnice>:<Dátum a čas vyhotovenia>:<Poradové číslo dokladu>:<Celková suma>

Toto odpoveda fieldom formulara v aplikacii over doklad:

Kompletne informacie o doklade sa ziskaju odoslanim POST request-u na:

URI: https://ekasa.financnasprava.sk/mdu/api/v1/opd/receipt/find

JSON Body:
{
“okp”: “<Overovací kód podnikateľa (OKP)>”,
“cashRegisterCode”: “<Kód pokladnice>”,
“issueDateFormatted”: “<Dátum a čas vyhotovenia>”, // format: 19.09.2021 10:19:28
“receiptNumber”: <Poradové číslo dokladu>,
“totalAmount”: <Celková suma>
}

1 Like

v ramci SD sa snazime uz od zaciatku eKasy umoznit aj jej sw podobu

MF SR planuje otvorit zakon a nad touto alternativou uvazuje

na druhej strane ako sme my, su tradicni vyrobcovia pokladnic

stvrtok ma byt k tomut zakonu a teme stretnutie…vstup do stretnutia su postrehy/navrhy vyrovbcov pokladnic
Ďalšie predložené podnety a pripomienky k súčasnému zákonu č.docx (35.4 KB)

Nechapem co tam riesia GDPR, ked sa paragon tlaci cez VRP, zadava sa len suma a cislo faktury. Na zaciatok by toto uplne stacilo. Uz by mal niekto odstavit to evidentne priame prepojenie na vyrobcov ekas.

Chcel som sa opýtať či sa diskusie niekam posunuli, keďže pracujem na študentskom projekte ktorý sa snaží využívať túto API na účtovanie bločkov. ale vzhľadom k tomu že ma to neustále blokuje vyzerá to že sa diskusia nikam nepohla…

funkcny curl

curl -X POST \
https://ekasa.financnasprava.sk/mdu/api/v1/opd/receipt/find \
-H "Content-Type: application/json" \
 -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:105.0) Gecko/20100101 Firefox/105.0' \
 -H 'Accept: */*' \
 -H 'Accept-Language: en-GB,en;q=0.5' \
 -H 'Accept-Encoding: gzip, deflate, br' \
 -H 'Content-Type: application/json' \
 -H 'Cache-Control: no-cache, no-store, must-revalidate' \
 -H 'Pragma: no-cache' \
 -H 'Expires: 0' \
 -H 'X-Authorized: ' \
 -H 'X-Token: ' \
 -H 'X-SesId: ' \
 -H 'X-DevId: ' \
 -H 'Origin: https://reqbin.com' \
 -H 'DNT: 1' \
 -H 'Connection: keep-alive' \
 -H 'Sec-Fetch-Dest: empty' \
 -H 'Sec-Fetch-Mode: cors' \
 -H 'Sec-Fetch-Site: same-site' \
 -H 'Sec-GPC: 1' \
 -H 'TE: trailers' \
-d "{\"receiptId\":\"O-AC6D5656CDC64336AD5656CDC60336E0\"}"

priatelia, ja uz svoje data z nieco malo cez 2000 blockov vyuzivam, ked idem nakupovat…

minule ze “akcia” - dal som si vyhladat tovar a naslo mi ho ze uz som ho kupoval, a dokonca za lepsiu cenu… takze ne ne, nic nebude… :slight_smile: mam to sice ako webappku, ale snad to raz preklopim do Flutteru hned ako sa ho naucim (keby bol cas)… dolezite je ze big data prinasaju kopec vyhod - aj moja myslienka vystavit to na web by nebola tak spatna - sak zas kolkym ludom sa chce skenovat qr-ka a sypat to do systemu nejakeho - a hlavne ked stale mame nejaky BAN-RATE co nevieme aky je… take mnozstvu ludi by to mozno neslo (?) ale bol by to pekny bic na predajcov ked by vedeli ze realne je databaza, z ktorej sa daju porovnavat okamzite ceny toho co ponukaju na regaloch s cenami co boli pripadne kde to maju lacnejsie… ako som ochotny aj bezat vlastny server na to len aby ludia posielali qr-ka ale ozaj az ked to bude trocha uvolnene nerad by som sa blamoval takto verejne :smiley: len preto ze verejna sprava nema nieco uvolnene alebo nejako banuje…

ale je to asi skor o tom ze ci je clovek ochotny si nieco kupit za nejaku cenu, ked vie, ze sa to dalo (da) kupit inde za lepsiu… ci sa mu chce koli tej jednej veci ist inam a minat phm a cas… ale zas ak by sme mali ozaj big data - tak to mnou uz spominane planovanie nakupu priamo v appke so zoznamom obchodov a co v nich kupit - to by bola parada… ale tam by mi dost chybalo previazanie na zive databazy obchodnikov. lebo z uz uskutocnenych nakupov to robit je troska “mimo”.

ale nejaku hodnotu maju urcite aj data za nakupy co sme uz urobili… minimalne na generovanie vykazov co sme a kolko spotrebovali + nejaka kategorizacia… koho to bavi, vie o com pisem… optimalizovat vydaje v buducnosti sa ad len na zaklade dat predoslych nakupov ked vieme “kde sme rozhadzovali” a kolko, aby sme si vedeli povedat “kde utiahnut opasok troska” alebo aj viac…

no sak sem tam sem pozriem ako sa to vyvija, ale s tym statnym molochom sa tazko cosi riesi evidentne…

1 Like

no zabudas na inflaciu :slight_smile: mozno to skutocne na dnesne pomery bola akcia :slight_smile:

Bločky už nemusíte odkladať

Nová práčka, kanvica či topánky na zimu… Ešte si odkladáte bločky, aby ste mohli využiť záruku v prípade problémov? Nič z toho už nie je potrebné keď využijete inovatívnu funkciu v mobilnej aplikácii od ČSOB. Viete si tam totiž ukladať tzv. e-bločky, ktoré sú podľa legislatívy rovnaké ako originál pokladničného bloku.

Stačí jednoducho zoskenovať QR kód z bločku a o zvyšok sa postará aplikácia – zobrazí sa vám informácia o zakúpených výrobkoch, cene, mieste nákupu a ďalšie informácie. Okrem toho vám aplikácia oznámi aj koniec záruky a dokonca si viete pridať aj fotku produktu, ku ktorému bloček patrí.

Vďaka tejto diskusii som si rozbehal Shortcut pre Apple zariadenie, ďakujem. Nemusím riešiť obmedzenia služby ako je BAN, lebo bloček nascanujem rovno ako idem z obchodu a robím to teda priebežne. Najprv som pozeral po službe eblocky.sk, to ma ale nejako nepresvedčilo.

Ak by si to chcel niekto rozbehať, tu je screen shortcutu pre naskenovanie bločku a jeho uloženie

Na to sa dajú nadviazať ďalšie operácie ako pridanie záznamu do súboru, napríklad do Numbers alebo sformátovanie ako prípravu pre ďalšie spracovanie.

2 Likes

Si si istý, že ti toto funguje?
Mne to vracia chybový kód -2 “Zlé vstupné hodnoty.”
Snažím sa z popisu integračného rozhrania nájsť správne hodnoty/data, ale akosi neviem nájsť nič, čo by prechádzalo.