Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Hyp 30. 12. 2023, 12:06:32
-
Zdravím všechny, myslel jsem, že přecením zásoby v souvislosti se změnou DPH přímo v mysql
UPDATE `karta` SET `prodejnicenabezdph`=Round(`prodejnicenabezdph`*((100+(SELECT `sazbadph` FROM `sazbadph` WHERE `iddph`=`dphvystup`))/100),0)/1.12 WHERE `dphvystup`=1 or `dphvystup`=3Problém je, že do databáze se např. pokud je cena s DPH12% 91Kč uloží místo 81.25 částka 81.24999999999. Pokud změním ručně na 81.25, pak mi dotaz SELECT `prodejnicenabezdph`*1.12 vrátí 91.00000000000001 ale SELECT 81.25*1.12 vrátí 91.
Taky dotaz např. SELECT `prodejnicenabezdph`, `prodejnicenabezdph`*1.12+0 FROM `karta` WHERE 1; vrací 81.25 a 91.00000000000001.
Zaokrouhlování nemám moc řešeno, ale hlavně netuším důvod, proč tomu tak je.
Hodnota je double, ale pokud změním na FLOAT, tak výsledek je stejný.
Děkuji za každou nápomoc.
-
Nepoužívat float https://stackoverflow.com/questions/13030368/best-data-type-to-store-money-values-in-mysql (https://stackoverflow.com/questions/13030368/best-data-type-to-store-money-values-in-mysql) ?
-
Nepoužívat float https://stackoverflow.com/questions/13030368/best-data-type-to-store-money-values-in-mysql (https://stackoverflow.com/questions/13030368/best-data-type-to-store-money-values-in-mysql) ?
Díky za odpověď. Používal jsem double, ale výsledek byl stejný. Pokud dám decimal 15.4, tak tento případ je OK, otestuji zítra a potvrdím.
Díky Hyp
-
vis jak se double jmenuje plnym jmenem? :)
-
Pro přesné počítání peněz vždy jen decimal.
Float je je oproti decimalu sice rychlejší a úspornější, ale daní za to je občasné drobná nepřesnost.
U čísla 4.4587965874 taková nepřesnost obvykle nevadí a nikdo si jí nevšimne, ale u čísel s používaným malým počtem desetinných míst to tluče do očí.
Alternativou může být všechny výstupy vždy zaokrouhlovat.
-
Používal jsem double, ale výsledek byl stejný.
z podstaty veci: pocitac interne nepocita v desiatkovej sustave. Ked budete pouzivat akukolvek verziu float-u, tak niekde na vas moze vyskocit, ze na x-tom desatinnom mieste sa schovalo nieco co nechcete.
Krasne to je vidno na Javascripte, kde sa to fakticky podla mna ani neda riesit. (spresnenie pre stalice FJ & D: som ochotny pripustit, ze uz dva dni existuje mne neznamy postup, ktory to riesi :P)
t.j. spravte si vsetky stlpce na peniaze na dve desatinne miesta a budete to mat tak, ako by to robil zivy clovek.
Co je to co sa pokusate v aplikacii napodobnit.
Alternativou může být všechny výstupy vždy zaokrouhlovat.
takyto pristup je koledovanie si o "zahadne chyby", kde uzivatel vidi v stlpci hrst cisel a sucet sa lisi o cent ;)
-
V db by hlavne nemela byt trojice { bez-dph, dph%, s-dph }, ale jenom dvojice { bez-dph, dph% } nebo dvojice { dph%, s-dph }, protoze na danovem dokladu se DPH pocita az ze sumy vsech polozek. Jinak bude samozrejme dochazet k tomu, ze soucty bez-dph a s-dph nebudou sedet, kdyz je budete rozepisovat per radek.
U sebe tedy mam ty tri, ale maji povoleny null, a ctvrty sloupec, ktery rika co je primarni informace - zda cena s dph nebo bez dph - pak je to uz na skriptech, aby z toho vykoumal co chce, ale stejne se jeste bez dalsiho sloupce na korekci zaokrouhlovaci chyby neobejdu :)
-
jenom dvojice { bez-dph, dph% } nebo dvojice { dph%, s-dph }
S DPH, z tej idu vypocitat vsetky hodnoty bez DPH. Pri opacnom postupe tj. vypocet ceny s dph z ceny bez dph, nie je mozne koli zaokruhlavaniu pokryt niektore hodnoty...
-
jenom dvojice { bez-dph, dph% } nebo dvojice { dph%, s-dph }
S DPH, z tej idu vypocitat vsetky hodnoty bez DPH. Pri opacnom postupe tj. vypocet ceny s dph z ceny bez dph, nie je mozne koli zaokruhlavaniu pokryt niektore hodnoty...
To by platilo, pokud uvazujete ciste o B2C eshopu a nejste platce - coz je takova situace, ze si jen hrajete na biz. Jakmile se jedna o vice B2B a je umozneno obchodovat s platci.. tak je primarnejsi hodnota ta cena bez dph. V praxi se pouziva to i to, zalezi od pristupu subjektu no. Takze jsem to ve svem reseni musel pokryt univerzalne.
A z pohledu statu - danovych priznani, je primarni hodnotou take castka bez dane ,)
-
jenom dvojice { bez-dph, dph% } nebo dvojice { dph%, s-dph }
S DPH, z tej idu vypocitat vsetky hodnoty bez DPH. Pri opacnom postupe tj. vypocet ceny s dph z ceny bez dph, nie je mozne koli zaokruhlavaniu pokryt niektore hodnoty...
To by platilo, pokud uvazujete ciste o B2C eshopu a nejste platce - coz je takova situace, ze si jen hrajete na biz. Jakmile se jedna o vice B2B a je umozneno obchodovat s platci.. tak je primarnejsi hodnota ta cena bez dph. V praxi se pouziva to i to, zalezi od pristupu subjektu no. Takze jsem to ve svem reseni musel pokryt univerzalne.
A z pohledu statu - danovych priznani, je primarni hodnotou take castka bez dane ,)
Ještě bych doplnil, že se zaokrouhlují až výstupní hodnoty. Takže nic nebrání tomu mít v databázi hodnotu uloženou s přesností třeba na desetiny halíře, abyste se i po připočtení/odečtení DPH trefil na hezké hodnoty. Zaokrouhlujete pak teprve vypočtenou hodnotu, a to v obou případech (bez DPH i s DPH).
-
Takže nic nebrání tomu mít v databázi hodnotu uloženou s přesností třeba na desetiny halíře, abyste se i po připočtení/odečtení DPH trefil na hezké hodnoty. Zaokrouhlujete pak teprve vypočtenou hodnotu, a to v obou případech (bez DPH i s DPH).
jasne a klientovi budete na fakture uctovat tiez desatiny haliera, ze?
uz ste dakedy skusal nieco na tu temu riesit?
klienti zboznuju ad-hoc zostavy, kde sa s niecim taky fakt uzasne pracuje :).
-
Takže nic nebrání tomu mít v databázi hodnotu uloženou s přesností třeba na desetiny halíře, abyste se i po připočtení/odečtení DPH trefil na hezké hodnoty. Zaokrouhlujete pak teprve vypočtenou hodnotu, a to v obou případech (bez DPH i s DPH).
jasne a klientovi budete na fakture uctovat tiez desatiny haliera, ze?
uz ste dakedy skusal nieco na tu temu riesit?
klienti zboznuju ad-hoc zostavy, kde sa s niecim taky fakt uzasne pracuje :).
To jste asi nepochopil co se snazil FJ rict. Fakturujete klientovi jednu vyslednou castku (urcenou k platbe), a ta je ta, co je zaokrouhlena na halire (u platbe prevodem, kartou) nebo koruny (pri platbe v hotovosti).
A pokud je v procesu jeste menova konverze, tak ta vam taky prida nekolik desetinnych mist, a u exotickych men je nekdy potreba i hodne mist pred teckou, protoze jsou v miliardovem meritku...
.. a pak nakonec skoncite na DECIMAL(30,18)
-
Takže nic nebrání tomu mít v databázi hodnotu uloženou s přesností třeba na desetiny halíře, abyste se i po připočtení/odečtení DPH trefil na hezké hodnoty. Zaokrouhlujete pak teprve vypočtenou hodnotu, a to v obou případech (bez DPH i s DPH).
jasne a klientovi budete na fakture uctovat tiez desatiny haliera, ze?
uz ste dakedy skusal nieco na tu temu riesit?
klienti zboznuju ad-hoc zostavy, kde sa s niecim taky fakt uzasne pracuje :).
Doporučuju nastudovat si pojem „zaokrouhlování“. V mém komentáři je podstatný, když ho jen tak přeskočíte, protože mu nerozumíte, komentář vám opravdu nemůže dávat smysl.
Jinak lidé pracující s měnovými částkami běžně zaokrouhlovat umí. Například české koruny se dělí na sto halířů, ale v hotovostní oběživu už halíře neexistují. Ale třeba v obchodech naprosto běžně narazíte na cenovky s desítkami halířů, někde i s halíři – a když pak platíte v hotovosti, obchodník to musí zaokrouhlit.
Nebo třeba různé cloudové služby mají často v ceníku položky, kdy jednotka za měsíc stojí třeba desetinu nebo setinu centu. A také zaokrouhlí až celkovou částku na faktuře, protože kdyby zaokrouhlovali ty ceníkové částky, přijdou na buben.
-
Děkuji všem za pomoc, změněno v DTB na decimal 15,4
-
jenom dvojice { bez-dph, dph% } nebo dvojice { dph%, s-dph }
S DPH, z tej idu vypocitat vsetky hodnoty bez DPH. Pri opacnom postupe tj. vypocet ceny s dph z ceny bez dph, nie je mozne koli zaokruhlavaniu pokryt niektore hodnoty...
Ehm lol ... ne. VZDY se pouziva cena BEZ DPH. Z te se plati veskere odvody, dane, to DPH atd atd atd. Cena s DPH nikoho kdo DPH vybira nezajima.
...
Naprosty nesmysl, ale co cekat od vseznalka Jirsaka ktery nevi ani to, ze nejmensi castkou dle zakona je 0,01Kc bezhotovostne nebo 1Kc hotove. Takze mit jakekoli ceny na jakali dalsi mista je holy nesmysl. Ktery pak jen vede k tomu, ze nesouhlasi soucty.
Doporučuju nastudovat si pojem „zaokrouhlování“. ....
A uz si zacal? Chci videt, jak na fakturu vytisknes 10 polozek, kdyz kazda jedna bude mit cenu na 5 desetin, aby soucet souhlasil ... a dal se zaplatit.
-
Naprosty nesmysl, ale co cekat od vseznalka Jirsaka ktery nevi ani to, ze nejmensi castkou dle zakona je 0,01Kc bezhotovostne nebo 1Kc hotove. Takze mit jakekoli ceny na jakali dalsi mista je holy nesmysl. Ktery pak jen vede k tomu, ze nesouhlasi soucty.
Když tvrdíte, že je něco podle zákony, jistě dokážete uvést i o které ustanovení zákona se jedná. Mimochodem, sám jste připustil dvě varianty – celé halíře a celé koruny. I to by vám bez zaokrouhlování dělalo problém.
A uz si zacal? Chci videt, jak na fakturu vytisknes 10 polozek, kdyz kazda jedna bude mit cenu na 5 desetin, aby soucet souhlasil ... a dal se zaplatit.
Tak se někdy na nějakou fakturu podívejte. Často tam najdete položky jako „haléřové vyrovnání“ nebo „zaokrouhlení“.
Příklad s cloudovými službami už jsem uváděl. Pokud byste chtěl namítat, že to jsou ceny v eurech nebo dolarech, a že tam platí jiná pravidla, tady máte položku ceníku 0,0070 Kč: https://www.forpsicloud.cz/object-storage/cenik.aspx Asi byste nechtěl, aby vám to zaokrouhlili rovnou na začátku na 1 Kč.
-
To by platilo, pokud uvazujete ciste o B2C eshopu a nejste platce
Z pohladu uctovnictva ziadna cena bez DPH a s DPH neexistuje. Mate Cenu, Sadzbu DPH a Zaklad DPH. To co vacsinu ludi pletie je ze pri B2B mate nulovu sadzbu a pri nulovej sadzbe je cena == zaklad.
-
Ještě bych doplnil, že se zaokrouhlují až výstupní hodnoty. Takže nic nebrání tomu mít v databázi hodnotu uloženou s přesností třeba na desetiny halíře, abyste se i po připočtení/odečtení DPH trefil na hezké hodnoty. Zaokrouhlujete pak teprve vypočtenou hodnotu, a to v obou případech (bez DPH i s DPH).
Na danovom doklade mate aj medzivysledky, minimalne suhrn dph sadzieb. Ak ma system atributy pokladnicneho systemu (vydava danove doklady) tak by mal mat certifikaciu od danoveho uradu. Danovak, ktory ten system bude auditovat sa vam na nejake spekulativne uvahy vykasle. Pouzije svoju blbu ekonomicku kalkulacku, ktora zaokruhluje na 2 desatinne miesta (cele centy/haliere) a prepocita ten danovy doklad. Ak mu to nebude sediet na cent, tak vam to hodi na hlavu. A nie, halierove vyrovnanie nie je stahdartny postup, v mnohych krajinach EU sa nepouziva.
-
A nie, halierove vyrovnanie nie je stahdartny postup, v mnohych krajinach EU sa nepouziva.
LOL, kdyz to rika frikulin z internetu, tak to tak musi byt, co? :D
Je mnoho faktur, u kterych prave nesedi ty castecne soucty - protoze se tvurce snazi zalibit na kulate ceny s dani, takze bez dane to pak vychazi hodne meh.
V podstate vsechny B2C eshopy resi takto pitome, z koncove ceny zpetne.
A nevim co mate proti halerovemu vyrovnani - treba Vodafone to ma celkem slusne udelany, ze se halerove vyrovnani pridava prubezne, aby castka k platbe byla vzdy na cele koruny. Nekdy tedy zaplatite tedy vice a nekdy mene, kdyz se ty halerove preplatky nahromadi.
Pokud vyslovene nedelate halerovou magii s cilem dosazeni vyhod (napr "korunove dluhopisy"), tak pri beznem obchodovani vam FU nic nerekne. Ostatne o nejaky ten halir jim nejde, protoze nektere podani jsou v korunach, nektere v halirich.. a jine dokonce v tisicich (s temi mam paradoxne nejvetsi problem, protoze to casto vyjde off by 1 v souctech).
-
...
do databáze se např. ... uloží místo 81.25 částka 81.24999999999.
...
Hodnota je double, ale pokud změním na FLOAT, tak výsledek je stejný.
...
Na ukladanie penaznych ciastok sa v databaze pouziva typ DECIMAL,
napr. DECIMAL(17, 2) ma 15 cislic pred desatinnou ciarkou a dve za desatinnou ciarkou.
Nadefinuj si to podla toho s akymi velkymi obnosmi pracujes.
-
LOL, kdyz to rika frikulin z internetu, tak to tak musi byt, co? :D
Ad frikulin z internetu... Pri par certifikaciach som uz bol, ci uz ako vyvojar alebo ako temleader...
Ad halierove dorovnanie... Ak si nejaky bezcenny vekslak mysli ze cena je zaklad DPH, a ze samotna DPH je naklad koncoveho zakaznika, tak je to len jeho problem. Potom nie je divu ze sa snazi dorovnat zaklad DPH na nejake pekne cislo. Ako som uz pisal, neexistuje cena s DPH a cena bez DPH. Je len cena, zaklad DPH a sadzba DPH.
-
To by platilo, pokud uvazujete ciste o B2C eshopu a nejste platce
Z pohladu uctovnictva ziadna cena bez DPH a s DPH neexistuje. Mate Cenu, Sadzbu DPH a Zaklad DPH. To co vacsinu ludi pletie je ze pri B2B mate nulovu sadzbu a pri nulovej sadzbe je cena == zaklad.
No, ono to spíše vypadá, že to spletlo vás. Vlastně hůř - toto je blábol.
Pokud si prodávají mezi sebou dva plátci, tak nejde o žádnou nulovou sazbu DPH nejde. DPH je stále ve své výši, MUSÍ být i na faktuře a plátci si mezi sebou platí částku s DPH.
Nulová sazba DPH je něco jiného.
-
....
Alebo len vy ste necital celu diskusiu, pripadne len ciastocne, lebo pre tak dlhy text neudrzite kontext?
Rozporujete moje tvrdenie ze je len cena (zaklad DPH + DPH), zalkad DPH a sadzba DPH, tym ze tvrdite ze dva subjekty si fakturuju ceny, ktore su suctom zakladu DPH a DPH? 😁
-
Ne. Rozporuji vas nesmyl, ze dve firmy si fakturuji s nulovou dph.
-
...
Jirsaku, tys zjevne vzivote zadnou fakturu nevidel. Zkus jakykoli firme poslat fakturu, kde nebude na halir sedet soucet polozek. S nejakym tvym vymyslem na tema vyrovnani ti ji tak leda omlati o hlavu.
A nejen ze ti ji omlati o hlavu, pokud se ta faktura posila elektronicky, tak ji proste vubec neprijmou, protoze ta faktura musi exaktne sedet na polozky ktere si objednali.
... MUSÍ být i na faktuře a plátci si mezi sebou platí částku s DPH.
Ehm ... ne. Zalezi na tom v jakem rezimu obchod probiha a je tam takovy kvantum podminek a vyjimek, ze se to ani nijak jednoduse popsat neda, ale firmy si ani zdaleka vzdy mezi sebou DPH neposilaji. Jednim z mnoha pripadu je ten, ze se kupujici nechce stat rucitelem (kterym se jinak automaticky stava = to aby si statni byrokrati zjednodusili zivot a penize mohli uloupit tam kde je to snazsi) za prodavajiciho, a nechce to DPH pripadne zaplatit jeste jednou ze sveho.
Stejne tak se to tyce treba obchodovani se zahranicim, kde se opet zadne DPH neplati.
Atd atd atd ...
-
Ježiš, to jsem čekal, že se objeví nějaký chytrák, co se chytí vyjímek, jako přenesená DPH, zahraničí apod. a další ...
Děkujeme. Těší nás. Ale jinak informace k ničemu.
PS: On Jirsák zase tak mimo není. Na fakturách běžně haléřové vyrovnání (celku, ne jednotlivých položek) je. takže se sklidni. Pokud jsi doteď žádnou fakturu neviděl, tak ti jich pár můžu poslat, ať se poučíš.
-
Jirsaku, tys zjevne vzivote zadnou fakturu nevidel. Zkus jakykoli firme poslat fakturu, kde nebude na halir sedet soucet polozek. S nejakym tvym vymyslem na tema vyrovnani ti ji tak leda omlati o hlavu.
To, že nebude sedět součet položek, je váš výmysl. Já jsem nic takového nepsal. Na rozdíl od vás totiž umím zařídit, aby ten součet seděl.
Vy jste možná někdy jedno fakturu viděl, ale měl byste si jich prohlédnout víc. Všimněte si, že jsou tam položky jako „haléřové vyrovnání“ nebo „zaokrouhlení“. To je ta „magie“, která způsobí, že součet sedí. Už to tady padlo několikrát, dokonce i s příkladem, že haléřové vyrovnání má na fakturách třeba Vodafone. Nechápu, proč ze sebe musíte dělat hlupáka tím, že píšete něco, co už tu bylo opakovaně vyvráceno.
-
Doporučuju nastudovat si pojem „zaokrouhlování“. V mém komentáři je podstatný, když ho jen tak přeskočíte, protože mu nerozumíte, komentář vám opravdu nemůže dávat smysl.
Niezeby o nieco slo, ale pisal som o reportoch a nie o trivalitach, ako je vystavovanie faktury.
Uz vidim ako sa vasa temna magia z hadzanim prebytocnych halierov kdekade do chlievikov ako "halierove vyrovnanie" zlucuje s tym, ze si klient vypyta ad-hoc rez dat.
-
Ježiš, to jsem čekal, že se objeví nějaký chytrák, co se chytí vyjímek, jako přenesená DPH, zahraničí apod. a další ...
Vas zrejme podrazdila ta moja narazka na potreby bezcennych vekslakov... Darmo tu prskate, tento boj by ste si mal vyriesit vo svojej mysli.
To je ta „magie“, která způsobí, že součet sedí.
Aby to sedelo staci daleko menej. Danovak alebo pricetny uctovnik, totiz pocita zaklad DPH z ceny (vydeli cenu cislom 1+sadzba/100). Nikdy nie cenu zo zakladu DPH. Pretoze v pripade delenia ceny cislom vacsim ako 1 dostanete presnu hodnotu zakladu. V pripade nasobenia cislom vacsim ako 1 vam vdaka zaokruhlovaniu vznikaju v urcitych intervaloch medzery, na ktore musite aplikovat halierove dorovnanie.
To co vy vidite ako "magiu" je len obycajny rovnak(halierove vyrovnanie) na ohybak(nespravny postup vypoctu DPH). Ak tu fakturu pocitate tak ako sa ma, tak ziadne halierove dorovnanie nepotrebujete k tomu aby vam sedela na cent.
-
Niezeby o nieco slo, ale pisal som o reportoch a nie o trivalitach, ako je vystavovanie faktury.
Uz vidim ako sa vasa temna magia z hadzanim prebytocnych halierov kdekade do chlievikov ako "halierove vyrovnanie" zlucuje s tym, ze si klient vypyta ad-hoc rez dat.
Pokud klient používá třeba desetiny či setiny halíře či centu, jistě nebude překvapen ani když se mu takové částky objeví v nějakém reportu.
Uvedl jsem tu několik konkrétních příkladů, kdy jsou přímo jednotkové ceny na webu uvedené v setinách centu nebo halíře. Když máme příklady z praxe, že to tak někdo používá, je trochu marné přesvědčovat mne, že to nejde, nemyslíte?
-
To je ta „magie“, která způsobí, že součet sedí.
Aby to sedelo staci daleko menej. Danovak alebo pricetny uctovnik, totiz pocita zaklad DPH z ceny (vydeli cenu cislom 1+sadzba/100). Nikdy nie cenu zo zakladu DPH. Pretoze v pripade delenia ceny cislom vacsim ako 1 dostanete presnu hodnotu zakladu. V pripade nasobenia cislom vacsim ako 1 vam vdaka zaokruhlovaniu vznikaju v urcitych intervaloch medzery, na ktore musite aplikovat halierove dorovnanie.
To co vy vidite ako "magiu" je len obycajny rovnak(halierove vyrovnanie) na ohybak(nespravny postup vypoctu DPH). Ak tu fakturu pocitate tak ako sa ma, tak ziadne halierove dorovnanie nepotrebujete k tomu aby vam sedela na cent.
Expert promluvil. Bohužel jste vedle jak ta jedle.
Je to přesně naopak - tou “základní” cenou je samozřejmě cena bez DPH. Nikoli cena s DPH.
Koncová cena se pak počítá připočtením DPH.
Už toho nechte. Od včera se tu ztrapňujete. A fakt se někdy na nějakou fakturu podilvejte.
-
Aby to sedelo staci daleko menej. Danovak alebo pricetny uctovnik, totiz pocita zaklad DPH z ceny (vydeli cenu cislom 1+sadzba/100). Nikdy nie cenu zo zakladu DPH. Pretoze v pripade delenia ceny cislom vacsim ako 1 dostanete presnu hodnotu zakladu. V pripade nasobenia cislom vacsim ako 1 vam vdaka zaokruhlovaniu vznikaju v urcitych intervaloch medzery, na ktore musite aplikovat halierove dorovnanie.
To co vy vidite ako "magiu" je len obycajny rovnak(halierove vyrovnanie) na ohybak(nespravny postup vypoctu DPH). Ak tu fakturu pocitate tak ako sa ma, tak ziadne halierove dorovnanie nepotrebujete k tomu aby vam sedela na cent.
Jste úplně vedle. Haléřové vyrovnání se používá v případě, kdy máte částky i s halíři, ale kvůli platbě v hotovosti potřebujete splatnou částku zaokrouhlit na koruny. Uváděl jsem to jenom jako příklad toho, že zaokrouhlování se při placení dávno běžně používá, zvládne to každý sedlák na trhu, takže to není zas až taková věda.
No a k tomu způsobu výpočtu – to, že x + a*x = y je to samé, jako x = y - a*x, (x je cena bez DPH, a je sazba DPH, y je cena s DPH) se učí už na prvním stupni ZŠ. Takže problém se zaokrouhlováním tam máte vždycky, ať to budete počítat z jakékoli strany.
-
To se ta diskuze teda rozjela.. Eshopy dělám dlouho a zatím mne vychází ze nejlepší je evidovat jako hlavní cenu tu bez DPH, jakékoliv převody totiž dal jsou jednoduší (do cizí měny, vývoz zboží do EU, reverse charge, OSS). Stejně tak, když se mění sazba DPH tak přecenění zboží je jednoduší. A zároveň evidovat u tu sazbu a cenu s DPH pro některé případy, aby se s tím dobře pracovalo a pohlídat si, aby vždy v DB vše sedělo, pak je to ideál (i z pohledu dalších věcí jako, dát nějakou slevu pokud obj. je nad X částkou (a ta je zase někdy s a nekdy bez DPH).
PS: řeším to z pohledu, že systém umí vystavovat doklady (a rozlišovat jednotlivé položky a členění DPH s návaznosti dále - intrastat, dovoz a vývoz). Samozřejmě tohle menší eshop neřeší, tam to nějak udělá dal účetní - pokud tyto případy vůbec nastanou..
-
Expert promluvil. Bohužel jste vedle jak ta jedle.
Je to přesně naopak - tou “základní” cenou je samozřejmě cena bez DPH. Nikoli cena s DPH.
Koncová cena se pak počítá připočtením DPH.
Už toho nechte. Od včera se tu ztrapňujete. A fakt se někdy na nějakou fakturu podilvejte.
Ak pokladate za experta niekoho kto stal pri uspesnej certifikacii niekolkych pokladnicnych systemov, tak sa nemylite. Ale to je jedine v com sa nemylite.
Pozrieme sa ako definuje zaklad DPH zakon 222/2004 paragraf 22 odstavec 1:
[q]
Základom dane pri dodaní tovaru alebo služby je všetko, čo tvorí protihodnotu, ktorú dodávateľ prijal alebo má prijať od príjemcu plnenia alebo inej osoby za dodanie tovaru alebo služby, zníženú o daň. Do základu dane sa zahŕňa aj dotácia alebo príspevok, ktorý dodávateľ prijal alebo má prijať k cene tovaru alebo služby. [/q]
Z toho je jasne, ze zaklad DPH vypocitavate z protihodnoty(ceny) znizenej o DPH. Naopak zakon nikde nehovori o tom ze protihodnota(cena) je zaklad DPH navyseny o DPH.
Ked tak by som vam preposlal vyjadrenie FS, ako jednemu projektakovi z wincoru ktori vtedy programovali jeden z tych pokladnicnych systemov. Ten tiez dokazal mlatit prazdnu slamu dlhe odstavce, nic na tom vsak nezmenilo ze ten blbec je on. Akurat sa obavam ze mi za to nestojite (a FS uz vobec nie).
-
Pokud klient používá třeba desetiny či setiny halíře či centu, jistě nebude překvapen ani když se mu takové částky objeví v nějakém reportu.
Nebude prekvapeny, bude nespokojny.
Uvedl jsem tu několik konkrétních příkladů, kdy jsou přímo jednotkové ceny na webu uvedené v setinách centu nebo halíře. Když máme příklady z praxe, že to tak někdo používá, je trochu marné přesvědčovat mne, že to nejde, nemyslíte?
a) o nicom Vas nepresviedcam. (Bolo by to hadzanie hrachu o stenu)
b) to, ze Vy si viete osetrit jeden/dva vystupy nic nemeni na fakte, ze je to temna magia, ktoru musite v takom pripade opakovane riesit pri kazdom reporte. Preto som napisal, ze to povazujem za koncepcny nedostatok takeho pristupu.
c) Samozrejme viem si predstavit pripady, kedy moze byt Vas pristup uzitocnejsi.
-
Eshopy dělám dlouho a zatím mne vychází ze nejlepší je evidovat jako hlavní cenu tu bez DPH, jakékoliv převody totiž dal jsou jednoduší
Ako riesite tento problem https://www.db-fiddle.com/f/2dtPBSzttFYo2NRirU5SdZ/0 a ako vam to pomaha k jednoduchosti.
-
Alebo neriesite a zakaznik nema narok na ceny ako 7,99 pretoze to zo zakladu dph nevypocitate...
-
Pokud klient používá třeba desetiny či setiny halíře či centu, jistě nebude překvapen ani když se mu takové částky objeví v nějakém reportu.
Nebude prekvapeny, bude nespokojny.
Uvedl jsem tu několik konkrétních příkladů, kdy jsou přímo jednotkové ceny na webu uvedené v setinách centu nebo halíře. Když máme příklady z praxe, že to tak někdo používá, je trochu marné přesvědčovat mne, že to nejde, nemyslíte?
a) o nicom Vas nepresviedcam. (Bolo by to hadzanie hrachu o stenu)
b) to, ze Vy si viete osetrit jeden/dva vystupy nic nemeni na fakte, ze je to temna magia, ktoru musite v takom pripade opakovane riesit pri kazdom reporte. Preto som napisal, ze to povazujem za koncepcny nedostatok takeho pristupu.
c) Samozrejme viem si predstavit pripady, kedy moze byt Vas pristup uzitocnejsi.
Ne, pokud ta firma počítá například v setinách centu, bude naopak nespokojený, pokud nějaká jedna sestava bůhvíproč v setinách centu nebude. A pokud počítá v setinách centu, nebude tak mít jeden dva výstupy, ale bude v tom mít vše. A není to žádná temná magie, prostě se akorát místo v setinách počítá v desetitisícinách. V celém systému, od začátku do konce. To, že vy jste zvyklý zrovna na dvě desetinná místa, není žádný fyzikální zákon. Italové třeba počítali částky bez desetinných míst, pak přešli na euro a počítají (obvykle) na dvě desetinná místa. Některé měny se dělí na tisíciny. Ta dvě desetinná místa, která máme v ČR a SR, fakt nejsou nic, co by bylo vypálené v křemíku.
-
A není to žádná temná magie, prostě se akorát místo v setinách počítá v desetitisícinách. V celém systému, od začátku do konce.
Tuto kravinu ste si vymyslel len pre kontext tohoto vlakna, vsak. Akoze stotiny v mene a stotiny v sadzbe nam daju desat tisiciny a tym sa vyhneme problemu so zaokruhlovanim. To ze aktualne vam na sadzbu stacia stotiny nie je vypalene do kremiku, vy mentalny atlet. Pozrite si ako vypadaju sadzby v EU, nie len v sucastnosti ale aj historicky a skuste sa zamysliet(oxymoron?) nad moznostami ako budu vyzerat v buducnosti. A uz vobec to neriesi skutocnost ze nie vsetky meny su delene na stotiny.
-
Některé měny se dělí na tisíciny. Ta dvě desetinná místa, která máme v ČR a SR, fakt nejsou nic, co by bylo vypálené v křemíku.
Mal by ste mysliet na to ze to ako sa pocita DPH je vypalena v hlavach uctovnikov a hlavne danovakov. A ti pouzivaju kalkulacky ktore by default zaokruhluju na 2 desatinne miesta v kazdom kroku. A spravnost vydaneho danoveho dokladu posudi danovak na zaklade tej kalkulacky.
-
Děkuji všem za pomoc, změnil jsem datový typ na DECIMAL 15,4 a po třech dnech provozu to vypadá v pořádku. Nechtěl jsem způsobit flamewar, ale nenapadlo mě, že u takto jednoduchých operací dostanu takové výsledky.
Co se týče zaokrouhlování dokladů tak jsem s tím nikdy neměl problém a to ani v kontrolním hlášení, pokud má protistrana např. o haléř chybně základ daně a daň, a to i pokud má i nemá zaokrouhlovací položku. Je ale fakt, že to jsou absolutně bagatelní částky.
Ještě jednou děkuji.Hyp
-
Pozrieme sa ako definuje zaklad DPH zakon 222/2004 paragraf 22 odstavec 1:
[q]
Základom dane pri dodaní tovaru alebo služby je všetko, čo tvorí protihodnotu, ktorú dodávateľ prijal alebo má prijať od príjemcu plnenia alebo inej osoby za dodanie tovaru alebo služby, zníženú o daň. Do základu dane sa zahŕňa aj dotácia alebo príspevok, ktorý dodávateľ prijal alebo má prijať k cene tovaru alebo služby. [/q]
Se nedivim ze mas v hlave gulas, z takove bananove republiky.
Podivejme se na zdejsi (tj. cesky) zakon:
ZDPH - 235/2004 Sb., § 36, ods. 1:
(1) Základem daně je vše, co jako úplatu obdržel nebo má obdržet plátce za uskutečněné zdanitelné plnění, včetně částky na úhradu spotřební daně od osoby, pro kterou je zdanitelné plnění uskutečněno, nebo od třetí osoby, a to bez daně za toto zdanitelné plnění.
Tj existuje zaklad a existuje z ni pocitana dan.
A jak psal nekdo vejs, evidovat zaklad je pro platce idealni - kdyz pak mate dodavky i mimo CR, do EU nebo sveta mimo EU, kdy se meni sazba podle statu, nebo se upravuje sazba podle narizeni vlady.
A pak mam za to, ze v normalnizovane forme databaze, by neco jako DPH nemelo byt vpocitano do datovych radku polozek, ale pocitano az vne, podle kontextu - tj. subjektu ktery je prihlasen do eshopu.
-
V db by hlavne nemela byt trojice { bez-dph, dph%, s-dph }, ale jenom dvojice { bez-dph, dph% } nebo dvojice { dph%, s-dph }, protoze na danovem dokladu se DPH pocita az ze sumy vsech polozek. Jinak bude samozrejme dochazet k tomu, ze soucty bez-dph a s-dph nebudou sedet, kdyz je budete rozepisovat per radek.
U sebe tedy mam ty tri, ale maji povoleny null, a ctvrty sloupec, ktery rika co je primarni informace - zda cena s dph nebo bez dph - pak je to uz na skriptech, aby z toho vykoumal co chce, ale stejne se jeste bez dalsiho sloupce na korekci zaokrouhlovaci chyby neobejdu :)
V DB u zbozi ma byt spravne jen kod danove klasifikace (snizena, standardni apod.), tzn. ani zadne ceny. Ceny bez DPH maji byt v jine tabulce, kde mame i validitu od-do a kod zbozi. V dalsi tabulce mame sazby DPH dle kombinace danove klasifikace zbozi a danove klasifikace zakaznika (export apod.) a take s validitou od-do. To co tam ma tazatel je neudrzovatelna sebevrazda a drive nebo pozdeji se jim to vymsti. (jako treba tento rok ;-)
-
Konecne rozumny pohled!
-
Pozrieme sa ako definuje zaklad DPH zakon 222/2004 paragraf 22 odstavec 1:
[q]
Základom dane pri dodaní tovaru alebo služby je všetko, čo tvorí protihodnotu, ktorú dodávateľ prijal alebo má prijať od príjemcu plnenia alebo inej osoby za dodanie tovaru alebo služby, zníženú o daň. Do základu dane sa zahŕňa aj dotácia alebo príspevok, ktorý dodávateľ prijal alebo má prijať k cene tovaru alebo služby. [/q]
Se nedivim ze mas v hlave gulas, z takove bananove republiky.
Podivejme se na zdejsi (tj. cesky) zakon:
ZDPH - 235/2004 Sb., § 36, ods. 1:
(1) Základem daně je vše, co jako úplatu obdržel nebo má obdržet plátce za uskutečněné zdanitelné plnění, včetně částky na úhradu spotřební daně od osoby, pro kterou je zdanitelné plnění uskutečněno, nebo od třetí osoby, a to bez daně za toto zdanitelné plnění.
Tj existuje zaklad a existuje z ni pocitana dan.
A jak psal nekdo vejs, evidovat zaklad je pro platce idealni - kdyz pak mate dodavky i mimo CR, do EU nebo sveta mimo EU, kdy se meni sazba podle statu, nebo se upravuje sazba podle narizeni vlady.
A pak mam za to, ze v normalnizovane forme databaze, by neco jako DPH nemelo byt vpocitano do datovych radku polozek, ale pocitano az vne, podle kontextu - tj. subjektu ktery je prihlasen do eshopu.
Tie zakony oba hovoria o tom istom, len malinko inak formulovane. Zaklad dane je ciastka od zakaznika minus dan. Ani v vo vasomzakone sa nepise o tom ze ciastka od zakaznika by mal by zaklad plus dan.
-
V db by hlavne nemela byt trojice { bez-dph, dph%, s-dph }, ale jenom dvojice { bez-dph, dph% } nebo dvojice { dph%, s-dph }, protoze na danovem dokladu se DPH pocita az ze sumy vsech polozek. Jinak bude samozrejme dochazet k tomu, ze soucty bez-dph a s-dph nebudou sedet, kdyz je budete rozepisovat per radek.
U sebe tedy mam ty tri, ale maji povoleny null, a ctvrty sloupec, ktery rika co je primarni informace - zda cena s dph nebo bez dph - pak je to uz na skriptech, aby z toho vykoumal co chce, ale stejne se jeste bez dalsiho sloupce na korekci zaokrouhlovaci chyby neobejdu :)
V DB u zbozi ma byt spravne jen kod danove klasifikace (snizena, standardni apod.), tzn. ani zadne ceny. Ceny bez DPH maji byt v jine tabulce, kde mame i validitu od-do a kod zbozi. V dalsi tabulce mame sazby DPH dle kombinace danove klasifikace zbozi a danove klasifikace zakaznika (export apod.) a take s validitou od-do. To co tam ma tazatel je neudrzovatelna sebevrazda a drive nebo pozdeji se jim to vymsti. (jako treba tento rok ;-)
To cim sa v prispevku zaoberate suvisi s normalizaciou DB a moznostou pouzivat viacere cenniky.
Ako pri ukladani zakladu dane (laicky ceny bez dph) riesite tento https://www.db-fiddle.com/f/2dtPBSzttFYo2NRirU5SdZ/0 problem?
-
To je ale definicie pojmu. To je sice hezký, ale pro téma diskuse zcela irelevantní.
Tady se řeší, jak cenu (+ dph atd) řešit v informačním systému. A tam držet cenu s DPH je naprosto špatně.
-
To je ale definicie pojmu. To je sice hezký, ale pro téma diskuse zcela irelevantní.
Tady se řeší, jak cenu (+ dph atd) řešit v informačním systému. A tam držet cenu s DPH je naprosto špatně.
Ta definicia pojmu ale urcuje aj to ako a z coho sa ma pocitat. Pisali to uctovnici ktori svojej praci rozumeju a vedia ze pocitat cenu zo zakladu dane je blbost, pretoze to nebude sediet. Tu mate dokaz: https://www.db-fiddle.com/f/2dtPBSzttFYo2NRirU5SdZ/0
-
To je ale definicie pojmu. To je sice hezký, ale pro téma diskuse zcela irelevantní.
Tady se řeší, jak cenu (+ dph atd) řešit v informačním systému. A tam držet cenu s DPH je naprosto špatně.
A tu mate priklad s ukladanim ceny (laicky ceny s dph) https://www.db-fiddle.com/f/gLsufiz9jJ4WbsX96LeEbs/0 Sedi uplne dokonale ;)
-
Tuto kravinu ste si vymyslel len pre kontext tohoto vlakna, vsak. Akoze stotiny v mene a stotiny v sadzbe nam daju desat tisiciny a tym sa vyhneme problemu so zaokruhlovanim. To ze aktualne vam na sadzbu stacia stotiny nie je vypalene do kremiku, vy mentalny atlet. Pozrite si ako vypadaju sadzby v EU, nie len v sucastnosti ale aj historicky a skuste sa zamysliet(oxymoron?) nad moznostami ako budu vyzerat v buducnosti. A uz vobec to neriesi skutocnost ze nie vsetky meny su delene na stotiny.
Je vtipné, že ve svém komentáři řešíte nesmysly, o kterých já jsem vůbec nepsal, prošpikujete to nadávkami – abyste na závěr v poslední větě slavnostně dospěl k tomu, co jsem psal já – totiž že některé měny se nedělí na setiny, ale na desetiny, tisíciny nebo se nedělí vůbec. Tak aspoň že jste to nakonec pochopil.
Mal by ste mysliet na to ze to ako sa pocita DPH je vypalena v hlavach uctovnikov a hlavne danovakov. A ti pouzivaju kalkulacky ktore by default zaokruhluju na 2 desatinne miesta v kazdom kroku. A spravnost vydaneho danoveho dokladu posudi danovak na zaklade tej kalkulacky.
Nechápu, proč pořád dokola opakujete něco, na co už tady několikrát zazněl protipříklad. Spočítejte si na té vaší kalkulačce, kolik by vydělal Amazon na S3, kdyby v každém kroku zaokrouhloval na 2 desetinná místa. A když už jste pochopil, že některé měny se dělí na tisíciny, zamyslete se nad tím, co by se dělo, kdyby tam počítali se zaokrouhlováním na dvě desetinná místa v každém kroku.
-
Nechápu, proč pořád dokola opakujete něco, na co už tady několikrát zazněl protipříklad. Spočítejte si na té vaší kalkulačce, kolik by vydělal Amazon na S3, kdyby v každém kroku zaokrouhloval na 2 desetinná místa.
A kolko by ten amazon zarobil ak by neeistovali zakony a financak, vsak :D
A když už jste pochopil, že některé měny se dělí na tisíciny, zamyslete se nad tím, co by se dělo, kdyby tam počítali se zaokrouhlováním na dvě desetinná místa v každém kroku.
Preco mi podsuvate ze meny delene na tisiciny by sa mali zaokruhlovat na 2 desatinne miesta? Uctovnikom v krajinach kde sa takato mena pouziva kalkulacka by default zaokruhluje na 3 desatinne miesta. Mam sa s vami bavit ako z malym chlapcom a explicitne pisat aj zrejme veci?
-
Preco mi podsuvate ze meny delene na tisiciny by sa mali zaokruhlovat na 2 desatinne miesta? Uctovnikom v krajinach kde sa takato mena pouziva kalkulacka by default zaokruhluje na 3 desatinne miesta. Mam sa s vami bavit ako z malym chlapcom a explicitne pisat aj zrejme veci?
Ne, máte se se mnou bavit jako malý chlapec s dospělým člověkem. Když napíšu, že měny mohou být bez desetinných míst a nebo dělené na tisíciny, vy na to reagujete komentářem, jaký je to nesmysl, který zakončíte tím, že měny mohou být dělené i na tisíciny, musíte psát i věci, které vám připadají zřejmé. Protože se ukazuje, že věci, které vám připadají zřejmé, často nejsou pravda.
-
Preco mi podsuvate ze meny delene na tisiciny by sa mali zaokruhlovat na 2 desatinne miesta? Uctovnikom v krajinach kde sa takato mena pouziva kalkulacka by default zaokruhluje na 3 desatinne miesta. Mam sa s vami bavit ako z malym chlapcom a explicitne pisat aj zrejme veci?
Ne, máte se se mnou bavit jako malý chlapec s dospělým člověkem. Když napíšu, že měny mohou být bez desetinných míst a nebo dělené na tisíciny, vy na to reagujete komentářem, jaký je to nesmysl, který zakončíte tím, že měny mohou být dělené i na tisíciny, musíte psát i věci, které vám připadají zřejmé. Protože se ukazuje, že věci, které vám připadají zřejmé, často nejsou pravda.
So naozaj rad ze vsetko co mam spolocne s clovekon vasich kvalit, je par riadkov v diskusii a nic viac. Ked uz mate potrebu pisat o tom co som napisal tak ma citujte a nefabuljte.
A ak sa uzodvolavate na priklad, tak pouzite nieco co je mozne overit, nie len nejaku vasu dalsiu fabulaciu.
Moj priklad mate tu:
Ulozeny zaklad a cena dopocitana: https://www.db-fiddle.com/f/2dtPBSzttFYo2NRirU5SdZ/0
Ulozena cena a dopocitany zaklad: https://www.db-fiddle.com/f/gLsufiz9jJ4WbsX96LeEbs/0
Zistite ze ukladanie zakladu je ohybak na ktory musite aplikovat rovnak. Kdezto pri ulozenej cene a dopocitanom zaklade cisla sedia bez akehokolvek ohybaku a rovnaku.
Ad delenie meny na stotiny, tisiciny, etc: kludne si tam doplnte SET lc_monetary TO "kod_pre_krajinu"; a zistite ze to nema ziadny vplyv na to co tu riesime a je to len vyhradne vas informacny sum.
-
Způsob uložení toho či onoho je jen jedním z mnoha aspektů, který se řeší při návrhu architektury systému.
Ale ani zdaleka ne jediným. A dost často se vyplatí použít jeden rovnák na ohýbak na místě A, než tři rovnáky na místech B, C a D.
Ale to byste jako superznalý expert měl dávno vědět.
-
Způsob uložení toho či onoho je jen jedním z mnoha aspektů, který se řeší při návrhu architektury systému.
Ale ani zdaleka ne jediným. A dost často se vyplatí použít jeden rovnák na ohýbak na místě A, než tři rovnáky na místech B, C a D.
Ale to byste jako superznalý expert měl dávno vědět.
Ak dokazete s presnej ulozenej ceny dopocitat presny zaklad, tak aky rovnak na miestach B, C, D potrebujete. Ten zaklad sice dopocitavate ale na chlp sedi stym ako by ste ho ukladal. Kdezto cena dopocitana zo zakladu sa rozchadza stym ako by ste ju mal ulozenu.
-
A ak sa uzodvolavate na priklad, tak pouzite nieco co je mozne overit, nie len nejaku vasu dalsiu fabulaciu.
Moj priklad mate tu:
Ulozeny zaklad a cena dopocitana: https://www.db-fiddle.com/f/2dtPBSzttFYo2NRirU5SdZ/0
Ulozena cena a dopocitany zaklad: https://www.db-fiddle.com/f/gLsufiz9jJ4WbsX96LeEbs/0
Zistite ze ukladanie zakladu je ohybak na ktory musite aplikovat rovnak. Kdezto pri ulozenej cene a dopocitanom zaklade cisla sedia bez akehokolvek ohybaku a rovnaku.
Asi byste se neměl vyjadřovat o výpočtu DPH, když neovládáte matematiku na úrovni prvního stupně základní školy (rovnice).
-
Zistite ze ukladanie zakladu je ohybak na ktory musite aplikovat rovnak. Kdezto pri ulozenej cene a dopocitanom zaklade cisla sedia bez akehokolvek ohybaku a rovnaku.
Nemusíte aplikovat žádný rovnák, pokud použijete totožnou logiku a cenu s DPH budete VŽDY vypočítávat z ceny bez DPH a daně.
Jediná nevýhoda je, že vám nemusí vždy vycházet ceny s DPH kulaté - ale to není ani tak problém účetní, jako spíš marketingový (rohlík nebude za 2,90 ale třeba za 2,89).
Takže si jen stačí ujasnit, jak důležité pro mně je, aby byly ceny s DPH vždy kulaté bez nežádoucích setin - pokud hodně, tak se asi vyplatí je použít jako základ pro výpočty, pokud ne, může být výhodnější mít jako základ cenu bez DPH.
-
A ak sa uzodvolavate na priklad, tak pouzite nieco co je mozne overit, nie len nejaku vasu dalsiu fabulaciu.
Moj priklad mate tu:
Ulozeny zaklad a cena dopocitana: https://www.db-fiddle.com/f/2dtPBSzttFYo2NRirU5SdZ/0
Ulozena cena a dopocitany zaklad: https://www.db-fiddle.com/f/gLsufiz9jJ4WbsX96LeEbs/0
Zistite ze ukladanie zakladu je ohybak na ktory musite aplikovat rovnak. Kdezto pri ulozenej cene a dopocitanom zaklade cisla sedia bez akehokolvek ohybaku a rovnaku.
Asi byste se neměl vyjadřovat o výpočtu DPH, když neovládáte matematiku na úrovni prvního stupně základní školy (rovnice).
Ak si nedokazete spustit priklad, ktory vam povie ci je dane tvrdenie spravne tak poproste niekoho svojpravneho.
-
Způsob uložení toho či onoho je jen jedním z mnoha aspektů, který se řeší při návrhu architektury systému.
Ale ani zdaleka ne jediným. A dost často se vyplatí použít jeden rovnák na ohýbak na místě A, než tři rovnáky na místech B, C a D.
Ale to byste jako superznalý expert měl dávno vědět.
Ak dokazete s presnej ulozenej ceny dopocitat presny zaklad, tak aky rovnak na miestach B, C, D potrebujete. Ten zaklad sice dopocitavate ale na chlp sedi stym ako by ste ho ukladal. Kdezto cena dopocitana zo zakladu sa rozchadza stym ako by ste ju mal ulozenu.
Co ve Vaší terminilogii znamená rovnák? Pokud se jako základ pro výpočty použije datový typ float nebo nějaký odvozený, budou operace násobení a sčítání komutativní, ale obecně ne asociativní a distributivní. Poslední dvě vlastnosti jsou splněny jen do jisté odchylky. Všechny tři vlastnosti mohou být při účetních operacích potřeba. Když k tomu přidáme požadavek, že pro reálnou měnu je vhodné prezentovat data s konečnou docela malou přesností a v hezké podobě, nemůžeme problém nikdy vyřešit. Můžeme se snažit eliminovat důsledky, počítat interně s vyšší přesností, vybírat precizně pořadí operací, ale boj je to marný. Obecně je špatný nápad problém zhoršovat nadbytečným zaokrouhlovánám mezivýpočtů. Výsledky mezivýpočtů ale na fakturách mohou vystupovat a není v mé moci říci, jestli je lepší pracovat se zaokrouhlenými hodnotami dle prezentované formy, nebo držet pro výpočty přesněji, ale nepatrně odchýlené od vytištěných hodnot.
Pár příkladů je i na wiki: https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems
-
Zistite ze ukladanie zakladu je ohybak na ktory musite aplikovat rovnak. Kdezto pri ulozenej cene a dopocitanom zaklade cisla sedia bez akehokolvek ohybaku a rovnaku.
Nemusíte aplikovat žádný rovnák, pokud použijete totožnou logiku a cenu s DPH budete VŽDY vypočítávat z ceny bez DPH a daně.
Jediná nevýhoda je, že vám nemusí vždy vycházet ceny s DPH kulaté - ale to není ani tak problém účetní, jako spíš marketingový (rohlík nebude za 2,90 ale třeba za 2,89).
Takže si jen stačí ujasnit, jak důležité pro mně je, aby byly ceny s DPH vždy kulaté bez nežádoucích setin - pokud hodně, tak se asi vyplatí je použít jako základ pro výpočty, pokud ne, může být výhodnější mít jako základ cenu bez DPH.
Ale je to problem uctovny. Na ktory sa musi aplikovat rovnak. To ako to pocitate jedno nie je, v jednom pripade delite v druhom nasobite a v oboch pripadoch zaokruhlujete. Kedze koeficient ktorim nasobite/delite je vzdy vacsi alebo rovny 1 z vyrazu 1+sadzba/100 tak v pripade nasobenia su intervaly vacsie ako hodnota na ktoru sa zaokruhluje.
Vy musite zauctovat nielen vydane doklady ale aj prijate doklady. Ak zauctujete doklad na ktorom je 2,90 ale uctovnictvo vam tvrdi ze je na nom 2.89, a z takychto udajov si opdpocitate naklady z prijmov pre vykazanie dane z prijmu, tak si budte isty ze ten problem nebude akurat v marketingovej rovine.
-
Způsob uložení toho či onoho je jen jedním z mnoha aspektů, který se řeší při návrhu architektury systému.
Ale ani zdaleka ne jediným. A dost často se vyplatí použít jeden rovnák na ohýbak na místě A, než tři rovnáky na místech B, C a D.
Ale to byste jako superznalý expert měl dávno vědět.
Ak dokazete s presnej ulozenej ceny dopocitat presny zaklad, tak aky rovnak na miestach B, C, D potrebujete. Ten zaklad sice dopocitavate ale na chlp sedi stym ako by ste ho ukladal. Kdezto cena dopocitana zo zakladu sa rozchadza stym ako by ste ju mal ulozenu.
Co ve Vaší terminilogii znamená rovnák? Pokud se jako základ pro výpočty použije datový typ float nebo nějaký odvozený, budou operace násobení a sčítání komutativní, ale obecně ne asociativní a distributivní. Poslední dvě vlastnosti jsou splněny jen do jisté odchylky. Všechny tři vlastnosti mohou být při účetních operacích potřeba. Když k tomu přidáme požadavek, že pro reálnou měnu je vhodné prezentovat data s konečnou docela malou přesností a v hezké podobě, nemůžeme problém nikdy vyřešit. Můžeme se snažit eliminovat důsledky, počítat interně s vyšší přesností, vybírat precizně pořadí operací, ale boj je to marný. Obecně je špatný nápad problém zhoršovat nadbytečným zaokrouhlovánám mezivýpočtů. Výsledky mezivýpočtů ale na fakturách mohou vystupovat a není v mé moci říci, jestli je lepší pracovat se zaokrouhlenými hodnotami dle prezentované formy, nebo držet pro výpočty přesněji, ale nepatrně odchýlené od vytištěných hodnot.
Pár příkladů je i na wiki: https://en.wikipedia.org/wiki/Floating-point_arithmetic#Accuracy_problems
Lenze pre ukladanie grosov urcite float ani double pouzit nechcete, pri dost vysokych cislach sa vam zacnu stracat haliere, koruny, desiatky korun. Je to dane tym ze vo float je cislo ulozene ako mantisa, ktora ma urcitu maximalnu velkost nasobenu exponentom.
Cize pouzijete na jednoduchsich DB decimal (ktory je ulozeny podobne ako BCD) alebo pouzijete typ premenu ktory je ulozeny ako integer s tym ze pri vypoctoch sa transparentne deli podielom platnym pre danu menu (napr 100 pre euro).
Ak nechceme zbytocne komplikovat vypocty tak ukladame cenu a zaklad DPH dopocitavane, a ziadne dodatocne vypocty ani zaokruhlenia nie su potrebne, pretoze zaklad z ceny vieme vypocitat presne, kdezto cenu zo zakladu nie. To ze je to fakt som ukazal na priklade a v predoslom prispevku som aj vysvetlil preco to tak je.
-
Ak nechceme zbytocne komplikovat vypocty tak ukladame cenu a zaklad DPH dopocitavane, a ziadne dodatocne vypocty ani zaokruhlenia nie su potrebne, pretoze zaklad z ceny vieme vypocitat presne, kdezto cenu zo zakladu nie. To ze je to fakt som ukazal na priklade a v predoslom prispevku som aj vysvetlil preco to tak je.
Uz s tim fakt dej pokoj. Nic ti ani ten zpetny vypocet nepocita presne.
Rekneme ze mas propisku za 1.25 eur vcetne dph v sazbe 23%.
Pri tvem vypoctu vyjde zaklad 1.02 a dan 0.23 eur.
Ale ten samy zaklad ti vyjde pri cene 1.26 eur, tj. 1.02 ale dan bude 0.24 eur.
A ted mi vysvetli, je 1.02 + 23% z 1.02 tedy 1.25 nebo 1.26 ??
je 102 + 23% z 102 tedy 125 nebo 126 na fakture se sto propiskami ruznych barev.
Anebo to vezmes zas od konce, jako 125, a spoctes zaklad 101.63 a dan 23.37 - to ten provozoval eshopu bude fakt moc rad, ze namisto 100 * 1.02 vydelal najednou jen 101.63. Ze on blbec si radeji nezvolil cenu 1.26 a neprenesl ten centik na zakaznika.. ale holt, konkurence mu to nedovoli zdrazovat!
Proto veskery normalni biz u platcu jede na cenach bez dane, krat pocet kusu na radku, pak suma, a az se pocita dan, ktera se vybere od toho, od koho se ma vybirat.
Tj. FA s propiskama bude jako:
100*1.02 = 102 zaklad, 23% sazba, 23.46 dan, 125.46 k platbe prevodem, nebo 125.45 pri platbe hotove.
A vis ze se zaokrouhluje u vas v cobolistanu na 0.05 nasobky od 2022 pro platby v hotovosti?
Nebo nam zas budes tvrdit ze zaokrouhovani je no-no-no?
Samozrejme to zaokrouhovani je mimo DPH system, ale uvadet to explicitne musis, pac to pak spada pod vynosy ci naklady od zaokrouhlovani.
-
Rekneme ze mas propisku za 1.25 eur vcetne dph v sazbe 23%.
...
Tj. FA s propiskama bude jako:
100*1.02 = 102 zaklad, 23% sazba, 23.46 dan, 125.46 k platbe prevodem, nebo 125.45 pri platbe hotove.
Jako, že jedna propiska stojí 1,25€ a 100 propisek stojí 125,46€. Tak to je zajímavej eshop... ;-)
-
To už je na eshopu, zda bude aplikovat matematické zaokrouhlování (někdy nahoru někdy dolů, ono se to nejspíš nějak nakonec pokrátí na hodnotu blízkou nule), anebo bude zaokrouhlovat celkovou cenu vždy jedině nahoru (a nemůže na tom nic ztratit).
-
Asi byste se neměl vyjadřovat o výpočtu DPH, když neovládáte matematiku na úrovni prvního stupně základní školy (rovnice).
Ak si nedokazete spustit priklad, ktory vam povie ci je dane tvrdenie spravne tak poproste niekoho svojpravneho.
Příklad, který ukazuje, že ten kód neumíte správně napsat, si spustit umím. Ono není divu, že to neumíte napsat, když nerozumíte ani té aritmetice (učivo 1. stupně ZŠ), která je za tím.
-
Ak nechceme zbytocne komplikovat vypocty tak ukladame cenu a zaklad DPH dopocitavane, a ziadne dodatocne vypocty ani zaokruhlenia nie su potrebne, pretoze zaklad z ceny vieme vypocitat presne, kdezto cenu zo zakladu nie. To ze je to fakt som ukazal na priklade a v predoslom prispevku som aj vysvetlil preco to tak je.
Uz s tim fakt dej pokoj. Nic ti ani ten zpetny vypocet nepocita presne.
Rekneme ze mas propisku za 1.25 eur vcetne dph v sazbe 23%.
Pri tvem vypoctu vyjde zaklad 1.02 a dan 0.23 eur.
Ale ten samy zaklad ti vyjde pri cene 1.26 eur, tj. 1.02 ale dan bude 0.24 eur.
A ted mi vysvetli, je 1.02 + 23% z 1.02 tedy 1.25 nebo 1.26 ??
je 102 + 23% z 102 tedy 125 nebo 126 na fakture se sto propiskami ruznych barev.
Anebo to vezmes zas od konce, jako 125, a spoctes zaklad 101.63 a dan 23.37 - to ten provozoval eshopu bude fakt moc rad, ze namisto 100 * 1.02 vydelal najednou jen 101.63. Ze on blbec si radeji nezvolil cenu 1.26 a neprenesl ten centik na zakaznika.. ale holt, konkurence mu to nedovoli zdrazovat!
Proto veskery normalni biz u platcu jede na cenach bez dane, krat pocet kusu na radku, pak suma, a az se pocita dan, ktera se vybere od toho, od koho se ma vybirat.
Tj. FA s propiskama bude jako:
100*1.02 = 102 zaklad, 23% sazba, 23.46 dan, 125.46 k platbe prevodem, nebo 125.45 pri platbe hotove.
A vis ze se zaokrouhluje u vas v cobolistanu na 0.05 nasobky od 2022 pro platby v hotovosti?
Nebo nam zas budes tvrdit ze zaokrouhovani je no-no-no?
Samozrejme to zaokrouhovani je mimo DPH system, ale uvadet to explicitne musis, pac to pak spada pod vynosy ci naklady od zaokrouhlovani.
Ze dodnes zijete v iluzii ze vas ucitelia matiky sikanovali? :D
Ja netvrdim ze zaokruhlovanie je fuj, ja tvrdim ze s nim treba vediet pracovat tak aby boli danovaci spokojny.
Ad coboli zaokruhluju na 5 centov. Ako som uz ukazal pred tym, je irelevantne na ake diely sa deli mena. Je jedno ci jeto 100, 1000 alebo 20 dielov. Nebudem riesit toho cobola, od toho su tu organy cinne v trestnom konani, aby riesili nenavistne prejavy.
Nie len z hladiska matiky ale aj z hladiska logiky tu bluznite. Ak chcte dat obchodnikovi moznost aby mohol korigovat ceny podla potreby tak by mal mat k dispozicii kopletnu mnozinu cien, to ale nie je mozne pri vypocte ceny zo zakladu DPH, ako som uzpred tym tiez ukazal.
Co sa tyka "cien bez DPH". Neeistuju ceny bez DHP. Ak niekomu predavate bez toho aby ste odvadzal dph, tak mu uctujete ceny nie z maloobchodneho cennika, ale z velkoobhodneho cennika, v ktorom ceny mozu(nemusia) byt totozne so zakladni dph z maloobchodneho cennika. Akurat sa na takom danovom doklade neuvadzaju sadzby DPH pretoze su nulove.
-
Asi byste se neměl vyjadřovat o výpočtu DPH, když neovládáte matematiku na úrovni prvního stupně základní školy (rovnice).
Ak si nedokazete spustit priklad, ktory vam povie ci je dane tvrdenie spravne tak poproste niekoho svojpravneho.
Příklad, který ukazuje, že ten kód neumíte správně napsat, si spustit umím. Ono není divu, že to neumíte napsat, když nerozumíte ani té aritmetice (učivo 1. stupně ZŠ), která je za tím.
Co sa vam nezda ze tam nasobim/delim 1.23? Skuste si to aritmeticky prebrat.
Na db-fiddle je dobre ze mozete ten priklad korigovat a korekciu publikovat. Tak len nemelte hubou a predvedte sa.
-
To už je na eshopu, zda bude aplikovat matematické zaokrouhlování (někdy nahoru někdy dolů, ono se to nejspíš nějak nakonec pokrátí na hodnotu blízkou nule), anebo bude zaokrouhlovat celkovou cenu vždy jedině nahoru (a nemůže na tom nic ztratit).
Pri samotnych cenach jeto nejak tak ako pisete. Problem nastane pri suhrnoch za jednotlive sadzby. Aby tie sadzby sedeli tak musite pocitat sumu zakladu zo sum cien. Takze moze stratit na pokute od financaku pre chyby na vydanych danovych dokladoch.
-
Co sa tyka "cien bez DPH". Neeistuju ceny bez DHP. Ak niekomu predavate bez toho aby ste odvadzal dph, tak mu uctujete ceny nie z maloobchodneho cennika, ale z velkoobhodneho cennika, v ktorom ceny mozu(nemusia) byt totozne so zakladni dph z maloobchodneho cennika. Akurat sa na takom danovom doklade neuvadzaju sadzby DPH pretoze su nulove.
Co to meles za kraviny? Na jakom dokladu je nulova DPH? Na dokladu ve velkoobchode je podle tebe nulova DPH?
Ty kokos. Tohle je slusnej matros.
Cena bez DPH se samozrejme uvadi. Na kazdem dokladu. I tom, ktery je (dle tvejo slovniku) v maloobchode.
-
Co sa tyka "cien bez DPH". Neeistuju ceny bez DHP. Ak niekomu predavate bez toho aby ste odvadzal dph, tak mu uctujete ceny nie z maloobchodneho cennika, ale z velkoobhodneho cennika, v ktorom ceny mozu(nemusia) byt totozne so zakladni dph z maloobchodneho cennika. Akurat sa na takom danovom doklade neuvadzaju sadzby DPH pretoze su nulove.
Co to meles za kraviny? Na jakom dokladu je nulova DPH? Na dokladu ve velkoobchode je podle tebe nulova DPH?
Ty kokos. Tohle je slusnej matros.
Cena bez DPH se samozrejme uvadi. Na kazdem dokladu. I tom, ktery je (dle tvejo slovniku) v maloobchode.
Zaklad DPH nie je cena, i ked sa mu slangovo hovori cena bez DPH.
-
Citace zákon 235/2004 j, paragraf 29 - daňové doklady
(1) Daňový doklad musí obsahovat tyto údaje:
.....
i) jednotkovou cenu bez daně a slevu, není-li obsažena v jednotkové ceně,
Sám seš slang. Dál to nemá cenu jakkoli komentovat. Nejhorší je debata s někým, kdo naprosto netuší, o čem ta debata je.
-
Mimochodem, pokud by sis dotyčný paragraf přečetl, tak zjistíš, že "cena s DPH" na danovem dokladu vůbec nemusí být. Pouze cen bez DPH + sazba a vyčíslená DPH.
Toliko k celé té diskusi o tom, jak se počítá DPH a z čeho.
Stejně tak finančák, pokud kontroluje daně, tak je nedělá tak, že vezme cenu s DPH a z té spočte DPH, ale přesně naopak - vezme cenu bez DPH a z té spočítá, kolik činí DPH.
Víc to fakt nemá smysl komentovat.
V danovem priznání na DPH vůbec není částka s DPH - jediné částky, které se tam objevují, jsou základy daně a DPH (hádej proč).
Stejně tak v kontrolním hlášení se objevuje pouze cena bez DPH (základ DPH) a DPH (hádej proč).
Cena s DPH vůbec nikoho nezajímá. Jenom koncového spotřebitele v obchodě, proto se tam uvádí.
-
Citace zákon 235/2004 j, paragraf 29 - daňové doklady
(1) Daňový doklad musí obsahovat tyto údaje:
.....
i) jednotkovou cenu bez daně a slevu, není-li obsažena v jednotkové ceně,
Sám seš slang. Dál to nemá cenu jakkoli komentovat. Nejhorší je debata s někým, kdo naprosto netuší, o čem ta debata je.
Mate to tam doslovne napisane, cena bez dane. Cize cena - dan. Dostanete ju tak ze z ceny vypocitate dan a odcitate od ceny.
-
Ty už se v tom regulerně motáš.
Tvrdíš tady, že na danovem dokladu "cena bez daně" není, že to je jen slang
Dokážeme ti opak
a zase tady začneš plácat dokolečka další nesmysly.
-
Mimochodem, sám sis naběhl. Rád tady používáš pojem "základ daně". A víš, co to znamená základ daně? Ano, je to základ něčeho, co se od základu odvíjí.
Základ daně se jmenáje "základ", protože je základem pro výpočet DPH.
Kdyby se daň počítala z ceny s DPH, tak se "základ daně" bude říkat ceně s DPH, a ne ceně bez DPH.
Už dost prosímtě.
-
Mimochodem, sám sis naběhl. Rád tady používáš pojem "základ daně". A víš, co to znamená základ daně? Ano, je to základ něčeho, co se od základu odvíjí.
Základ daně se jmenáje "základ", protože je základem pro výpočet DPH.
Kdyby se daň počítala z ceny s DPH, tak se "základ daně" bude říkat ceně s DPH, a ne ceně bez DPH.
Už dost prosímtě.
Skuste si precitat zakonnik ako definuje zaklad DPH. A skuste si najst ci definuje cenu bez DPH.
-
Lenze pre ukladanie grosov urcite float ani double pouzit nechcete, pri dost vysokych cislach sa vam zacnu stracat haliere, koruny, desiatky korun. Je to dane tym ze vo float je cislo ulozene ako mantisa, ktora ma urcitu maximalnu velkost nasobenu exponentom.
Cize pouzijete na jednoduchsich DB decimal (ktory je ulozeny podobne ako BCD) alebo pouzijete typ premenu ktory je ulozeny ako integer s tym ze pri vypoctoch sa transparentne deli podielom platnym pre danu menu (napr 100 pre euro).
Ak nechceme zbytocne komplikovat vypocty tak ukladame cenu a zaklad DPH dopocitavane, a ziadne dodatocne vypocty ani zaokruhlenia nie su potrebne, pretoze zaklad z ceny vieme vypocitat presne, kdezto cenu zo zakladu nie. To ze je to fakt som ukazal na priklade a v predoslom prispevku som aj vysvetlil preco to tak je.
Float má nevýhody, o kterých jsem psal. Ale nemám pocit, že by je typ decimal(x, y) řešil. Obecně může záležet na pořadí operací i u decimal. Pokud navíc data prezentujete zaokrouhlená, musíte se rozhodnout, jestli se budete držet prezentované přesnosti (haléř, setina haléře atp.), nebo budete interně používat vyšší přesnost a pak nebudou dokonale odpovídat prezentované mezivýsledky s výsledky spočtenými.
Jen si představte, že na položku za 0,0007 korony dá někdo akční nabídku tři za cenu dvou. A pak se na faktuře těchto položek objeví desetitisíce. S typem decimal(x, 4) bude výsledek záviset na pořadí operací a uplatnění slevy. A je úplně jedno, jestli počítáte DPH z daňového základu, nebo postupujete naopak. Jiní tu citovali pasáže o povinných údajích na fakturách; většinou je zvykem vycházet z nutných údajů a pak dle okolností doplnit nepovinné: Occamova břitva...
-
Lenze pre ukladanie grosov urcite float ani double pouzit nechcete, pri dost vysokych cislach sa vam zacnu stracat haliere, koruny, desiatky korun. Je to dane tym ze vo float je cislo ulozene ako mantisa, ktora ma urcitu maximalnu velkost nasobenu exponentom.
Cize pouzijete na jednoduchsich DB decimal (ktory je ulozeny podobne ako BCD) alebo pouzijete typ premenu ktory je ulozeny ako integer s tym ze pri vypoctoch sa transparentne deli podielom platnym pre danu menu (napr 100 pre euro).
Ak nechceme zbytocne komplikovat vypocty tak ukladame cenu a zaklad DPH dopocitavane, a ziadne dodatocne vypocty ani zaokruhlenia nie su potrebne, pretoze zaklad z ceny vieme vypocitat presne, kdezto cenu zo zakladu nie. To ze je to fakt som ukazal na priklade a v predoslom prispevku som aj vysvetlil preco to tak je.
Float má nevýhody, o kterých jsem psal. Ale nemám pocit, že by je typ decimal(x, y) řešil. Obecně může záležet na pořadí operací i u decimal. Pokud navíc data prezentujete zaokrouhlená, musíte se rozhodnout, jestli se budete držet prezentované přesnosti (haléř, setina haléře atp.), nebo budete interně používat vyšší přesnost a pak nebudou dokonale odpovídat prezentované mezivýsledky s výsledky spočtenými.
Jen si představte, že na položku za 0,0007 korony dá někdo akční nabídku tři za cenu dvou. A pak se na faktuře těchto položek objeví desetitisíce. S typem decimal(x, 4) bude výsledek záviset na pořadí operací a uplatnění slevy. A je úplně jedno, jestli počítáte DPH z daňového základu, nebo postupujete naopak. Jiní tu citovali pasáže o povinných údajích na fakturách; většinou je zvykem vycházet z nutných údajů a pak dle okolností doplnit nepovinné: Occamova břitva...
Lenze je uplne jedno ako mate interne nakodenu aplikaciu. Ide o to aby ta aplikacia davala vystupy take ktore autorita uzna ako spravne.
Priebeh certifikacie pokladnicneho systemu (z praxe):
1. Danovak vas poziada aby ste si pre konkretne polozky nastavil konkretne ceny.
2. Potom vas poziada aby ste mu vytlacil danovy doklad s vyssie uvedenymi polozkami.
3. Zoberie kalkulacku a ten papier si prepocita
4a. Ak mu bude sediet tak pokladnicny system ziska certifikat a moze sa v krajine pouzivat.
4b. Ak mu nebude sediet tak vas posle prec a absolutne ho nebude zaujimat vas pohlad na vec.
Z toho plynie ze je idealne nakodit tu aplikaciu podla pochodov ktore pouziva danovak. A buddte si isty ze ten tu fakturu nebude pocitat tak aby mal medzivysledky na 4 desatinne miesta. Ak ju nakodite podla seba, tak ju budete musite ohnut tak aby davala pozadovane vystupy, co je zbytocna komplikacia ktora sa prejavi na zbytocne spalenom case a tym zvysenych nakladoch.
-
Zákon a finančák neuděluje žádné povolení k tomu, aby jsi mohl používat SW k účetním účelům. Můžeš používat jakýkoli software, který uznáš za vhodné. Nepotřebuješ žádnou certifikaci.
-
Skuste si precitat zakonnik ako definuje zaklad DPH. A skuste si najst ci definuje cenu bez DPH.
Ano, tímto jsme si už prošli. Z definice v žádném případě nevyplývá, že DPH se počíta z ceny s DPH a žím se dojde k ceně (základu) DPH.
Naopak, celý zákon o DPH, odstavec po odstavci, je napsán tak, že cena s DPH vůbec nikoho nezajímá, základem pro výpočet DPH je základ daně, a DPH se počítá tak, že se z ceny bez DPH vypočte DPH podle příslušné sazby.
Ono ani nemůže nijak záviset na ceně s DPH, protože tuto cenu nemáš v danovem priznání, cenu s DPH nemusíš mít na dokladech, cenu s DPH nemáš v kontrolním hlášení.
Kdyby to bylo tak, jak říkáš, jak by asi tak mohl finančák ověřit, že DPH byla vypočetena správně? Vždyt bys ji nemohl vůbec spočíst.
Mimochodem, celou diskusi můžeme definitivně ukončit.
Zákon explicitně říká, že výše daně se počítá tak, že se základ daně vynásobí sazbou. Cituji
Daň se vypočte jako
a) součin základu daně a sazby daně
Upřímně doufám, že s těmi bláboly o tom, že DPH počítáš z ceny s DPH už dáš konečně pokoj.
-
Co sa vam nezda ze tam nasobim/delim 1.23? Skuste si to aritmeticky prebrat.
Jenže to tam právě neděláte. V aritmetice je násobení a dělení komutativní, takže opravdu nezáleží na tom, zda napíšete a×x=y, nebo y/a=x pro nenulové a.
Vtip je v tom, že celou dobu řešíme zaokrouhlování, ale to vy v těch příkladech vůbec neřešíte. Spoléháte na nějaké výchozí chování, které ani neznáte, natož abyste věděl, zda vyhovuje vašim potřebám.
-
Zákon explicitně říká, že výše daně se počítá tak, že se základ daně vynásobí sazbou. Cituji
Daň se vypočte jako
a) součin základu daně a sazby daně
Nezapomeňte na to, že je v zákoně ještě písmeno b), druhý způsob výpočtu daně – rozdíl mezi částkou s daní a vypočteným základem daně.
-
Co sa vam nezda ze tam nasobim/delim 1.23? Skuste si to aritmeticky prebrat.
Jenže to tam právě neděláte. V aritmetice je násobení a dělení komutativní, takže opravdu nezáleží na tom, zda napíšete a×x=y, nebo y/a=x pro nenulové a.
Vtip je v tom, že celou dobu řešíme zaokrouhlování, ale to vy v těch příkladech vůbec neřešíte. Spoléháte na nějaké výchozí chování, které ani neznáte, natož abyste věděl, zda vyhovuje vašim potřebám.
Tu je presne vidiet ako sa vase bludy rozchadzaju s realitou. Realita je to co je napisane v dokumentacii. Vzhladom na to ako je typ MONEY definovany, tak zaokruhluje transparentne. Je to interne bigint, s tym ze pre matematicke operatory sa transparentne deli/nasobi 100 (pre meny s dvoma desatinnymi miestami). Chovanie pre decimal(*,2) bude rovnake.
Prestante bluznit a skorigujte ten priklad tak aby bol podla vas spravne. Memal by to byt problem, ak ste naozaj taky odbornik za akeho sa pasujete.
-
Zákon explicitně říká, že výše daně se počítá tak, že se základ daně vynásobí sazbou. Cituji
Daň se vypočte jako
a) součin základu daně a sazby daně
Nezapomeňte na to, že je v zákoně ještě písmeno b), druhý způsob výpočtu daně – rozdíl mezi částkou s daní a vypočteným základem daně.
Nezapomínám :) Jen pro tuto diskusi a vyvrácení pohádek předřečníka je tento bod nejdůležitější.
-
Tu je presne vidiet ako sa vase bludy rozchadzaju s realitou. Realita je to co je napisane v dokumentacii. Vzhladom na to ako je typ MONEY definovany, tak zaokruhluje transparentne. Je to interne bigint, s tym ze pre matematicke operatory sa transparentne deli/nasobi 100 (pre meny s dvoma desatinnymi miestami). Chovanie pre decimal(*,2) bude rovnake.
Prestante bluznit a skorigujte ten priklad tak aby bol podla vas spravne. Memal by to byt problem, ak ste naozaj taky odbornik za akeho sa pasujete.
Na tom je právě vidět, jak o tom vůbec nic nevíte. Zaokrouhlovat můžete v každém kroku výpočtu nebo až na konci. Zaokrouhlovat můžete vždy dolů, vždy nahoru, k nule, matematicky se zaokrouhlením pětky nahoru, dolů, k sudé – a spoustou dalších způsobů. Zaokrouhlovat dokonce teoreticky můžete postupně. A vy napíšete „zaokrouhlení je transparentní“. Celou dobu tu řešíme problém se zaokrouhlováním, vy napíšete příklad, u kterého vůbec nevíte, jak se zaokrouhluje, ale tváříte se, že je to určitě tak, jak to má být správně – aniž byste vůbec tušil, jak to má správně být.
-
Zákon explicitně říká, že výše daně se počítá tak, že se základ daně vynásobí sazbou. Cituji
Daň se vypočte jako
a) součin základu daně a sazby daně
Nezapomeňte na to, že je v zákoně ještě písmeno b), druhý způsob výpočtu daně – rozdíl mezi částkou s daní a vypočteným základem daně.
Nezapomínám :) Jen pro tuto diskusi a vyvrácení pohádek předřečníka je tento bod nejdůležitější.
Zabudate vsak najednu dolezitu sucast danoveho dokladu - suhrn DPH. Skuste si vytvorit nejaku fakturu aj so suhrnom dane a pocitajte ceny zo zakladu. Zistite ze vam nesedia sumy. Danovaka nezaujima jednotkova cena polozky, zaujima ho kolko mate zaplatit na DPH za jednotlive sadzby DPH.
-
Tu je presne vidiet ako sa vase bludy rozchadzaju s realitou. Realita je to co je napisane v dokumentacii. Vzhladom na to ako je typ MONEY definovany, tak zaokruhluje transparentne. Je to interne bigint, s tym ze pre matematicke operatory sa transparentne deli/nasobi 100 (pre meny s dvoma desatinnymi miestami). Chovanie pre decimal(*,2) bude rovnake.
Prestante bluznit a skorigujte ten priklad tak aby bol podla vas spravne. Memal by to byt problem, ak ste naozaj taky odbornik za akeho sa pasujete.
Na tom je právě vidět, jak o tom vůbec nic nevíte. Zaokrouhlovat můžete v každém kroku výpočtu nebo až na konci. Zaokrouhlovat můžete vždy dolů, vždy nahoru, k nule, matematicky se zaokrouhlením pětky nahoru, dolů, k sudé – a spoustou dalších způsobů. Zaokrouhlovat dokonce teoreticky můžete postupně. A vy napíšete „zaokrouhlení je transparentní“. Celou dobu tu řešíme problém se zaokrouhlováním, vy napíšete příklad, u kterého vůbec nevíte, jak se zaokrouhluje, ale tváříte se, že je to určitě tak, jak to má být správně – aniž byste vůbec tušil, jak to má správně být.
Viete vase teoretizovanie dokazat tym ze poskytnete priklad ktory je mozne overit? Alebo neviete. Nechajte si zbytocne teoretizovanie a dokazte ze mate pravdu.
-
Zabudate vsak najednu dolezitu sucast danoveho dokladu - suhrn DPH. Skuste si vytvorit nejaku fakturu aj so suhrnom dane a pocitajte ceny zo zakladu. Zistite ze vam nesedia sumy. Danovaka nezaujima jednotkova cena polozky, zaujima ho kolko mate zaplatit na DPH za jednotlive sadzby DPH.
Souhrn DPH je součet DPH za jednotlivé položky. Posčítat jednotlivé hodnoty fakt není žádný problém – teda pro většinu lidí.
-
Viete vase teoretizovanie dokazat tym ze poskytnete priklad ktory je mozne overit? Alebo neviete. Nechajte si zbytocne teoretizovanie a dokazte ze mate pravdu.
Příklad čeho konkrétně?
-
Viete vase teoretizovanie dokazat tym ze poskytnete priklad ktory je mozne overit? Alebo neviete. Nechajte si zbytocne teoretizovanie a dokazte ze mate pravdu.
Příklad čeho konkrétně?
Vy si nepamatate kontext diskusie? Nie je divu ze diskusie s vami vyzeraju tak ako vyzeraju.
Priklad pre vase tvrdenie. Tvrdite ze moj priklad je nespravny, tak ho upravte tak aby bol spravne a sucastne bol odrazom toho co tvrdite.
-
Zabudate vsak najednu dolezitu sucast danoveho dokladu - suhrn DPH. Skuste si vytvorit nejaku fakturu aj so suhrnom dane a pocitajte ceny zo zakladu. Zistite ze vam nesedia sumy. Danovaka nezaujima jednotkova cena polozky, zaujima ho kolko mate zaplatit na DPH za jednotlive sadzby DPH.
Souhrn DPH je součet DPH za jednotlivé položky. Posčítat jednotlivé hodnoty fakt není žádný problém – teda pro většinu lidí.
Problem to nie je ak teda ratate s tym ze aj v suhrne musi sediet zaklad, dph a cena pre kazdu sadzbu. A ak s tym ratate tak pocitate DPH z ceny, nie zo zakladu.
-
Teda vy s těmi počty fakt svádíte nerovný boj.
Příklad čeho konkrétně?
Vy si nepamatate kontext diskusie? Nie je divu ze diskusie s vami vyzeraju tak ako vyzeraju.
Priklad pre vase tvrdenie. Tvrdite ze moj priklad je nespravny, tak ho upravte tak aby bol spravne a sucastne bol odrazom toho co tvrdite.
Já si kontext diskuse pamatuju. Ale chtěl jsem po vás, abyste přesně formuloval zadání – třeba byste si při tom uvědomil, v čem děláte chyby. Vy už jste tu totiž jednu chybu popsal – a vůbec jste si neuvědomil, že je to chyba.
Mohl byste nám tedy jako ten certifikovaný expert odpovědět, proč ve vašem příkladu, který je podle vás správně, vychází, že pro cenu 8,11 Kč bez DPH je cena s DPH 9,97 Kč nebo taky 9,98 Kč? (Počítám s těmi vašimi DPH 23 %.) To si jako mám hodit korunou, jestli zákazníkovi naúčtuju DPH 1,86 Kč nebo 1,87 Kč? Můžete nám vysvětlit, proč v tom vašem příkladu, který je podle vás špatně, máte pro cenu 8,11 Kč bez DPH jako očekávanou částku s DPH 9,97 Kč a vadí vám, že vychází částka 9,98 Kč s DPH? Ona totiž při sazbě DPH 23 % je pro cenu bez daně 8,11 Kč správná daň 1,87 Kč tudíž cena s daní 9,98 Kč. Zkuste si to spočítat na jakékoli kalkulačce.
Machrujete tady, jak jste jediný, kdo to umí spočítat správně, přitom jste se na ty výsledky ani nepodíval.
Problem to nie je ak teda ratate s tym ze aj v suhrne musi sediet zaklad, dph a cena pre kazdu sadzbu. A ak s tym ratate tak pocitate DPH z ceny, nie zo zakladu.
Ne, jakási fiktivní DPH spočítaná ze součtu částek bez DPH fakt nemusí sedět na součet DPH. Do konce ani nemůže, právě kvůli zaokrouhlování. A nezáleží na tom, ze kterého směru to počítáte.
Například můžete mít následující fakturu (počítám s těmi vašimi oblíbenými 23 %):
Šroubek základ daně: 8,11 Kč 23% DPH: 1,87 Kč celkem: 9,98 Kč
Matička základ daně: 8,11 Kč 23% DPH: 1,87 Kč celkem: 9,98 Kč
Daň v sazbě 23 % celkem: 3,74 Kč
Celkem k úhradě: 19,96 Kč
Chcete některé z těch čísel na faktuře rozporovat? Nenapadlo vás třeba, že by celková DPH mohla být 3,73 Kč?
No a ten výpočet, který jste chtěl, máte tady: https://codepen.io/filipjirsak/pen/eYXZNQz Máte tam i zakomentovaný i kód, který zaokrouhluje stejně špatně, jako ty vaše příklady. To jen kdybyste si to chtěl porovnat. A světe div se, všechny výpočty sedí do halíře, ať to počítáte z jednoho směru nebo z druhého. I když si to přepnete na to vaše špatné zaokrouhlování.
Tak jsem zvědav, jestli jste chlap a ještě tu odpovíte.
-
pro cenu 8,11 Kč bez DPH je cena s DPH 9,97 Kč nebo taky 9,98 Kč?
Jsou správně obě. 9,98Kč podle §37 odst a) a 9,97Kč podle §37 odst b) tzv. výpočet shora (tedy pokud se bavíte o české legislativě, což sazba 23% trochu rozporuje, ale budiž)
Nechcete snad tvrdit, že za 9,97Kč (s 23% DPH) nelze nic prodat s odůvodněním, že by vám pak neseděl výpočet dle §37 odst a)? :-)
Máte plnou volnost zvolit si, zda DPH vypočítáte ze základu nebo z „ceny s DPH“. Např. v případě prodeje spotřebitelům dává víc smysl výpočet shora, abyste se nedostal do křížku se zákonem na ochranu spotřebitele a zákonem o cenách (viz ten příklad s propiskami https://forum.root.cz/index.php?topic=28374.msg397819#msg397819 (https://forum.root.cz/index.php?topic=28374.msg397819#msg397819)). Ale výběr je čistě na vás, co vám v dané situaci víc vyhovuje.
-
Jsou správně obě. 9,98Kč podle §37 odst a) a 9,97Kč podle §37 odst b) tzv. výpočet shora (tedy pokud se bavíte o české legislativě, což sazba 23% trochu rozporuje, ale budiž)
To není úplně přesné. Pro výpočet ze základu daně podle písmene a) je správně jen 9,98 Kč (při sazbě DPH 23 %). Pro výpočet shora podle písmena b) jsou správné obě, jak 9,97 Kč tak 9,98 Kč (logicky, z obou dvou dokážete vypočítat daň).
Každopádně když tu Death Walker celou dobu porovnává výpočty zdola a shora a tvrdí, že některý výpočet je špatně, nemůže to porovnávat na celkové částce 9,97 Kč, protože k té se není jak dostat výpočtem zdola.
Máte plnou volnost zvolit si, zda DPH vypočítáte ze základu nebo z „ceny s DPH“. Např. v případě prodeje spotřebitelům dává víc smysl výpočet shora, abyste se nedostal do křížku se zákonem na ochranu spotřebitele a zákonem o cenách (viz ten příklad s propiskami https://forum.root.cz/index.php?topic=28374.msg397819#msg397819 (https://forum.root.cz/index.php?topic=28374.msg397819#msg397819)). Ale výběr je čistě na vás, co vám v dané situaci víc vyhovuje.
O tom tady Death Walkera všichni přesvědčují už nutnou dobu, ale je to marný, je to marný, je to marný.
-
...
Zakon vam uklada zaplatit dan z protihodnoty ktoru ste dostal od zakaznika. To moze byt 9,97 alebo 9,98. V oboch pripadoch je zaklad dane 8,11. Ak ale budete pri vypoctoch operovat nie s tou protihodnotou, ale so zakladom dane, tak netusite ci ste zakaznikovi uctoval 9,97 alebo 9,98. Tusite preco sa tam udava ten zaklad dane. Nenapadlo vas hadam ze len pre to aby sme ukazali ze dokazeme spocitat cena-dph? Ten zaklad dane za polozku tam ani byt nemusi (zjednoduseny DD) len sadzba. V suhrne DPH ale uz musi byt zaklad aj na ZDD.
Mozno vas omyl plynie z toho ze si myslite ze zakaznikovy uctujete dan. Omyl, vy zakaznikovi uctujete cenu a z tej ceny FS uctuje vam dan podla sadzby. Preto je tam ten suhrn so sumami za jednotlive sadzby.
Takze ano do DB je spravne ukladat ceny vratane DPH a nie zaklad DPH. Aby sme vedeli kolko sme uctovali zakaznikovi. Su polozky ktorych cenu si neucite sam ale mate ju nariadenu. Napr. tabak, dajme tomu take cigarilo za 7,99 ecok...
K tej vasej fakture, suma cien za sadzbu 23% je 19,96. Zaklad DPH je 16,23 = round(cena/1.23; 2). DPH je 3,73 = cena - zaklad.
K tomu vase prikladu. Preco to robit zlozito, ked ako som ukazal ide to aj jednoducho. KISS (najdite si radsej co to znamena, nemam chut sa s vami pusinkovat). Napisete takuto obludnost, len koli tomu ze zakazdu cenu musite mat pravdu ze v DB budu ceny bez DPH?
Taktiez som dufal ze ten vas priklad bude v SQL, ked uz sa bavime o tom ci do db ulozit cenu s dph alebo zaklad dph... tvl, javascript, pritom je tolko krasnych jazykov, ako napriklad plsql. Njn, js, na monitore sami vyhadzali vyrazky...
Ako tu skaredu vec citam tak vy ste v omyle ze ak pocitam s datovym typom MONEY v postgrese tak sa zaokruhluje transparentne nadol? Otvorime si konzolu, spustime psql a skusime:
# SET lc_monetary to "cs_CZ";
SET
# SELECT '1,005'::money;
┌─────────┐
│ money │
├─────────┤
│ 1,01 Kč │
└─────────┘
(1 řádka)
Napada vas nejaka krajina kde su pre zaokruhlovanie meny ine pravidla, ak hej tak dajte kod, alebo si skuste sam.
-
jenom dvojice { bez-dph, dph% } nebo dvojice { dph%, s-dph }
S DPH, z tej idu vypocitat vsetky hodnoty bez DPH. Pri opacnom postupe tj. vypocet ceny s dph z ceny bez dph, nie je mozne koli zaokruhlavaniu pokryt niektore hodnoty...
Jsou správně obě. 9,98Kč podle §37 odst a) a 9,97Kč podle §37 odst b) tzv. výpočet shora (tedy pokud se bavíte o české legislativě, což sazba 23% trochu rozporuje, ale budiž)
To není úplně přesné. Pro výpočet ze základu daně podle písmene a) je správně jen 9,98 Kč (při sazbě DPH 23 %). Pro výpočet shora podle písmena b) jsou správné obě, jak 9,97 Kč tak 9,98 Kč (logicky, z obou dvou dokážete vypočítat daň).
Každopádně když tu Death Walker celou dobu porovnává výpočty zdola a shora a tvrdí, že některý výpočet je špatně, nemůže to porovnávat na celkové částce 9,97 Kč, protože k té se není jak dostat výpočtem zdola.
Máte plnou volnost zvolit si, zda DPH vypočítáte ze základu nebo z „ceny s DPH“. Např. v případě prodeje spotřebitelům dává víc smysl výpočet shora, abyste se nedostal do křížku se zákonem na ochranu spotřebitele a zákonem o cenách (viz ten příklad s propiskami https://forum.root.cz/index.php?topic=28374.msg397819#msg397819 (https://forum.root.cz/index.php?topic=28374.msg397819#msg397819)). Ale výběr je čistě na vás, co vám v dané situaci víc vyhovuje.
O tom tady Death Walkera všichni přesvědčují už nutnou dobu, ale je to marný, je to marný, je to marný.
Vy ste na drogach? Celu tuto saskaren roztocite koli tomu ze nakoniec napisete ze mam pravdu? Tj. ze z ceny (s DPH) dokazem vzdy vypocitat zaklad, kdezto zo zakladu nedokazem vypocitat vsetky ceny (s DPH).
-
Zakon vam uklada zaplatit dan z protihodnoty ktoru ste dostal od zakaznika.
Ne, zákon vám ukládá zaplatit daň spočítanou buď ze základu bez daně (písmeno a) nebo z celkové částky (písmeno b).
Ak ale budete pri vypoctoch operovat nie s tou protihodnotou, ale so zakladom dane, tak netusite ci ste zakaznikovi uctoval 9,97 alebo 9,98.
Když daň počítám podle písmene a) ze základu daně 8,11 Kč, bude celková částka vždy 9,98 Kč. Spočítejte si to.
Tusite preco sa tam udava ten zaklad dane.
Proto, aby se z něj spočítala daň postupem podle písmene a). Když se počítá daň z celkové částky, základ daně se vůbec uvádět nemusí (a pokud ho chcete zjistit, spočítáte ho jednoduše tak, že odečtete daň od celkové částky).
Ten zaklad dane za polozku tam ani byt nemusi (zjednoduseny DD) len sadzba.
No vida, takže to víte.
V suhrne DPH ale uz musi byt zaklad aj na ZDD.
V souhrnu není žádný základ, je tam suma základů, ze kterých byly spočítány částky daně v dané daňové sazbě. A u toho je součet těch daní.
Mozno vas omyl plynie z toho ze si myslite ze zakaznikovy uctujete dan. Omyl, vy zakaznikovi uctujete cenu a z tej ceny FS uctuje vam dan podla sadzby. Preto je tam ten suhrn so sumami za jednotlive sadzby.
Nikoli, daň se může počítat jak ze základu daně (podle písmene a) tak z celkové ceny dané položky (podle písmene b).
Takze ano do DB je spravne ukladat ceny vratane DPH a nie zaklad DPH. Aby sme vedeli kolko sme uctovali zakaznikovi.
Ne, v databázi klidně můžete ukládat základ daně a k tomu sazbu. Kolik se účtovalo zákazníkovi zjistí všichni kromě vás tak, že sečtou základ daně a vypočtenou daň. Jako můžete klidně zákazníkovi účtovat méně, ale pak ten rozdíl budete muset uhradit ze svého, protože státu musíte odvést vypočtenou daň. A pokud byste zákazníkovi zkusil účtovat více, než je součet základu a daně, bude to nezdaněný příjem, který vám pak spočítá FÚ. (Nebavíme se samozřejmě o zaokrouhlování na celé koruny v souvislosti s hotovostními platbami.)
Su polozky ktorych cenu si neucite sam ale mate ju nariadenu. Napr. tabak, dajme tomu take cigarilo za 7,99 ecok...
V takovém případě asi použiju metodu výpočtu shora podle písmene b) zákona. To ale neznamená, že tak musí postupovat i ten, kdo tabák neprodává.
K tej vasej fakture, suma cien za sadzbu 23% je 19,96. Zaklad DPH je 16,23 = round(cena/1.23; 2). DPH je 3,73 = cena - zaklad.
Ne, to máte vypočítané špatně. Na té faktuře není žádný základ DPH 16,23. DPH se počítá po položkách faktury.
K tomu vase prikladu. Preco to robit zlozito, ked ako som ukazal ide to aj jednoducho.
Sice to máte jednoduše, ale špatně.
Napisete takuto obludnost, len koli tomu ze zakazdu cenu musite mat pravdu ze v DB budu ceny bez DPH?
Napsal jsem vám to, abyste někde viděl ty částky vypočtené správně. A abyste viděl, že to vychází stejně, ať tu DPH vypočítám zdola nebo shora (samozřejmě pokud se k té částce dostat jde).
Taktiez som dufal ze ten vas priklad bude v SQL, ked uz sa bavime o tom ci do db ulozit cenu s dph alebo zaklad dph...
Proč bych vám to ukazoval v SQL, když SQL nerozumíte?
Popisoval jste tu chování měnového typu v MySQL – přitom příklad jste měl v PostgreSQL. Nevím, zda jste to chování popsal správně, každopádně z vašeho popisu plyne, že by MySQL zaokrouhlovala vždy k nule. Stejným způsobem zaokrouhluje PostgreSQL při dělení inetegrem. Jsem si téměř jistý, že zaokrouhlování k nule není při výpočtu DPH povoleno (přece se stát nebude systematicky obírat o halíře, že).
Váš příklad je ovšem v PostgreSQL. Které při dělení monetárního typu zaokrouhluje k nejbližší sudé hodnotě (a to ještě záleží na platformě). To je jedno ze spravedlivých zaokrouhlování, byl bych rád, kdyby při zaoukrouhlování DPH bylo povolené, ale nejsem si úplně jistý, že to tak je (opět – v některých případech to vyjde o haléř méně, než zaokrouhlování pětky nahoru, které se učí na ZŠ a které určitě pro výpočet DPH povolené bude – možná jako jediné).
Celou dobu tady řešíme i zaokrouhlování, a vy klidně použijete systémové zaokrouhlování nějaké databáze, aniž byste se zajímal o to, jak ta databáze vlastně zaokrouhluje. Jak pak můžete vědět, že zaokrouhluje tak, jak potřebujete? No nevíte to. Jenže tohle je úplně mimo vaše obzory, že.
tvl, javascript, pritom je tolko krasnych jazykov, ako napriklad plsql. Njn, js, na monitore sami vyhadzali vyrazky...
Tak proč jste to v tom PL/SQL nenapsal? Ale správně.
Ako tu skaredu vec citam tak vy ste v omyle ze ak pocitam s datovym typom MONEY v postgrese tak sa zaokruhluje transparentne nadol?
Se zaokrouhlováním k nule jsem počítal proto, že jste o něm vy psal (akorát jste o tom zjevně nevěděl).
Otvorime si konzolu, spustime psql a skusime:
# SET lc_monetary to "cs_CZ";
SET
# SELECT '1,005'::money;
┌─────────┐
│ money │
├─────────┤
│ 1,01 Kč │
└─────────┘
(1 řádka)
Napada vas nejaka krajina kde su pre zaokruhlovanie meny ine pravidla, ak hej tak dajte kod, alebo si skuste sam.
Tím jste toho o zaokrouhlování v PostgreSQL moc nezjistil. Asi to bude zaokrouhlování k nejbližší hodnotě – ale jak přesně se zaokrouhluje prostřední hodnota? Nahoru? Od nuly? K liché? To jste nezjistil. Stejně tak jste nezjistil, zda se to tak chová na všech platformách. To byste se totiž musel podívat do dokumentace. A také jste nezjistil. jak funguje zaokrouhlování při výpočtech.
Vyzkoušejte si třeba tohle:
SELECT '0.01'::money * 0.5, '0.03'::money * 0.5;Třeba se pak konečně podíváte do dokumentace PostgreSQL, jak zaokrouhluje.
A jaká pravidla pro zaokrouhlování DPH tedy podle vás platí v ČR?
„Zaokrouhlování měny“ je samozřejmě totální nesmysl. Různé významy měny se zaokrouhlují různě – už jenom u daní se v různých případech zaokrouhluje na celé koruny nahoru i dolů, na celé stovky nahoru i dolů. Pokud jste tím myslel „zaokoruhlování měny v PostgreSQL“, tak za prvé to právě ukazuje na to, že když databáze zaokrouhluje jedním způsobem, ale vy potřebujete použít několik různých způsobů, zjevně se nemůžete spoléhat jen na systémové zaokrouhlování v databázi. Za druhé, kdybyste se ráčil podívat do dokumentace, zjistil byste, že zaokrouhlování typu money a souvisejících operací v PostgreSQL není závislé na nastavené měně – ta určuje jenom počet platných desetinných míst.
-
Vy ste na drogach? Celu tuto saskaren roztocite koli tomu ze nakoniec napisete ze mam pravdu? Tj. ze z ceny (s DPH) dokazem vzdy vypocitat zaklad, kdezto zo zakladu nedokazem vypocitat vsetky ceny (s DPH).
Nikoli, to celé jsem psal, abych nakonec dokázal, že nemáte pravdu hned v několika bodech:
- Zákon umožňuje výpočet DPH „zdola“, tj. od základu daně, podle § 37 písmeno a), nebo „shora“, tj. od celkové částky za danou položku faktury, podle § 37 písmeno b). Takže se mýlíte v tom, že je možný pouze výpočet shora.
- Když budete DPH počítat zdola a dojdete k nějaké výsledné ceně s daní, když vypočtete z této celkové částky znova daň metodou shora, dojdete ke stejné dani. Takže se mýlíte v tom, že ty dva způsoby výpočtu dávají různé výsledky.
- Absolutně plavete v zaokrouhlování, asi jste vůbec netušil, že existují různé způsoby zaokrouhlování. A že při daňových výpočtech musíte použít takové zaokrouhlování, které připouští zákon – nemůžete jen tak použít zaokrouhlování nějaké knihovny či aplikace, aniž byste si ověřil, jak zaokrouhluje.
- Nechápete daňovou rekapitulaci. Daňová rekapitulace je jenom suma položek na faktuře, žádná daň se tam nevypočítává.
-
Tuto hru uz s vami hrat nebudem. Zase sem nalejete kopu hnoja, a zase tu o tom budeme tocit 2 dni... Staci ak si porovnate to co som tvrdil povodne a co ste vy potvrdil. Lenze vy si potrebujete obhajit hovadinu, ze budete do DB ukladat zaklad dane na 4 desatinne miesta, aby ste vedel dopocitat cenu(s DPH). Pritom by stacilo ukladat cenu(s DPH) a dopocitat zaklad.
Na dalsie kolecko uz fakt nemam chut, mam prijemnejsie moznosti ako stravit vikend.
jenom dvojice { bez-dph, dph% } nebo dvojice { dph%, s-dph }
S DPH, z tej idu vypocitat vsetky hodnoty bez DPH. Pri opacnom postupe tj. vypocet ceny s dph z ceny bez dph, nie je mozne koli zaokruhlavaniu pokryt niektore hodnoty...
Pro výpočet ze základu daně podle písmene a) je správně jen 9,98 Kč (při sazbě DPH 23 %). Pro výpočet shora podle písmena b) jsou správné obě, jak 9,97 Kč tak 9,98 Kč (logicky, z obou dvou dokážete vypočítat daň).
-
Staci ak si porovnate to co som tvrdil povodne a co ste vy potvrdil.
S DPH, z tej idu vypocitat vsetky hodnoty bez DPH. Pri opacnom postupe tj. vypocet ceny s dph z ceny bez dph, nie je mozne koli zaokruhlavaniu pokryt niektore hodnoty...
To, co jste tvrdil původně, není pravda. Možné jsou oba postupy – jak počítat DPH ze základu, tak počítat DPH z celkové ceny položky na faktuře. To, že prvním postupem se nedostanete k libovolné celkové ceně je úplně jedno – počítáte to ze základu, takže nikdy nemůže nastat případ, že to spočítat nejde.
Vy jste pak ovšem tvrdil takové nesmysly, jako že se to musí počítat vždy z celkové ceny nebo že výpočet z celkové ceny a ze základu vychází různě. Nic z toho není pravda. DPH se může počítat oběma směry, a pro částky, pro které existují oba směry výpočtu, dávají oba směry stejné výsledky. Vy jste také tvrdil opak. A pak jste se ještě úplně ztratil v v zaokrouhlování a v rekapitulaci daně.
Lenze vy si potrebujete obhajit hovadinu, ze budete do DB ukladat zaklad dane na 4 desatinne miesta, aby ste vedel dopocitat cenu(s DPH).
Nic takového já jsem nikdy netvrdil.
Ale fajn, tak snad už jste konečně pochopil, že se DPH může počítat oběma směry, a že výpočet oběma směry dává stejný výsledek (pro částky, kde oba směry existují).
-
Vy jste pak ovšem tvrdil takové nesmysly, jako že se to musí počítat vždy z celkové ceny nebo že výpočet z celkové ceny a ze základu vychází různě.
Fakt? Dajte link. Ja tvrdim nieco ine, popisem nizsie.
Lenze vy si potrebujete obhajit hovadinu, ze budete do DB ukladat zaklad dane na 4 desatinne miesta, aby ste vedel dopocitat cenu(s DPH).
Nic takového já jsem nikdy netvrdil.
Tak na 3, tu: ...
Ale fajn, tak snad už jste konečně pochopil, že se DPH může počítat oběma směry, a že výpočet oběma směry dává stejný výsledek (pro částky, kde oba směry existují).
To ale nie je jednosmerny alebo obojsmerny vypocet.
Takto: Majme 3 mnoziny ktorych prvky su ceny. Kazda cena je uvedena na pocet miest, na ktore je delena, kolko je to miest je irelevantne. Tak isto aj sposob zaokruhlovania je irelevantny, s tym ze sa pouzije len sposob definovany pre menu ktoru pouzijeme.
Mnozina A: obsahuje vsetky mozne ceny z nejakeho rozsahu. Je irelevantne kde ten rozsah zacina alebo konci.
Mnozina B: obsahuje zaklady DPH (alebo ceny bez dph), vypocitane pre prvky v mnozine A.
Mnozina C: obsahuje ceny s DPH, vypocitane pre prvky z mnoziny B.
V com je problem: Mnozina C nikdy nebude zhodna s mnozinou A. Vzdy to bude len jej podmnozina.
Cize ak mate v DB stlpce "s dph" a "bez dph", tak na otazku ktory stlpec ponechat tak mame 2 moznosti:
- Ponechame stlpec s DPH, pretoze pricetny clovek netusi ci je tento stlpec z mnoziny A alebo C. Stlpec "bez dph" zmaze, pretoze mnozinu B dokaze dopocitat jak zmnoziny A tak s mnoziny B
- Ponechame stlpec bez DPH, napriek tomu ze netusime ci neobsahuje aj ceny z mnoziny A. Tym padom sme odkazany na ceny s DPH len z mnoziny C
Vy ste si uvedomil ze moznost 2 je blbost, pretoze ani vy nemozete tusit ze ceny s DPH budu prave z mnoziny C. Lenze nebol by ste TROL keby ste zvolil moznost 1. Miesto toho ste zvolil moznost 2, ktoru ste si ohol tak aby vam vyhadzali ceny aj pre mnozinu A (pridal ste si k cene bez dph jedno desatinne miesto). Napriek tomu ze to riesi co riesit netreba (stacilo by zvolit moznost 1). Potom vsetky vypocty skrz celou bussines logikou budu musiet ratat s tym ze ta cena je ulozena nestandartne. Skuste si napisat napriklad sql dotaz, kde pred scitatnim sa stlpec zaokruhluje, a zajte si na to zobrazit plan toho dotazu.
K tej vasej obojsmetnosti/jednosmernosti: funcia je vzdy jednosmerna. Moze k nej ked tak existovat funkcia inverzna. Ale ani ta nie je obojsmerna.
-
Vy jste pak ovšem tvrdil takové nesmysly, jako že se to musí počítat vždy z celkové ceny nebo že výpočet z celkové ceny a ze základu vychází různě.
Fakt? Dajte link. Ja tvrdim nieco ine, popisem nizsie.
Tvrdil jste to například tady:
Ta definicia pojmu ale urcuje aj to ako a z coho sa ma pocitat. Pisali to uctovnici ktori svojej praci rozumeju a vedia ze pocitat cenu zo zakladu dane je blbost, pretoze to nebude sediet. Tu mate dokaz: https://www.db-fiddle.com/f/2dtPBSzttFYo2NRirU5SdZ/0
Tady jste to zkoušel dokazovat chybnými příklady:
A ak sa uzodvolavate na priklad, tak pouzite nieco co je mozne overit, nie len nejaku vasu dalsiu fabulaciu.
Moj priklad mate tu:
Ulozeny zaklad a cena dopocitana: https://www.db-fiddle.com/f/2dtPBSzttFYo2NRirU5SdZ/0
Ulozena cena a dopocitany zaklad: https://www.db-fiddle.com/f/gLsufiz9jJ4WbsX96LeEbs/0
Zistite ze ukladanie zakladu je ohybak na ktory musite aplikovat rovnak. Kdezto pri ulozenej cene a dopocitanom zaklade cisla sedia bez akehokolvek ohybaku a rovnaku.
Tak na 3, tu: ...
Tam je ale napsané něco jiného. Jinak jsem zde odkazoval příklad, kde jsou daňový základ, daň i celková cena na dvě desetinná místa. Takže celkovou cenu na dvě desetinná místa zjevně zvládám spočítat i ze základu na dvě desetinná místa.
To ale nie je jednosmerny alebo obojsmerny vypocet.
Ne, výpočet DPH je jednosměrný výpočet, a možné jsou dva různé jednosměrné výpočty. Jeden způsob výpočtu DPH je ze základu daně, druhý způsob výpočtu DPH je z celkové částky. Použije se ten způsob výpočtu, pro který máte data.
Takto: Majme 3 mnoziny ktorych prvky su ceny. Kazda cena je uvedena na pocet miest, na ktore je delena, kolko je to miest je irelevantne. Tak isto aj sposob zaokruhlovania je irelevantny, s tym ze sa pouzije len sposob definovany pre menu ktoru pouzijeme.
Mnozina A: obsahuje vsetky mozne ceny z nejakeho rozsahu. Je irelevantne kde ten rozsah zacina alebo konci.
Mnozina B: obsahuje zaklady DPH (alebo ceny bez dph), vypocitane pre prvky v mnozine A.
Mnozina C: obsahuje ceny s DPH, vypocitane pre prvky z mnoziny B.
V com je problem: Mnozina C nikdy nebude zhodna s mnozinou A. Vzdy to bude len jej podmnozina.
Jenže tohle je nesmysl, takhle se DPH nepočítá. Když máte daný daňový základ, počítá se DPH z něj. Když máte danou celkovou částku, počítá se DPH z ní. Nikdy nemáte daný daňová základ i celkovou částku zároveň.
Cize ak mate v DB stlpce "s dph" a "bez dph", tak na otazku ktory stlpec ponechat tak mame 2 moznosti:
Jenže tohle nikdo neřeší.
K tej vasej obojsmetnosti/jednosmernosti: funcia je vzdy jednosmerna. Moze k nej ked tak existovat funkcia inverzna. Ale ani ta nie je obojsmerna.
Tak se tu nesnažte vymýšlet obousměrnou funkci na výpočet DPH.