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.
101 Odpovědí
15164 Zhlédnutí