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

Re:MySQL a přecenění se změnou DPH
« Odpověď #45 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?


Re:MySQL a přecenění se změnou DPH
« Odpověď #46 kdy: 03. 01. 2024, 18:24:58 »
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ě.

Re:MySQL a přecenění se změnou DPH
« Odpověď #47 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

Re:MySQL a přecenění se změnou DPH
« Odpověď #48 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 ;)

Re:MySQL a přecenění se změnou DPH
« Odpověď #49 kdy: 03. 01. 2024, 18:43:09 »
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.


Re:MySQL a přecenění se změnou DPH
« Odpověď #50 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 :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?

Re:MySQL a přecenění se změnou DPH
« Odpověď #51 kdy: 03. 01. 2024, 19:44:59 »
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.

Re:MySQL a přecenění se změnou DPH
« Odpověď #52 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.

Re:MySQL a přecenění se změnou DPH
« Odpověď #53 kdy: 03. 01. 2024, 20:48:17 »
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.

Re:MySQL a přecenění se změnou DPH
« Odpověď #54 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.

Re:MySQL a přecenění se změnou DPH
« Odpověď #55 kdy: 03. 01. 2024, 21:18:18 »
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).

Re:MySQL a přecenění se změnou DPH
« Odpověď #56 kdy: 03. 01. 2024, 21:45:25 »
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.

Re:MySQL a přecenění se změnou DPH
« Odpověď #57 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.

Re:MySQL a přecenění se změnou DPH
« Odpověď #58 kdy: 03. 01. 2024, 22:58:39 »
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

Re:MySQL a přecenění se změnou DPH
« Odpověď #59 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.