Příspěvky

16

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 04. 01. 2024, 14:40:46 »

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.

17

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 04. 01. 2024, 14:37:24 »

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?

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.

18

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 23:21:07 »

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.

19

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 23:10:08 »

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.

20

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 22:51:06 »

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.

21

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 20:56:35 »

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.

22

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 20:43:13 »

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.

23

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 18:56:53 »

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

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?

24

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 18:40:41 »

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

25

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 18:35:46 »

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

26

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 18:24:03 »

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?

27

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 18:19:40 »

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.

28

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 08:53:47 »

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.

29

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 03. 01. 2024, 08:45:34 »

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.

30

Vývoj / Re:MySQL a přecenění se změnou DPH

« kdy: 01. 01. 2024, 22:15:34 »

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