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

[Hyp]

Zdravím všechny, myslel jsem, že přecením zásoby v souvislosti se změnou DPH  přímo v mysql

Kód: [Vybrat]

UPDATE `karta` SET `prodejnicenabezdph`=Round(`prodejnicenabezdph`*((100+(SELECT `sazbadph` FROM `sazbadph` WHERE `iddph`=`dphvystup`))/100),0)/1.12 WHERE `dphvystup`=1 or `dphvystup`=3Problém je, že do databáze se např. pokud je cena s DPH12% 91Kč uloží místo 81.25 částka 81.24999999999. Pokud změním ručně na 81.25, pak mi dotaz

Kód: [Vybrat]

SELECT `prodejnicenabezdph`*1.12 vrátí 91.00000000000001 ale

Kód: [Vybrat]

SELECT 81.25*1.12 vrátí 91.
Taky dotaz např.

Kód: [Vybrat]

SELECT `prodejnicenabezdph`, `prodejnicenabezdph`*1.12+0 FROM `karta` WHERE 1; vrací 81.25  a    91.00000000000001.
Zaokrouhlování nemám moc řešeno, ale hlavně netuším důvod, proč tomu tak je.
Hodnota je double, ale pokud změním na FLOAT, tak výsledek je stejný.
Děkuji za každou nápomoc.

[Reklama]

[CFM]

Nepoužívat float https://stackoverflow.com/questions/13030368/best-data-type-to-store-money-values-in-mysql ?

[Hyp]

Nepoužívat float https://stackoverflow.com/questions/13030368/best-data-type-to-store-money-values-in-mysql ?

Díky za odpověď. Používal jsem double, ale výsledek byl stejný. Pokud dám decimal 15.4, tak tento případ je OK, otestuji zítra a potvrdím.
Díky Hyp

[panpanika]

vis jak se double jmenuje plnym jmenem?

[Tomas-T]

Pro přesné počítání peněz vždy jen decimal.
Float je je oproti decimalu sice rychlejší a úspornější, ale daní za to je občasné drobná nepřesnost.
U čísla 4.4587965874 taková nepřesnost obvykle nevadí a nikdo si jí nevšimne, ale u čísel s používaným malým počtem desetinných míst to tluče do očí.
Alternativou může být všechny výstupy vždy zaokrouhlovat.

[Reklama]

[Pavel...]

Používal jsem double, ale výsledek byl stejný.

z podstaty veci: pocitac interne nepocita v desiatkovej sustave. Ked budete pouzivat akukolvek verziu float-u, tak niekde na vas moze vyskocit, ze na x-tom desatinnom mieste sa schovalo nieco co nechcete.
Krasne to je vidno na Javascripte, kde sa to fakticky podla mna ani neda riesit. (spresnenie pre stalice FJ & D: som ochotny pripustit, ze uz dva dni existuje mne neznamy postup, ktory to riesi )

t.j. spravte si vsetky stlpce na peniaze na dve desatinne miesta a budete to mat tak, ako by to robil zivy clovek.
Co je to co sa pokusate v aplikacii napodobnit.

Alternativou může být všechny výstupy vždy zaokrouhlovat.

takyto pristup je koledovanie si o "zahadne chyby", kde uzivatel vidi v stlpci hrst cisel a sucet sa lisi o cent

[RDa]

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

[Death Walker]

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

[RDa]

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

To by platilo, pokud uvazujete ciste o B2C eshopu a nejste platce - coz je takova situace, ze si jen hrajete na biz. Jakmile se jedna o vice B2B a je umozneno obchodovat s platci.. tak je primarnejsi hodnota ta cena bez dph. V praxi se pouziva to i to, zalezi od pristupu subjektu no. Takze jsem to ve svem reseni musel pokryt univerzalne.

A z pohledu statu - danovych priznani, je primarni hodnotou take castka bez dane ,)

[Filip Jirsák]

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

To by platilo, pokud uvazujete ciste o B2C eshopu a nejste platce - coz je takova situace, ze si jen hrajete na biz. Jakmile se jedna o vice B2B a je umozneno obchodovat s platci.. tak je primarnejsi hodnota ta cena bez dph. V praxi se pouziva to i to, zalezi od pristupu subjektu no. Takze jsem to ve svem reseni musel pokryt univerzalne.

A z pohledu statu - danovych priznani, je primarni hodnotou take castka bez dane ,)

Ještě bych doplnil, že se zaokrouhlují až výstupní hodnoty. Takže nic nebrání tomu mít v databázi hodnotu uloženou s přesností třeba na desetiny halíře, abyste se i po připočtení/odečtení DPH trefil na hezké hodnoty. Zaokrouhlujete pak teprve vypočtenou hodnotu, a to v obou případech (bez DPH i s DPH).

[Pavel...]

Takže nic nebrání tomu mít v databázi hodnotu uloženou s přesností třeba na desetiny halíře, abyste se i po připočtení/odečtení DPH trefil na hezké hodnoty. Zaokrouhlujete pak teprve vypočtenou hodnotu, a to v obou případech (bez DPH i s DPH).

jasne a klientovi budete na fakture uctovat tiez desatiny haliera, ze?
uz ste dakedy skusal nieco na tu temu riesit?

klienti zboznuju ad-hoc zostavy, kde sa s niecim taky fakt uzasne pracuje .

[RDa]

Takže nic nebrání tomu mít v databázi hodnotu uloženou s přesností třeba na desetiny halíře, abyste se i po připočtení/odečtení DPH trefil na hezké hodnoty. Zaokrouhlujete pak teprve vypočtenou hodnotu, a to v obou případech (bez DPH i s DPH).

jasne a klientovi budete na fakture uctovat tiez desatiny haliera, ze?
uz ste dakedy skusal nieco na tu temu riesit?

klienti zboznuju ad-hoc zostavy, kde sa s niecim taky fakt uzasne pracuje .

To jste asi nepochopil co se snazil FJ rict. Fakturujete klientovi jednu vyslednou castku (urcenou k platbe), a ta je ta, co je zaokrouhlena na halire (u platbe prevodem, kartou) nebo koruny (pri platbe v hotovosti).

A pokud je v procesu jeste menova konverze, tak ta vam taky prida nekolik desetinnych mist, a u exotickych men je nekdy potreba i hodne mist pred teckou, protoze jsou v miliardovem meritku...

.. a pak nakonec skoncite na DECIMAL(30,18)

[Filip Jirsák]

Takže nic nebrání tomu mít v databázi hodnotu uloženou s přesností třeba na desetiny halíře, abyste se i po připočtení/odečtení DPH trefil na hezké hodnoty. Zaokrouhlujete pak teprve vypočtenou hodnotu, a to v obou případech (bez DPH i s DPH).

jasne a klientovi budete na fakture uctovat tiez desatiny haliera, ze?
uz ste dakedy skusal nieco na tu temu riesit?

klienti zboznuju ad-hoc zostavy, kde sa s niecim taky fakt uzasne pracuje .

Doporučuju nastudovat si pojem „zaokrouhlování“. V mém komentáři je podstatný, když ho jen tak přeskočíte, protože mu nerozumíte, komentář vám opravdu nemůže dávat smysl.

Jinak lidé pracující s měnovými částkami běžně zaokrouhlovat umí. Například české koruny se dělí na sto halířů, ale v hotovostní oběživu už halíře neexistují. Ale třeba v obchodech naprosto běžně narazíte na cenovky s desítkami halířů, někde i s halíři – a když pak platíte v hotovosti, obchodník to musí zaokrouhlit.

Nebo třeba různé cloudové služby mají často v ceníku položky, kdy jednotka za měsíc stojí třeba desetinu nebo setinu centu. A také zaokrouhlí až celkovou částku na faktuře, protože kdyby zaokrouhlovali ty ceníkové částky, přijdou na buben.

[Hyp]

Děkuji všem za pomoc, změněno v DTB na decimal 15,4

[jjrsk]

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

Ehm lol ... ne. VZDY se pouziva cena BEZ DPH. Z te se plati veskere odvody, dane, to DPH atd atd atd. Cena s DPH nikoho kdo DPH vybira nezajima.

...

Naprosty nesmysl, ale co cekat od vseznalka Jirsaka ktery nevi ani to, ze nejmensi castkou dle zakona je 0,01Kc bezhotovostne nebo 1Kc hotove. Takze mit jakekoli ceny na jakali dalsi mista je holy nesmysl. Ktery pak jen vede k tomu, ze nesouhlasi soucty.

Doporučuju nastudovat si pojem „zaokrouhlování“. ....

A uz si zacal? Chci videt, jak na fakturu vytisknes 10 polozek, kdyz kazda jedna bude mit cenu na 5 desetin, aby soucet souhlasil ... a dal se zaplatit.