Automatický přepočet měny? Jak na to?

Ahoj, momentalne v jednom nasem projektu resim jak automaticky prepocitavat ceny podle zvolene meny uzivatelem.Priklad: na webu mame ruzne nabidky, lokalizovane do danych jazyku, nicmene u kazde nabidky je cena uvedena v EUR, RUB, CZK, USD a tak podobne.Uzivatel muze zvolit svoji menu a ja bych chtel zobrazit cenu dane nabidky v jeho mene. Nabidka je od ruznych uzivatelu, ktere cenu sami u dane nabidky nastavili v jejich preferovane mene, nekdo v USD nebo v EUR nekdo v nejake jine.Udealni priklad je Booking.com Pokud chcete zobrazit ceny v EUR nebo jine mene nez CZK tak se Vam vsechny nabidky prepocitaji na danou menu.Podle ceho se cerpa dany kurz pro prevod na urcitou menu?Nabidky na nasem projektu jsou dostupne globalne, neni idealni cerpat kurzy men podle CNB, protoze nekdo danou sluzbu nabizi ve Spanelsku, nekdo v Argentine nekdo v Tokio, kazdy stat tak ma svuj vlastni kurz meny.

Nejlepsi je se poradit s ucetni. Jinak se to dela bud podle aktualniho kurzu, coz nechces, tak potom danym kurzem, ktery si nastavis napr. Na ctvrtleti nebo rok.

Ucetni k tomuto nic nerekne, ja neprodavam za tyto ceny.Dam smysleny priklad jak funguje nas web.Uzivatele pridavaji z ruznych statu a mest sve ubytovani jako nabidku. Uzivatel prijde na web a chce si zobrazi ceny (orientacne) ve sve mene. Napriklad Rus prijde na nas web a zobrazi ceny ubytovani v CR v RUB (rublech), pritom nabidky z CR jsou v ruznych menach. Nekdo prida moznost ubytovani s cenou EUR, nekdo v USD nekdo v CZK nekdo GBP.... Ja potrebuji tyto ceny uakzat uzivateli v mene, kterou si zvoli .)---------- Příspěvek doplněn 30.11.2016 v 19:39 ----------Uz jsem to nasel, budu cerpat info z ECB

a čím ti ty lidé platí? Info bys primárně měl čerpat podle kurzů, za které prodáváš devize, v případě, kdy si vedeš devizový účet, můžeš použít kurz ČNB/ECB nebo použít kurz, za který poté devize prodáváš obvykle.

Aha, tak to jsem spatne pochopil :)

Napsal TomášX;1343055

a čím ti ty lidé platí? Info bys primárně měl čerpat podle kurzů, za které prodáváš devize, v případě, kdy si vedeš devizový účet, můžeš použít kurz ČNB/ECB nebo použít kurz, za který poté devize prodáváš obvykle.

Me neplati lidi, proste zakaznici maji misto kde inzeruji sve nabidky. Navstevnik muze na tuto nabidku reagovat naprimo s prodejcem/poskytovatelem, pritom plati cenu v jeho vychozi mene.Podejce poskytovatel ma k dispozici 12 men v Back Endu ve kterych muze vystavovat sve nabidky, navic nabidky muze lokalizovat do X jazykovych mutaci. Pro kazdou jakykovou mutaci muze dat k nabidce jinou castku v jine mene. Pokud primarne inzeruje v Cestine s a menou CZK tak muze nabidku take prelozit to ENG a cenu uvest v USD nebo EUR ekvivalentne k primarni cene v CZK (v CZK cena 1000,- v USD 40 v Nemcine uz 50€)Na Front Endu prijde navstevnik, ktery zvoli svuj jazyk ve ktere vyhledava a zvoli menu, ve ktere chce hledat. Takze se mu zobrazi jen lokalizovane nabidky do jeho jazyku.Ve vysledku vyhledavani, pokud navstevnik zvoli ENG jazyk, tak se mu zobrazi nabidky jak v CZK, USD, EUR, JPY, GBP a tak dale...Takze navstevnik nema moznost vyfiltrovat nabidky v urcite cenove relaci (Price Range), protoze nemuze filtrovat podle kazde meny zvlaste > zvoli jemu blizsi menu - napriklad CAD.Takze potrebuji prepocitat v realtime vsechny nabidky ze vsech men do vybrane meny a timpadem zaroven zristupnit Price Range aby mohl vyfiltrovat ceny v relaci od 50 do 100 CAD.Nemuzu ulozit 5 000 nabidek v 6 jazykovych mutacich s ruznou menou a ruznou cenou a zarove kazdou jednotlivou nabidku prepocitat do DB do vsech dostupnych men v app mezi sebou :D---------- Příspěvek doplněn 30.11.2016 v 21:52 ----------P.S.mam inzerenta, ktery ma 20 nabidek, ma tyto nabidky lokalizovane do Cestiny, Nemciny, Anglictiny a Rustiny.V cestine ma cenu v CZK, v Rustine ma v EUR, v Nemcine ma ceny v EUR, ale v Anglictine ma v USD.Pak dalsi inzeren ma uvedene ceny ve 4 lang mutacich pouze v USD a dalsi pouze v EUR + RUB.Na front endu navstevnik kouka na vsechny nabidky a vidi ruzne ceny v ruznych menach.Navstevnik chce prepnout vsechno na EUR a ja navstevnikovi chci poskytnou unifikaci cen (aprox) v EUR. Takze vsechny nabidky v danem jazykce i ruznych menach by se meli prepocitat na EUR. Navstevnik vidi teda orientacni ceny v jim zvolene mene, ale pak az namiste inzerentovi plati v jeho vychozi mene.

Ahoj,pro inspiraci, něco obdobného jsem řešil takto:Mám konverze, které mají cenu, datum a měnu (cena je částka v určité měně).V další tabulce mám uložené kurzovní listky (ID + datum, kdy se stahoval z ČNB) + v další tabulce konkrétní kurzy pro daný kurzovní listek (pro jednu měnu jeden záznam).Přímo v DB jsem pak schopný spočítat cenu v jakékoliv měně (podle nastavení přihlášeného uživatele), cena se počítá podle stažených kurzů prodaný den.Pro více více států asi budeš potřebovat i více takových kurzovních lístků.

aha, to pak opravdu nemusí být přesně, nemá smysl to počítat jinak než v db.

dobra data na orientacni rpevody men nabizi treba https://www.quandl.com stahujem odsud pro kazdej den kurz mezi pary co pouzivame a kdyz vytahujeme data v jine mene, prevadime podle tabulky prevodnich kurzu, lze primo v db nebo dodatecne pri vypisu treba...

na subregu pouzivame exporty kurzu CNB ... zakladni meny maji denni kurz, exoticky tydenni. Ceny mame ve vsech moznych svetovych menach prepocitavany do meny klienta, a meny klientu mame v CZK, EUR, USD, GBP, TZS, KES, HRK, RSD, UAH, RUB - takze se to aplikuje opravdu krizem-krazem.Namitat se da na ty mesicni kurzy exotickych men, na druhou stranu, svetovy sluzby to do CZK stejne prepocitavaj skrze USD nebo EUR, takze tam jsou take nepresnosti.http://www.cnb.cz/cs/financni_trhy/devizovy_trh/kurzy_devizoveho_trhu/denni_kurz.txthttps://www.cnb.cz/cs/financni_trhy/devizovy_trh/kurzy_ostatnich_men/kurzy.txt

@Gransy a @Aleší.Pokud mate 1000x cen, konvertujete a ukladate tyto data 1000 x 30měn mezi sebou do DB, abyste zobrazili cenu podle zvolene meny uzivatele?Neni to narocny na DB a serverovy vykon?Protoze jak pisi, tak mam ruzne meny ve vysledku vyhledavani, a abych to jendou denne zkonvertoval mezisebou tak se to cele zblazni, zvlast kdyz vysledky vyhledavani maji desitky tisi zaznamu :)

Ja to konvertuju az pri zobrazeni uzivateliV DB mam jen ceniky v lokalnich cenach a kurzovni listek.Samozrejme cenu v BRL uzivateli pouzivajici EUR to konvertuju skrze CZK :)

staci to prece pocitat az pri vypisu podle aktualnich kurzu, nemusis to mit nijak poukladane, poukladane musis mit jen ty kurzy... v tomhle pripade je to anvci o to jendodussi ze staci mit ulozeny jen aktualni den, my mame kolikrat aplikace kde je treba prepocitavat ceny i roky dozadu podle kurzu co byl aktualni kdysi tak to pak mame tabulku plnou kurzu z minulosti (neni to zas tak hrozny) :)

Dobre. Prepocet pri vypisu OK, ale napada Vas jak napojit filtr podle rozmezi ceny v takovem pripade?Pokud navstevnik na front endu vybere jednu z nabizenych men, pri vypisu probehne prepocet na vybranou menu uzivatele, a zaroven potrebuji zprovoznit filtr v teto, zvolene uzivatelem, mene, ktery bude filtrovat uz prepocitane vysledky.viz obrazek:21767