Tak pěkné API na firemní data je zde: https://merk.cz/api-strojovy-pristup/
Uctenky maji cislovane rady. Pokud se vyda provozovne blocek, musi v kopii vratit celou sadu (v ramci vnitrofiremni kontroly). V pripade ze to organizuje majitel, muze ztopit cely blocek a pripadne udelat fake s novym, ale je to cele takove vachrlate.
Pri udani se toto rozkryva pak treba i vyslechy zamestancu a pohybem zbozi a tezko treba tvrdit, ze provozovna ve Svitavach neprodala za 9 dni ani jednu polozku (kdyz by jela na blocky a ten se nepriznal).
Na druhou stranu toto nikdo z kontrolnich pracovniku moc neresi, nestihaji se ani fejkovy faktury nejakych karuselu.
Jinak dvoji verze ucetnictvi se delaly pred 15-20 lety, dlouho jsem nevidel ani naznak tohoto typu problemu. U mensich firem. OSVC si to cele klidne udela nacisto v prosinci z ciste vody, zejmena kdyz dela jenom retail.
Spis je to clovek, ktery nema realny podil na cemkoli, co ma fungovat, pro co je nutna koordinace, vyjednavani, odhad veci pristi, tah na branku, odpovednost a dalsi. Staci treba "stavet garaz", nemusi to byt nic vetsiho.
Budto nekde uci, nebo dela presne danou praci u lisu/pocitace/lince, ani s multikarou nejezdi v nejake metstke sprave zelene, protoze tam si musite zorganizovat praci.
Pripadne chodi do skoly a mamka obcas vola pres dvere co dela, ze ma zamceno.
Chápu to správně tak, že to „kde“ chcete určovat podle umístění mobilu, a to „kolik“ podle doby, jak dlouho je člověk u pokladny? A prosím vás, ta závislost je lineární – že člověk, který platí 1000 Kč, je u pokladny tisíckrát déle, než člověk platící 1 Kč, nebo je to nějaká exponenciála a člověk platící 4999 Kč bude u pokladny o 5 mikrosekund rychlejší, než když někdo platí 5000 Kč?
Ale něco vám musím uznat. Někteří lidé si myslí, jak mají neotřelé nápady, a přitom je na první pohled vidět, jak jsou svázáni tím, co už existuje. To vy ne. Vám člověk doopravdy věří, že jste nikdy žádné placení, peníze, platební kartu ani obchod neviděl.
Statni sprava vam nalije citliva data ktera by mel vlastnit stat do systemu cizi firmy;) Hehe;) Dalsi cloudovy startupovy gelous..
Momentalne delame vyzkum nasazeni AWSka na nejake projekty protoze klaut protoze politicke rozhodnuti. AWSko protoze amici i kdyz jsou lepsi cloudove sluzby.
AWSko zrovna neni etalon high avalability a nechapu proc jsou z toho vsichni tak vydreni. Ocekaval bych ze treba retirement instanci bude bezesvy a bez zasahu za behu se prenese na novy hw. Ocekaval bych plynulou skalovatelnost instanci.
Jako cloveka ktery spravuje obcas systemy na kterych vymenite temer vsechno za behu mne ti u cloudove sluzby irituje. Uz jen to ze se za kazdy prd R&D plati a progrosi si ztezujou.
Kolik umi pameti nejvetsi instance? Jen 256GB. To je strasne malo. 512-1000GB by stacilo.
Pri minulem budget meetingu tak CEO prudil, ze jsme se rozhodli pronajmout si fyzicke zelezo a udelat si privatni cloud jen na research protoze sami si udelame vhodnejsi reseni.
Pokud by se provadela profylaxe prostor tak je riziko se pripravi vic jak tretina republiky o konektivitu vcetne te mezinarodni(ale tam by naskocily zalohy z jinych casti republiky). Nektere veci se proste nedelaji protoze jsou prilis nebezpecne a neni pro to delat duvod. Je to zazita praxe i z jinych firem. Samozrejmne mame prostory kde se uklizi ale kabelarna to neni. Cim vic se kabelem hejbe tim vetsi je riziko ze se zmeni jeho vlastnosti. Tam je jen beton a hrube kabely a pouzdra ktere se budou menit maximalne az to jednou vyhori.
"Vzhledem k tomu, že se jedná o zastaralý informační systém, který nepatří mezi „Významné informační systémy“ ani „Prvky kritické infrastruktury“, jeho servery byly provozovány na diskovém poli s vysokou dostupností bez redundance."
Dokaze mi nejaky znalec objasnit, jak funguje vysoka dostupnost bez redundance?
A s tím EET je to úplně stejné.
To neni, Vyse uvedeny priklad s emailem jsou dva rovnopravne subjekty. Kdezto tady je to stat versus obcan, ktery je vzdy v nevyhode. Ostatne prvni co stat udela, ze ten vypadek proste zataji a nic s tim neudelas.
Ostatne dnes kdyz musis posilat neco Datovou schrankou, taky nevis zda to skutecne doslo a bylo spravne vyplene. Dozvis se to az pokutou :-)
V cem je rozdil jestli to je 2 vteriny nebo 2 minuty ?
Nastesti http://www.podnikatel.cz/clanky/obstrukce-zatim-nejsou-treba-na-projednani-eet-opet-nedoslo/
Jenže to je ajťácký pohled na věc. Tady se dostáváme do oblasti práva a tam věci nefungují takto exaktně.
Podobný problém jsme řešili s distribucí pozvánek na schůzi bytového domu emailem. Ajťák řeší prokazování doručení nějakou technologií se 100% garancí, soud se na to podívá obecněji a řekne například, že pokud je schůze každý rok přibližně v listopadu, na poslední schůzi se předběžně domluvilo, že tak bude i letos (tudíž si měl vědět že bude a když nepřišla pozvánka, tak se zajímat), všichni ostatní sousedé přišli, atd., tak bude chyba na tvojí straně a svolavatel nemusí prokazovat nějakými logy z mailserveru, jestli se to ztratilo na jeho serveru nebo v tvím antispamu.
A s tím EET je to úplně stejné. Pokud bude nějaký výpadek, který postihne více uživatelů, těžko po tobě ministerstvo bude mít nárok chtít nějakou pokutu, to by bylo protiústavní. Akorát to možná bude trvat než si to v nefunkčním soudnictví obhájíš.
viz článek na blogu http://blog.monitoring-serveru.com/mega-vypadek-informacniho-systemu-ares/ ,který se na to dívá jen z pohledu čísel dostupnosti aplikace.
Tohle je přesně ta věc, ke které to nemá sloužit. Ono už se to děje dnes (protože některé firmy ta data stejně dolují a pak k nim za peníze poskytují přístup), ale pokud by to byla přímo funkce ARESu, bylo by to ještě mnohem horší. Nechtěl bych být v kůži těch "vlezlouchů", kteří by to zkoušeli. První tři bych slušně vyhodil, čtvrtý už by dostal palicí po hlavě.
Spatne hledate, soucasti je to, ze podnikatel si (nejak) ma urcit maximalni odezvu (rekneme 10s) a pokud system do 10s neodpovi, tak muze vygenerovat to cislo sam. Jenze pak musi do onech 48 hodin nahlasit veskere takto realizovane platby a radne byrokraticky vse zduvodnit. Jak to udela, pokud ten system nebude fungovat tyden, to nikdo neresi.
Tedy defakto resi, jediny spravny a legalni postup je zakaznika vyhodit, a nic mu tyden neprodat.
Takto to není. Ten limit si každý nastaví sám na hodnotu, kterou bude schopen obhájit před FÚ. U stánku s pivem na koncertu to budou třeba 3 s, kdežto třeba v nějaké galerii, kde se prodá maximálně několik předmětů denně, by úřad tak malou hodnotu těžko uznal. Ty 2 sekundy jsou doba odezvy samotného systému EET.
Jinak při dodatečném odesílání se musí data odeslat do 48 hodin. To by při pětidenním výpadku jaksi nešlo. Dokonce nemusí být ten výpadek souvislý. MF se bude tvářit, že už to dávno bezproblémově běží, jenže ono to třeba chvilkově vynechává, ztrácí se pakety, spojení vyhnívají na timeouty apod. Výsledkem pak je, že podnikatel nic neodešle a bude muset složitě prokazovat, že byl problém na straně ministerstva.
To by bylo sice hezke, ale nemusi to tak byt. V tom pripade pak musi zarizeni (pokladna) stejne reportovat, ze v definovanem casovem useku (48 hodin) opravdu doslo opakovanemu odeslani te "datove zpravy" a o tomto musi vytvorit verohodny protokol (jak ale bez DS ?), ktery bude slouzit pro nasledny (ocekavany) spor s uradem.
Jinde se zase pise o datove zprave s autentizaci pomoci datove schranky. A snahy o to nacpat DS pokud mozno vsem jsou zde stale.
Ano, uznavam ze to nemusi dopadnout tak strasne jak to vypada.
Ty uváděné paragrafy ale nezmiňují datovou schránku, nýbrž datovou zprávu. A v kontextu tohoto návrhu je datovou zprávou právě informace zasílaná na servery finanční správy. Tedy paragraf 22 říká pouze to, že když no neprojde (například kvůli výpadku internetu) přímo během přijímaní tržby, tak by to měla pokladna odeslat do dvou dnů (opět stejným způsobem).
Z webu finanční správy:
"Každá hotovostní tržba podnikatele bude v okamžiku zaplacení zaevidována prostřednictvím internetu v centrálním datovém uložišti Finanční správy, a jako potvrzení bude zaslán zpět unikátní kód, který podnikatel uvede na účtenku."
Tak pokud si mám jako zákazník odnést účtenku a na ní má být uveden unikátní kód, tak asi nebudu čekat týden.
Tak zrovna ARES je spíše závislý na aktuálních dat. K čemu Vám bude půl roku staré data, když třeba nějaká firma přestane existovat nebo se přestěhovala?
Prostě záleží i na tom, jak velká data jsou a jak často jsou aktualizována. Pokud se aktualizuji každý den, nebo jsou data příliš velká, tak nevím k čemu Vám budou kompletní data, když už druhý den budou neaktuální.
Jediná možnost, kde to má smysl, je nějaké hromadné zpracování, kdy potřebujete data srovnat s ARES. Ale i tak, na množství by to i tak bylo poněkud nepraktické. Co vím, tak je kolem 400 tisíc firem + 1,5 milionů osob, takže kolem 2 milionů záznamů. A z toho chcete vytáhnout jen třeba 50 tisíc záznamů?
Proč by to měl být hukot?
Převedeno na počet údajů mi to přijde jako směšný počet.
Kolega se stará o systém, kde se pro každou zprávu dohledávají další informace, dohledávají se souvislosti mezi existujícími a zároveň proti DB s x 10 miliony záznamů. Garantováno je zpracování 10 tisíc událostí za minutu.
Vazeni, je videt ze jeden i druhy netusite, o cem je rec. Skoda i T-mobile mohou sklidem na sve zakazniky ukazat vztyceny prostrednik, zkuste to udelat vy, jako jejich dodavatel. Zkuste napriklad do retezcu nedodat objednavku, a hned platite penale, pokud nedodate nic tyden, tak mate zrusenou smlouvu a zbozi ve skladech si muzete nalozit s octem.
Plati nasobne, pokud by se zjistilo, ze vase nedodavka neni zpusobena nejakou prirodni katastrofou (coz se jeste da prevazne nejak omluvit) ale vasi neschopnosti zajistit provoz. Davate tim totiz jasne najevo, ze se to muze naprosto kdykoli opakovat.
Jasně, není nic lepšího než státní data nalít do zahraničí, do datacentra americké firmy, které se navíc něco jako výpadek nemůže stát: http://www.firstpost.com/business/aws-mega-outage-what-exactly-went-wrong-2444734.html
To je zatím budoucnost (druhá polovina 2016). Ale od ledna 2016 budou podávána kontrolní hlášení. A jsem zvědavý, jak jim systémy budou fungovat, když tam najednou půl milionu plátců DPH pošle svá hlášení a zjednodušeně řečeno všechna plnění nad 10 tis. Kč se budou proti sobě křížově kontrolovat. To bude teprve na diskových polích hukot :-).
Prdel bude až Burešovi spadnou servery s EET
Na to naopak ceka, to bude pulmilionovych pokut za nesplneni povinnosti oznameni evidovane trzby datovou schrankou do 48 hodin ... (viz navrh zakona https://apps.odok.cz/kpl-detail?pid=KORN9TEC3YTP paragrafy 22 a 29).
Je to fail. Ten omezený režim má odezvu 30s nebo timeoutuje.
Člověk by čekal, že to pojede na něčem jako Amazon AWS už od začátku nebo budou to tam aspoň budou schopni nahodit do dvou hodin od výpadku v plné kapacitě.
Podle všeho jim zdechnulo v pátek pole a teď tam sesmolili dohromady nějaký náhradní HW za pětikorunu než se jim podaří dát do provozu ten původni.. Ten stát je prostě mimo, toto je úroveň roku 1995.
Zvlaste kdyz navrh zakona o EET vyzaduje reakce poplatnika pri kazde chybne transakci do 48 hodin vyhradne elektronickou cestou, jinak hrozi likvidacni pokuta 500 000 Kc.
Jinak ten clanek neni presny, nefunguje to stale, na uvedenem odkazu v clanku je informace:
Aktualizováno 11. 11. 2015 16:20
Dne 11. listopadu 2015 v dopoledních hodinách byly zprovozněny informační systémy ARES, ARIS, UFIS v omezeném rozsahu.
Při používání informačních systémů může docházet k delším odezvám a ke krátkodobé nedostupnosti.
Omlouváme se za způsobené obtíže. Na plném obnovení provozu se intenzivně pracuje.
Co bychom take za ty miliardy rocne chteli, ze ... kdyz se tak rozhlednu ve svem okoli, znacnou cast firem by takovy vypadek privedl na pokraj krachu. Opravdu bych nechtel byt v roli dodavatele napriklad automobilky, kteremu tyden nefunguje system. A uz vubec bych nechtel platit ta penale co by nasledovala.
A co teprv az se to nebude tykat jen byrokratu, ale nas vsech, to bude teprve radosti na starem belidle, az skolabuje ten uzasny Babisoregistr.
Predpokladam, ze prislusny urednik dostal prislusne minimalne 7 mistne odmeny za dobre realizovanou zakazku, a za repliku na rezervnim (v cene o rad nizsi) poli jel na pulrocni dovolenou na Bahamy/Maledivy/...