MySQL a přecenění se změnou DPH

[Lord_Pitzbudka]

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.

[Reklama]

[Filip Jirsák]

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.

[fos4]

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..

[Death Walker]

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).

[Pavel...]

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.

[Reklama]

[Death Walker]

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.

[Death Walker]

Alebo neriesite a zakaznik nema narok na ceny ako 7,99 pretoze to zo zakladu dph nevypocitate...

[Filip Jirsák]

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.

[Death Walker]

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.

[Death Walker]

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.

[Hyp]

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

[RDa]

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.

[Daniel Mašek]

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 ;-)

[Lord_Pitzbudka]

Konecne rozumny pohled!

[Death Walker]

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.