forum.odorik.cz

áno tá gopay penaženka má službu dobitia cez sms ale len z CZ ! a nie SK ...

Jsem novym uzivatelem a nikde jsem nenasel informaci ohledne 2 lete platnosti kreditu, respektive co se stane po uplynuti 2 let???
Zbývající kredit propadne provozovateli?
Konkurence to má řešeno tak, že každé dobití prodlužuje platnost celého kreditu (tedy i starého) nebo žádnou platnost nemá.
Dekuji za odpoved (odkaz).

Dobití kreditu prodlužuje platnost na další 2 roky.

Děkuji, ale měl jsem 2 dotazy...
Takže znovu. Co se stane, když kredit nedobiji (propadne, bude mi zrusen ucet)? Zkrátka co všechno se stane?
Nikde nemáte VOP ani nic podobného, takže se hold musím takhle ptát

Já jen opět připomínám možnost inkasa z účtu při poklesu pod nastavenou hranici a nastavenou částkou. Pak se o to nemusím starat a můžu telefonovat pořád, zvláště u většího provozu se může stát rychle, že kredit klesne na nulu.

Návštěvník píše:Děkuji, ale měl jsem 2 dotazy...
Takže znovu. Co se stane, když kredit nedobiji (propadne, bude mi zrusen ucet)? Zkrátka co všechno se stane?
Nikde nemáte VOP ani nic podobného, takže se hold musím takhle ptát

VOP jsou zde https://www.odorik.cz/registrace/vseobe ... minky.html
i když pravda v těchto věcech nejsou až tak konkrétní.
Nulování kreditu po dvou letech není vůbec naprogramováno, zatím nikomu kredit vynulován nebyl.
Ale podle podmínek může být. Počítáme ale s tím, že bychom na to dostatečně dopředu upozornili, aby měl každý možnost kredit provolat nebo znovu dobít.
Žádný důvod proč rušit účty s nulovým kreditem nemáme. S čím je však nutné počítat, že pokud nebudete dlouhodobě používat veřejná čísla (jako třeba ty dva roky) a zároveň nebudete mít žádný kredit, mohou být uvolněna. To ve VOP není, protože ty byly dříve než veřejná čísla.

Někdo psal ve fóru, že implementace inkasa by byla tááák složitá a trvala by tóólik člověkohodin.
Zřídil jsem si demoúčet u Fia a trochu jsem si s tím hrál.

Tak za prvé, Fio nabízí import/export příkazů a transakcí ve formátu ABO. Nejpřímější je tedy poloautomatická implementace inkasa, kde systém ústředny vygeneruje soubor ABO se seznamem příkazů k inkasu na žádost obsluhy. Obsluha v nějakém intervalu sedne k iBankingu a soubor uploaduje.

Za druhé, všechny stránky ve Fio bankingu přijímají LOGIN_NAME, LOGIN_PASSWORD a LOGIN_TIME (time_t). Pokud by chtěl někdo automatizovat bankonvictví, není třeba simulovat klikání myší, protože lze volat přímo stránku z form action, do které se posílá vyplněný formulář a přihlašovací údaje přidat k parametrům. Fio je jediná banka, o které vím, že toto umožňuje. Provedení operace je tedy na úrovni RESTful API, protože jen posíláte parametry na nějaké url. Mírná komplikace je upload souboru ABO, kdy je nutno simulovat multipart form-data.

Zbývá poslední problém, autorizace operace. Pro Odorika asi není problém automaticky přijímat a parserovat SMS, když má SMS bránu. Ale opět nám to Fio maximálně usnadní. Místo SMS lze použít jejich Java aplikaci, případně API pro autorizaci klíčem.

Část těchto informací jsem na demoúčtu nemohl ověřit, ale už mám u Fio objednaný reálný účet, takže po aktivaci budu pokračovat v testech a výsledky budu zde referovat.

martin1 píše:Někdo psal ve fóru, že implementace inkasa by byla tááák složitá a trvala by tóólik člověkohodin.
Zřídil jsem si demoúčet u Fia a trochu jsem si s tím hrál.

Tak za prvé, Fio nabízí import/export příkazů a transakcí ve formátu ABO. Nejpřímější je tedy poloautomatická implementace inkasa, kde systém ústředny vygeneruje soubor ABO se seznamem příkazů k inkasu na žádost obsluhy. Obsluha v nějakém intervalu sedne k iBankingu a soubor uploaduje.

Za druhé, všechny stránky ve Fio bankingu přijímají LOGIN_NAME, LOGIN_PASSWORD a LOGIN_TIME (time_t). Pokud by chtěl někdo automatizovat bankonvictví, není třeba simulovat klikání myší, protože lze volat přímo stránku z form action, do které se posílá vyplněný formulář a přihlašovací údaje přidat k parametrům. Fio je jediná banka, o které vím, že toto umožňuje. Provedení operace je tedy na úrovni RESTful API, protože jen posíláte parametry na nějaké url. Mírná komplikace je upload souboru ABO, kdy je nutno simulovat multipart form-data.

Zbývá poslední problém, autorizace operace. Pro Odorika asi není problém automaticky přijímat a parserovat SMS, když má SMS bránu. Ale opět nám to Fio maximálně usnadní. Místo SMS lze použít jejich Java aplikaci, případně API pro autorizaci klíčem.

Část těchto informací jsem na demoúčtu nemohl ověřit, ale už mám u Fio objednaný reálný účet, takže po aktivaci budu pokračovat v testech a výsledky budu zde referovat.

Dík za info. Fio má svoje oficiální API http://www.fio.cz/docs/cz/API_Bankovnictvi.pdf ABO je tam taky.
Fio nejen že má nulové poplatky, ale i po jiných stránkách se zdá být nejlepší bankou v ČR. Např. její webové rozhraní je nejlepší co znám.
Nicméně já jsem nikdy neříkal, že je to hrozně složité, nezabývali jsme se tím.

xsouku04 píše:Fio má svoje oficiální API http://www.fio.cz/docs/cz/API_Bankovnictvi.pdf ABO je tam taky.

Myslel jsem, že to jen pro čtení transakcí. To asi používáte pro připočtení příchozích plateb. Já jsem řešil "API" pro aktivní provádění transakcí a příkazů.

xsouku04 píše:Nicméně já jsem nikdy neříkal, že je to hrozně složité, nezabývali jsme se tím.

Netvrdím, že jste to psal Vy. Psal to nějaký uživatel fóra. Je pravda, že jsem ho měl citovat, ale ten příspěvek se mi nechtělo hledat. Zde je:

ViR píše:2 mi-ko: Hmm. Položme si otázku kolik lidí by takové automatické inkaso podle aktuálního stavu kreditu využívalo, jak pracné je naprogramování, co by to stálo "člověkohodin", jak by se to muselo smluvně/právně ošetřit, aby se ani účastník ani operátor (ten hlavně) nevystavili nepřiměřenému riziku velkých ekonomických ztrát v případě prolomení zabezpečení účtu, a také, zda to nejde řešit nějak jinak jednodušeji.

martin1 píše:

xsouku04 píše:Nicméně já jsem nikdy neříkal, že je to hrozně složité, nezabývali jsme se tím.

Netvrdím, že jste to psal Vy. Psal to nějaký uživatel fóra. Je pravda, že jsem ho měl citovat, ale ten příspěvek se mi nechtělo hledat. Zde je:

ViR píše:2 mi-ko: Hmm. Položme si otázku kolik lidí by takové automatické inkaso podle aktuálního stavu kreditu využívalo, jak pracné je naprogramování, co by to stálo "člověkohodin", jak by se to muselo smluvně/právně ošetřit, aby se ani účastník ani operátor (ten hlavně) nevystavili nepřiměřenému riziku velkých ekonomických ztrát v případě prolomení zabezpečení účtu, a také, zda to nejde řešit nějak jinak jednodušeji.

Ten příspěvek byl ode mne. Jenže, pane kolego "martin1", vy jste z komplexní otázky, složené ze čtyř částí, vytrhl jednu dílčí otázku, a to i z kontextu celého, podstatně rozsáhlejšího, příspěvku .

A dvě dílčí otázky "kolik lidí by takové automatické inkaso podle aktuálního stavu kreditu využívalo, jak pracné je naprogramování, co by to stálo "člověkohodin"" opravdu (ale opravdu ) neznamená že "že implementace inkasa by byla tááák složitá a trvala by tóólik člověkohodin". Ale znamená to, že podnikatel, který to musí zaplatit se musí společně s pracností souběžně zabývat (mimo jiné) naléhavostí a užitečností práce na takovém inkasu (podmíněnou i tím, kolik lidí to bude využívat a zda nelze stejného účelu dosáhnout jednodušeji).

Jednoduše řečeno, kdyby například v současné době práce na takové implementaci inkasa vyšla na pouhý jeden "člověkoden", přidalo to podnikateli například deset klientů, ale oddálilo o ten den spuštění mobilních služeb (protože ten kdo dělá na inkasu nemůže v tu samou dobu dělat na uživatelském rozhraní pro mobilní služby), musí podnikatel zvážit, co je pro něj ekonomicky provozně významnější.

Tedy nejde o absolutní náročnost něco udělat, ale o relativní, vzhledem k ostatním ekonomickým a provozním aspektům podniku. Jo pokud by technici miniTELu měli hotovo, všechno běželo jako na drátkách, zisk ze stávajících poskytovaných služeb činil 40 % po zdanění a oni neměli do čeho píchnout, pak by se samozřejmě účelnost a pracnost čehokoli, co si nějaký klient vymyslí, nemusela řešit