Možno tam ani žiadny nie je.
Vyskúšaj niečo rozumné napr.1 za sekundu a uvidíš. 
-)
… prípadne sa to zrúbe.
Čo som to skúšal, tak tam bol tuším limit 60 requestov a potom ma to vyplo. Netuším za aký čas je možné spraviť viac.
no vazeni, ban rate je uplne na 3.14cu - raz to ide napriklad 30 requestov na supu, potom to zabanuje na neviem kolko, potom spravi iba 5 a uz je to v pipke, nepomoze ani sekundovy sleep(1)… no idem skumat ci to nahodou nevie aj nejaky multi-kod v jednom requeste spravit… fakt nechapem jak toto mohol dakto spravit a neuvolnit API… 
Len tak na príklad.
Využívam https://www.minv.sk/?stratene-a-odcudzene-doklady na automatizovanú kontrolu dát. Nechcú urobiť formulár na zadanie viacerých dokladov, ani nechcú publikovať súbor na stiahnutie ako v ČR.
Robím cez sleep(1), cez deň priebežne ako sa pracuje s konkrétnymi zákazníkmi, v noci cez pracovné dni väčšia kontrola limitujem do 1000 dokladov a cez víkend pustím kontrolu na 10 000 dokladov, tak aby som každé 2 týždne mal prekontrolované všetky doklady aj neaktívnych zákazníkov.
Ručne by to pracovník nerobil a tak ho program automaticky upozorní, že má zvýšiť pozornosť, lebo pracuje so zákazníkom kde má stratený/odcudzený doklad.
Zatiaľ som ban nedostal
Tak som si konecne precital dump pola co pride ked to nejde overit davkovo…
array (size=3)
‘returnValue’ => int -1
‘errorCode’ => string ‘-39’ (length=3)
‘errorDescription’ => string 'Overovanie dokladu je pre Vás momentálne zablokované. Akciu opakujte neskôr prosím. ’ (length=89)
- takze ako pozeram na returnValue - je teraz -1 oproti normalnemu 0
- otazka je, ked dam rutinu na check dokola ci uz nevracia -1, ci sa nebudem BAN-ovat donekonecna…
- ak ano som zvedavy ako si s tym poradi kaskadove predlzovanie casov na re-check (napr. ak nejde tak pridaj pause(60), ak nejde 2x tak 120, 240, 480 - len potom si asi musim nejaku notifikaciu spravit, ze uz mam 1000 blockov preskenovanych…
- asi bude rychlejsie ist cez VPN a dynamicky menit pred kazdym requestom IP adresu
sak co uz s blbym systemom… kua len sa to komplikuje…
zatial som si spravil IF takze ak je -1 aspom mi nehadze errory a len vypise, ze je to zabanovane, nech skusim neskor
…dlhodobo (vuz asi rok o pol) sa snazime viest dialog a presadit na FS SR vylepsenie eKasy…napr. otvorenim API na blocky a umoznenim certifikacie sw riesenia eKasy + dalsie ine odporucania pre zlepsie denno-denneho pouzivania…tu pre info publikujem poslednu diskusiu s FS SR v tychto temach…verim, ze diskusia bude pokracovat v konstruktivnej rovine a podari sa postupne system eKasy pootvarat a vylepsit…
Reakcia FS SR:
Dobrý deň pán Kulich,
dovoľte mi najskôr sa Vám ospravedlniť sa za meškajúcu odpoveď, ktorá bola spôsobená náporom na komunikáciu v ostatných dňoch spôsobeným medializovaným aktuálnym dianím ako aj personálnou výmenou na poste hovorcu FS, ktorá s Vami doteraz komunikovala. Mrzí ma vzniknutá situácia, komunikácia na FS je však už zabezpečená aj v podobe novej hovorkyne, ktorú dávam do kópie tohto mailu.
K diskutovanej záležitosti si dovoľujeme uviesť, že po viacerých diskusiách a prevereniach musíme konštatovať, že sprístupnenie Open API nebude jednoduché a bude potrebná súčinnosť aj iných orgánov štátnej správy, najmä MIRRI a Úradu na ochranu osobných údajov.
Finančná správa po konzultáciách eviduje nasledovné problematické oblasti, ktoré vyplývajú z platnej legislatívy:
-
problémom je ochrana osobných údajov podľa GDPR. Podľa stanoviska našej bezpečnosti je problém, ak v názve živnosti je meno a priezvisko, čo môže byť považované za osobný údaj. Toto stanovisko uvádzame nižšie a opiera sa o vyjadrenie Úradu na ochranu osobných údajov, na ktoré je tam tiež odkaz. Podľa diskusie s Oddelením bezpečnosti by sme toto stanovisko vedeli zmeniť iba vtedy, ak by nám Úrad dal jasné stanovisko, že názov živnosti (s menom a priezviskom živnostníka) zverejňovať v našej službe môžeme. Určite by pomohla Vaša súčinnosť a prípadná komunikácia aj z Vašej pozície s Úradom na ochranu osobných údajov -
účel poskytnutia údajov o pokladničnom doklade – zákon o eKase definuje účel služby overenia pokladničného dokladu veľmi striktne, čo je v rozpore s požiadavkami, ktoré majú ostatní potenciálni konzumenti nasej služby -
evidujeme aj obavu zo zásadného zvýšenia počtu dotazov a neadekvátneho zvýšenia záťaže na infraštruktúru eKasy
Finančná správa zadefinovala aj možnosti riešenia:
· novela zákona o eKase – s dvoma zmenami, ktoré by reflektovali Vaše požiadavky
o rozšíril by sa účel služby na overenie pokladničného dokladu
o vyriešila by sa aj možnosť poskytovania SW eKasy (dnes len vo forme VRP poskytovanej zo strany FS)
· úprava rozhrania eKasy tak, aby neposkytovala kompletné údaje ako dnes, ale oklieštené údaje tak, aby to vyhovovalo všetkým, potenciálne vo forme samostatného komponentu, ktorý by nemal vplyv na ostatné časti eKasy
O novele zákona o eKase sa už interne na finančnej správe diskutovalo, pričom je nevyhnutné si uvedomiť, že aj legislatívny proces má svoje trvanie. Úprimne treba tiež povedať, že finančná správa má momentálne pred sebou enormné výzvy, ktoré majú celospoločenský dopad. Svoje kapacity momentálne sústredí na povinnosti a úlohy, ktoré jej vyplývajú zo skončenia prechodného obdobia po Brexit-e, zabezpečenia ICS2 a najmä zavedenia celoeurópskeho projektu povinného preclievania všetkých zásielok z tretích krajín eCommerce. Aj z toho je zrejmé, že finančná správa do týchto projektov investuje okrem personálnych aj finančné kapacity, z čoho vyplýva, že na úpravu rozhrania eKasy nedisponuje potrebnými finančnými prostriedkami.
Vzhľadom na vyššie uvedené by sme v záujme dosiahnutia tohto cieľa privítali, keby ste zo svojej pozície pomohli presadiť zakomponovanie požiadaviek do niektorej z aktuálnych výziev napr. MIRRI, pre ktoré sú dáta jednou z aktuálnych priorít. Tým by tieto požiadavky získali na priorite pri ich riešení ale pomohli by vyriešiť aj problém s financovaním ich realizácie.
stanovisko Oddelenia bezpečnosti:
Podľa názoru Oddelenia bezpečnosti nasledovné údaje uvedené v časti 1. ods. 1.2 predmetného zápisu (Návrh údajov na sprístupnenie:) - IČO, DIČ, IČ DPH (ak podnikateľ je platiteľom DPH) a prípadne „ďalšie údaje, ktorých uvedenie vyplýva z osobitného predpisu“, ktoré k dnešnému dňu nie sú Oddeleniu bezpečnosti známe - je možné označiť ako osobné údaje v súlade s ustanovením článku 4 ods. 1 Nariadenia GDPR, za podmienky, že boli pridelené fyzickej osobe oprávnenej na podnikanie, nakoľko za predpokladu, že tretie strany, ako príjemcovia týchto údajov, budú mať k dispozícii „kľúč“, resp. informáciu, na základe ktorej by mohli konkrétny údaj, ako unikátny identifikátor predajcu uvedeného na pokladničnom doklade, priradiť k identite konkrétnej dotknutej (fyzickej) osoby (napr. ŽIVNOSTENSKà REGISTER SLOVENSKEJ REPUBLIKY alebo VIES ), budú tretie strany môcť konkrétnu dotknutú osobu jednoznačne identifikovať, resp. dotknutá osoba, ako predávajúci, bude podľa na pokladničnom doklade uvedeného unikátneho identifikátora zo strany tretích strán, ako príjemcov týchto údajov, v zmysle ustanovenia článku 4 ods. 1 Nariadenia GDPR identifikovateľná.
Podľa článku 4 ods. 1 Nariadenia GDPR, na účely tohto nariadenia „osobné údaje“ sú akékoľvek informácie týkajúce sa identifikovanej alebo identifikovateľnej fyzickej osoby (ďalej len „dotknutá osoba“); identifikovateľná fyzická osoba je osoba, ktorú možno identifikovať priamo alebo nepriamo, najmä odkazom na identifikátor, ako je meno, identifikačné číslo, lokalizačné údaje, online identifikátor, alebo odkazom na jeden či viaceré prvky, ktoré sú špecifické pre fyzickú, fyziologickú, genetickú, mentálnu, ekonomickú, kultúrnu alebo sociálnu identitu tejto fyzickej osoby.
Zároveň v súvislosti s údajmi fyzických osôb oprávnených na podnikanie, ktoré FR SR v IS e-Kasa spracúva, dávame do pozornosti skutočnosť, že podľa metodiky Úradu na ochranu osobných údajov Slovenskej republiky:
„Úrad v predmetnej otázke rešpektuje judikatúru Európskeho súdu pre ľudské práva a Súdneho dvora Európskej únie, ktoré sa prikláňajú k širokému výkladu pojmu práva na súkromie, pod ktoré možno subsumovať tiež ochranu osobných údajov vzťahujúcich sa na živnosť či slobodné povolanie. Je nepochybné, že aj informácie o fyzických osobách – podnikateľoch môžu z hľadiska ich vecného obsahu zodpovedať definícii osobného údaju. Dotknutou osobou tak môže byť aj fyzická osoba – podnikateľ, nakoľko nie je vylúčené, že by mohlo dôjsť k narušeniu jeho súkromia a ochrany osobných údajov. V nadväznosti na uvedené je úrad toho názoru, že aj pri výkone povolania má každý právo na primeranú ochranu súkromia, ktoré zahŕňa tiež ochranu osobných údajov. Aj s ohľadom na úzku previazanosť súkromného a profesijného života fyzických osôb – podnikateľov, pri spracúvaní údajov o nich môže dôjsť k identifikácii fyzickej osoby, ktorá bude identifikovaná na základe znakov, tvoriacich výkon činnosti fyzickej osoby - podnikateľa.“
a
„Ak v členskom štáte fyzická osoba vykonáva ekonomické činnosti, ale podľa vnútroštátneho práva členského štátu nie je považovaná za právnickú osobu, potom by táto osoba mala mať priznanú ochranu podľa Nariadenia“ (GDPR).
Reakcia SD:
Dobry den,
dakujem za reakciu. Az teraz som sa dostal k danej veci, tak konecne reagujem.
Dakujem za priblizenie pohladu FS SR a aj za navrh rieseni. Ale este predtym by sme radi prediskutovali jeden nas pohlad.
FS SR poskytuje na overenie si pravosti, korektnosti dokladu sluzbu (predpokladam, ze to je aj ucel danej sluzby) OPD Po zadani ID dokladu (ten sa nachadza aj v QR kode) pouzivatel, t.j. fyzicka osoba, ktora ma v ruke blocek vidi na webe FS SR udaje z blocku, aby si potvrdila jeho pravost, napr. uctovnik pred zaradenim blocku do uctovnictva. API poskytuje rovnaku sadu udajov ako overenie cez webove rozhranie vid eKasa: pridať využitie aj pre občanov - #9 by jsuchal
Otazka teda znie, ze ak je ucel pouzitia API rovnaky ako pri webovom rozhrani, tak preco ho nie je mozne z pohladu bezpecnosti a GDPR pouzivat rovnako ako webove rozhranie? Napr uctovnik si oskenuje QR kod a takto sa mu do uctovnictva dostanu udaje z blockov v strukturovanej podobe.
Radi by sme sa informovali, ci stanovisko odboru bezpecnosti je odvodene od usmerneni Uradu na ochranu osobnych udajov alebo bol tento problem zo strany FS SR s Uradom na ochranu osobnych udajov komunikovany priamo a komplexne (webove rozhranie, API, ucely pouzitia)? V pripade, ze bol, mohli by ste nam poskytnut stanovisko Uradu a aj kontaktne osoby za Urad k tejto veci?
Sme nazoru, ze navrhovane moznosti rozsirenia vyuzivania systemu eKasa:
-
otvorenie API na blocky
-
umoznenie certifikacie aj sw rieseni eKasa
by mali mat ziadny, pripadne minimalny dopad na financne naklady FS SR, nakolko ide uz o existujuce sluzby, funkcionality a procesy.
Dovolim si pripomenut, ze ako Slovensko.Digital uz od spustenia systemu eKasa do prevadzky apelujeme na FS SR, aby na zaklade spatnej vazby od pouzivatelov rozsirovala a vylepsovala funkcnost systemu. Spolu s najvacsimi vyrobcami sw pre uctovnictvo, skladove hospodarstvo sme spisali a Fs SR poskytli viacero odporucani, ktore by pouzivatelia ocenili pri denno-dennej praci.
Osobne si myslim, ze cielom FS SR by malo byt, aby system eKasy bol vyuzivany “externymi pouzivatelmi” v co najvacsej miere, nakolko vedlajsim efektom je validacia blockov a zvysovanie % uspesnosti kontrol a teda znizovanie nakladov na potrebne kontroly zo strany FS SR.
Vopred dakujem za reakciu
Myslim, ze poznat pohlady jednotlivych stran diskusiu posuva konstruktivne dopredu.
Peter Kulich
4 Likes
Ak sa uvazuje aj o zmene zakona, mozno by bolo dobre urobit urcite obdobie na zmenu nazvov firiem zivnostnikov.
Teraz ked uz je v platnosti GDPR by si mal zivnostnik uvedomit, ze ked si da svoje meno do nazvu firmy, ze vlastne zverejnuje svoje osobne udaje. Cize ak to urobi vedome asi je v poriadku ak sa jeho meno bude pouzivat aj pre horeuvedene ucely. Cize mal by mat moznost vyberu ci chce aby sa dal ako osoba identifikovat cez nazov svojej firmy, alebo si nazov zmeni. Nemalo by to byt podla mna tak, ze sa jeho zakaznik nedopracuje k nemu, lebo nejaka sluzba to nemoze urobit koli GDPR.
Ci by nebolo vhodne urobit nejaku prechodnu dobu v ktorej by mali moznost zivnostnici si zmenit nazov a ak tak neurobia bude pouzivany ako nazov firmy obsahujuci ich meno.
Je fakt ze napriklad zrsr.sk zverejnuje aj udaje s menom zivnostnika ico aj adresu, ale je tam aj vela firiem ktore maju nazov este z doby pred GDPR a takato moznost by sa mozno hodila.
Súhlas. Podobný “problem” je ked opravnene osoby davaju nazvy klienotv do nazvov suborov a potom z toho robia zaručene konverzie. Názvuy súborov sa samozrejme objavia v EZZK registri a daju sa vyhľadať.
Možno systémovejšie riešenie by bolo, keby UOOU vyšiel zo svojej komfortnej zóny, prestal alibisticky označovať za možný problém takéto veci a vydal JASNÉ stanovisko že názov firmy, názov živnosti a názvy súborov nikdy nebudú spadať pod ochranu osobných údajov. Ak sa s tým spriahne aj nejaké obdobie na zmenu názvov pre tých čo to chcú, vnímal by som to ako veľký prínos. Ináč sa nepohneme kvôli alibizmu úradníkov.
1 Like
Ak na papierovom bločku môžem vidieť meno živnostníka a na elektronickom bločku už nie lebo je to osobný údaj, aký je problém pri živnostníkoch cez api zobraziť len IČO bez názvu firmy a u právnických aj názov firmy?
Potom si už podľa IČO pohľadám kde som nakupoval cez zrsr.sk
Živnostník musí mať v názve firmy Meno a Priezvisko.
Obchodným menom fyzickej osoby je jej meno a priezvisko (ďalej len „meno“). Obchodné meno fyzickej osoby môže obsahovať dodatok odlišujúci osobu podnikateľa alebo druh podnikania.
https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/1991/513/20201001#paragraf-9.odsek-1
evidujeme aj obavu zo zásadného zvýšenia počtu dotazov a neadekvátneho zvýšenia záťaže na infraštruktúru eKasy
Ak sa boja preťaženia, API na zobrazovanie bločkov by nemuselo byť online, stačilo by ak dáta budú pravidelne automaticky kopírovať na iný server.
Podobne funguje aj register adries tu sú dáta online https://portal.minv.sk/wps/portal/domov/com.ness.ra/com.ness.ra_/ a na data.gov.sk sú na tretí deň.
1 Like
Problem je v tom ze zakony su v tejto otazke trochu v rozpore. Jeden nariadi ze musis do mena firmy dat svoje meno a druhy ktory prisiel “zhora” hovori ze osobny udaj je vsetko pomocou coho sa da identifikovat konkretny clovek. Cize bezne nepotrebujeme identifikovat cloveka ale skorej firmu s ktorou mame obchodny styk. Preto by mozno bolo dobre dat moznost vymenit obchodne mena za ine take ktore na prvy pohlad neidentifikuju konkretnu osobu.
Lebo ako tu pise Robert problem potom vznika napriklad v tom ze pri pripadnej kontrole musim hladat argumenty preco mam v menach suborov mena osob a napr. obec (niekedy tieto dva udaje stacia na urcenie konkretneho cloveka. Nieco ine je napr. mena zamestnancov a ine je mena obchodnych partnerov ktori maju meno v obchodnom nazve). Cize ak ma byt meno sucastou obchodneho nazvu nespravat sa k nemu (nie len tam kde je registovany ale aj vsade tam kde ho ktokolvek pouziva) ako k osobnemu udaju a v zakone to vyslovne uviest, alebo urobit premenovanie tychto obchodnych nazvov tak aby neobsahovali udaj identifikujuci osobu. Aby potom nasledne nevznikali komplikacie tohoto typu v spolocnostiach ktore taketo udaje vytvaraju a v spolocnostiach ktore tieto udaje od nich pouzivaju a ukladaju.
1 Like
potrebné si je uvedimiť, že žiadna firma v prípade živnostníkov nie je. To, že niekto si pridá k svojmu menu a priezvisku prílepok napr. “Maľovanie bytov”, nerobí z neho firmu.
Ak sa niekto rozhodne podnikať ako živnostník, musí strpieť publikovanie svojho mena.
v tom pripade to je potom reklama 
a nie problem s osobnými údajmi. Už by sa tá hystéria okolo GDPR mala zreálniť.
1 Like
To je naopak iba to ostatne okrem mena je dobrovolne. On si svoje meno nepridava lebo ako aj @Val uvadza:
Cele vyjadrenie UOOU je - musim napisat, ze nanestastie je to uz aj pravidlom - totalne alibisticke a tu navyse este aj uplne absurdne, lebo:
- Ak mam zaujem o osobne udaje uplne vsetkych zivnostnikov, tak si otvorim ZRSR, register uctovnych zavierok, RPO… a mam. Nebudem sa babrat s nejakymi blockami.
- Ten blocek mam po kupe fyzicky v ruke, cez GUI overovania blockov sa nedostanem k ziadnym dalsim udajom, iba k tomu, co je na tom papieriku napisane. Vyda teraz stanovisko UOOU, ze na blockoch tiez nesmie byt osobny udaj zivnostnikov? A samozrejme ani ICO, lebo cez verejny register ZRSR si tie dalsie zverejnene osobne udaje najde hocikto.
- Ano, API je novy “kanal” kade sa potencialny utocnik moze dostat aj k inym blockom a teda osobnym udajom avsak:
- tie kody blockov nevyzeraju, ze by sa zrovna dali nejako lahko enumerovat.
- je tam rate limiter, ktory je sice na IP adresu, ale vyrazne limituje sancu nejakych brute-force utokov.
- To GUI na blocky dnes uz existuje, je v prevadzke. Tu to nikomu doteraz nevadilo, ze tam mozu byt osobne udaje zivnostnikov? eKasa sa pustala bez posudenia bezpecnosti? To snad nie…
- UOOU je uz dlhodobo v totalne nekonstruktivnej pozicii “povedzte nam ako to robite a my vam ukazeme preco to robit nesmiete”. Takto uz som ich zazil pri teme “moje data” a to je nieco neuveritelne.
Zatial mam dojem, ze novi ludia na FS tuto absurdnu situaciu chapu, ale maju na stole taketo stanovisko od UOOU a nechcu zobrat na triko, ze by isli proti ich stanovisku len tak.
PS. Som ochotny sa stavit, ze zataz, ktora by sa otvorenim takehoto API sposobila bude taka mala, ze to nestoji ani za akukolvek diskusiu. Kedze si vsak vedia limitovat requesty uplne ako len chcu, tak toto mi pride uz len taky folklor.
3 Likes
Ochrana udajov musi platit rovnako pre papierove vypisy ci elektronicke API, teda to co nemozte ziskat na papieri, nemozte ziskat ani elektronicky a naopak, Elektronizacia nezavadza novy problem v oblasti OOU, samozrejme elektronickych poziadaviek moze byt nasobne viac a niektore pozidavky na spristupnenie na papieri nemaju zmysel, ale princip ochrany musi byt rovnaky. Zverjenovanie/spristupnovanie blockov nie je jednoducha tema (stanovisko FS povazujem za korektne).
Predsa uloha uradu (moze robit len to na co bol urad zalozeny a co mu zakon prikazuje) je ochrana udajov a nie ako ich spristupnovat, na to su ine urady ktore ich chcu resp. maju poskytovat. Takze tie musia povedat ako sa to da urobit a pritom dodrzat ochranu OU (napr. to by mohla byt parketa MIRRI kde by radili inym, ktori ich maju poskytovat), ale nedavajte to za vinu uradu (on nerobi ani zakony a nema ani spristupnovat udaje, ale ma dbat na dodrziavanie zakonnosti v oblasti OU)
Toto je chybná logika. Úrad (v tomto prípade FSSR) zbiera údaje za naše peniaze. My, občania, ho financujeme.
Jednou z povinností úradu je poskytovať informácie (či už na základe zákona o slobodnom prístupe k informáciám alebo iných zákonov, napr. s informatizáciou súvisiacich).
Kde je vôľa, tak tam je cesta.
Hovoril som o Urade na ochranu osobnych udajov (na neho boli staznosti), Len tak na okraj FS vybera v prvom rade peniaze do statneho rozpoctu (jej ucel nie je zbierat udaje a uz voibec nie za Vase peniaze) , predstavuje to viac ako 3/4 prijmov statu
najlepsie je, ze sa tu ohanaju vsetky urady nejakou ochranou udajov - a ked si spomeniem ako ma 3 roky buzerovali zo statistickeho uradu ze komplet vykazy im musela uctovnicka posielat (co ma stalo navyse peniaze) - a potom si najdem svoju firmu vystavenu na internete jak taku tacku plnu penazi kde si vypalnici mozu rovno precitat aky som mal zisk = kludne pride panko s 9mm do kanclu a povie - sak mate pekne zisky - budete nam davat niekolko tisic rocne a vase deti budu zdrave… jako cim sa tu ti uradnici ohanaju ???
tu to proste vyzera na pravidlo, ze kto nechce hlada dovody ale kto chce hlada sposoby…
jako fakt nevidim inu oblast kde tieto udaje pouzit, ako miniappky pre ludi, co si chcu robit domace financie zodpovedne…
ale z ineho sudka.
preco by napriklad nemohli napisat konecne zakon, ktory by obchodom prikazoval uploadovat na dennej baze ich ceny komodit aj s poctom kusov rano na sklade (predajni) - s tym by sa uz dalo zacat budovat krasnu aplikaciu pre nakupovanie s planovanim cesty… ved pocitac so skladom im musi bezat nonstop, taky upload a synchro databazy fakt nemoze byt az tak narocny - o com sa tu pre boha bavime sak mame procesory a disky co zvladnu X krat viac ako pocitace pred rokom ci dvoma… proste to len treba raz dobre napisat…
a nemyslim ze by to neprispelo ku konkurencnemu boju - prave naopak.
jasne ze pristup by mohol byt aj plateny - ale sak zase preco ? ved je to z nasich dani, za nase by sa to postavilo…
a myslim ze nejaka centralna databaza by bola fakt super - ved co viac nasere cloveka, co si pise cely tyzden zoznam na velky nakup - potom to ide kupit a ked je potom dakde v druhom obchode tak ho ide picnut z toho, ze tam to kupil o 20% drahsie, lebo od toho dna vydal ten druhy obchod akciu - ako krasne by sa to ukazalo ked by appka zmenila dynamicky podla “re-check prices” co si kde mam kupit ?
tu vidim ozaj velky potencial a hlavne - konecne usetrit bez nejakeho velkeho investovania casu vlastneho. jako sak niesme dochodci co maju cas si vytahovat udaje z blockov a kukat do letakov…
keby na to vsetci presli povinne, a dali by do placu aj nejake rozumne API - co viac by sme chceli ?
jasne ze uniformna vizaz nazvov produktov, nech sa v tom da vyhladavat poriadne, poriesit diakritiku, ziadne kratenie nazvov, a ine “normalne” veci… ale ved to by stacilo iba raz napisat a v podstate by trval “akozedlho” iba prvy INSERT… no a samozrejme nejaka kategorizacia rozumna - potraviny, drogeria, a pod. aspom na hrube odfiltrovania kde sa nechce clovek pohybovat…
troska som sa rozpisal… ale clovek nikdy nevie…
Tie udaje su dnes zverejnovane, nikto od nich nechce nic nove zverejnovat, len aby tam dali mensi rate limit na to API a oficialne to povolili pouzivat cez API.
3 Likes