Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Death Walker

Stran: [1] 2 3 ... 34
1
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 08. 01. 2024, 06:06:54 »
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.

2
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 06. 01. 2024, 11:15:31 »
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ň).

3
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 06. 01. 2024, 09:06:49 »
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). 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).

4
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 06. 01. 2024, 08:56:52 »
...
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:
Kód: [Vybrat]
# 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.

5
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 04. 01. 2024, 18:39:29 »
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.

6
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 04. 01. 2024, 18:35:47 »
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.

7
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 04. 01. 2024, 17:49:25 »
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.

8
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 04. 01. 2024, 17:47:14 »
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.

9
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 04. 01. 2024, 16:56:37 »
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.

10
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 04. 01. 2024, 15:44:27 »
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.

11
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 04. 01. 2024, 15:34:50 »
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.

12
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 04. 01. 2024, 15:12:56 »
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.

13
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 04. 01. 2024, 14:55:44 »

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.

14
Vývoj / Re:MySQL a přecenění se změnou DPH
« kdy: 04. 01. 2024, 14:50:14 »
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.

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

Stran: [1] 2 3 ... 34